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_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>