runtime vs builder, was: SpringApplicationImpl

[Jeremy Boynes <jb...@apache.org>]

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

Re: runtime vs builder, was: SpringApplicationImpl

[Jules Gosnell <ju...@coredevelopers.net>]

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


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