Salient Soft

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 »

CDI stands for Context and Dependency Injection, and is the standard for Java EE 6, being an important part of the Java EE 6 stack. The reference implementation of CDI is JBoss Weld. Full details including documentation downloads for Weld, may be found here.

Here are some initial pointers/gotchas when starting out with CDI:-

• Any bean which is @SessionScoped or @ConversationScoped must be serializable. If you do not obey this rule you get an error when trying to deploy your application. The easiest way to do this in Eclipse is to implement Serializable. This will give a warning about the need to declare serialVersionUID.Just right click the warning and pick quick fix. You will have the choice of a default serialVersionUID or a generated one. Normally you would want to use a generated one, which Eclipse will do automatically for you when you pick the option. (You can also use a Java command line tool to do it but there is no point as Eclipse is easier). This post here gives more details about SerialVersionUID and serialization.
• Any bean which uses parameterised types (i.e. generics) in its interface must be declared as @Dependent, i.e. it is only used and referenced from one client bean and its lifetime is dependent on the lifetime of that client bean – it is created when the client bean is created, and destroyed when it is destroyed. If you do not obey this rule you get an error when trying to deploy your application. An example of this situation might be a generic table bean which returns a list of rows of a generic type <E>, e.g. @Dependent public class TableBean<E> implements Serializable. This makes sense if you think about it – if it returns a generic type, it cannot be instantiated in isolation as it is the creating client which determines the actual type returned. Remember in this regard that CDI performs type safe injection in order to pick up as many errors as possible at compile time. Therefore, taking an example of our table bean, a consequence of this is that the table bean cannot be referred to directly from a JSF page. This is not the issue that it might appear. In practice, the table bean will be created by a client backing bean for the page. For example, a UserCredentials.jsf page might contain several tables, each backed by a different TableBean. The page will have its own backing bean, for example UserCredentialsBean, which will hold the backing state for the whole page. When referring to a table on the JSF page, it will always be referred to via the page backing bean, for example userCredentials.rightTable.rows. This is what you would naturally do anyway, and referring to the dependent bean via a property of its ‘owning’ parent if perfectly correct and does not violate any CDI rules. Note that it is also perfectly correct to assign such a reference to a JSF table value attribute for use in the table, and to then use the shorthand name assigned to the var attribute to refer to the bean. This is also fine and does not break any rules.
• When referencing an EJB from a JSF backing bean, you should always use CDI annotations rather than the older @EJB ones, as the CDI ones are typesafe and allow all the additional flexibility of CDI, such as alternatives for swapping in mock test versions of EJBs by adding settings in beans.xml. An example of injecting a local EJB into a backing bean might be  private @Inject SentryServiceLocal sentryService; assuming that SentryServiceLocal is the local interface for the EJB.
• Given the choice, you should always use CDI for preference rather than a legacy feature. For example, JSF managed beans are still available for backwards compatibility in JSF (and even have some new features for JSF 2.0). However, you should ignore these and use CDI instead as it offers superior flexibility and type safety. Using CDI across the board gives additional benefits such as when grouping annotations using Stereotypes.

No Comments »

Some tips and gotchas on this, as follows :-

1/ the Oracle documentation pages for Javadoc complete with examples etc. may be found here

2/ An example of Javadoc applied to a project may be found in the PropertyTree project in the repository.

3/ JAutodoc is a useful Eclipse plugin. Whilst Eclipse can generate Javadoc comments at source creation time if you tick the box for it, and lets you add them afterwards one by one via ctrl/alt/J etc., using  JAutodoc allows creation, addition or replacement of a full set of Javadoc comments to an entire project at any time. It also has a better stab at guessing comments for properties etc. than Eclipse, by parsing words out of the code. Obviously there is still a lot of manual editing to be done, but I found it a useful addition. Note that JAutodoc is available for a project on the package Explorer context menu for a project, but not on the project explorer one.

