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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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
