Janimede

17 de diciembre de 2013

Eclipse Juno desapareció la consola

Me sucedió que desapareció la vista de consola y no vuelve al hacer Window>showview>console

la solución fue Window>reset perspective

17 de noviembre de 2011

Jax wsimport Two classes have the same XML type name

Tomado Desde jackdevofalltrades

JAX-WS "Two classes have the same XML type name"

When generating the Java classes using wsgen from a WSDL I was getting the following error:

Two classes have the same XML type name "{http://myservice/}foo". Use @XmlType.name and @XmlType.namespace to assign different names to them.
this problem is related to the following location:

As suggested by the exception I tried changing @XmlType but that was fine for me.
This link offers the same solution and it also suggests to change Response classes which I think its an extreme solution.

Anyway in my case the problem was that I generated the classes and I wanted to change the package name.
Everything worked fine, compiled and the webservice deployed successfully.
When viewing the WSDL I got the above error.
In my case the solution was just to update the new namespace in the Webmethod attribute.

@WebMethod
@WebResult(targetNamespace = "")
@RequestWrapper(localName = "foo", targetNamespace = "http://fooservice/", className = "com.foo.service.generated.foo")
@ResponseWrapper(localName = "fooResponse", targetNamespace = "http://fooservice/", className = "com.foo.service.generated.FooResponse")

The attribute className had to be updated :(

3 de octubre de 2011

Presentando JSF 2

Extraido de http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=jsf2Return

Índice de contenidos

1. Introducción 2. Entorno 3. “Instalando” JSF 2 en nuestro proyecto
3.1. web.xml
4. Creando nuestra plantilla para la aplicación
4.1. defaultLayout.xhtml
4.2. Gestión de recursos
4.2.1. ¿Qué significa el atributo library y name?
5. Creando la página de login
5.1. loginView.xhtml
5.2. Validaciones según la JSR-303
5.3. Soporte para AJAX
5.4. Navegación
6. Creando la página de alta y listado
6.1. listTutorialsView.xhtml
6.2. Haciendo nuestros propios conversores
6.3. Listas desplegables relacionadas en cascada
6.4. Ámbito de los BackBeans
6.5. Declaración de los backbeans e Inyección de Dependencias
7. ¿Y dónde está el fichero de configuración faces-config.xml?
8. Conclusiones
9. Sobre el autor
10. Recursos de interes

3. “Instalando” JSF 2 en nuestro proyecto

El tutorial lo he planteado como un pequeño proyecto donde veremos en funcionamiento varias de las nuevas funcionalidades de JSF 2. El código completo del proyecto lo podéis descargar aquí
El proyecto básicamente tiene dos pantallas, una de login (más falsa que un duro de madera) y otra donde podremos dar de alta tutoriales y veremos el listado con lo que vamos añadiendo.
El proyecto está preparado con Maven, donde nos encontraremos la siguiente jerarquía de proyectos:

autentiaJsf2-parent: Es el proyecto padre que dirige la compilación del resto de proyectos.
- autentiaJsf2-model: Tendremos las clases del modelo.
- autentiaJsf2-web: Tendremos las clases de la interfaz Web, y por supuesto toda la chicha sobre JSF 2 que nos interesa en este tutorial.

A lo largo del tutorial vamos a ir mostrando trozos de código y comentando las nuevas funcionalidades.
Empezaremos por enseñar como declara las dependencias de Maven para poder usar JSF 2. En el pom.xml del parent y el model no hay nada destacable, lo interesante está en el proyecto web:

	... 
	<dependencies>
		<dependency>
			<groupId>com.autentia.tutorial.jsf2</groupId>
			<artifactId>autentiaJsf2-model</artifactId>
			<version>${version}</version>
		</dependency>

		<!-- API e implementación de JSF 2. Del repo dev.java.net -->
		<dependency>
			<groupId>com.sun.faces</groupId>
			<artifactId>jsf-api</artifactId>
			<version>2.0.2-b10</version>
		</dependency>
		<dependency>
			<groupId>com.sun.faces</groupId>
			<artifactId>jsf-impl</artifactId>
			<version>2.0.2-b10</version>
		</dependency>

		<!-- API e implementación de JSR-303 (validaciones). Del repo de jboss -->
		<dependency>
			<groupId>javax.validation</groupId>
			<artifactId>validation-api</artifactId>
			<version>1.0.0.GA</version>
		</dependency>
		<dependency>
			<groupId>org.hibernate</groupId>
			<artifactId>hibernate-validator</artifactId>
			<version>4.0.2.GA</version>
		</dependency>
	</dependencies>

	<repositories>
		<repository>
			<id>maven2-repository.dev.java.net</id>
			<name>Java.net Repository for Maven</name>
			<url>http://download.java.net/maven/2</url>
		</repository>
		<repository>
			<id>maven2-repository.jboss.com</id>
			<name>Jboss Repository for Maven</name>
			<url>http://repository.jboss.com/maven2</url>
		</repository>
	</repositories>
	...

Podemos ver en las líneas 34-45, como se declaran dos repositorios. Esto es necesario porque los jar todavía no están disponibles en el repositorio público de ibiblio. Más arriba vemos como se declaran las dependencias: por un lado incluimos tanto el api (paquetes javax.faces) como la implementación (paquetes com.sun.faces); ambos son necesarios. También se puede ver como se incluye el validation-api e hibernate-validator. El primero es la interfaz del JSR-303 y el segundo es la implementación que da Hibernate a este JSR. Este JSR-303 ya está dentro de JSF 2 y nos permite, mediante anotaciones, especificar que validaciones queremos hacer sobre nuestros beans (más adelante veremos ejemplos de esto).

3.1. web.xml

El web.xml es extremadamente sencillo:

<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://java.sun.com/xml/ns/javaee"
	xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee 
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd"
	id="WebApp_ID" version="2.5">

	<display-name>Autentia JSF 2 Tutorial</display-name>

	<context-param>
		<description>
			Define the value returned by Application.getProjectStage(). Allowed values: Production, Development, 
			UnitTest, SystemTest, Extension. Default value is Production.
		</description>
		<param-name>javax.faces.PROJECT_STAGE</param-name>
		<param-value>Development</param-value>
	</context-param>

	<!-- Definir este parámetro es más cómodo y más visual que usar el <ui:remove> de Facelets. -->
	<context-param>
		<description>Do not render comments in facelets (xhtml) pages. Default is false.</description>
		<param-name>javax.faces.FACELETS_SKIP_COMMENTS</param-name>
		<param-value>true</param-value>
	</context-param>

	<servlet>
		<servlet-name>Faces Servlet</servlet-name>
		<servlet-class>javax.faces.webapp.FacesServlet</servlet-class>
		<load-on-startup>1</load-on-startup>
	</servlet>

	<servlet-mapping>
		<servlet-name>Faces Servlet</servlet-name>
		<url-pattern>*.xhtml</url-pattern>
	</servlet-mapping>

</web-app>

Lo único destacable es la línea 13 donde indicamos la variables PROJECT_STAGE. Esto nos sirve para indicar si estamos en desarrollo, en producción, ... Esto va ha hacer que determinadas piezas o componentes se comporten de forma distinta. Por ejemplo hay ciertos componentes que en producción darán una excepción ante un error, mientras que en desarrollo sacarán un mensaje en el propio HTML. Esta variable también se puede definir por JNDI, cosa que sería casi más recomendable, para no tener que modificar el fichero cada vez que queremos hacer una instalación en un entorno diferente.
También vemos en la línea 20 la variable FACELETS_SKIP_COMMENTS. Esta nos permite indicar que los comentarios de XML  no se interpreten. En Facelets, por defecto, se interpreta todo, incluso los comentarios. Si queremos que algo no se interprete por el motor de Facelets habría que usar la etiqueta <ui:remove>, pero a mi me resulta más cómodo e intuitivo usar los comentarios de verdad, así que prefiero activar este parámetro.

4. Creando nuestra plantilla para la aplicación

Una de las novedades es que Facelets ya está integrado dentro del propio estándar (antes lo podíamos usar pero eramos nosotros los que nos teníamos que encargar de la integración ya que era un JAR “de terceros”).
Facelets es un sistema de plantillas que nos va a permitir tanto crear plantillas o layouts de nuestra aplicación, como crear nuestros propios componentes por composición de forma muy sencilla (podemos hacer un componente como la suma/composición de otros componentes más pequeños).
Otra de las ventajas de usar Facelets es que nos libramos de las dichosas JSP, y no es que tenga nada en contra de ellas, pero su ciclo de vida no casa con el del diseño en base a componentes de JSF. Así, a partir de ahora, nos vamos a dedicar a escribir XHTML (es decir ficheros XML bien formados y válidos). Además Facelets procesan estos ficheros más rápido que las clásicas JSP, por lo que todo son ventajas ;)

