Skip to main content

Unable to launch Glassfish v3 app client via Java Web Start

16 replies [Last post]
suttridge_farm
Offline
Joined: 2006-01-27

Hi All (and Tim),

Just done a first app client on Glassfish v3 using Netbeans 6.9M1 (latest GFv3 with updates from yesterday 17th). System is Ubuntu with Sun Java 1.6.0_16. The app client is packaged in an EAR, along with an assortment of other stuff (war's and ejb's, which works fine). When attempting to launch the app client from a browser, I get the following exception :-

com.sun.deploy.net.FailedDownloadException: Unable to load resource: http://localhost:8080/___JWSappclient/___app/Suprima/SuprimaClient.jar

Now the actual name of the app client is Suprima/SuprimaBootstrap, and not /Suprima/SuprimaClient. I see in the displayed "more information" of the java web start application error dialog, the following for the launch file :-

Both of these seem to not match the original name of the app client. Looking into the domain, I can see :-
applications/Suprima/SuprimaBootstrap_jar
generated/ejb/Suprima/SuprimaBootstrap_jar
generated/jsp/Suprima/SuprimaBootstrap_jar
generated/xml/Suprima/SuprimaBootstrap_jar

The xml sub-directory contains a file SuprimaBootstrapClient.jar, and then there is also the "signed" sub-directory, containing another SuprimaBootstrapClient.jar.

so it seems as if the whole ear got correctly exploded.

The server log shows the following report :-

INFO: ACDEPL103: Java Web Start services started for the app client Suprima/SuprimaBootstrap.jar (contextRoot: /Suprima/SuprimaBootstrap)
INFO: jarsigner: unable to open jar file: /home/steve/glassfishv3/glassfish/domains/domain1/generated/xml/Suprima/SuprimaBootstrap_jar/SuprimaClient.jar

mainly because it is looking for the file SuprimaClient.jar, when the one there is SuprimaBootstrapClient.jar. Thereafter follows a long list of exceptions, about the not found jar cannot be signed.

Can you check this out please ?

Thanks,

Steve.

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
vasekt
Offline
Joined: 2010-03-22

Hi,

just confirming I have exactly the same problem. I use netbeans 6.8 Glassfish 3.0.1b12 or b9.
When I create any simple Enterprise application with client and try to run it I get error 500 from glassfish HTTP for Client file.

I found why this happens but I don't know how to avoid it

Let's say my application is called TestEA (one bean with hello world method) + client calling this method. This is structure of generated/xml/testEA directory:

myserver:/opt/glassfish-3.0.1-b12/glassfish/domains/domain1/generated/xml/TestEA# find *
TestEA-app-client_jar
TestEA-app-client_jar/signed
TestEA-app-client_jar/TestEA-app-clientClient.jar
TestEAClient.jar
TestEA-ejb_jar

After launching application via webstart in Administration console I get following error:
Server returned HTTP response code: 500 for URL: http://business2.anderlippin.cz:80/___JWSappclient/___app/TestEA/TestEAC...

This is in glassfish log:

