Let's see, where to start?
1. Thanks for going through all my suggestions!
2. Can you send me the EAR privately? If so, please include asadmin commands for setting up any JDBC connections, pools, etc.
If not, can you at least post the structure of the EAR's contents? The output from "jar ft Suprima.ear" would probably do it.
3. About the naming... Yes, it can be confusing. Here's a brief summary:
GlassFish 3 differs from GlassFish 2 in what files it generates for app client support. GlassFish 2 used to generate a single JAR file which held the contents from the developer's original app client JAR as well as some other things. That was listed in the JNLP. GlassFish 3 takes a different approach. Now we leave the original developer's files alone and, where needed, download them as-is. This is faster during deployment because we don't copy all that data around, and it preserves any signing the developer might have done with the JARs. It also lets Java Web Start optimize its downloading after a redeployment, in which some JARs might not have changed and therefore would not need to be refreshed in the Java Web Start cache.
Here are the client-related files GlassFish 3 generates:
${appName}Client.jar - same name as in GlassFish 2 but very small (therefore much different content from GF 2's version of this JAR) Internally in the code we call this the "EAR-level facade" or the "client group facade." There is one of these for the EAR and it's manifest contains various bits of information about each of the app clients in the EAR. In particular, it contains references to the next generated file...
${clientName}Client.jar - no precedent in GlassFish 2 - also very small. This is the "client facade." It's manifest refers to the corresponding actual client JAR file from the developer. There is one of these for each client in the EAR. (In your case that sounds like there is just one.)
Further, the namespace in the URL paths is a little confusing but closely parallels the files and directories we create during the download that's part of "asadmin deploy --retreive localDir ..." or "asadmin get-client-stubs --appname Suprima localDir" (which I know is not your use case but I mention it in case you or others try to relate one to the other).
The codebase for the JNLP document is (long-prefix)/${appName}. In your case, (long-prefix)/Suprima. This qualifies all relative paths elsewhere in the JNLP. (You can see this in the javaws -viewer output URLs for the applications and resources.) Ultimately, this makes sure that the server can distinguish files and even paths from different apps that have identically-named files.
Within the JNLP codebase is this structure:
${appName}Client.jar - the client group facade
${appName}Client/ - here really just for consistency with the --retrieve and get-client-stubs behavior
${clientName}Client.jar - client facade for this client
${clientName}.jar - your original client JAR
It's a little more complicated if your client does not reside at the top-level of the EAR. It still works but the naming is more intricate.
Anyway, the bottom line to this very long story is that the names you see in the GlassFish 3 JNLP documents look correct to me. That's why I'm eager to see your EAR so I can try to reproduce the problem you are seeing - or at least to see your EAR's layout.
- Tim
[Message sent by forum member 'tjquinn']
http://forums.java.net/jive/thread.jspa?messageID=392647