Thanks to Shreedar for circulating this for wider distribution, and most
of all thanks to Ryan for taking the time to write up your thoughts.
Currently I'm the lead for the app client container. I've inserted some
responses below.
Shreedhar Ganapathy wrote:
> Forwarding to users alias for broader discussion. This is very useful
> feedback. Worth discussing either on the users alias or on the forum.
>
> -------- Original Message --------
> Subject: Application client container suggestions / feedback.
> Date: Fri, 02 Feb 2007 13:08:45 -0600
> From: Ryan <ryan.j_at_vacode.com>
> Reply-To: feedback_at_glassfish.dev.java.net
> To: feedback_at_glassfish.dev.java.net
>
>
>
> Hi,
>
> This got a little bit long. It's not a rant, it's not a complaint, it's
> not criticism. It's simply my point of view as an application developer.
>
> If you think this has the potential to create a useful discussion feel
> free to post it / forward it wherever you like.
>
> I've spent most of my day working with the Glassfish ACC (the command
> line invoked application client container) and wanted to provide some
> feedback. I'll start by saying that I really like the Java Web Start
> feature built into Glassfish and think it would make a great addition to
> the specification.
Thanks for the kind words. There is already some thought of adding this
as a spec requirement.
> Also, if I've overlooked any existing features of
> the ACC, I'd love to hear from you.
>
> To give a little background, I'm working on deployment and would like to
> deploy an application client using a standalone installer. I downloaded
> a trial version of install4j and it seems to be a really good fit for us.
>
> I really like the JavaEE platform and consider it the best technology
> available for creating network based applications (thick clients). I
> also think it's the perfect platform for creating hosted applications
> (web based applications, subscription applications; whatever you like to
> call them). I also think that complexities in application deployment
> (standalone clients and application clients) are partially responsible
> for Java's lack of success on the desktop. There's been a lot of
> improvement over the last couple years, but I still think there's room
> for more.
>
> Anyway, here are a few of the issues that are deterring me from working
> with the ACC.
>
> My main concern is that when I'm using the ACC there is a total loss of
> control when dealing with application startup. In my opinion, this is a
> major issue. The ACC is launched before my application and loads my
> application after the ACC has started successfully. There are a few
> things that concern me about such an approach:
>
> First, I'm not able to provide any feedback to the user while the ACC is
> starting up. I use an AMD Athlon 1GHz with 256MB of RAM and Windows
> 2000 as a (very) low end test machine and, between the JRE and the ACC,
> it takes a tiny sample application with a single screen 17 seconds to
> load. By itself this isn't a real major issue for me since I'm able to
> use the splash functionality of the JRE version 6.
>
Good point. See some more responses below with your discussion of the
helper.
> Second, there is no way for me to deal with exceptions that occur during
> ACC startup. This is also a problem that bleeds over into the Java Web
> Start functionality and is, for me at least, the main reason the ACC
> isn't a practical deployment solution. If my application fails to start
> and gives no feedback to the user they're going to get upset and it's
> difficult to diagnose the problem and support the application.
>
I see at least two aspects to this: errors during the ACC start-up
itself (as opposed to the client) and error handling and output in
general during Java Web Start launches.
If by dealing with exceptions you mean displaying and/or logging them, I
agree. If by dealing with them you mean providing code that might
detect them and take some recovery action, that I think is less likely
simply because failures during ACC's start-up are probably not
conditions that user-provided logic can recover from reasonably.
Currently, during a launch using the appclient script, any exceptions
will be written to System.err which - if the user sees and has access to
the console window - would give some idea that a problem has occurred,
admittedly an unfriendly one for a GUI client. And if you suppress the
command window during the launch of the client then that output is not
even accessible. We should address that.
As for Java Web Start, for our initial implementation we made a
conscious decision to keep app client launches as close as possible to
the Java Web Start model. This includes relying on Java Web Start's
tracing and logging features - which by default are turned off. Even
when tracing is turned on you have to know where to look for the trace
file. Frankly, we also wanted to avoid building too much additional
functionality into the Java Web Start support until we had feedback from
users to help identify the areas where we should invest time and effort
going forward. Feedback like yours is invaluable and exactly what we
were hoping to get.
Your feedback and that from others is saying pretty clearly that we need
to do better on this. Time and resources allowing, I would like to
provide a better out-of-the-box way of handling exceptions and output as
well, perhaps, as allowing a user-supplied helper class as you've
suggested. This would be particularly helpful, I think, with Java Web
Start launches.
> Third, there is no way for me to set ACC related variables at runtime.
> The main variable I'd like to set (or override) is for the hostname / ip
> address of the application server. Consider this scenario from the
> perspective of a hosted application. The application server runs
> several domains, one for each customer, and a single, polished
> application installer is distributed to everyone. Right now there would
> only be two options for adjusting the hostname variable without
> distributing a secondary application for the sole purpose of providing a
> front-end to sun-acc.xml. The first would be to customize the installer
> to edit sun-acc.xml during installation. The second would be to edit
> sun-acc.xml by hand after the installation. Editing by hand is not a
> practical solution if the application is deployed to regular users, and
> editing during installation would require the user to re-install every
> time they wanted to connect to a different server. I'd rather have the
> application server hostname as an editable field on an initial login
> screen or as a user preference.
>
This has come up before and is something I'd really like to address.
The sun-acc.xml file has always been intended as an example file that
users (administrators, typically) would revise to suit their purposes.
I'm not sure this intent has been documented as clearly as it might have
been! Even so, the use case you've described shares this requirement
with a few others we have heard about. To satisfy a number of related
needs we may consider allowing a way to specify this on the command line
(which could be built into a short-cut, for instance) or similar to what
you've said involving a user-supplied helper class in some way.
> Fourth, the libraries / dependencies for the ACC are fairly
> disorganised. 30MB of libraries seems like a lot and it's difficult to
> determine what is actually needed. For example, if I write a client
> that doesn't use messaging it would be nice if it were possible to
> remove the related libraries from the ACC. If the current libraries are
> a necessary evil maybe it would be possible to combine them into
> distinct categories (ie: web services, messaging, etc).
>
This is a place I'd like us to really improve. The footprint of the ACC
is much too large and does not need to be so overwhelming. Luckily,
installing the required files on a client is a one-time thing (until
updates need to be installed, of course) and we've structure the Java
Web Start support so that different app clients can share the same
cached libraries. Still, when a user first launches a client using Java
Web Start it can be frustrating watching the progress bar as all those
bits are downloaded from the server.
There are a couple of ways we can go at this. One, there are just lots
of bits brought over today that are not needed. Another, not every
client needs every segment of the runtime. The ideal would be for the
client-side footprint to be so lean that the selectivity you describe -
excluding libraries that support features that are needed - would not
even be necessary...one small JAR and that's it. Whether we can get
there remains to be seen, but that's where I'd like to see us aim.
> Fifth, being forced to build the ACC for each platform I'd like to
> target seems to go against the 'write once run anywhere' nature of Java.
> However, my main concern is that it forces me to build, test and
> maintain several application client containers. Realistically I'd only
> need to build two; one for windows and one for linux, but it would be a
> lot more appealing if it were possible to download pre-built, pre-tested
> ACCs, at least for the most popular target platforms.
>
If I understand your point correctly, I think this is mostly due to the
fact that the script names and script contents are platform-dependent
(appclient.bat for Windows vs. appclient for non-Windows, etc.). We
could certainly look at ways of moving away from scripts for the
client-side and relying only on Java - or at least providing both
variants of client-side scripts regardless of the platform so at least
the construction of the client installation package would be consistent
across platforms.
Did I understand your point fully?
> Finally, and I'm probably just being picky now, naming the ACC
> appclient.jar when developers are creating 'application clients' may be
> confusing to some people. It would make it simpler to understand the
> idea behind the ACC if it were name more descriptively. Something like
> appclientcontainer.jar would probably eliminate a lot of confusion.
>
Yes, I agree.
> The current design of the ACC in Glassfish is very close to being an
> ideal solution, but could use a few tweaks. These are things I think
> that could be done to make the ACC more application developer friendly:
>
> 1. Provide downloadable, pre-build, tested ACC libraries for as many
> target platforms as possible.
>
Or how about one that works anywhere?
> 2. Clean up the libraries / dependencies. The ACC should be distributed
> as a single .jar or a small number of .jar[s] that make it easy to
> determine what they are supporting (ie: acc-web-services.jar,
> acc-messaging.jar, acc-security.jar, etc).
I agree wholeheartedly.
> I also think the ACC related
> configuration is in the wrong place. It would be more logical, at least
> to me, to have all ACC related configuration information bundled with
> the application client .jar (ie: my-app-client.jar). This would
> eliminate the necessity of uncompressing the ACC .jar (appclient.jar) to
> edit configuration parameters.
We will look at this and see how much we can improve. I should point
out that in the Java Web Start case, at least, the configuration of
which host to contact is taken care of automatically...it's the same
host (or other instances in the same cluster in an EE-cluster profile)
from which the user retrieved the JNLP document for launching the app in
the first place.
> Finally, the configuration should be
> platform independent; this is Java.
>
Just so I'm sure I understand you, can you describe how you see
configuration that's platform dependent now that should be
platform-independent?
> 3. Give the application developer more control over the startup process.
> I think this could be done fairly easily. The current behavior of the
> ACC could be left as is and be the default behavior, but it should be
> possible include some type of ACCHelper class in the ACC configuration.
> Such a class could be invoked by the ACC and be used by the application
> developer to provide runtime configuration information, to control when
> the main ACC logic is executed and to control when the client
> application is invoked. To begin with, even a very simple, extendable
> default class would do. Here's an example:
>
> public class DefaultAccHelper
> {
> public DefaultAccHelper() {
> try {
> initAcc();
> initClientApp();
> }
>
> // Could actually catch multiple exception types
> // and exit with different exit codes.
> catch(Exception e) {
> System.exit(1);
> }
> }
>
> // Could actually throw multiple exception types
> public void initAcc() throws Exception {
> // main ACC startup logic
> }
>
> public void initClientApp() throws Exception {
> // invoke the main class of the target client application
> }
>
> public String getOrbHost() {
> // return orb host from sun-acc.xml
> }
>
> public String getOrbPort() {
> // return orb port from sun-acc.xml
> }
> }
>
> public class MyAccHelper extends DefaultAccHelper
> {
> private JFrame loginWithEditableOrbHostFieldAndConnectButton;
> private String orbHost;
>
> public MyAccHelper() {
> initLoginFrame();
> }
>
> private void initLoginFrame() {
> // Instantiate login frame
> // Add listener to connect button
> // Show login frame using EDT (Event Dispatch Thread)
> }
>
> private void connectActionPerformed() {
> // start progress indicator using EDT
> // validate orb host field
> // set orb host property
> try {
> initAcc();
> // access restricted resource
> // to force authentication
> cleanUp();
> initClientApp();
> }
> catch(Exception e) {
> // inform the user of startup failure
> cleanUp();
> System.exit(1);
> }
> }
>
> private void cleanUp() {
> // dispose of UI resources using EDT
> }
>
> String getOrbHost() {
> return(orbHost);
> }
> }
>
> Hopefully that example isn't too ugly / hackish and you can get an idea
> of the functionality I'd like to see. As an application developer I
> want to control everything that affects my users. I want them to see a
> splash screen and a progress indicator as the bulk of my client
> application is loading (including the ACC) and I want to control when,
> if and how all exceptions (or startup errors) are presented to the user.
>
I definitely see the merits in providing the developer this kind of
access. Off the top of my head, I think if we were to add something
like this to the ACC it might take the form of a callback mechanism, in
which the GlassFish-provided ACC main class remains "in charge" but
would call out to an optional developer-provided class to provide pieces
of information, handle an exception, etc. We'll need to give this some
thought to what spec changes might be needed along these lines as well,
apart from implementation changes in GlassFish itself.
> I've looked at extending the com.sun.enterprise.appclient.Main class to
> accomplish this, but there is too much logic in the constructor. I'm
> assuming that com.sun.enterprise.appclient.MainWithModuleSupport does
> the same thing as com.sun.enterprise.appclient.Main, but in a more
> modular fashion, although even that class is probably too complex for
> the average application developer to extend.
>
Yes. In fact the Main class is actually obsolete but has remained in
the repository temporarily. But it's certainly true that
MainWithModuleSupport was not intended for extension. The helper
class/callback approach seems a better route for all concerned, but
given the situation you faced I see why you looked at that.
> Thanks for listening,
>
And thanks to you for taking the time to tell us what you're thinking
and how you're using the software, and for offering the constructive
suggestions for improvements.
- Tim