4.1. defaultLayout.xhtml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets"
	xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html">

<h:head>
	<meta http-equiv="Content-Type" content="text/html; charset=UTF-8" />
	<h:outputStylesheet library="css" name="style.css" />
	<title>Autentia JSF 2 Tutorial</title>
</h:head>

<h:body>
<div id="layout">

	<div id="top" class="top">
		<ui:insert name="top">
			<span id="title">Autentia JSF 2 Tutorial</span>
			<a href="http://www.adictosaltrabajo.com" target="_blank">
				<h:graphicImage library="img" name="logoAdictosAlTrabajo.png" alt="Adictos Al Trabajo" height="31" />
			</a>
		</ui:insert>
	</div>

	<div id="content">
		<h1><ui:insert name="title">??? View title ???</ui:insert></h1>

		<ui:insert name="content">??? View content ???</ui:insert></div>

		<div id="bottom">
			<ui:insert name="bottom">
				<span id="copyright">Esta aplicación se distribuye bajo licencia <a href="http://www.gnu.org/licenses/gpl-3.0-standalone.html">GPL</a></span>
				<a href="http://www.autentia.com" target="_blank">
					<h:graphicImage value="#{resource['img:poweredByAutentia_100x30x72dpi.png']}" />
				</a>
			</ui:insert>
		</div>
	</div>
</h:body>
</html>

4.2. Gestión de recursos

No vamos a explicar como funciona el sistema de plantillas de Facelets, porque eso no es nuevo, pero si vamos a destacar algunos elementos:
Línea 09 h:outputStylesheet - Nos permite indicar que CSS queremos añadir en nuestra página. Por defecto esta CSS se añadirá en el HEAD del html pero con un atributo podemos forzar que se incluya en el BODY. Aunque hemos puesto la etiqueta dentro de h:head, esto no quiere decir nada, la propia etiqueta h:outputStylesheet determina donde se acabará pintando en el html final la inclusión de la CSS. Las CSS por defecto se incluyen en el HEAD, pero tenemos otra etiqueta para incluir JavaScript (h:outputScript) que por defecto lo incluyen en el BODY.

4.2.1. ¿Qué significa el atributo library y name?

JSF 2 va a servir los recursos de un directorio resources que puede estar situado en nuestro directorio webapp (donde tenemos las imágenes, html, ...) o dentro del directorio META-INF (esto da pie a empaquetar recursos dentro de un JAR).
El atributo library indica un subdirectorio dentro de este directorio resources, y el atributo name, el nombre del recurso que se quiere servir. De esta forma library="css" name="style.css" buscará el fichero resources/css/style.css
Línea 20 h:graphicImage - Es la misma idea que antes, pero para mostrar imágenes. Vemos como sigue la misma idea de library y name.
Línea 34 #{resource['img:poweredByAutentia_100x30x72dpi.png']} - es otra forma de hacer referencia a un recurso, esta vez usando EL. La idea es la misma, pondremos library:nombreDelRecuros

5. Creando la página de login

5.1. loginView.xhtml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets"
	xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html">