[#|2010-04-09T16:04:37.771+0200|INFO|glassfish3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=32;_ThreadName=Thread-1;|jarsigner: unable to open jar file: /opt/glassfish-3.0.1-b12/glassfish
/domains/domain1/generated/xml/TestEA/TestEA-app-client_jar/TestEAClient.jar|#]

[#|2010-04-09T16:04:37.772+0200|INFO|glassfish3.0|javax.enterprise.system.std.com.sun.enterprise.v3.services.impl|_ThreadID=32;_ThreadName=Thread-1;|jarsigner error: java.security.AccessControlException: System.exit|#]

[#|2010-04-09T16:04:37.773+0200|SEVERE|glassfish3.0|com.sun.grizzly.config.GrizzlyServiceListener|_ThreadID=32;_ThreadName=Thread-1;|service exception
java.lang.RuntimeException: java.io.IOException: java.lang.Exception: Error attempting to create signed jar /opt/glassfish-3.0.1-b12/glassfish/domains/domain1/generated/xml/TestEA/TestEA-app-client_jar/signed/TestEAClie
nt.jar with alias s1as
at org.glassfish.appclient.server.core.jws.AppClientHTTPAdapter.service(AppClientHTTPAdapter.java:139)
at com.sun.grizzly.tcp.http11.GrizzlyAdapter.service(GrizzlyAdapter.java:166)
at com.sun.enterprise.v3.server.HK2Dispatcher.dispath(HK2Dispatcher.java:100)
at com.sun.enterprise.v3.services.impl.ContainerMapper.service(ContainerMapper.java:245)
at com.sun.grizzly.http.ProcessorTask.invokeAdapter(ProcessorTask.java:791)
at com.sun.grizzly.http.ProcessorTask.doProcess(ProcessorTask.java:693)
at com.sun.grizzly.http.ProcessorTask.process(ProcessorTask.java:954)
at com.sun.grizzly.http.DefaultProtocolFilter.execute(DefaultProtocolFilter.java:170)
at com.sun.grizzly.DefaultProtocolChain.executeProtocolFilter(DefaultProtocolChain.java:135)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:102)
at com.sun.grizzly.DefaultProtocolChain.execute(DefaultProtocolChain.java:88)
at com.sun.grizzly.http.HttpProtocolChain.execute(HttpProtocolChain.java:76)
at com.sun.grizzly.ProtocolChainContextTask.doCall(ProtocolChainContextTask.java:53)
at com.sun.grizzly.SelectionKeyContextTask.call(SelectionKeyContextTask.java:57)
at com.sun.grizzly.ContextTask.run(ContextTask.java:69)
at com.sun.grizzly.util.AbstractThreadPool$Worker.doWork(AbstractThreadPool.java:330)
at com.sun.grizzly.util.AbstractThreadPool$Worker.run(AbstractThreadPool.java:309)
at java.lang.Thread.run(Thread.java:619)
Caused by: java.io.IOException: java.lang.Exception: Error attempting to create signed jar /opt/glassfish-3.0.1-b12/glassfish/domains/domain1/generated/xml/TestEA/TestEA-app-client_jar/signed/TestEAClient.jar with alias
s1as
at org.glassfish.appclient.server.core.jws.servedcontent.AutoSignedContent.isAvailable(AutoSignedContent.java:93)
at org.glassfish.appclient.server.core.jws.RestrictedContentAdapter.serviceContent(RestrictedContentAdapter.java:225)
at org.glassfish.appclient.server.core.jws.AppClientHTTPAdapter.service(AppClientHTTPAdapter.java:135)
... 17 more
Caused by: java.lang.Exception: Error attempting to create signed jar /opt/glassfish-3.0.1-b12/glassfish/domains/domain1/generated/xml/TestEA/TestEA-app-client_jar/signed/TestEAClient.jar with alias s1as
at org.glassfish.appclient.server.core.jws.servedcontent.ASJarSigner.signJar(ASJarSigner.java:170)
at org.glassfish.appclient.server.core.jws.servedcontent.AutoSignedContent.createSignedFile(AutoSignedContent.java:112)
at org.glassfish.appclient.server.core.jws.servedcontent.AutoSignedContent.isAvailable(AutoSignedContent.java:91)
... 19 more
Caused by: java.security.AccessControlException: System.exit
at org.glassfish.appclient.server.core.jws.servedcontent.ASJarSigner$NoExitSecurityManager.checkExit(ASJarSigner.java:577)
at java.lang.Runtime.exit(Runtime.java:88)
at java.lang.System.exit(System.java:904)

I THINK PROBLEM IS THIS:
jarsigner: unable to open jar file: /opt/glassfish-3.0.1-b12/glassfish
/domains/domain1/generated/xml/TestEA/TestEA-app-client_jar/TestEAClient.jar|#]

because TestEAClient.jar is located in different directory!
After moving TestEAClient.jar to TestEA-app-client_jar/TestEAClient.jar I can launch the application.

This is how generated/xml/TestEA looks after launch:
myserver:/opt/glassfish-3.0.1-b12/glassfish/domains/domain1/generated/xml/TestEA# find *
TestEA-app-client_jar
TestEA-app-client_jar/signed
TestEA-app-client_jar/signed/TestEA-app-client.jar
TestEA-app-client_jar/signed/TestEAClient.jar
TestEA-app-client_jar/signed/TestEA-app-clientClient.jar
TestEA-app-client_jar/signed/TestEA-ejb.jar
TestEA-app-client_jar/TestEAClient.jar
TestEA-app-client_jar/TestEA-app-clientClient.jar
TestEAClient.jar
TestEA-ejb_jar

So I guess the problem is that glassfish looks to wrong directory when signing client jar. And the question is what can I do about this? Because I don't want to copy client.jar each time i do deploy.

Thanks for help

Added by: vasekt

And one more note - It is another issue - but also important for running clients via webstart. When launching application via WebStart I can't use javaws from newest JDK - it gives me some error
JDK 1.6.15 works on Linux
JDK 1.6.17 works on Mac
JDK 1.6.19 on Linux does not
JDK 1.6.19 on Windows does not

muhkuh2k
Offline
Joined: 2007-11-08

I am having a similar problem with webstart. I use JDK 1.6.0_20 linux, Netbeans 6.8 for development and Glassfish OSE 3.0.1 (build 18), but I had this problems with earlier builds too.

Webstart complains, that some resource can not be loaded.

Here is the (localized) Exception:

com.sun.deploy.net.FailedDownloadException: Ressource konnte nicht geladen werden: http://localhost:38634/___JWSappclient/___app/TestEE/TestEEClient.jar
at com.sun.deploy.net.DownloadEngine.actionDownload(DownloadEngine.java:1376)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(DownloadEngine.java:1529)
at com.sun.deploy.net.DownloadEngine.getCacheEntry(DownloadEngine.java:1507)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(DownloadEngine.java:1613)
at com.sun.deploy.net.DownloadEngine.getResourceCacheEntry(DownloadEngine.java:1538)
at com.sun.deploy.net.DownloadEngine.getResource(DownloadEngine.java:217)
at com.sun.javaws.LaunchDownload$DownloadTask.call(LaunchDownload.java:1739)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
at java.util.concurrent.FutureTask.run(FutureTask.java:138)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:619)

tjquinn
Offline
Joined: 2005-03-30

The problem with Java SE 1.6.0_19 and later is described in issue 11889:

https://glassfish.dev.java.net/issues/show_bug.cgi?id=11889

I am testing the fix now.

I plan to also address the other problem - the one in which the resource is not found - in the same check-in. I hope to commit the changes very soon. With luck tonight's nightly builds of 3.0.1 and 3.1 will have the fixes.

-Tim

tjquinn
Offline
Joined: 2005-03-30

I have checked in changes for both 3.0.1 and 3.1

Tonight's nightly builds of each should have the changes.

- Tim

mgfarme
Offline
Joined: 2010-05-24

Ok - So I have downloaded and installed version 3.0.1, build 19 from May 24th. I was previously getting the same error as the others were reporting earlier in the thread. with the new build, I no longer get that error, but I now get this:

Unsigned application requesting unrestricted access to system
Unsigned resource:
http://localhost:8080/__JWSappclient/___system/s1as/glassfish/modules/hk...

The exception comes from:

at com.sun.javaws.LaunchDownload.checkSignedResourcesHelper(LauchDownload.java:1432)

Thanks for any thoughts!

Martin

tjquinn
Offline
Joined: 2005-03-30

One possibility:

Clear out your client's Java Web Start cache of the GlassFish system JARs to make sure the client will download the signed ones from the server.

Use

javaws --viewer

and then use the drop-list in the upper left corner to choose Resources. Click URL to sort the entries by URL, then select all the ones that come from ___JWSappclient/___system. When you launch the client the next time you'll go through the downloads again but it should leave you with the correct, signed copies of the GlassFish system JARs.

- Tim

tjquinn
Offline
Joined: 2005-03-30

Hi, Steve. Good to hear from you again!

I just tried a deployment of an EAR containing two app clients, using a build from a very recently updated workspace, so we should be using close to the same code base. I could deploy and launch the clients just fine. So let's see if there's something in the environment on your system that explains this.

The error during signing could be either a symptom of another problem or the problem itself. Were there any errors reported earlier during the deployment?

Can you please try this? Sorry for all the steps, but if this is the problem it would help to collect this information.

Use

javaws -viewer

to open the Java Web Start app viewer. You should see a drop-list (in the upper left on the system and version I'm using) with choices Applications/Resources/Deleted Applications. Choose Applications and you should see a list of apps cached by Java Web Start. Capture an image of that window and attach it to a reply to this topic. Now select the app for Suprima and then click the red X or press the delete key to remove it.

Next, choose Resources from that same drop-list and you should see supporting JNLPs and JARs for the apps Java Web Start has cached. Sort by URL to get the Suprima ones close together and visible without scrolling. Capture a window image and attach it also to your reply here. Select the ones with URLs referring to Suprima and delete those.

Now try launching the client via Java Web Start again.

If this works, then Java Web Start was incorrectly using an older cached version of a JNLP document. That could be due to a bug in Java Web Start or it could be GlassFish incorrectly reporting the timestamp for the generated JNLP documents which caused Java Web Start to think it already had an up-to-date copy of a JNLP when in fact it had a stale one. So if clearing the cache worked for you, I'd appreciate it if you could describe any naming changes you might have made with the app between deployments, or if you had launched this same app using Java Web Start using an earlier build of GlassFish 3. (Some bug fixes in GlassFish 3 have changed where some of the generated JAR files reside, which affects the paths in the URLS in the JNLP documents that point to those JARs. So a stale JNLP could have had the old path to a generated file.)

I think I need to write a blog about the naming conventions for the JARs. The names you described actually look correct, given the app name and client name with the app. It can be a bit confusing, but the goal is for you to never need to think about these names anyway.

Please let us know what you find, and thanks in advance for posting the screen captures. Of course if you'd prefer you can e-mail me the images rather than posting them here publicly.

- Tim

suttridge_farm
Offline
Joined: 2006-01-27

Hi Tim,

Yes, I'm back in the fray again - this time with GF v3 ! I have ported the previous application which was running on GF v2.1.1 to GF v3, and modified the code so that it uses all the goodness of EJB 3.1. The old application eventually did not have any app clients in it, but I decided to put a very small one in the new version.

OK, basically this was the first ever app client that had ever been run on the machine. But I went in and cleared the JWS cache, and also made sure that the EAR was undeployed, stopped Glassfish, made sure all the generated stuff for the application had been deleted from the domain, reboot the computer, restarted Glassfish, redeployed the EAR, and got exactly the same results.

On different Linux machine (same latest available version of GF v3 of 17th, and Sun Java 1.6.0_16), I then did the same, and also got the same result, and finally, on a Windows XP machine (Sun Java 1.6.0_18), and also finished with exactly the same result again. So I would kind of think it is not actually something on my one machine.

I am including the entire JNLP launch file as reported by the JWS dialog here (less all the copyright verbiage and stuff) :-

spec="1.0+"
codebase="http://localhost:8080/___JWSappclient/___app/Suprima"
href="___dyn/SuprimaBootstrap.jarClient/___main.jnlp">

SuprimaBootstrap
Application Client

SuprimaBootstrap
SuprimaBootstrap







The first two lines of the tag

while the I would expect the property "client.facade.jar.path" to have a value of "Suprima/SuprimaBootstrapClient.jar", instead of what it is.

Just as an additional side-show, on deployment, the server log also shows a couple of other errors before declaring that it has deployed the app client as in :-
INFO: ACDEPL103: Java Web Start services started for the app client Suprima/SuprimaBootstrap.jar (contextRoot: /Suprima/SuprimaBootstrap)

These two similar errors are related to two additional library jars that are supposed to included with the app client (let's call them lib1.jar and lib2.jar). They are :-
WARNING: ACDEPL112: Error attempting to process extensions from the manifest of JAR file /home/steve/glassfishv3/glassfish/domains/domain1/applications/Suprima/lib1.jar; ignoring it and continuing
java.util.zip.ZipException: error in opening zip file
at java.util.zip.ZipFile.open(Native Method)
at java.util.zip.ZipFile.(ZipFile.java:114)
at java.util.jar.JarFile.(JarFile.java:133)
at java.util.jar.JarFile.(JarFile.java:97)
at org.glassfish.appclient.server.core.jws.ExtensionFileManager.findExtensionTransitiveClosure(ExtensionFileManager.java:264)
at org.glassfish.appclient.server.core.jws.JavaWebStartInfo.processExtensionReferences(JavaWebStartInfo.java:331)
and a similar one for lib2.jar, basically because these two library jars are indeed, not to be found where the code is thinking they are.

Regards,

Steve.

tjquinn
Offline
Joined: 2005-03-30

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

suttridge_farm
Offline
Joined: 2006-01-27

Hi Tim,

OK, I decided to start from scratch this time, with the smallest possible example, the ear of which should be attached.

Steps (using NetBeans 6.9M1) :-
1. Create new enterprise application (TestServer).
2. Create new application client (TestApp) tht has only got empty main class, which is part of TestServer.
3. Build.
4. Deploy (by using the Admin console of GF v3 with "Packaged File to Be Uploaded to the Server").
5. Point browser to http://localhost:8080/TestServer/TestApp
6. Fails to start with same kind of error.

Can't be any simpler than that.

Regards,

Steve.

tjquinn
Offline
Joined: 2005-03-30

Thanks for the sample.

This is officially weird now. I can successfully deploy the test EAR you posted on my system, using both a build from my workspace and an installation from the 17 March nightly build download.

This worked for me using Mac OS X 10.5.8 (Leopard) and Java 1.6.0_17 (the Apple Java SE implementation). It also worked for me using Windows XP with Java 1.6.0_18 and _17 with the same GlassFish download.

I did not try using NetBeans 6.9M1 to create or build or deploy the app. Did you try deploying the test app using asadmin deploy and see the same error?

By the way, just so I'm clear about this, the signing will occur on the first attempted access to the signed file as opposed to during deployment itself.

Is there any chance that on the systems where you see the signing error that GlassFish might have been installed under one user (root, for example) but is started under another, and so that file protections on the generated tree might be preventing the signing from working?

As you can tell, I'm running out of plausible theories as to what the problem might be.

- Tim

suttridge_farm
Offline
Joined: 2006-01-27

Hi Tim,

Yup, weird it is. I can confirm that all file protections are all OK, since everything was installed, is running, under one user (both Linux & Windows). But I've been investigating further ...

I downloaded a nightly of Glassfish v3.1 of the 20th March. I could correctly deploy and run my test application on this version - no problem at all. But (there's always a but), when I copied some third-party jars into the lib/ext sub-directory of the domain, I again find problems.

Just to explain the history of my initial problems - I started with the final Glassfish V3.0 release, and have kept it up-to-date with the updatetool. This reports the component Glassfish AppClient as version 3.0.1-9 dated 03/17/2010. This is the version i first tried out, and got the errors as reported initially. Now, with the nightly GF V3.1, the AppClient component has the version 3.1-1, dated 03/20/2010.

Some of the 3rd party jars are things like Bouncy Castle, Joda Time, etc. If we leave the GF 3.0 version behind, and just concentrate on 3.1, then my TestServer application deploys and runs perfectly, as long as I do not have these 3rd party libraries in the domain's lib/ext sub-directory. If I install them there, then the Java Web Start fails (after downloading quite a lot of other jars), because it says it cannot access the resource bcprov-jdk16-145.jar (Bouncy Castle). If I remove this library, then it fails again because it cannot access the Joda Time library. Basically, it fails on the first library in lib/ext that it encounters. Note that between making any changes, I always undeploy, stop Glassfish, clear the JWS cache, and then restart and redeploy - just to make sure that everything starts from scratch again.

Now the thing is that my little test application does not reference these libraries at all, so I'm not sure why the app-client would even want to download them anyway.

Regards, Steve.

tjquinn
Offline
Joined: 2005-03-30

The business with the JARs in the domain's lib/ext directory could be an issue.

Let me look into that aspect further. Obviously if the application does not refer to any extension libraries then their presence in lib/ext should not affect anything.

- Tim

tjquinn
Offline
Joined: 2005-03-30

I can reproduce the problem with an extension library JAR in ${domainDir}/lib/ext.

The __system.jnlp refers to the extension JAR so that, if the client needs it, it's available. But that means that Java Web Start will try to download it regardless.

So there are two issues - one is the unnecessary downloading of extension JARs that are not used by a given client. That's a convenience/performance issue. The other is that the server is not able to respond to the request from Java Web Start to download the extension, which is a functionality problem.

I have opened Issue 11713 (https://glassfish.dev.java.net/issues/show_bug.cgi?id=11713) to track this.

suttridge_farm
Offline
Joined: 2006-01-27

Hi Tim,

Thanks for the help so far. I can report that I started out with 18 extension library jars, and there was only a problem with 3 of the 18 - when I removed the 3 that were being complained about, the application launched OK again. However, I cannot see any pattern in why specifically those 3 were causing a problem (Bouncy Castle, Joda Time, and Commons Logging 1.1.1).
Sorry to keep torturing you, but I have two more woes with this issue :-

Woe number 1 : Using the same little test ear (with no extension libs), start Glassfish V3.1, deploy the test ear via the admin console, launch the test app-client from a browser - all OK. Now shut down Glassfish, leaving the test ear deployed. Start Glassfish again. Use browser to launch the app-client - browser instantly gets 404 error - resource not found. No errors or messages in the server log at all. I tried various combinations of this - restarting the browser, clearing the JWS cache, always a 404. The only way to get rid of it is to undeploy the test ear and redeploy it again.

Woe number 2 : Attached is another small test ear (TestServer.ear), which is the same as the first, except now the app-client part has another simple Java library jar, called TestLib, upon which it depends, but the test lib is packaged with the TestApp (as opposed to being placed in the lib/ext sub-directory of the domain. Upon deploying the ear, the server reports the following problem :-
WARNING: ACDEPL112: The following extensions or libraries are referenced from the manifest of /home/steve/glassfishv31/glassfish/domains/domain1/applications/TestServer/TestApp.jar but were not found where indicated: TestLib.jar ; ignoring and continuing

This is not really a show-stopper, because the ear deploys successfully, and the app-client can be launched and run successfully - but it still sort of indicates that things are not being found.

I'll go away after these last two things are solved - promise !!

Thanks,

Steve.

tjquinn
Offline
Joined: 2005-03-30

Steve,

I have some good news and some less good news.

1. (good news) I have checked in changes to fix the original problem with optional extension libraries in ${domainDir}/lib/ext always being downloaded for every app client launched using Java Web Start (and the URL being incorrect so the JAR could never be downloaded). These changes should be available with the next nightly build of GlassFish 3.1.

As for your latest woes...

2. (good news or not so good news, depending on how you look at it) I cannot reproduce Woe #1. I was able to follow your sequence in Woe #1 and I saw no problems at all. I could launch the client the second time, after the server restart, successfully.

One possibility - but it would require quite a different set of steps from what you described - is if during deployment the Java Web Start enabled box was left unchecked. (In my opinion it should be checked, because that's the default for command-line deployment, but that's a different issue.) In that case the deployment will succeed but attempts to launch the client using Java Web Start will fail with a 404 error.

Another possibility - an unlikely one I think - is that my recent changes to fix the extension library problem somehow affected this behavior too.

3. (good news) Woe #2 happens because the app client JAR's manifest contains this:

Class-Path: TestLib.jar lib/TestLib.jar

Because only the JAR in the lib directory is actually present in the EAR, deployment issues the warning about the [i]other[/i] JAR - the one at the top-level - because you have said your client depends on it but that JAR is absent.

- Tim