Re: Remove server-environment from app client
On Aug 6, 2006, at 12:13 PM, Aaron Mulder wrote: On 8/6/06, David Jencks [EMAIL PROTECTED] wrote: How do we install the required yet idiotic jsr-77 gbean that represents the app client without a module to put it in? So as far as I can tell, it doesn't matter at runtime if the JSR-77 GBean module and the app client module had the same module ID, since they'll always run in different VMs. However, it is an issue in practice because we can't put the config.ser in the same place for both, and we need one config.ser containing all the client stuff and a different config.ser containing the JSR-77 GBean. I'd suggest in the EAR-with-app-client case, we put the app client JSR-77 GBean in the EAR configuration, just to indicate that the EAR contains an app client with such-and-such a name. (You still can't use it via JMX to start the client in the server VM.) I'd suggest in the standalone-app-client case, we skip the JSR-77 app client GBean, since the app client may not be present at all in the server installation of Geronimo (again, it may be installed only in a client distribution of Geronimo). I don't think there's any requirement that the application client container supports a JSR-77 interface. correct, but I'm pretty sure we still need the server side jsr-77 gbean for the app client even for standalone app clients where as you point out it makes particularly little sense. Please check the spec before you get too much farther. thanks david jencks Thanks, Aaron
Re: Remove server-environment from app client
On Aug 6, 2006, at 4:40 PM, Dain Sundstrom wrote: On Aug 6, 2006, at 12:04 PM, David Jencks wrote: How do we install the required yet idiotic jsr-77 gbean that represents the app client without a module to put it in? Easy, just toss it into the parent ear configuration. ok, but that won't work for a standalone app client. For consistency I think we should generate a server side moduleId from the supplied client side moduleId e.g. by appending _server to the artifactId. thanks david jencks -dain
Re: Remove server-environment from app client
On Aug 6, 2006, at 11:31 PM, David Jencks wrote: On Aug 6, 2006, at 4:40 PM, Dain Sundstrom wrote: On Aug 6, 2006, at 12:04 PM, David Jencks wrote: How do we install the required yet idiotic jsr-77 gbean that represents the app client without a module to put it in? Easy, just toss it into the parent ear configuration. ok, but that won't work for a standalone app client. For consistency I think we should generate a server side moduleId from the supplied client side moduleId e.g. by appending _server to the artifactId. To start with, I am totally cool with the solution above, but I would like to point out this is exactly what we do for ejb and rar modules. In those cases, we don't generate a module for the beans and just put the 77 services into the ear module. When they are standalone we generate a standalone module. Aaron pointed out the inconstancy between the handling of web and ejb modules when we were finishing the 1.1 work. I still think it would be best to generate a module for each nested deployment, but I think it would be a lot of work. Before we do this I think we need to introduce the concept of shared and private child modules. Shared child modules would add their class path entries to the shared (e.g., ear) class loader, and their services would become part of the shared (e.g., ear) service registry. Private modules would operate like web modules do today meaning they have a private class loader and private service registry. Anyway, it would be a lot of work, and I'm not planning on doing it :) -dain
Re: Remove server-environment from app client
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.
Re: Remove server-environment from app client
On Aug 6, 2006, at 12:15 AM, David Jencks wrote: 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. Thinking back, we introduced the server side app client module because we were planning on allowing server side resources to be allocated for an app client program. At first this was just a server side JNDI, but later we removed this due to it's complexity, and now I don't think anything uses the server side module. So, if someone wanted to do the work, we should be able to remove it completely, and avoid the conflict entirely. -dain
Re: Remove server-environment from app client
On Aug 6, 2006, at 9:59 AM, Dain Sundstrom wrote: On Aug 6, 2006, at 12:15 AM, David Jencks wrote: 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. Thinking back, we introduced the server side app client module because we were planning on allowing server side resources to be allocated for an app client program. At first this was just a server side JNDI, but later we removed this due to it's complexity, and now I don't think anything uses the server side module. So, if someone wanted to do the work, we should be able to remove it completely, and avoid the conflict entirely. How do we install the required yet idiotic jsr-77 gbean that represents the app client without a module to put it in? thanks david jencks -dain
Re: Remove server-environment from app client
On 8/6/06, David Jencks [EMAIL PROTECTED] wrote: How do we install the required yet idiotic jsr-77 gbean that represents the app client without a module to put it in? So as far as I can tell, it doesn't matter at runtime if the JSR-77 GBean module and the app client module had the same module ID, since they'll always run in different VMs. However, it is an issue in practice because we can't put the config.ser in the same place for both, and we need one config.ser containing all the client stuff and a different config.ser containing the JSR-77 GBean. I'd suggest in the EAR-with-app-client case, we put the app client JSR-77 GBean in the EAR configuration, just to indicate that the EAR contains an app client with such-and-such a name. (You still can't use it via JMX to start the client in the server VM.) I'd suggest in the standalone-app-client case, we skip the JSR-77 app client GBean, since the app client may not be present at all in the server installation of Geronimo (again, it may be installed only in a client distribution of Geronimo). I don't think there's any requirement that the application client container supports a JSR-77 interface. Thanks, Aaron
Re: Remove server-environment from app client
On Aug 6, 2006, at 12:04 PM, David Jencks wrote: How do we install the required yet idiotic jsr-77 gbean that represents the app client without a module to put it in? Easy, just toss it into the parent ear configuration. -dain
Remove server-environment from app client
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.
