Salient Soft

Eclipse allows you to export Jars via the Export/Java/Jar File right click option from the package or project explorer on a project.

The export wizard has a number of options. I generally create one jar with the class files in and a second for the sources.

It is obviously somewhat tedious and error prone to select all the options each time, so fortunately on the export wizard, on the Jar Packaging Options page you can select the option to Save the description of this jar in the workspace.

This will then create a .jardesc file with all the options on. Later you can simply right click a previously saved .jardesc  and select Create Jar to recreate the jar with the same options that you saved.

No Comments »

This error came up while building a new development environment with the Eclipse Helios SR2 and Eclipselink 2.2.0.
The error appeared for every JPA entity, even after the database drivers/connections were correctly defined.

The simple answer  as detailed here is to right click the project and do a validate – hey presto, all the errors disappear!
This appears to have been around a while and is still not fixed in Eclipselink 2.2.0, but at least it is simple to resolve.

The tip was found on this Oracle tutorial post :-

Note:

If you encounter a Schema “null” cannot be resolved for table “<TABLE_NAME>” error, you’ve hit a known Eclipse bug.
To resolve the issue, right-click the project and choose select Validate from menu. Eclipse will clear the errors.

No Comments »

I was attempting to create a database for a new project which just contained entities – I had imported the entity classes from Enterprise Architect and added the required annotations, getters & setters etc.

My first attempt used the following persistence.xml (I have removed most of the classes for the example)

<?xml version=”1.0″ encoding=”UTF-8″?>
<persistence version=”2.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_2_0.xsd”>
    
    <persistence-unit name=”Test” transaction-type=”RESOURCE_LOCAL”>
      <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>

      <non-jta-data-source>jdbc/TestPool</non-jta-data-source>
      <class>uk.co.salientsoft.Test.domain.Address</class>
      <class>uk.co.salientsoft.Test.domain.AddressLine</class>
      <class>uk.co.salientsoft.Test.domain.Campaign</class>
      <class>uk.co.salientsoft.Test.domain.CampaignText</class>      
      <exclude-unlisted-classes>false</exclude-unlisted-classes>     
      <properties>
       <property name=”eclipselink.logging.level” value=”INFO” />
       <property name=”eclipselink.target-server” value=”None” />
       <!– <property name=”eclipselink.target-server” value=”SunAS9″ />–>
       <property name=”eclipselink.target-database” value=”Oracle” />      
       <property name=”eclipselink.ddl-generation.output-mode” value=”database” />
      </properties>
     </persistence-unit>
</persistence>

 Having created the database and validated the connection/datasource etc., I attempted to create the tables from  Eclipse by right clicking the project and selecting JPA Tools/Create Tables from Entities…

This resulted in the following error:-

[EL Config]: Connection(5226838)–connecting(DatabaseLogin(
    platform=>OraclePlatform
    user name=> “Test”
    connector=>JNDIConnector datasource name=>jdbc/TestPool
))
[EL Severe]: Local Exception Stack:
Exception [EclipseLink-7060] (Eclipse Persistence Services – 2.0.1.v20100213-r6600): org.eclipse.persistence.exceptions.ValidationException
Exception Description: Cannot acquire data source [jdbc/TestPool].
Internal Exception: javax.naming.NoInitialContextException: Need to specify class name in environment or system property, or as an applet parameter, or in an application resource file:  java.naming.factory.initial

The error occurred even though the data source was being used outside the container as a non-jta data source (this worked previously for JPA1/Glassfish V2, allowing JPA to be used outside the container but still using a datasource defined in Glassfish). A previous post here (in the section Notes on Persistence.xml) also reports that when running outside the container, it is vital to have eclipselink.target-server defaulted or set to none. In this case, the setting caused no difference either way. After a fair bit of research/Googling, I could not find the cause of the problem, so I simply reverted to specifying the connection explicitly in persistence.xml,  without using the connection defined in Glassfish at all.

This worked correctly. I will not need to create the database very often, and it only involved tweaking a few lines in the file, so I’m happy to live with it. Here is my modified persistence.xml which uses a direct connection specified in the file. This version created the database correctly. Note that as detailed in this post here (near the bottom of the post), the property names for JDBC url, user, password and driver have now been standardised and are no longer eclipslink specific.

