TechJava» TechJava – Articles on enterprise systems

JSF 2.0 Reality Check

Simon Zambrovski — Mon, 22 Feb 2010 21:50:42 +0000

Abstract

The JavaServer Faces (JSF) 2.0 is the newest Java presentation technology that is covered in JSR-314 and was publicly released on July 01, 2009. It became a part of the JEE6 standard and can be comfortably used in conjunction with other JEE frameworks, with Spring or just on its own. This article reveals the possible scenarios and shows the required configuration for the usage of JSF 2.0 with EJB 3.1 and with Spring 3.0. It also discusses several auxilary technologies which can be used along with JSF 2.0.

Management Summary

There are many presentation frameworks available, so why JSF 2.0? The short answer is simple: it has an extensible component-oriented presentation layer and event-driven programming model, which both abstract from HTML/JS and leverage the developement. In more detail, the most important features are:

Facelet Support
Validation & Conversion Mechanisms
Resources Support
Templating
Expression Language
Annotation Support

JSF 2.0 makes strong use of the SoC (Separation of Concerns) principle, promoting the MVC (Model View Controller) design pattern. Its declarative view is based on facelets: the view documents can be defined using XHTML. These documents build their own component tree from the core or third-party components. The use of special composition elements allows effective templating. The model or/and the controller are realized using so called backing beans / managed beans. A backing bean is an annotated POJO (Plain Old Java Object). The access from the view to the backing beans is possible using the expression language. The navigation can be influenced directly from the view or from the backing beans, by pointing to the logical names of the pages. JSF offers a flexible validation model, which suports Bean Validation (JSR 303) out of the box.

Presentation with JSF 2.0

This chapter discusses the model of the presentation used in JSF 2.0.

Initial setup

A JSF project is an ordinary Java Web project. The result of it runs inside of a web container, like Tomcat or Jetty. A characteristical descriptor has to contain the servlet definitions/mappings of the JSF servlet and third-party component servlets. Here is an exammple for JSF 2.0 and Prime Faces, an open-source component library.


