Tim Quinn wrote:
> *1. Difference in the contents of the "deploy --retrieve" and
> "get-client-stubs" download directory *
>
> In v2 when the user uses "deploy --retreive" or "get-client-stubs,"
> GlassFish downloads the entire cooked JAR which contains all app clients
> in the EAR and any required library JARs. It places this one umbrella
> cooked JAR into the directory which the user specified on the command.
> The use can easily copy the downloaded file anywhere on that system or
> any other system.
>
> In the v3 proposal - also mentioned briefly during the review - we could
> add the optional "--client client-name" option to the deploy and
> get-client-stubs commands. (The client-name could also be a
> comma-separated list of client names.) GlassFish would download to the
> specified directory the cooked JAR and library JARs for the client or
> clients requested. In the absence of the option GlassFish would
> download the cooked JARs for all clients (and relevant library JARs) in
> the specified application.
>
> What is stored in the download directory would be different from v2.
> Users who might be accustomed to copying the single downloaded file to
> other places would need to change. We have never published or
> documented the contents of that directory, but people might still have
> made assumptions about what's there.
Let me make sure I understand what you're proposing...
If my ear file contains appclient1.jar and appclient2.jar, which both
depend on common.jar, then the download directory would contain
appclient1.jar, appclient2.jar, and common.jar?
Would appclient1.jar and appclient2.jar be exactly the original versions
from my ear file? I assume not. I assume you're processing them in
some way to at least add the information the ACC needs to start the app.
I also assume that appclient1.jar and appclient2.jar would have Class-Path
manifest entries that reference common.jar, correct? So if I run them in
place (or copy the entire download directory), the dependencies will be
found.
I think that's all fine, but there's another alternative to consider.
There's some open source technology (whose name I can't remember) that
allows you to add a bunch of dependent jar files into a single jar file,
along with a "starter" program that sets up a special class loader that
allows loading classes from a jar file within the jar file, and then
runs your app. That would allow you to bundle the original, unchanged,
appclient1.jar and common.jar into a new appclient1.jar that would run
the app from that single jar file.
> *2. Requiring the user indicate where the ACC is at launch time when
> using "java -jar cookedAC.jar"*
Are you assuming that the entire app server is installed separately on
the client, and that the application client needs to specify the
location of the app client container within that full app server
installation?
Is it not possible to bundle the parts of the app client container
that are needed and include them in the download directory? (Wouldn't
that be the same classes delivered to a web start client?) And given
the technology referenced above, couldn't they all be bundled into a
single jar file? (Depending on the size, that may not be a good idea.)
Another alternative you don't list is the use of the "appclient" command
to run the app client. If I could just replace the "java" command with
the "appclient" command, and all other arguments would be the same, this
would seem to be an easy way to run an app client. Of course, that
depends on a separate installation of the appclient command and dependencies.
(Yes, I know some people don't like this, because they trust the "java"
command and they don't want to use a different command to run their
applications. Those people would need to use one of your other approaches,
and maybe we don't need to worry so much that it's convenient.)