Salient Soft

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 »

I had issues getting Activesync to connect over bluetooth during the last few days. at each attempt activeSync on the HTCgave the error “attention required, unable to connect, bluetooth port may be in use” etc.

I tried restarting both and reconnecting but this did not work.

On one occasion, Window 7/panther was unable to complete listing the devices, but this appears to have been a one of as it is fine today.

In the end, I tried deleting the pairing and repairing the devices. This solved the problem. I was concerned that it would also delete activesync related info and require reconfiguration of that, but it did not. Once the pairing was set up, I was able to connect via Bluetooth from the HTC and resync correctly with no further errors.

I have seen this before in other situations where a bluetooth pairing appears to get corrupted in someway, and generally as in this case deleting the pairing and repairing seems to resolve it.

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 »

This article by Andreas Höhmann details how to do this. It uses the infamous map trick using a custom Map implementation to allow map based lookups, and also discusses list based index lookups.

This all needs to be weighed up with the ability of JSF2 to allow method expressions with parameters, but still a useful trick in some cases.

No Comments »

This is a hugely funny take on design (anti) patterns – well worth a read, also available in Google Docs and as PDF download.

No Comments »

It seems to be that Weld:-

• has error/log messages which are not as good as Spring
• has a lot of magic going on compared with, say, Guice, and so more info is needed about what is going on under the hood.
• Turning logging up to full is obviously a starter. I haven’t done this yet – need to look at weld log messages to see what to turn up. Note that Weld uses sls4J NOT java.util.logging, and the levels are therefore different – need to look at how they are mapped/how to turn it up.

You can find out more about Weld’s decision making when injecting beans by writing some code to listen to various weld events. You have to use Weld’s extension mechanism to do this but it is apparently very easy. Details of it in this post here on stackoverflow.

There are also some comments around about slow weld performance and memory usage, during startup. Performance is being improved and Weld 1.1 has these fixes in, but you need Glassfish 3.1 to use it which also opens up all the issues of Mojarra client state saving problems etc. which have prevented me moving to it.

There is some negative CDI/Weld comment about on the net, but as with any toolset there is no silver bullet. Any choice will have some downsides and our priorities should and will determine the best choice. Even with these issues, I cannot see a justification to move to Spring as whilst it is mature and very popular, it is a closed standard which is very XML heavy and does not do typesafe injection. Guice is closer in style to CDI, but both Guice and Spring are JSR330 implementations and so are not portable. Weld uses JSR299/CDI and is therefore an open portable (and the most recent) standard, and is built on input from both the Spring and Guice teams. If we can suffer some early adopter pain, I feel Weld will end up being the best choice.

By the time performance becomes a serious issue for this project, Weld will have moved on and these issues should have improved. Note also that there is already (at least) one alternative JSR299 implementation – Apache OpenWebBeans. This means that we can move to another CDI implementation if we have to, with minimum pain, in the same way that if Mojarra screws us we still have Apache Myfaces as a choice.

No Comments »

String.split is now the preferred means of tokenising strings as java.util.StringTokeniser is now deprecated. String.split returns a string array containing the split strings. Using String.split requires some understanding of regular expressions, so I have included a couple of simple examples here.

String[] output = input.split(“[,\\s]+”);

This example takes string input and splits it on any white space (including newlines) or commas. Multiple white space and/or multiple comma characters are treated as a single delimiter. The regex string operates as follows:-

• []+ matches any of the characters/constructs in the brackets, and matches 1-n times via the plus character. Multiples are treated as a single match.
• , matches the comma character.
• \\s matches any white space. The double backslash is needed as both Java and Regex use it as an escape character, so it is needed twice.

String[] output = input.split(“\\s*,\\s*”);

This example takes string input and splits it on commas only. Each comma may be preceeded or followed with zero or more white space characters (and newlines), which are also matched and therefore are stripped from the output. Multiple commas will result in empty strings in the output array, as there must always be exactly one comma as a delimiter. The regex string operates as follows:-

• \\s* matches zero or many white space characters, and is placed both before and after the comma. This means that white space is swallowed up and not returned if present (as it is part of the delimiter), but it is not required to be present i.e. is not mandatory for the delimiter.
• ,  matches a single comma character. This means that a delimiter must have one and only one comma. Multiple commas are treated as multiple delimiters.

Some points about string splitting in general:-

• Any leading or trailing white space on the input string needs careful handling. In the first case above,  leading white space will cause an empty first output string to be part of the array. In the second example, leading white space will precede the first output string, and trailing white space will be left appended to the last output string. To avoid these problems, it is a good idea to trim the input string before splitting it, e.g.:-

String[] output = input.trim().split(“[,\\s]+”);
String[] output = input.trim().split(“\\s*,\\s*”);

• Any characters which are matched as part of the delimiter are swallowed up and not returned in the output array. This gives an opportunity to clean up the string as I have done in the second example here, by making other characters (in this case white space) an optional part of the delimiter, so that they are removed if present.
• You can compile the regular expression string into a pattern, which is efficient if the same pattern will be reused a number of times. You then perform the split via the pattern, so that our second example above would then be:-

Pattern pattern = Pattern.compile((“\\s*,\\s*”);
String[] output = pattern.split(input);

The Sun Java tutorial on regular expressions may be found here. There are many other sites with examples as well, as for example this google search shows.

No Comments »