...
	
	
		com.sun.faces.expressionFactory
		com.sun.el.ExpressionFactoryImpl
	

	
	
		Faces Servlet
		javax.faces.webapp.FacesServlet
		1
	
	
	
		Resource Servlet
		org.primefaces.resource.ResourceServlet
		1
	
	
	
		Faces Servlet
		*.jsf
	
	
	
		Resource Servlet
		/primefaces_resource/*
	
...

The View

The definition of a JSF presentation is relatevely simple. Just create a simple XHTML document and import the JSF namespaces in the header.


	 
	 
		 #{msgs.welcomeTitle}
		 
	 
	 
		 
			 
				 
			 
			...

Please note, that along with the JSF core components, the PrimeFaces component dataTable is used. At runtime the components will be transformed into the corresponding HTML elements.

The Backing Bean

In the previos example, special strings have been used #{customerProvider.customers} and #{customer.name}. Both of them are expressions specified in the Expression Language. This language allows to address elements known inside the application. The customer.name accesses the property name of the variable defined inside the iteration over the elements delivered from the customerProvider.getCustomers(). The customerProvider is a Java Object that delivers data to the view and is called Backing Bean. A Backing Bean is a serializeable POJO, that is attached to the view. It can be declared using JSF Annotation javax.faces.ManagedBean, using the ManagedBean element of the faces-config.xml or by other mechanisms compatible with the Expression Language resolvers.

@ManagedBean
@SessionScope
public class CustomerProvider
{
	public List  getCustomers()
	{
		...
	}
}

Internationalization

Internationalization is an important requirement for the presentation layer. In the previous example, a special string has been used #{msgs.welcomeTitle} to provide a message. The msgs variable is bound to a resource file, containing the localized messages, so the #{msgs.welcomeTitle} is pointing to the key welcomeTitle inside the property file.

Validation

Input validation is another important requirement for web applications. Especially, the ability to validate parts of the input using technologies like AJAX has to be supported in order to deliver the state-of-the-art technology. JSF fosters numerous different validation approaches. For example:

...
 
	 
 
 
...

Please note, that in the example above, the input of the customer name is mandatory and the minimum length is seven.

Another validation approach is defined in the Bean Validation Standard (JSR 303) and is supported if the components are deployed and available. According to JSR 303, the data container can define format constraints which can be used for purposes of validation. There is a set of predefined constraints available, which can be extended by custom constraints. For example:

public class Customer
{
	@Size(min=2, max=50, message= "Customer name must be at least 2 and at most 50 characters long. ")
	private String name;
	// getters and setters
	...
}

This example shows that the customer name has to be at least two and at most fifty characters long and defines a custom error message which is displayed on violation. Remember the previous section Internationalization? Yes, the validation error message can be localized too, by suppliying EL-expressions instead of the message description:

public class Customer
{
	@Size(min=2, max=50, message= "{customerNameError} ")
	private String name;
	// getters and setters
	...
}

Thus, the value of {customerNameError} (without a #) is a key in the file which must be named ValidationMessages.properties and must be available on classpath.

JSF 2.0 with other frameworks

The use of JSF fosters comfort in implementing the presentation tier. The presentation-tier is usually built on top of the business logic layer. The latter can be implemented using different technolgies.

JSF 2.0 and EJB 3.1

Enterprise Java Beans is a standard way to implement business logic inside JEE applications. The current EJB 3.1 specification fosters the usage of Stateless and Statefull Session Beans for this purpose. Since JEE6-compliant servers support Context and Dependency Injection (CDI) and the EJB and Resource Injection, the session beans can be directly referenced from the backing beans. JSF 2.0 is also a part of the JEE 6, every JEE-compliant server will support JSF out-of-the-box, too.

@ManagedBean
public class CustomerProvider
{
	@EJB
	private CustomerService service;
	...
}

JSF 2.0 and Spring 3.0

If you don’t want to run a full-blown JEE server, but a web-container only, you have to include some libraries into your application deployment.

JSF 2.0 API and Implementation: e.g. Mojarra 2.0.2 ( mojarra-2.0.2-FCS-binary.zip)
Expression Language 2.2 API and Implementation: el-api-2.2.jar, el-impl-2.2.jar
Content and Dependency Injection (CDI, JSR 330) API and Implementation: javax.inject.zip
Bean Validation (JSR 303) API and Implementation: e.g. Hibernate Validator ( hibernate-validator-4.0.2.GA-dist.zip)

This list will be extended by libraries required to run the Spring framework. In order to activate Spring, the context listeners have to be activated. The application context parameter can be provided as a context parameter.

 
 
	 org.springframework.web.context.ContextLoaderListener
 
 
	 org.springframework.web.context.request.RequestContextListener
 
 
	 contextConfigLocation
	 /WEB-INF/spring-config.xml

In addition, the Expression Language variable resolvers of JSF should be replaced by those from Spring. This is configured in the faces-config.xml


	
		org.springframework.web.jsf.el.SpringBeanFacesELResolver

In order to enable the Spring’s IoC (Inversion of Control), we need to activate the component scan in the application-context configuration file:

Instead of using JSF for resolving the backing beans, the Spring framework can be used. The backing bean is annotated with the Spring annotation Controller. The controller is a special kind of Spring component, which is used in the presentation layer. The Spring’s way of implementing business logic is to provide Spring services. Spring service has to be annotated with Service annotation.

@Controller
@Scope( "session ")
public class CustomerProvider implements Serializable
{
	@Inject
	private CustomerService customerService;
	...
}

@Service
@Scope( "singleton ")
public class CustomerServiceImpl implements CustomerService
{
	...
}

This is not as elegant as inside the JEE server, but it will work.

References

Launching Eclipse RCP via Java Web Start

Simon Zambrovski — Wed, 03 Feb 2010 16:32:15 +0000

The Eclipse RCP became a prominent platform for building client software. One of the delivery mechanisms supported by Eclipse RCP is Sun’s Java Web Start (JWS). Since Galileo Edition some changes has been introduced in the platform. This article provides some hints for creation of the RCP delivered by Java Web Start.

Packaging

In order to package the RCP I suggest to use feature-based products as described in a previous article. Following it, you should have a top-level plug-in (also refered as product-defining plug-in) and top-level feature, which is called “wrap”-feature in the context of the Java Web Start.

Exporting the product

Before you start with Java Web Start (JWS), export the product and make sure it starts as a standalone application. In doing so, you have to ensure that your references to the plug-ins are correct. One of the way of doing it is to hit the Validate button in the top left of the product editor. If the validation is successful, try to export the product. The PDE builder will run and create a distribution. The errors of the compiler/builder/assembler, if any, are reported to files zipped to the logs.zip file in the distribution directory. A prominent error is

Compliance level '1.3' is incompatible with source level '1.6'. A compliance level '1.6' or better is required.

Which actually means that the plug-in classes has not been compiled at all. In order to avoid this error make sure to set the following properties in the build.properties file of the corresponding plug-in:

javacSource=1.3
javacTarget=1.3

Exporting the wrap-feature

After a successful export of the product, just export the top-level feature (the wrap-feature). Make sure to provide the signing information, since JWS requires all resources to be signed. If you are aiming to deliver for different platforms, make sure to define a target platform (Window > Preferences > Plug-in Development > Target Platform) which contains a Delta Pack. A Delta Pack is a set of plug-ins which can be downloaded separately on the Eclipse Homepage. Also, don’t forget to switch over to the Java Web Start tab of the Feature Export Wizard, activate the checkbox “Create JNLP manifest for the JAR archives” and specify the site URL where the resulting JNLP will be located. Make sure all your features has the provider attribute set, since it is used as the “vendor” inside of the JNLP file, which is a mandatory attribute.

Creating the main JNLP

The PDE build will run and create a distribution in the specified directory. Along with the exported JARs in features and plug-ins, the packaging script will generate the JNLP descriptors for every feature. Still, the main JNLP file required for launching the application is missing and has to be provided separately. Here is, how it looks like:



    
        application titel
        provider
        
    

    
        
    

    
	-product
	de.techjava.app.webstart.productid
	-application
	de.techjava.app.webstart.appid

Important is to specify both, the product id and the applciation id, otherwise you will see the “Application id not found” exception. Of course you can specify additional options as command-line arguments of the launcher itself. I found it useful to be able to let the OSGi running and then connect to it and query for loaded bundles. You can do it by adding the following arguments:

	-console
	1234
	-noExit

This will allow to connect via telnet with running OSGi, even after the application finishes.
This is basically it.

Real World Java EE Practices – Rethinking Best Practices by Adam Bien

Simon Zambrovski — Tue, 02 Feb 2010 23:21:43 +0000

I just returned from the furious event given by Adam Bien on Real World Java EE Practices. The presentation has been held in Lehmanns Bookstore in Hamburg in co-operation with the JUGHH. It was a full success with no space left in the bookstore. I think, I got the last seat and there were some people standing.

Adam made it in an hour and presented many interesting topics. He started with new subjects introduces in JEE6, like optional local interfaces, cronjob-like Timer Service and other nice goodies. Then he covered new stuff from JEE like REST and CDI (Context and Dependency Injection). Finally, he moved to the best practices, patterns and anti-pattern. As usual, it was quick and precise – Adam answered many questions and gave a good overview of the technology.

After the presentation, JUGHH / Lehmanns offer a glass of sparkling wine for the smaller audience and Adam spoke about the possibility to speak about JavaFX next time. This time I left my camera at home and only had my phone with me, so sorry for the low-resolutioned picture…

Exposing Functionality using Web Services and JEE

Simon Zambrovski — Thu, 07 Jan 2010 11:11:22 +0000

Abstract

About two years ago, I published an article about Exposing the Functionality implemented in Stateless Session Beans (EJB 2.1) using Web Services. J2EE 1.4 times are over and the new version of the Java Enterprise framework, called Java Enterprise Edition 5 (JavaEE 5, or simply JEE) has emerged. In this article the same business scenario is repeated in the new framework.

Requirements

Before we dive into code examples, some software is required. The good news about the software is, that it also evolved over time. Here is what we use:

Sun’s Java 6 SDK
JBoss AS 5.1.0 GA for JDK6
Eclipse Galileo 3.5.1 for JEE development

Some words about the used software. It is important to get the JDK6-compiled version of the JBoss Application Server. There are some issues with running the version compiled with Java 5 on JDK6, since JDK6 has its own JAX-WS implementation which causes problems with JBoss (affected should be all versions of JBoss < 5.2. Currently it seems like version 5.2 will be compiled with JDK6 by default.) If you launch JBoss from Eclipse, make sure to add the -Djava.endorsed.dirs=PATH_TO_JBOSS/jboss-5.1.0.GA/lib/endorsed as a VM argument, if launched from the command line, please add it as an option inside of the run.conf.bat file:

set "JAVA_OPTS=%JAVA_OPTS% -Djava.endorsed.dirs=$JBOSS_HOME/lib/endorsed"

Otherwise you will get the following exception:

java.lang.UnsupportedOperationException: setProperty must be overridden by all subclasses of SOAPMessage

After installation (unpacking) of Eclipse, make sure to configure the JDK (under Preferences > Java > Installed JREs) and the JBoss instance (Preferences > Server > Runtime Environment).

Use Case

In order to demonstrate the technology by example, imagine the following use case. The system under construction is capable of providing measurements of some sensors. The sensors are identified by numbers and can be queried by the user by providing the timespan of measurements. As a result, the systems delivers the set of measurements for the given timespan with one measurement per minute but at most sixty measurements. Every measurement contains the id of sensor from which it has been recorded, the timestamp, the value as a byte array, the measurement unit and finally a flag whether the measurement exceeds the limits or specified alarm values.

Implementation

We start the implementation with the creation of a JEE Session Bean and then expose the functionality using a second Facade bean. In doing so we follow the EJB 3 specification.

Eclipse for Java EE development

The plugins in Eclipse for Java EE provide massive support and foster the development by deep integration withe JEE servers. Instead of a simple Java Project, start with an Enterprise Application Project. Then, create a new EJB Project and add it to the created Enterprise Application Project. In order to deploy the resulting application to the server, right-click on the enterprise project and select Run As > Run on Server .

To check the deployment on the application server, use the JBoss Consoles. These can be accessed via http://localhost:8080/ for the locally installed JBoss. An additional Web Service Console is accessible via http://localhost:8080/jbossws/.

Implementing the Functionality

In order to implement the functionality in a stateless session bean, we start with the creation of the business interface.

/**
 * Defines the sensor manager functionality
 */
