geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Quintin Beukes <>
Subject Re: Spring in Geronimo
Date Sat, 12 Sep 2009 10:15:06 GMT
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?


On Sat, Sep 12, 2009 at 12:12 PM, Quintin Beukes <> 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 <> 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 <> 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.
>>> 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:
>>> 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

View raw message