users@glassfish.java.net

RE: Problem with WebStart

From: Piero Filippin <filippinp_at_yahoo.co.uk>
Date: Fri, 28 Sep 2007 00:20:14 +0100

I am following issue 3701, looks like things are proceding much faster than I expected!
I think the suggested solution would be more than enough to satisfy most requirements.

As a general set of suggestions (I think they are trivial to implement) for the JavaWS deployement, to save additional bandwidth:

Instead of generating a fat jar with all the required client jars, what about making them available as separate downloads? This would enhance caching a lot, and in addition this would benefit multiple clients sharing components (I think that common components are very common if you supply more than one client).

Another good thing would be to use JavaWS 6 lazy downloader (it just matter of "enhancing" the jnlp file) so GF runtime components are downloaded when (and only if) needed.
As an example for my clients to run I see a toplink jar is included, but my client is not using any toplink class. If you specify the toplink jar with the attribute download="lazy" (actually is more complex than that, but this will be anyway something static) this will be downloaded as soon as my client uses one of the toplink classes (never in my case, saving some mb).

Piero



-----Original Message-----
From: Piero Filippin <filippinp_at_yahoo.co.uk>
Sent: 27 September 2007 00:59
To: users_at_glassfish.dev.java.net
Subject: RE: Problem with WebStart

Tim,
Thank you a lot for the explanation.

I think I got a little bit confused initially, as in my eyes it still not clear what happen inside GF (the idea of the containers, how classes are made visible etc).

I designed my app to be self contained and to expose only the ejb, everything is passed using strings (xml) and integers. My main goal is to design a web app with only simple calls to the backend (login, create employee, create company, assign employee to company etc) without the need for the web app to implement any logic (only presentation).
Designing a java client is only a temporary workaround to speed up the developement (I have to demonstate to a large audience on the 10th of Oct), and I was a little bit offset by the fact that after all the time I spent designing interfaces and encapsulation I found out that everything is sent to the client!

GF documentation is not bad but it is a little bit too large... By the time I will finish reading it GF v10 will be on its way!
 
Piero

-----Original Message-----
From: glassfish_at_javadesktop.org
Sent: 26 September 2007 23:34
To: users_at_glassfish.dev.java.net
Subject: Re: Problem with WebStart

> > In fact, this is not a problem restricted to the
> Java Web Start support for app clients but applies to
> app clients regardless of how they are launched.
> >
> >
> I don't understand what you mean:

I used the term "app client" to refer to a Java EE app client that runs inside the client-side app client container (ACC) that is part of GlassFish. You are describing what is often called a "Java client" that runs independently from the ACC. (You would think by now I would be in the habit of being clearer about what I mean, because these terms related to clients and app clients and stand-alone app clients often mean different things to different people.)

> I still do not see the need - in my understanding
> only the interface is
> needed, this is why you have to create an annotat