4/ Package level documentation sits in package.html in the package source directory. As Javadoc is frames based, the following doctype is recommended by Oracle for this file :- <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Frameset//EN" "http://www.w3.org/TR/html4/frameset.dtd">. Simple html is the order of the day as Javadoc has simple, somewhat retro styling. You can get new style sheets for it to spice it up, but I find the standard ones perfectly readable. Javadoc has its own Stylesheet.css, but I avoided amending this, and deliberately did not add another stylesheet of my own. Therefore, I avoided heavy use of styling, and just borrowed the odd style from the built in stylesheet for my own uses such as table header styling below.

5/ For subheadings in the package doc <h3> and <h4> worked fine.

6/ It was straightforward to add simple tables. Whilst some of the attributes are rather outdated/deprecated in favour of CSS, they are also used elsewhere in the Javadoc for its own tables, so I did not lose sleep over it. I used the TableHeadingColor class from Javadoc’s own stylesheet to give a similar background colour to my own table headers.

<table border="1" cellspacing="1" width="100%">
    <tr class="TableHeadingColor">
        <th>Column 1 Header</th>
        <th>Column 2 Header</th>
    </tr>
    <tr>
        <td>Column 1 data</td>
        <td>Column 1 data</td>
    </tr>
</table>

7/ Styling code samples is a bit messy with several tags being involved. This post here on StackOverflow discusses some of the issues In the end I used the following examples, generally going with what worked well:-

<blockquote><pre>
      PropertyTree propertyTree = new PropertyTree("lan").load("Test.properties");
</pre></blockquote>

or :-

<blockquote><pre>{@code
lan.default.broadcast=10.0.0.255
lan.default.port=7

}</pre></blockquote>

