Wow! Thanks for all this great feedback and ideas regards this problem.
I'm sorry I cannot add any useful prompts to help you develop a plugin
Wes as Spring and it's methods for injection are something I know
nothing about. I have to admit, injection is not something I fully
understand and anything I offered as a solution would likely be incorrect.
However, my only real requirement (currently) is to obtain local
references to both stateless and stateful session beans in Glassfish 2.1
from within Struts 2 action classes.
Looking at Haroons' examples, this would seem to be exactly the solution
I'm looking for and I will try and implement this.
Can I just ask two further small questions to Haroon?
Is the EJBInvokerServlet set to initialise at app startup via the
web.xml definition?
Does the EJBInvokerServlet approach work for stateful session bean
references as well as stateless?
Again, thank you for the time and effort everyone has gone through in
providing ideas and solutions to this problem. It is good to know that
this kind of expert help is available via the forum.
Many thanks, Robin
Wes Wannemacher wrote:
On Thu, Jul 30, 2009 at 10:34 AM, Haroon
Rafique<haroon.rafi...@utoronto.ca> wrote:
Hi Wes,
I don't know much of the details about the JEE spec, however, I can share
my implementation with you. The code is not in production yet, so caveat
emptor (it works for us, for now in development).
I use glassfish as my app server. To expose local EJB interfaces within
our entire application, I use an EJBInvokerServlet (uses the @EJB and
@EJBs annotations). The listing is as follows (took out package and import
statements and anonymized):
@EJBs(
value = {
@EJB(beanInterface = Local1.class, name = "ejb/local1"),
@EJB(beanInterface = Local2.class, name = "ejb/local2"),
}
)
/**
* Used to make local interfaces of listed EJBs available within the whole
* web application.
*/
public class EJBInvokerServlet extends HttpServlet {
}
The other way to inject beans is by specifying <ejb-local-ref> inside web.xml.
<ejb-local-ref>
<ejb-ref-name>Local1Bean</ejb-ref-name>
<ejb-ref-type>Session</ejb-ref-type>
<local>Local1</local>
</ejb-local-ref>
I prefer the Servlet approach as its simpler.
Wherever we need the EJBs to be automagically injected (the container does
its part because of EJBInvokerServlet), we then use the @Resource
annotation, e.g., to inject the Local1 interface, I would use:
@Resource(mappedName = "ejb/local1")
private Local1 local1;
Hope that helps.
Haroon, it does and it doesn't. @EJB/@EJBs and @Resource aren't the
only DI annotations that are part of the EE specs. This is the problem
Robin has with the existing integration plugins. My understanding of
what he wants is that he wants to be able to use other annotations
(like @PersistenceContext) on fields in a struts action and have those
fields injected.
To turn it around and consider it compared to another similar
plugin... In the spring plugin, we delegate the class instantiation to
spring, then spring can decide what needs injected, etc. based on
spring configuration. What I'd like to do is apply the same concept to
EE. To do this in spring, there is an implementation of the
ObjectFactory that first tries to instantiate objects using spring,
and when that fails, it falls back on traditional xwork instantiation
(reflection-based). Once the object is created, the spring object
factory then checks to see if it can autowire the instance (based on
plugin configuration).
I'd like to try a similar approach with EE. The hard part is that I
don't know what API, or where to look for an API that instantiates EE
objects. Spring has 'applicationContext.getBean', is there something
similar for EE? Even if it's not as easy as Spring, I'm still willing
to wade through it for a bit since it seems like it would be useful to
at least a few users. The advantage to an object factory based EE
plugin is that I don't need to be aware of the annotations at all, I'd
be delegating that sort of thing to the EE app server's own
mechanisms.
-Wes
------------------------------------------------------------------------
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 8.5.392 / Virus Database: 270.13.37/2273 - Release Date: 07/30/09 18:09:00
