Salient Soft

Update

• One issue to be aware of, which is not immediately obvious, is when populating a database from scripts. If the version column is left null (Eclipselink leaves it as nullable by default), then the null value causes an immediate OptimisticLockException to be thrown. This is because EclipseLink expects and checks for a zero as the initial value for a new record. If EclipseLink itself persists the record, then it writes a zero.
• One good idea to resolve this would be to enforce version columns to be non null with a zero default – although it must be said that it would be helpful if EclipsLink did this automatically in response to the @Version annotation.
• Population scripts should therefore set version to zero, unless it is set non null with a default of zero in JPA – this latter solution is cleaner and would be automatic for me because I create version columns in a mapped superclass used by all Entities. I have yet to test this out however.

Original Post

This follows on from a previous post relating to JPA 1.0/Glassfish 2.1, and contains a few notes and pointers relating to JPA 2.0 under Glassfish 3 with CDI/Weld.

Firstly, when using an EJB from a client, use CDI injection (@Inject) rather than the @EJB annotation, as CDI gives many additional benefits such as type safety.

In an EJB:-

• You are using container managed transactions, and so simply have to inject an entity manager rather than create one from an entity manager factory.
• The container managed entity manager can be injected with a simple @PersistenceContext annotation – the persistence unit name may be defaulted and is discovered automatically.
• The container is responsible for entity manager lifetime/closing. Calling e.g. em.close at the end of a bean method is illegal and will make Glassfish angry. You do not want to make Glassfish angry – you end up with many long stack traces in the log which on the surface do not appear to relate to this trivial problem!

A major issue with container managed transactions is how to use optimistic locking and detect and handle optimistic lock exceptions correctly. This is detailed in Pro JPA 2, pages 355-357 (you can preview this in Google Books). The main problem is that in a server environment, the OptimisticLockException will simply be logged by the container which then throws an EJBException. Trying to catch an OptimisticLockException in the calling client is therefore doomed to failure – it will probably never be caught!

The solution is to call flush() on the entity manger (e.g. em.flush()) just before you are ready to complete the method. This forces a write to the database, locking resources at the end of the method so that the effects on concurrency are minimised. This allows us to handle an optimistic failure while we are still in control, without the container swallowing the exception. The ChangeCollisionException might contain the object which caused the exception, but it is not guarranteed to. If there were multiple objects in the transaction, we could have invoked getEntity() on the caught exception to see whether the offending object was included.

If we do get an exception from the flush() call, we can throw a domain specific application exception which the caller can recognise, i.e. convert an OptimisticLockException to our own ChangeCollisionException, avoiding coupling the caller to the internal semantics of JPA transactions. It is also desirable to factor out the code which calls flush() into our own method, e.g. flushChanges() to avoid the need for every method which needs to flush having to catch the optimistic lock exception and then throw our domain specific one – we can centralise the exception conversion in our own single method.

We must annotate the ChangeCollisionException class with @ApplicationException, which is an EJB container annotation, to indicate to the container that the exception is not really a system level one but should be thrown back to the client as-is. Normally defining an application exception will cause the container not to roll back the transaction, but this is an EJB 3 container notion. The persistence provider that threw the OptimisticLockException  (in this case Eclipselink) does not know about the special semantics of designated application exceptions and, seeing a runtime exception, will go ahead and mark the transaction for rollback. The client can now receive and handle the ChangeCollisionException and do something about it.

Here is an example of our exception class with the required annotation:-

@ApplicationException
public class ChangeCollisionException extends RunTimeException {
   public ChangeCollisionException() {super(); }
}

Here are code fragment examples from a stateless session bean showing the entity manager injection, and a client JSF model bean showing the CDI injection of the stateless session bean. Note that with EJB 3.1 it is not necessary to declare local or remote interfaces for an EJB as business interfaces are not a requirement. However, I always use an interface as it allows for example a mock version of a service layer to be easily swapped in for testing. CDI supports this conveniently via alternatives, whereby a mock version of a bean can be switched in via a setting in beans.xml for testing.

