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 »

My old TyTn II has had sync issues over the last few weeks, sometimes needing several attempts to sync.

A few days ago it failed completely with sync errors part way through.

I have tried a number of things to resolve the issue, with only partial success.

1/ WMDC 6.1 did not sync at all. I tried turning ‘advanced network functionality’ both on and off on the TyTn II (under settings/connections/USB to PC), and neither worked. The advanced setting is apparently what allows the device to share the PCs internet connection, and is not available with this turned off, although I have not investigated this.

2/ I tried removing WMDC 6.1 and installing WMDC6.0 for Windows 7/Vista 64 bit, but it always installed 6.1 as part of the install, and so was very tricky to roll back.

3/ This procedure worked in the end and allowed 6.0 to install (as per this forum post here):-

Note that as part of this procedure, when deleting the WindowsMobile folder, renaming it first then allows all the contents to be deleted (possibly rebooting after the rename but this was not always required). Note also that I turned windows update automatic mode off so that it would always ask about any update first, in case it was responsible for the ‘invisible’ update to 6.1

Here are the steps that I performed during this cycle of events that has got
my Dopod phone with WM6 sync’ing again with WMDC 6.0:
— Uninstalled the two Windows Mobile Device Center 6.1 items from the
Control Panel > Programs and Features list
— Manually deleted the contents of the C:\Windows\WindowsMobile folder.
Initially I could not delete some DLLs but once the two “Windows Mobile
device connectivity” services were stopped from the Task Manager, I was able
to delete the rest of the files in the WindowsMobile folder, except for the
en-US folder containing the *.MUI files. I could not delete them and so
decided to leave them.
— Using Regedit, I deleted all entries from the following two keys that
related to my two devices:
* HKCU\Software\Microsoft\Windows CE Services\Partners
* HKLM\Software\Microsoft\Windows Portable Devices\Devices (I left
in the entry for my memory card)
— Using Windows Explorer, I deleted all files in the following folder:
* C:\Users\<username>\AppData\Roaming\Microsoft\Acti veSync\Profiles
— With my two Pocket PCs disconnected, I tapped on Start > Programs >
ActiveSync > Menu > Options, highlighted the Windows PC and tapped on and
the Delete button. Both of my PPCs had two entries in here so there could
have been some confusion on the desktop at some point, so I deleted both of
them. They do not sync with any other computer.
— Rebooted (Restarted) my Windows Vista computer
— Reinstalled WMDC 6.0 from the Microsoft Download website.
— Recreated the two relationships from my two devices, and they each did
the initial long sync
— I then tested each device that it could perform a sync not long after it
was reconnected, and they both now sync perfectly. I also tested that making
any changes to some contact details in Outlook 2007 would update the devices
after a sync. and it did.

4/ When using WMDC 6.0, I had to disable the Advanced Networking Functionality on the device, as WMDC was unable to install the correct driver for it when I tried.

4/ This now allowed the TyTn II to sync contacts, calendar and tasks. However, annoyingly, it does not sync the textual content of calendar appointments or tasks – only the headers are synced. This is the ‘partial’ solution that I am having to live with. The good point is that at least contacts are synced properly, and at least with the appointments I will get reminders on the phone plus the title details, which is enough for most of them.

5/ I retried the different versions a number of times but this behaviour was consistent. In the end I had to use system restore to remove 6.1 as the driver update would not remove. It may have done so in safe mode but I did not try this. The behaviour was consistent with both USB and bluetooth syncing.

6/ I also tried syncing with a laptop running Windows XP, but interestingly this also failed to sync, which perhaps points the finger at the TyTn II as this used to work.

7/ I tried running SCANPST.EXE (in the C:\Program Files (x86)\Microsoft Office\Office12 folder) to check for PST corruption as a possible issue. Interestingly it did find a number of issues. It fixed most, if not all of them ( I reran the check again after it had done the fix and some errors remained). However, these errors have not caused any issues when using Outlook and did not allow the TyTn II to sync with WMDC 6.1

It is not clear what the actual issue is, but it is interesting that WMDC 6.0 at least completes a full sync consistently (albeit without calendar/task text). There are any number of posts on the internet complaining about this issue, and I must say I agree with them. It is hugely ironic that an iPhone can sync with Outlook but in many cases a Windows Mobile cannot.

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 »

I have sometimes had a need to define temporary variables for use on a facelets page.

When I tried using <c:set> for this it failed to work when used within a decorator.

However, <ui:param> fulfills the need admirably. Whilst it is normally used to pass EL parameters to a template from its client, it can also be used to hold data for use elsewhere in the same decorator for example. Bear in mind that there are scoping issues which as yet I have not fully bottomed out – the variable is probably visible anywhere else in other templates/xhtml files on the same page and so care is needed with naming.