<ui:composition template="./defaultLayout.xhtml">
	<ui:define name="title">Login</ui:define>

	<ui:define name="content">
		<h:form>
			<h:panelGrid columns="3">
				<h:outputLabel for="name" value="Nombre" />
				<h:inputText id="name" label="Nombre" value="#{loginView.name}">
					<f:validateBean />
					<f:ajax render="nameError" />
				</h:inputText>
				<h:message id="nameError" for="name" errorClass="error" />

				<h:outputLabel for="password" value="Clave" />
				<h:inputSecret id="password" label="Clave" value="#{loginView.password}">
					<f:validateBean />
					<f:ajax render="passwordError" />
				</h:inputSecret>
				<h:message id="passwordError" for="password" errorClass="error" />
			</h:panelGrid>

			<h:commandButton action="listTutorialsView" value="Entrar" />
		</h:form>
	</ui:define>
</ui:composition>
</html>

5.2. Validaciones según la JSR-303

En la línea 15 nos encontramos con

<f:validateBean
/>

. Con esta nueva etiqueta estamos indicando que queremos usar una validación de Bean, es decir, que queremos usar una validación basada en la JSR-303.
Estas validaciones se definen con anotaciones en el propio Bean, por lo que habría que mirar el código de la clase LoginView.java para encontrarnos con:

	... 
	@NotNull
	@Size(min = 6, max = 128)
	private String name;

	@NotNull
	@Size(min = 6, max = 128)
	private String password;
	...

Se ve como estamos validando los atributos para que no sean nulos y para que tengan un tamaño entre 6 y 128 caracteres.
Ojo, porque existe una limitación y es que aunque indiquemos el @NotNull, si queremos que JSF 2 nos haga esta validación, tendremos que indicar en el componente el atributo required=”true” como hacíamos con JSF 1.

5.3. Soporte para AJAX

JSF 2 ya viene con soporte para AJAX (este está basado en el soporte proporcionado por RichFaces). De esta forma tenemos una nueva etiqueta f:ajax que pondremos en el componente donde queremos tener comportamiento AJAX; de forma que si la ponemos en un h:commandButton se disparará al pulsar el botón, y si la ponemos en un h:inputText se disparará al cambiar de valor (cuando el input text pierde el foco).
Básicamente lo que vamos ha hacer con esta etiqueta es indicar que otros componentes queremos que se repinten cuando se produzca el evento (al pulsar el botón, al cambiar de valor, ...). Esto lo haremos con el atributo render.
En el ejemplo, en las líneas 16 y 23 se ve como estamos indicando que queremos repintar el componente que presenta los mensajes de error de la validación. Como el f:ajax lo hemos asociado a un h:inputText, lo que va a ocurrir es que cuando este campo de entrada pierda el foco, se lanzará un evento de cambio de valor, se irá al servidor, se hará la validación de bean según el JSR-303, y si se producen errores estos se pintarán en el componente h:message indicado (nótese que con el atributo render de f:ajax se indican los ids de los componentes que se quieren repintar).

5.4. Navegación

Con JSF 2 se simplifica enormemente la navegación. Podemos seguir usando las reglas de navegación en el faces-config.xml, pero JSF 2 añade soporte para “Convención frente a Configuración”.
En la línea 28 vemos como en el h:commandButton, en el atributo action, indicamos una cadena. Esta no es EL, por lo que no estamos haciendo referencia a un backbean. Esta cadena correspondería con el “outcome” que serviría para determinar la regla de navegación a disparar. Pero como no hemos escrito ninguna regla de navegación ¿qué es lo que va ha hacer JSF 2? Sencillo, simplemente se limitará a buscar una página con el mismo nombre y la extensión .xhtml. Es decir, si en nuestro ejemplo hemos puesto action=”listTutorialsView”, JSF 2 intentará saltar a la vista listTutorialsView.xhtml
En el ejemplo la página se buscará a la misma altura, pero podemos indicar rutas relativas. Por ejemplo, si la ruta empieza por / estaremos indicando que es relativa al dominio y nombre de aplicación actual.

6. Creando la página de alta y listado

6.1. listTutorialsView.xhtml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

<html xmlns="http://www.w3.org/1999/xhtml" xmlns:ui="http://java.sun.com/jsf/facelets"
	xmlns:f="http://java.sun.com/jsf/core" xmlns:h="http://java.sun.com/jsf/html">

<ui:composition template="./defaultLayout.xhtml">
	<ui:define name="title">Tutoriales</ui:define>

	<ui:define name="content">
		<h2>Añade un tutorial</h2>
		<h:form>
			<h:panelGrid columns="5">
				<h:outputLabel for="title" value="Título" />
				<h:outputLabel for="publicationDate" value="Fecha de publicación (dd/mm/aaaa)" />
				<h:outputLabel for="category" value="Categoría" />
				<h:outputLabel for="subCategory" value="Sub-categoría" />
				<h:outputLabel for="subsubCategory" value="Sub-sub-categoría" />

				<h:inputText id="title" label="Título" value="#{listTutorialsView.title}" required="true" />
				<h:inputText id="publicationDate" label="Fecha de publicación" value="#{listTutorialsView.publicationDate}" required="true">
					<f:convertDateTime pattern="dd/MM/yyyy" />
				</h:inputText>
				<h:selectOneMenu id="category" label="Categoría" value="#{listTutorialsView.category}" converter="selectItemsConverter">
					<f:selectItems value="#{listTutorialsView.categories}" var="category" itemLabel="#{category.name}" />
					<f:ajax render="subCategory subsubCategory" />
				</h:selectOneMenu>
				<h:selectOneMenu id="subCategory" label="Sub-categoría" value="#{listTutorialsView.subCategory}" converter="selectItemsConverter">
					<f:selectItems value="#{listTutorialsView.subCategories}" var="subCategory" itemLabel="#{subCategory.name}" />
					<f:ajax render="subsubCategory" />
				</h:selectOneMenu>
				<h:selectOneMenu id="subsubCategory" label="Sub-sub-categoría" value="#{listTutorialsView.subsubCategory}" converter="selectItemsConverter">
					<f:selectItems value="#{listTutorialsView.subsubCategories}" var="subsubCategory" itemLabel="#{subsubCategory.name}" />
				</h:selectOneMenu>
			</h:panelGrid>
			<h:commandButton action="#{listTutorialsView.add}" value="Añadir" />
			<h:messages errorClass="error" />
		</h:form>

		<h2>Lista de tutoriales</h2>
		<h:dataTable id="tutorials" value="#{listTutorialsView.tutorials}" var="tutorial" border="1">
			<h:column>
				<f:facet name="header">
					<h:outputText value="Título" />
				</f:facet>
				<h:outputText value="#{tutorial.title}" />
			</h:column>
			<h:column>
				<f:facet name="header">
					<h:outputText value="Categoría" />
				</f:facet>
				<h:outputText value="#{tutorial.category.name}">
				</h:outputText>
			</h:column>
			<h:column>
				<f:facet name="header">
					<h:outputText value="Fecha de publicación" />
				</f:facet>
				<h:outputText value="#{tutorial.publicationDate}">
					<f:convertDateTime dateStyle="full" />
				</h:outputText>
			</h:column>
		</h:dataTable>
	</ui:define>
