Salient Soft

There are 2 competing issues here – you want to cache for example javascript and css files on the client for speed, but you want to flush the cache and update them when you release new software versions.

An interesting discussion on this, detailing the use of the web.xml parameter javax.faces.PROJECT_STAGE and its control of caching, may be found on the Primefaces forum here.

There are some more links on this and discussion on my issue raised for this on Mantis here.

No Comments »

Update 6/7/2011

There appear to be major issues with the design of retargeting when using it in nested composite components – it fundamentally does not work. See this JSF JIRA issue here for details on this. There is quite a robust debate in the comments on the post as to whether to deprecate and redesign retargeting completely, but it looks like that will not happen.

Original Post

This is very much an undocumented feature of JSF 2, but it is possible for the action method for a command component such as a button or link to be passed in to the CC by its client.

You might think that you can just pass in a method expression string as an attribute and use that attribute within the CC on the action attribute of a button, but this fails as there is more that needs to go on behind the scenes. To make it work, you use the targets= attribute when declaring the action attribute on the CCs interface using composite:attribute – note that the attribute in the CC interface must be called action.

This is discussed in a comment (by Cay Horstmann no less) in this StackOverflow post here.

Note that according to the link here from the above post, you can also retarget actionListeners, validators and valueChangeListeners in the same way. In these cases, the attribute name must be called actionListener, validator or valueChangeListener respectively in the same manner as is done with action above. Check the link out for full details – its not exactly clear on its own but it is easier to understand once you have the concepts from Cay Horstmann’s post above.

No Comments »

Update

The original post below mentioned at the beginning #{cc.attrs.clientId}. Whilst this does work and is mentioned on the net, the correct form is #{cc.clientId}. I have amended accordingly.

Original Post

This post here is an IBM Developerworks post on CC best practice. Some comments/observations follow:-

1. Wrap a cc in a div (NOT a panelgroup) and give it id=“#{cc.attrs.clientId }” “#{cc.clientId }” to give it the ID given to the actual composite. Note that if you use a div, it will NOT be given the CC’s Nameingcontainer prefix (and hence will not have the “double ID” issue whereby it prefixes the ID you specify with the naming container prefix again).
2. You cannot specify an h:panelGroup inside a CC without an ID, or the resulting div is not rendered on the page at all.
3. The id= and rendered= are both ‘standard’ attributes of a CC that you can use by virtue of the fact that a CC is a jsf component – you don’t need to roll your own ‘display=’ attribute for example. This is helpful, as otherwise you would need to wrap a CC in a div in order to give it the CC naming container ID as in 1/, but you would also need to wrap it additionally in an actual h:panelGroup in order to roll your own display= ‘rendered’ style attribute. This may very well be the reason why you get an illegal argument exception if you try to specify your own rendered= attribute on a CC (as per this Mantis issue).
4. cc.id is a built in reference for the CC’s declared ID without any naming container prefixes. cc.clientId is the full monty with all the prefixes. These are analagous to component.id and component.clientId which can be used for any JSF component. Sadly I have not seen any full documentation for the cc or component built in objects.

The second part of the IBM Developerworks article is here. It details how to add Ajax behaviour to a CC, and in particular how to add Ajax behaviour to a component inside a CC from outside. This is useful for less complex CCs, and partners with the other features like retargeting which allows you to pass a listener to a CC which is attached to a component inside the CC.

For more complex CCs, I tend to take a different approach, as follows:-

