geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: Remove server-environment from app client
Date Sun, 06 Aug 2006 07:15:00 GMT

On Aug 5, 2006, at 5:49 PM, Aaron Mulder wrote:

> 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
> client.

Thinking about it some more I think the problem is that for a  
standalone app client, you would get two modules with the same module  
id: one is the server jsr-77 gbean and the other is the actual app  
client module.  I think we ran into this problem and that is one  
reason there is the server-environment.  There's some logic to  
generate a module id if no plan is supplied, perhaps we could reverse  
or modify that to generate distinct but related module ids for the  
client and server bits.  However it's not quite as simple as I  
originally hoped :-(

david jencks

> * 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.
> Thanks,
>    Aaron
> 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