You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by Jules Gosnell <ju...@coredevelopers.net> on 2005/01/28 01:22:20 UTC
Geronimo/Spring integration - Deployer checked in...
I have just checked in the beginnings of a SpringDeployer (revision 128446).
This requires an updated version of Spring (1.1.3). So, if you tend to
run your builds offline, you will need to hook up and let maven sort
it all out.
A Spring deployable currently looks like this - e.g. :
foo.spr/
META-INF/spring.xml
Foo.class
Bar.class
...
Classes should be deployed unpacked at the top level of the jar :
You should run the org/apache/geronimo/SpringDeployer configuration in
your server to use this functionality.
The org/apache/geronimo/DebugConsole will be useful to look at GBeans
that represent your Spring apps.
e.g.
[jules@smilodon cvs]$ java -jar
geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/deployer.jar
--user system --password manager deploy foo.spr
Deployed
[jules@smilodon cvs]$ java -jar
geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/deployer.jar
--user system --password manager undeploy /tmp/deployer34206.tmpdir/foo.spr
Undeployed /tmp/deployer34206.tmpdir/foo.spr
[jules@smilodon cvs]$
output from server :
23:39:45,704 INFO [Daemon] Server startup completed
PLANNING: /tmp/deployer34206.tmpdir/foo.spr
BUILDING: /tmp/deployer34206.tmpdir/foo.spr
23:40:23,556 INFO [XmlBeanDefinitionReader] Loading XML bean
definitions from class path resource [META-INF/spring.xml]
23:40:23,679 INFO [LocalConfigStore:config-store] Installed
configuration /tmp/deployer34206.tmpdir/foo.spr in location 16
23:40:23,730 INFO [ConfigurationManagerImpl] Loaded Configuration
geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
23:40:23,733 INFO [Configuration] Started configuration
/tmp/deployer34206.tmpdir/foo.spr
23:40:38,787 INFO [Container] Started HttpContext[/,/]
23:41:36,069 INFO [Configuration] Stopping configuration
/tmp/deployer34206.tmpdir/foo.spr
23:41:36,078 INFO [ConfigurationManagerImpl] Unloaded Configuration
geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
23:41:36,083 INFO [LocalConfigStore:config-store] Uninstalled
configuration /tmp/deployer34206.tmpdir/foo.spr
Functionality is rudimentary at the moment.
Only one GBean is created per Spring app.
We hope to add the following functionality soon :
1. Support for a META-INF/geronimo-spring.xml (internally or
externally) - this will be used to provide platform specific deploy
time metadata.
2. The possibility of exposing individual Spring generated beans as
GBeans in the Geronimo kernel with all attendant benefits -
management, monitoring and persistent configuration.
3. Transparent injection of platform hosted resources into Spring apps
- allowing seemless hookup between Spring composed apps running in
different containers within Geronimo.
4. Support for nested jars within the .spr.
5. Anything else that looks useful - please join this thread with your
ideas.
The code is in modules/spring-builder if you want to take a look.
If anyone can figure out how to move the Spring-related stuff out of
the j2ee-runtime-deployer-plan.xml and back into the
spring-deployer-plan.xml without losing the deployer they will have my
undying gratitude - I ran out of steam - maybe tomorrow :-)
We will be working closely with the Spring team on this integration. We
hope that both Geronimo and Spring will benefit substantially from
this.
Enjoy,
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: Geronimo/Spring integration - Deployer checked in...
Posted by Jeremy Boynes <jb...@apache.org>.
Jules Gosnell wrote:
> Rob,
>
> You'll need to refresh your view - I have made a few changes, including
> quickly hacked up support for one-level of nested packed jars:
>
> foo.spr/
> META-INF/spring.xml
> foo/Foo.class
> bar.jar
> bar/Bar.class
> ...
>
> This is useful as you can just throw any jars that your Spring app uses
> into the spr, jar it all up and drop it into Geronimo :-)
>
You should also look at the <dependency> mechanism in the Configuration
system that allows modules to load jars from a common Repository - that
way you don't need to include them in your application but can just
reference them and leave it to the Repository subsystem to figure out
where to load them from.
--
Jeremy
Re: Geronimo/Spring integration - Deployer checked in...
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Rob Harrop wrote:
> Is there a test :)?
errr... ehemmm...
I'll send you a really simple .spr that I have cobbled up, but as yet
there is no testsuite - I couldn't face digressing from getting a
working deployer long enough to grok how to set up and check in a test -
It is on my list.
smacked wrist ? :-)
Jules
>
> Jules Gosnell wrote:
>
>> Rob,
>>
>> You'll need to refresh your view - I have made a few changes,
>> including quickly hacked up support for one-level of nested packed jars:
>>
>> foo.spr/
>> META-INF/spring.xml
>> foo/Foo.class
>> bar.jar
>> bar/Bar.class
>> ...
>>
>> This is useful as you can just throw any jars that your Spring app
>> uses into the spr, jar it all up and drop it into Geronimo :-)
>>
>> Re patching, there is an svn diff (I think), for the moment, just
>> send me patches and I'll commit them. If things go well and you need
>> further access we can work on persuading the powers that be to let
>> you in...
>>
>> Jules
>>
>> Rob Harrop wrote:
>>
>>> What is the preferred mechanism for contributing this code? Should
>>> Jules check it all in. I'm not that familiar with SVN - can I create
>>> a patch like with CVS?
>>>
>>> Rob
>>>
>>> Rob Harrop wrote:
>>>
>>>> Jules,
>>>>
>>>> This is great stuff - I'm just downloading everything here at work
>>>> and I will start to look at the Spring side of things -
>>>> specifically satisfying dependencies using the beans that are
>>>> deployed in Geronimo.
>>>>
>>>> Regards,
>>>>
>>>> Rob
>>>>
>>>> Jules Gosnell wrote:
>>>>
>>>>>
>>>>> I have just checked in the beginnings of a SpringDeployer
>>>>> (revision 128446).
>>>>>
>>>>> This requires an updated version of Spring (1.1.3). So, if you
>>>>> tend to
>>>>> run your builds offline, you will need to hook up and let maven sort
>>>>> it all out.
>>>>>
>>>>> A Spring deployable currently looks like this - e.g. :
>>>>>
>>>>> foo.spr/
>>>>> META-INF/spring.xml
>>>>> Foo.class
>>>>> Bar.class
>>>>> ...
>>>>>
>>>>> Classes should be deployed unpacked at the top level of the jar :
>>>>>
>>>>> You should run the org/apache/geronimo/SpringDeployer
>>>>> configuration in
>>>>> your server to use this functionality.
>>>>>
>>>>> The org/apache/geronimo/DebugConsole will be useful to look at GBeans
>>>>> that represent your Spring apps.
>>>>>
>>>>> e.g.
>>>>>
>>>>> [jules@smilodon cvs]$ java -jar
>>>>> geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/deployer.jar
>>>>> --user system --password manager deploy foo.spr
>>>>> Deployed
>>>>> [jules@smilodon cvs]$ java -jar
>>>>> geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/deployer.jar
>>>>> --user system --password manager undeploy
>>>>> /tmp/deployer34206.tmpdir/foo.spr
>>>>> Undeployed /tmp/deployer34206.tmpdir/foo.spr
>>>>> [jules@smilodon cvs]$
>>>>>
>>>>> output from server :
>>>>>
>>>>> 23:39:45,704 INFO [Daemon] Server startup completed
>>>>> PLANNING: /tmp/deployer34206.tmpdir/foo.spr
>>>>> BUILDING: /tmp/deployer34206.tmpdir/foo.spr
>>>>> 23:40:23,556 INFO [XmlBeanDefinitionReader] Loading XML bean
>>>>> definitions from class path resource [META-INF/spring.xml]
>>>>> 23:40:23,679 INFO [LocalConfigStore:config-store] Installed
>>>>> configuration /tmp/deployer34206.tmpdir/foo.spr in location 16
>>>>> 23:40:23,730 INFO [ConfigurationManagerImpl] Loaded Configuration
>>>>> geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
>>>>> 23:40:23,733 INFO [Configuration] Started configuration
>>>>> /tmp/deployer34206.tmpdir/foo.spr
>>>>> 23:40:38,787 INFO [Container] Started HttpContext[/,/]
>>>>> 23:41:36,069 INFO [Configuration] Stopping configuration
>>>>> /tmp/deployer34206.tmpdir/foo.spr
>>>>> 23:41:36,078 INFO [ConfigurationManagerImpl] Unloaded
>>>>> Configuration
>>>>> geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
>>>>> 23:41:36,083 INFO [LocalConfigStore:config-store] Uninstalled
>>>>> configuration /tmp/deployer34206.tmpdir/foo.spr
>>>>>
>>>>>
>>>>> Functionality is rudimentary at the moment.
>>>>>
>>>>> Only one GBean is created per Spring app.
>>>>>
>>>>> We hope to add the following functionality soon :
>>>>>
>>>>> 1. Support for a META-INF/geronimo-spring.xml (internally or
>>>>> externally) - this will be used to provide platform specific deploy
>>>>> time metadata.
>>>>>
>>>>> 2. The possibility of exposing individual Spring generated beans as
>>>>> GBeans in the Geronimo kernel with all attendant benefits -
>>>>> management, monitoring and persistent configuration.
>>>>>
>>>>> 3. Transparent injection of platform hosted resources into Spring
>>>>> apps
>>>>> - allowing seemless hookup between Spring composed apps running in
>>>>> different containers within Geronimo.
>>>>>
>>>>> 4. Support for nested jars within the .spr.
>>>>>
>>>>> 5. Anything else that looks useful - please join this thread with
>>>>> your
>>>>> ideas.
>>>>>
>>>>>
>>>>> The code is in modules/spring-builder if you want to take a look.
>>>>>
>>>>> If anyone can figure out how to move the Spring-related stuff out of
>>>>> the j2ee-runtime-deployer-plan.xml and back into the
>>>>> spring-deployer-plan.xml without losing the deployer they will
>>>>> have my
>>>>> undying gratitude - I ran out of steam - maybe tomorrow :-)
>>>>>
>>>>> We will be working closely with the Spring team on this
>>>>> integration. We
>>>>> hope that both Geronimo and Spring will benefit substantially from
>>>>> this.
>>>>>
>>>>> Enjoy,
>>>>>
>>>>> 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: Geronimo/Spring integration - Deployer checked in...
Posted by Rob Harrop <ro...@cakesolutions.net>.
Is there a test :)?
Jules Gosnell wrote:
> Rob,
>
> You'll need to refresh your view - I have made a few changes,
> including quickly hacked up support for one-level of nested packed jars:
>
> foo.spr/
> META-INF/spring.xml
> foo/Foo.class
> bar.jar
> bar/Bar.class
> ...
>
> This is useful as you can just throw any jars that your Spring app
> uses into the spr, jar it all up and drop it into Geronimo :-)
>
> Re patching, there is an svn diff (I think), for the moment, just send
> me patches and I'll commit them. If things go well and you need
> further access we can work on persuading the powers that be to let you
> in...
>
> Jules
>
> Rob Harrop wrote:
>
>> What is the preferred mechanism for contributing this code? Should
>> Jules check it all in. I'm not that familiar with SVN - can I create
>> a patch like with CVS?
>>
>> Rob
>>
>> Rob Harrop wrote:
>>
>>> Jules,
>>>
>>> This is great stuff - I'm just downloading everything here at work
>>> and I will start to look at the Spring side of things - specifically
>>> satisfying dependencies using the beans that are deployed in Geronimo.
>>>
>>> Regards,
>>>
>>> Rob
>>>
>>> Jules Gosnell wrote:
>>>
>>>>
>>>> I have just checked in the beginnings of a SpringDeployer (revision
>>>> 128446).
>>>>
>>>> This requires an updated version of Spring (1.1.3). So, if you tend to
>>>> run your builds offline, you will need to hook up and let maven sort
>>>> it all out.
>>>>
>>>> A Spring deployable currently looks like this - e.g. :
>>>>
>>>> foo.spr/
>>>> META-INF/spring.xml
>>>> Foo.class
>>>> Bar.class
>>>> ...
>>>>
>>>> Classes should be deployed unpacked at the top level of the jar :
>>>>
>>>> You should run the org/apache/geronimo/SpringDeployer configuration in
>>>> your server to use this functionality.
>>>>
>>>> The org/apache/geronimo/DebugConsole will be useful to look at GBeans
>>>> that represent your Spring apps.
>>>>
>>>> e.g.
>>>>
>>>> [jules@smilodon cvs]$ java -jar
>>>> geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/deployer.jar
>>>> --user system --password manager deploy foo.spr
>>>> Deployed
>>>> [jules@smilodon cvs]$ java -jar
>>>> geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/deployer.jar
>>>> --user system --password manager undeploy
>>>> /tmp/deployer34206.tmpdir/foo.spr
>>>> Undeployed /tmp/deployer34206.tmpdir/foo.spr
>>>> [jules@smilodon cvs]$
>>>>
>>>> output from server :
>>>>
>>>> 23:39:45,704 INFO [Daemon] Server startup completed
>>>> PLANNING: /tmp/deployer34206.tmpdir/foo.spr
>>>> BUILDING: /tmp/deployer34206.tmpdir/foo.spr
>>>> 23:40:23,556 INFO [XmlBeanDefinitionReader] Loading XML bean
>>>> definitions from class path resource [META-INF/spring.xml]
>>>> 23:40:23,679 INFO [LocalConfigStore:config-store] Installed
>>>> configuration /tmp/deployer34206.tmpdir/foo.spr in location 16
>>>> 23:40:23,730 INFO [ConfigurationManagerImpl] Loaded Configuration
>>>> geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
>>>> 23:40:23,733 INFO [Configuration] Started configuration
>>>> /tmp/deployer34206.tmpdir/foo.spr
>>>> 23:40:38,787 INFO [Container] Started HttpContext[/,/]
>>>> 23:41:36,069 INFO [Configuration] Stopping configuration
>>>> /tmp/deployer34206.tmpdir/foo.spr
>>>> 23:41:36,078 INFO [ConfigurationManagerImpl] Unloaded
>>>> Configuration geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
>>>> 23:41:36,083 INFO [LocalConfigStore:config-store] Uninstalled
>>>> configuration /tmp/deployer34206.tmpdir/foo.spr
>>>>
>>>>
>>>> Functionality is rudimentary at the moment.
>>>>
>>>> Only one GBean is created per Spring app.
>>>>
>>>> We hope to add the following functionality soon :
>>>>
>>>> 1. Support for a META-INF/geronimo-spring.xml (internally or
>>>> externally) - this will be used to provide platform specific deploy
>>>> time metadata.
>>>>
>>>> 2. The possibility of exposing individual Spring generated beans as
>>>> GBeans in the Geronimo kernel with all attendant benefits -
>>>> management, monitoring and persistent configuration.
>>>>
>>>> 3. Transparent injection of platform hosted resources into Spring apps
>>>> - allowing seemless hookup between Spring composed apps running in
>>>> different containers within Geronimo.
>>>>
>>>> 4. Support for nested jars within the .spr.
>>>>
>>>> 5. Anything else that looks useful - please join this thread with your
>>>> ideas.
>>>>
>>>>
>>>> The code is in modules/spring-builder if you want to take a look.
>>>>
>>>> If anyone can figure out how to move the Spring-related stuff out of
>>>> the j2ee-runtime-deployer-plan.xml and back into the
>>>> spring-deployer-plan.xml without losing the deployer they will have my
>>>> undying gratitude - I ran out of steam - maybe tomorrow :-)
>>>>
>>>> We will be working closely with the Spring team on this
>>>> integration. We
>>>> hope that both Geronimo and Spring will benefit substantially from
>>>> this.
>>>>
>>>> Enjoy,
>>>>
>>>> Jules
>>>>
>>>
>>>
>
>
Re: Geronimo/Spring integration - Moving forward...
Posted by Rob Harrop <ro...@cakesolutions.net>.
As of version 1.2, Spring will support the export of POJOs to JMX using
ModelMBeans as a level of indirection. Plus there will be support for
proxying a JMX resource in Spring. Most of the JMX code is already
written and you can check it out from CVS. We have Dependency Injection
support for JNDI resources already - all we need is some mechanism for
export POJOs to JNDI.
On the Geronimo side, Spring should be able to access the
ApplicationContext for any deployed .spr files and then merge this into
deployed web applications using a ContextLoader (Spring thing). This
will allow for service sharing in a Spring-style manner without the
overhead of proxies. We could add proxies as a mechanism for surviving
service reboot as well, but the option to go without proxies might be
wise. The main barrier here is the whole classloading murk, but it
should be that much of an issue.
Rob
Jules Gosnell wrote:
>
> So, Rob and I have been talking about exactly what we want out of the
> Spring integration...
>
> I've thought a little and decided to share it with the whole list as
> well as Rob, so that anyone else with an interest can join in...
>
> I think that the integration is really one of contained components,
> not the containers themselves. This means that things in the Spring
> world need to see things in the J2EE world in Spring terms and vice
> versa....
>
> Lookup in the J2EE world, depending on granularity and indirection is
> done via JNDI or JMX, lookup is avoided in the Spring world and
> replaced with injection of POJOs into other POJOs.
>
> This seems to be leading us towards :
>
> - Spring must be able to resolve JNDI refs and inject the resulting
> POJO into Spring apps.
> - Spring must be able to resolve JMX ObjectNames and inject a
> corresponding POJO (proxy) into Spring apps.
> - Spring must export some/all managed POJOs into a JNDI registry
> - Spring must register some/all managed POJOs as MBeans (via a proxy)
> with JMX Agent
>
> Since we are in the Geronimo world we might reasonably expect some/all
> of these MBeans to be GBeans.
>
> Geronimo supports inter-MBean dependendencies.
> Spring supports a POJO constuction-time dependency tree.
>
> It makes sense to integrate these as well.
>
> The results of this work should be transparent access to J2EE managed
> objects from Spring and vice versa. Spring components in one container
> could talk to those in another Spring container via a lookup through
> the J2EE layer, JNDI (if the relationship did not need to survive
> redeployment) or JMX (if it did), or could perhaps optimise this
> process by looking up each others BeanRegistries, which could be
> registered in JNDI/JMX anyway....
>
> etc...
>
> There are undoubtedly ClassLoading issues lurking here - more thought
> needed.
>
> One last thing that would be very useful would be to somehow intercept
> Spring-managed calls to POJO-setters, and pass them through the POJO's
> GBean proxy. This should allow successful recording of configuration
> deltas, so that Spring-managed POJOs may have their state persisted
> like other GBeans. Can anyone more famailiar with the Geronimo kernel
> comment on this.... ?
>
> How does that sound ?
>
>
> Jules
>
>
Re: Geronimo/Spring integration - Moving forward...
Posted by David Jencks <dj...@gluecode.com>.
This looks very good.
Most of this will happen more or less automatically if you deploy each
spring component as a gbean and give them jsr-77 like names.
We don't use mbeans any more.
We don't have a global jndi context: components' jndi component context
is resolved entirely based on gbean object names. By using jsr-77
naming conventions systematically we can resolve most references based
on only a small portion of the object name (the "name" key).
So, if you give the spring gbeans appropriate names they will be
findable by the existing name resolution process (although it might
need a little tweaking)
The object names in gbean references should give spring gbeans access
to all other components in geronimo, j2ee and non-j2ee alike. This
gives injection of components into other components. We generally
prefer constructor dependency injection but the gbean infrastructure
also supports setter injection.
What gets injected is a proxy giving geronimo some control over the
lifecycle of the components.
Hope this helps,
david jencks
On Jan 28, 2005, at 7:56 AM, Jules Gosnell wrote:
>
> So, Rob and I have been talking about exactly what we want out of the
> Spring integration...
>
> I've thought a little and decided to share it with the whole list as
> well as Rob, so that anyone else with an interest can join in...
>
> I think that the integration is really one of contained components,
> not the containers themselves. This means that things in the Spring
> world need to see things in the J2EE world in Spring terms and vice
> versa....
>
> Lookup in the J2EE world, depending on granularity and indirection is
> done via JNDI or JMX, lookup is avoided in the Spring world and
> replaced with injection of POJOs into other POJOs.
>
> This seems to be leading us towards :
>
> - Spring must be able to resolve JNDI refs and inject the resulting
> POJO into Spring apps.
> - Spring must be able to resolve JMX ObjectNames and inject a
> corresponding POJO (proxy) into Spring apps.
> - Spring must export some/all managed POJOs into a JNDI registry
> - Spring must register some/all managed POJOs as MBeans (via a proxy)
> with JMX Agent
>
> Since we are in the Geronimo world we might reasonably expect some/all
> of these MBeans to be GBeans.
>
> Geronimo supports inter-MBean dependendencies.
> Spring supports a POJO constuction-time dependency tree.
>
> It makes sense to integrate these as well.
>
> The results of this work should be transparent access to J2EE managed
> objects from Spring and vice versa. Spring components in one container
> could talk to those in another Spring container via a lookup through
> the J2EE layer, JNDI (if the relationship did not need to survive
> redeployment) or JMX (if it did), or could perhaps optimise this
> process by looking up each others BeanRegistries, which could be
> registered in JNDI/JMX anyway....
>
> etc...
>
> There are undoubtedly ClassLoading issues lurking here - more thought
> needed.
>
> One last thing that would be very useful would be to somehow intercept
> Spring-managed calls to POJO-setters, and pass them through the POJO's
> GBean proxy. This should allow successful recording of configuration
> deltas, so that Spring-managed POJOs may have their state persisted
> like other GBeans. Can anyone more famailiar with the Geronimo kernel
> comment on this.... ?
>
> How does that sound ?
>
>
> 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: Geronimo/Spring integration - Moving forward...
Posted by Jeff Genender <jg...@savoirtech.com>.
Jules,
You hit the nail on the head. At my current client, I just got done
implementing Spring ApplicationContext objects into JNDI that are
managed via JMX MBeans, so separate applications could share the POJOs
between themselves. This proved to be huge when we are getting Portlets
that need to leverage Spring based persistence layers between themselves.
One small hurdle to overcome is the ApplicationContext is not
serializable, so wrapping this with a Serializable Adapter is a must. A
pattern behind the scenes can make this seemless to the end
user/developer, so they only work with the ApplicationContext.
This is good stuff.
Jeff
Jules Gosnell wrote:
>
> So, Rob and I have been talking about exactly what we want out of the
> Spring integration...
>
> I've thought a little and decided to share it with the whole list as
> well as Rob, so that anyone else with an interest can join in...
>
> I think that the integration is really one of contained components, not
> the containers themselves. This means that things in the Spring world
> need to see things in the J2EE world in Spring terms and vice versa....
>
> Lookup in the J2EE world, depending on granularity and indirection is
> done via JNDI or JMX, lookup is avoided in the Spring world and replaced
> with injection of POJOs into other POJOs.
>
> This seems to be leading us towards :
>
> - Spring must be able to resolve JNDI refs and inject the resulting POJO
> into Spring apps.
> - Spring must be able to resolve JMX ObjectNames and inject a
> corresponding POJO (proxy) into Spring apps.
> - Spring must export some/all managed POJOs into a JNDI registry
> - Spring must register some/all managed POJOs as MBeans (via a proxy)
> with JMX Agent
>
> Since we are in the Geronimo world we might reasonably expect some/all
> of these MBeans to be GBeans.
>
> Geronimo supports inter-MBean dependendencies.
> Spring supports a POJO constuction-time dependency tree.
>
> It makes sense to integrate these as well.
>
> The results of this work should be transparent access to J2EE managed
> objects from Spring and vice versa. Spring components in one container
> could talk to those in another Spring container via a lookup through the
> J2EE layer, JNDI (if the relationship did not need to survive
> redeployment) or JMX (if it did), or could perhaps optimise this process
> by looking up each others BeanRegistries, which could be registered in
> JNDI/JMX anyway....
>
> etc...
>
> There are undoubtedly ClassLoading issues lurking here - more thought
> needed.
>
> One last thing that would be very useful would be to somehow intercept
> Spring-managed calls to POJO-setters, and pass them through the POJO's
> GBean proxy. This should allow successful recording of configuration
> deltas, so that Spring-managed POJOs may have their state persisted like
> other GBeans. Can anyone more famailiar with the Geronimo kernel comment
> on this.... ?
>
> How does that sound ?
>
>
> Jules
>
>
Re: Geronimo/Spring integration - Moving forward... (Dain, David,
Jeremy,... - Please read)
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Rob Harrop wrote:
> Jules,
>
> I've used CGLIB extensively in Spring - you could skip this completely
> and use Spring's AOP proxies with CGLIB underlying. This will sheild
> you from the complexity of CGLIB and you can think in terms of
> MethodInterceptors. If I had a choice between proxy frameworks I would
> use AspectWerkz Proxy although I have encountered some problems on Mac
> OS X. That said, CGLIB is perfectly fine, and the newer version (2.1)
> has some important bug fixes in it. If you need help building a proxy
> implementation using CGLIB drop me a line, but I think it would be
> easier to use Spring's AOP proxies.
>
> Rob
I've had a chat with Rob and it looks like any form of proxying that
uses subclassing is out, because Spring may return a cglib proxy with
final methods on it.
The best candidate at the moment seems to be
net.sf.cglib.proxy.InterfaceMaker - missed on my first sweep because the
doc at http://cglib.sourceforge.net/apidocs is out of date...
I'll hold off on messing around with this for a while...
Jules
>
> Jules Gosnell wrote:
>
>> <stuff deleted>
>>
>>>>
>>>> The plan for integrating component frameworks such as spring is to
>>>> write a GBean component that holds the spring object delegates
>>>> method calls to it. Yes this is another layer of indirection, but
>>>> it can be made very fast. This way, spring can handle construction
>>>> and your GBean component simply wraps it.
>>>>
>>> So, given that the Spring component might be any POJO, this GBean
>>> (except that it doesn't have to be a GBean , only implement
>>> GBeanLifecycle, and it doesn't even seem to have to do that, as the
>>> kernel uses an instanceof test before calling lifecycle methods -
>>> only at a swift glance) needs to be either the POJO itself, or some
>>> form of engineered proxy, since we cannot be sure that the POJO
>>> implements an interface that we can 1.3-proxy. Regardless of which,
>>> we still need a way to push this instance into the kernel so it can
>>> be given to the proxy...
>>>
>>> Is this how you would want to approach it ?
>>>
>> So, I thought I would revisit your suggestion whilst I await
>> judgement on the patch...
>>
>> The only way I can see this working, is for me to find some way of
>> dynamically generating a proxy class that duplicates all methods on
>> my POJO and delegates any call to them to the POJO. The POJO would
>> have to be injected at construction time, as the Proxy does not want
>> to start adding accessors (e.g. setPOJO()) in case they collide with
>> methods already present in the POJO.
>>
>> So, I need a ProxyClass that I can pass in to the kernel along with
>> the POJO and enough metadata that the kernel can understand how to
>> inject it into a fresh instance of the class. Then everything would
>> work as planned. Only I see no benefit in having a proxy here :-). I
>> am not intercepting anything - it is simply complex syntactic sugar
>> to avoid making a change to the kernel...
>>
>> I've had a look at cglib, in an effort to find a way of creating such
>> a proxy - there seem to be 3 promising avenues - Proxy (interfaces
>> only), Enhancer (no final methods) and Mixin, which I am trying to
>> grok at the moment...
>>
>> I could do with some guidance here. Have I correctly understood what
>> you are suggesting, or am I off on a time-wasting tangent ? If so,
>> what did you mean ? If not, do you think this is achievable with
>> proxying technology - which one ?
>>
>> Cheers,
>>
>> Jules
>>
>>
>>> Jules
>>>
>>>
>>>> -dain
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
--
"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: Geronimo/Spring integration - Moving forward... (Dain, David,
Jeremy,... - Please read)
Posted by Rob Harrop <ro...@cakesolutions.net>.
Jules,
I've used CGLIB extensively in Spring - you could skip this completely
and use Spring's AOP proxies with CGLIB underlying. This will sheild you
from the complexity of CGLIB and you can think in terms of
MethodInterceptors. If I had a choice between proxy frameworks I would
use AspectWerkz Proxy although I have encountered some problems on Mac
OS X. That said, CGLIB is perfectly fine, and the newer version (2.1)
has some important bug fixes in it. If you need help building a proxy
implementation using CGLIB drop me a line, but I think it would be
easier to use Spring's AOP proxies.
Rob
Jules Gosnell wrote:
> <stuff deleted>
>
>>>
>>> The plan for integrating component frameworks such as spring is to
>>> write a GBean component that holds the spring object delegates
>>> method calls to it. Yes this is another layer of indirection, but
>>> it can be made very fast. This way, spring can handle construction
>>> and your GBean component simply wraps it.
>>>
>> So, given that the Spring component might be any POJO, this GBean
>> (except that it doesn't have to be a GBean , only implement
>> GBeanLifecycle, and it doesn't even seem to have to do that, as the
>> kernel uses an instanceof test before calling lifecycle methods -
>> only at a swift glance) needs to be either the POJO itself, or some
>> form of engineered proxy, since we cannot be sure that the POJO
>> implements an interface that we can 1.3-proxy. Regardless of which,
>> we still need a way to push this instance into the kernel so it can
>> be given to the proxy...
>>
>> Is this how you would want to approach it ?
>>
> So, I thought I would revisit your suggestion whilst I await judgement
> on the patch...
>
> The only way I can see this working, is for me to find some way of
> dynamically generating a proxy class that duplicates all methods on my
> POJO and delegates any call to them to the POJO. The POJO would have
> to be injected at construction time, as the Proxy does not want to
> start adding accessors (e.g. setPOJO()) in case they collide with
> methods already present in the POJO.
>
> So, I need a ProxyClass that I can pass in to the kernel along with
> the POJO and enough metadata that the kernel can understand how to
> inject it into a fresh instance of the class. Then everything would
> work as planned. Only I see no benefit in having a proxy here :-). I
> am not intercepting anything - it is simply complex syntactic sugar to
> avoid making a change to the kernel...
>
> I've had a look at cglib, in an effort to find a way of creating such
> a proxy - there seem to be 3 promising avenues - Proxy (interfaces
> only), Enhancer (no final methods) and Mixin, which I am trying to
> grok at the moment...
>
> I could do with some guidance here. Have I correctly understood what
> you are suggesting, or am I off on a time-wasting tangent ? If so,
> what did you mean ? If not, do you think this is achievable with
> proxying technology - which one ?
>
> Cheers,
>
> Jules
>
>
>> Jules
>>
>>
>>> -dain
>>
>>
>>
>>
>>
>
>
Re: Geronimo/Spring integration - Moving forward... (Dain, David,
Jeremy,... - Please read)
Posted by Jules Gosnell <ju...@coredevelopers.net>.
<stuff deleted>
>>
>> The plan for integrating component frameworks such as spring is to
>> write a GBean component that holds the spring object delegates method
>> calls to it. Yes this is another layer of indirection, but it can be
>> made very fast. This way, spring can handle construction and your
>> GBean component simply wraps it.
>>
> So, given that the Spring component might be any POJO, this GBean
> (except that it doesn't have to be a GBean , only implement
> GBeanLifecycle, and it doesn't even seem to have to do that, as the
> kernel uses an instanceof test before calling lifecycle methods - only
> at a swift glance) needs to be either the POJO itself, or some form of
> engineered proxy, since we cannot be sure that the POJO implements an
> interface that we can 1.3-proxy. Regardless of which, we still need a
> way to push this instance into the kernel so it can be given to the
> proxy...
>
> Is this how you would want to approach it ?
>
So, I thought I would revisit your suggestion whilst I await judgement
on the patch...
The only way I can see this working, is for me to find some way of
dynamically generating a proxy class that duplicates all methods on my
POJO and delegates any call to them to the POJO. The POJO would have to
be injected at construction time, as the Proxy does not want to start
adding accessors (e.g. setPOJO()) in case they collide with methods
already present in the POJO.
So, I need a ProxyClass that I can pass in to the kernel along with the
POJO and enough metadata that the kernel can understand how to inject it
into a fresh instance of the class. Then everything would work as
planned. Only I see no benefit in having a proxy here :-). I am not
intercepting anything - it is simply complex syntactic sugar to avoid
making a change to the kernel...
I've had a look at cglib, in an effort to find a way of creating such a
proxy - there seem to be 3 promising avenues - Proxy (interfaces only),
Enhancer (no final methods) and Mixin, which I am trying to grok at the
moment...
I could do with some guidance here. Have I correctly understood what you
are suggesting, or am I off on a time-wasting tangent ? If so, what did
you mean ? If not, do you think this is achievable with proxying
technology - which one ?
Cheers,
Jules
> Jules
>
>
>> -dain
>
>
>
>
--
"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: Geronimo/Spring integration - Moving forward... (Dain, David,
Jeremy,... - Please read)
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Dain Sundstrom wrote:
> On Feb 2, 2005, at 7:54 AM, Jules Gosnell wrote:
>
>> Jules Gosnell wrote:
>>
>>> Rob Harrop wrote:
>>>
>>>> Jules,
>>>>
>>>> The Spring config file does not change when new modules are added,
>>>> it is generic enough to support most configuration options. For JMX
>>>> metadata we currently use interfaces or source level metadata
>>>> (Commons Attributes or Annotations). I am working on an XML-based
>>>> JMX descriptor, but this is separate from the core config file. You
>>>> can hook into the JMX registration process by implementing the
>>>> RegistrationStrategy interface and you can then transform the MBean
>>>> into a GBean. The MBeans we use are ModelMBeans so you can get all
>>>> the metadata from that.
>>>>
>>> Excellent :-)
>>>
>>> I am just putting in a placeholder POJOGBean that wraps each POJO,
>>> but the API is simply that of GBean (i.e. has one accessor
>>> getPeer()) at the moment - I have to look into how we can
>>> dynamically declare an interface's metadata to the kernel...
>>
>>
>>
>> I'm looking at how I can interface a POJO with the Geronimo kernel.
>>
>> GBeanInstance has a concept of 'target' (see getTarget()) which
>> GBeanAttributes and Operations seem to use to retrieve the object on
>> which to act. So, this is good - I just need to make GBeanInstance
>> wrap a ready made object (my POJO) instead of constructing another
>> one...
>
>
> Please do not use this method. It is simply there as a hack to allow
> the kernel to get access to the internal instance of one gbean it
> creates. The GBeanInstance object itself is an internal detail of the
> Kernel itself, and has been carefully written so user code should
> never be able to obtain a reference to the instance object. This
> allows me to have complete freedom over the gbean implementation
> behind the kernel interface.
>
>> However, the GBeanInstance ctor insists on creating a new object from
>> scratch - no good if I want to just proxy one already existing in
>> Spring.... (unless I add yet another layer of wrapping, which is not
>> ideal).
>>
>> So, I guess I am looking at altering or subclassing GBeanInstance to
>> allow the passing in of an object to be wrapped and extending the
>> Kernel with a method to loadGBean() around an already existing object.
>>
>> Are the people who know about how the kernel works happy with this
>> solution, or have I missed another way of achieving this ?
>>
>> Are you happy for me to put this in, or would you like to do this
>> yourselves ?
>
>
> The plan for integrating component frameworks such as spring is to
> write a GBean component that holds the spring object delegates method
> calls to it. Yes this is another layer of indirection, but it can be
> made very fast. This way, spring can handle construction and your
> GBean component simply wraps it.
>
So, given that the Spring component might be any POJO, this GBean
(except that it doesn't have to be a GBean , only implement
GBeanLifecycle, and it doesn't even seem to have to do that, as the
kernel uses an instanceof test before calling lifecycle methods - only
at a swift glance) needs to be either the POJO itself, or some form of
engineered proxy, since we cannot be sure that the POJO implements an
interface that we can 1.3-proxy. Regardless of which, we still need a
way to push this instance into the kernel so it can be given to the proxy...
Is this how you would want to approach it ?
Jules
> -dain
--
"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: Geronimo/Spring integration - Moving forward... (Dain, David, Jeremy,... - Please read)
Posted by Dain Sundstrom <ds...@gluecode.com>.
On Feb 2, 2005, at 7:54 AM, Jules Gosnell wrote:
> Jules Gosnell wrote:
>
>> Rob Harrop wrote:
>>
>>> Jules,
>>>
>>> The Spring config file does not change when new modules are added,
>>> it is generic enough to support most configuration options. For JMX
>>> metadata we currently use interfaces or source level metadata
>>> (Commons Attributes or Annotations). I am working on an XML-based
>>> JMX descriptor, but this is separate from the core config file. You
>>> can hook into the JMX registration process by implementing the
>>> RegistrationStrategy interface and you can then transform the MBean
>>> into a GBean. The MBeans we use are ModelMBeans so you can get all
>>> the metadata from that.
>>>
>> Excellent :-)
>>
>> I am just putting in a placeholder POJOGBean that wraps each POJO,
>> but the API is simply that of GBean (i.e. has one accessor getPeer())
>> at the moment - I have to look into how we can dynamically declare an
>> interface's metadata to the kernel...
>
>
> I'm looking at how I can interface a POJO with the Geronimo kernel.
>
> GBeanInstance has a concept of 'target' (see getTarget()) which
> GBeanAttributes and Operations seem to use to retrieve the object on
> which to act. So, this is good - I just need to make GBeanInstance
> wrap a ready made object (my POJO) instead of constructing another
> one...
Please do not use this method. It is simply there as a hack to allow
the kernel to get access to the internal instance of one gbean it
creates. The GBeanInstance object itself is an internal detail of the
Kernel itself, and has been carefully written so user code should never
be able to obtain a reference to the instance object. This allows me
to have complete freedom over the gbean implementation behind the
kernel interface.
> However, the GBeanInstance ctor insists on creating a new object from
> scratch - no good if I want to just proxy one already existing in
> Spring.... (unless I add yet another layer of wrapping, which is not
> ideal).
>
> So, I guess I am looking at altering or subclassing GBeanInstance to
> allow the passing in of an object to be wrapped and extending the
> Kernel with a method to loadGBean() around an already existing object.
>
> Are the people who know about how the kernel works happy with this
> solution, or have I missed another way of achieving this ?
>
> Are you happy for me to put this in, or would you like to do this
> yourselves ?
The plan for integrating component frameworks such as spring is to
write a GBean component that holds the spring object delegates method
calls to it. Yes this is another layer of indirection, but it can be
made very fast. This way, spring can handle construction and your
GBean component simply wraps it.
-dain
Re: Geronimo/Spring integration - configurations?
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Jeremy Boynes wrote:
> Jules Gosnell wrote:
>
>>>
>>> The intent behind GBeans is that they are long running services -
>>> for example, running for the lifetime of an application. Is that how
>>> Spring would be using them or are you trying to create/delete
>>> instances frequently (say on each web request)?
>>
>>
>>
>> long running services - the SpringGBean will do a kernel load and a
>> kernel start on each one at the start-time of the module and a kernel
>> stop and unload on each one at module stop-time.
>>
>
> This is exactly what a Configuration does to the GBean it contains -
> do you think there is a way we can package a set of Spring components
> into a Configuration?
>
> The state portion of a Configuration comprises of:
> * GBeanInfo describing classes of GBeans
> * GBeanData describing instances of GBeans, with the values of their
> persistent attributes
>
> When a Configuration starts, it loads GBeans into the kernel for each
> GBeanData present which:
> 1) instantiates the target instances,
> 2) initializes them with their persistent attributes via CDI or SDI, and
> 3) leaves them in the STOPPED state;
>
> If startRecursive is used then the kernel will also attempt to start
> them.
>
> In an closely integrated world, a Spring builder would be able to
> convert all Spring components into persistent GBeans that can be
> placed into a Configuration. That Configuration could then run in any
> server containing just the runtime components it needed and you would
> not need to handle the runtime load,start,stop,unload,fail operations
> for every component.
I agree with all of this. unfortunately, in pre-Geronimo days,
containers did not tend to perform this native-component->GBean
precompilation, so I think it unlikely that Spring will separate the two
stages as cleanly as we would like. With the initial integration I have
gone for the path of least resistance, which is to do everything in the
runtime, since it is tricky to push it back to configration time. I will
be looking, with the Spring team's help, at pushing more and more back
to this stage. Ultimately, however, I think it unlikely that we will be
able to come up with a perfect solution as it would mean that all the
POJOs would have to serialisable (wouldn't they? - so that they can be
built, preconfigured and stashed during the configuration phase, then
unmarshalled and started up at runtime...). The lack of start/stop in a
POJOs lifecycle would also make this awkward, I would imagine. Which is
why I have mapped GBeanInstance.start() to POJO construct() and
GBeanInstance.stop() to the releasing of all the POJO references.
Does this make sense ?
Jules
>
> --
> Jeremy
--
"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: Geronimo/Spring integration - configurations?
Posted by Jeremy Boynes <jb...@apache.org>.
Jules Gosnell wrote:
>>
>> The intent behind GBeans is that they are long running services - for
>> example, running for the lifetime of an application. Is that how
>> Spring would be using them or are you trying to create/delete
>> instances frequently (say on each web request)?
>
>
> long running services - the SpringGBean will do a kernel load and a
> kernel start on each one at the start-time of the module and a kernel
> stop and unload on each one at module stop-time.
>
This is exactly what a Configuration does to the GBean it contains - do
you think there is a way we can package a set of Spring components into
a Configuration?
The state portion of a Configuration comprises of:
* GBeanInfo describing classes of GBeans
* GBeanData describing instances of GBeans, with the values of their
persistent attributes
When a Configuration starts, it loads GBeans into the kernel for each
GBeanData present which:
1) instantiates the target instances,
2) initializes them with their persistent attributes via CDI or SDI, and
3) leaves them in the STOPPED state;
If startRecursive is used then the kernel will also attempt to start them.
In an closely integrated world, a Spring builder would be able to
convert all Spring components into persistent GBeans that can be placed
into a Configuration. That Configuration could then run in any server
containing just the runtime components it needed and you would not need
to handle the runtime load,start,stop,unload,fail operations for every
component.
--
Jeremy
Re: Geronimo/Spring integration
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Jeremy Boynes wrote:
> Jules Gosnell wrote:
>
> <snip for the sake of clarity on the following points/>
>
>>
>>>
>>> To what extent is it necessary for Spring to register the actual
>>> POJOs at runtime? How much can be built before hand and be packaged
>>> into a Geronimo Configuration?
>>
>>
>>
>> Good question.... I guess it comes down to the fact that user code
>> may be supplied to create the beans inside Spring. So, these must be
>> created at runtime, since we have no protocol with which we can
>> dehydrate/rehydrate them in the way that we can a normal J2EE app.
>> Since, I don't actually see the full set of Beans until runtime, i
>> don't have a chance to build GBean proxies for them until this point.
>> maybe we can break up the process somewhere in Spring and get all
>> this information out without actually creating the bean instances
>> themselves - Rob ?
>>
>
> Would an alternative here be to change the GBean wrapper so that
> instead of constructing the target itself it called out to a factory
> defined in the GBeanInfo? Basic Geronimo could continue to use the
> constructor but we would call back to Spring or the user's factory.
>
This would work just as well - I could simply wrap the instance that I
wanted to inject into the kernel in a SingletonFactory that always
returned it, but this, until my current proxying approach throws up a
problem, is no longer an issue, just a refactoring now.
>
>>>
>>> To me, the challenges here are not in the lifecycle but in how
>>> references between objects are handled. I would have thought some
>>> level of proxy integration would also be needed with integration at
>>> this low a level.
>>
I agree completely. I only got sidetracked into the lifecycle issue
because David mentioned it as a concern.
>>
>>
>> So, can we drill down on this - what problems do you foresee that
>> putting a proxy, dumb or otherwise, between me and you will solve ? I
>> simply create the beans when i am started and destroy them when i am
>> stopped....
>>
>
> I think there are two things going on here.
>
> Firstly, there is a desire to expose Spring components to management
> via Geronimo's infrastructure (JMX or otherwise). In the same way
> Spring can register them directly with JMX, we would like to support
> the ability to register them with Geronimo - this is what your patch
> is doing and in this simple scenario I see no issues.
>
:-)
>
> Secondly, and this is where I see concerns, is that both Spring and
> Geronimo already intercept inter-component references and replace them
> with proxies. If the reference type is a interface we may be OK, but
> we both support proxied references to classes and I am concerned about
> interference between the two proxy mechanisms - for example, if the
> only thing Geronimo knows about is the cglib proxy and it contains
> final methods.
now these are valid concerns.
>
> In any non-trival example, the POJO you are registering is going to
> contain Spring proxies for the inter-POJO references. Can we leave
> those as they are, or do we need to re-proxy them with Geronimo
> references? Do we need to add a mechanism to the kernel to allow
> Spring to obtain a Geronimo reference to a GBean so that it can inject
> it up front?
>
these are all things that will require someone having a deep
understanding of both Geronimo and Spring proxying technologies and
their interaction. I figured the best approach was to suck-it-n-see.
With friends in both the Geronimo and Spring camp we should be able to
overcome any issues that arise, or at least mark them as no-mans-land
and steer people away from using the problem features with warnings etc.
> Geronimo transparently re-proxies references (and updates collection
> valued ones) as a referenced GBean gets loaded and unloaded. Will this
> continue to work with Spring proxies present?
all interesting areas to look into.
let me get the code checked in (I need the cglib upgrade) and then i
will look at some more serious testing - I may need some advice on how
to tickle the kernel into doing these things...
>
>>>
>>> Thanks
>>
>>
>>
>> Thank you fot taking the time to go through this with me.
>>
>
> Better sooner than later :-)
too true :-)
Jules
> --
> Jeremy
--
"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: Geronimo/Spring integration
Posted by Jeremy Boynes <jb...@apache.org>.
Jules Gosnell wrote:
<snip for the sake of clarity on the following points/>
>
>>
>> To what extent is it necessary for Spring to register the actual POJOs
>> at runtime? How much can be built before hand and be packaged into a
>> Geronimo Configuration?
>
>
> Good question.... I guess it comes down to the fact that user code may
> be supplied to create the beans inside Spring. So, these must be created
> at runtime, since we have no protocol with which we can
> dehydrate/rehydrate them in the way that we can a normal J2EE app.
> Since, I don't actually see the full set of Beans until runtime, i don't
> have a chance to build GBean proxies for them until this point. maybe we
> can break up the process somewhere in Spring and get all this
> information out without actually creating the bean instances themselves
> - Rob ?
>
Would an alternative here be to change the GBean wrapper so that instead
of constructing the target itself it called out to a factory defined in
the GBeanInfo? Basic Geronimo could continue to use the constructor but
we would call back to Spring or the user's factory.
>>
>> To me, the challenges here are not in the lifecycle but in how
>> references between objects are handled. I would have thought some
>> level of proxy integration would also be needed with integration at
>> this low a level.
>
>
> So, can we drill down on this - what problems do you foresee that
> putting a proxy, dumb or otherwise, between me and you will solve ? I
> simply create the beans when i am started and destroy them when i am
> stopped....
>
I think there are two things going on here.
Firstly, there is a desire to expose Spring components to management via
Geronimo's infrastructure (JMX or otherwise). In the same way Spring can
register them directly with JMX, we would like to support the ability to
register them with Geronimo - this is what your patch is doing and in
this simple scenario I see no issues.
Secondly, and this is where I see concerns, is that both Spring and
Geronimo already intercept inter-component references and replace them
with proxies. If the reference type is a interface we may be OK, but we
both support proxied references to classes and I am concerned about
interference between the two proxy mechanisms - for example, if the only
thing Geronimo knows about is the cglib proxy and it contains final methods.
In any non-trival example, the POJO you are registering is going to
contain Spring proxies for the inter-POJO references. Can we leave those
as they are, or do we need to re-proxy them with Geronimo references? Do
we need to add a mechanism to the kernel to allow Spring to obtain a
Geronimo reference to a GBean so that it can inject it up front?
Geronimo transparently re-proxies references (and updates collection
valued ones) as a referenced GBean gets loaded and unloaded. Will this
continue to work with Spring proxies present?
>>
>> Thanks
>
>
> Thank you fot taking the time to go through this with me.
>
Better sooner than later :-)
--
Jeremy
Re: Geronimo/Spring integration - Moving forward... (Dain, David,
Jeremy,... - Please read)
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Jeremy Boynes wrote:
> I don't know enough about Spring's internals to really evaluate this
> but here are a few questions.
Rob may like to qualify this, but I will give it a shot.
>
> The intent behind GBeans is that they are long running services - for
> example, running for the lifetime of an application. Is that how
> Spring would be using them or are you trying to create/delete
> instances frequently (say on each web request)?
long running services - the SpringGBean will do a kernel load and a
kernel start on each one at the start-time of the module and a kernel
stop and unload on each one at module stop-time.
>
> I didn't see anything in the patch about unregistering an instance -
> how would that happen?
kernel stop and kernal unload in the SpringGBean that represents the
module. You didn't see this because it was not part of the patch to the
kernel.
>
> Is the target really the user's POJO or is it a Spring proxy? If the
> latter, doesn't it have final methods which would cause a problem for
> Geronimo trying to create proxies to it when it is referenced by other
> GBeans? If the former, is there a problem with having two proxy stacks
> (Spring's and Geronimo's)?
I believe that in certain cases it is a 1.3 or cglib proxy, if Spring
needs to e.g. aspect it, otherwise i think it is whatever the user has
specified i.e. probably a POJO - Rob ? We have to assume that it may
have final methods because user space classes can do whatever they want.
>
> Doesn't the instance get double initialized - once via Spring and then
> again via setter injection from the GBeanData?
If Geronimo held a persistant configuration for the POJO (my ultimate
goal), then yes, this might be the case. If the same setter being called
twice is a problem for the bean then i would say it was a badly written
bean and this was a problem for the app-writer. We could get a bit more
clever and merge Geronimo and Spring's injection so that each setter
gets called once...
>
> To what extent is it necessary for Spring to register the actual POJOs
> at runtime? How much can be built before hand and be packaged into a
> Geronimo Configuration?
Good question.... I guess it comes down to the fact that user code may
be supplied to create the beans inside Spring. So, these must be created
at runtime, since we have no protocol with which we can
dehydrate/rehydrate them in the way that we can a normal J2EE app.
Since, I don't actually see the full set of Beans until runtime, i don't
have a chance to build GBean proxies for them until this point. maybe we
can break up the process somewhere in Spring and get all this
information out without actually creating the bean instances themselves
- Rob ?
>
> To me, the challenges here are not in the lifecycle but in how
> references between objects are handled. I would have thought some
> level of proxy integration would also be needed with integration at
> this low a level.
So, can we drill down on this - what problems do you foresee that
putting a proxy, dumb or otherwise, between me and you will solve ? I
simply create the beans when i am started and destroy them when i am
stopped....
>
> Thanks
Thank you fot taking the time to go through this with me.
Jules
> --
> Jeremy
>
>
> Jules Gosnell wrote:
>
>>
>> I enclose a minimal (15 lines changed/added) patch to the kernel
>> which allows a POJO to be passed via Kernel.loadGBeanProxy(). This
>> POJO is subsequently used as the target of the ensuing GBeanInstance.
>> If the target is already initialise, the GBeanInstance does not
>> bother to construct a fresh instance of its target's class, it just
>> uses the one it has been given.
>>
>> Pros:
>>
>> It allows existing POJOs to take advantage of management and
>> monitoring services provided by the kernel.
>>
>> Cons:
>>
>> person providing this POJO needs to be careful about managing its
>> lifecycle - it must be loaded into the kernel after construction and
>> unloaded before destruction. If it implements GBeanLifecycle the
>> relevant methods will be called at the relevant time.
>>
>> Thoughts:
>>
>> This is really a minimal patch, designed to demonstrate exactly what
>> I am talking about in the simplest manner. It should be immediately
>> obvious that if no target is supplied the codepath will be completely
>> unchanged. The path, if you do supply the target is suboptimal, many
>> lines are still executed finding constructors and arranging
>> parameters for them when they will never be called. Making the
>> current requirement for target classes to provide accessible
>> constructors conditional on whether a preconstructed target is not
>> supplied will take a little more effort, but I don't see any real
>> issue with this.
>>
--
"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: Geronimo/Spring integration - Moving forward... (Dain, David,
Jeremy,... - Please read)
Posted by Jeremy Boynes <jb...@apache.org>.
I don't know enough about Spring's internals to really evaluate this but
here are a few questions.
The intent behind GBeans is that they are long running services - for
example, running for the lifetime of an application. Is that how Spring
would be using them or are you trying to create/delete instances
frequently (say on each web request)?
I didn't see anything in the patch about unregistering an instance - how
would that happen?
Is the target really the user's POJO or is it a Spring proxy? If the
latter, doesn't it have final methods which would cause a problem for
Geronimo trying to create proxies to it when it is referenced by other
GBeans? If the former, is there a problem with having two proxy stacks
(Spring's and Geronimo's)?
Doesn't the instance get double initialized - once via Spring and then
again via setter injection from the GBeanData?
To what extent is it necessary for Spring to register the actual POJOs
at runtime? How much can be built before hand and be packaged into a
Geronimo Configuration?
To me, the challenges here are not in the lifecycle but in how
references between objects are handled. I would have thought some level
of proxy integration would also be needed with integration at this low a
level.
Thanks
--
Jeremy
Jules Gosnell wrote:
>
> I enclose a minimal (15 lines changed/added) patch to the kernel which
> allows a POJO to be passed via Kernel.loadGBeanProxy(). This POJO is
> subsequently used as the target of the ensuing GBeanInstance. If the
> target is already initialise, the GBeanInstance does not bother to
> construct a fresh instance of its target's class, it just uses the one
> it has been given.
>
> Pros:
>
> It allows existing POJOs to take advantage of management and monitoring
> services provided by the kernel.
>
> Cons:
>
> person providing this POJO needs to be careful about managing its
> lifecycle - it must be loaded into the kernel after construction and
> unloaded before destruction. If it implements GBeanLifecycle the
> relevant methods will be called at the relevant time.
>
> Thoughts:
>
> This is really a minimal patch, designed to demonstrate exactly what I
> am talking about in the simplest manner. It should be immediately
> obvious that if no target is supplied the codepath will be completely
> unchanged. The path, if you do supply the target is suboptimal, many
> lines are still executed finding constructors and arranging parameters
> for them when they will never be called. Making the current requirement
> for target classes to provide accessible constructors conditional on
> whether a preconstructed target is not supplied will take a little more
> effort, but I don't see any real issue with this.
>
Re: Geronimo/Spring integration - Moving forward... (Dain, David,
Jeremy,... - Please read)
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Jules Gosnell wrote:
> Jeremy Boynes wrote:
>
>> Jules Gosnell wrote:
>>
>>>
>>> I would like to change the kernel - I don't think there is much
>>> value in Spring support if the first thing we do is to start eroding
>>> its feature set.
>>>
>>
>> Please not at this time - IMHO changes to the kernel now would pose
>> too much risk to the rest of the project with the progress to J2EE
>> certification.
>>
>> Let's explore this in detail first (cough, design work, cough) and
>> fire off a branch specifically for Spring if necessary.
>>
> OK - I will explore it in my local filespace and see how invasive the
> change that I need is - then I will come back with my findings and you
> guys can comment.
>
> Jules
I enclose a minimal (15 lines changed/added) patch to the kernel which
allows a POJO to be passed via Kernel.loadGBeanProxy(). This POJO is
subsequently used as the target of the ensuing GBeanInstance. If the
target is already initialise, the GBeanInstance does not bother to
construct a fresh instance of its target's class, it just uses the one
it has been given.
Pros:
It allows existing POJOs to take advantage of management and monitoring
services provided by the kernel.
Cons:
person providing this POJO needs to be careful about managing its
lifecycle - it must be loaded into the kernel after construction and
unloaded before destruction. If it implements GBeanLifecycle the
relevant methods will be called at the relevant time.
Thoughts:
This is really a minimal patch, designed to demonstrate exactly what I
am talking about in the simplest manner. It should be immediately
obvious that if no target is supplied the codepath will be completely
unchanged. The path, if you do supply the target is suboptimal, many
lines are still executed finding constructors and arranging parameters
for them when they will never be called. Making the current requirement
for target classes to provide accessible constructors conditional on
whether a preconstructed target is not supplied will take a little more
effort, but I don't see any real issue with this.
So, Guys, what I am proposing is not really that scary is it ? What do
you think ?
Jules
>
>> --
>> Jeremy
>
>
>
>
--
"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: Geronimo/Spring integration - Moving forward... (Dain, David,
Jeremy,... - Please read)
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Jeremy Boynes wrote:
> Jules Gosnell wrote:
>
>>
>> I would like to change the kernel - I don't think there is much value
>> in Spring support if the first thing we do is to start eroding its
>> feature set.
>>
>
> Please not at this time - IMHO changes to the kernel now would pose
> too much risk to the rest of the project with the progress to J2EE
> certification.
>
> Let's explore this in detail first (cough, design work, cough) and
> fire off a branch specifically for Spring if necessary.
>
OK - I will explore it in my local filespace and see how invasive the
change that I need is - then I will come back with my findings and you
guys can comment.
Jules
> --
> Jeremy
--
"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: Geronimo/Spring integration - Moving forward... (Dain, David,
Jeremy,... - Please read)
Posted by Jeremy Boynes <jb...@apache.org>.
Jules Gosnell wrote:
>
> I would like to change the kernel - I don't think there is much value in
> Spring support if the first thing we do is to start eroding its feature
> set.
>
Please not at this time - IMHO changes to the kernel now would pose too
much risk to the rest of the project with the progress to J2EE
certification.
Let's explore this in detail first (cough, design work, cough) and fire
off a branch specifically for Spring if necessary.
--
Jeremy
Re: Geronimo/Spring integration - Moving forward... (Dain, David,
Jeremy,... - Please read)
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Jules Gosnell wrote:
> David Jencks wrote:
>
>>
>> On Feb 2, 2005, at 7:54 AM, Jules Gosnell wrote:
>>
>>> Jules Gosnell wrote:
>>>
>>>> Rob Harrop wrote:
>>>>
>>>>> Jules,
>>>>>
>>>>> The Spring config file does not change when new modules are added,
>>>>> it is generic enough to support most configuration options. For
>>>>> JMX metadata we currently use interfaces or source level metadata
>>>>> (Commons Attributes or Annotations). I am working on an XML-based
>>>>> JMX descriptor, but this is separate from the core config file.
>>>>> You can hook into the JMX registration process by implementing the
>>>>> RegistrationStrategy interface and you can then transform the
>>>>> MBean into a GBean. The MBeans we use are ModelMBeans so you can
>>>>> get all the metadata from that.
>>>>>
>>>> Excellent :-)
>>>>
>>>> I am just putting in a placeholder POJOGBean that wraps each POJO,
>>>> but the API is simply that of GBean (i.e. has one accessor
>>>> getPeer()) at the moment - I have to look into how we can
>>>> dynamically declare an interface's metadata to the kernel...
>>>
>>>
>>>
>>>
>>> I'm looking at how I can interface a POJO with the Geronimo kernel.
>>>
>>> GBeanInstance has a concept of 'target' (see getTarget()) which
>>> GBeanAttributes and Operations seem to use to retrieve the object on
>>> which to act. So, this is good - I just need to make GBeanInstance
>>> wrap a ready made object (my POJO) instead of constructing another
>>> one...
>>>
>>> However, the GBeanInstance ctor insists on creating a new object
>>> from scratch - no good if I want to just proxy one already existing
>>> in Spring.... (unless I add yet another layer of wrapping, which is
>>> not ideal).
>>>
>>> So, I guess I am looking at altering or subclassing GBeanInstance to
>>> allow the passing in of an object to be wrapped and extending the
>>> Kernel with a method to loadGBean() around an already existing object.
>>>
>>> Are the people who know about how the kernel works happy with this
>>> solution, or have I missed another way of achieving this ?
>>
>>
>>
>> This makes me extremely nervous. We will have two dependency
>> management systems working on the same objects, and I think they will
>> surely conflict.
>>
>> What exactly does Spring do? Can we get whatever it does in the way
>> of instantiation to create gbeans instead of POJOs?
>
>
> I'll check with Rob, perhaps we can take over the creation of Beans
> within Spring. I understand your reticence to wrap objects over whose
> lifecycle you have no control - perhaps you could think of it as
> delegating this control to another part of Geronimo, the SpringGBean,
> which in turn delegates it to Spring.
>
Bad news.
Has a good look around Spring and realised that this approach will hit a
show-stopper. Spring allows the configuration of factory objects for
contained beans. This means that bean construction can be done by
user-space code. This code could be doing anything, so there is no way
that Geronimo could replace it. We have no option therefore but to
either say "We support a SUBSET of Spring" or extend the kernel to allow
facading of existing beans as well as kernel-owned ones.
I would like to change the kernel - I don't think there is much value in
Spring support if the first thing we do is to start eroding its feature set.
I am going to make some test alterations to the kernel and see if I can
get it to work - I promise not to check anything in ;-).
I'll submit my changes to you, David, for review, if I am successful.
Any further thoughts on the subject will be most welcome.
Jules
> So, I can infer from this that there is no existing mechnism for
> plugging existing instances into the Geronimo kernel ?
>
> Anyone else have any thoughts on this ?
>
> Cheers,
>
>
> Jules
>
>>
>> thanks
>> david jencks
>>
>>>
>>> Are you happy for me to put this in, or would you like to do this
>>> yourselves ?
>>>
>>> Cheers,
>>>
>>>
>>> Jules
>>>
>>>
>>>
>>>
>>>>
>>>> Jules
>>>>
>>>>> Rob
>>>>>
>>>>> Jules Gosnell wrote:
>>>>>
>>>>>> Rob Harrop wrote:
>>>>>>
>>>>>>> Jules,
>>>>>>>
>>>>>>> I think it is best to keep the metadata in geronimo-spring.xml,
>>>>>>> purely because spring.xml has no support for modifying the XML
>>>>>>> format. You want that to be a standard Spring config with no
>>>>>>> special features.
>>>>>>>
>>>>>> I though you might say that :-)
>>>>>>
>>>>>> We will end up with an xdoclet template to generate a
>>>>>> geronimo-spring.xml with metadata about classes and methods that
>>>>>> need exposing and keep it in sync with the code.... - maybe this
>>>>>> can be done via source-level attributes...
>>>>>>
>>>>>> Does Spring not have any tag (or requirement for one - e.g. for
>>>>>> JMX exporting), which, in a Geronimo context, might be overloaded
>>>>>> to mean "export to Geronimo kernel" rather than just "export to
>>>>>> JMX Agent" ? i.e. just "export to relevant infrastructure".
>>>>>>
>>>>>>> From a Spring perspective, the two things we need are
>>>>>>> JMX-exposed POJOs, which we can already do, and a JNDI-bound
>>>>>>> ApplicationContext which will allow for transparent merging of
>>>>>>> shared services into an application.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> The more I'm learning about this stuff, the less straightforward
>>>>>> it is becoming :-(
>>>>>>
>>>>>> It doesn't seem enough to just expose POJOs to JMX, since
>>>>>> Geronimo doesn't necessarily use it - we have to expose ourselves
>>>>>> to the kernel as GBeans, which means that the Spring JMX support
>>>>>> needs to kick out something which can be transformed into/look
>>>>>> like a GBean description, or we need to build it from the ground up.
>>>>>>
>>>>>> Re JNDI - from what David is saying, it looks like being a
>>>>>> well-named GBean may be enough to get us published via JNDI. I
>>>>>> will investigate this more today.
>>>>>>
>>>>>> Happy hacking ;-)
>>>>>>
>>>>>> Jules
>>>>>>
>>>>>>>
>>>>>>> Rob
>>>>>>>
>>>>>>> Jules Gosnell wrote:
>>>>>>>
>>>>>>>>
>>>>>>>> I've taken all of the points raised on board and just checked
>>>>>>>> in the second cut, which splits Spring support into runtime and
>>>>>>>> deploy time components.
>>>>>>>>
>>>>>>>> I'm still having trouble getting the Builder spotted by the
>>>>>>>> Deployer, but as long as I run the DebugConsole config aswell I
>>>>>>>> am OK - I'll look further into it when the dust dies down.
>>>>>>>>
>>>>>>>> If anyone wants to take another look at the code and comment
>>>>>>>> (yeah - I know it's ugly at the moment) that would be
>>>>>>>> gratefully received.
>>>>>>>>
>>>>>>>> Rob, what are your thoughts on publishing POJOs to the Geronimo
>>>>>>>> kernel ? Do we just blindly export all of them, can you attach
>>>>>>>> metadata in the spring.xml or source, or do you think it should
>>>>>>>> go in the geronimo-spring.xml.
>>>>>>>>
>>>>>>>> Logically, I think it should go in the latter, however,
>>>>>>>> pragmatically, this will lead to a maintenance nightmare as
>>>>>>>> spring.xml moves on and geronimo-spring.xml fossilises, so I
>>>>>>>> would rather see a single descriptor... - I guess we could do
>>>>>>>> both ?
>>>>>>>>
>>>>>>>> Anyone have any interesting thoughts ?
>>>>>>>>
>>>>>>>> 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.
**********************************/
Re: Geronimo/Spring integration - Moving forward... (Dain, David,
Jeremy,... - Please read)
Posted by Jules Gosnell <ju...@coredevelopers.net>.
David Jencks wrote:
>
> On Feb 2, 2005, at 7:54 AM, Jules Gosnell wrote:
>
>> Jules Gosnell wrote:
>>
>>> Rob Harrop wrote:
>>>
>>>> Jules,
>>>>
>>>> The Spring config file does not change when new modules are added,
>>>> it is generic enough to support most configuration options. For JMX
>>>> metadata we currently use interfaces or source level metadata
>>>> (Commons Attributes or Annotations). I am working on an XML-based
>>>> JMX descriptor, but this is separate from the core config file. You
>>>> can hook into the JMX registration process by implementing the
>>>> RegistrationStrategy interface and you can then transform the MBean
>>>> into a GBean. The MBeans we use are ModelMBeans so you can get all
>>>> the metadata from that.
>>>>
>>> Excellent :-)
>>>
>>> I am just putting in a placeholder POJOGBean that wraps each POJO,
>>> but the API is simply that of GBean (i.e. has one accessor
>>> getPeer()) at the moment - I have to look into how we can
>>> dynamically declare an interface's metadata to the kernel...
>>
>>
>>
>> I'm looking at how I can interface a POJO with the Geronimo kernel.
>>
>> GBeanInstance has a concept of 'target' (see getTarget()) which
>> GBeanAttributes and Operations seem to use to retrieve the object on
>> which to act. So, this is good - I just need to make GBeanInstance
>> wrap a ready made object (my POJO) instead of constructing another
>> one...
>>
>> However, the GBeanInstance ctor insists on creating a new object from
>> scratch - no good if I want to just proxy one already existing in
>> Spring.... (unless I add yet another layer of wrapping, which is not
>> ideal).
>>
>> So, I guess I am looking at altering or subclassing GBeanInstance to
>> allow the passing in of an object to be wrapped and extending the
>> Kernel with a method to loadGBean() around an already existing object.
>>
>> Are the people who know about how the kernel works happy with this
>> solution, or have I missed another way of achieving this ?
>
>
> This makes me extremely nervous. We will have two dependency
> management systems working on the same objects, and I think they will
> surely conflict.
>
> What exactly does Spring do? Can we get whatever it does in the way
> of instantiation to create gbeans instead of POJOs?
I'll check with Rob, perhaps we can take over the creation of Beans
within Spring. I understand your reticence to wrap objects over whose
lifecycle you have no control - perhaps you could think of it as
delegating this control to another part of Geronimo, the SpringGBean,
which in turn delegates it to Spring.
So, I can infer from this that there is no existing mechnism for
plugging existing instances into the Geronimo kernel ?
Anyone else have any thoughts on this ?
Cheers,
Jules
>
> thanks
> david jencks
>
>>
>> Are you happy for me to put this in, or would you like to do this
>> yourselves ?
>>
>> Cheers,
>>
>>
>> Jules
>>
>>
>>
>>
>>>
>>> Jules
>>>
>>>> Rob
>>>>
>>>> Jules Gosnell wrote:
>>>>
>>>>> Rob Harrop wrote:
>>>>>
>>>>>> Jules,
>>>>>>
>>>>>> I think it is best to keep the metadata in geronimo-spring.xml,
>>>>>> purely because spring.xml has no support for modifying the XML
>>>>>> format. You want that to be a standard Spring config with no
>>>>>> special features.
>>>>>>
>>>>> I though you might say that :-)
>>>>>
>>>>> We will end up with an xdoclet template to generate a
>>>>> geronimo-spring.xml with metadata about classes and methods that
>>>>> need exposing and keep it in sync with the code.... - maybe this
>>>>> can be done via source-level attributes...
>>>>>
>>>>> Does Spring not have any tag (or requirement for one - e.g. for
>>>>> JMX exporting), which, in a Geronimo context, might be overloaded
>>>>> to mean "export to Geronimo kernel" rather than just "export to
>>>>> JMX Agent" ? i.e. just "export to relevant infrastructure".
>>>>>
>>>>>> From a Spring perspective, the two things we need are JMX-exposed
>>>>>> POJOs, which we can already do, and a JNDI-bound
>>>>>> ApplicationContext which will allow for transparent merging of
>>>>>> shared services into an application.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> The more I'm learning about this stuff, the less straightforward
>>>>> it is becoming :-(
>>>>>
>>>>> It doesn't seem enough to just expose POJOs to JMX, since Geronimo
>>>>> doesn't necessarily use it - we have to expose ourselves to the
>>>>> kernel as GBeans, which means that the Spring JMX support needs to
>>>>> kick out something which can be transformed into/look like a GBean
>>>>> description, or we need to build it from the ground up.
>>>>>
>>>>> Re JNDI - from what David is saying, it looks like being a
>>>>> well-named GBean may be enough to get us published via JNDI. I
>>>>> will investigate this more today.
>>>>>
>>>>> Happy hacking ;-)
>>>>>
>>>>> Jules
>>>>>
>>>>>>
>>>>>> Rob
>>>>>>
>>>>>> Jules Gosnell wrote:
>>>>>>
>>>>>>>
>>>>>>> I've taken all of the points raised on board and just checked in
>>>>>>> the second cut, which splits Spring support into runtime and
>>>>>>> deploy time components.
>>>>>>>
>>>>>>> I'm still having trouble getting the Builder spotted by the
>>>>>>> Deployer, but as long as I run the DebugConsole config aswell I
>>>>>>> am OK - I'll look further into it when the dust dies down.
>>>>>>>
>>>>>>> If anyone wants to take another look at the code and comment
>>>>>>> (yeah - I know it's ugly at the moment) that would be gratefully
>>>>>>> received.
>>>>>>>
>>>>>>> Rob, what are your thoughts on publishing POJOs to the Geronimo
>>>>>>> kernel ? Do we just blindly export all of them, can you attach
>>>>>>> metadata in the spring.xml or source, or do you think it should
>>>>>>> go in the geronimo-spring.xml.
>>>>>>>
>>>>>>> Logically, I think it should go in the latter, however,
>>>>>>> pragmatically, this will lead to a maintenance nightmare as
>>>>>>> spring.xml moves on and geronimo-spring.xml fossilises, so I
>>>>>>> would rather see a single descriptor... - I guess we could do
>>>>>>> both ?
>>>>>>>
>>>>>>> Anyone have any interesting thoughts ?
>>>>>>>
>>>>>>> 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.
**********************************/
Re: Geronimo/Spring integration - Moving forward... (Dain, David, Jeremy,... - Please read)
Posted by David Jencks <dj...@gluecode.com>.
On Feb 2, 2005, at 7:54 AM, Jules Gosnell wrote:
> Jules Gosnell wrote:
>
>> Rob Harrop wrote:
>>
>>> Jules,
>>>
>>> The Spring config file does not change when new modules are added,
>>> it is generic enough to support most configuration options. For JMX
>>> metadata we currently use interfaces or source level metadata
>>> (Commons Attributes or Annotations). I am working on an XML-based
>>> JMX descriptor, but this is separate from the core config file. You
>>> can hook into the JMX registration process by implementing the
>>> RegistrationStrategy interface and you can then transform the MBean
>>> into a GBean. The MBeans we use are ModelMBeans so you can get all
>>> the metadata from that.
>>>
>> Excellent :-)
>>
>> I am just putting in a placeholder POJOGBean that wraps each POJO,
>> but the API is simply that of GBean (i.e. has one accessor getPeer())
>> at the moment - I have to look into how we can dynamically declare an
>> interface's metadata to the kernel...
>
>
> I'm looking at how I can interface a POJO with the Geronimo kernel.
>
> GBeanInstance has a concept of 'target' (see getTarget()) which
> GBeanAttributes and Operations seem to use to retrieve the object on
> which to act. So, this is good - I just need to make GBeanInstance
> wrap a ready made object (my POJO) instead of constructing another
> one...
>
> However, the GBeanInstance ctor insists on creating a new object from
> scratch - no good if I want to just proxy one already existing in
> Spring.... (unless I add yet another layer of wrapping, which is not
> ideal).
>
> So, I guess I am looking at altering or subclassing GBeanInstance to
> allow the passing in of an object to be wrapped and extending the
> Kernel with a method to loadGBean() around an already existing object.
>
> Are the people who know about how the kernel works happy with this
> solution, or have I missed another way of achieving this ?
This makes me extremely nervous. We will have two dependency
management systems working on the same objects, and I think they will
surely conflict.
What exactly does Spring do? Can we get whatever it does in the way of
instantiation to create gbeans instead of POJOs?
thanks
david jencks
>
> Are you happy for me to put this in, or would you like to do this
> yourselves ?
>
> Cheers,
>
>
> Jules
>
>
>
>
>>
>> Jules
>>
>>> Rob
>>>
>>> Jules Gosnell wrote:
>>>
>>>> Rob Harrop wrote:
>>>>
>>>>> Jules,
>>>>>
>>>>> I think it is best to keep the metadata in geronimo-spring.xml,
>>>>> purely because spring.xml has no support for modifying the XML
>>>>> format. You want that to be a standard Spring config with no
>>>>> special features.
>>>>>
>>>> I though you might say that :-)
>>>>
>>>> We will end up with an xdoclet template to generate a
>>>> geronimo-spring.xml with metadata about classes and methods that
>>>> need exposing and keep it in sync with the code.... - maybe this
>>>> can be done via source-level attributes...
>>>>
>>>> Does Spring not have any tag (or requirement for one - e.g. for JMX
>>>> exporting), which, in a Geronimo context, might be overloaded to
>>>> mean "export to Geronimo kernel" rather than just "export to JMX
>>>> Agent" ? i.e. just "export to relevant infrastructure".
>>>>
>>>>> From a Spring perspective, the two things we need are JMX-exposed
>>>>> POJOs, which we can already do, and a JNDI-bound
>>>>> ApplicationContext which will allow for transparent merging of
>>>>> shared services into an application.
>>>>
>>>>
>>>>
>>>>
>>>> The more I'm learning about this stuff, the less straightforward it
>>>> is becoming :-(
>>>>
>>>> It doesn't seem enough to just expose POJOs to JMX, since Geronimo
>>>> doesn't necessarily use it - we have to expose ourselves to the
>>>> kernel as GBeans, which means that the Spring JMX support needs to
>>>> kick out something which can be transformed into/look like a GBean
>>>> description, or we need to build it from the ground up.
>>>>
>>>> Re JNDI - from what David is saying, it looks like being a
>>>> well-named GBean may be enough to get us published via JNDI. I will
>>>> investigate this more today.
>>>>
>>>> Happy hacking ;-)
>>>>
>>>> Jules
>>>>
>>>>>
>>>>> Rob
>>>>>
>>>>> Jules Gosnell wrote:
>>>>>
>>>>>>
>>>>>> I've taken all of the points raised on board and just checked in
>>>>>> the second cut, which splits Spring support into runtime and
>>>>>> deploy time components.
>>>>>>
>>>>>> I'm still having trouble getting the Builder spotted by the
>>>>>> Deployer, but as long as I run the DebugConsole config aswell I
>>>>>> am OK - I'll look further into it when the dust dies down.
>>>>>>
>>>>>> If anyone wants to take another look at the code and comment
>>>>>> (yeah - I know it's ugly at the moment) that would be gratefully
>>>>>> received.
>>>>>>
>>>>>> Rob, what are your thoughts on publishing POJOs to the Geronimo
>>>>>> kernel ? Do we just blindly export all of them, can you attach
>>>>>> metadata in the spring.xml or source, or do you think it should
>>>>>> go in the geronimo-spring.xml.
>>>>>>
>>>>>> Logically, I think it should go in the latter, however,
>>>>>> pragmatically, this will lead to a maintenance nightmare as
>>>>>> spring.xml moves on and geronimo-spring.xml fossilises, so I
>>>>>> would rather see a single descriptor... - I guess we could do
>>>>>> both ?
>>>>>>
>>>>>> Anyone have any interesting thoughts ?
>>>>>>
>>>>>> 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: Geronimo/Spring integration - Moving forward... (Dain, David,
Jeremy,... - Please read)
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Jules Gosnell wrote:
> Rob Harrop wrote:
>
>> Jules,
>>
>> The Spring config file does not change when new modules are added, it
>> is generic enough to support most configuration options. For JMX
>> metadata we currently use interfaces or source level metadata
>> (Commons Attributes or Annotations). I am working on an XML-based JMX
>> descriptor, but this is separate from the core config file. You can
>> hook into the JMX registration process by implementing the
>> RegistrationStrategy interface and you can then transform the MBean
>> into a GBean. The MBeans we use are ModelMBeans so you can get all
>> the metadata from that.
>>
> Excellent :-)
>
> I am just putting in a placeholder POJOGBean that wraps each POJO, but
> the API is simply that of GBean (i.e. has one accessor getPeer()) at
> the moment - I have to look into how we can dynamically declare an
> interface's metadata to the kernel...
I'm looking at how I can interface a POJO with the Geronimo kernel.
GBeanInstance has a concept of 'target' (see getTarget()) which
GBeanAttributes and Operations seem to use to retrieve the object on
which to act. So, this is good - I just need to make GBeanInstance wrap
a ready made object (my POJO) instead of constructing another one...
However, the GBeanInstance ctor insists on creating a new object from
scratch - no good if I want to just proxy one already existing in
Spring.... (unless I add yet another layer of wrapping, which is not ideal).
So, I guess I am looking at altering or subclassing GBeanInstance to
allow the passing in of an object to be wrapped and extending the Kernel
with a method to loadGBean() around an already existing object.
Are the people who know about how the kernel works happy with this
solution, or have I missed another way of achieving this ?
Are you happy for me to put this in, or would you like to do this
yourselves ?
Cheers,
Jules
>
> Jules
>
>> Rob
>>
>> Jules Gosnell wrote:
>>
>>> Rob Harrop wrote:
>>>
>>>> Jules,
>>>>
>>>> I think it is best to keep the metadata in geronimo-spring.xml,
>>>> purely because spring.xml has no support for modifying the XML
>>>> format. You want that to be a standard Spring config with no
>>>> special features.
>>>>
>>> I though you might say that :-)
>>>
>>> We will end up with an xdoclet template to generate a
>>> geronimo-spring.xml with metadata about classes and methods that
>>> need exposing and keep it in sync with the code.... - maybe this can
>>> be done via source-level attributes...
>>>
>>> Does Spring not have any tag (or requirement for one - e.g. for JMX
>>> exporting), which, in a Geronimo context, might be overloaded to
>>> mean "export to Geronimo kernel" rather than just "export to JMX
>>> Agent" ? i.e. just "export to relevant infrastructure".
>>>
>>>> From a Spring perspective, the two things we need are JMX-exposed
>>>> POJOs, which we can already do, and a JNDI-bound ApplicationContext
>>>> which will allow for transparent merging of shared services into an
>>>> application.
>>>
>>>
>>>
>>>
>>> The more I'm learning about this stuff, the less straightforward it
>>> is becoming :-(
>>>
>>> It doesn't seem enough to just expose POJOs to JMX, since Geronimo
>>> doesn't necessarily use it - we have to expose ourselves to the
>>> kernel as GBeans, which means that the Spring JMX support needs to
>>> kick out something which can be transformed into/look like a GBean
>>> description, or we need to build it from the ground up.
>>>
>>> Re JNDI - from what David is saying, it looks like being a
>>> well-named GBean may be enough to get us published via JNDI. I will
>>> investigate this more today.
>>>
>>> Happy hacking ;-)
>>>
>>> Jules
>>>
>>>>
>>>> Rob
>>>>
>>>> Jules Gosnell wrote:
>>>>
>>>>>
>>>>> I've taken all of the points raised on board and just checked in
>>>>> the second cut, which splits Spring support into runtime and
>>>>> deploy time components.
>>>>>
>>>>> I'm still having trouble getting the Builder spotted by the
>>>>> Deployer, but as long as I run the DebugConsole config aswell I am
>>>>> OK - I'll look further into it when the dust dies down.
>>>>>
>>>>> If anyone wants to take another look at the code and comment (yeah
>>>>> - I know it's ugly at the moment) that would be gratefully received.
>>>>>
>>>>> Rob, what are your thoughts on publishing POJOs to the Geronimo
>>>>> kernel ? Do we just blindly export all of them, can you attach
>>>>> metadata in the spring.xml or source, or do you think it should go
>>>>> in the geronimo-spring.xml.
>>>>>
>>>>> Logically, I think it should go in the latter, however,
>>>>> pragmatically, this will lead to a maintenance nightmare as
>>>>> spring.xml moves on and geronimo-spring.xml fossilises, so I would
>>>>> rather see a single descriptor... - I guess we could do both ?
>>>>>
>>>>> Anyone have any interesting thoughts ?
>>>>>
>>>>> 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: Geronimo/Spring integration - Moving forward...
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Rob Harrop wrote:
> Jules,
>
> The Spring config file does not change when new modules are added, it
> is generic enough to support most configuration options. For JMX
> metadata we currently use interfaces or source level metadata (Commons
> Attributes or Annotations). I am working on an XML-based JMX
> descriptor, but this is separate from the core config file. You can
> hook into the JMX registration process by implementing the
> RegistrationStrategy interface and you can then transform the MBean
> into a GBean. The MBeans we use are ModelMBeans so you can get all the
> metadata from that.
>
Excellent :-)
I am just putting in a placeholder POJOGBean that wraps each POJO, but
the API is simply that of GBean (i.e. has one accessor getPeer()) at the
moment - I have to look into how we can dynamically declare an
interface's metadata to the kernel...
Jules
> Rob
>
> Jules Gosnell wrote:
>
>> Rob Harrop wrote:
>>
>>> Jules,
>>>
>>> I think it is best to keep the metadata in geronimo-spring.xml,
>>> purely because spring.xml has no support for modifying the XML
>>> format. You want that to be a standard Spring config with no special
>>> features.
>>>
>> I though you might say that :-)
>>
>> We will end up with an xdoclet template to generate a
>> geronimo-spring.xml with metadata about classes and methods that need
>> exposing and keep it in sync with the code.... - maybe this can be
>> done via source-level attributes...
>>
>> Does Spring not have any tag (or requirement for one - e.g. for JMX
>> exporting), which, in a Geronimo context, might be overloaded to mean
>> "export to Geronimo kernel" rather than just "export to JMX Agent" ?
>> i.e. just "export to relevant infrastructure".
>>
>>> From a Spring perspective, the two things we need are JMX-exposed
>>> POJOs, which we can already do, and a JNDI-bound ApplicationContext
>>> which will allow for transparent merging of shared services into an
>>> application.
>>
>>
>>
>> The more I'm learning about this stuff, the less straightforward it
>> is becoming :-(
>>
>> It doesn't seem enough to just expose POJOs to JMX, since Geronimo
>> doesn't necessarily use it - we have to expose ourselves to the
>> kernel as GBeans, which means that the Spring JMX support needs to
>> kick out something which can be transformed into/look like a GBean
>> description, or we need to build it from the ground up.
>>
>> Re JNDI - from what David is saying, it looks like being a well-named
>> GBean may be enough to get us published via JNDI. I will investigate
>> this more today.
>>
>> Happy hacking ;-)
>>
>> Jules
>>
>>>
>>> Rob
>>>
>>> Jules Gosnell wrote:
>>>
>>>>
>>>> I've taken all of the points raised on board and just checked in
>>>> the second cut, which splits Spring support into runtime and deploy
>>>> time components.
>>>>
>>>> I'm still having trouble getting the Builder spotted by the
>>>> Deployer, but as long as I run the DebugConsole config aswell I am
>>>> OK - I'll look further into it when the dust dies down.
>>>>
>>>> If anyone wants to take another look at the code and comment (yeah
>>>> - I know it's ugly at the moment) that would be gratefully received.
>>>>
>>>> Rob, what are your thoughts on publishing POJOs to the Geronimo
>>>> kernel ? Do we just blindly export all of them, can you attach
>>>> metadata in the spring.xml or source, or do you think it should go
>>>> in the geronimo-spring.xml.
>>>>
>>>> Logically, I think it should go in the latter, however,
>>>> pragmatically, this will lead to a maintenance nightmare as
>>>> spring.xml moves on and geronimo-spring.xml fossilises, so I would
>>>> rather see a single descriptor... - I guess we could do both ?
>>>>
>>>> Anyone have any interesting thoughts ?
>>>>
>>>> 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: Geronimo/Spring integration - Moving forward...
Posted by Rob Harrop <ro...@cakesolutions.net>.
Jules,
The Spring config file does not change when new modules are added, it is
generic enough to support most configuration options. For JMX metadata
we currently use interfaces or source level metadata (Commons Attributes
or Annotations). I am working on an XML-based JMX descriptor, but this
is separate from the core config file. You can hook into the JMX
registration process by implementing the RegistrationStrategy interface
and you can then transform the MBean into a GBean. The MBeans we use are
ModelMBeans so you can get all the metadata from that.
Rob
Jules Gosnell wrote:
> Rob Harrop wrote:
>
>> Jules,
>>
>> I think it is best to keep the metadata in geronimo-spring.xml,
>> purely because spring.xml has no support for modifying the XML
>> format. You want that to be a standard Spring config with no special
>> features.
>>
> I though you might say that :-)
>
> We will end up with an xdoclet template to generate a
> geronimo-spring.xml with metadata about classes and methods that need
> exposing and keep it in sync with the code.... - maybe this can be
> done via source-level attributes...
>
> Does Spring not have any tag (or requirement for one - e.g. for JMX
> exporting), which, in a Geronimo context, might be overloaded to mean
> "export to Geronimo kernel" rather than just "export to JMX Agent" ?
> i.e. just "export to relevant infrastructure".
>
>> From a Spring perspective, the two things we need are JMX-exposed
>> POJOs, which we can already do, and a JNDI-bound ApplicationContext
>> which will allow for transparent merging of shared services into an
>> application.
>
>
> The more I'm learning about this stuff, the less straightforward it is
> becoming :-(
>
> It doesn't seem enough to just expose POJOs to JMX, since Geronimo
> doesn't necessarily use it - we have to expose ourselves to the kernel
> as GBeans, which means that the Spring JMX support needs to kick out
> something which can be transformed into/look like a GBean description,
> or we need to build it from the ground up.
>
> Re JNDI - from what David is saying, it looks like being a well-named
> GBean may be enough to get us published via JNDI. I will investigate
> this more today.
>
> Happy hacking ;-)
>
> Jules
>
>>
>> Rob
>>
>> Jules Gosnell wrote:
>>
>>>
>>> I've taken all of the points raised on board and just checked in the
>>> second cut, which splits Spring support into runtime and deploy time
>>> components.
>>>
>>> I'm still having trouble getting the Builder spotted by the
>>> Deployer, but as long as I run the DebugConsole config aswell I am
>>> OK - I'll look further into it when the dust dies down.
>>>
>>> If anyone wants to take another look at the code and comment (yeah -
>>> I know it's ugly at the moment) that would be gratefully received.
>>>
>>> Rob, what are your thoughts on publishing POJOs to the Geronimo
>>> kernel ? Do we just blindly export all of them, can you attach
>>> metadata in the spring.xml or source, or do you think it should go
>>> in the geronimo-spring.xml.
>>>
>>> Logically, I think it should go in the latter, however,
>>> pragmatically, this will lead to a maintenance nightmare as
>>> spring.xml moves on and geronimo-spring.xml fossilises, so I would
>>> rather see a single descriptor... - I guess we could do both ?
>>>
>>> Anyone have any interesting thoughts ?
>>>
>>> Jules
>>>
>>>
>
>
Re: Geronimo/Spring integration - Moving forward...
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Rob Harrop wrote:
> Jules,
>
> I think it is best to keep the metadata in geronimo-spring.xml, purely
> because spring.xml has no support for modifying the XML format. You
> want that to be a standard Spring config with no special features.
>
I though you might say that :-)
We will end up with an xdoclet template to generate a
geronimo-spring.xml with metadata about classes and methods that need
exposing and keep it in sync with the code.... - maybe this can be done
via source-level attributes...
Does Spring not have any tag (or requirement for one - e.g. for JMX
exporting), which, in a Geronimo context, might be overloaded to mean
"export to Geronimo kernel" rather than just "export to JMX Agent" ?
i.e. just "export to relevant infrastructure".
> From a Spring perspective, the two things we need are JMX-exposed
> POJOs, which we can already do, and a JNDI-bound ApplicationContext
> which will allow for transparent merging of shared services into an
> application.
The more I'm learning about this stuff, the less straightforward it is
becoming :-(
It doesn't seem enough to just expose POJOs to JMX, since Geronimo
doesn't necessarily use it - we have to expose ourselves to the kernel
as GBeans, which means that the Spring JMX support needs to kick out
something which can be transformed into/look like a GBean description,
or we need to build it from the ground up.
Re JNDI - from what David is saying, it looks like being a well-named
GBean may be enough to get us published via JNDI. I will investigate
this more today.
Happy hacking ;-)
Jules
>
> Rob
>
> Jules Gosnell wrote:
>
>>
>> I've taken all of the points raised on board and just checked in the
>> second cut, which splits Spring support into runtime and deploy time
>> components.
>>
>> I'm still having trouble getting the Builder spotted by the Deployer,
>> but as long as I run the DebugConsole config aswell I am OK - I'll
>> look further into it when the dust dies down.
>>
>> If anyone wants to take another look at the code and comment (yeah -
>> I know it's ugly at the moment) that would be gratefully received.
>>
>> Rob, what are your thoughts on publishing POJOs to the Geronimo
>> kernel ? Do we just blindly export all of them, can you attach
>> metadata in the spring.xml or source, or do you think it should go in
>> the geronimo-spring.xml.
>>
>> Logically, I think it should go in the latter, however,
>> pragmatically, this will lead to a maintenance nightmare as
>> spring.xml moves on and geronimo-spring.xml fossilises, so I would
>> rather see a single descriptor... - I guess we could do both ?
>>
>> Anyone have any interesting thoughts ?
>>
>> 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: Geronimo/Spring integration - Moving forward...
Posted by Rob Harrop <ro...@cakesolutions.net>.
Jules,
I think it is best to keep the metadata in geronimo-spring.xml, purely
because spring.xml has no support for modifying the XML format. You want
that to be a standard Spring config with no special features.
From a Spring perspective, the two things we need are JMX-exposed
POJOs, which we can already do, and a JNDI-bound ApplicationContext
which will allow for transparent merging of shared services into an
application.
Rob
Jules Gosnell wrote:
>
> I've taken all of the points raised on board and just checked in the
> second cut, which splits Spring support into runtime and deploy time
> components.
>
> I'm still having trouble getting the Builder spotted by the Deployer,
> but as long as I run the DebugConsole config aswell I am OK - I'll
> look further into it when the dust dies down.
>
> If anyone wants to take another look at the code and comment (yeah - I
> know it's ugly at the moment) that would be gratefully received.
>
> Rob, what are your thoughts on publishing POJOs to the Geronimo kernel
> ? Do we just blindly export all of them, can you attach metadata in
> the spring.xml or source, or do you think it should go in the
> geronimo-spring.xml.
>
> Logically, I think it should go in the latter, however, pragmatically,
> this will lead to a maintenance nightmare as spring.xml moves on and
> geronimo-spring.xml fossilises, so I would rather see a single
> descriptor... - I guess we could do both ?
>
> Anyone have any interesting thoughts ?
>
> Jules
>
>
Re: Geronimo/Spring integration - Moving forward...
Posted by Jules Gosnell <ju...@coredevelopers.net>.
I've taken all of the points raised on board and just checked in the
second cut, which splits Spring support into runtime and deploy time
components.
I'm still having trouble getting the Builder spotted by the Deployer,
but as long as I run the DebugConsole config aswell I am OK - I'll look
further into it when the dust dies down.
If anyone wants to take another look at the code and comment (yeah - I
know it's ugly at the moment) that would be gratefully received.
Rob, what are your thoughts on publishing POJOs to the Geronimo kernel ?
Do we just blindly export all of them, can you attach metadata in the
spring.xml or source, or do you think it should go in the
geronimo-spring.xml.
Logically, I think it should go in the latter, however, pragmatically,
this will lead to a maintenance nightmare as spring.xml moves on and
geronimo-spring.xml fossilises, so I would rather see a single
descriptor... - I guess we could do both ?
Anyone have any interesting thoughts ?
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: Geronimo/Spring integration - Moving forward...
Posted by Rob Harrop <ro...@cakesolutions.net>.
Jules Gosnell wrote:
> Dain Sundstrom wrote:
>
>> Excellent work.
>>
>> One big issue here is Geronimo does not require JMX anymore. JMX is
>> an option for the kernel but it is not a dependency or guaranteed to
>> even be available, so a JMX based solution will not work. My guess
>> is we will need to write code similar to the existing spring JMX
>> integration code to produce GBeans.
>>
> OK - so I guess Rob needs to compare dynamically generated MBean and
> GBean metadata and translate JMX descrips built by Spring into gbean
> descrips - or start from scratch :-)
Sounds fun! I'm sure there is some level of similarity and that
we can probably reuse a lot of the Spring code. I can always restructure
the internals of Spring JMX to make it easier for Geronimo to hook and
generate GBeans in place of MBeans.
>
>> On another note, I plan on (I even have some starter code) supporting
>> injecting GBean references into the J2EE enc so J2EE components can
>> obtain proxies to GBeans automatically. So if the Spring objects are
>> registered as GBeans then they would automatically be available to
>> all J2EE components.
>>
> Sounds good - I'll start looking at all this stuff soon,
>
> Jules
>
>> -dain
>>
>> --
>> Dain Sundstrom
>> Chief Architect
>> Gluecode Software
>> 310.536.8355, ext. 26
>>
>> On Jan 28, 2005, at 9:04 AM, Rob Harrop wrote:
>>
>>> I think it might be an idea to create a GBean for the Spring
>>> ApplicationContext but not for each bean. Spring will have the
>>> ability to register with JMX for bean management, plus some Spring
>>> beans have weird lifecycles which are better handled internally.
>>> Spring currently doesn't provide a management layer for the
>>> ApplicationContext which is where I see the GBean coming in. Using
>>> this GBean a custom Geronimo ContextLoader deployed in a web
>>> application should be able to access shared services - or at least
>>> this is my vision.
>>>
>>> Rob
>>>
>>> Jeremy Boynes wrote:
>>>
>>>>
>>>> Jules Gosnell wrote:
>>>>
>>>>>
>>>>> I think that the integration is really one of contained
>>>>> components, not the containers themselves. This means that things
>>>>> in the Spring world need to see things in the J2EE world in Spring
>>>>> terms and vice versa....
>>>>>
>>>>> Lookup in the J2EE world, depending on granularity and indirection
>>>>> is done via JNDI or JMX, lookup is avoided in the Spring world and
>>>>> replaced with injection of POJOs into other POJOs.
>>>>>
>>>>
>>>> Traditionally, Spring has had to interface with the J2EE platform
>>>> provided by the container provider it was running in. I think with
>>>> Geronimo you have the chance to integrate very closely with the
>>>> container services it provides rather than to the generic J2EE world.
>>>>
>>>> For example, our EJB container depends on a TransactionManager in a
>>>> very similar way to Spring. It doesn't get this service by doing a
>>>> JNDI or JMX lookup, it declares a dependency and has it injected by
>>>> the kernel. This seems very similar to Spring's internal model.
>>>>
>>>>>
>>>>> The results of this work should be transparent access to J2EE
>>>>> managed objects from Spring and vice versa. Spring components in
>>>>> one container could talk to those in another Spring container via
>>>>> a lookup through the J2EE layer, JNDI (if the relationship did not
>>>>> need to survive redeployment) or JMX (if it did), or could perhaps
>>>>> optimise this process by looking up each others BeanRegistries,
>>>>> which could be registered in JNDI/JMX anyway....
>>>>>
>>>>
>>>> Why have two BeanRegistries? I would have thought if Spring could
>>>> delegate component registration to the Geronimo kernel there would
>>>> be one unified view and dependency resolution mechanism which would
>>>> greatly simplify things.
>>>>
>>>> It is probably not obvious, but this is what our J2EE deployer does
>>>> - it converts the J2EE view of the world (java:comp/env JNDI refs
>>>> etc) into a set of dependencies managed by the kernel. This gets
>>>> pre-packaged into a Configuration containing just GBeans (plus
>>>> code) - the core runtime doesn't actually know much about J2EE at all.
>>>>
>>>>> etc...
>>>>>
>>>>> There are undoubtedly ClassLoading issues lurking here - more
>>>>> thought needed.
>>>>
>>>>
>>>>
>>>>
>>>> Hopefully that can be sorted out by the Configuration and
>>>> Repository subsystems.
>>>>
>>>>>
>>>>> One last thing that would be very useful would be to somehow
>>>>> intercept Spring-managed calls to POJO-setters, and pass them
>>>>> through the POJO's GBean proxy. This should allow successful
>>>>> recording of configuration deltas, so that Spring-managed POJOs
>>>>> may have their state persisted like other GBeans. Can anyone more
>>>>> famailiar with the Geronimo kernel comment on this.... ?
>>>>>
>>>>
>>>> If you have Spring creating the POJOs as GBeans then that will be
>>>> automatic - you just need Spring to generate the right GBeanInfo
>>>> and GBeanData.
>>>>
>>>> One word of caution though is that GBeans are optimized for
>>>> long-running objects, multi-threaded containers basically rather
>>>> than instances, so if Spring is continually rebuilding graphs of
>>>> instances this will not work very well.
>>>>
>>>> For example, in EJB land, we create a GBean for each EJB container
>>>> but do not create GBeans for individual EJB instances - it is the
>>>> EJB container rather than the kernel that managed the pool/cache of
>>>> those. We do this as the container is long lived and manageable but
>>>> individual instances are much more transient. On the other hand, in
>>>> Servlet land we do create a GBean for each Servlet as servlet
>>>> instances tend to live for the lifetime of the application.
>>>>
>>>> --
>>>> Jeremy
>>>>
>>>>
>
>
Re: Geronimo/Spring integration - Moving forward...
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Dain Sundstrom wrote:
> Excellent work.
>
> One big issue here is Geronimo does not require JMX anymore. JMX is
> an option for the kernel but it is not a dependency or guaranteed to
> even be available, so a JMX based solution will not work. My guess is
> we will need to write code similar to the existing spring JMX
> integration code to produce GBeans.
>
OK - so I guess Rob needs to compare dynamically generated MBean and
GBean metadata and translate JMX descrips built by Spring into gbean
descrips - or start from scratch :-)
> On another note, I plan on (I even have some starter code) supporting
> injecting GBean references into the J2EE enc so J2EE components can
> obtain proxies to GBeans automatically. So if the Spring objects are
> registered as GBeans then they would automatically be available to all
> J2EE components.
>
Sounds good - I'll start looking at all this stuff soon,
Jules
> -dain
>
> --
> Dain Sundstrom
> Chief Architect
> Gluecode Software
> 310.536.8355, ext. 26
>
> On Jan 28, 2005, at 9:04 AM, Rob Harrop wrote:
>
>> I think it might be an idea to create a GBean for the Spring
>> ApplicationContext but not for each bean. Spring will have the
>> ability to register with JMX for bean management, plus some Spring
>> beans have weird lifecycles which are better handled internally.
>> Spring currently doesn't provide a management layer for the
>> ApplicationContext which is where I see the GBean coming in. Using
>> this GBean a custom Geronimo ContextLoader deployed in a web
>> application should be able to access shared services - or at least
>> this is my vision.
>>
>> Rob
>>
>> Jeremy Boynes wrote:
>>
>>>
>>> Jules Gosnell wrote:
>>>
>>>>
>>>> I think that the integration is really one of contained components,
>>>> not the containers themselves. This means that things in the Spring
>>>> world need to see things in the J2EE world in Spring terms and vice
>>>> versa....
>>>>
>>>> Lookup in the J2EE world, depending on granularity and indirection
>>>> is done via JNDI or JMX, lookup is avoided in the Spring world and
>>>> replaced with injection of POJOs into other POJOs.
>>>>
>>>
>>> Traditionally, Spring has had to interface with the J2EE platform
>>> provided by the container provider it was running in. I think with
>>> Geronimo you have the chance to integrate very closely with the
>>> container services it provides rather than to the generic J2EE world.
>>>
>>> For example, our EJB container depends on a TransactionManager in a
>>> very similar way to Spring. It doesn't get this service by doing a
>>> JNDI or JMX lookup, it declares a dependency and has it injected by
>>> the kernel. This seems very similar to Spring's internal model.
>>>
>>>>
>>>> The results of this work should be transparent access to J2EE
>>>> managed objects from Spring and vice versa. Spring components in
>>>> one container could talk to those in another Spring container via a
>>>> lookup through the J2EE layer, JNDI (if the relationship did not
>>>> need to survive redeployment) or JMX (if it did), or could perhaps
>>>> optimise this process by looking up each others BeanRegistries,
>>>> which could be registered in JNDI/JMX anyway....
>>>>
>>>
>>> Why have two BeanRegistries? I would have thought if Spring could
>>> delegate component registration to the Geronimo kernel there would
>>> be one unified view and dependency resolution mechanism which would
>>> greatly simplify things.
>>>
>>> It is probably not obvious, but this is what our J2EE deployer does
>>> - it converts the J2EE view of the world (java:comp/env JNDI refs
>>> etc) into a set of dependencies managed by the kernel. This gets
>>> pre-packaged into a Configuration containing just GBeans (plus code)
>>> - the core runtime doesn't actually know much about J2EE at all.
>>>
>>>> etc...
>>>>
>>>> There are undoubtedly ClassLoading issues lurking here - more
>>>> thought needed.
>>>
>>>
>>>
>>> Hopefully that can be sorted out by the Configuration and Repository
>>> subsystems.
>>>
>>>>
>>>> One last thing that would be very useful would be to somehow
>>>> intercept Spring-managed calls to POJO-setters, and pass them
>>>> through the POJO's GBean proxy. This should allow successful
>>>> recording of configuration deltas, so that Spring-managed POJOs may
>>>> have their state persisted like other GBeans. Can anyone more
>>>> famailiar with the Geronimo kernel comment on this.... ?
>>>>
>>>
>>> If you have Spring creating the POJOs as GBeans then that will be
>>> automatic - you just need Spring to generate the right GBeanInfo and
>>> GBeanData.
>>>
>>> One word of caution though is that GBeans are optimized for
>>> long-running objects, multi-threaded containers basically rather
>>> than instances, so if Spring is continually rebuilding graphs of
>>> instances this will not work very well.
>>>
>>> For example, in EJB land, we create a GBean for each EJB container
>>> but do not create GBeans for individual EJB instances - it is the
>>> EJB container rather than the kernel that managed the pool/cache of
>>> those. We do this as the container is long lived and manageable but
>>> individual instances are much more transient. On the other hand, in
>>> Servlet land we do create a GBean for each Servlet as servlet
>>> instances tend to live for the lifetime of the application.
>>>
>>> --
>>> Jeremy
>>>
>>>
--
"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: Geronimo/Spring integration - Moving forward...
Posted by Dain Sundstrom <ds...@gluecode.com>.
Excellent work.
One big issue here is Geronimo does not require JMX anymore. JMX is an
option for the kernel but it is not a dependency or guaranteed to even
be available, so a JMX based solution will not work. My guess is we
will need to write code similar to the existing spring JMX integration
code to produce GBeans.
On another note, I plan on (I even have some starter code) supporting
injecting GBean references into the J2EE enc so J2EE components can
obtain proxies to GBeans automatically. So if the Spring objects are
registered as GBeans then they would automatically be available to all
J2EE components.
-dain
--
Dain Sundstrom
Chief Architect
Gluecode Software
310.536.8355, ext. 26
On Jan 28, 2005, at 9:04 AM, Rob Harrop wrote:
> I think it might be an idea to create a GBean for the Spring
> ApplicationContext but not for each bean. Spring will have the ability
> to register with JMX for bean management, plus some Spring beans have
> weird lifecycles which are better handled internally. Spring currently
> doesn't provide a management layer for the ApplicationContext which is
> where I see the GBean coming in. Using this GBean a custom Geronimo
> ContextLoader deployed in a web application should be able to access
> shared services - or at least this is my vision.
>
> Rob
>
> Jeremy Boynes wrote:
>
>>
>> Jules Gosnell wrote:
>>
>>>
>>> I think that the integration is really one of contained components,
>>> not the containers themselves. This means that things in the Spring
>>> world need to see things in the J2EE world in Spring terms and vice
>>> versa....
>>>
>>> Lookup in the J2EE world, depending on granularity and indirection
>>> is done via JNDI or JMX, lookup is avoided in the Spring world and
>>> replaced with injection of POJOs into other POJOs.
>>>
>>
>> Traditionally, Spring has had to interface with the J2EE platform
>> provided by the container provider it was running in. I think with
>> Geronimo you have the chance to integrate very closely with the
>> container services it provides rather than to the generic J2EE world.
>>
>> For example, our EJB container depends on a TransactionManager in a
>> very similar way to Spring. It doesn't get this service by doing a
>> JNDI or JMX lookup, it declares a dependency and has it injected by
>> the kernel. This seems very similar to Spring's internal model.
>>
>>>
>>> The results of this work should be transparent access to J2EE
>>> managed objects from Spring and vice versa. Spring components in one
>>> container could talk to those in another Spring container via a
>>> lookup through the J2EE layer, JNDI (if the relationship did not
>>> need to survive redeployment) or JMX (if it did), or could perhaps
>>> optimise this process by looking up each others BeanRegistries,
>>> which could be registered in JNDI/JMX anyway....
>>>
>>
>> Why have two BeanRegistries? I would have thought if Spring could
>> delegate component registration to the Geronimo kernel there would be
>> one unified view and dependency resolution mechanism which would
>> greatly simplify things.
>>
>> It is probably not obvious, but this is what our J2EE deployer does -
>> it converts the J2EE view of the world (java:comp/env JNDI refs etc)
>> into a set of dependencies managed by the kernel. This gets
>> pre-packaged into a Configuration containing just GBeans (plus code)
>> - the core runtime doesn't actually know much about J2EE at all.
>>
>>> etc...
>>>
>>> There are undoubtedly ClassLoading issues lurking here - more
>>> thought needed.
>>
>>
>> Hopefully that can be sorted out by the Configuration and Repository
>> subsystems.
>>
>>>
>>> One last thing that would be very useful would be to somehow
>>> intercept Spring-managed calls to POJO-setters, and pass them
>>> through the POJO's GBean proxy. This should allow successful
>>> recording of configuration deltas, so that Spring-managed POJOs may
>>> have their state persisted like other GBeans. Can anyone more
>>> famailiar with the Geronimo kernel comment on this.... ?
>>>
>>
>> If you have Spring creating the POJOs as GBeans then that will be
>> automatic - you just need Spring to generate the right GBeanInfo and
>> GBeanData.
>>
>> One word of caution though is that GBeans are optimized for
>> long-running objects, multi-threaded containers basically rather than
>> instances, so if Spring is continually rebuilding graphs of instances
>> this will not work very well.
>>
>> For example, in EJB land, we create a GBean for each EJB container
>> but do not create GBeans for individual EJB instances - it is the EJB
>> container rather than the kernel that managed the pool/cache of
>> those. We do this as the container is long lived and manageable but
>> individual instances are much more transient. On the other hand, in
>> Servlet land we do create a GBean for each Servlet as servlet
>> instances tend to live for the lifetime of the application.
>>
>> --
>> Jeremy
>>
>>
Re: Geronimo/Spring integration - Moving forward...
Posted by Rob Harrop <ro...@cakesolutions.net>.
I think it might be an idea to create a GBean for the Spring
ApplicationContext but not for each bean. Spring will have the ability
to register with JMX for bean management, plus some Spring beans have
weird lifecycles which are better handled internally. Spring currently
doesn't provide a management layer for the ApplicationContext which is
where I see the GBean coming in. Using this GBean a custom Geronimo
ContextLoader deployed in a web application should be able to access
shared services - or at least this is my vision.
Rob
Jeremy Boynes wrote:
>
> Jules Gosnell wrote:
>
>>
>> I think that the integration is really one of contained components,
>> not the containers themselves. This means that things in the Spring
>> world need to see things in the J2EE world in Spring terms and vice
>> versa....
>>
>> Lookup in the J2EE world, depending on granularity and indirection is
>> done via JNDI or JMX, lookup is avoided in the Spring world and
>> replaced with injection of POJOs into other POJOs.
>>
>
> Traditionally, Spring has had to interface with the J2EE platform
> provided by the container provider it was running in. I think with
> Geronimo you have the chance to integrate very closely with the
> container services it provides rather than to the generic J2EE world.
>
> For example, our EJB container depends on a TransactionManager in a
> very similar way to Spring. It doesn't get this service by doing a
> JNDI or JMX lookup, it declares a dependency and has it injected by
> the kernel. This seems very similar to Spring's internal model.
>
>>
>> The results of this work should be transparent access to J2EE managed
>> objects from Spring and vice versa. Spring components in one
>> container could talk to those in another Spring container via a
>> lookup through the J2EE layer, JNDI (if the relationship did not need
>> to survive redeployment) or JMX (if it did), or could perhaps
>> optimise this process by looking up each others BeanRegistries, which
>> could be registered in JNDI/JMX anyway....
>>
>
> Why have two BeanRegistries? I would have thought if Spring could
> delegate component registration to the Geronimo kernel there would be
> one unified view and dependency resolution mechanism which would
> greatly simplify things.
>
> It is probably not obvious, but this is what our J2EE deployer does -
> it converts the J2EE view of the world (java:comp/env JNDI refs etc)
> into a set of dependencies managed by the kernel. This gets
> pre-packaged into a Configuration containing just GBeans (plus code) -
> the core runtime doesn't actually know much about J2EE at all.
>
>> etc...
>>
>> There are undoubtedly ClassLoading issues lurking here - more thought
>> needed.
>
>
> Hopefully that can be sorted out by the Configuration and Repository
> subsystems.
>
>>
>> One last thing that would be very useful would be to somehow
>> intercept Spring-managed calls to POJO-setters, and pass them through
>> the POJO's GBean proxy. This should allow successful recording of
>> configuration deltas, so that Spring-managed POJOs may have their
>> state persisted like other GBeans. Can anyone more famailiar with the
>> Geronimo kernel comment on this.... ?
>>
>
> If you have Spring creating the POJOs as GBeans then that will be
> automatic - you just need Spring to generate the right GBeanInfo and
> GBeanData.
>
> One word of caution though is that GBeans are optimized for
> long-running objects, multi-threaded containers basically rather than
> instances, so if Spring is continually rebuilding graphs of instances
> this will not work very well.
>
> For example, in EJB land, we create a GBean for each EJB container but
> do not create GBeans for individual EJB instances - it is the EJB
> container rather than the kernel that managed the pool/cache of those.
> We do this as the container is long lived and manageable but
> individual instances are much more transient. On the other hand, in
> Servlet land we do create a GBean for each Servlet as servlet
> instances tend to live for the lifetime of the application.
>
> --
> Jeremy
>
>
Re: Geronimo/Spring integration - Moving forward...
Posted by Jeremy Boynes <jb...@apache.org>.
Jules Gosnell wrote:
>
> I think that the integration is really one of contained components, not
> the containers themselves. This means that things in the Spring world
> need to see things in the J2EE world in Spring terms and vice versa....
>
> Lookup in the J2EE world, depending on granularity and indirection is
> done via JNDI or JMX, lookup is avoided in the Spring world and replaced
> with injection of POJOs into other POJOs.
>
Traditionally, Spring has had to interface with the J2EE platform
provided by the container provider it was running in. I think with
Geronimo you have the chance to integrate very closely with the
container services it provides rather than to the generic J2EE world.
For example, our EJB container depends on a TransactionManager in a very
similar way to Spring. It doesn't get this service by doing a JNDI or
JMX lookup, it declares a dependency and has it injected by the kernel.
This seems very similar to Spring's internal model.
>
> The results of this work should be transparent access to J2EE managed
> objects from Spring and vice versa. Spring components in one container
> could talk to those in another Spring container via a lookup through the
> J2EE layer, JNDI (if the relationship did not need to survive
> redeployment) or JMX (if it did), or could perhaps optimise this process
> by looking up each others BeanRegistries, which could be registered in
> JNDI/JMX anyway....
>
Why have two BeanRegistries? I would have thought if Spring could
delegate component registration to the Geronimo kernel there would be
one unified view and dependency resolution mechanism which would greatly
simplify things.
It is probably not obvious, but this is what our J2EE deployer does - it
converts the J2EE view of the world (java:comp/env JNDI refs etc) into a
set of dependencies managed by the kernel. This gets pre-packaged into a
Configuration containing just GBeans (plus code) - the core runtime
doesn't actually know much about J2EE at all.
> etc...
>
> There are undoubtedly ClassLoading issues lurking here - more thought
> needed.
Hopefully that can be sorted out by the Configuration and Repository
subsystems.
>
> One last thing that would be very useful would be to somehow intercept
> Spring-managed calls to POJO-setters, and pass them through the POJO's
> GBean proxy. This should allow successful recording of configuration
> deltas, so that Spring-managed POJOs may have their state persisted like
> other GBeans. Can anyone more famailiar with the Geronimo kernel comment
> on this.... ?
>
If you have Spring creating the POJOs as GBeans then that will be
automatic - you just need Spring to generate the right GBeanInfo and
GBeanData.
One word of caution though is that GBeans are optimized for long-running
objects, multi-threaded containers basically rather than instances, so
if Spring is continually rebuilding graphs of instances this will not
work very well.
For example, in EJB land, we create a GBean for each EJB container but
do not create GBeans for individual EJB instances - it is the EJB
container rather than the kernel that managed the pool/cache of those.
We do this as the container is long lived and manageable but individual
instances are much more transient. On the other hand, in Servlet land we
do create a GBean for each Servlet as servlet instances tend to live for
the lifetime of the application.
--
Jeremy
Re: Geronimo/Spring integration - Moving forward...
Posted by Jules Gosnell <ju...@coredevelopers.net>.
So, Rob and I have been talking about exactly what we want out of the
Spring integration...
I've thought a little and decided to share it with the whole list as
well as Rob, so that anyone else with an interest can join in...
I think that the integration is really one of contained components, not
the containers themselves. This means that things in the Spring world
need to see things in the J2EE world in Spring terms and vice versa....
Lookup in the J2EE world, depending on granularity and indirection is
done via JNDI or JMX, lookup is avoided in the Spring world and replaced
with injection of POJOs into other POJOs.
This seems to be leading us towards :
- Spring must be able to resolve JNDI refs and inject the resulting POJO
into Spring apps.
- Spring must be able to resolve JMX ObjectNames and inject a
corresponding POJO (proxy) into Spring apps.
- Spring must export some/all managed POJOs into a JNDI registry
- Spring must register some/all managed POJOs as MBeans (via a proxy)
with JMX Agent
Since we are in the Geronimo world we might reasonably expect some/all
of these MBeans to be GBeans.
Geronimo supports inter-MBean dependendencies.
Spring supports a POJO constuction-time dependency tree.
It makes sense to integrate these as well.
The results of this work should be transparent access to J2EE managed
objects from Spring and vice versa. Spring components in one container
could talk to those in another Spring container via a lookup through the
J2EE layer, JNDI (if the relationship did not need to survive
redeployment) or JMX (if it did), or could perhaps optimise this process
by looking up each others BeanRegistries, which could be registered in
JNDI/JMX anyway....
etc...
There are undoubtedly ClassLoading issues lurking here - more thought
needed.
One last thing that would be very useful would be to somehow intercept
Spring-managed calls to POJO-setters, and pass them through the POJO's
GBean proxy. This should allow successful recording of configuration
deltas, so that Spring-managed POJOs may have their state persisted like
other GBeans. Can anyone more famailiar with the Geronimo kernel comment
on this.... ?
How does that sound ?
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: Geronimo/Spring integration - Deployer checked in...
Posted by David Jencks <dj...@gluecode.com>.
On Jan 28, 2005, at 3:53 AM, Jules Gosnell wrote:
>
<snip>
> Re patching, there is an svn diff (I think), for the moment, just send
> me patches and I'll commit them. If things go well and you need
> further access we can work on persuading the powers that be to let you
> in...
Please create one or more jira issues and attach your patches to
it/them. That way (1) you get to check the code grant box so we can be
more comfortable about the provenance of your patches and (2) there's a
public record of your work we can point to when voting on committer
status.
There's certainly no problem in Jules committing the patches
immediately:-)
I'm glad this spring integration is taking off. I took a quick look at
it a while back and it looked doable and like a very good idea.
thanks
david jencks
>
> Jules
>
> Rob Harrop wrote:
>
>> What is the preferred mechanism for contributing this code? Should
>> Jules check it all in. I'm not that familiar with SVN - can I create
>> a patch like with CVS?
>>
>> Rob
>>
>> Rob Harrop wrote:
>>
>>> Jules,
>>>
>>> This is great stuff - I'm just downloading everything here at work
>>> and I will start to look at the Spring side of things - specifically
>>> satisfying dependencies using the beans that are deployed in
>>> Geronimo.
>>>
>>> Regards,
>>>
>>> Rob
>>>
>>> Jules Gosnell wrote:
>>>
>>>>
>>>> I have just checked in the beginnings of a SpringDeployer (revision
>>>> 128446).
>>>>
>>>> This requires an updated version of Spring (1.1.3). So, if you tend
>>>> to
>>>> run your builds offline, you will need to hook up and let maven sort
>>>> it all out.
>>>>
>>>> A Spring deployable currently looks like this - e.g. :
>>>>
>>>> foo.spr/
>>>> META-INF/spring.xml
>>>> Foo.class
>>>> Bar.class
>>>> ...
>>>>
>>>> Classes should be deployed unpacked at the top level of the jar :
>>>>
>>>> You should run the org/apache/geronimo/SpringDeployer configuration
>>>> in
>>>> your server to use this functionality.
>>>>
>>>> The org/apache/geronimo/DebugConsole will be useful to look at
>>>> GBeans
>>>> that represent your Spring apps.
>>>>
>>>> e.g.
>>>>
>>>> [jules@smilodon cvs]$ java -jar
>>>> geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/
>>>> deployer.jar --user system --password manager deploy foo.spr
>>>> Deployed
>>>> [jules@smilodon cvs]$ java -jar
>>>> geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/
>>>> deployer.jar --user system --password manager undeploy
>>>> /tmp/deployer34206.tmpdir/foo.spr
>>>> Undeployed /tmp/deployer34206.tmpdir/foo.spr
>>>> [jules@smilodon cvs]$
>>>>
>>>> output from server :
>>>>
>>>> 23:39:45,704 INFO [Daemon] Server startup completed
>>>> PLANNING: /tmp/deployer34206.tmpdir/foo.spr
>>>> BUILDING: /tmp/deployer34206.tmpdir/foo.spr
>>>> 23:40:23,556 INFO [XmlBeanDefinitionReader] Loading XML bean
>>>> definitions from class path resource [META-INF/spring.xml]
>>>> 23:40:23,679 INFO [LocalConfigStore:config-store] Installed
>>>> configuration /tmp/deployer34206.tmpdir/foo.spr in location 16
>>>> 23:40:23,730 INFO [ConfigurationManagerImpl] Loaded Configuration
>>>> geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
>>>> 23:40:23,733 INFO [Configuration] Started configuration
>>>> /tmp/deployer34206.tmpdir/foo.spr
>>>> 23:40:38,787 INFO [Container] Started HttpContext[/,/]
>>>> 23:41:36,069 INFO [Configuration] Stopping configuration
>>>> /tmp/deployer34206.tmpdir/foo.spr
>>>> 23:41:36,078 INFO [ConfigurationManagerImpl] Unloaded
>>>> Configuration
>>>> geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
>>>> 23:41:36,083 INFO [LocalConfigStore:config-store] Uninstalled
>>>> configuration /tmp/deployer34206.tmpdir/foo.spr
>>>>
>>>>
>>>> Functionality is rudimentary at the moment.
>>>>
>>>> Only one GBean is created per Spring app.
>>>>
>>>> We hope to add the following functionality soon :
>>>>
>>>> 1. Support for a META-INF/geronimo-spring.xml (internally or
>>>> externally) - this will be used to provide platform specific deploy
>>>> time metadata.
>>>>
>>>> 2. The possibility of exposing individual Spring generated beans as
>>>> GBeans in the Geronimo kernel with all attendant benefits -
>>>> management, monitoring and persistent configuration.
>>>>
>>>> 3. Transparent injection of platform hosted resources into Spring
>>>> apps
>>>> - allowing seemless hookup between Spring composed apps running in
>>>> different containers within Geronimo.
>>>>
>>>> 4. Support for nested jars within the .spr.
>>>>
>>>> 5. Anything else that looks useful - please join this thread with
>>>> your
>>>> ideas.
>>>>
>>>>
>>>> The code is in modules/spring-builder if you want to take a look.
>>>>
>>>> If anyone can figure out how to move the Spring-related stuff out of
>>>> the j2ee-runtime-deployer-plan.xml and back into the
>>>> spring-deployer-plan.xml without losing the deployer they will have
>>>> my
>>>> undying gratitude - I ran out of steam - maybe tomorrow :-)
>>>>
>>>> We will be working closely with the Spring team on this
>>>> integration. We
>>>> hope that both Geronimo and Spring will benefit substantially from
>>>> this.
>>>>
>>>> Enjoy,
>>>>
>>>> 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: Geronimo/Spring integration - Deployer checked in...
Posted by Jules Gosnell <ju...@coredevelopers.net>.
Rob,
You'll need to refresh your view - I have made a few changes, including
quickly hacked up support for one-level of nested packed jars:
foo.spr/
META-INF/spring.xml
foo/Foo.class
bar.jar
bar/Bar.class
...
This is useful as you can just throw any jars that your Spring app uses
into the spr, jar it all up and drop it into Geronimo :-)
Re patching, there is an svn diff (I think), for the moment, just send
me patches and I'll commit them. If things go well and you need further
access we can work on persuading the powers that be to let you in...
Jules
Rob Harrop wrote:
> What is the preferred mechanism for contributing this code? Should
> Jules check it all in. I'm not that familiar with SVN - can I create a
> patch like with CVS?
>
> Rob
>
> Rob Harrop wrote:
>
>> Jules,
>>
>> This is great stuff - I'm just downloading everything here at work
>> and I will start to look at the Spring side of things - specifically
>> satisfying dependencies using the beans that are deployed in Geronimo.
>>
>> Regards,
>>
>> Rob
>>
>> Jules Gosnell wrote:
>>
>>>
>>> I have just checked in the beginnings of a SpringDeployer (revision
>>> 128446).
>>>
>>> This requires an updated version of Spring (1.1.3). So, if you tend to
>>> run your builds offline, you will need to hook up and let maven sort
>>> it all out.
>>>
>>> A Spring deployable currently looks like this - e.g. :
>>>
>>> foo.spr/
>>> META-INF/spring.xml
>>> Foo.class
>>> Bar.class
>>> ...
>>>
>>> Classes should be deployed unpacked at the top level of the jar :
>>>
>>> You should run the org/apache/geronimo/SpringDeployer configuration in
>>> your server to use this functionality.
>>>
>>> The org/apache/geronimo/DebugConsole will be useful to look at GBeans
>>> that represent your Spring apps.
>>>
>>> e.g.
>>>
>>> [jules@smilodon cvs]$ java -jar
>>> geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/deployer.jar
>>> --user system --password manager deploy foo.spr
>>> Deployed
>>> [jules@smilodon cvs]$ java -jar
>>> geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/deployer.jar
>>> --user system --password manager undeploy
>>> /tmp/deployer34206.tmpdir/foo.spr
>>> Undeployed /tmp/deployer34206.tmpdir/foo.spr
>>> [jules@smilodon cvs]$
>>>
>>> output from server :
>>>
>>> 23:39:45,704 INFO [Daemon] Server startup completed
>>> PLANNING: /tmp/deployer34206.tmpdir/foo.spr
>>> BUILDING: /tmp/deployer34206.tmpdir/foo.spr
>>> 23:40:23,556 INFO [XmlBeanDefinitionReader] Loading XML bean
>>> definitions from class path resource [META-INF/spring.xml]
>>> 23:40:23,679 INFO [LocalConfigStore:config-store] Installed
>>> configuration /tmp/deployer34206.tmpdir/foo.spr in location 16
>>> 23:40:23,730 INFO [ConfigurationManagerImpl] Loaded Configuration
>>> geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
>>> 23:40:23,733 INFO [Configuration] Started configuration
>>> /tmp/deployer34206.tmpdir/foo.spr
>>> 23:40:38,787 INFO [Container] Started HttpContext[/,/]
>>> 23:41:36,069 INFO [Configuration] Stopping configuration
>>> /tmp/deployer34206.tmpdir/foo.spr
>>> 23:41:36,078 INFO [ConfigurationManagerImpl] Unloaded Configuration
>>> geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
>>> 23:41:36,083 INFO [LocalConfigStore:config-store] Uninstalled
>>> configuration /tmp/deployer34206.tmpdir/foo.spr
>>>
>>>
>>> Functionality is rudimentary at the moment.
>>>
>>> Only one GBean is created per Spring app.
>>>
>>> We hope to add the following functionality soon :
>>>
>>> 1. Support for a META-INF/geronimo-spring.xml (internally or
>>> externally) - this will be used to provide platform specific deploy
>>> time metadata.
>>>
>>> 2. The possibility of exposing individual Spring generated beans as
>>> GBeans in the Geronimo kernel with all attendant benefits -
>>> management, monitoring and persistent configuration.
>>>
>>> 3. Transparent injection of platform hosted resources into Spring apps
>>> - allowing seemless hookup between Spring composed apps running in
>>> different containers within Geronimo.
>>>
>>> 4. Support for nested jars within the .spr.
>>>
>>> 5. Anything else that looks useful - please join this thread with your
>>> ideas.
>>>
>>>
>>> The code is in modules/spring-builder if you want to take a look.
>>>
>>> If anyone can figure out how to move the Spring-related stuff out of
>>> the j2ee-runtime-deployer-plan.xml and back into the
>>> spring-deployer-plan.xml without losing the deployer they will have my
>>> undying gratitude - I ran out of steam - maybe tomorrow :-)
>>>
>>> We will be working closely with the Spring team on this integration. We
>>> hope that both Geronimo and Spring will benefit substantially from
>>> this.
>>>
>>> Enjoy,
>>>
>>> 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: Geronimo/Spring integration - Deployer checked in...
Posted by Rob Harrop <ro...@cakesolutions.net>.
What is the preferred mechanism for contributing this code? Should Jules
check it all in. I'm not that familiar with SVN - can I create a patch
like with CVS?
Rob
Rob Harrop wrote:
> Jules,
>
> This is great stuff - I'm just downloading everything here at work and
> I will start to look at the Spring side of things - specifically
> satisfying dependencies using the beans that are deployed in Geronimo.
>
> Regards,
>
> Rob
>
> Jules Gosnell wrote:
>
>>
>> I have just checked in the beginnings of a SpringDeployer (revision
>> 128446).
>>
>> This requires an updated version of Spring (1.1.3). So, if you tend to
>> run your builds offline, you will need to hook up and let maven sort
>> it all out.
>>
>> A Spring deployable currently looks like this - e.g. :
>>
>> foo.spr/
>> META-INF/spring.xml
>> Foo.class
>> Bar.class
>> ...
>>
>> Classes should be deployed unpacked at the top level of the jar :
>>
>> You should run the org/apache/geronimo/SpringDeployer configuration in
>> your server to use this functionality.
>>
>> The org/apache/geronimo/DebugConsole will be useful to look at GBeans
>> that represent your Spring apps.
>>
>> e.g.
>>
>> [jules@smilodon cvs]$ java -jar
>> geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/deployer.jar
>> --user system --password manager deploy foo.spr
>> Deployed
>> [jules@smilodon cvs]$ java -jar
>> geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/deployer.jar
>> --user system --password manager undeploy
>> /tmp/deployer34206.tmpdir/foo.spr
>> Undeployed /tmp/deployer34206.tmpdir/foo.spr
>> [jules@smilodon cvs]$
>>
>> output from server :
>>
>> 23:39:45,704 INFO [Daemon] Server startup completed
>> PLANNING: /tmp/deployer34206.tmpdir/foo.spr
>> BUILDING: /tmp/deployer34206.tmpdir/foo.spr
>> 23:40:23,556 INFO [XmlBeanDefinitionReader] Loading XML bean
>> definitions from class path resource [META-INF/spring.xml]
>> 23:40:23,679 INFO [LocalConfigStore:config-store] Installed
>> configuration /tmp/deployer34206.tmpdir/foo.spr in location 16
>> 23:40:23,730 INFO [ConfigurationManagerImpl] Loaded Configuration
>> geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
>> 23:40:23,733 INFO [Configuration] Started configuration
>> /tmp/deployer34206.tmpdir/foo.spr
>> 23:40:38,787 INFO [Container] Started HttpContext[/,/]
>> 23:41:36,069 INFO [Configuration] Stopping configuration
>> /tmp/deployer34206.tmpdir/foo.spr
>> 23:41:36,078 INFO [ConfigurationManagerImpl] Unloaded Configuration
>> geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
>> 23:41:36,083 INFO [LocalConfigStore:config-store] Uninstalled
>> configuration /tmp/deployer34206.tmpdir/foo.spr
>>
>>
>> Functionality is rudimentary at the moment.
>>
>> Only one GBean is created per Spring app.
>>
>> We hope to add the following functionality soon :
>>
>> 1. Support for a META-INF/geronimo-spring.xml (internally or
>> externally) - this will be used to provide platform specific deploy
>> time metadata.
>>
>> 2. The possibility of exposing individual Spring generated beans as
>> GBeans in the Geronimo kernel with all attendant benefits -
>> management, monitoring and persistent configuration.
>>
>> 3. Transparent injection of platform hosted resources into Spring apps
>> - allowing seemless hookup between Spring composed apps running in
>> different containers within Geronimo.
>>
>> 4. Support for nested jars within the .spr.
>>
>> 5. Anything else that looks useful - please join this thread with your
>> ideas.
>>
>>
>> The code is in modules/spring-builder if you want to take a look.
>>
>> If anyone can figure out how to move the Spring-related stuff out of
>> the j2ee-runtime-deployer-plan.xml and back into the
>> spring-deployer-plan.xml without losing the deployer they will have my
>> undying gratitude - I ran out of steam - maybe tomorrow :-)
>>
>> We will be working closely with the Spring team on this integration. We
>> hope that both Geronimo and Spring will benefit substantially from
>> this.
>>
>> Enjoy,
>>
>> Jules
>>
>
>
Re: Geronimo/Spring integration - Deployer checked in...
Posted by Rob Harrop <ro...@cakesolutions.net>.
Jules,
This is great stuff - I'm just downloading everything here at work and I
will start to look at the Spring side of things - specifically
satisfying dependencies using the beans that are deployed in Geronimo.
Regards,
Rob
Jules Gosnell wrote:
>
> I have just checked in the beginnings of a SpringDeployer (revision
> 128446).
>
> This requires an updated version of Spring (1.1.3). So, if you tend to
> run your builds offline, you will need to hook up and let maven sort
> it all out.
>
> A Spring deployable currently looks like this - e.g. :
>
> foo.spr/
> META-INF/spring.xml
> Foo.class
> Bar.class
> ...
>
> Classes should be deployed unpacked at the top level of the jar :
>
> You should run the org/apache/geronimo/SpringDeployer configuration in
> your server to use this functionality.
>
> The org/apache/geronimo/DebugConsole will be useful to look at GBeans
> that represent your Spring apps.
>
> e.g.
>
> [jules@smilodon cvs]$ java -jar
> geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/deployer.jar
> --user system --password manager deploy foo.spr
> Deployed
> [jules@smilodon cvs]$ java -jar
> geronimo/modules/assembly/target/geronimo-1.0-SNAPSHOT/bin/deployer.jar
> --user system --password manager undeploy
> /tmp/deployer34206.tmpdir/foo.spr
> Undeployed /tmp/deployer34206.tmpdir/foo.spr
> [jules@smilodon cvs]$
>
> output from server :
>
> 23:39:45,704 INFO [Daemon] Server startup completed
> PLANNING: /tmp/deployer34206.tmpdir/foo.spr
> BUILDING: /tmp/deployer34206.tmpdir/foo.spr
> 23:40:23,556 INFO [XmlBeanDefinitionReader] Loading XML bean
> definitions from class path resource [META-INF/spring.xml]
> 23:40:23,679 INFO [LocalConfigStore:config-store] Installed
> configuration /tmp/deployer34206.tmpdir/foo.spr in location 16
> 23:40:23,730 INFO [ConfigurationManagerImpl] Loaded Configuration
> geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
> 23:40:23,733 INFO [Configuration] Started configuration
> /tmp/deployer34206.tmpdir/foo.spr
> 23:40:38,787 INFO [Container] Started HttpContext[/,/]
> 23:41:36,069 INFO [Configuration] Stopping configuration
> /tmp/deployer34206.tmpdir/foo.spr
> 23:41:36,078 INFO [ConfigurationManagerImpl] Unloaded Configuration
> geronimo.config:name="/tmp/deployer34206.tmpdir/foo.spr"
> 23:41:36,083 INFO [LocalConfigStore:config-store] Uninstalled
> configuration /tmp/deployer34206.tmpdir/foo.spr
>
>
> Functionality is rudimentary at the moment.
>
> Only one GBean is created per Spring app.
>
> We hope to add the following functionality soon :
>
> 1. Support for a META-INF/geronimo-spring.xml (internally or
> externally) - this will be used to provide platform specific deploy
> time metadata.
>
> 2. The possibility of exposing individual Spring generated beans as
> GBeans in the Geronimo kernel with all attendant benefits -
> management, monitoring and persistent configuration.
>
> 3. Transparent injection of platform hosted resources into Spring apps
> - allowing seemless hookup between Spring composed apps running in
> different containers within Geronimo.
>
> 4. Support for nested jars within the .spr.
>
> 5. Anything else that looks useful - please join this thread with your
> ideas.
>
>
> The code is in modules/spring-builder if you want to take a look.
>
> If anyone can figure out how to move the Spring-related stuff out of
> the j2ee-runtime-deployer-plan.xml and back into the
> spring-deployer-plan.xml without losing the deployer they will have my
> undying gratitude - I ran out of steam - maybe tomorrow :-)
>
> We will be working closely with the Spring team on this integration. We
> hope that both Geronimo and Spring will benefit substantially from
> this.
>
> Enjoy,
>
> Jules
>