public interface SensorManager
{
	/**
	 * Retrieve sensor data
	 * @param sensorId id of the sensor
	 * @param timespan the measurement period
	 * @return a list of measurements in the given period
	 * @throws SensorManagerException on any kinds of errors
	 */
	public List getSensorData(SensorID sensorId, Timespan timespan) throws SensorManagerException;
}

The POJOs Measurement, SensorID and Timespan are used to show the usage of custom user types:

public class Measurement
{
	private SensorID sensorID;
	private Date timestamp;
	private boolean critical;
	private byte[] value;
	private String unit;
...
// getters and setters
}
....
public class SensorID
{
	private long sensorId;
...
// getters and setters
}

public class Timespan
{
	private Date start;
	private Date end;
...
// getters and setters
}

After the creation of the business interface, let us create the actual Session Bean. The class is annotated with the @javax.ejb.Stateless annotation in order to indicate that the bean is a Stateless Session Bean. Since it implements the business interface (and only it), the container will be able to deduce that the given interface is the Local Business interface: this is just one of many examples of the Configurations by Exception in EJB 3. In order to be able to reference the bean from other beans, we annotate the binding of the local interface to a specific JNDI name using the vendor-specific annotation org.jboss.ejb3.LocalBinding.

@Stateless
@LocalBinding(jndiBinding="de.techjava.sensor/SensorManager")
public class SensorManagerBean implements SensorManager
{
	/** Logging facility */
	protected static Logger LOG = Logger.getLogger(SensorManagerBean.class);
	/** Max number of returned values */
	private static final long MAX_DURATION = 60;

	/**
	 * Implementation of the business method
	 */
	public List getSensorData(SensorID sensorId, Timespan timespan) throws SensorManagerException
	{
		LOG.debug("Entering getSensorData()");
		if (sensorId == null || timespan == null || timespan.getStart() == null || timespan.getStart() == null)
		{
			throw new SensorManagerException("Missing a mandatory parameter, that was null (not set)");
		} else if (!timespan.getStart().before(timespan.getEnd()))
		{
			throw new SensorManagerException("The timespan is defined by the start that should be before end");
		}

		List measurements = new LinkedList();
		for (long i = 0; i < getNumberOfElements(timespan); i++)
		{
			Date date = new Date();
			date.setTime(timespan.getStart().getTime() + i * 1000 * 60);
			if (date.after(timespan.getEnd()))
				break;
			Measurement measurement = createMeasurement(sensorId, date, i);
			measurements.add(measurement);
		}

		LOG.debug("Leaving getSensorData(). Returning " + measurements.size() + " values.");
		return measurements;
	}

	/**
	 * Retrieves the number of measurements in timespan
	 */
	private long getNumberOfElements(Timespan timespan) { ... }

	/**
	 * Creates a measurement instance, a dummy implementation
	 */
	private Measurement createMeasurement(SensorID sensorId, Date timestamp, long number) { ... }
}

Web Service Definition

The quality of the web service interface is an important design consideration. As described in the previous post, in many cases it is a good idea to create it by hand instead of generation by a tool. In this particular case, we create another annotated Stateless Session Bean, which is used as a Facade and contains all Web Service-specific settings. From this Bean we generate the WSDL and then tune it in order to show the capability of the customization. In doing so we try to match the WSDL from the previous example as close as possible.