<?xml version=”1.0″ encoding=”UTF-8″?>
<persistence version=”2.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_2_0.xsd”>

    <persistence-unit name=”Test” transaction-type=”RESOURCE_LOCAL”>   
    <!– <persistence-unit name=”Test” transaction-type=”JTA”>–>
   
      <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>

     <!–<jta-data-source>jdbc/TestPool</jta-data-source>–>
     <!–<non-jta-data-source>jdbc/TestPool</non-jta-data-source>–>
    
      <class>uk.co.salientsoft.Test.domain.Address</class>
      <class>uk.co.salientsoft.Test.domain.AddressLine</class>
      <class>uk.co.salientsoft.Test.domain.Campaign</class>
      <class>uk.co.salientsoft.Test.domain.CampaignText</class>      
      <exclude-unlisted-classes>false</exclude-unlisted-classes>     
      <properties> 
      
        <property name=”javax.persistence.jdbc.url” value=”jdbc:oracle:thin:@localhost:1521:xe”/>     
        <property name=”javax.persistence.jdbc.user” value=”Test”/>
        <property name=”javax.persistence.jdbc.password” value=”Test”/>
        <property name=”javax.persistence.jdbc.driver” value=”oracle.jdbc.OracleDriver”/>     
     
       <property name=”eclipselink.logging.level” value=”INFO” />
        <property name=”eclipselink.target-server” value=”None” />
       <!– <property name=”eclipselink.target-server” value=”SunAS9″ />–>
       <property name=”eclipselink.target-database” value=”Oracle” />      
       <property name=”eclipselink.ddl-generation.output-mode” value=”database” />
      </properties>
     </persistence-unit>
</persistence>

No Comments »

Update

Another post here describes how to enable and control logging when using the Tomcat Server Adapter, as it is not enabled by default. As a result, I changed my thinking and have switched to using the Workspace Metadata to store the server configuration (as detailed below). This allows more convenient editing of the logging.properties file in Eclipse, and also allows a separate Tomcat configuration for each Eclipse Workspace. I have not experienced any corruption/pollution issues from working this way.

Original Post

I use this a lot for prototyping as it is significantly faster for deployment and has less overhead than Glassfish. I run JSF/ICEfaces/JPA applications by running JPA outside the container – see here for more details.

When running Tomcat inside Eclipse, it runs within its own context, i.e. separately from the installed Tomcat Server. Therefore, you should stop Tomcat externally when using it internally via Eclipse’s Tomcat Server Adapter.

You can use the adapter by right clicking in the Server view and clicking on New, then choosing the appropriate version of the Apache Tomcat adapter, browsing for the installation directory for Tomcat in the process.

When using this, you have 3 choices as to where the applications deployed to Tomcat are stored, all of which may be chosen by opening the Server Window for your Tomcat Server in Eclipse. As I point out here, there is often some ambiguity between which properties you change from the properties context menu option (resulting in a popup), and which are from the Server view via the Open option (also obtained by double clicking the server entry in the server view). In this case, the 3 choices are listed under the Server view (Open/double click option), but they are typically shown disabled and it is not always consistent as to how to enable the selections. Firstly stop all running applications on the server, and stop the server. Secondly, clear out any applications from the server by using the Clean context menu option, and/or visiting the Modules tab in the Server view and removing all applications there. You can also click the Switch Location button on the properties context menu popup. You will also need to refresh/reopen the Server view window to ensure that changes are picked up. Once you have reached the point where the the server locations are modifiable, you have the following choices :-

1. Workspace Metadata (does not modify Tomcat Installation)
2. Use Tomcat Installation (takes control of Tomcat Installation)
3. Use Custom Location (does not modify Tomcat Installation) :-
   Server Path: Top level location for all the deployed apps and other Tomcat metadata
   Deploy Path: Subfolder under the Server Path, where the apps sit – defaults to wtpwebapps

My preference is 3. – I like to avoid polluting the main Tomcat installation with Eclipse development stuff, as I can then use it for other purposes. Also, I like to avoid storing the Tomcat applications in the Eclipse workspace metadata. The metadata is cluttered enough as it is, and is sometimes prone to pollution and problems with Eclipse not starting (see here). I therefore like to keep this data in a custom location separate from both the Metadata and the Tomcat installation, but as part of a folder structure which includes the workspaces. I also include any libraries which are shared between workspaces (e.g. JSF/ICEfaces plugins) in the same structure. See here for details about sharing downloaded plugin libraries across multiple workspaces by exporting/importing Eclipse preferences.

My typical folder structure might be as follows :-

Dev (top level (sub)folder somewhere)
Tomcat (custom Tomcat apps location as above)
webapps (my preferred setting for the Deploy Path: above)
Libraries (Top level for libraries shared between workspaces, such as JSF/ICEfaces plugin libraries)
Workspaces (All Eclipse workspaces live under here)
Workspace 1
Project 1
Project 2
Project 3
Workspace 2
Project 4
Project 5

