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