@Stateless
public class SentryServiceImpl implements SentryServiceLocal {

    @PersistenceContext
    private EntityManager em;
…
}

@Named
@Dependent
public class ModelBeanImpl implements ModelBean, Serializable {
    private static final long serialVersionUID = -366401344661990776L;
    private @Inject SentryServiceLocal sentryService;
… 
}

With container managed JPA and/or Glassfish your persistence.xml  can also be simplified, as you can define your data source in Glassfish rather than explicitly in persistence.xml, as described here.

Note that when defining a data source directly in persistence.xml,  some property names have been standardized for JPA 2.0, so have changed from e.g. eclipselink.jdbc.user to javax.persistence.jdbcuser. The following properties in persistence.xml are now standard:-

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

An example persistence.xml used under JPA 2.0 follows:-

<?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="SentryPrototype" transaction-type="JTA">
      <provider>org.eclipse.persistence.jpa.PersistenceProvider</provider>
      <jta-data-source>jdbc/SentryPool</jta-data-source>
      <properties>
       <property name="eclipselink.logging.level" value="INFO" />
       <property name="eclipselink.target-database" value="Oracle" />      
       <property name="eclipselink.ddl-generation.output-mode" value="database" />      
      </properties>
     </persistence-unit>
</persistence>

No Comments »

I originally used display:inline-block, line-height and vertical-align:middle to do this as detailed here, but the results were inconsistent across browsers.

Using floats is a much better solution for a number of reasons – details are as follows:- 

• The controls are floated left inside a div which is itself floated left. As the div is floating, it auto resizes to fit around the content, and so scales to fit unknown control sizes.
• The controls are all set to have fixed top and bottom margins (4px in the example), and the leftmost and rightmost also have similar left and right margins respectively.
• The floated div is set to have the desired border and background etc. – in my case, I use Primefaces/jQuery UI theme style classes to apply theme look and feel.
• The floated div is then placed inside another outer div, which may be of fixed dimensions. This allows the control group to adjust in size, but to be located inside a fixed area on a page.
• If the outer div is of fixed size and non floating, the floating inside it is invisible to the rest of the document, so it is not necessary for example to clear the float.
• If desired, the outer div can be set to overflow:auto to allow scroll bars if the size of the inner floating div exceeds the space allocated for it on the page.
• If the area surrounding the control group is also floating, the outer div can also be set to float with no size specified, so the concept works well in both floating and fixed size situations.
• display:inline-block and vertical-align:middle are not used with this method.

 This mechanism has the following characteristics:-

• The control group bordering works nicely and consistently with the Primefaces/jQuery theme styling, as rather than trying to centre the controls in a fixed border, instead we vary the border size and keep the margin between the controls and the border constant.
• The approach makes use of the laws of Gestalt Psychology – the eye notices even small imperfections in the alignment of the controls and their relationship to the border because they are close and obviously grouped/related.
• Conversely the position of the entire bordered control group within its surroundings (the outer div) will typically not be so critical – it will likely be in a larger area of white space between it and adjacent items,  and so its position and size within that space matters less than the control / border relationship.

A caveat to all this is that it is still not perfect – the simple example below does not perform quite as well in terms of cross browser alignment as the Primefaces/jQuery UI version, as the Primefaces themes apply their own styling as well which changes the situation. This could of course be improved by adjusting the margins individually for different controls in the group to get the best overall cross browser alignment. One very important goal I am trying to acheive is to avoid browser specific CSS. The Primefaces/jQuery UI CSS does in general have browser specific tweaks which will help it in certain situations.

Overall though this approach performs significantly better than the previous method using vertical-align:middle etc. and has the advantage of being fully floating/dynamically sizing if required. An example of this approach follows :-

