Spring in Geronimo

[Q Beukes]

Hey,

I had a look at the Spring in OEJB 3.1. Works well. Very nice feature.

My question is how I can get the same running in Geronimo. Since I'm
not initializing OpenEJB myself I figured I would need to get Geronimo
to initialize it somehow, and then update the application context by
dynamically loading spring configurations.

Any ideas on how to do this?

--
Quintin Beukes

[Fredrik Jonson-3]

Quintin Beukes wrote:
 
>  I had a look at the Spring in OEJB 3.1. Works well. Very nice feature.
>  My question is how I can get the same running in Geronimo.

I've used spring for webapps in G. Spring can be configured to lookup javaee
managed resources from jndi environment, and inject those as beans in the
context:

 <jee:jndi-lookup id="myEjb" jndi-name="MyEjbBean" resource-ref="true" />
 <bean id="somePojo" class="org.example.some.SomePojo"">
   <property name="myEjb" value="myEjb"/>
 </bean>

http://static.springsource.org/spring/docs/2.5.x/reference/xsd-config.html

--
Fredrik Jonson

[Quintin Beukes-2]

That is fine, but I'm specifically looking to have the EJBs able to
lookup without first defining it in Spring, and further to be able to
inject spring beans with @Resource. Being the lead developer I develop
the inhouse frameworks/layouts/idioms, so other developers can follow
an easy straightforward path.

To have to initialize all EJBs first I might as well just @EJB them.

Though what you suggested is the good way to do it, and in the mean
time (until I find the complete solution) I'll do it that way. Thanks,
this way I should still be able to AOP the hell out of my project.

Q

On Fri, Sep 11, 2009 at 1:37 PM, Fredrik Jonson <fredrik@...> wrote:

> Quintin Beukes wrote:
>
>>  I had a look at the Spring in OEJB 3.1. Works well. Very nice feature.
>>  My question is how I can get the same running in Geronimo.
>
> I've used spring for webapps in G. Spring can be configured to lookup javaee
> managed resources from jndi environment, and inject those as beans in the
> context:
>
>  <jee:jndi-lookup id="myEjb" jndi-name="MyEjbBean" resource-ref="true" />
>  <bean id="somePojo" class="org.example.some.SomePojo"">
>   <property name="myEjb" value="myEjb"/>
>  </bean>
>
> http://static.springsource.org/spring/docs/2.5.x/reference/xsd-config.html
>
> --
> Fredrik Jonson
>
>

--
Quintin Beukes

[David Blevins]

On Sep 11, 2009, at 3:26 AM, Quintin Beukes wrote:

> I had a look at the Spring in OEJB 3.1. Works well. Very nice feature.
>
> My question is how I can get the same running in Geronimo. Since I'm
> not initializing OpenEJB myself I figured I would need to get Geronimo
> to initialize it somehow, and then update the application context by
> dynamically loading spring configurations.

So far that setup only works when Spring is booting OpenEJB as an  
embedded container in a Java SE application.  It doesn't work with the  
same automagic exporting and importing in Tomcat or Geronimo.

Here's an email with some explanation of the difficulties in a  
bidirectional export/import.

   http://www.nabble.com/Re%3A-Deploying-Spring-Integration-example-p24704223.html

Note that in either Tomcat or Geronimo you should be able to export  
from OpenEJB into your Spring context no problems with the  
"org.apache.openejb.spring.EJB" bean mentioned on this page:  http://openejb.apache.org/3.0/spring.html

Just be aware that Geronimo uses a more complex deploymentId format  
than the one OpenEJB uses by default.  You'd probably want to set them  
to be the same since your spring xml would be referencing them.

Also note that you could install PropertyEditor classes to take care  
of looking up and injecting spring beans into your EJBs.  You'd just  
need to find some way to make your Spring ApplicationContext available  
to the PropertyEditor instance (perhaps a static or thread local).  
That will work in all environments (embedded, Tomcat, Geronimo).

See the custom-injection example for the PropertyEditor example.

We are looking for more functionality in this area, so if you come up  
with anything neat.  Definitely feel encouraged to share.


-David

[Quintin Beukes-2]

I actually have something here.

I was trying a lot the other day to see if I can get more advanced
@Resource injections.