Firstly, we create the business interface and the bean class, then annotate it and finally add the code delegating the Web Service request to the SensorManager.

public interface MeasurementProviderFacade
{
	public List getSensorData(SensorID id, Timespan timespan) throws SensorDataOperationFault;
}

...

@Stateless
public class MeasurementProviderFacadeBean implements MeasurementProviderFacade
{
	public List getSensorData(SensorID id, Timespan timespan) throws SensorDataOperationFault
	{
	...
	// implementation code
	}
}

In order to have a Session Bean exposed as a Web Service, the JAX-WS specification defines a set of annotations. The most important two are @javax.jws.WebMethod and @javax.jws.WebService. The @WebService annotation is used to mark the class to be exposed e.G.

@Stateless
@WebService(
	serviceName = "MeasurementProviderService",
	name = "MeasurementProviderPortType",
	portName = "MeasurementProviderPort",
	targetNamespace = "http://www.techjava.de/2010/ws4jee/measurement/"
)
public class MeasurementProviderFacadeBean implements MeasurementProviderFacade
{
	@WebMethod(
		operationName="GetSensorDataOperation",
		action="http://www.techjava.de/2010/ws4jee/measurement/GetSensorDataOperation"
	)
	public List getSensorData(SensorID id, Timespan timespan) throws SensorDataOperationFault { ... }
}

All the attributes of the annotation are optional and their values will be derived from the classname and the name of the business interface. The default target namespace for the service definition is derived from the package name, the annotated class is located in. By default, all public methods of the annotated class will be exposed as WSDL operations, with operation’s name derived from the method name. Using the @WebMethod annotation, the name of the WSDL operation and the SOAP action can be changed.

The careful reader might have observed that the getSensorData-method is throwing an exception. In order to map the exception to a SOAP-Fault, the javax.xml.ws.WebFault class-level annotation can be used. The faultBean attribute is used to provide the full-qulified class name of the exception.

...
@WebFault(
	name="GetSensorDataFault",
	targetNamespace="http://www.techjava.de/2010/ws4jee/measurement/",
	faultBean="de.techjava.sensor.bean.SensorDataOperationFault")
public class MeasurementProviderFacadeBean implements MeasurementProviderFacade { ... }

In order to increase the quality of the WSDL further, the method parameters and return type can be annotated with javax.jws.WebParam and javax.jws.WebResult respectively, so the method signature becomes a little unreadable. In order not to copy the long string containing the taget namespace a String constant can be used.

...
	public final static String TYPES = "http://www.techjava.de/2010/ws4jee/measurement/types/";
...
	@WebResult(name="measurement", targetNamespace=TYPES)
	public List getSensorData(
		@WebParam(name="sensor-id", targetNamespace=TYPES) SensorID id,
		@WebParam(name="timespan", targetNamespace=TYPES) Timespan timespan) throws SensorDataOperationFault	{ ... }

Finally, in order to force the marshaller / unmarshaller to map the custom data types (Measurement, SensorID and Timespan) to belong to the same namespace, the JAX-B class-level annotation javax.xml.bind.annotation.XmlType has to be used. By default, the datatypes will be mapped to XML Schema types according to their package name and class name.

@XmlType(namespace = "http://www.techjava.de/2010/ws4jee/measurement/types/", name = "TimeSpan", propOrder = { "start", "end" })
public class Timespan
{
	private Date start;
	private Date end;

If deployed to the JBoss, the resulting WSDL looks as following:

Please note, that the domain datatypes are mapped to the different namespace as the target namespace of the Web Service.

After some tuning the WSDL, like changing the cardinality of elements (minOccurs = 1, maxOccurs = 1) or adding comments we can let the container use the changed WSDL file instead of generating a new one. In order to do this, let us package the WSDL together with the source code. A good place for it is for example /META-INF/wsdl/, so we can provide a reference to it in an wsdlLocationattribute of the @WebService annotation:

@WebService(
...
        wsdlLocation="META-INF/wsdl/MeasurementProviderService.wsdl"
)

Putting all together

After the creation of the Facade Bean and its exposure as a Web Service, we need to delegate the call to the SensorManagerBean, providing the actual implementation. In order to do so, add a private member of type SensorManager inside of the facade bean and annotate it with the javax.ejb.EJB annotation. The container will intialize the member using Dependency Injection and provide a valid reference which can be simply used inside of the method.

...
public class MeasurementProviderFacadeBean implements MeasurementProviderFacade
{
	@EJB(mappedName="de.techjava.sensor/SensorManager")
	private SensorManager sensorManager;