</ui:composition>
</html>

6.2. Haciendo nuestros propios conversores

En la línea 24 vemos como indicamos un conversor para el h:selectOneMenu con el atributo converter=”selectItemsConverter”. Pero ¿cómo hemos declarado y registrado este conversor? Para contestar a esta pregunta tenemos que ver el código de la clase SelectItemsConverter.java, donde nos encontraremos con:

... 
@FacesConverter("selectItemsConverter")
public class SelectItemsConverter implements Converter {
...

De nuevo JSF 2 nos simplifica la vida, ya que gracias a la anotación @FacesConverter no tenemos que dar de alta el conversor en el fichero de configuración faces-config.xml. El valor de la anotación será el id del conversor, por el cual haremos referencia en el xhtml (línea 24)
Al igual que esta anotación tenemos otras que nos permiten registrar validadores, componentes, ...

6.3. Listas desplegables relacionadas en cascada

No se si os ha pasado alguna vez, pero es bastante común tener listas desplegables relacionadas entre si. Lo típico de selecciono país, selecciono región, selecciono ciudad; o cosas por el estilo. Dentro de que esta situación es bastante común, no era del todo fácil de implementar, y nos podía dar más de un quebradero de cabeza (que si pongo el immediate=”true”, que si cambio los valores de las lisas, ...).
Con JSF 2 estos problemas son historia, y ahora gracias al soporte para AJAX se convierte en algo trivial. En las líneas 26 y 30, podéis ver como volvemos a hacer uso de f:ajax para indicar a JSF que cuando se produzca un evento de cambio de valor en la lista se vaya al servidor y a la vuelta vuelva a repintar las otras listas. En la línea 26 vemos como indicamos dos ids en el atributo render, esto es perfectamente posible, de forma que si queremos repintar más de un componente, basta con indicar la lista de ids separados por un espacio en blanco.

6.4. Ámbito de los BackBeans

Con JSF teníamos los ámbitos de request (el ámbito por defecto), session y application. En JSF 2 tenemos un par más: view y custom (el ámbito custom nos permite definir nuestros propios ciclos de vida para los backbeans).
View es más que request y menos que session. Es decir la primera vez que naveguemos a una vista (a una página) se creará el backbean, y este se mantendrá hasta que saltemos a otra vista por una regla de navegación. Esto quiere decir que todas las peticiones AJAX, o incluso peticiones que no sean AJAX pero que no nos hagan saltar de vista, compartirán la misma instancia del backbean.
Este comportamiento es especialmente indicado para situaciones como la que hemos descrito en el punto 6.3. Si los valores de las listas desplegables están relacionadas, al cambiar el valor de la primera lista, se cambiará el valor de las otras dos. Si el backbean está en request al hacer la siguietne petición hemos perdido el estado, por lo que era causa de bastantes errores, y lo que se solía hacer era guardar el backbean en session. Gracias al ámbito view, ya no es necesario saturar la session de backbeans para solucionar estos problemas.
Para ver como podemos indicar que el backbean es de ámbito view, podemos ver el código de la clase ListTutorialsView.java:

...
@ManagedBean
@ViewScoped
public class ListTutorialsView implements Serializable {

	...