<!DOCTYPE html>
<html>
<head>
 <style type=”text/css”>
  .ss-outerdiv {
   height: 40px;
   width: 200px;
   background-color: orange;
  } 
  .ss-controlgroup {
   float: left;
   background-color: green;
   border: 1px solid black;
  }
  .ss-select, .ss-leftbutton, .ss-rightbutton {
   margin-top: 4px;
   margin-bottom: 4px;
   float: left;
  }
  .ss-select {
   width: 120px;
     font-family: Arial,Verdana,sans-serif;
     font-size: 11px;    
   margin-left: 4px;
   margin-right: 4px;
  }
  .ss-leftbutton, .ss-rightbutton {
   height: 20px;
   width: 30px;
  }
  .ss-leftbutton  {margin-right: 2px;}
  .ss-rightbutton {margin-right: 4px;}
 </style>
</head>
<body>
<div class=”ss-outerdiv”>
 <div class=”ss-controlgroup”>
  <select class=”ss-select”>
  <option value=”Test”>Test Value</option>
  </select>
  <button class=”ss-leftbutton ss-button”></button>
  <button class=”ss-rightbutton ss-button”></button>
 </div>
</div>
</body>
</html>

No Comments »

This post highlights a few lessons learned whilst experimenting with a simple composite component, in this case an experimental  Primefaces theme switcher component. The component does the following:-

• Automatically iterates the themes directory on the server to build a list of available themes which are presented for the user to select
• Generates a simple theme control panel with a border, consisting of a drop down combo listing the themes, with previous theme/next theme buttons to the right.
• Also allows theme switching via ctrl/shift/left arrow and ctrl/shift/right arrow, to give a quick way of cycling through the themes when choosing one.
• The component is used on the JSF page in two modes – the first usage is with outputStyle=”true”, themeBase and defaultTheme attributes. It is placed in the <head> section, and it defines the base path for all the theme directories, and the default starting theme (which may be programmatically overriden by setting the theme property in its backing bean, themeSwitcherBean). This mode also outputs the link directive to link the current theme stylesheet to the page. It does not result in the display of the control panel.
• The second mode is used inside a <form> on the page, and results in the theme switcher panel being displayed.
• A theme switch results in a form submission, so this must be acceptable to the form logic. If not, i.e. if the form is dirty, the theme switcher must be disabled. This would be done by passing a disable flag attribute to the component, which maps to a disable property of the backing bean, which results in enabling/disabling the controls. At present, a disable feature is not supported.

The following salient points were picked up along the way:-

