Salient Soft

A little counter intuitive gotcha this one. At first glance, you would expect to right click a server in the servers view, and pick properties. However, if you do this, you do not get the full set – you just get the ability to switch deployed file location and some monitoring options.

If you just double click the server in the list, or right click and select Open, you get the Overview page listing (almost – see below) all the available properties for the server. For some reason in the past I tripped over this more than once, as it just does not seem right that the properties context menu option does not give the full property page (or at least link to it)!

Also, note that the ‘monitoring’ options available on the properties context menu option do not also appear on the Overview page – however the location  options do appear on the overview page in more comprehensive form.

DOH!!!

Comments Off on Changing Server Properties in Eclipse

I’ve found that this is useful for prototyping/mockups of apps that are targetted for GlassFish. It is possible to run JPA with Eclipselink outside an EJB container, so a JSF/JPA app can be run under Tomcat, resulting in less overhead and faster turnaround of changes. For a while I’ve had to use a PC which is RAM limited, and so developing/prototyping with Eclipse and Glassfish has been slow. Turning around deployments/changes around takes time, and I’ve found the synchronisation between Eclipse and Glassfish to be a bit fussy – sometimes Eclipse misunderstands the state of Glassfish, needing a Glassfish restart which again takes valuable time.

Note the following points on doing this:-

1/ My application stack looks similar to the ‘real’ one, but my Service layer/domain objects are just POJOs which are explicitly created or injected via faces_config.xml. This Oracle Example details the various IOC features of the JSF. managed bean facility.

2/ Persistence.xml needs setting up differently to run JPA outside the container. I have found it easiest to specify the database connection explicitly, rather than using a data source. In Eclipse, you can use the persistence.xml editor to populate the connection properties directly from the one Eclipse uses for its entity validation. Whilst you can do JNDI lookups of a data source stored in Tomcat, the naming context used is different, as it makes use of the Enterprise Naming Context (ENC), i.e. “java:comp/env”. This example details how to do it if you want to go that way. A sample persistence.xml follows (with entries commented out where they have been replaced for use with Tomcat) :- 

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="1.0" xmlns="http://java.sun.com/xml/ns/persistence"
 xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:schemaLocation="http://java.sun.com/xml/ns/persistence
 http://java.sun.com/xml/ns/persistence/persistence_1_0.xsd">

 <!--<persistence-unit name="SentryPrototype" transaction-type="JTA">-->
 <persistence-unit name="SentryPrototype" transaction-type="RESOURCE_LOCAL">

   <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>

   <!--<jta-data-source>jdbc/JPATestPool</jta-data-source>-->

   <class>uk.co.salientsoft.jpatest.domain.UserInfo</class>
   <properties>
    <property name="eclipselink.logging.level" value="INFO" />

    <!-- <property name="eclipselink.target-server" value="SunAS9" />-->
    <property name="eclipselink.target-server" value="None" />

    <property name="eclipselink.session-name" value="SentryPrototypeSession" />
    <property name="eclipselink.target-database" value="Oracle" />   
    <property name="eclipselink.ddl-generation.output-mode" value="database" />

    <property name="eclipselink.jdbc.url" value="jdbc:oracle:thin:@localhost:1521:xe"/>
    <property name="eclipselink.jdbc.user" value="sentry"/>
    <property name="eclipselink.jdbc.password" value="sentry"/>
    <property name="eclipselink.jdbc.driver" value="oracle.jdbc.OracleDriver"/>

   </properties>
  </persistence-unit>
</persistence>

3/ Ref this eclipse tutorial :-
Tomcat does not have an EJB container so you must add EJB 3.0/JPA 1.0 capability for EclipseLink JPA by placing the specification persistence.jar into the container lib directory $TOMCAT_HOME/lib.
It is recommended to put persistence_1_0.xsd there as well.  It is not recommended that the WAR include its own version of persistence.jar. Your eclipse project should reference but not include this jar and xsd.

The eclipselink.jar should be placed off of the container lib directory $TOMCAT_HOME/lib.
Since Tomcat does not include an EJB container, you may put eclipselink.jar in the web applications’s lib directory or higher up in the classloader by putting it off of Tomcats’ lib directory, where all web applications can access it.
Do not split the eclipselink.jar from the javax.persistence jar – keep them together – preferably in $TOMCAT_HOME/lib

 4/ Tomcat has its own dependencies on the Expression Language (EL) web libraries. These should be removed from WEB_INF/lib when deploying to Tomcat as pointed out here. (If you do not do this, the application will crash with duplicate class loading exceptions.) This may be done in eclipse on the Java Server Faces facet page – open the project properties for the project, and select Java Server Faces under Project Facets. Untick the entry for Standardized EL Library v1.0.

Then save the changes and redeploy the application.

For more information, the eclipse tutorial referenced in 3/ goes into greater depth on the subject. You can also find a list of the available eclipse JPA tutorials here.

5/ When running xxxxxx

Comments Off on Using Eclipse/JSF/JPA with Tomcat 6

This can be done a couple of different ways :-

1. From the Project context menu, select JPA Tools/Create Tables from Entities. This will drop and create the whole schema based on the entity definitions.
2. Alternatively, you can configure persistence.xml to drop and create the whole schema before each run as detailed in the example file here.

Comments Off on Creating database tables from Entities in Eclipse

OSGI is an acronym for the Open Services Gateway Initiative, an open standards organisation formed to promote the specification of a Java based services platform that can be remotely managed. The Acronym is now obsolete, and instead the organisation is called the OSGi Alliance.

Eclipse is an OSGi compliant platform, and uses OSGi to manage its services and plugins. An OSGi plugin is quickly recognisable by the fact that its library jars are broken down to a fine grained level to allow flexible deployment, and have long names consisting of a package prefix and version number information. A typical example of an OSGi style jar is this core Java persistence jar :-

org.eclipse.persistence.core_1.1.3.v20091002-r5404.jar

Glassfish V3 is also OSGi compliant, but Glassfish V2.1 and earlier are not.

An overview and details of the OSGi concept and specification may be found on Wikipedia here.

No Comments »

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 »

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 »

Update 08/09/2022

Another interesting and helpful post on primary key generation may be found on Baeldung here.

Original Post

There are a number listed on eclipse.org, oracle.com, and Sun.com. The eclipse ones are often not all complete but still useful.

1. A general list of Eclipse tutorials is here
2. Eclipse/JPA/Tomcat web tutorial
3. Eclipselink/JPA/JSF web tutorial (looks incomplete and is missing the source code).
4. Eclipselink/JPA/Glassfish V2 Web Tutorial – also a work in progress.
5. Oracle – Build a Web Application (JSF) Using JPA
6. Oracle – Example: Web Application (JSF) Using JPA (another article using the same code example as the previous one)
7. The Sun Java ee 5 tutorial contains a JPA example.

No Comments »

This one is from Web Age Solutions and is a good basic tutorial building on their earlier “simple session bean” one:-
http://www.webagesolutions.com/knowledgebase/javakb/jkb006/index.html

No Comments »