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