The code tag (“{@code …}” was supposed to be the one to use here (particularly when Generics are involved) but was a bit mixed in its usefulness, and I found some variations in the tabbing, and closing braces in the code can be an issue as the code tag also uses this for its own closure. I did not therefore always use it. Interestingly the above StackOverflow post cites that String.java in the JRE just uses <p><blockquote><pre>,  so I often followed suit.

8/ Individual code or data identifiers such as class and method names looked good in a fixed font when framed with <code></code>, which seemed to be the preferred way to highlight them. Sometimes I made them links as follows, but I did not do this all the time when there was already a link on the comment, as it was tedious and unnecessary. Links can be added, and you can link to a method, a class or a package (which links to package.html) by just linking to the desired level. The first parameter after {@link is the hyperlink, and the second parameter is the clickable description that appears for the hyperlink. Eclipse does code completion for the tags when you are entering them. The following example links to a property (which is specified after the “#”):-

{@link  uk.co.salientsoft.util.propertytree.TagTree#getProperty() TagTree.getProperty()}

9/ One gotcha is that for overriden methods, the Javadoc always comes from the inherited method, and the Javadoc method comments in the subclass are ignored. However, you can add additional comments by using the Javadoc documentation comment syntax (prefixed “/**” i.e. with the extra asterisk on the first line) in the subclass, and these will be added in and not ignored:-

/**
  * For the <code>NullIterator</code> this will always return <code>false</code>.
  */

10/ In Eclipse, you can create Javadoc via the Project/Create Javadoc menu bar option (this is not available on the package explorer context menu). There are a number of options when doing so, but these are not all defaulted to your previous settings when you go back next time round. You can therefore create and save an Ant build file for the Javadoc which you can then re-run much more easily. Javadoc.exe needs to be on the path for this – it should be anyway if you have Java SE installed and on the path, and for me I did not have to add it. You can then open the Ant view in Eclipse. In the view pane, right click and select Add Buildfiles… and browse for the Ant build file which you saved at Javadoc creation time. This then stays pinned to the Ant pane and you can double click it any time to recreate your Javadoc with all the saved settings.

No Comments »

This is a collection of useful notes and post/article references on ideas for a suitable new Java stack:-

http://blogs.sun.com/enterprisetechtips/entry/using_cdi_and_dependency_injection

http://stackoverflow.com/questions/2270379/differences-between-java-ee-6-cdi-implementations

http://docs.jboss.org/weld/reference/1.0.0/en-US/html/environments.html#d0e4910

http://stackoverflow.com/questions/2499323/jee6-vs-spring-3-stack

No Comments »

This post is to explore best practice in this area.

The reason is that I am looking at a stack based on JSF/ICEfaces or PrimeFaces/Tomcat/JPA, as I have a project in mind to run in a hosted environment and Tomcat hosting is easier and cheaper than JBoss/Glassfish hosting.

Spring’s JPATemplate looks useful, but ties you to a Spring standard rather than an open (JPA) one which is vendor independent.

I am always wary when I read in a vendor’s documentation that “such and such an interface abstracts all the other interfaces used by other vendors/standards etc.”
Whilst of course abstraction is a good thing, you do end up tied to the abstraction interface and so need to be aware of the implications of this!

On face value (and I have not explored this at all yet as I am just starting to look at Spring) it seems a backwards step to encapsulate a platform/container independent standard (JPA) which has cross platform support with a platform/container specific one (Spring)?

This post (which I have yet to explore in detail) suggests that it is cleaner not to use Spring’s JPA support classes, which makes sense to me.

The True Way Of Developing Applications has been disturbed and that is damn good. For starters, please take a moment to read these articles in order:

Getting started with JPA and Spring
JPA Annotations Guide (broken link)
Advanced JPA with spring

• What will happen if you do:
• No more need for hibernate mapping files; everything will work from annotations, persistent classes are automagically discovered, and greenfield projects can have the database automatically generated. Controller interceptors can be substituted with Transaction annotations, which is much easier to understand and maintain. Spring will generate interceptors anyway but at least you do not have to be so aware of them.
• No more need of JpaDaoSupport and JpaTemplate. They were a great commodity with JDBC and raw Hibernate, but with JPA it’s cleaner if you do not use the support classes.
• Do not forget to make your test classes extend AbstractJpaTests so that Spring can inject your attributes.

 
I will continue to post links and discusssions here as I explore it in more detail.

No Comments »

This review compares open source UML tools. Unlike a number of other reviews I read, it is fairly recent (02/2009) so well worth a read.  The conclusion is as follows :-

From the perspective of a reviewer with no specific software development project in mind, the most feature-laden option is the Papyrus / Acceleo combination. If your primary IDE is Eclipse, you will benefit from having your modeling software running in the same environment as your active code editor. For Java programmers using Netbeans, the same can said of its modeling tool. BOUML, while superb in its own right, is the vision of a single author and, as such, enterprise development institutions may be hesitant to adopt it. If you don’t mind breaking away from your IDE, give Taylor a test drive.

This Eclipse post gives a comparison of UML Tools which are Eclipse Plugins. I tried several different versions of the Eclipse UML2 plugin, both installing via the update site and with a manual/dropin install, and could not get it to run with my Eclipse galileo installation. I note anyway that it does not yet support code generation, so that rules it out for me as I want to generate class stubs.

Another interesting review from diagramming.org may be found here.

After a long look around at commercial offerings as well, I found that it was all rather a minefield – some products were rough around the edges to say the least, but still trying to command a 4-5 figure sum for purchase!

In the end I found Enterprise Architect from Sparx Systems, and was immediately very impressed. Good reviews on the net, a variety of flavours at reasonable prices. It appears stable and has a very large feature set and extensive documentation. To generate and import Java code (which I want to do), the professional edition is needed as a minimum. This works out at $199 at the time of posting, which translates roughly to £133 – very impressive for a very reasonable price. Support is prompt (they fixed a broken trial version download promptly), forums seem helpful. I’m trialling it at the moment but it is likely that this is what I will go for.

No Comments »