users@glassfish.java.net

Re: Runnging application client as web start

From: <forums_at_java.net>
Date: Fri, 26 Oct 2012 14:37:27 -0500 (CDT)

I'm glad to hear you have it working! About placing the app client module in
an EAR... If you package the app client in the EAR then you do need to get
the correct JAR files onto the client system, but only once. You can do this
manually when you deploy the EAR ("asadmin deploy --retrieve localDir ...")
or after you deploy the EAR ("asadmin get-client-stubs ..."). Then you can
use the appclient command on the client. Running the client uses the JARs on
the remote system - it does NOT retrieve any files from the server at
runtime. Of course, if you deploy a new version of the EAR with different
code in the client then you need to get the new client files to the remote
client system again. As you know you can have the files delivered to the
client system automatically for you if you launch the client using Java Web
Start. One advantage is that Java Web Start will download any files that are
newer on the server automatically; the end user does not need to worry about
that. Plus, Java Web Start does not download any file that has not changed.
This gives the best of both worlds: Java Web Start makes sure the client
files are up-to-date but does not copy any file that is already current.
About packaging... In my example in NetBeans I added the library project to
the EAR project as a library. Then in the Build->Packaging part of the EAR
project's properties I told NetBeans to package the library in the /lib
directory. The Java EE spec requires all JARs there to be accessible to all
modules (the EJB and the app client modules in our example) so that makes the
library JAR available to both at runtime. We still need to add the library
project as a library to the separate EJB NetBeans project and the app client
NetBeans project so they will compile correctly, but we DO NOT want NetBeans
to package that library with either of those modules directly because we have
packaged it into the EAR. I am not sure, but I think the warning you got
during deployment might have been because the library JAR was being processed
as part of the EJB module because you had packaged the library with the EJB
module. There are no EJBs in the library JAR so that might be why GlassFish
reported the warning. You can make the POJO classes available to both modules
by including them in the same library that contains the EJB remote interface
or by placing them in a different library, whichever makes more sense to you.
In the second case, make sure to add the second library also as a library to
the EJB and the app client modules (for compiling but NOT for packaging) and
then add the second library as a library to the EAR also and tell NetBeans to
put it also in the /lib directory of the EAR. As with the first library,
GlassFish will then make the second library available to all modules in the
EAR. Ideally, you want each class in exactly one JAR and accessible to only
those modules that really need to use it. Splitting the classes up as I
described takes a little more work but it's a good design. Let us know if we
can be of more help. Best of luck in your further use of GlassFish! - Tim

--
[Message sent by forum member 'tjquinn']
View Post: http://forums.java.net/node/891603