• The component does not have to be placed in a form. The examples in the Core JavaServer Faces book seemed to always show the client page with the control placed on a form, and also with <form></form> tags present in the custom component implementation. There is absolutely no requirement for the custom component implementation definition to be in its own form.
• With JSF 2.0, it is easy to pass a value e.g. from a composite component attribute in a call, direct to a backing bean property, as JSF 2.0 now supports method expressions with parameters in EL expressions – just add the brackets and the call arguments. This used to be tricky, and many posts on technical blogs just seemed to answer ‘why on earth do you want to’. Well, perhaps it is unusual, but in this example it feels just the right thing. Normally when linking to a style sheet, one would put the path to the sheet directly on the page in the <link> tag, as one also would when referring to other resources such as images. I have therefore done exactly the same with the themeswitcher – you pass the theme base web context path (along with the default theme name) to the component just as you would do to a <link> tag. This then allows the backing bean to discover the physical theme directory location on disk and automatically iterate it to generate a list of the available themes which are present, which is then passed to the select list of the combo. Whilst the theme base context path could be set up as an injected property of the backing bean, it just does not feel right to do it that way, as normally this knowledge is encapsulated on the page. Sometimes, passing values from the page to a bean is actually the right thing to do!
• When using an EL method expression to write to a bean property, note that you can just call a setter on the bean directly as if it was a method, giving the “set” prefix, and passing the value as an argument. You literally just plant the EL call on its own in the middle of the page. (You can of course also use another custom method if you wish, for example if you want to pass a number of properties in a single call). Furthermore, when calling for example a setter or any other method that returns void, nothing is written to the page, as you would expect. In the example code below, the EL expression #{cc.attrs.bean.setThemeBase(cc.attrs.themeBase)} does exactly this.
• A composite component acts as a JSF naming container. Naming containers are required to ensure uniqueness of IDs on a page , by modifying Ids to add a prefix. For example a composite component could be placed many times on a page, and the Ids of all its constituent components/controls must be unique. As a test example, when the above component was placed in the <head> section (i.e. not in a form), its clientId was j_idt4. When placed on the page a second time, in the form to show the control panel , its clientId was frmTest:j_idt9. Notice that by default the clientId was automatically prefixed by the form ID. This issue becomes important when Javascript is in use to refer to controls in the component, as the Id given to a control is in turn prefixed by the clientId. For example, when on the form, a select box which was given an Id of cmbTheme actually ended up with an id of frmTest:j_idt9:cmbTheme. This needs to be taken account of in the code. Note that in the Javascript examples in Chapter 9 of Core JavaServer Faces (p369), the form is inside the composite component. This turns things around, as the form ID is then prepended by the clientId of the composite component as the latter is a naming container – our case is different.
• By default a form’s controls have the form id prefixed to their id, as the form is also a naming container. This behaviour can be disabled if desired by adding the attribute prependId=”false” to the form tag, but I did not do this.
• JSTL functionality can be used such as c:if, and for example you can test parameters passed to composite components (cc.attrs.attrname)– the themeswitcher example uses this with the outputStyle attribute to determine whether to output a <link> tag for the theme stylesheet and set the theme base directory/default theme, or whether to output the themeswitcher control panel. The use of c:if in this way is a powerful means of controlling exactly what a custom component renders on the page, and is a useful alternative to using the render property on a component to prevent it being rendered. In addition, it can for example conditionalise the setting of backing bean properties from the page, as is done in the themeswitcher, which could not be done via toggling the render property on components.  In this case, it seemed more convenient and clearer to give two modes to the same component, so that all the design decisions where encapsulated and visible in one place, rather than inventing another component. Other examples of where this might be useful is where a general purpose composite component might be tailorable via its call attributes. For example a table component might have adjacent up/down buttons to allow re-ordering/moving of a block of selected rows, but the re-order capability might not always be needed, so it could be conditionally selected with c:if.
• When using JSTL, there are limitations. As an example, I tried c:set to copy an attribute containing the backing bean reference to another variable, to use later in a subsequent instance of the composite component and save passing it twice. Setting a valueChangeListener using the saved copy of the bean reference gave a run time error and is not supported. However, reading and writing properties on the bean using the saved copy of the reference worked fine.
• Note that other JSTL functions can also be used, e.g. to return the size of a string or list, as noted here.

Comments Off on JSF 2.0 Composite Components

There is a quite a large collection of useful built in icons, such as those used for the table paginator buttons. It is useful to be able to reuse these in your own buttons:-

• It simplifies coding as you don’t need to roll your own icons.
• The Unicode character set has quite an extensive library of symbols (see here for details of how to use numeric unicode references in HTML to access them), and it is at first tempting to use them as they are readily available. The font color used for them will change automatically with your chosen theme, so it seems like you might be home free with minimal effort for buttons with symbols on, by just using them as text labels on a button. However,  you are at the mercy of the theme font stack/Browser font fallback/font rendering as to how well they are represented in a given font. When I tried some of them out the rendering was very poor in some Primefaces themes, and getting them centrally positioned on buttons of various sizes involved some quirky bits of CSS which were dependent on your chosen font size, particularly if you wanted multiple symbols on a button (e.g. 2 triangles to give a double arrow). I decided this was a blind alley and in the end discovered that using the theme icons was better and easier. 
• You don’t need to tweak a set of new ones for each theme. Themeroller may assist with recolouring them for a theme (haven’t used it yet) but even if it does reusing is still easier than running themeroller to tweak every theme.
• It promotes consistency – your own e.g. arrow buttons can have the same look and feel as e.g. the table paginator ones, so as well as making your life easier you have scored points for better user interface design. When a user sees the same icon used consistently in different places this gives a strong visual cue on how the interface works and what to expect.
• Reusing them minimises downloading and caching additional icons.

