Re: runtime vs builder, was: SpringApplicationImpl
OK - all understood - I will get back into the code today and tomorrow and try to sort this out. There may be a few more questions flying about later :-) Jules Jeremy Boynes wrote: Adding to what David said with some clarification of runtime vs. builder. The intention is that running systems contain only the stuff needed to actually run applications. They use a Geronimo kernel to load and manage Configurations, where each Configuration is a package of GBean instances and code (either directly or via repository dependencies). The GBeans are stored in a persisted offline form, currently by serializing their persistent attributes. The builders have the job of converting user-land artifacts such as J2EE modules (EARs, WARs, etc) or non-J2EE packagings (.SPR?) into Configurations that the runtime can use. A collection of builders bundled together forms a deployer. Deployers can run standalone - reading a module and spitting out a Configuration archive - or online (in-server) where they do the same thing but add the Configuration they built into the running system. The former mode is intended for production use where you would deploy once and then run the same Configuration in many places; the online mode is intended for development use where you just want the thing running as quickly as possible. If you look at the J2EE stuff, we have, for example, both jetty and jetty-builder. jetty is the runtime system containing the stuff used to bridge between GBeans and jetty containers; jetty-builder is the builder stuff used to convert a WAR into jetty GBeans. There would be a similar relationship between spring the runtime which bridged the Geronimo kernel and the Spring framework core, and spring-builder the thing that converted a .SPR module into a Configuration. A general rule is to do as much configuration work as possible in the builder - it means there is less chance of things failing at runtime, it means the runtime code is cleaner, it means you can do computationally expensive analysis of the module without impacting a production system (e.g. figuring out a transaction or security domain, pre-compiling queries, parsing validating XML, building interceptor stacks ...) Finally, it would be good if you can separate the Spring configuration from the J2EE one completely - it would then be possible to have a server that dealt with Spring applications natively without needing all that elephantine J2EE baggage :-) -- Jeremy David Jencks wrote: On Jan 28, 2005, at 3:39 PM, Jules Gosnell wrote: Jeremy Boynes wrote: From the source: // I know that this should not be here (in the j2ee package) but, // until someone who knows what they are doing has time to have a look // at it, this seems the path of least resistance... Move to the spring module? -- Jeremy spring - or spring-builder ? Definitely spring. spring-builder generally won't be available in running systems, only in ones that happen to have online deployment configured. I tried it in the spring-builder jar (I'm not using the spring module), but, in org.apache.geronimo.gbean.runtime.GBeanInstance one of the ctors does this : type = classLoader.loadClass(gbeanInfo.getClassName()); org.apache.geronimo.j2ee.management.impl.* must be in a classloader that is accessible to this code, whereas org.apache.geronimo.spring.deployment.* did not seem to be - it could never find the class. I just wanted the thing working quickly, so I chose the path of least resistance. I will revisit this soon. You don't want the builders in any classpath that is needed only by the running system. So, if you include via dependency the spring builder in j2ee-deployer-plan and runtime-deployer-plan, don't include it anywhere else. Assuming you come up with stuff in the spring module, that would presumably be included as a dependency in the j2ee-server-plan which should make it available to the code above. (actually just making sure the parentId chain of the module you are deploying includes the spring module should work) Deployment types seem to be a closed set that have to be known to Geronimo at build time (see org.apache.geronimo.kernel.config.ConfigurationModuleType). So I decided that since the system was already so tightly coupled another temporary coupling would not be so harmful ;-) - I thought about not putting it in the j2ee package and creating another one, but decided that that would just create more mess. I shall just have to try a few alternatives and give you guys a shortlist of solutions so that you can pick one... BTW - I also had to hack the SPRDeployer config into the j2ee-runtime-deployer-plan.xml - sorry. Deployers seem to be collected up using a wildcarded ObjectName and if yours is not around at the time, you miss the bus... - perhaps I could move it back into the spring-deployer-plan.xml and force its loading before this happens - it was late when I checked all this in This should
Re: SpringApplicationImpl
On Jan 28, 2005, at 3:39 PM, Jules Gosnell wrote: Jeremy Boynes wrote: From the source: // I know that this should not be here (in the j2ee package) but, // until someone who knows what they are doing has time to have a look // at it, this seems the path of least resistance... Move to the spring module? -- Jeremy spring - or spring-builder ? Definitely spring. spring-builder generally won't be available in running systems, only in ones that happen to have online deployment configured. I tried it in the spring-builder jar (I'm not using the spring module), but, in org.apache.geronimo.gbean.runtime.GBeanInstance one of the ctors does this : type = classLoader.loadClass(gbeanInfo.getClassName()); org.apache.geronimo.j2ee.management.impl.* must be in a classloader that is accessible to this code, whereas org.apache.geronimo.spring.deployment.* did not seem to be - it could never find the class. I just wanted the thing working quickly, so I chose the path of least resistance. I will revisit this soon. You don't want the builders in any classpath that is needed only by the running system. So, if you include via dependency the spring builder in j2ee-deployer-plan and runtime-deployer-plan, don't include it anywhere else. Assuming you come up with stuff in the spring module, that would presumably be included as a dependency in the j2ee-server-plan which should make it available to the code above. (actually just making sure the parentId chain of the module you are deploying includes the spring module should work) Deployment types seem to be a closed set that have to be known to Geronimo at build time (see org.apache.geronimo.kernel.config.ConfigurationModuleType). So I decided that since the system was already so tightly coupled another temporary coupling would not be so harmful ;-) - I thought about not putting it in the j2ee package and creating another one, but decided that that would just create more mess. I shall just have to try a few alternatives and give you guys a shortlist of solutions so that you can pick one... BTW - I also had to hack the SPRDeployer config into the j2ee-runtime-deployer-plan.xml - sorry. Deployers seem to be collected up using a wildcarded ObjectName and if yours is not around at the time, you miss the bus... - perhaps I could move it back into the spring-deployer-plan.xml and force its loading before this happens - it was late when I checked all this in This should not be the case -- you should be able to add more configbuilders at any time and they should be picked up by the Deployer gbean reference. Are you sure you had the j2eeType set correctly in the builder's gbean info? If this is really not working please complain loudly. my apologies, I will sort it out over the next few days - at least Rob can get on with his stuff in the meantime ... np, very glad to see progress on this! thanks david jencks Jules -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training Support. **/
runtime vs builder, was: SpringApplicationImpl
Adding to what David said with some clarification of runtime vs. builder. The intention is that running systems contain only the stuff needed to actually run applications. They use a Geronimo kernel to load and manage Configurations, where each Configuration is a package of GBean instances and code (either directly or via repository dependencies). The GBeans are stored in a persisted offline form, currently by serializing their persistent attributes. The builders have the job of converting user-land artifacts such as J2EE modules (EARs, WARs, etc) or non-J2EE packagings (.SPR?) into Configurations that the runtime can use. A collection of builders bundled together forms a deployer. Deployers can run standalone - reading a module and spitting out a Configuration archive - or online (in-server) where they do the same thing but add the Configuration they built into the running system. The former mode is intended for production use where you would deploy once and then run the same Configuration in many places; the online mode is intended for development use where you just want the thing running as quickly as possible. If you look at the J2EE stuff, we have, for example, both jetty and jetty-builder. jetty is the runtime system containing the stuff used to bridge between GBeans and jetty containers; jetty-builder is the builder stuff used to convert a WAR into jetty GBeans. There would be a similar relationship between spring the runtime which bridged the Geronimo kernel and the Spring framework core, and spring-builder the thing that converted a .SPR module into a Configuration. A general rule is to do as much configuration work as possible in the builder - it means there is less chance of things failing at runtime, it means the runtime code is cleaner, it means you can do computationally expensive analysis of the module without impacting a production system (e.g. figuring out a transaction or security domain, pre-compiling queries, parsing validating XML, building interceptor stacks ...) Finally, it would be good if you can separate the Spring configuration from the J2EE one completely - it would then be possible to have a server that dealt with Spring applications natively without needing all that elephantine J2EE baggage :-) -- Jeremy David Jencks wrote: On Jan 28, 2005, at 3:39 PM, Jules Gosnell wrote: Jeremy Boynes wrote: From the source: // I know that this should not be here (in the j2ee package) but, // until someone who knows what they are doing has time to have a look // at it, this seems the path of least resistance... Move to the spring module? -- Jeremy spring - or spring-builder ? Definitely spring. spring-builder generally won't be available in running systems, only in ones that happen to have online deployment configured. I tried it in the spring-builder jar (I'm not using the spring module), but, in org.apache.geronimo.gbean.runtime.GBeanInstance one of the ctors does this : type = classLoader.loadClass(gbeanInfo.getClassName()); org.apache.geronimo.j2ee.management.impl.* must be in a classloader that is accessible to this code, whereas org.apache.geronimo.spring.deployment.* did not seem to be - it could never find the class. I just wanted the thing working quickly, so I chose the path of least resistance. I will revisit this soon. You don't want the builders in any classpath that is needed only by the running system. So, if you include via dependency the spring builder in j2ee-deployer-plan and runtime-deployer-plan, don't include it anywhere else. Assuming you come up with stuff in the spring module, that would presumably be included as a dependency in the j2ee-server-plan which should make it available to the code above. (actually just making sure the parentId chain of the module you are deploying includes the spring module should work) Deployment types seem to be a closed set that have to be known to Geronimo at build time (see org.apache.geronimo.kernel.config.ConfigurationModuleType). So I decided that since the system was already so tightly coupled another temporary coupling would not be so harmful ;-) - I thought about not putting it in the j2ee package and creating another one, but decided that that would just create more mess. I shall just have to try a few alternatives and give you guys a shortlist of solutions so that you can pick one... BTW - I also had to hack the SPRDeployer config into the j2ee-runtime-deployer-plan.xml - sorry. Deployers seem to be collected up using a wildcarded ObjectName and if yours is not around at the time, you miss the bus... - perhaps I could move it back into the spring-deployer-plan.xml and force its loading before this happens - it was late when I checked all this in This should not be the case -- you should be able to add more configbuilders at any time and they should be picked up by the Deployer gbean reference. Are you sure you had the j2eeType set
SpringApplicationImpl
From the source: // I know that this should not be here (in the j2ee package) but, // until someone who knows what they are doing has time to have a look // at it, this seems the path of least resistance... Move to the spring module? -- Jeremy
Re: SpringApplicationImpl
Jeremy Boynes wrote: From the source: // I know that this should not be here (in the j2ee package) but, // until someone who knows what they are doing has time to have a look // at it, this seems the path of least resistance... Move to the spring module? -- Jeremy spring - or spring-builder ? I tried it in the spring-builder jar (I'm not using the spring module), but, in org.apache.geronimo.gbean.runtime.GBeanInstance one of the ctors does this : type = classLoader.loadClass(gbeanInfo.getClassName()); org.apache.geronimo.j2ee.management.impl.* must be in a classloader that is accessible to this code, whereas org.apache.geronimo.spring.deployment.* did not seem to be - it could never find the class. I just wanted the thing working quickly, so I chose the path of least resistance. I will revisit this soon. Deployment types seem to be a closed set that have to be known to Geronimo at build time (see org.apache.geronimo.kernel.config.ConfigurationModuleType). So I decided that since the system was already so tightly coupled another temporary coupling would not be so harmful ;-) - I thought about not putting it in the j2ee package and creating another one, but decided that that would just create more mess. I shall just have to try a few alternatives and give you guys a shortlist of solutions so that you can pick one... BTW - I also had to hack the SPRDeployer config into the j2ee-runtime-deployer-plan.xml - sorry. Deployers seem to be collected up using a wildcarded ObjectName and if yours is not around at the time, you miss the bus... - perhaps I could move it back into the spring-deployer-plan.xml and force its loading before this happens - it was late when I checked all this in my apologies, I will sort it out over the next few days - at least Rob can get on with his stuff in the meantime ... Jules -- Open Source is a self-assembling organism. You dangle a piece of string into a super-saturated solution and a whole operating-system crystallises out around it. /** * Jules Gosnell * Partner * Core Developers Network (Europe) * *www.coredevelopers.net * * Open Source Training Support. **/