Basically how it works is that you have a class X. So assume you do
this: @Resource(name="springBean") X myObj;
OpenEJB will then look for a property editor associated with making an
X from a String, and then do an env-entries lookup for springBean. It
then takes the value associated with 'springBean' and pass this to the
PropertyEditor, returned the given object. This all works fine, for
specific lookups for which you configured everything.

Though it's not possible to do this and have a general PropertyEditor.
What is I wanted to do a Spring bean lookup through a class like
SpringContext (or whatever), then I have to associated this with every
Class type before an @Resource will work on it.

So I was thinking that in the openejb-jar configuration, how about
being able to define an interceptor "callback", which would allow you
to have a custom callback used to retrieve the object. You could
possible define the interceptor for a specific Class type (even String
or Integer), but then also for type "Object" (which would catch them
all) and finally the more useful - one defined as a "fallback" which
is called when a type isn't found.

So if I had it defined and did the following:
@Resource(name = "MyConfigurationBean") Properties config;

Then openejb will see that I associated a callback against Object, and
thus call my interceptor no matter what. It will also supply the name
argument (and any others), ie. "MyConfigurationBean". My callback will
do a Spring lookup, find a configuration bean and return this. If I
had supplied a name which wasn't found, then the interceptor will
invoke the intercepted function and thus allow OpenEJB to continue as
before.

I know this isn't compatible with the spec, but much of these things
aren't. And if you prefer making a comfortable environment for your
developers over compatibility, then you can continue using such a
feature. Besides, from my own experience it's very difficult to create
a perfectly portable EE application anyway. JavaEE development has a
lot of non-programming in it, and these are most of the time appserver
specific - take for example configuring security realms.

Further. Doing all this, I would be able to wrap my EJBs inside a
spring context, by doing something like the following, where BeanLocal
is an @Local interface for an EJB;
@Resource
private BeanLocal myBean;

So the injection would happen via the interceptor, which would be
supplied with a name=null and a class=BeanLocal.class. It would know
that the name is null and the interface is an @Local, so it would
supply this information to the SpringContext EJB, which in turn would
use the interface's type to lookup a Spring bean with the name
BeanLocal. This would be a spring bean defined as an JNDI lookup.

After returning this to OpenEJB, myBean would be injected with the EJB
looked through Spring, and thus you can use @Resource and Spring to
wire together complex EJB setups. You can for instance have your Local
interface extend the Remote interface. Then for a custom setup
configure your spring XML file to associate BeanLocal instead with a
remote JNDI lookup. All transparent to the application.

You can also then configure Spring's AOP for your beans, since they
are wrapped in the Spring context and thus it's possible to have
Spring strap it with it's own interceptors.

I might have missed something, or misunderstood something, or
suggested things that aren't possible. And there might be a few better
ways to do it, but this is generally what I think would be a very
useful feature. There might also be a better way to do this than using
interceptors for the @Resource injection, though it's the only way I
can think you could achieve such dynamic behaviour without explicitly
defining each type this should be possible for.

Further, since Spring is already inside Geronimo and used in ActiveMQ,
how about creating an ApplicationContext for OpenEJB, and having
Spring startup the OpenEJB instance? Then somehow provide access to
the ApplicationContext? Maybe a JNDI lookup? Maybe an EJB itself?
Maybe make this configurable. Or through a GBean. You can maybe define
a GBean of a certain type and name "SpringContext". Or better yet,
instead of giving direct access to the context, use GBeans to
configure the XML files to load. Something like:
    <gbean name="MySpring"
class="org.apache.geronimo.spring.applicationContext">
      <attribute name="configuration">/META-INF/spring.xml</attribute>
   </gbean>

This would then load the spring XML file into the global application
context and allow you to do all the springy things like you would with
openejb-spring.jar.

Just a few ideas. Spring en EJB complement each other very well, and
to be able to use them together in Geronimo would certainly make
Geronimo even more of a a uniquely powerful EE server. Something it's
already leaning towards with it's plugin architecture. With glassfish
I always had problems distributing our applications on pre-installed
systems. Geronimo makes this so easy with it's platform export, where
you export a custom setup from the console :>

Q