After quite a bit a bit of experimentation with both commandButtons and commandLinks, and learning about how JQuery (which Primefaces is based on) works,  I came up with the following example page which illustrates how to add a built in theme icon to a commandButton:-

<!DOCTYPE HTML>
<html xmlns=’http://www.w3c.org/1999/xhtml’
   xmlns:f=’http://java.sun.com/jsf/core’
   xmlns:h=’http://java.sun.com/jsf/html’
   xmlns:p=’http://primefaces.prime.com.tr/ui’>
<f:view contentType=’text/html’>
<h:head>
    <link type=”text/css” rel=”stylesheet”
     href=”#{request.contextPath}/themes/cupertino/skin.css” />    
    
    <style type=”text/css”>       
        .ui-widget, .ui-widget .ui-widget {
            font-size: 80% !important;
        }
        .ss-iconbutton {
            height:21px;
            width:30px;
        }
        .ss-spacer {margin-right:4px;}
        .ss-iconbutton-icon {
            background-color: transparent;
            border:none;
        }
    </style>
</h:head>
<h:body>
<h:form>
    <p:commandButton styleClass=”ss-iconbutton ss-spacer” onclick=”alert(‘Previous button clicked’)”
      image=”ss-iconbutton-icon ui-icon ui-icon-seek-prev”/>
    <p:commandButton styleClass=”ss-iconbutton” onclick=”alert(‘Next button clicked’)”
      image=”ss-iconbutton-icon ui-icon ui-icon-seek-next”/>                               
</h:form> 
</h:body>
</f:view>
</html>

Note the following points about the example:-

• The image property of the commandButton accepts a CSS class which loads the icon as a background property. If you inspect one of the command buttons e.g. with Firebug you will note that it applies this class to a <span> tag. The advantage of this is that the icon is defined in theme switched CSS rather than HTML. Note that as is normal when applying CSS classes, multiple classes may be passed as a space separated list as I have done.
• The example uses some of the standard jQueryCSS classes from WebContent/themes/cupertino/skin.css which is the skinning css present for each theme (in this case, the theme used is cupertino).
• Class ui-icon defines and loads an icon file for the theme. The chosen file may be modified by the jQuery state classes such as ui-state-default, ui-state-disabled, ui-state hover etc. Therefore,the added benefit of using the standard jQuery classes and icon files is that mouse hover automatically causes a switch of icon file to change the colour as determined by the theme, and things like enable/disable of the button also have the correct effect. In short – it all just works as it should with no effort if the built-in classes are correctly used.
• A fundamental mechanism used by jQuery for states like hover is to use Javascript functions triggered by the hover/mouseover to dynamically add and remove CSS classes from elements. For example, class ui-state-hover is added and removed on hover. this may be seen within Firebug when you hover over the button with the mouse. Note that therefore jQuery does not only use CSS Pseudo-classes such as :hover, :active to support this as one might expect. Examples of the latter will be found in skin.css  but they do not give the whole picture about what is going on internally. This is presumably done for reasons of browser compatibility as CSS pseudo classes do not work consistently across different element types and browsers (IE is especially limited in this regard).
• Primefaces/jQuery stores multiple icons in a single icon file, and uses the css background-position property with appropriate X and Y pixel coordinates in the file to pick out the desired icon. If an icon file is examined with Windows you will see all the icons store in the file in a matrix fashion. A set of classes is defined in skin.css , one for each icon, to encapsulate the position of that icon within the icon file. In the above example, ui-icon-seek-prev and ui-icon-seek-next have been used to select the next and previous icons used on the dataTable paginator.
• By default, the icon in a commandButton is given a border and a background colour, which in this case we do not want. These are removed by class ss-iconbutton-icon above which is also passed as one of the classes to the image attribute of the commandButton.
• Whilst we are to an extent going “under the hood” and using mechanisms and CSS classes which are not part of the documented Primefaces interface, they are a standard part of jQuery upon which Primefaces is based. When extending a user interface a fashion similar to the above, it is highly recommended to gain familiarity with the workings and operation of jQuery, as this can allow additional functionality to be harmonised with the existing functionality. This will typically make adding functionality easier, promote consistency with the existing feature set, and as in this case can give a number of side benefits for no extra work. Of course, using features that are not part of a formally documented Primefaces interface may mean that your code needs to change with later releases, but in this case, as these are jQuery features, it definitely feels the right way to go.

