geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aaron Mulder" <>
Subject Remove server-environment from app client
Date Sun, 06 Aug 2006 00:49:57 GMT
Currently, the application client plan has both a client-environment
and a server-environment.  These can have separate module IDs and
separate classpath modifiers.

The client-environment is used for when you run the application client
in the application client container (which is essentially a
stripped-down Geronimo runtime).

The server-environment is used to create a JSR-77 GBean representing
the application client, on the server side.  That is, the module ID is
used as part of the GBean name for the JSR-77 GBean, and the class
path is used to run the JSR-77 GBean.  There was apparently some
thought that the client might be able to list GBeans that should run
on the server side using that class path and module ID as well, but
that was never implemented.

So here are my claims:
 * There's no need to have different module IDs on the client side and
server side.  The JSR-77 GBean and app client container GBeans could
all use the same module ID for GBeans associated with the same app
 * If an application client wants code to run on the server side, it
should be packaged in an EAR, and the EAR's environment, classpath,
and GBeans would be used on the server side.
 * It's not workable for a standalone (non-EAR) app client to include
server-side code.  What happens, for example, if you have different
Geronimo installations for the client and server, and only deploy the
app client in your "client" Geronimo installation?  It can talk to
code (e.g. remote EJBs) running in the server, but how can it possibly
cause GBeans or other code to be run on the server which are defined
and available only in the client's Geronimo installation?

That being the case, I'd like to remove the server-environment.  The
impact here is that the client container GBeans and JSR-77 GBean for
the app client would all use the same Module ID for the app client in
question, and we'd always use a fixed classpath for the JSR-77 GBean
representing the app client.  We'd keep the client-environment (as is,
or renamed to just "environment" like in all the other plans) to hold
that module ID and to customize the client-side class path.

Any objections?  I would consider this for the 1.2-or-later timeframe
since it involves plan format changes and there's no pressing need to
undertake this in 1.1.x.


P.S. My first claim is unproven -- there may actually currently be a
problem if the JSR-77 GBean and app client container GBeans use the
same module ID.  If we agree to the change in principle, we can
investigate and if necessary fix any conflicts, to avoid needing two
different module IDs to refer to the same app client.

View raw message