No Comments »

Update 6/7/2011

I hit this problem again when accidentally ignoring the Eclipse warning.
This time, the problem prevented <c:if> tags from working correctly – the tags always tested as true. This was especially nasty as the cause did not appear related to the problem I was having. See this issue in Mantis about the problem.

Original Post

I was using the following namespace declaration in order to use JSTL (c:if etc.) on a Facelets/JSF 2.0 page, as I had done successfully previously under JSF 1.2:-

xmlns:c=”http://java.sun.com/jstl/core“

This gave rise to the following warning in Eclipse:-

NLS missing message: CANNOT_FIND_FACELET_TAGLIB in: org.eclipse.jst.jsf.core.validation.internal.facelet.messages

The namespace is incorrect, and as pointed out here (in Ryan Lubke’s comment on the post) should now be:-

xmlns:c=”http://java.sun.com/jsp/jstl/core“

This fixed the problem. A complete listing of the namespaces for the tag libraries is also available in edition 3 of Core JavaServer Faces, at the start of Chapter 4, page 101 – (edition 2 did not have this table; it is a useful addition).

No Comments »

I recreated a new simple JSF application from scratch, in the end making it identical to an existing one that worked.
Each time I ran it on Glassfish 3.0.1 from Eclipse, it displayed a blank page as if not being sent to the faces servlet.
I checked every detail in making the apps identical – checking every configuration file and the xhtml page.
I cleaned and republished to Glassfish, but still no joy.

In the end I did a detailed examination of the deployment folders under the Glassfish domain (Eclipse deploys its apps under domain1\eclipseApps\ assuming you are using the default domain of domain1). I discovered that the Primefaces jar, primefaces-2.2M1.jar had not been deployed, even though the library was added and the web deployment assembly page had an entry for it.

I tried explicitly removing the app from Glassfish by using the Add and Remove… option on Eclipse’s server context menu for the Glassfish server, and then adding it back. This time, the deployment folders were correct and the library was deployed correctly. The application then ran correctly and displayed the page.

The lesson from this is that deployment to Glassfish 3.0.1 from Helios can be flakey, and just using a clean in Eclipse is not always enough to really clean out any issues. Removing the app and re-adding may be needed. If there is any strange behaviour, the deployment folders under the Glassfish domain should be examined early on to check that everything did in fact deploy – sometimes Eclipse will say it is all ‘synchronised’ when it may not be, and you will not always get smoking gun errors to lead you to the problem!

No Comments »

I have experimented with the following techniques for managing user defined collections of library jars in a Java EE 6 web application within Eclipse Helios. Much of this follows from this chapter in Eclipse Distilled:-

1. An interesting method described in “Eclipse Distilled” is to use a local simple project in the workspace as a library project just to hold eclipse folders to plant the jar collections in. This then allows all other projects in the workspace to reference the jars using relative workspace references, which gives complete portability to the workspace across different locations and operating systems. It does not however allow the library collections to be designated via a single name in the way that user libraries do – you end up with a just a pile of jars on the build path of a referencing project. You can however at least add them all at once via multi select of the jars from a folder in the library project.
2. Another way is to use User Libraries, again as in the above chapter. They have the benefit of allowing a single name to designate the collection of jars, they can be used from anywhere in the workspace, and they can also be exported and imported between workspaces along with other workspace settings. The drawback is that the library location must be defined as an absolute file system location, which means that unlike the above method, you can’t just copy a workspace with all the libraries in it to somewhere completely different and have it ‘just work’ – you have to set up the library locations. However, you also have to typically do this for JSF and JRE libraries, so unless you have a lot of them it is not such a chore.
3. Another mechanism is to use eclipse Classpath Variables, which allow a folder location in the filesystem to be defined and then used via a name. Again, the definitions need to be set up on each different system/location that you migrate the workspace to.
4. Classpath Containers are a dynamic form of reference where a named reference is intercepted by code in a class. This is used by plugins, and allows the definition to change dynamically in response to other environmental changes detected by the plugin code.

On balance, in the absence of a plugin/Classpath Container approach, my favoured option is to use User Libraries for tools like Primefaces as they are convenient and look tidy on the build path even when it gets large. In an ideal world, it would be helpful if User Libraries allowed workspace relative references. This would permit the libraries to be packaged within the workspace which would mean no setup is needed to port the workspace. The downside is that when multiple workspaces are used, you end up with library duplication unless you use an absolute location outside the workspaces. However, you could have a libraries folder under a parent folder above all the workspaces. Then if a relative reference like ..\libraries was permitted you get your cake and eat it – no duplication and a portable collection of workspaces with a single copy of all the associated libraries.