A good example of this was when I wanted to define a couple of size parameters (which could not be done with CSS) at the top of a decorator/custom tag where they were clearly visible, and then re-use them multiple times further down in tag attribtutes to called tags.

No Comments »

There appears to be an issue when using EL in child components included in a composite component using <composite:insertChildren>

I am already using this technique for the tableCC component, to insert the columns as children, and the child columns have plenty of EL in them which is not passed to tableCC, as well as having custom tags as columns. However, there appears to be an issue when this technique is used in nested composite components.

When I tried this, I found that any EL expressions in the child components is evaluated as late as possible in the context of the called composite component, not the caller!

This means that if you need to refer to an attribute passed in to the caller of the CC, you must pass that attribute on to the CC as well as referring to it in the child components, as their EL will be evaluated in the CC not the caller.

Providing you do this, it all works fine. However, the issue with this is that it will tend to break encapsulation of the interface to the child nested CC – you have to change its interface depending on what EL you want to use in the child components passed to it.

This was unacceptable to me, so I switched to a different technique. Instead, my base component (actually a flexible icon/base button using p:commandLink) became a custom tag, and I used facelets <ui:inserts> to handle the insertion of custom markup. I then wrapped composite components around this to provide the necessary custom markup.

The reason for going down this route was that I have had issues with glitchy ajax updates on standard Primefaces buttons at small sizes (see this Mantis issue). Also I was crafting icon buttons with multiple jQuery icons on them, using CSS to position them accurately. This was tricky with a p:commandButton and involved introducing CSS that I was concerned may need change in future releases, so I went my own way when using highly custom buttons and buttons at small sizes.

No Comments »

This can be done e.g. by a Facelets Decorator using <ui:insert> and I have used this in a number of places.

However, in one case, I wanted to make a complex treeBrowser custom tag switchable between editable mode and readonly using just a single flag passed as an attribute. Note that I did not want to switch it dynamically at run time – I just re-used the tag in a number of places and some were editable and some were not. As this switch involved a number of changes in the tag, it was convenient to drive them all from a single flag.

In addition, whilst I could have used a decorator for this, I already had 2 versions of the tag each decorating a base version, where each version was used to browse completely different tree structured data in the application which was all handled polymorphically.  Using decorators for readonly/editable as well would have multiplied up the variants to 4, which was undesirable. By using a single EL flag, I was able to make all the switching entirely in the base custom tag which was a real help here.

Anyway – to discuss the real point of the post – to achieve my goal I needed to conditionally include columns for a <p:dataTable>. Using <ui:fragment> to do this does not work as <ui:fragment> creates a new component in the JSF tree which is not a column, and <p:dataTable> ignores any children that are not columns. Whilst there are ways using composite components to indicate with interface properties the precise Class type that the component appears to be, fooling <p:dataTable> by making it look like a column does not work – I tried this and it failed, and there are posts on the Primefaces forum citing the same issue.

The simple solution was to use <c:if> to conditionally include columns. This eventually worked correctly, once I had fixed a particularly nasty incorrect JSTL namespace issue which is fully described in this post here.

No Comments »

As I am running a Java development machine I want precise manual control of the versions of Java and all the related tools.

The Java auto updater runs regularly and nags about updating, but I want to turn it off. There is a control panel applet  – “Java (32-bit)” – with an option under the updates tab to do this, however it does not work – if you uncheck the “check for updates automatically” tick box, it appears to save OK but when you close and re-open the applet and look again the value has not changed.

This is due to an apparently long standing Java bug – it does not run with admin privileges and so cannot change the value. It would be nice if it gave an error telling you that it did not work due to a permissions problem, but unfortunately it just fails completely silently.

This post here outlines various solutions to the problem. The accepted answer, which worked for me, is to find javacpl.exe, right click it, and run with admin privileges. The location of it in my case was not where the post suggested, even though I had done a default install, so you will probably need to search for it. In my case I had a couple of versions of it, one was for an old version of Java. The path for mine which I used successfully was C:\Program Files (x86)\Java\jre6\bin

This fixed the problem, and upon reopening the control panel applet (with or without admin privileges) the box was unticked.

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 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 »

This error came up while building a new development environment with the Eclipse Helios SR2 and Eclipselink 2.2.0.
The error appeared for every JPA entity, even after the database drivers/connections were correctly defined.

The simple answer  as detailed here is to right click the project and do a validate – hey presto, all the errors disappear!
This appears to have been around a while and is still not fixed in Eclipselink 2.2.0, but at least it is simple to resolve.

The tip was found on this Oracle tutorial post :-

Note:

If you encounter a Schema “null” cannot be resolved for table “<TABLE_NAME>” error, you’ve hit a known Eclipse bug.
To resolve the issue, right-click the project and choose select Validate from menu. Eclipse will clear the errors.

No Comments »