A little tip: deploying a war file on different containers / application servers can lead to different results. Although their scope widely differs, Sun has 2 offerings when it comes to deploying a war file: Sun Java System Web Server (SJWS) and Glassfish.

Well, it turns out that Glassfish replaces the entire content of the directory where the application is deployed while Sun JSWS will simply overwrite the existing files, thus leaving all other files in place. In a recent case, I had copied some properties file in that directory (after a first deployment) and was surprised to find them there after a re-deploy.

Now, I know that I’m not really supposed to mess around with files of a deployed war but I find it to be a good reminder of the sometimes not so subtle differences between containers.

I had mentioned in a previous blog an issue I was seeing with my web application and its use of JPA. It turns out (thanks to people on the Glassfish users mailing list) that, after a refactoring, my JPQL query was rendered wrong up by using the name of the table instead of the name of the Java entity.
@NamedQueries(name = "Acctoken.findAll", query = "SELECT a FROM Acctoken a")
should have been:
@NamedQuery(name = "AccessToken.findAll", query = "SELECT a FROM AccessToken a")
Simple enough but, as I had written before, the fact that it somehow was working for subsequent calls remains a mystery to me…

Here’s an interesting problem I’m facing.
I have been working on a web application that I’m deploying using Glassfish. The web app leverages the Jersey framework (I really recommend it to anyone interested in RESTful development in Java). I also use the Java Persistence API to store objects in a DB. For all this, I’m using NetBeans tools to create a Persistence Unit and the entities I have to manage (from a DB schema). NetBeans also creates the appropriate mapping of the entities and their Java classes. So far so good…
For each entity, I end up with java classes that look something like this:

@Table(name = "ACCTOKEN")
@NamedQueries({@NamedQuery(name = "Acctoken.findAll", query = "SELECT a FROM Acctoken a"),
@NamedQuery(name = "Acctoken.findById", query = "SELECT a FROM Acctoken a WHERE a.id = :id"),
@NamedQuery(name = "Acctoken.findByAcctUri", query = "SELECT a FROM Acctoken a WHERE a.acctUri = :acctUri")
/... more queries .../ })

public class AccessToken implements Serializable { /.../ }

The code above compiles fine and I can deploy the generated war file with Glassfish. However, and this is where I could use suggestions from anyone, I see a weird behaviour upon hitting one of the exposed endpoints:
The very first time I do a POST (or GET), the web application throws an exception that looks like:

Exception [TOPLINK-8034] (Oracle TopLink Essentials - 2.0.1 (Build b04-fcs (04/11/2008))):
oracle.toplink.essentials.exceptions.EJBQLException Exception Description: Error compiling
the query [Acctoken.findByAcctVal: SELECT a FROM Acctoken a WHERE a.acctVal = :acctVal].
Unknown abstract schema type [Acctoken]. at oracle.toplink.essentials.exceptions.
EJBQLException.unknownAbstractSchemaType (EJBQLException.java:494)

What’s funny is that this does not happen in any subsequent access to those URLs, the web app behaves properly. Because subsequent calls are fine I know the mapping does happen and is correct. I thus don’t really have to explicitly list the classes in the persistence.xml file and instead I have the <exclude-unlisted-classes>false</exclude-unlisted-classes> tag. However listing the classes will not help. I have verified this in both Glassfish 2.2 and Glassfish 3: same behaviour.

It really looks like Glassfish (what else?) adopts a “lazy” approach for the mapping to happen and is basically not ready for the 1st call. I already have the <load-on-startup /> tag set in my web.xml and this didn’t help.

So there it is, anyone has an idea?

While deploying OpenSSO on Glassfish (I used v2ur2), I ran in an interesting situatation:
Although deployment goes well, OpenSSO’s configurator (that is the process OpenSSO goes through the very first time you launch it after deployment) failed with a rather laconic LDAP operation failed message. Searching into the Glassfish server log, I could see that indeed LDAP had a problem:

Message:The LDAP operation failed.
The lower level exception message
error result
The lower level exception:
netscape.ldap.LDAPException: error result (68); The entry
dc=net cannot be added because an entry with that name already exists
at netscape.ldap.LDAPConnection.checkMsg(LDAPConnection.java:4866)
at netscape.ldap.LDAPConnection.add(LDAPConnection.java:2864)
at netscape.ldap.LDAPConnection.add(LDAPConnection.java:2879)
at netscape.ldap.LDAPConnection.add(LDAPConnection.java:2829)

After consulting experts on the matter, I had the solution to my issue:
Modify Glassfish’s domain.xml configuration file of the domain OpenSSO is deployed in (most of the time it will be the default: domain1).
The change is fairly simple:

Good to know…