Hello, everyone.
I apologize in advance for the length of this message.
Fairly recently we held the review of the app client container
one-pager. This is the version we reviewed:
http://wiki.glassfish.java.net/Wiki.jsp?page=Gfv3AppclientcontainerOnepager&version=3
; I have already begun (but not yet finished) editing the one-pager on
the wiki since then so the current version is a work-in-progress.
Several good comments and suggestions surfaced during the review and
this message is a response to some of those.
I'd like to get people's thoughts on a possible approach for v3 app
clients that will allow us to meet several requirements while
introducing only some change in external behavior. Of course I'll
welcome feedback on the internal design of the approach but I'd like to
focus for the moment on the externally-visible aspects on which
one-pagers focus.
There are two main points:
1. What format the generated ("cooked") JAR file will have and what are
the implications on what is downloaded during the "deploy --retrieve"
and "get-client-stubs" commands.
2. How users would launch app clients using regular java command syntax.
First, brief background. As we discussed during the review, GlassFish
v2 creates a generated ("cooked") JAR file that includes any generated
stubs (this is no longer the default - dynamic proxies are the default)
and any required library JARs. If an EAR contains multiple app clients
then the cooked JAR contains all the app clients. At launch time the
user chooses which to run using one of several command-line options.
During the review we discussed briefly how v3 could instead generate a
separate cooked JAR for each app client in an EAR. There are advantages
to doing this: it allows a fairly simple approach for allowing users to
launch app clients with a standard java command line (see below) and it
lets us support the Java SE 6 splash screen feature very simply, to name
two.
Here are some implications for what's externally visible:
*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.
Note that with the new approach app client launches would be faster than
in v2. The v2 ACC must first expand the umbrella cooked JAR before
building a class path from its contents; v3 would require no such expansion.
*2. Requiring the user indicate where the ACC is at launch time when
using "java -jar cookedAC.jar"*
Supporting the ability to launch app clients using the standard java
command
java -jar cookedJar.jar
requires the user to indicate at launch time where the ACC JAR resides
(so it can be on the class path).
The appclient script knows this information - it is recorded in a config
file when GF is installed. But if the user launches with a java command
we have no way to find this out without the user's help. The user
cannot use the -classpath option or the CLASSPATH env. variable - the
Java launcher ignores these during a java -jar execution.
There are at several choices - perhaps more - for how the user could
convey this.
(1) Do not use java -jar but instead use java -classpath and require the
user to include the cooked JAR and the ACC JAR in the class path, and
specify the GlassFish-provided main program class in the cooked JAR as
the main class on the command line. This seems quite awkward.
(2) Specify a command-line argument; "-accdir path-to-acc-dir" for
example. We would then need to provide our own main program in the
cooked app client JAR that would detect this and create a class loader
with the cooked JAR and the ACC JAR from the accdir on its class path.
The rest of the execution would rely on that class loader.
(3) Specify the ACC as a Java agent;
"-javaagent:path-to-acc-dir/gf-acc.jar" for example. The agent would
not need to transform any byte code; it's main purpose is to get the ACC
JAR on the system class path, which the Java launcher itself does for
all agents.
Although clearly v2 uses no agent, the net effect of this approach is
the same as in the v2 appclient script: the system classpath includes
the GlassFish JARs (appserv-rt, etc.)
Choice (3) has the added advantage of allowing users to cleanly separate
ACC options as agent options rather than mix them in with arguments
intended for the app client itself. For example:
java -javaagent:path-to-acc-dir/gf-acc.jar=-server=myHost:3700 -jar
myCookedAC.jar [args-to-client...]
instead of
java -jar myCookedAC.jar -server myHost:3700 -accdir path-to-acc-dir
[args-to-client...]
in which the ACC options are mixed in with the arguments to the client.
I'll look forward to hearing people's thoughts on these. Again,
although I welcome ideas on the design my main concern at the moment is
about the changes and additions to what would be externally visible.
Thanks.
- Tim