geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jules Gosnell <>
Subject Re: runtime vs builder, was: SpringApplicationImpl
Date Mon, 31 Jan 2005 11:58:36 GMT
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 :-)


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());
>>>* 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)
>>> *
>>> *
>>> *
>>> * 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)
 * Open Source Training & Support.

View raw message