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 :-(
thanks 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.