	@ManagedProperty("#{libraryOfAlexandria}")
	private LibraryOfAlexandria libraryOfAlexandria;
	...

En la línea 03 vemos como con la anotación @ViewScoped indicamos que el backbean es de ámbito view. De nuevo no ha hecho falta declarar nada en el faces-confg.xml. Por supuesto tenemos anotaciones similares para el resto de ámbitos.

6.5. Declaración de los backbeans e Inyección de Dependencias

En JSF 1 teníamos que declara los backbeans en el fichero faces-config.xml. En JSF 2, gracias a la anotaciones @ManagedBean, ya no es necesario. Podemos ver un ejemplo de esto en la línea 02 del código del apartado 6.4. Si no indicamos nada en la anotación, el id que se le dará al backbean será el de la clase poniendo la primera letra en minúscula.
Ademas con anotaciones también podemos hacer Inyección de Dependencias. Por ejemplo, en la línea 08 podemos ver como con @ManagedProperty estamos inyectando el resultado del EL "#{libraryOfAlexandria}", esto es, un backbean cuyo id es “libraryOfAlexandria”.
La Inyección de Dependencias de JSF 2 tiene algunos inconvenientes o incomodidades. Por ejemplo, aunque anotamos el atributo de la clase, estamos obligados a tener el método getter y setter.
Y otra cosa más importante es que JSF 2 sólo es capaz de buscar los @ManagedBean que están en el directorio classes de nuestra aplicación web. Es decir, no nos podríamos inyectar un bean que esté dentro de un JAR. Debido a esta limitación la clase LibraryOfAlexandria la hemos metido dentro del proyecto web, pero realmente tendría que estar en el proyecto del modelo, ya que se trata de un servicio de negocio (en otro tutorial ya veremos como solventar esta limitación combinando JSF 2 con Spring).
JSF 2, también admite otras anotaciones como el @PostConstruct. Esta anotación se pone en un método y le indica a JSF 2 que debe llamar a ese método después de crear e inyectar los valores al backbean. Esta anotación es especialmente útil para hacer tareas de inicialización del backbean usando las dependencias que nos inyecta JSF 2.

7. ¿Y dónde está el fichero de configuración faces-config.xml?

Eso es de las mejores cosas que tiene JSF 2, que no hace falta !!!
Con esto no quiero decir que no lo uses, simplemente usarlo cuando os aporte valor, pero en este ejemplo hemos visto como podemos hacer una aplicación perfectamente funcional, con soporte para AJAX, con conversores propios, con navegación, ... sin que exista este fichero.

Usar Managed Bean de presentación desde jsp o servlet

Extraido de http://stackoverflow.com/questions/2633112/jsf-get-managed-bean-by-name

In a Servlet, you can get request scoped beans by:

Bean bean = (Bean) request.getAttribute("beanName");

and session scoped beans by:

Bean bean = (Bean) request.getSession().getAttribute("beanName");

and application scoped beans by:

Bean bean = (Bean) getServletContext().getAttribute("beanName");

If you're running in a dependency injection capable framework/container, it's even more easy:

@Inject
private Bean bean;

Regardless of the scope, when you're actually inside the FacesContext, then normal JSF2 way is using Application#evaluateExpressionGet():

FacesContext context = FacesContext.getCurrentInstance();
Bean bean = (Bean) context.getApplication().evaluateExpressionGet(context, "#{beanName}", Bean.class);

which can be convenienced as follows:

@SuppressWarnings("unchecked")
public static <T> T findBean(String beanName) {
    FacesContext context = FacesContext.getCurrentInstance();
    return (T) context.getApplication().evaluateExpressionGet(context, "#{" + beanName + "}", Object.class);
}

and can be used as follows:

Bean bean = findBean("bean");

However, when you're already inside the FacesContext but not inside a dependency injection capable container, then using @ManagedProperty is cleaner since it's more declarative.

@ManagedProperty(value="#{bean}")
private Bean bean;

Installation of SSL certificate from GoDaddy.com on Oracle Application Server 10.1.3.

Extraido de http://www.dcinformatics.com/home/blog.jsp#090911

Installation of SSL certificate from GoDaddy.com on Oracle Application Server 10.1.3.

Comparing to VeriSign, Comodo, Thawte and other $400+/year SSL certificates, the $12.99 product from GoDaddy.com looks like a very attractive alternative. But the downside is that installation of certificate is not simple at all. These notes might help others to save some time while going through SSL installation and configuration.
My objective was to secure Oracle HTTP server 10.1.3.1.1 with SSL certificate using Oracle Wallet 10.1.0.5.0. My OS is Windows 2003 Server. First I've checked existing default certificate, which comes with the Application Server installation, by connecting to the default Welcome page as http://www.myserver.com/ and simply changing address to https://www.myserver.com/. As expected, the browser complained that I am using certificate provided for testing purpose and should get the real one. The ssl_engine_log file at {ORA_HOME}\Apache\Apache\logs recorded an error:

SSL call to NZ function nzos_Handshake failed with error 28860 
    (server www.myserver.com:443, client xxx.x.xxx.xx)

This is normal response showing that Apache is configured right: it received a request on the port 443, which goes through the ssl engine.
Creating new wallet, new certificate request and signing it at GoDaddy.com was not a problem. I received a zip archive with 2 files in it: www.myserver.com.crt which contained my user certificate, and gd_bundle.crti> with 3 CA certificates. The later is meant to be used for creating certificate chain, making godaddy authority recognized by the server. Import of these two certificates into the wallet produced an error

    User certificate installation failed.
    Possible errors:
    -Input was not a valid certificate
    -No matching certificate request was found
    -CA certificate needed for certificate chain not found
    Please install it first

After struggling against this error for some time I realized that gd_bundle.crt is useless and downloaded chain-building certificates one-by-one from the location: https://certs.godaddy.com/anonymous/repository.seam. The next files are required:

    sfsroot.crt
    valicert_class2_root.crt
    gd_cross_intermediate.crt
    gd_class2_root.crt
    gd_intermediate.crt

I am not sure how critical the order is, but in my case they were ordered as listed above. After that I successfully imported my user certificate

www.mycompany.com.crt

and saved the wallet in {ORA_HOME}/Apache/Apache/conf/ssl.wlt/default
To my surprise, when I restarted the server and tried to connect using https, my FireFox browser gave me an error

    no common encryption algorithm(s)

and IE complained about connectivity like

    Internet connectivity has been lost.

The ssl_engine_log had an error:

