Salient Soft

If you want to configure the libraries for use with a particular Eclipse plugin, this can seem rather a mystery at first. The traditional way in Eclipse to configure libraries for a project is to open the project properties for a project, select Java Build Path in the list on the left, and visit the libraries tab in the pane on the right. You can then use the “Add Jars” or “Add External Jars” to add jars to the project. To improve project portability across different development platforms, you can also add Classpath Variables which can be defined appropriately for each platform to isolate a project from platform specific jar locations etc. An example of this screen, with the JSF and ICEfaces entries expanded, is here :-

However, whilst you will see entries for plugins such as Eclipslink and ICEfaces on this screen, it does not provide any means of configuring them. Libraries for such plugins use an Eclipse feature called a Classpath Container. This allows the library configuration to be completely dynamic, as it is handled in code via a class. This allows the configuration to change at any time in response to project changes, as every reference to the classpath container is handled via the code rather than being static. To configure plugin libraries, therefore, you need to visit the dialogs for the Project Facets, which is where plugins are configured for the project. This post here, which details how to create a JPA-enabled EJB, shows this in action for JPA.

Another example would be to configure the  libraries for JSF and ICEfaces. You can do this as follows :-

Open the Project Properties dialog for the project, and select the Java Server Faces option under Project Facets in the left hand pane. This lists all the JSF and ICEfaces libraries available which may be selected/deselected.

The buttons on the right of the libraries frame allow management and downloading of the libraries. Clicking the Manage Libraries button allows configuration of the libraries available for selection in the project facets dialog above.

This is for example where you would upgrade ICEfaces libraries to a new version. You can leave both versions, or remove the old ones once you don’t need them any more. You can then select the new versions for that particular project in the parent Project Facets dialog.

Note that one particular issue arises when creating a new Eclipse workspace, as it is useful to migrate all the library definitions to the new workspace to avoid having to set them up manually or download them again. This post describes how you can do this by exporting and importing workspaces preferences. The post also discusses the issue of library location when sharing libraries – this is important as by default you would end up with one workspace sharing libraries within the folder structure of another workspace. My typical development folder structure is detailed at the end of this post.

If you subsequently return to view the libraries on the Libraries tab of the Java Build Path screen, you will then see the results of your efforts – the libraries for the plugins will have changed in accordance with your actions.

The dialogs used for plugin configuration do vary and are certainly not always intuitive or consistent – in these examples JPA was configured via the Java Persistence dialog in the project properties or via a link on the JPA facet screen which is not always present. In contrast, the JSF libraries (including the ICEfaces libraries) are configured via the Java Server Faces option under Project Facets. Even though there is an ICEfaces option under project facets, in my 3.5 Galileo Eclipse this displays “unknown library configuration”. However, the configuration is all there if you are willing to hunt around a bit for it!

No Comments »

This simple example was performed with Eclipse Galileo 3.5.1

1/ Project Creation Dialog

From the menus in eclipse, select File/New/EJB project. On the resulting dialog, name the project. You can pick other options at this stage such as EAR membership but this can be done later if desired. Note that we are not amending the configuration section (via the modify button) at this stage to add JPA faceting (more on this later).

Click Finish and your EJB project will be created.

2/Project Facets

Right click your new project, and select Project Facets on the left. Tick the box marked Java Persistence in the middle pane, and you will be presented with the following screen :-

3/ JPA Facets

Now Click the “Further configuration available” link at the bottom. This will display the JPA Facet dialog as follows. On this screen you should do the following :-

