|
Replies:
6
-
Last Post:
Sep 27, 2007 4:56 PM
by: tjquinn
|
|
|
|
|
|
|
Problem with WebStart
Posted:
Sep 26, 2007 7:44 AM
|
|
|
Hi,
I just noticed something "scary" - I am pretty sure this has something
to do with how my project is structured, can someone please help me
tracing what I am doing wrong?
My project EAR contains:
o EJBean jar (defining the implementation of my bean + all the
persistence classes)
o Separate Jar (defining the bean remote interface - this is the only
thing the client should know about the bean)
o Normal java app (the client)
o A bunch of jars with all my libraries required by the client.
Now, if download the client app using webstart, I receive a jar file
containing:
o The normal java app jar (the client)
o all the jars required by it (work as expected)
o The separate Jar with the bean interfaces (needed)
o the entire bean jar!
Why is the bean jar included in the webstart version? The implementation
is not needed, plus it introduces security issues as it contains all the
business logic (which a client should not allowed to know)
In addition (but this is an Eclipse problem) the EAR contains the source
code (no matter if I uncheck the "export source code" during the
export), so I am giving away the source of the bean as well!!
Piero
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
Re: Problem with WebStart
Posted:
Sep 26, 2007 8:49 AM
in response to: Piero Filippin
|
|
|
Hi, Piero.
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.
This behavior is in GlassFish to preserve an old convenience feature from earlier implementations of the app server. As you probably know, GlassFish creates a generated app client JAR containing what will really be needed to run the app client. For example, this generated app client JAR may included library JARs from the EAR.
To save developers some work the contents of EJB submodules from an EAR have also been included in the generated app client JAR for that EAR for quite a while. This allowed a developer of the client to refer to the remote interfaces (primarily) of the EJBs without having to change the app client's manifest to refer to the EJB module JAR or some other library JAR.
Other users have reported (complained!) that this greatly increases the size of the generated app client JAR file, and because the generated JAR must be expanded into a temporary directory on the client side this significantly slows down the start-up of the client.
I am not sure there is a good workaround for this given the existing code. For example, one idea might be to refactor the EJB JAR to move the sensitive classes into a separate JAR. But the EJB module would then depend on that JAR (through its manifest's Class-Path entry, for example) and the code that creates the generated app client JAR file will detect that and, because the EJB submodule is being included will follow the chain to the separate library JAR and include it also.
One possibility could be for us to add a way (perhaps via a system property setting in the domain.xml) so generated app client JARs would exclude EJB submodules. We cannot make that the default behavior (at least not immediately without advance warning) because we want to remain backward-compatible with apps that might depend on the existing behavior.
If this is a serious problem, as it sounds like it is, please open an issue (use category=deployment because that's where the generated app client JAR is created or category=standalone_client) so we can prioritize it and respond more formally.
Sorry this is creating a problem for you.
- Tim
|
|
|
|
|
|
|
|
|
Re: Problem with WebStart
Posted:
Sep 26, 2007 1:28 PM
in response to: tjquinn
|
|
|
Hi Tim
> Hi, Piero.
>
> 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 created three jars, one with the
client, one with the Bean @Remote interfaces and one with the
implementation, and I can launch the client as a standalone application
(supplying the address and the port for JNDI with -D ) just with the
interface jar and the J2EE runtime on the classpath (without the need
for the client to have any access to the implementation jar).
Obviously I must limit myself on using only standard java objects
(string an integers) as parameters and return types.
> This behavior is in GlassFish to preserve an old convenience feature from earlier implementations of the app server. As you probably know, GlassFish creates a generated app client JAR containing what will really be needed to run the app client. For example, this generated app client JAR may included library JARs from the EAR.
>
> To save developers some work the contents of EJB submodules from an EAR have also been included in the generated app client JAR for that EAR for quite a while. This allowed a developer of the client to refer to the remote interfaces (primarily) of the EJBs without having to change the app client's manifest to refer to the EJB module JAR or some other library JAR.
>
>
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!
> Other users have reported (complained!) that this greatly increases the size of the generated app client JAR file, and because the generated JAR must be expanded into a temporary directory on the client side this significantly slows down the start-up of the client.
>
>
This is not a concern for me at the moment, my application is quite
small (few Mb) compared to the runtime jar (which is cached anyway after
the first launch) and will be only used internally (fast lan connection|).
However, I am worried because I intend to use GF to develop a much
larger application, and my problem is that sending the implementation to
the client will break the security imposed by layered approach. I see GF
anf JavaEE as an extension of the object oriented approach, where the
user not only knows the method signatures and nothing else, but also has
no access at all to the .class files (in addition to many other benefits).
Take as an example a credit card processing application (not my case!):
you probably want the user to know only the methods you are allowed to
call (the public interface), but not how those methods are implemented
(as far as I know, .class files are easy to reverse engineer), as this
would expose details on the data structures and how they are used, how
they are saved on the database and eventual bugs that can be exploited!
> I am not sure there is a good workaround for this given the existing code. For example, one idea might be to refactor the EJB JAR to move the sensitive classes into a separate JAR. But the EJB module would then depend on that JAR (through its manifest's Class-Path entry, for example) and the code that creates the generated app client JAR file will detect that and, because the EJB submodule is being included will follow the chain to the separate library JAR and include it also.
>
>
Already tried - as you rightly point out, everything is sent along with
the client! I event tried putting a copy of the interface in each jar
with no luck.
> One possibility could be for us to add a way (perhaps via a system property setting in the domain.xml) so generated app client JARs would exclude EJB submodules. We cannot make that the default behavior (at least not immediately without advance warning) because we want to remain backward-compatible with apps that might depend on the existing behavior.
>
> If this is a serious problem, as it sounds like it is, please open an issue (use category=deployment because that's where the generated app client JAR is created or category=standalone_client) so we can prioritize it and respond more formally.
>
>
Will do it - but I understand this is not a bug but a design issue, so I
don't see any short term fix for it.
> Sorry this is creating a problem for you.
>
>
Don't worry - no problems at the moment, but this will probably
> - Tim
> [Message sent by forum member 'tjquinn' (tjquinn)]
>
> http://forums.java.net/jive/thread.jspa?messageID=237184
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
> For additional commands, e-mail: users-help@glassfish.dev.java.net
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: Problem with WebStart
Posted:
Sep 26, 2007 3:34 PM
in response to: Piero Filippin
|
|
|
> > 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
|
|
|
|
|
|
|
|
|
RE: Problem with WebStart
Posted:
Sep 26, 2007 4:59 PM
in response to: Piero Filippin
|
|
|
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@javadesktop.org
Sent: 26 September 2007 23:34
To: users@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@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
RE: Problem with WebStart
Posted:
Sep 27, 2007 4:20 PM
in response to: Piero Filippin
|
|
|
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@yahoo.co.uk>
Sent: 27 September 2007 00:59
To: users@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@javadesktop.org
Sent: 26 September 2007 23:34
To: users@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
[The entire original message is not included]
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@glassfish.dev.java.net
For additional commands, e-mail: users-help@glassfish.dev.java.net
|
|
|
|
|
|
|
|
|
Re: RE: Problem with WebStart
Posted:
Sep 27, 2007 4:56 PM
in response to: Piero Filippin
|
|
|
Hi, Piero.
Thanks for writing down your thoughts on this.
Your suggestions are very much in line with some of what I have been planning for a long time to enhance the Java Web Start app client launching performance. In the original implementation for Java Web Start support we needed to impose as little additional logic as possible, compared to what the server was already doing for the appclient script case. That meant we needed to use the existing "fat" generated app client JAR, and there just has not been time or people to improve that during V2.
Looking ahead to GlassFish V3 there are quite a few possible improvements. You have mentioned some that we have had on the drawing board for some time. There are others that will take advantage of the modular approach we are planning for GlassFish itself in V3, server and client side, which should shrink the client-side footprint of the app client container quite a bit which should also improve the Java Web Start download and start-up performance.
In the V2 timeframe we can look at some smaller fixes - similar to the one I mentioned with Issue 3701 - but we might not have much of a chance to make radical improvements until V3. There are improvements in Java Web Start in Java SE 6 that take full advantage of indexed JAR files, which we could also consider using.
All along we need to keep in mind that GlassFish V2 (and perhaps V3) needs to work in Java SE 5 environments. We can try to take advantage of Java SE 6 features where we can, but not in a way that causes problems with the Java SE 5 runtime in place.
Anyway, I'm glad to hear that the possible workaround described in Issue 3701 would work for you. Stay tuned!
- Tim
|
|
|
|
|
java.net RSS
