Salient Soft

Update 17/10/2013

This StackOverflow Post here is by David Blevins, EJB 3.1 expert group member among many other things. It confirms my original post below that plain CDI beans can be freely mixed with EJBs etc. and that you use what you need based on the features offered. It confirms that an @ApplicationScoped bean is pretty much an @Singleton but does not have the @Startup capability to run a method when the application starts. There is a javax.inject.Singleton as well as a javax.ejb.Singleton, however this post here points out that javax.inject.Singleton is not part of the official CDI spec. Therefore, it suggests (as does David Blevins in the above post) that you use @ApplicationScoped if you don’t need the special transactional/locking features of @Singleton (javax.ejb.Singleton that is), as it can be a lot faster.

In my case, there are a number of places where I may now end up replacing intermediate @Stateless beans with @Application scoped ones for simplicity and performance.

Original Post

A number of blog posts on this maintain that you need to create an EJB singleton for this, and set it to readonly, perhaps with Transactionattribute  set to unsupported to suspend the transaction whilst in the utility POJO/EJB.

Assuming the utility POJO did no database access and had no transaction involvement, I could see no reason for this. After all, an EJB can create and use an ArrayList for example without having to take any special actions. Why should my utility POJO be any different? In my case, the POJO was using the Apache Base64 encoder to encode an ID in Base64. When I subsequently read the CDI spec for info on this, it came to the rescue. CDI states that you can pretty much inject anything into anything else.

In particular, on P13 of the weld spec, Section 2.2.2 “SessionBeans” it states :-

“You can inject one session bean into another session bean, a managed bean into a session bean, a session bean into a managed bean, have a managed bean observe an event raised by a sessionbean, and so on.”

Therefore, if I just have a plain utility class which has nothing to do with session beans, the DB, or transactions, I can just inject it with CDI and call it from a session bean. I do not have to make it a singleton session bean/with readonly locking/transactions not supported etc.

The restriction would be that unlike session beans it could not be called remotely with all the clever EJB remote stuff, however this is absolutely not required in cases like this, I would just deploy it as a utility library in the local container along with the rest of the application. Each application server would therefore have its own copy.

This finally makes sense. In my case, it also works perfectly well when I inject an application scoped POJO into a stateless session bean.

No Comments »

I passed a styleClass attribute to a facelets decorator using <ui:param>. The decorator in turn used a custom tag which had a styleClass attribute.
I discovered whilst looking in Firebug that the styleClass attribute passed to the decorator was being passed on to the custom tag, even though I had not specified a styleClass attribute on the custom tag. The CSS class name was clearly visible in Firebug.

I’ve investigated this with a test application and have confirmed the following points. I have also logged these points under a Mantis issue here.

Note that this was running on Mojarra 2.0.4 FCS, and I am not clear whether all of these issues are by design or would be considered a bug, and how consistent they are across other versions/JSF implementations:-

1. A ui:param passed say to a decorator is indeed visible via EL in a custom tag called from the decorator. If the custom tag has an attribute of the same name, this will be passed to the tag in preference, but crucially, if the attribute is omitted/defaulted on the tag, the tag will then see the ui:param from the calling decorator.
2. The above issue in 1/ even occurs if the above decorator is changed to be itself a custom tag, and the ui:param instead becomes an attribute of the parent/calling custom tag. In this case, the nested custom tag sees attributes passed to its parent if the same attribute is not explicitly passed to it.
3. Fortunately, if a child custom tag is called with an explicit attribute with the same name as an attribute or ui:param passed to its calling tag or decorator, the value in the calling tag/decorator is not modified. This means that you can call child tags without corrupting state in the calling environment.
4. Point 3/ is also true when a decorator is called with ui:param. If the ui:param has the same name as one used in the caller (either defined there or passed to it), changing the value of the ui:param within the ui:decorate tag to pass it to the decorator does not change the value of the same named parameter outside of the ui:decorate tag.
5. If a child decorator modifies a ui:param passed by its caller, the modified value is visible only within the child decorator. On return to the calling environment, the ui:param value reverts to what was passed to the child by the caller. This indicates that there is scoping going on.