1. Select the correct platform version and library type – typically these will be Eclipselink 1.1 or later version if available.
2. Untick the box marked “Include libraries with this application”.  The  latest Eclipselink.jar  library should be deployed separately to Glassfish, and stored in the $GLASSFISH_HOME/lib directory. To clarify, Eclipselink is available as a single jar, non-OSGI deployment, or split up into multiple jars for OSGI deployment. The OSGI jars have the long names with the OSGI packaging prefixes such as “org.eclipse.persistence.core” followed by name and version number information. They are a finer grained breakdown of the classes to allow more selectivity/flexibility in use. You can copy the OSGI jars to $GLASSFISH_HOME/lib directory – this will also work but is unnecessarily complex for non-OSGI use. This post here contains a brief overview of OSGI and links to detailed information about it.
3. Select the database connection to be used. If it is not already present, click the Add connection link to create a new one. This also allows you to add a new JDBC provider for a given database type, and point to the jar file(s) for the provider. Note that you will also need to add the JDBC provider jar to GLASSFISH_HOME/lib. To clarify, this database connection is used by eclipse to validate the persistent entities and mappings in the project during development. It is not used by Glassfish at run time. The run time connection (data source) will be created in Glassfish, and persistence.xml will be configured to use the datasource that you created in Glassfish.
4. Next, you can select whether your annotated persistent classes will be discovered automatically, or whether they must be listed explicitly in persistence.xml. To ensure portatbility, you should take the manual option as  automatic discovery is not guarrranteed to be portable.
5. Finally you can select whether or not to create orm.xml. You can always create it later if you need it – if you are using annotations entirely you won’t. This post here describes how you can combine both annotations and orm.xml in order to both take advantage of features like sequences in Oracle whilst still retaining database independance.

Click OK on the JPA Facet dialog, and then OK on the project facets screen. This will complete the creation of your project.

Note that as already stated, it is possible to click the modify button in the configuration section of the dialog in stage 1, which will also display the project facet screen. However, this version of the project facet screen is different to the one displayed if you select Project Facets after creating the project. In particular it does not have the “Further configuration available” option, and so does not allow you to display the JPA Facet dialog to modfy the options there. It assumes defaults for these options instead.

It is possible to  reconfigure the project JPA Facet settings subsequently, by selecting the “Java Persistence” option which appears in the list on the left of the project properties dialog (this only appears for projects with the JPA facet selected). This displays the “Java Persistence” dialog which has the same options as the “JPA Facets” dialog. Instead, you can also untick Java Persistence on the Project Facets screen, applying the changes, and retick the option. This will reveal the “Further Configuration Available” option to allow access to the JPA Facet dialog as well. In the example above, we added the Java persistence facet after saving the project which gave us immediate access to the JPA Facets dialog.

No Comments »

Note that when implementing dual (both Local and Remote) interfaces on an EJB, you can extend a single underlying superinterface. In this case, SimpleBeanLocal and SimpleBeanRemote both extend SimpleBean. However, when you do this, the implementation code must explicitly implemement both subinterfaces SimpleBeanLocal and SimpleBeanRemote as in this example. Implementing the superinterface SimpleBean on its own will not work.

(Super)Interface SimpleBean

public interface SimpleBean {
   public void createUsers(); 
   public List fetchUsers();
}

(Sub)Interface SimpleBeanLocal

@Local()
public interface SimpleBeanLocal extends SimpleBean {}

(Sub)Interface SimpleBeanRemote

@Remote()
public interface SimpleBeanRemote extends SimpleBean {}

Implementation Class SimpleBeanImpl

@Stateless(mappedName="ejb/JPAGlassFishIceEJB/SimpleBean")
public class SimpleBeanImpl implements SimpleBeanLocal, SimpleBeanRemote {

...class Code here...

}

No Comments »

This article on CodeIdol is a good detailed FAQ on the Enterprise Naming Context or ENC, also known as the Java EE Application Component Environment, accessed via the JNDI name “java:comp/env”.  The article details the use of the java ee annotations in @javax.annotation.EJB and the equivalent XML, including injection of bean references via XML using <injection-target> rather than annotations. 

Another article on redhat.com gives a good overview of this with some other helpful links.

No Comments »

Update

I have posted some further notes on this here. The notes are in raw form from an earlier investigative email – much of it is covered here, but some points and links are not, and I do not have the time or inclination at present to rework everything into a single post!

The following examples show typical scenarios which have been tested as working :-

1/ Local EJB Interface injected into JSF managed bean via @EJB

