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 annotated
> interface and the
> bean must implement that interface!
I believe the rationale behind including the EJB submodules in the generated app client JAR file was to let the client developer have easy access to classes other than the bean implementations he or she might have packaged into the EJB JAR. I agree that it's not an ideal approach because the bean implementations come along as well.
With an eye towards your later, larger application, I see that you have opened a new issue -
https://glassfish.dev.java.net/issues/show_bug.cgi?id=3701 - thanks for doing that. Having the issue will help draw more attention to this and, with luck, get at least a usable workaround in place sooner rather than later.
- Tim
[Message sent by forum member 'tjquinn' (tjquinn)]
http://forums.java.net/jive/thread.jspa?messageID=237261
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
For additional commands, e-mail: users-help_at_glassfish.dev.java.net