The lessons from this are therefore as follows:-

1. The prime gotcha here is that if you omit an attribute on a custom tag call or a ui:param on a decorator call, a ui:param or attribute value in the caller’s environment will be visible to the called environment exactly as if it was passed in explicitly! You must therefore take great care to ensure that child calls have explicit empty/null attributes or ui:params specified where there is a name clash with one in the calling environment.
2. Attribute values and ui:param values are scoped, and you can safely pass the same named ones with different values to child decorators or custom tags without affecting the values in the calling environment. This is even true when defining a ui:param within a ui:decorate tag – it does not affect the value of a similarly named ui:param outside the ui:decorate tag.
3. Changing the value of a ui:param in a child decorator/tag does not change the value of the same named one in the calling environment. It does however cause the value to change after the point of change in the child environment.

No Comments »

<f:subview> creates a naming container and so may be used to avoid ID collisions on a facelets page. It says in CoreJSF, 3rd edition, that this is not needed for facelets, but as it turns out, I have found a significant use for this.

One of my custom tags is a complex multi table tree browser component, which has lots of optionally included/defined markup. It therefore needs to be a custom tag rather than a composite component, as the latter would not give the required flexibility.

The issue I hit with this is that I use multiple variants of this tree browser on the same page, to browser different tree structured data within my application. The trees are all polymorphic, and indeed share and subclass the same base JSF controller class, as well as re-using the same base custom tag. As there is more than one on a page, I have potential ID collisions, and so to avoid this, using <f:subview> to define a naming container in the custom tag is ideal in this case.

This is helped by the fact that in JSF 2 you can actually pass an ID to a custom tag and define it in the tag in <f:subview> using an EL expression. Whilst this is normally unorthodox and not encouraged, in this case it makes perfect sense – the value does not come from a bean, but is a constant string passed via the attribute.

No Comments »

Update 26/7/2011

Some more points that were omitted or incorrect in the first posting:-

• A handy feature with templates/custom tags is that you can render children of the template/tag at the call site simply by using a <ui:insert> without a name. You therefore do not need to use a <ui:define> tag in this case, and all children which are not contained in other <ui:define> or <ui:param> tags will be rendered as part of this default <ui:insert>
• The statement below that it is not possibly to insert a number of different markup variants in a composite component is incorrect. A composite component can have a number of named facets just like a ‘real’ JSF component, and these allow markup to be inserted in the same way as <ui:insert>/<ui:define> does for a template or custom tag.

Original Post

I had a complex decorator which was used for tree browsing. It had a number of ui:inserts for custom markup, plus also a large number of <ui:params> to define EL parameters used within it.

This all worked fine, and even looked quite tidy as all the <ui:params> were listed one per line below each other. However, it was all rather verbose compared to using a custom tag where you would use attributes instead to pass the EL parameters.

It turns out that you can convert a decorator to be a custom tag with no effort as they operate similarly. You merely need to register the xhtml file in a taglib as with any custom tag, and you can then call exactly the same code as a custom tag instead of a decorator.

The neat tricks here are that:-

• <ui:params> become attributes which are less verbose, but the tag itself does not know any difference and needs no changes.
• <ui:insert>/<ui:define> work perfectly with a custom tag exactly as they do with a decorator.

Another nice point on this is you can develop custom tags that include pseudo ‘child markup’ in similar fashion to composite components, by using the <ui:define>s. Providing you do not need the other features of composite components such as retargeting, Ajax etc., custom tags can be very useful where you have a need to insert a number of different markup variants for different flavours of the tag, as you cannot do this so flexibly with a composite component.

The technique of using <ui:inserts> in a custom tag is hinted at somewhat obliquely in Core Javaserver Faces, 3rd Edition, on P196 in the listing of the planet custom tag, which contains a <ui:insert> called content1.

No Comments »

This utility was developed to allow JSF and Java software to dynamically manage dependency issues caused by interface changes across differing versions of dependant libraries, by querying the utility at runtime with rule based match checks about the versions actually deployed. Typically interfaces to software are consistent for a range of versions, and then change whereupon they remain the same for a further range of versions. The Version
Manager thus allows rule based checks to match a contiguous range of versions, as well as matching a single specific version.

