GlassFish Tip of the Day: HttpOnly

This is just a quick tip for those who are configuring HttpOnly on GlassFish.  To enable it, you simply add the following to your web.xml.
The default on GlassFish is to have it enabled anyway, and you must explicitly disable it.

UPDATE:
The issue I had was testing it. When I deployed my application to localhost I did not see any of the cookies being marked as HttpOnly. I was using Chrome and auto-deploying my application, before I turned on the developer tools. The initial request contained the header marking it as HttpOnly. You can confirm it by easily using JSF and the method below. Simply invalidate the session while using the developer tools and examine the response returned.
I got a response header like the one below.

RichFaces 4.x Drag and Drop (DnD) Issue with MyFaces and WebSphere 8.5

I have been fighting with MyFaces for a couple of weeks now to get it to run on multiple containers that have Weld as the CDI implementation, and also to run on WebSphere with OpenWebbeans (CDI) implementation. Just when we thought we had the problem solved... RichFaces is killing us with a Drag and Drop (DnD) issue on MyFaces.

The issue is detailed in RF-12675 Drag and drop doesn't work with MyFaces. It is an ugly bug that prevents the application from dropping the draggable on the drop target. It is supposed to be fixed according to JIRA in version 5 which as far as I know has an undetermined launch date at this time.

I think that the issue probably warrants investigation by the RichFaces team, but I am posting this just in case folks have encountered the same issue.

I have a test application that is from on the RichFaces Showcase application that demonstrates the Drag and Drop functionality. I tested it on GlassFish, JBoss 7, and Weblogic 12c. It works perfectly on those platforms but the drag freezes in "mid-air" on WebSphere 8.5 with MyFaces.

Here is a link to the application, or you can get it from the JIRA issue above: dragdrop-test.zip.

I hope the RichFaces team reconsiders the bug since it affects 4.2.3 and 4.3.2 final releases.

UPDATE: One of the Senior Engineer's on my team, Amit Tikoo, confirmed the issue is focused on the <rich:dragIndictor />. The work around is to remove the indicator and the application will function. The JIRA issue was updated with the observations.

JSF Tip of the Day: Reading Authorization Header in JSF

After I did the JAX-RS Tip of the Day today, I wondered about reading the authorization header from JSF. The technique is the same as the JAX-RS version, but the methods are different depending on what is available to the JSF application. The JAX-RS Base64 class is not part of the web profile in Java EE 6. It will be part of Java EE 7 so you could use it. I chose to add the comments in the code below, but decided that I would use the com.sun.misc.Base64Decoder which is currently available in Java SE 6 and 7.
UPDATE: I got a suggestion on Google+ from +Thomas Darimont who mentioned using DatatypeConverter.parseBase64Binary() from the Java API for XML Binding (JAXB). I confirmed that it is available in Java EE 5 and 6. It is also in the Web Profile in Java EE 6.