The jQuery UI web site, which contains full documentation, tutorials and demos,  may be found here. In my opinion it is certainly worth delving into further to augment your understanding of Primefaces, especially when you want to extend or reuse features and components in ways like the above example.

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 »

Update 7/10/2010

I had some further issues when trying to realign the boot partition of an OCZ Vertex 30GB SSD on an Intel D510 dual core atom ‘always on’ silent pc running Windows XP Pro.
I tried the technique used before below, using diskpar to create the partition and then using Acronis True Image 2010 to restore first the NTFS partition, then restoring the MBR and track 0 as a second subsequent operation. In order run diskpar standalone, I created a bootable CD containing diskpar using Bart PE, as I found that booting a Windows XP CD into recovery mode does not give you full command prompt capabilities – you cannot run an arbitrary .EXE utility at all (a real surprise to learn) – you can only use the commands listed. All this was done as below (see here) so as to force Acronis to re-use the partition created by diskpar. Unfortunately allthough the process went smoothly the resulting system would not boot, citing NTLDR/boot loader problems.

I then upgraded to Acronis True Image Home 2011 and also Acronis Disk Director 11, as these were both supposed to be SSD friendly and handle the alignment correctly. I deleted the partition and restored the original backup with the incorrect alignment, allowing Acronis to create the partition itself, and the system booted fine as before. I then used Disk Director to slightly shrink the partition to ensure that there was space to allow it to realign – there should have been a few MB on the end anyway, but I shrank it by 100MB to be really sure.

I then did a full standalone backup of the system disk with the shrunken partition. I found that just restoring that backup (shrunken but with the wrong alignment) with True Image 2011 was not enough – the incorrect alignment was still present on the SSD, i.e. it appeared that True Image always gives priority to the partition details in the backup. In hindsight it may have been possible to override the partition settings during the restore to cause Acronis to fix the alignment by using ‘new’ partition settings but I did not try – if so, this might have fixed the alignment problem in one go.

However, Disk Director 11 was able to delete and then recreate the partition correctly, i.e. when it created a new partition on the SSD it automatically used the correct alignment (1048576 bytes or 1MB), as confirmed afterwards by diskpar. I created a partition to fill the disk, as I knew that True Image would happily restore the slightly smaller shrunken one to a larger one. I then used the same technique as above with True Image Home 2011, i.e. restore the NTFS partition first without the MBR and track 0, then restore MBR and track 0 as a second operation after the restore.

This time, it all worked fine and I ended up with a bootable system with the correct partition alignment. I’m not sure what the issue was – perhaps the shrinking first fixed it. I do know that this technique has worked fine for me previously as below, when I backed up a 2.5" laptop hard drive via Acronis True Image, created an aligned partition on a new SSD with diskpar, and then restored the backup to the SSD with the same trick.

The resulting lessons learned seem to be as follows:-

1. Use Disk Director 11 with SSDs, alignment will be correct, and you can easily do it standalone by creating a Disk Director boot CD.
2. Using True Image 2011 is also recommended – it is stated to be SSD friendly and is better all around.
3. However, care is needed when restoring an SSD backup with the wrong alignment, as by default even True Image 2011 keeps the wrong alignment. Either the technique above is needed or it may be possible to get Acronis to use ‘new’ partition settings to override the ones in the backup, in which case the restore can all be done in a single step.
4. to be safe, when correcting wrong SSD alignment, shrink partition first by say a few 10s of MB to be sure (I used 100MB) to ensure there is no funny truncation when it is restored and realigned.