	/**
	 * Simple delegate to the business method of the sensor manager
	 */
	@WebMethod(
			operationName="GetSensorDataOperation",
			action=TNS + "/GetSensorDataOperation"
	)
	public @WebResult(name="measurement", targetNamespace=TYPES) List getSensorData(
			@WebParam(name="sensor-id", targetNamespace=TYPES) SensorID id,
			@WebParam(name="timespan", targetNamespace=TYPES) Timespan timespan) throws SensorDataOperationFault
	{
		try
		{
			return sensorManager.getSensorData(id, timespan);
		} catch (SensorManagerException e)
		{
			throw new SensorDataOperationFault("Error accessing the Sensor Manager: " + e.getMessage() + "");
		}
	}
}

Here is the call in Web Service Explorer:

Outline

In this article we showed how to expose the functionality implemented in an EJB 3 Session Bean using Web Service Technology. In fact, the creation of a FacadeBean was not required since one could annotate the SensorManager-Bean directly, but we separated the implementation Bean from the exposing Bean to make it easier to understand. Even if we didn’t match the WSDL from the J2EE 1.4 example exactly, we came very close. Merely some message-related datatypes have different names. In this example we used the Document/Literal/Wrapped style of Web Services in order to gain maximum interoperability. Even though the creation of the Web Service is a simple task using the annotations. The number of tools and dependencies has dramataically reduced since J2EE 1.4 and the development became less error-prone. Together with other EJB3 improvements it makes the JEE framework suitable for development in the context of enterprise distributed systems.

References and Resources

The example source code is available for download ( ws4jee.zip). Just import the projects from the archive into Eclipse Worskspace. Make sure to set up the JRE and JBoss Server instance for the projecst to work.

[2008,techreport] bibtex

E. Jendrock, J. Ball, D. Carson, I. Evans, S. Fordin, and K. Haase, "The Java EE 5 Tutorial," 2008.

@techreport{JAVAEE, author = {Eric Jendrock and Jennifer Ball and Debbie Carson and Ian Evans and Scott Fordin and Kim Haase}, title = {The Java EE 5 Tutorial}, url = {http://java.sun.com/javaee/5/docs/tutorial/doc/}, month = {Oct}, year = {2008} }
[2007,book] bibtex

O. Ihns, D. Harbeck, S. M. Heldt, H. Koschek, R. Schl�r, J. Ehm, and C. Sahling, EJB 3 professionell. Grundlagen- und Expertenwissen zu Enterprise JavaBeans 3 fr Einsteiger, Umsteiger und Fortgeschrittene , publisher DPunkt Verlag, , 2007.

@Book{IHNS_2003, author = {Oliver Ihns and Dierk Harbeck and Stefan M. Heldt and Holger Koschek and Roman Schl�mmer and Jo Ehm and Carsten Sahling}, title = {EJB 3 professionell. Grundlagen- und Expertenwissen zu Enterprise JavaBeans 3 f�r Einsteiger, Umsteiger und Fortgeschrittene }, publisher {DPunkt Verlag}, year = {2007}, month = {Jul}, url = {Oliver Ihns, Dierk Harbeck, Stefan M. Heldt, Holger Koschek, Roman Schl�mmer, Jo Ehm, Carsten Sahling} }

Configuring JBoss Datasource for Firebird DB

shuron — Mon, 04 Jan 2010 00:33:17 +0000

Accessing a relational database system from Java is a basic step required for many applications. The JEE architecture defines a standard for gaining this access, calls Java Connector Architecture (JCA). This article is a short HOWTO of configuring JCA-compliant datasource to a Firebird 2.x RDBMs using JBoss AS 5.1.0 as example. This tutorial is based on a Windows installation, but can be easily ported to Linux, or other OS.

For the configuration of the datasource two steps are required:

Deployment of the Firebird RAR resource adapter (jaybird-*.rar)
Creation of the firebird-ds.xml configuration

RAR Resource Adapter

The RAR Resource Adapter is a version of RDBMs drivers packaged in a special way, defined by the JCA specifcation. The
latest versions of Type 4 JCA-JDBC Firebird Driver (JayBird) can be downloaded from the IBPhoenix site. Inside of the downloaded archive you will find jaybird-*.rar (The version used during the creation of this tutorial was jaybird-2.1.6.rar). Since deployment in JBoss AS is performed by simple file copy, make sure to put the RAR-adapter-file into the deployment location of the application server. (e.G. ${JBOSS_ROOT}\server\default\deploy\).

After deployment, you can check the status of the resource adapter, by looking on the Administration Console of the JBoss (by default accessing the server URL http://localhost:8080/admin-console/ if run locally).

Datasource Description

After a successful deployment of the Resource RAR, the configuration of the datasource has to be created. The Firebird datasource configuration is supplied in a file, located in the default deployment location. JBoss AS auto-deplyoer will automatically look for the *-ds.xml files, so we name it e.G. firebird-ds.xml.

The following datasource configuration defines a local transactional datasource. You just need to replace placeholders USERNAME, PASSWORD and path to your database-file (In the used installation the file was located in: c:\databses\tesdb.fdb)



  
  
  
  


	
		DataSourceFirebirdDS
		jdbc:firebirdsql:localhost/3050:c:${/}databses${/}tesdb.fdb
		org.firebirdsql.jdbc.FBDriver
		TRANSACTION_REPEATABLE_READ
		ISO8859_1
		10
		USERNAME
		PASSWORD
		0
		10

		5000

		15
		SELECT CAST(1 as INTEGER) FROM rdb$database
		false
		0
		
			Firebird

Usage

The datasource in the example above is registered in the java JNDI namespace and is called DataSourceFirebirdDS. In the source code, this resource should be accessible via java:/DataSourceFirebirdDS. Here is the example using Dependency Injection (DI):

@Ressource(mappedName = "java:/DataSourceFirebirdDS")
private DataSource firebirdDataSource;

In order to use the datasource in a JPA, the persistence unit has to be configured. For example, for using Hibernate, the following persistence unit can be configured.

...

	java:/DataSourceFirebirdDS
	org.hibernate.ejb.HibernatePersistence
	...
	
		
		
		...
	

...

Then in the DAO for manipulation of Persistent Entities, the Persistence Context can be injected by:

@Stateless
public class TestDAOBean implements TestDAO {

	@PersistenceContext(unitName = "testunit")
	private EntityManager manager;

	...
}

Have fun and please provide some feedback.

EWiTa and ESE 2009

Simon Zambrovski — Tue, 10 Nov 2009 21:24:55 +0000

Even if some time has passed since the events EWiTa 2009 and Eclipse Summit Europe 2009, I would like to share my impressions, since I took part in both events…

EWiTa 2009

EWiTa 2009 stands for Elmshorner Wirtschaftsinfromatiktag, that is German for “Elmshorn Business Information Systems Day”. The event has been organized by Frank Zimmermann, of Nordakademie – a private university in Northern Germany. Even if the event is not an official sequel of the MDSD Today, there were many similarities. The event had two tracks: the process modeling track and the MDSD track. After an excellent keynote from Mathias Weske about the importance of collaboration during the process of (business) modeling I stayed in the business track to listen to the Andrea Grass ( oose GmbH) on the combination of UML and BPMN 2.0. To say the truth, I’m not a big fan of this approach, especially, because the conceptual mismatch of modeling of business behavior and technical behavior. After a coffee break I enjoyed an excellent talk of itemis), reporting about the success story of xText in a big project of Deutsche Börse AG (German Stock Exchange).

After a small lunch, I was listening to two Arcando consultants reporting about their eTicketing project. The strange thing about this talk was that they just made some ads on a standard Microsoft product. After this, I enjoyed an interesting talk on business modeling based on CobIT process. Finally, I switched the track again to MDSD and listend to the an interesting usage of MDSD techniques for generation of DynPro and ABAP code.

In general I enjoyed the event. I think the MDSD track was a little more technical, but the combination was good.

Eclipse Summit Europe 2009

The Eclipse Summit Europe 2009 (ESE 2009) took place on October 27-29 in Ludwigsburg, Germany, it is the European complement to the EclipseCon in the US. In contrast to the spring event in Santa Clara, CA, the ESE is an autumn event in a beautiful baroque town near Stuttgart. The event lasted three days and is a must for Eclipse-related technology people. As usual, the venue was great, the keynotes excellent and the talks interesting. And of course it was the place to meet the committers, evangelists, see them in action, talk to them and discuss the future directions.

Symposium Day

The first day is an arrival day. People arrive during the day, some of them are already there. I was visiting the Modeling Track the whole day and had much fun with Ed Merks, Eike Stepper and Thomas Schindl in the morning. Later, in the Modeling Symposium, Eike showed the eDine RCP based on CDO, UBS envisioned the modeling tool pipeline and so on, and so on. About 10 people showed different technologies on and about modeling. Intersting, unstructured and relaxed. And of course, the first evening is the opportunity to speak with all the Eclipse VIPs and drink a cold beer.

First Day

The main conference day was Wednesday and it started with a great keynote on functional programming held by Don Syme, the father of F#. Suprisingly, the talk was about F#. For some of us, there was not enough functional beauty exposed in the talk, so I scheduled a private session with Don and he told Markus Voelter, Heiko Behrens and me about some interesting F# features.

I took part in the How about I/O session on JPicus. A very interesting tool for tracking I/O problems in Java programs developed by SAP. The Climb The Tower of Babel was about the Eclipse translation project. Intersting is the runtime editor allowing you to translate you runnig application. After a delicios lunch, I enjoyed two modeling talks: Xtext and EMF Query. The itemis team introduced some really new features, which make Xtext in my oppinion to a unique technology. Just to mention few of them: white-space aware parsing, usage of scopes and qualified names, usage of index (construted by a builder) in your own language, separation of markers and annotations in the editor, integration of the generator on-save, declarative quick-fix in your DSL, strings with special meaning, references to java types, and much more… The EMF Query is a project developed by the SAP team, that leverages the index by a query language. The language is a SQL-like DSL for querying the EMF-based models. The infrastructure is very intersting and allows complex scenarios with multiple model providers – very technical, and I believe, very interesting project.

Second Day

After the keynote on the importance of software ecosystems and a deep economical analysis of Eclipse ecosystem, I switched off the track to be able to prepare my talk. I was reporting about the IDE for TLA+ which I was building the last nine month at Microsoft Research, and which will be available soon. The main emphasis of the talk, was not the demo of the IDE, but the exchange of experiences on building one. Especially, I focused on the possible pitfalls and conceptual mismatches of IDEs depending on the integrated language. The slides will be available soon.

At the end, I enjoyed the event very much. I even liked it more than EclipseCon. Modeling still seems to be the most interesting part of Eclipse ecosystem. Technologies like Xtext and CDO gain maturity, new technolgoes like EMF Query are being developed. It was nice to see the people again… As usual, some pictures:

Packaging Eclipse-based RCP for the use in enterprise context

Simon Zambrovski — Wed, 08 Jul 2009 20:00:33 +0000

Abstract

Using Eclipse-based rich-clients as stand-alone applications is discussed in many books and articles. In the context of enterprise systems, the software development adopted several paradigms to improve the quality of the overall architecture. This short article describes some issues in packaging the application for using it in the context of enterprise systems.

Architectural Assumptions

Designing enterprise architectures is a standard discipline for IT-consulting companies or freelancers involved in software development. Maybe one of the main characteristics of enterprise architectures is the framework-driven approach of software creation. Thus, the software has to comply certain rules and standards adopted inside the enterprise. In order to simplify such constrained development process, it is common to use an in-house software framework, which enforces the compliance of the enterprise-internal standards and acts as glue between different technologies adopted as parts of the enterprise architecture.

Using such frameworks has major implications for the software development in general, and especially for the rich client development. The design issues are summarized in the next section.

Usaging an Enterprise Framework

The major goal of the enterprise in-house framework is to simplify the process of software systems development and to enforce standardization among the software systems. This usually includes the following aspects:

Domain-specific component framework
Methods for master data management
Infrastructure services: authentication, authorization, communication, security, printing, reporting
Application skeletons and launchers

The more unification and standardization is included inside the framework, the easier it is for a software developer to concentrate on the particular business task and the easier is the maintenance of the software system.

From the previous list, the most interesting part related to RCP packaging and deployment is the existence of the application skeletons and launchers. So, when launching an application, the framework libraries are loaded and executed first and pass the control to the application-specific modules. The advantage of this approach is that infrastructure services can be loaded first, which can be developed and shared among different applications.

The required plug-ins

Following the general idea of RCP packaging (see rules provided in the RCP Book) and assuming one target platform (in terms of one RCP product), one top-level plug-in and should be defined. In addition, we assume at least one in-house framework plug-in and at least one application-specific plug-in. Usually there will be more of each type, but it will not change the picture much. Important at this point is the fact, that the application-specific code depends on the in-house framework code. In order to simplify the identification of the plug-ins, an example project is introduced. Let’s assume the project is called FooBar. Then, the plug-ins are called:

de.techjava.foobar: This is the functional plug-in, which contains the application-specific code.
de.techjava.framework: This is the framework plug-in, which contains framework component code.
de.techjava.foobar.product.standalone: This is an application and product definition plug-in which contains the definition of the product and application-agnostic code for launching the application.

Managing plug-in dependencies

A difficult issue for the RCP beginners is the management of dependencies between plug-ins. Especially, the transition from the development of a single plug-in to the configuration of features and products seem to be non-trivial. In order to solve this problem, there are simple rules to follow. You can violate these rules in sophisticated scenarios, but for the beginners it is a good idea to follow them.

Create dependencies only if you need them. Each plug-in should only list plug-ins (or even better packages) it really depends on. Make sure to check it with the “Find unused dependencies” action available on the right-click in the Dependencies Tab of the Plug-in Manifest Editor.
Use versioning information. Plug-ins (or better bundles, or as Chris call them Plundles) provide version information. And it is highly advisable to include them in the import statements of the plug-ins, which simplifies the migration later on…
Don’t forget anything. Every Plug-in should appear in at least in one Plug-In section of the Feature definition. Every feature should be included by another feature, higher in the hierarchy.
Keep the hierarchy flat. For simple scenarios, it is sufficient to have two levels of features (top-level feature, one per-product and the underlying features include their plug-ins).
Don’t re-export dependencies. Every Feature for a group of plug-ins should also include plug-ins required by the members of the group. It does not hurt if a plug-in is included several times, but it does if it is not included at all. You can optimize here if you check which plug-ins are imported by the Eclipse RCP feature (which can be considered as stable), but it does not make assumptions about features developed by third parties.

Following these rules it is simple to create features for the corresponding plug-ins. Several plug-ins which belong together and are handled as a fixed piece can be grouped into Features. Usaging Features is highly advisable, and sometimes simply required (e.G. by RCP in a Java Web Start target deployment strategy). So in addition to the previously mentioned plug-in projects, at least three feature projects are required:

de.techjava.foobar.feature: This is a functional feature, which includes the de.techjava.foobar plug-in and all plug-ins required by it, which do not appear in the Eclipse RCP feature
de.techjava.framework.feature: This is a framework feature, which includes the de.techjava.framework plug-in and all plug-ins required by it, which do not appear in the Eclipse RCP feature
de.techjava.foobar.feature.standalone This is the top level feature, which is used for the product configuration. It includes the two features above and the Eclipse RCP feature (and optional other features used, like e.G. org.eclipse.help). It also includes exactly one plug-in, which is not included anywhere else: de.techjava.foobar.standalone.product

The product definition plug-in

The definition of the product is spread among several files. First of all the plug-in.xml of the de.techjava.foobar.standalone.product plug-in makes uses of two extensions:

org.eclipse.core.runtime.applications
org.eclipse.core.runtime.products

The application extension point is used to point to the Java class implementing the interface org.eclipse.equinox.app.IApplication. Along with this implementation, other classes needed to start up the RCP (like Advisors, etc…) are placed into the source directory of the plug-in. The product extension point is used for the association of the application with a product id. The previously-defined top-level feature includes all required features and the product definition plug-in. Finally, the .product file is the place, where all things are bound together: product id, application id, launcher parameters, and the one top level feature: de.techjava.foobar.feature.standalone. Other customization of the RCP is possible from the plugin-customization.ini, which is placed together with the .product file into the plug-in root directory.

As a result the following configuration should be achieved after the packaging is finished. The product references the product-id and the application, defined in the plugin.xml of the plug-in project it is contained in. The product configuration is feature-based and includes one top-level feature. The top-level feature includes all other features (functional, framework, Eclipse RCP, other optional) and the one plugin, in which the product file resides.

The simple example provided in this articles is available as sourcecode for download ( rcp-packaging.zip).

The framework hooks

In the introduced scenario, the packaging is not specific to the in-house framework. It just includes the feature containing the framework plug-in. This approach works fine, if the framework is used in a white-box manner, which means that the framework provides ready-to-use components to be plugged-in to the application (like e.G. a component for the master data management). The other type of frameworks is the so-called black-box framework, which provides components that have to be configured and integrated into the application components. In this case, the framework components can not be plugged-in using some declarative extension points, but need to be called from the application code. In the latter case, the dependencies appear between the plug-in launching the application (de.techjava.foobar.standalone.product) and the framework plug-ins. This requires a modification in the previous setup and the violation of one of the rules posted above. The plug-in has to define the dependency to the framework plug-in, but the top-level feature does not include the required plug-in directly, but imports the whole framework feature.

Technorati-Tags: eclipse, java, rcp, packaging, plugin, feature, product, enterprise systems

RCP Help System

Simon Zambrovski — Fri, 24 Apr 2009 22:04:23 +0000

Eclipse Platform provides a help system that can be used during creation of the help content for your application. It is very convenient while used inside of the IDE, but needs a special approach if used in the RCP. This article tries to gather the information which may be useful.

Adding Help Support

Basic preparations

As discussed in Eclipse RCP Book and RCP Articles, the help system is not a part of the RCP-Runtime and should be added separately. The question arises where to add at to? If you follow the best practices for packaging of RCP applications, you should have at least one product and the top level feature defined (See Rule 1 of Chapter 23 of Eclipse Rich Client Platform). The top level feature includes the branding plug-in (containing the product definition) and refer to other features (like org.eclipse.rcp, and your functional features). In order to add the help system, you need to add the org.eclipse.help feature in this list.

Platform help buttons

There are several predefined buttons (actions) you can use for calling the help system. These are:

Help Contents
Help Search
Dynamic Help

In order to activate them from your ApplicationActionBarAdvisor just call:

private IWorkbenchAction helpContentsAction;
private IWorkbenchAction helpSearchAction;
private IWorkbenchAction dynamicHelpAction;

protected void makeActions(IWorkbenchWindow window)
{
helpContentsAction = ActionFactory.HELP_CONTENTS.create(window);
dynamicHelpAction = ActionFactory.DYNAMIC_HELP.create(window);
helpSearchAction = ActionFactory.HELP_SEARCH.create(window);
register(helpContentsAction);
register(helpSearchAction);
register(dynamicHelpAction);
}

If you want to do the same declarative, you have to create commands that use the following actionDefinitionIds:

org.eclipse.ui.help.helpContents
org.eclipse.ui.help.helpSearch
org.eclipse.ui.help.dynamicHelp

The same ids are required for registration of key bindings (e.G. Ctrl + F1, Shift + F1, F1 on Win32). Apparently, since these actions adjust their status depending on the state of the system and the plug-ins installed, I could not figure out how to force them to be enabled, when installed in a declarative way. Since they are still provided as ActionFactory (which is legacy due to the changes introduced by new Command Framework), they should be further activated from the ApplicationActionBarAdvisor.

Context-Sensitive Help UI Integration

The Eclipse platform provides not only the help system, but also support the so-called Context-Sensitive Help (a very confusing name, because the context is only the widget, and not the data). In the following, it is shown, how the connection between the widgets and the help system can be established.

The big picture

The content already defined in the help system can be pointed at from various places in the your application using the so-called help contexts, which on one hand point to the places in the documentation and on the other hand can be assigned to widgets in the application UI.

Establishing contexts

In order to assign the help context to a widget the invocation of the method PlatformUI.getWorkbench().getHelpSystem().setHelp(Control control, String contextId); is used. The contextId is a full-qualified string constructed from the pluginId and the local context name. The context name should be unique for this plug-in (usage of non-unique ids leads to a merge of different subjects, which is a nice feature, but may be not desired). I prefer to create the convenience method for this invocation:

public class HelpUtil
{
public static void setHelp(Control control, String localContextId)
{
if (localContext == null || control == null) return;
PlatformUI.getWorkbench().getHelpSystem().setHelp(control,
Activator.PLUGIN_ID + "." + localContextId);
}
}

There are also methods for registration of other SWT widgets (Control, IAction, Menu, or MenuItem) in the help system, which can be handled by the overloaded version of the method. The invocation of the convenenience method usually looks like: HelpUtil.setHelp(composite, "newWizardPage") and should be invoked from the createControls() of the correponding element. Please note, that the “newWizardPage” is a local name, and the pluginId is added to it inside of the conveninece method. Widgets that do not get focus should not be assigned context ids, since they will never trigger a context-sensitive help

The declarative part

As usual in Eclipse, there is a declarative part, that connects the context ids, set up in the code with the help pages. The connection is established by a special XML file. In order for the platform to know, where to find the file, there is an extension point (org.eclipse.help.contexts), that you need to contribute to:

The file attribute specifies the full path to the XML file containing the context definition. The plugin attribute is optional and declares for which plugin the context definition applies. Please note, that if the plugin attribute is ommited, the context names used in the context definition file will be seen as local to the plugin they are declared in. For example, if you want to support the context-sensitive help in plug-in de.techjava.rcp.xyz then your in-code definition of the context should define full qualified context names like de.techjava.rcp.xyz.context1. Either you use the extension point (org.eclipse.help.contexts) in the plugin.xml of the de.techjava.rcp.xyz plugin.xml, or if you put the usage of the extension point into some other plugin (e.G. central for all help), you must provide the plugin attribute with value “de.techjava.rcp.xyz”. This issue is badly discussed in the help guide and is a little confusing. In the context definition file the contexts are defined as follows:



This is a test context


...

Wizards and Dialogs

Wizards are used with or without dialog.

The call of the Wizard#setHelpAvailable(true) shows the Help button.
The call of the WizardDialog.setHelpAvailable(true); shows the small sexy round Question button.

References

Eclipse Ganymede and WSCompile incompatibility?

shuron — Wed, 25 Feb 2009 17:49:04 +0000

I found strange problem running wscompile (from Sun’s Java Web Service Developer Pack 1.6) inside Ganymede (Eclipse Version 3.4.1). The run of the wscompile Ant task produce a problem. The build script execution freezes on the wscompile task. It prints the following message on console but then nothing happens.

[wscompile] wscompile ...\env\java\1.4.2_03\jre\bin\classpath-classpath D:\workspaces\general\lib\bla.bo-0.0.1.jar; ... D:\workspaces\general\lib\... jar.0.5.5

In this line, the classpath of wscompile is printed.

The build script uses configured Apache Ant in version 1.6.5. I tried to start it with Java in versions 1.4.2 und 1.6.0.10. Both works in Europa (Eclipse 3.3.x) but don’t work in Ganymede (Eclipse 3.4.x), except for the first run. It seems that Ganymede provides a different handling for Ant scripts. Every first start of an Ant build script produces new “External Tool Configuration” (if not already there). If this configuration already exists, wscompile task doesn’t work!

This means my build script with wscompile task works only once, every first time after deleting the “External Tool Configuration”. I could live with that if I wouldn’t need that configuration. But I need that configuration to use different java version that is the workspace default.

Do anyone know how to fix that?
Here is my task definiton.

and also task usage in the script

Comments are welcome.

Hacking, Progmatic, Productive

Simon Zambrovski — Wed, 17 Sep 2008 14:12:49 +0000

Yesterday, the second Adam Bien event in Lehmanns Bookstore took place. Again, the event was a full success. I arrived half-an-hour earlier and got a seat only in the tenth row.
Adam spoke about new features of EJB 3.1 and Glassfish. He showed examples running on a developer build of Glassfish V3, promising that the features will work without exceptions…
Here are some topics, I remember:

Singleton Beans: usefull a s a central point of the application, e.G. central cache etc…
Async Methods: allows asynchronous execution of time-consuming methods. Especially, it is possible to abort the execution
Deploying Beans in WARs: could be helpful for small applications
Global JNDI-Namespace
No interface view: simplifies the access to beans, if needed
EJBCOntainer.getEJBContainer().getContext(): allows external initialization of bean context, which is nice for testing

Later, Adam discussed some Core J2EE patters, that become absolete with EJB 3.1 and others which are still valid.

After the talk, I spoke with Adam about the OSGi as a module architecture inside JEE application, which seems interesting to me.

The pictures are as usual available in my FlickR Gallery.

Marco published a video on Loroma.