However for now, it’s User Libraries for me. To create a User Library for a project in Eclipse, do the following :-

1. Select project properties/build path/Configure build path, then select the Libraries tab in the right hand pane.
2. Click Add Library…, select User Libraries, and hit Next.
3. Click User Libraries… which will display the User libraries page.
4. Click New to add a library, then add jar(s) to it with Add Jars…
5. Having added a jar, you can expand its definition using the tree control in the middle pane, and then double click on javadoc location, and/or Source attachment to add a jar or zip containing the javadocs/source for the jar.
6. The library is then accessible from all the projects in your Workspace. You can export it to other workspaces by using File/Export/Preferences.
7. Note that typically you need to tell Eclipse to deploy the libraries to WEB-INF\lib when deploying. Under Eclipse Helios, you do this using the Deployment Assembly options page under the project properties, adding an entry for each library you need deploying. When adding, you can elect to add from the java build path, which makes the most sense if you are deploying libraries you have added to the build path. Note that in previous versions of Eclipse, this option on the project properties was designated J2EE Module Dependencies.

No Comments »

This follows on from this post which detailed my previous development stack based on ICEfaces and Glassfish V2.1.

This new stack uses Primefaces, which I now prefer to ICEfaces, for the following reasons (in no particular order):-

1. It has a JSF2 full release – ICEfaces is still only in Beta for JSF2 (as is richFaces)
2. According to various reviews, it is simpler and more lightweight – this may also be a factor contributing to it being further ahead in JSF2 support.
3. It has fuller functionality as standard – with ICEfaces you need to subscribe to the commercial paid version to get some enhanced features such as the treetable.
4. Like ICEfaces, it has a very clean and modern look and feel out of the box with minimal effort. It comes with many themes out of the box, and new themes may be constructed easily online via themeroller, with minimal CSS knowledge. The Primefaces CSS is structured to global theme skinning CSS from component specific CSS.
5. The transparent AJAX bridge of ICEfaces was a compelling feature, as it gave completely transparent partial rendering, although at the expense of resources/performance due to the need for a replica DOM tree in the server which had to be kept in synch. However the new AJAX features of JSF2 perform this in a new way which is also now standard.
6. It has a related component library, Touchfaces, which supports webkit based mobile browsers – widely compatible mobile support will be an important requirement for me.

The following operations should be performed :-

