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. 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.
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.
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.
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).
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.
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.
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.
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 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. Finally, the configuration should be
platform independent; this is Java.
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'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.
Thanks for listening,
Ryan Jaeb
---------------------------------------------------------------------
To unsubscribe, e-mail: feedback-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: feedback-help_at_glassfish.dev.java.net