On Sat, Sep 12, 2009 at 1:34 AM, David Blevins <david.blevins@...> wrote:

>
> On Sep 11, 2009, at 3:26 AM, Quintin Beukes wrote:
>
>> I had a look at the Spring in OEJB 3.1. Works well. Very nice feature.
>>
>> My question is how I can get the same running in Geronimo. Since I'm
>> not initializing OpenEJB myself I figured I would need to get Geronimo
>> to initialize it somehow, and then update the application context by
>> dynamically loading spring configurations.
>
> So far that setup only works when Spring is booting OpenEJB as an embedded
> container in a Java SE application.  It doesn't work with the same automagic
> exporting and importing in Tomcat or Geronimo.
>
> Here's an email with some explanation of the difficulties in a bidirectional
> export/import.
>
>  http://www.nabble.com/Re%3A-Deploying-Spring-Integration-example-p24704223.html
>
> Note that in either Tomcat or Geronimo you should be able to export from
> OpenEJB into your Spring context no problems with the
> "org.apache.openejb.spring.EJB" bean mentioned on this page:
>  http://openejb.apache.org/3.0/spring.html
>
> Just be aware that Geronimo uses a more complex deploymentId format than the
> one OpenEJB uses by default.  You'd probably want to set them to be the same
> since your spring xml would be referencing them.
>
> Also note that you could install PropertyEditor classes to take care of
> looking up and injecting spring beans into your EJBs.  You'd just need to
> find some way to make your Spring ApplicationContext available to the
> PropertyEditor instance (perhaps a static or thread local).  That will work
> in all environments (embedded, Tomcat, Geronimo).
>
> See the custom-injection example for the PropertyEditor example.
>
> We are looking for more functionality in this area, so if you come up with
> anything neat.  Definitely feel encouraged to share.
>
>
> -David
>
>

--
Quintin Beukes

[Quintin Beukes-2]

Regarding your message on having OpenEJB load your spring config.

I'm willing to have a look at this. You mentioned you'd be willing to
help out with the details. If you can give me an idea on what to do
I'll be more than willing to implement it. Using them together in
Geronimo/OpenEJB is something valuable. So just let me know what to
do.

Q

On Sat, Sep 12, 2009 at 12:08 PM, Quintin Beukes <quintin@...> wrote:

> I actually have something here.
>
> I was trying a lot the other day to see if I can get more advanced
> @Resource injections.
>
> Basically how it works is that you have a class X. So assume you do
> this: @Resource(name="springBean") X myObj;
> OpenEJB will then look for a property editor associated with making an
> X from a String, and then do an env-entries lookup for springBean. It
> then takes the value associated with 'springBean' and pass this to the
> PropertyEditor, returned the given object. This all works fine, for
> specific lookups for which you configured everything.
>
> Though it's not possible to do this and have a general PropertyEditor.
> What is I wanted to do a Spring bean lookup through a class like
> SpringContext (or whatever), then I have to associated this with every
> Class type before an @Resource will work on it.
>
> So I was thinking that in the openejb-jar configuration, how about
> being able to define an interceptor "callback", which would allow you
> to have a custom callback used to retrieve the object. You could
> possible define the interceptor for a specific Class type (even String
> or Integer), but then also for type "Object" (which would catch them
> all) and finally the more useful - one defined as a "fallback" which
> is called when a type isn't found.
>
> So if I had it defined and did the following:
> @Resource(name = "MyConfigurationBean") Properties config;
>
> Then openejb will see that I associated a callback against Object, and
> thus call my interceptor no matter what. It will also supply the name
> argument (and any others), ie. "MyConfigurationBean". My callback will
> do a Spring lookup, find a configuration bean and return this. If I
> had supplied a name which wasn't found, then the interceptor will
> invoke the intercepted function and thus allow OpenEJB to continue as
> before.
>
> I know this isn't compatible with the spec, but much of these things
> aren't. And if you prefer making a comfortable environment for your
> developers over compatibility, then you can continue using such a
> feature. Besides, from my own experience it's very difficult to create
> a perfectly portable EE application anyway. JavaEE development has a
> lot of non-programming in it, and these are most of the time appserver
> specific - take for example configuring security realms.
>
> Further. Doing all this, I would be able to wrap my EJBs inside a
> spring context, by doing something like the following, where BeanLocal
> is an @Local interface for an EJB;
> @Resource
> private BeanLocal myBean;
>
> So the injection would happen via the interceptor, which would be
> supplied with a name=null and a class=BeanLocal.class. It would know
> that the name is null and the interface is an @Local, so it would
> supply this information to the SpringContext EJB, which in turn would
> use the interface's type to lookup a Spring bean with the name
> BeanLocal. This would be a spring bean defined as an JNDI lookup.
>
> After returning this to OpenEJB, myBean would be injected with the EJB
> looked through Spring, and thus you can use @Resource and Spring to
> wire together complex EJB setups. You can for instance have your Local
> interface extend the Remote interface. Then for a custom setup
> configure your spring XML file to associate BeanLocal instead with a
> remote JNDI lookup. All transparent to the application.
>
> You can also then configure Spring's AOP for your beans, since they
> are wrapped in the Spring context and thus it's possible to have
> Spring strap it with it's own interceptors.
>
> I might have missed something, or misunderstood something, or
> suggested things that aren't possible. And there might be a few better
> ways to do it, but this is generally what I think would be a very
> useful feature. There might also be a better way to do this than using
> interceptors for the @Resource injection, though it's the only way I
> can think you could achieve such dynamic behaviour without explicitly
> defining each type this should be possible for.
>
> Further, since Spring is already inside Geronimo and used in ActiveMQ,
> how about creating an ApplicationContext for OpenEJB, and having
> Spring startup the OpenEJB instance? Then somehow provide access to
> the ApplicationContext? Maybe a JNDI lookup? Maybe an EJB itself?
> Maybe make this configurable. Or through a GBean. You can maybe define
> a GBean of a certain type and name "SpringContext". Or better yet,
> instead of giving direct access to the context, use GBeans to
> configure the XML files to load. Something like:
>    <gbean name="MySpring"
> class="org.apache.geronimo.spring.applicationContext">
>      <attribute name="configuration">/META-INF/spring.xml</attribute>
>   </gbean>
>
> This would then load the spring XML file into the global application
> context and allow you to do all the springy things like you would with
> openejb-spring.jar.
>
> Just a few ideas. Spring en EJB complement each other very well, and
> to be able to use them together in Geronimo would certainly make
> Geronimo even more of a a uniquely powerful EE server. Something it's
> already leaning towards with it's plugin architecture. With glassfish
> I always had problems distributing our applications on pre-installed
> systems. Geronimo makes this so easy with it's platform export, where
> you export a custom setup from the console :>
>
> Q
>
> On Sat, Sep 12, 2009 at 1:34 AM, David Blevins <david.blevins@...> wrote:
>>
>> On Sep 11, 2009, at 3:26 AM, Quintin Beukes wrote:
>>
>>> I had a look at the Spring in OEJB 3.1. Works well. Very nice feature.
>>>
>>> My question is how I can get the same running in Geronimo. Since I'm
>>> not initializing OpenEJB myself I figured I would need to get Geronimo
>>> to initialize it somehow, and then update the application context by
>>> dynamically loading spring configurations.
>>
>> So far that setup only works when Spring is booting OpenEJB as an embedded
>> container in a Java SE application.  It doesn't work with the same automagic
>> exporting and importing in Tomcat or Geronimo.
>>
>> Here's an email with some explanation of the difficulties in a bidirectional
>> export/import.
>>
>>  http://www.nabble.com/Re%3A-Deploying-Spring-Integration-example-p24704223.html
>>
>> Note that in either Tomcat or Geronimo you should be able to export from
>> OpenEJB into your Spring context no problems with the
>> "org.apache.openejb.spring.EJB" bean mentioned on this page:
>>  http://openejb.apache.org/3.0/spring.html
>>
>> Just be aware that Geronimo uses a more complex deploymentId format than the
>> one OpenEJB uses by default.  You'd probably want to set them to be the same
>> since your spring xml would be referencing them.
>>
>> Also note that you could install PropertyEditor classes to take care of
>> looking up and injecting spring beans into your EJBs.  You'd just need to
>> find some way to make your Spring ApplicationContext available to the
>> PropertyEditor instance (perhaps a static or thread local).  That will work
>> in all environments (embedded, Tomcat, Geronimo).
>>
>> See the custom-injection example for the PropertyEditor example.
>>
>> We are looking for more functionality in this area, so if you come up with
>> anything neat.  Definitely feel encouraged to share.
>>
>>
>> -David
>>
>>
>
>
>
> --
> Quintin Beukes
>