The utility was developed in response to issues caused by changes between Primefaces versions. A particular case in point was that some custom Javascript and CSS was implemented for V2.2.M1 to fix common issues concerning header alignment and column width for scrolling tables. These changes were encapsulated in .css and js files in a TableCC composite component which decorates the standard Primefaces p:dataTable.
These fixes of necessity used css and jQuery selectors referring to underlying Primefaces structural css classes – this exposes such code to risk of change, but in this case the risk was justified as the code was there to fix issues.

The css in Primefaces changed late on in the V2.2 cycle – the class names changed and the HTML was simplified to remove a div container layer. These changes broke the above code. It was felt that this would in general not be an isolated issue. Primefaces is a fast moving development project, which has its upsides in that new features and new versions come onstream regularly. The downside in a fast moving environment can be issues such as the
above one. In fairness to Primefaces, it is very difficult to develop a generic Table component using current HTML standards which allows fixed column headers with a scrolling data table. Some things such as dynamic resizing of columns just cannot play ball in the current scenario, and scroll bars coming and going with different data volumes add further challenges of their own! In practice it is not possible to cover every possible use case. My approach is to narrow down a particular set of use cases I need to work with, and then come up with the necessary fixes/decorator components as above to handle those particular use cases.

In order to mitigate the effect of this kind of issue when versions change, and to avoid proliferation of a number of different code versions each matched to a set of dependant library (e.g. Primefaces) versions, a Version  Manager facility was developed.

The Version Manager including PDF documentation and an example may be found in the repository here.

No Comments »

With JSF 2.0, it is now possible to use any class as an item in a selectOneMenu combo and related components. This is described in  “Core JavaserverFaces” p157ff. However, the book does not mention that you also need a custom JSF converter to convert between object and string.

If you then implement a custom converter as in the book on p279, e.g. with:-

<h:selectOneMenu styleClass="ss-tsw-select" id="cmbTheme"
      value="#{themeSwitcherBean.theme}" disabled="#{themeSwitcherBean.selectDisabled}"
      converter="uk.co.salientsoft.thememanager.ThemeConverter"
      immediate="true" onchange="submit()">

CDI fails to inject any references used in the converter class, as JSF 2 does not allow CDI in converters, as detailed in this Stack Overflow Post.

It does work however if you use an EL reference in the converter attribute as mentioned in this post here.

Note that the post indicates that it may require it to be an application scoped bean. In my case, it worked fine as both a request scoped and application scoped bean with no trouble. I also removed the @FacesConverter("uk.co.salientsoft.thememanager.Theme") annotation as this was no longer required due to the EL reference. The post indicates that this is perceived to be more untidy due to the use of EL and a managed bean, but I cannot see an issue with this. I cannot see why converters cannot be application scoped CDI beans, it all fits in fine. Here is the code fragment above, modified to use an EL reference instead:-

<h:selectOneMenu styleClass="ss-tsw-select" id="cmbTheme"
      value="#{themeSwitcherBean.theme}" disabled="#{themeSwitcherBean.selectDisabled}"
      converter="#{themeConverter}"
      immediate="true" onchange="submit()">

No Comments »

When developing plugin architectures with IOC, it is useful to be able to iterate over the available beans of a given type which are known to the IO container.

In CDI, this is easy to do, but it is not obvious how from the Weld documentation unless you do a bit of digging and searching.

This post here gives a sample application which does it. The crucial code snippet which does the business is here:-

private @Named @Produces ArrayList<String> wilsons = new ArrayList<String>();
@Inject
void initWilsonRacquets(@Any Instance<WilsonType> racquets) {
    for (WilsonType racquet : racquets) {
        wilsons.add(racquet.getWilsonRacquetType());
    }
}

The intance keyword (used with @Any) exposes an iterator which lets you iterate the available beans. In the above sample they are added to a collection, but you could equally call methods on them as you iterate if you don’t need to keep them.

The Weld documentation describes this on page 25, with the following sample fragment:-

