Thanks for taking the time to respond to this Tim. Here's a bit of
clarification regarding some of the areas you addressed.
I'm going to ignore Java Web Start for this reply. Even though it
shares some of these issues, I'd guess it's not something that you could
deal with easily (at least without making major changes to the Java Web
Start technology). Perhaps some of these issues should be brought to
the attention of the people that are responsible for Java Web Start.
Exception handling - You absolutely right that user provided logic is
not going to have the ability to deal with ACC exceptions. However, I'm
not too concerned with recovering from exceptions. I mainly would like
the ability to detect ACC start up failure and display an error to the
user in a manner that is consistent with the rest of my application. A
single ACC related exception would be adequate.
ACC start up scripts on different platforms - A Java solution on the
client side would be awesome. The thing that was really concerning me
with building the ACC on different platforms was a portion of the docs
that indicated there was native code that needed to be included in the
ACC. I get the impression that the only 'native code' is the platform
dependent start up scripts.
A single (Glassfish) ACC library that works everywhere would be great.
Even though I think the ACC configuration is best placed in the
application client .jar file, it really doesn't matter where it ends up.
I guess the main thing for me is that I don't like the idea of having
to extract the appclient.jar file and edit configuration files. It
makes it more difficult for me to integrate the configuration into my
build environment (ant).
When I referred to platform dependent configuration I was referring to
the 'asenv.conf' and 'asenv.bat' files in the 'conf' folder that need to
be edited.
I think some type of callback mechanism during ACC startup would work
very well. I'd really like to see callbacks for some the following:
pre initialization
post initialization
handling errors
setting acc related parameters
Consider the ACC start up from the perspective of having a start up
wizard that allows the user to specify the host (IP) on which the
application server is running.
Thanks again for the reply. I wrote a more detailed article relating to
thick clients and Java application deployment earlier this week. It's
really a re-hash of what we've discussed here, but is presented better
than my original post. If I end up posting it on the net I'll post a
link here.
Finally, I would like to thank you for your work on the current ACC
implementation for Glassfish. Even though it's not ideal for my
situation, it's the only one, in my opinion, that's even usable in
anything more than a development / testing environment.
Ryan
Tim Quinn wrote:
> 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