Note that when implementing a dual interface as here, you can extend a single underlying interface. In this case, SimpleBeanLocal and SimpleBeanRemote both extend SimpleBean. However, when you do this, the implementation code must explicitly implemement both SimpleBeanLocal and SimpleBeanRemote as in this example. Implementing the superinterface SimpleBean on its own will not work. This is also explained in this post.

JSF managed bean code

@EJB()
private SimpleBean simpleBean;

EJB Implementation Code

@Stateless()
public class SimpleBeanImpl implements SimpleBeanLocal, SimpleBeanRemote {

...class code here...

}

2/ Local EJB Interface looked up in JSF managed bean directly via JNDI 

JSF managed bean code

try {
  InitialContext ctx = new InitialContext();

  /* Note that the JNDI name consists of the Java EE Environment Naming Context (ENC) -
    "java:comp/env", followed by "/", followed by the <ejb-ref-name> used in web.xml.
    The extra /Local is just to make the name different to the remote example.
    Any name can be used providing web.xml matches, and multiple slashes can be present.
  */

  simpleBean = (SimpleBean) ctx.lookup("java:comp/env/ejb/JPAGlassFishIce/Local/SimpleBean");     
  userList = simpleBean.fetchUsers();
} catch (NamingException e1) {
  e1.printStackTrace();
}

web.xml

<!-- We define a reference for the bean here.
     If we were using @EJB this would do it for us,
     but in this case we are using an explicit JNDI lookup.
-->
<ejb-local-ref>
    <ejb-ref-name>ejb/JPAGlassFishIce/Local/SimpleBean</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <local-home></local-home>
    <local>uk.co.salientsoft.jpaglassfishice.domain.SimpleBeanLocal</local>
</ejb-local-ref>

EJB Implementation Code

@Stateless()
public class SimpleBeanImpl implements SimpleBeanLocal, SimpleBeanRemote {

...class code here...

}

3/ Remote EJB Interface injected into JSF managed bean via @EJB

JSF managed bean code

@EJB(name="ejb/JPAGlassFishIce/SimpleBean", beanInterface=SimpleBeanRemote.class)
private SimpleBean simpleBean;

EJB Implementation Code

@Stateless(mappedName="ejb/JPAGlassFishIceEJB/SimpleBean")
public class SimpleBeanImpl implements SimpleBeanLocal, SimpleBeanRemote {

...class code here...

}

4/ Remote EJB Interface looked up in JSF managed bean directly via JNDI 

JSF managed bean code

try {
  InitialContext ctx = new InitialContext();

  /* Note that the JNDI name here matches the mappedName given in the
     @Stateless annotation in the EJB implementation code.
     mappedName is only relevant for remote interfaces.
     It is not used for a local interface.
  */

  simpleBean = (SimpleBean) ctx.lookup=("ejb/JPAGlassFishIceEJB/SimpleBean");     
  userList = simpleBean.fetchUsers();
} catch (NamingException e1) {
  e1.printStackTrace();
}

EJB Implementation Code

@Stateless(mappedName="ejb/JPAGlassFishIceEJB/SimpleBean")
public class SimpleBeanImpl implements SimpleBeanLocal, SimpleBeanRemote {

...class code here...

}

No Comments »

I created a simple test web app using ICEfaces, including the test/sample page that the plugin creates for you by default. When running the app on Glassfish, the error “Object doesn’t support this property or method” occurs and the page fails to load correctly. The same application works in Tomcat.

The issue turns out to be due to a single extra space in web.xml. The Eclipse code has an extra trailing space in the url pattern for the Persistent Faces Servlet mapping as follows :-

Broken Version with trailing space after the * – works on Tomcat 6, fails on GlassFish 2.1