• I code a controller class in Java for use with the CC, and pass it in as an attribute of the CC (typically controller=). Any behaviour of components inside the CC such as Ajax and listeners are all handled by this controller bean.
• The controller bean is injected by CDI as an @dependent bean, and is typically injected into the page bean which acts as controller for the page. In this way, the lifecycle of the controller is tied to that of its containing bean, which is clear and exactly as it should be.
• As the controller is a dependent bean, CDI allows it to be generic and to use parameterised types (you can only do this for a dependent bean). For example, I have my own breadcrumb control CC (see here) which has its own controller class. This accepts a list of crumbs, where a crumb is a parameterised type for the class.
• A page may have multiple instances of such a CC, in which case it just injects multiple controllers, one per CC that it manages.
• In order to provide event handling, I take a simple approach. A controller just has an event interface which it calls out to in order to pass on any relevant events such as listener or action events. Typically, these will mimic the interface for a listener or action and just pass it on. I generally add an additional argument to the start of all such calls, containing a reference to the controller itself (i.e. the controller passes this in the argument). This is useful in cases where for example the containing page bean itself implements the event interface and handles the events, as where there are multiple components/controllers on a page this argument can be used to determine which one the event was for.
• A key concept with this technique, which works better for more complex cases, is that I am not just exposing internal component behaviour of components in the CC to the outside as you might using JSF retargeting for example. Rather, I am using the controller to provide its own abstraction of the internal behaviour and to provide an external interface which reflects its overall function. In other words, I can map the internal behaviour to the external interface in any way I choose, which gives me much greater control and design flexibility.
• Another approach would be to use a JSF CC Backing Component, as detailed in Core Javaserver Faces on p373. This allows Java behaviour to be added to a CC transparently to the CC’s clients. However, it does involve using some of the JSF internal interfaces that would also be used to develop full blown custom components. In that sense it provides a halfway house to a full custom component implementation. I have deliberately not used this approach in my use cases – the ‘controller’ approach I have outlined is simple and clear, and easy to develop. The controller is not hidden, being declared as a dependent by a calling backing bean, and being passed in to the CC on the facelet page. I feel that in my use cases the visibility, clear lifecycle control, and use of a separate controller instance per component on the page are a benefit and keep things clear and simple.  In design pattern terms, JSF uses the MVC pattern. The JSF components form the view, and my controllers and page beans form the controller. It could be said that a backing component for a CC is part of the view rather than part of the controller, as it uses internal JSF interfaces used by JSF components to implement the view part of the pattern.

No Comments »

This simple line of code does it, by looking up the current directory (“.”) and fetching its canonical path :-

System.out.println(new File(".").getCanonicalPath());

No Comments »

Update 04/10/2011

An essential step was omitted below, which is to clear out the OSGI cache. If you do not do this, and for example manually update Mojarra, the old version will still be loaded from the OSGI cache so your update will not take effect (and probably leave you wondering where glassfish can possibly still be getting the old version from!)

The simple solution is to ensure that you clear the OSGI cache after an update. The cache will be automatically rebuilt by Glassfish.

Simply delete all files in the  <glassfish-root>/glassfish/domains/domain1/osgi-cache/ folder. (Typically this just has a felix  subfolder to be deleted).

This solves the problem.

Original

Glassfish has its updatetool which automatically lists and installs updates from known repositories. You can add to the list of repositories, but they have to be of the type that Glassfish will accept – it will not install from any old download site.

When I wanted to update Mojarra in GF 3.0.1 from 2.0.2 FCS to 2.0.4 FCS with the updatetool, I could not find an update site with that version on.

The alternative (which I did) is to update manually – in this case to stop Glassfish and copy the jsf-api.jar and jsf-impl.jar into the <glassfish-root>\glassfish\modules directory, then restart. The only issue with this is that the new version will not be correctly listed in the installed components under the update tool or in the glassfish administration if you do it manually. However, you can verify that the correct version is running by starting glassfish and one of your web apps running in it, then look in the log for Mojarra and you will see that Mojarra logs its version when it loads. (Be careful if using Notepad++ – I found that its search was unreliable when searching backwards in the log for Mojarra, and it missed the relevant matches.

This can also be done for JPA/Eclipselink. However, the issue with this is that in the update tool it is listed with the name Glassfish JPA, with a different version number to the one used for Eclipselink. It is therefore not possible to work out which version of Eclipselink you are upgrading to. Some of the forums suggest just copying in a later set of Eclipselink OSGI jars but this just does not feel right for OSGI!

The only think I can be certain of is the installed version of Eclipselink with a base version of Glassfish, as this is documented as part of the Glassfish release.

At present I am sticking with the Eclipselink 2.0.2 version that ships with Glassfish, as I have not had any problems with this.

No Comments »