--
Quintin Beukes

[Quintin Beukes-2]

I think the idea about having an openejb-spring.xml would work
perfectly. It can still allow you all the freedom.

OpenEJB would load the ApplicationContext, and even though it's a
single fixed spring file, you can have access to the
ApplicationContext by simply make your own Spring bean that loads in
here, and from it's loading load other files.

I think it keeps it simple (unlike the previous ones I mentioned), and
gives the same freedom.

What did you have in mind?

Q

On Sat, Sep 12, 2009 at 12:12 PM, Quintin Beukes <quintin@...> wrote:

> Regarding your message on having OpenEJB load your spring config.
>
> I'm willing to have a look at this. You mentioned you'd be willing to
> help out with the details. If you can give me an idea on what to do
> I'll be more than willing to implement it. Using them together in
> Geronimo/OpenEJB is something valuable. So just let me know what to
> do.
>
> Q
>
> On Sat, Sep 12, 2009 at 12:08 PM, Quintin Beukes <quintin@...> wrote:
>> I actually have something here.
>>
>> I was trying a lot the other day to see if I can get more advanced
>> @Resource injections.
>>
>> Basically how it works is that you have a class X. So assume you do
>> this: @Resource(name="springBean") X myObj;
>> OpenEJB will then look for a property editor associated with making an
>> X from a String, and then do an env-entries lookup for springBean. It
>> then takes the value associated with 'springBean' and pass this to the
>> PropertyEditor, returned the given object. This all works fine, for
>> specific lookups for which you configured everything.
>>
>> Though it's not possible to do this and have a general PropertyEditor.
>> What is I wanted to do a Spring bean lookup through a class like
>> SpringContext (or whatever), then I have to associated this with every
>> Class type before an @Resource will work on it.
>>
>> So I was thinking that in the openejb-jar configuration, how about
>> being able to define an interceptor "callback", which would allow you
>> to have a custom callback used to retrieve the object. You could
>> possible define the interceptor for a specific Class type (even String
>> or Integer), but then also for type "Object" (which would catch them
>> all) and finally the more useful - one defined as a "fallback" which
>> is called when a type isn't found.
>>
>> So if I had it defined and did the following:
>> @Resource(name = "MyConfigurationBean") Properties config;
>>
>> Then openejb will see that I associated a callback against Object, and
>> thus call my interceptor no matter what. It will also supply the name
>> argument (and any others), ie. "MyConfigurationBean". My callback will
>> do a Spring lookup, find a configuration bean and return this. If I
>> had supplied a name which wasn't found, then the interceptor will
>> invoke the intercepted function and thus allow OpenEJB to continue as
>> before.
>>
>> I know this isn't compatible with the spec, but much of these things
>> aren't. And if you prefer making a comfortable environment for your
>> developers over compatibility, then you can continue using such a
>> feature. Besides, from my own experience it's very difficult to create
>> a perfectly portable EE application anyway. JavaEE development has a
>> lot of non-programming in it, and these are most of the time appserver
>> specific - take for example configuring security realms.
>>
>> Further. Doing all this, I would be able to wrap my EJBs inside a
>> spring context, by doing something like the following, where BeanLocal
>> is an @Local interface for an EJB;
>> @Resource
>> private BeanLocal myBean;
>>
>> So the injection would happen via the interceptor, which would be
>> supplied with a name=null and a class=BeanLocal.class. It would know
>> that the name is null and the interface is an @Local, so it would
>> supply this information to the SpringContext EJB, which in turn would
>> use the interface's type to lookup a Spring bean with the name
>> BeanLocal. This would be a spring bean defined as an JNDI lookup.
>>
>> After returning this to OpenEJB, myBean would be injected with the EJB
>> looked through Spring, and thus you can use @Resource and Spring to
>> wire together complex EJB setups. You can for instance have your Local
>> interface extend the Remote interface. Then for a custom setup
>> configure your spring XML file to associate BeanLocal instead with a
>> remote JNDI lookup. All transparent to the application.
>>
>> You can also then configure Spring's AOP for your beans, since they
>> are wrapped in the Spring context and thus it's possible to have
>> Spring strap it with it's own interceptors.
>>
>> I might have missed something, or misunderstood something, or
>> suggested things that aren't possible. And there might be a few better
>> ways to do it, but this is generally what I think would be a very
>> useful feature. There might also be a better way to do this than using
>> interceptors for the @Resource injection, though it's the only way I
>> can think you could achieve such dynamic behaviour without explicitly
>> defining each type this should be possible for.
>>
>> Further, since Spring is already inside Geronimo and used in ActiveMQ,
>> how about creating an ApplicationContext for OpenEJB, and having
>> Spring startup the OpenEJB instance? Then somehow provide access to
>> the ApplicationContext? Maybe a JNDI lookup? Maybe an EJB itself?
>> Maybe make this configurable. Or through a GBean. You can maybe define
>> a GBean of a certain type and name "SpringContext". Or better yet,
>> instead of giving direct access to the context, use GBeans to
>> configure the XML files to load. Something like:
>>    <gbean name="MySpring"
>> class="org.apache.geronimo.spring.applicationContext">
>>      <attribute name="configuration">/META-INF/spring.xml</attribute>
>>   </gbean>
>>
>> This would then load the spring XML file into the global application
>> context and allow you to do all the springy things like you would with
>> openejb-spring.jar.
>>
>> Just a few ideas. Spring en EJB complement each other very well, and
>> to be able to use them together in Geronimo would certainly make
>> Geronimo even more of a a uniquely powerful EE server. Something it's
>> already leaning towards with it's plugin architecture. With glassfish
>> I always had problems distributing our applications on pre-installed
>> systems. Geronimo makes this so easy with it's platform export, where
>> you export a custom setup from the console :>
>>
>> Q
>>
>> On Sat, Sep 12, 2009 at 1:34 AM, David Blevins <david.blevins@...> wrote:
>>>
>>> On Sep 11, 2009, at 3:26 AM, Quintin Beukes wrote:
>>>
>>>> I had a look at the Spring in OEJB 3.1. Works well. Very nice feature.
>>>>
>>>> My question is how I can get the same running in Geronimo. Since I'm
>>>> not initializing OpenEJB myself I figured I would need to get Geronimo
>>>> to initialize it somehow, and then update the application context by
>>>> dynamically loading spring configurations.
>>>
>>> So far that setup only works when Spring is booting OpenEJB as an embedded
>>> container in a Java SE application.  It doesn't work with the same automagic
>>> exporting and importing in Tomcat or Geronimo.
>>>
>>> Here's an email with some explanation of the difficulties in a bidirectional
>>> export/import.
>>>
>>>  http://www.nabble.com/Re%3A-Deploying-Spring-Integration-example-p24704223.html
>>>
>>> Note that in either Tomcat or Geronimo you should be able to export from
>>> OpenEJB into your Spring context no problems with the
>>> "org.apache.openejb.spring.EJB" bean mentioned on this page:
>>>  http://openejb.apache.org/3.0/spring.html
>>>
>>> Just be aware that Geronimo uses a more complex deploymentId format than the
>>> one OpenEJB uses by default.  You'd probably want to set them to be the same
>>> since your spring xml would be referencing them.
>>>
>>> Also note that you could install PropertyEditor classes to take care of
>>> looking up and injecting spring beans into your EJBs.  You'd just need to
>>> find some way to make your Spring ApplicationContext available to the
>>> PropertyEditor instance (perhaps a static or thread local).  That will work
>>> in all environments (embedded, Tomcat, Geronimo).
>>>
>>> See the custom-injection example for the PropertyEditor example.
>>>
>>> We are looking for more functionality in this area, so if you come up with
>>> anything neat.  Definitely feel encouraged to share.
>>>
>>>
>>> -David
>>>
>>>
>>
>>
>>
>> --
>> Quintin Beukes
>>
>
>
>
> --
> Quintin Beukes
>

--
Quintin Beukes