    SSL call to NZ function nzos_Handshake failed with error 29040 
    (server www.mycompany.com:443, client xxx.xx.xxx.xx)

The same error always appear when "not ready" certificate was used (certificate which is not successfully signed by CA authority). It took me a while to realize that my certificate is OK, but in addition to start/stop of the AS, I have to close/open Wallet in order to make it working. I am not sure why (maybe because I am using Remote Desktop to connect to the server?), but my updated certificate was not delivered to the browser until I closed Wallet, opened it again and opened-saved the certificate. After that everything was working fine.
I have seen on internet lots of complains about GoDaddy tech support. In my case they were not very instrumental either, but give them a break. What could you expect for $12.99!?

26 de septiembre de 2011

Deploy en openshift

El siguiente video explica como hacer el deploy de una aplicación en jboss 7 openshift

Getting Started with OpenShift Flex and Java EE from JBoss Developer on Vimeo.

20 de septiembre de 2011

jsf expression language

http://developers.sun.com/docs/jscreator/help/2update1/jsp-jsfel/jsf_expression_language_intro.html#syntax

Richfaces demo page

http://livedemo.exadel.com/richfaces-demo/index.jsp

Guia de JPA

http://en.wikibooks.org/wiki/Java_Persistence

19 de septiembre de 2011

Securing jboss aplications

Fuente
http://www.datadisk.co.uk/html_docs/java_app/jboss5/jboss5_securing_web_apps.htm

Security can be compromised in many ways, unauthorized users may access your applications data, someone may intercept a message being transmitted between two users, or crackers may expose vulnerabilities in your network or application server, giving them access to run commands on your O/S.
There are three security related subjects

Authentication
Authorization
Secure Communications

Authentication is the process by which a system verifies the identity of a user, in most cases a user ID and a password is requested, however more sophisticated mechanisms can be used certificates, biometric data, smart cards, physical tokens, etc. If using a password it can be stored in a flat file, database or even LDAP.
Authorization is the process of verifying that a user has sufficient privileges to access an application resource, JBoss uses the common mechanism of roles to archive this, by assigning roles to a user then giving access to resources to the role, the user will be able to access the resource, this is commonly known as role-based authorization.
JBoss Security SX Framework
JBoss uses the JBoss security SX framework, which builds on top of the Java Authentication and Authorization Service (JAAS) which secures all the Java EE technologies running in the application.

A incoming component request is routed to a JBoss SX component called a security domain, an abstraction used to secure all requests made to a component, the security domain performs any necessary checks and notifies the component whether the user can proceed or not. The security domain knows how to use one or more login modules to load security data from a data source. Security domains are configured at the server level and can be used by any component within the server. Security domains are bound into JNDI (see Tomcat JNDI for information on JNDI) when the server starts, JNDI context maps a component to a security domain. This information in in the server/xxx/conf/login-config.xml file.

example of a security domain (login-conf.xml)

<application-policy name="jmx-console">
  <authentication>
    <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
      <module-option name="usersProperties">props/jmx-console-users.properties</module-option>
      <module-option name="rolesProperties">props/jmx-console-roles.properties</module-option>
    </login-module>
  </authentication>
</application-policy>

The above example is the jmx-console login authorization, it starts off defining the security domain name "jmx-console", this name is the one bound into JNDI which would be java:/jaas/jmx-console, all bound security domains start with java:/jaas namespace. One note is that JBoss only bounds the security domain into JNDI after you deploy an application that references the security domain. The login-module points to a login module (Java class), you can point it to more than one if you need to, the module will load security information from a file in this case but can use a database or LDAP. The module-options obviously is used by the login-module to obtain the file names, so check what options your particular module will use.
JBoss SX provides a feature called dynamic login configuration that allows you to define security in your application archive rather than in the server's login-config.xml file. To enable this feature, you have to create and deploy a MBean for the service to the server's server/xxx/deploydirectory. This file can be named anything you like as long as it has the suffix -service.xml, this enables the appropriate JBoss deployer to pick it up and deploy it as a MBean service.

Example MBean dynamic login config

<server>
  <mbean code="org.jboss.security.auth.login.DynamicLoginConfig" name="jboss:service=DynamicLoginConfig">
    <attribute name="AuthConfig">dynamic-login-config.xml</attribute>
    <depends option-attribute-name="LoginConfigService">jboss.security:service=XMLLoginConfig</depends>
    <depends option-attribute-name="SecurityManagerService">jboss.security:service=JaasSecurityManager</depends>
  </mbean>
</server>

Logging Additional Security
By default security logging is minimal, to increase this update the server/xxx/conf/jboss-log4j.xml

increase security logging

<category name="org.jboss.security">
  <priority value="TRACE" class="org.jboss.logging.XLevel"/>
</category>
<category name="org.jboss.web.tomcat.security">
  <priority value="TRACE" class="org.jboss.logging.XLevel"/>
</category>
<category name="org.apache.catalina">
  <priority value="DEBUG"/>
</category>

Note: don't forget to comment out the threshold parameter in the appender that you want the logging messages to appear in.

Secure Communications
When sending data over the wire (network), you should be aware of three aspects of secure communication

Confidentiality - protect a message from being read by others
Data Integrity - make sure the message has not been tampered with
Source Integrity - give assurance to the recipient that the message has been sent by the sender he/she thinks he/she is communicating with

To ensure confidentiality the sender often encrypts the message and the recipient decrypts the message, encrypted communication protocols ensure data integrity (use SSL and TLS protocols) and source integrity can be protected by using a reliable third party that assigns certificates to different people and organizations.
There are two types of encryption

symmetric

This is like a user having a secret message that he/she puts into a box and secures it with a padlock, if your friend has the same key to the padlock you can both open and close it knowing no else can.
Symmetric works in the same manor by using a secret key, a message is encrypted with a secret key and decrypted with the same key, as long as the key is not comprised the two parties can communicate securely.

asymmetric

Public key encryption (asymmetric encryption) uses a pair of mathematically associated keys, after a message is encrypted with one, it can only be decrypted with the other. The keys are called public and private, the public you can give to anyone and the private you keep yourself, only the private key can decrypt messages encrypted by the public key. What this means is that you can freely distribute the public to anyone, the only drawback is that this mechanism is slower.

To ensure that the encrypted message you receive from the sender is actually the sender you think you are communicating with, you use apublic key certificate which is a digital certificate that consists of some information about the certificate holders identity and a public key. To verify that the public key belongs to the user whose identity is on the certificate, a CA (Certificate Authority) signs the certificate. There are a number of public CA's that charge for public key certificates, VeriSign, Thawte and Entrust.
To get a signed certificate, you first generate a self-signed certificate and use it to create a Certificate Signing Request (CSR). The CSR and a few hundred bucks is then sent to the CA who validates your identity and then sends back a signed certificate. You can also create your own self-signed certificates which is a good idea when using them internally.
To create your own certificates the JVM comes with a tool called keytool, this tool can be used for the following

Generating and storing self-signed public/private key pairs
Generating CSRs
Importing public certificates that you have had signed by a CA
Importing public certificates for some other party that you trust

Generate a keystore and self-signed certificate	keytool -genkey -alias "selfsigned" -keyalg RSA -keystore keystore.pfv -storepass "password123" -validity 360
Generate a keystore and Export the CSR file to get signed then Import the signed-cert from the CA	keytool -genkey -alias mydomain -keyalg RSA -keystore keystore.pfv keytool -certreq -alias mydomain -keystore keystore.pfv -file getMeSigned.csr keytool -import -trustcacerts -alias mydomain -keystore keystore.pfv -file signedCertificate.crt
Export the certficate from the keystore to distribute it	keytool -export -alias mydomain -keystore keystore.pfv -file mydomain.crt
Print keystore information	keytool -list -v -keystore keystore.pfv keytool -list -v -keystore keystore.pfv -alias mydomain

The JVM comes with a keystore that has many public key certificates, this type of keystore is a truststore, if you need to import any certificates in to the truststore use the below command

importing into the trust store	keytool -import -alias myserver -file server.csr -keystore C:\jdk1.6.0_12\jre\lib\secruity\cacerts
specify on the commandline	java -Djavax.net.ssl.trustStore=<file> -Djavax.net.ssl.trustStorePassword=<pass>

When using secure communications the server has to have a certificate, but the client does not. You can authenticate the client if required to do so although this is uncommon (normally use login/password authentication to identify the client) , this is called mutual authentication.

Authentication Strategy	Who wants to verify the other party's identity	Who needs public key?
Server Authentication	Client	Server
Mutual Authentication	Client and Server	Client and Server

Configuring an SSL-aware security domain
It is very simple to setup SSL through the HTTP connector, you cannot setup an SSL-aware security domain in the login-config.xml file, you must define an MBean instance of Jaas SecurityDomain that points to a truststore.

Create a file (see below example) that ends with -service.xml and place it in the server/xxx/deploy directory

Example SSL-aware security domain defined MBean

<server>
  <mbean code="org.jboss.security.plugins.JaasSecurityDomain" name="jboss.security:service=MySecurityDomain">
    <constructor>
      <arg type="java.lang.String" value="my-security-domain"/>
    </constructor>
    <attribute name="KeyStoreURL">${jboss.server.home.dir}/conf/server.truststore</attribute>
    <attribute name="KeyStorePass">servercert</attribute>
    <depends>jboss.security:service=JassSecurityManager</depends>
  </mbean>
</server>

Note: this will now bind to JNDI as java:/jaas/my-security-domain

If you want your security domain to do authentication and authorization as well, you still need to define a security domain in your login-config.xml file

<application-policy name="my-security-domain">
  ...
</application-policy>

Configuring Login Modules
A JBoss SX login module knows how to access a security data source in order to load a users password and role information. Login modules are configured with security domains, each security domain can have one or more login modules, they are configured in the login-config.xmlfile.

Login Module	Description
BaseCertLoginModule	Authenticates client certificates, must be stacked with another login module that does authorization
CertRolesLoginModule	An extension of BaseCertLoginModule that authenticates against client certificates and authorizes against properties files
ClientLoginModules	Used by standalone clients that want to log into a secure server
DatabaseCertLoginModule	An extension of BaseCertLoginModule that authenticates against client certificates and authorizes against a database
DatabaseServerLoginModule	Loads user/role information from a database
IndentityLoginModule	a testing login module that causes all users to authenticate with the same credentials
LdapExtLoginModule	Loads user/roles information from a LDAP server (supports hierarchical role structure)
ldapLoginModule	Loads user/roles information from a LDAP server (only works with flat role structures)
RunASLoginModule	Can be stacked with another login module to define the run-as status that they use while they're authenticating, useful if you need to call a secured EJB that's responsible for authenticating users.
SimpleServerLoginModule	A testing login module that allows any role with a null password to authenticate
SRPCacheLoginModule	Used to authenticate users using the Secure Remote Password (SRP) protocol
SRPLoginModule	Used by standalone clients that want to authenticate using the SRP protocol
UsersRolesLoginModule	Loads user/roles information from property files

I have supplied a couple of examples of the most commonly used ones, but you can use any of the login modules, don't forget to lookup the options that are available for each module.

UserRolesLoginModule

<application-policy name="my-security-domain">
  <authentication>
    <login-module code="org.jboss.security.auth.spi.UsersRolesLoginModule" flag="required">
      <module-option name="usersProperties">my-users.properties</module-option>
      <module-option name="rolesProperties">my-roles.properties</module-option>
    </login-module>
  </authentication>
</application-policy>

# my-user.properies file
pvalle=password
willhay=password1
normanwisdom=password2

# my-role.properies file
pvalle=admin,movies
willhay=movies
normanwisdom=movies 

DatabaseServerLoginModule

<application-policy name="database-domain">
  <authentication>
    <login-module code="org.jboss.security.auth.spi.DatabaseServerLoginModule" flag="required">
      <module-option name="dsJndiName">java:/OracleDS</module-option>
      <module-option name="principalsQuery">select passwd from users where userid=?</module-option>
      <module-option name="rolesQuery">select roleid, 'Roles' from roles where userid=?</module-option>
    </login-module>
  </authentication>
</application-policy>

17 de agosto de 2011

Eclipse Cambiar tipo de letra

WINDOW->PREFERENCES

Y en el arbol:

GENERAL->APPEARANCE->COLORS AND FONTS

dentro de la rama BASIC, la última opcion es Text Font, que es la fuente del editor de texto normal. Pulsas el botón Change y pones la fuente que quieras.

13 de junio de 2011

Dividir Faces Config

Para añadir un segundo fichero config deberemos añadir las siguientes líneas al fichero web.xml.

<context-param>
<param-name>javax.faces.CONFIG_FILES </param-name>
<param-value>/WEB-INF/faces-config.xml, /WEB-INF/tiles-defs.xml</param-value>
</context-param>

26 de abril de 2011

Diseño Modelado con Seam

Cuando se arma el modelo de las entities en seam, la visibilidad elegida define la navegación generada por el seam-gen.

Tanto para la visibilidad ManyToOne o ManyToMany en las pantallas crea tabs para contemplar esta visibilidad.

Por lo tanto una regla a la hora de elegir la visibilidad del modelo, sería identificar las entities que son más relevantes ( aquellas que llevan ABM ) y que sean ellas quienes tengan visibilidad sobre el resto.

25 de abril de 2011

SEAM page error "duplicate Id for a component selectParent"

Yes, it is a bug. Quick solution:look at seam-home/seam-gen/view/edit.page.xml.ftl

and change the following line:

<s:button id="${'#'}{${homeName}.instance.${property.name} != null ? 'changeParent' : 'selectParent'}" value="${'#'}{${homeName}.instance.${property.name} != null ? 'Change' : 'Select'} ${property.name}"

for:

<s:button id="${'#'}{${homeName}.instance.${property.name} != null ? 'changeParent${property.name}' : 'selectParent${property.name}'}" value="${'#'}{${homeName}.instance.${property.name} != null ? 'Change' : 'Select'} ${property.name}"

Enjoy!!!

extraido de http://seamframework.org/Community/PageErrorDuplicateIdForAComponentSelectParent#comment84431

Esto soluciona el bug del generador de seam

en mi caso debí cambiar la página

Esto

<s:button id="#{beneficiarioHome.instance.direccionContacto != null ? 'changeParent ' : 'selectParent '}"

value="#{beneficiarioHome.instance.direccionContacto != null ? 'Change' : 'Select'} direccionContacto"

view="/DireccionContactoList.xhtml">

<f:param name="from" value="BeneficiarioEdit"/>

</s:button>

por esto:

<s:button id="#{beneficiarioHome.instance.direccionContacto != null ? 'changeParentdireccionContacto ' : 'selectParentdireccionContacto '}"

value="#{beneficiarioHome.instance.direccionContacto != null ? 'Change' : 'Select'} direccionContacto"

view="/DireccionContactoList.xhtml">

<f:param name="from" value="BeneficiarioEdit"/>

</s:button>

Y ESO TAMPOCO ANDUVO ASÍ QUE LE SAQUE EL id="#{bla bla}"

12 de abril de 2011

Jboss 5.1 eclipse Jboss tools y proyecto Seam vs netbeans jboss 4.2 y EJB+JSF

Utilizar seam reduce los tiempos de desarrollo ?

En la experiencia personal trabajando con jboss 5.1 o 4.2 y eclipse con jbossTools se tienen muchos problemas técnicos que nada tienen que ver con programación a tal punto que se pierde más tiempo arreglando estos problemas que desarrollando en sí.

Ventajas Seam:

mejora el pasaje de parámetros a las páginas
mejora la sintaxis de navegación de páginas
separa las navegaciones por página para tener las cosas más ordenadas
Prácticamente no se utilizan converters
Mejora la interacción con logger
Evita el código replicado que se ocasiona al trabajar en capas separadas
Provee anotaciones para

Trabajo con Roles de usuario
Biyección
Insertar métodos que se disparan durante el ciclo de vida
Demarcación de contextos Begin y End
Demarcación de transacciones Rollback
Para Manejo de excepciones redirect y HttpError
Validación IfInvalid
Remoting
Seam interceptors
Asincronismo
Jsf DataTable selección automática ( sin converters ni cosas raras )

8 de abril de 2011

Net beans seam glassfish

Probando un nuevo entorno de desarrollo

http://www.coffeecrew.org/files/2010/10/netbeansFaceletsSeamEjb3.pdf

http://blogs.sun.com/arungupta/entry/java_ee_6_glassfish_31

El plugin para que netbeans soporte seam ya no está disponible.

igual seam deja levantar el proyecto
http://www.adictosaltrabajo.com/tutoriales/tutoriales.php?pagina=JBossSeam_primeros_pasos#03

1 de abril de 2011

Seam Error: entity not mapped jboss tools

query syntax exception not mapped

El Bug esta reportado aca https://issues.jboss.org/browse/JBSEAM-3821

Solución cambiar el persistence.xml y el components.xml de la siguiente forma

--components.xml
<persistence:entity-manager-factory name="bookingDatabase" installed="false"/>

<persistence:managed-persistence-context name="em" auto-create="true"
entity-manager-factory="#{bookingDatabase}" persistence-unit-jndi-name="java:/bookingEntityManagerFactory"/>

--persistence.xml

<property name="jboss.entity.manager.factory.jndi.name" value="java:/bookingEntityManagerFactory"/>

11 de marzo de 2011

java.lang.IllegalStateException: Application was not properly initialized at startup, could not find Factory: javax.faces.context.FacesContextFactory

Causa: no se encuentran los jar de jsf en el build path
No Solución: configure build path , add jar seleccionar jsf-api y jsf-impl
No Solución: copilar los jar api e impl a web-inf/lib
Causa: Problema del hot deploy de tomcat
Solución: Agregar en el web.xml

<listener>
<listener-class>com.sun.faces.config.ConfigureListener</listener-class>
</listener>

<listener>
<listener-class>com.sun.faces.application.WebappLifecycleListener</listener-class>
</listener>

3 de marzo de 2011

Piques JBoss

Consola de administración

http://localhost:8080/admin-console/
Default user password
admin / admin

Tiene la sección de aplicaciones y otra de recursos los cuales son utilizados por las aplicaciones

se puede controlar el deploy de las aplicaciones

Levantar jboss por fuera de eclipse para que es escuche desde fuera de la lan.
cd c:\jboss-5.1.0.GA\bin
run -b 0.0.0.0

Cuando copiamos a deploy se realiza el deploy automatico. para evitar esto modificamos la entrada de /conf/jboss-service.xml al final de todo
<attribute name="ScanEnabled">true</attribute> lo cambiamos a false, reiniciamos y listo

Servicios Web
http://localhost:8080/jbossws/services

para generar el proxy del web service y que incluya el codigo fuente ( los .java )
jboss-4.2.2.GA/bin/wsconsume -k http://cosa.com/archivo.xsdl

9 de febrero de 2011

Tildes y ñ en eclipse seam jsf

Uno de los problemas que me he encontrado al realizar páginas web es que
aunque en mi template.xhtml tengo <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
los tildes o ñ provocaban un error (invalid utf-8 character) al visitar la página.
El problema era sencillo el archivo .xhtml no estaba codificado en utf-8 porque eclipse en windows por defecto usa cp1252
para cambiarlo
windows > Preferences > General > Workspace > text file encoding

Problema resuelto!