|
Replies:
7
-
Last Post:
Jul 23, 2009 12:54 AM
by: morettoni
|
|
|
|
|
|
|
If you deploy app clients we need your feedback on some choices in v3!
Posted:
Feb 22, 2009 8:11 PM
|
|
|
We want to improve several things with app clients, in particular the launching performance when you use the appclient script. (This topic does NOT apply to the Java Web Start support for app clients in GlassFish.)
We have some choices to make and we want your feedback. The options have advantages and disadvantages. Please read the summary below and reply to this entry to let us know what you think. If you see other pros and cons or think of other options we should consider please mention them.
In v2, when you deploy an app client or an EAR containing an app client, GlassFish generates a new JAR file containing the app client JAR itself, all JARs listed in the Class-Path of its manifest, and all JARs in the EAR's library directory
When you use the "deploy --retrieve" or "get-client-stubs" commands, GlassFish downloads this generated JAR file into the end-user's directory that is specified on the command.
During an app client launch the GlassFish app client container (ACC) expands the downloaded JAR into a temporary directory, then builds a class path including the JARs in that temp directory. This is how GlassFish makes sure that you app client has access to all the classes and resources it needs. The expansion occurs into a new temporary directory every time an end-user launches an app.
We have received complaints that start-up time is too long, especially for larger app clients or clients using large library JARs, and part of the reason is this expansion step. We are considering how to address this in v3.
Option 1 - Just-in-time extraction of nested JARs from the enclosing JAR
Deployment would generate a JAR as in v2. But the ACC would not expand the entire downloaded JAR at the start of the launch. Instead it would extract an inner JAR to the temp directory only when the app client needs a class or resource from that JAR.
Option 2 -No enclosing JAR
The download that occurs as part of "deploy --retrieve" or "get-client-stubs" would deposit the individual JARs into the download directory. The ACC would not expand any JAR before launching the client.
Pros and Cons
Because option 1 delivers an enclosing JAR as in v2, if you have been copying the single downloaded file to other places that will continue to work.
Depending on the specifics of each app client, the just-in-time extraction can spread the overhead of extracting the nested JARs over the run of the client. If a particular JAR is never needed during a particular run it would never be extracted.
It is possible, of course, that a particular client might need something from all of the JARs early in the run, so the net improvement in performance would be minimal in such cases with Option 1.
Option 2 skips all expansion and would even speed up deployment by avoiding the creation of the enclosing JAR. There are at least two disadvantages:
a. If you have scripts (or work habits) based on v2 which involve downloading the enclosing JAR and then copying it elsewhere, those would break in Option 2. You would need to copy *all* of the files from the download directory to the new location.
b. Downloading two or more different app clients into the same directory works in v2 without problem. This could cause problems in Option 2 if JARs of the same name appeared in different clients. GlassFish could detect such a collision but they might or might not be OK. For example, downloading a new version of a client into the same directory would be likely to cause collisions but overwriting the old files is probably OK. Doing so when downloading different clients to the same directory is probably wrong.
One possibility: GlassFish v3 could insist that the download directory be empty (or non-existent) before using it. But that's a change from v2 behavior.
In short, following Option 2 would give better improvement in but at the cost of breaking some scenarios that work in GlassFish v2.
Thanks for staying with me through this long description. Now, it's your turn. Please post your thoughts, ideas, reactions, and comments as replies here to this topic.
Thanks in advance.
- Tim
|
|
|
|
|
|
|
Re: If you deploy app clients we need your feedback on some choices in v3!
Posted:
Feb 23, 2009 1:01 AM
in response to: tjquinn
|
|
|
Hi Tim,
It's nice to see you guys working on improving app client deployment for v3. If I had to choose between the two options you've outlined, I'd prefer the second; multiple files instead of one large file. My motivation for selecting that option is in part because I hope it would make it easier for me to discard the resources I don't need.
Either option would be fine with me though. If you do end up using a single file and doing 'as needed' unpacking would you consider adding an option to force everything to be unpacked on startup?
Edit: I just read this:
http://wiki.glassfish.java.net/Wiki.jsp?page=gfv3-appclientcontainer-onepager
...and the embedded ACC section looks like one giant leap in the direction I was hoping the client container would go. Good job guys!
The below was useless ranting (after reading the above), so I deleted it.
Message was edited by: ryan6608
|
|
|
|
|
|
|
|
|
Re: If you deploy app clients we need your feedback on some choices in v3!
Posted:
Feb 23, 2009 11:39 AM
in response to: ryan6608
|
|
|
Hi, Ryan.
Yes, I was going to mention the plans for embedded, hoping that would sound good to you!
Good idea about the expand-all-at-start option for Option 1.
- Tim
|
|
|
|
|
|
|
|
|
Re: If you deploy app clients we need your feedback on some choices in v3!
Posted:
Feb 23, 2009 11:47 AM
in response to: tjquinn
|
|
|
If I must choose one of these options, I'd like to have option 2.
But my favorite is option 3: Complete separation of deployment tasks from startup tasks! Pulling stuff from the server, exploding it on the directory, and telling the client where to find its classes is clearly part of the deployment phase and shall be done ONCE. The startup shall be actually just simple as executing java -jar client.jar (where client.jar has META-INF Class-Path: entries pointing to the needed libraries). THAT would improve startup time much more than any kind of deferred extraction. And I do not see any good argument against it, since it is what EVERY non-JavaEE application works like anyways.
Regards
Markus
|
|
|
|
|
|
|
|
|
Re: If you deploy app clients we need your feedback on some choices in v3!
Posted:
Feb 26, 2009 5:07 PM
in response to: mkarg
|
|
|
Hi, Markus.
I think we may be in "violent agreement" on this. I think you've described Option 2, at least in many respects. The Class-Path entry in the client JAR's manifest is definitely something we'll take advantage of to simplify things.
Just to clarify a few things...
Deployment in the sense you mean is, I think, deployment of the required app client bits to a given remote system, correct? Not considering the Java Web Start support for a moment, there are really three ways to deploy the client bits to a remote system:
1. As part of deploying the enterprise application to GlassFish, by specifying "deploy --retreive local-dir ..." which will retrieve the required client bits (including library JARs) into the local directory local-dir.
2. Using the "get-client-stubs" command on a remote system where you want the client bits to reside.
Note that both 1 and 2 require a subset of GlassFish be present on the system beyond what's needed for the app client container. Executing the get-client-stubs command requires some JARs on which the ACC does not depend.
3. Using 1 or 2 on some system and then transporting those client bits to the remote system(s). The remote system also needs to have the ACC bits installed at some point. (Of course, simplifying all of this is part of the value of the Java Web Start support.)
As for starting the client using java -jar, we actually are moving very close to that. If we can get the ACC bits small enough then we could include the ACC with every downloaded app client. I'm afraid that's unlikely, though, because some of the pieces ACC needs (the ORB, persistence unit support, etc.) are just too large.
We would like to support java -jar, so we're not arguing against it by any means. We are working through some options and challenges and I've done a fair amount of thinking of how we might accomplish this. There's more work to do to get there, though.
As for the start-up time, the extraction (in v2 and, if deferred, somewhat so in v3) actually does take a fair amount of time if the client or any libraries it depends on is large. So can connecting to the ORB on the server, for example. We're trying to find ways to improve anywhere we can.
And I'm very glad for the feedback.
- Tim
|
|
|
|
|
|
|
|
|
Re: If you deploy app clients we need your feedback on some choices in v3!
Posted:
Feb 28, 2009 4:13 AM
in response to: tjquinn
|
|
|
I hope it's ok if I add a little more input on this topic. I think the issue Markus was talking about was more than likely the way the build-appclient script and configuration (asenv / sun-acc.xml) of the resulting environment is set up in v2.
It's not exactly what I'd consider portable.
Don't hesitate to correct me if I'm wrong, because it's been well over a year since I've used the ACC and I'm mostly going by memory.
If I remember correctly the configuration of the v2 ACC is what really turned me away from it. Running the build-appclient script wasn't too big of a deal, but the way the appclient had to be configured was a hassle. Some of the big points for me were:
1. Absolute paths in the asenv config file.
2. Different launch scripts and configs for different platforms (win32 vs linux).
3. Having to change configuration in the sun-acc.xml file.
When I first started using the v2 ACC I had to do too much tweaking to get what I felt like was a 'portable enough' ACC that I could wrap in a traditional installer.
From what I've read, the first two points I mentioned won't be an issue anymore. The sun-acc.xml is probably a necessary evil since it looks like it mostly contains configuration information about the server that isn't guaranteed to be the same on every server.
I'm guessing things will be very close to a 'java -jar appclient.jar' exectution, but there will always be a need for a minimal amount of configuration information that's going to be required by the ACC (the target client main class, initial orb host & ports, etc).
If the ACC is being used as an entry point (ACC gets started, inits, hands off to real app), would it be possible to split and layer the configuration? By that, I mean split the configuration requirements into two categories (verbose names as examples)...
acc-non-portable-host-config.xml
acc-non-portable-runtime-config.xml
Config info like initial orb ports & hosts, logging, etc could go in the runtime-config. Other more involved settings where it's likely the defaults will suffice for most people could go in the host-config. Chances are most app developers aren't going to start thinking about some of the (host-config style) settings that we saw in the v2 sun-acc.xml file until they're getting closer to an actual deployment. At that point it would probably be better to let the person responsible for configuring the production environment supply that config info.
By layering the configuration I mean (keep) using configuration priorities similar to the way a lot of EE components are configured; command line args > hand config > default config.
It would also be nice if the app server were capable of spitting out intelligent defaults for either of those configs (ie: --get-acc-non-portable-configs). As a general rule, I don't care about that kind of stuff unless something breaks. I want to point my app client to a runtime-config (host, port, etc) and have it 'just work'.
In terms of what I consider 'portablility' I'd like to be able to build an ACC on one machine (ie: my wn32 dev machine) and use it to run app clients that connect to any app servers (ie: a linux test server accessible to others) that have my .ear deployed. Ideally I wouldn't have to build it and could just download a .jar. To me, having to build the ACC is an indication that it's adding some server specific information and is likely only going to (be guaranteed to) work with the server on which it was built.
I started to ask some questions about the embedded version of the appclient since that's what I'm really interested in, but my post is already a bit long winded. Is there any more detailed information regarding how the embedded appclient will work that anyone knows of?
|
|
|
|
|
|
|
|
|
RE: Re: If you deploy app clients we need your feedback on some choices in v3!
Posted:
Feb 28, 2009 7:39 AM
in response to: ryan6608
|
|
|
Actually I didn't even know that portability is a design target for the ACC and frankly I do not care about this type of portability at all (my clients only need to be able to talk to the GlassFish instance they belong to and nothing else; I do not see any note in the Java EE spec that any portability here is mandatory and I do not see the benefit of supporting this -- but I see drawbacks). What I want is that the install and config step has to be separated from the startup procedure to speed up things as much as possible. I thought that this is what this thread is about?
> -----Original Message-----
> From: glassfish@javadesktop.org [mailto:glassfish@javadesktop.org]
> Sent: Samstag, 28. Februar 2009 13:14
> To: users@glassfish.dev.java.net
> Subject: Re: If you deploy app clients we need your feedback on some
> choices in v3!
>
> I hope it's ok if I add a little more input on this topic. I think the
> issue Markus was talking about was more than likely the way the build-
> appclient script and configuration (asenv / sun-acc.xml) of the
> resulting environment is set up in v2.
>
> It's not exactly what I'd consider portable.
>
> Don't hesitate to correct me if I'm wrong, because it's been well over
> a year since I've used the ACC and I'm mostly going by memory.
>
> If I remember correctly the configuration of the v2 ACC is what really
> turned me away from it. Running the build-appclient script wasn't too
> big of a deal, but the way the appclient had to be configured was a
> hassle. Some of the big points for me were:
>
> 1. Absolute paths in the asenv config file.
> 2. Different launch scripts and configs for different platforms (win32
> vs linux).
> 3. Having to change configuration in the sun-acc.xml file.
>
> When I first started using the v2 ACC I had to do too much tweaking to
> get what I felt like was a 'portable enough' ACC that I could wrap in a
> traditional installer.
>
> From what I've read, the first two points I mentioned won't be an issue
> anymore. The sun-acc.xml is probably a necessary evil since it looks
> like it mostly contains configuration information about the server that
> isn't guaranteed to be the same on every server.
>
> I'm guessing things will be very close to a 'java -jar appclient.jar'
> exectution, but there will always be a need for a minimal amount of
> configuration information that's going to be required by the ACC (the
> target client main class, initial orb host & ports, etc).
>
> If the ACC is being used as an entry point (ACC gets started, inits,
> hands off to real app), would it be possible to split and layer the
> configuration? By that, I mean split the configuration requirements
> into two categories (verbose names as examples)...
>
> acc-non-portable-host-config.xml
> acc-non-portable-runtime-config.xml
>
> Config info like initial orb ports & hosts, logging, etc could go in
> the runtime-config. Other more involved settings where it's likely the
> defaults will suffice for most people could go in the host-config.
> Chances are most app developers aren't going to start thinking about
> some of the (host-config style) settings that we saw in the v2 sun-
> acc.xml file until they're getting closer to an actual deployment. At
> that point it would probably be better to let the person responsible
> for configuring the production environment supply that config info.
>
> By layering the configuration I mean (keep) using configuration
> priorities similar to the way a lot of EE components are configured;
> command line args > hand config > default config.
>
> It would also be nice if the app server were capable of spitting out
> intelligent defaults for either of those configs (ie: --get-acc-non-
> portable-configs). As a general rule, I don't care about that kind of
> stuff unless something breaks. I want to point my app client to a
> runtime-config (host, port, etc) and have it 'just work'.
>
> In terms of what I consider 'portablility' I'd like to be able to build
> an ACC on one machine (ie: my wn32 dev machine) and use it to run app
> clients that connect to any app servers (ie: a linux test server
> accessible to others) that have my .ear deployed. Ideally I wouldn't
> have to build it and could just download a .jar. To me, having to
> build the ACC is an indication that it's adding some server specific
> information and is likely only going to (be guaranteed to) work with
> the server on which it was built.
>
> I started to ask some questions about the embedded version of the
> appclient since that's what I'm really interested in, but my post is
> already a bit long winded. Is there any more detailed information
> regarding how the embedded appclient will work that anyone knows of?
> [Message sent by forum member 'ryan6608' (ryan6608)]
>
> http://forums.java.net/jive/thread.jspa?messageID=334398
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: If you deploy app clients we need your feedback on some choices in v3!
Posted:
Jul 23, 2009 12:54 AM
in response to: tjquinn
|
|
|
Hi Tim, I develope a lot of application in factory automation (using only a JavaSE platform) but for some big project we moved our software to the JavaEE platform and we used GlassFish v.2 as a default platform. All the client are based on a JavaSE+Swing interface; we need a lot of interaction with the users and we can't use the web tier to do that.
We use the web-start feature to install/use the client side, we just use a simple url like this: http://factory/startme and nothing other to do... we hope to see that easy way under GFv3 too!
--
Luca Morettoni <luca(AT)morettoni.net> | OpenSolaris SCA #OS0344
Web/BLOG: http://www.morettoni.net/ | http://twitter.com/morettoni
jugUmbria founder - https://jugUmbria.dev.java.net/ | Thawte notary
ITL-OSUG leader - http://www.opensolaris.org/os/project/itl-osug/
|
|
|
|
|
java.net RSS