1. Download and install the chosen Java SE JDK
2. Download and install Glassfish V3.0.1 (in my case, the Web profile edition,as it is lighter, I don’t need the full EE feature set and can upgrade incrementally as required). Eclipse has a plugin for, and therefore a dependency on, Glassfish so we do the latter first.
3. Download and install Eclipse (in my case, Eclipse Helios for Java EE, which includes Java EE 6, Eclipselink and all the web tools.
4. Install the Glassfish Plugin for Eclipse (note the updated workaround for Helios), then create a new server for it in Eclipse – right click in the server view then select new and follow the wizard instructions. Note that by default, Eclipse Helios appears to configure the default JVM using the separate JRE (installed by default by the JDK kit) rather than the JDK, even though the JDK was installed. The Glassfish adapter complains about this JRE as it needs a JDK based one. You can just add an additional one for the JDK, and point the server create wizard at it, as detailed here
5. Download and install Primefaces and its documentation. Primefaces is installed manually – I just download the jar to e.g. <workspace>\libraries\primefaces-2.2M1. I then create it as a User Library as detailed here. If you open a web page with the Eclipse web page editor, and display the palette, you will find all the Primefaces components under the http://primefaces.prime.com/tr/ui pallet entry (there may be other palette entries with the name primefaces which may be empty, and should be ignored). Code/tag completion for the components should all work correctly.
6. Download Tomcat if required. I use this for some projects that need a servlet container but not Java EE. I have in the past used the windows service installer version, which is a self installing .exe and installs/runs Tomcat as a service. However note that this does not work under Windows 64-bit if you are using a 32 bit JVM. See here for a manual install process from the zip kit to give you all the functionality of the windows installer version, including run as a service, configuration utility, and system tray monitor/utility.

Comments and issues when test driving the resulting installation:-

• The new Glassfish V3 is fully OSGI compliant, as is Eclipse, so the old issues about Eclipse losing sync as to whether Glassfish was started or not are a thing of the past. However, Eclipse would not use the configured Glassfish admin username/password, and always asked for username and password on startup. It also gave the impression that Eclipse was occasionally losing sync and did not detect properly that Glassfish had already been started externally. This can be avoided by setting Glassfish to have a null password. When I did this, Eclipse never asked for credentials and always seemed to sync with it properly. As this was a dev workstation with no inbound external access and a dev/test install of Glassfish, I was quite happy to run it without a password.
• I imported the Primefaces Component Showcase .war file directly into Eclipse as a test to play around with. This ran fine, but initially any changes to the Java code did not deploy to Glassfish. It turned out that the code folders as loaded were not under the src folder where Eclipse was expecting them, so the auto build process was not compiling them. I just moved all the source up to where Eclipse was expecting them – it already had a set of empty packages there so I just dragged all the source files in the project explorer from where it originally was into the appropriate matching empty packages and all was well. Eclipse then compiled and deployed any Java changes I made correctly.
• Glassfish 3 is supposed to start much faster than 2.1, it did not feel much faster but I did not do any testing on this. However, the new hot deployment on Glassfish 3 was good. I made some simple changes with the Primefaces component showcase, saved them and then did a republish. Some changes e.g. to xhtml files deployed almost instantly. Some java code changes that had larger scale impact took several seconds but were still hot deployed successfully. With Glassfish 2.1, I had found that the integration with Eclipse was a bit hit and miss – sometimes changes would hot deploy, but quite often things just got a bit sick/out of sync as already stated and Glassfish would need restarting, which was always the slow thing. This is why in the end I stuck with Tomcat for dev testing etc. as even though code changes triggered a restart, the start time was so much faster. I’m hoping for better things with Glassfish V3 and the reports I have seen are positive but will need to try it in anger for a while.

No Comments »

I had an Eclipse Galileo workspace containing several projects, and for some reason some of the projects did not show a full palette of components when opening a jspx file using the Web Page Editor. The main culprit was the ICEfaces components set which was missing. The workspace as a whole was clearly OK, but some projects had become broken. I now believe that some changes I made to user library locations may have caused the problem, but not sure on this.

Firstly, I visited the JSF project facets screen by right clicking the project in the explorer and selecting Properties to open the project properties page, then opening the  Project Facets entry in the left hand pane. I removed (unticked) support for ICEfaces and saved the changes. Then I added it back and saved again. This did not fix the problem.

I looked at the JSF Tag Registry view which lists all the Tag libraries registered for a project. This can be displayed by clicking menu option Window/Show View/Other and then entering Tag in the search box at the top. Select Tag Registry under JSF and the view will open. You must select the desired project in the view as it does not default to the current project. You can then expand the entries to see the Tag libraries registered. If you select one of the top level nodes on the registry tree (in my case these were labelled Facelet Tag Registry and JSP Tag registry) you can click the refresh button adjacent to the project selection button. This refreshes the entries, and you can elect whether or not to flush the cache in the resulting dialog. Unfortunately it was of no help to me in fixing the above problem, and refreshing/clearing the cache did not clear the issue. However, this view could be useful to browse Tag Library registrations.

I was aware that the palette entries are driven by the available Tag libraries on the project Build path, so still felt that it was library related. I then revisited the project properties page, and this time expanded the Project Facets entry in the left pane rather than clicking on it. I then selected Java Server Faces. This listed the user libraries for the project in the right hand pane, including all of the ICEfaces and JSF ones. I deselected all but one of them (you cannot deselect all of them), leaving the JSF 1.2 (Sun RI) library selected. I then applied/saved the changes and closed the screen. I then re-opened it, selected all the originally selected libraries and applied/saved again. This time, when I opened a jspx file in the project with the Web Page Editor, the ICEfaces components were present on the palette.

One last glitch was that after doing this, the palette entries for ICEfaces only had icons present, no descriptions. I then  closed the web page editor window, and closed Eclipse down normally, and re-opened the same workspace in Eclipse again. I then re-opened the same jspx in the Web Page Editor, and this time the ICEfaces components were all present with both the Icons and the descriptions. Problem solved!

No Comments »

Eclipse can compare  a pair of open files. It is not obvious how to do this however.

All you need to do is select the first file in the project/package explorer, then ctrl/select the second file so that both are selected. If you then right click, you can select Compare To/Each Other and a new differences view is created.

You can also select a single file, and compare to another version in CVS by selecting Compare To/Another Branch or Version

This post also discusses the technique.

No Comments »