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.blev...@visi.com> 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