I have not done any performance comparisons before and after the realignment, but have confirmed that the alignment is now correct. Whilst I have seen posts on the internet that suggest lower alignment values than 1MB, both Windows 7 when it installs to an SSD, and Disk Director 11 use 1MB (1048576 bytes), so I am sticking with this value.

Original Post

Partition alignment is important for SSD performance to avoid unnecessary read/write cycles. Windows 7 appears to handle this but Windows XP does not. The partition alignment must be set manually when creating it (with diskpar or diskpart – diskpar seems to be preferred as it displays the partition offset in bytes so that the resulting offset can be accurately seen, even though diskpart is newer and has more features)

When restoring or cloning disks with Acronis True Image Home 2010, the original partition alignment is kept providing the operation does not recreate the partitions. See the Acronis forums here for details.

The OCZ forums have some articles on how to create correctly aligned partitions here and here.

Another step by step guide to cloning to an SSD with Acronis may be found here. When doing this, do not (as I did) forget the step which says to set the restore partition as primary and active in Acronis! In my case, Acronis made the wrong partition active so the SSD would not boot. It was simple enough to change – boot a system which can see the disk, then use disk management, right click the correct boot partition and select set as active. It is not necessary to repartition the SSD and re-restore the Acronis backup.

A good balanced article about optimising Windows XP for SSD use is here. There is a lot of misinformation around for example about the performance effects of swap files, which is based on misunderstandings about windows swap file usage, and also based on older SSDs with short service lives. The more informed wisdom appears to say that you should not disable the swap file as it will not make a significant difference.

No Comments »

Much of this has already been covered here, but I am posting these somewhat raw notes from an earlier investigative email as they include one or two links and points not covered elsewhere. I don’t have the time or inclination at present to rework everything into an existing post :-

1/ For local beans, you can just use defaults in @Stateless (in the bean) and in @EJB (in the referring code)
Note that when you do not use all the defaults, you must declare both the beaninterface and the name attributes

@EJB(name=”ejb/JPAGlassFishIce/SimpleBean”, beanInterface=SimpleBeanLocal.class)
private SimpleBean simpleBean;
2/ For remote beans, you can use e.g.

@Stateless(mappedName=”ejb/JPAGlassFishIceEJB/SimpleBean”)

Then

@EJB(beanInterface=SimpleBeanRemote.class, mappedName=”ejb/JPAGlassFishIceEJB/SimpleBean”)
private SimpleBean simpleBean;

Note – you must pass the class of the remote interface as above or it will not work, and you just get name not found exception.

3/ The above methods work for both access from one bean to another, and from a JSF managed bean to a remote (or local) bean
It also works from any POJO called from e.g. a JSF manged bean.
Note that this ability is container specific – Glassfish does it, other containers may vary in what/if/how they support.

4/ If doing JNDI lookups yourself to a local bean (via context.lookup), you need to add <ejb-local-ref> to web.xml as follows :-

 <ejb-local-ref>
    <ejb-ref-name>ejb/JPAGlassFishIce/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>

This would be used if using e.g. Spring or a custom EL resolver  to inject references into JSF managed beans (via JSF DI)

Note that the JNDI name for the above local reference would be
“java:comp/env/ejb/JPAGlassFishIce/SimpleBean”
i.e. this is picking up from the <ejb-ref-name> above, and is prefixed java:comp/env
java:comp/env is a reference to the JNDI “Environment” service provider for Java EE
you can also use this  to look up environment variables etc.
see here http://java.sun.com/developer/technicalArticles/xml/WebAppDev4/

The <ejb-local-ref> stuff is done for you automatically if you use @EJB

5/ Note that JNDI names are container specific at present (fixed in java ee6)
See here for a good SUN post on all the EJB reference stuff :-
https://glassfish.dev.java.net/javaee5/ejb/EJB_FAQ.html

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 »

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 »