@Inject
void initServices(@Any Instance<Service> services) {
    for (Service service: services) {
        service.init();
    }
}

No Comments »

This is a set of loosely related posts which are of interest.

• This post here on the Primefaces forum discusses partial Page update with view Expiry error handling using a generic Global Exception Handler. The idea can handle different scenarios generically, e.g. Ajax or not, and seems to have impressed Cagatay Civici so well worth a look!
• This post on Stack Overflow discusses the desire for navigation during Partial Page Update. The simple conclusion is that basically you can’t, so don’t try it! This implies that if you code an application that uses PPU across a number of forms/conversations, then it all must be driven from a single URL.
• Another important point which reinforces this is made on Primefaces FAQ #4, which states that forward navigation in Primefaces does not currently work with Ajax, although this may change at some point in the future.

No Comments »

This is an interesting  2 part article by Andy Gibson on how to use CDI conversations. Part 1 is here and Part 2 is here. Of particular interest is his discussion in part 2 about how to manage a collection of conversations and index them/return to them etc.

Another post here discusses the use of conversations and some custom reflection trickery to implement a generic CRUD application that only uses JSF view coding to implement a particular application.

No Comments »

Update 15/9/2011

Here is an example of my initial implementation, similar to the corejsf example above, but using a shorthand syntax to avoid the ifs. This only requires the 2 additional lines in front to declare the namespace. This can be done with global ‘register’ functions, but these in turn have namespacing issues and seem overly complex compared to the code below. Note also that this uses Javascript Object literal syntax to declare the functions (the ‘colon operator’ below, which is also used in JSON). This syntax in Javascript is a concise notation for name value pairs.

This implementation needs rolling out across all the other Javascript – this still needs doing.

var uk=uk||{}; uk.co=uk.co||{}; uk.co.salientsoft=uk.co.salientsoft||{};
uk.co.salientsoft.util= {
 clearElement: function(elementId) {
  var escapedId = ‘#’ + elementId.replace(/:/g, ‘\\3A ‘);
  jQuery(escapedId).val(”);
 }
};

Original Post

It is important to avoid collisions between Javascript function/variable names used by different objects – it is all too easy for entirely different pieces of code to be used in the same application and result in a name collision.

A good mechanism to avoid this for both functions and data is detailed in Core JavaServer Faces Edition 3, page 399. An excerpt from this page detailing how this is done is shown below.

 JavaScript Namespaces

In “The f:ajax Tag” on page 389, we implemented a JavaScript function—showProgress()—that uses Prototype to show and hide a DOM element. That method is fragile, however, because it can be overwritten by another JavaScript method of the same name.

It sounds plausible that someone might implement another JavaScript function named showProgress(), thereby replacing your version of the method with theirs. To prevent that replacement from happening, you could name your function something more unique, such as com.corejsf.showProgress(). With that strategy in mind for protecting our JavaScript method from being overwritten, we implement a simple map that serves as a namespace, and we define functions in that map**:

if (!com) var com = {}
if (!com.corejsf) {
    com.corejsf = {
        showProgress: function(data) {
            var inputId = data.source.id
            var progressbarId = inputId.substring(0, inputId.length – “name”.length) + “pole”;
            if (data.status == “begin”)
                Element.show(progressbarId);
            else if (data.status == “success”)
                Element.hide(progressbarId);
        }
    }
}

So now the caller accesses the function through the namespace, like this:

<f:ajax event=”blur” render=”nameError” onevent=”com.corejsf.showProgress”/>

JavaScript namespacing not only prevents others from overwriting your functions, but it also indicates to readers of your code that you are a JavaScript coder of some substance.

NOTE: Besides creating an ad-hoc namespace by putting JavaScript functions in a map, you can also put data in a map. Namespacing data is a consideration when you implement custom components that maintain data on the client. If you have multiple instances of the component, they will overwrite each other’s data. Putting the data in a map, keyed by the client identifier of the component to which the data is associated, is a way to ensure that multiple Ajax-based custom components of the same type that store data on the client, can co-exist in a single page.

** The map is actually an object literal—JavaScript does not have a map data structure—but semantically a JavaScript object literal is similar to a map.

No Comments »