<url-pattern>/xmlhttp/* </url-pattern>

Working Version without trailing space – works on both

<url-pattern>/xmlhttp/*</url-pattern>

The effect of the extra trailing space appears to be that GlassFish 2.1 does not obey the servlet mapping for this url pattern. Tomcat is not tripped up by the trailing space. An extra hazard for the unwary in Eclipse (Galileo) is that if you use the XML editor to edit web.xml, it hides the trailing space if it is present, so you could miss it even if you were aware of the potential issue. The text editor shows the space correctly.

My original post on this in the ICEfaces forums is here. This problem has been fixed in 1.8.2 – the bug tracker entry for the problem is here. Note that upgrading to 1.8.2 will not apply the fix to existing projects in Eclipse, only to new ones. For existing projects, you need to remove the extra space in web.xml manually.

No Comments »

A useful article on this, and on keeping Eclipse clean is here. Some general points on this are as follows :-

1. In my experience it does not pay to let workspaces become too large, as metadata corruption can sometimes cause the whole workspace to fail to load and cross project pollution of metadata can happen. It also helps with performance not to have a huge workspace. I keep all related projects for a given application in the same workspace, but not others.
2. The article describes the use of the -clean command line argument to remove cached OSGi framework and Eclipse run time metadata. I haven’t used it myself, but it is said to be able to fix really obscure bugs/issues caused by metadata corruption.
3. When creating a new workspace, use File/Export/Preferences to save a preferences file which can be imported into the new workspace. This will allow e.g. your plug in libraries and other preferences to be quickly defined in the new workspace. If you do not do this, you need to either download the libraries again via eclipse’s user library management, or load them one at a time. An xml file is used to define the userlibraries and I did not look into how to store a library repository locally with its own xml definition.
4. Note that when sharing the libraries across multiple workspaces, you will want to change the default download locatation when downloading them initially – the default is <workspace>\libraries, which would mean that subsequent workspaces would be sharing libraries from inside another one.  This post here details my typical folder structure which places the shared libraries at a level above the workspaces. You will need to modify the download path each time you download a library (in my case this involves just taking out the Workspaces\<workspace>\ levels from the path).

No Comments »

Useful post gives the code for this here. The code extract is as follows :-

String nextJSP = "/searchResults.jsp";
RequestDispatcher dispatcher = getServletContext().getRequestDispatcher(nextJSP);
dispatcher.forward(request,response);

No Comments »

An interesting article on this is here. It is very thorough and lists all the common gotchas and workarounds to do the job properly.

No Comments »

This Glassfish article  is a must read reference on the naming and JNDI minefield when looking up local and remote EJBs.
There is also a very  informative Refcardz card on this topic. Refcardz can be downloaded as PDFs if  you register.
In my experience, there is a lot of misinformation around the internet on this which can be time consuming to weed out.

I’ve posted some examples of local and remote EJB access via both injection and JNDI here.

Here are some key points I worked through and learned :-

1. Despite a number of blog posts to the contrary, EJBs can be injected via @EJB into JSF managed beans, POJOs called from managed beans, and servlets provided the JSF/servlets are running in the EJB container, e.g. if Glassfish is used both as servlet and EJB container.
2. When injecting local EJBs, using the defaults on @EJB and matching defaults e.g. on @Stateless will work and the bean will inject.
3. When injecting remote EJBs via @EJB, use the mappedName argument to specify the JNDI name of the remote bean. It is also essential to specify the class of the remote EJB interface in the beanInterface argument to @EJB. Failure to do this will result in NamingExceptions, which can give the misleading impression that it is the JNDI name that is wrong.
4. If @EJB is not used, then <ejb-local-ref> may be used in web.xml to define a reference to the bean. If @EJB is used then this is handled automatically. The above Glassfish article details how the various fields in @EJB and <ejb-local-ref> are related.
5. In addition to @EJB and direct JNDI lookups, EJBs can be injected via JSF using a custom EL resolver which performs the JNDI lookups and injections performed in faces-config.xml.  An interesting example of a custom EL resolver to do this is here. However, for injecting EJBs,  @EJB requires no extra code. It is also possible to inject EJBs via Spring, into beans managed by a Spring container. However these have not been pursued as @EJB is the easiest way. It would be overkill to use a Spring container purely for EJB injection/service location.

No Comments »