If your intent is to go for a ObjectFactory implementation / extension, I think it would not be necessary to distinct between action or non-action classes - just check the bean to build for the EJB annotations, regardless what kind of bean that is. Actually, in Struts2 not only action classes are candidates for an injection like this - interceptors would also be good candidates, maybe even results.

I would really like to see "first class" EJB3 support in S2, and would also be glad to help where I can

- Rene

Karan Malhi schrieb:
If a class has a suffix of Action or implements the Action interface, would
that automatically be treated as an action class?  Would such a class
require that it be listed in the struts.xml file?


On Sat, Feb 21, 2009 at 11:29 PM, Karan Malhi <karan.ma...@gmail.com> wrote:

Thanks Wes,

Appreciate such a prompt response.

There are likely to be actions mapped via other means. There are many
plugins
available, most prominently the REST plugin and the Convention plugin that
allow our users to map actions without any XML

So a user would need these plugins to map actions without XML. Struts
default behavior would require a user to map the action in the XML file and
that would be struts.xml, right? So would it be fair to say that if I parse
the struts.xml file and all included xml files, then I will have a list of
all available actions in the webapp (assuming user is not using the plugins
you mentioned) ?


3. I was planning to write a plugin, but wanted to have access to the
ServletContext within the plugin. Could you show me how to do that -- I
tried implementing ServletContextAware in the plugin class, but that did
not work for me (maybe that interface is only supposed to be implemented
by
actions)
That interface is meant for actions. The best way to get a ServletContext
is
to do the following from an interceptor -

final ActionContext context = invocation.getInvocationContext();
ServletContext servletContext = (ServletContext)

context.get(org.apache.struts2.StrutsStaticsSERVLET_CONTEXT);

Although I did not manage to get access to  the actual ServletContext, I
believe ActionContext.getContext().getApplication() would give me access to
the Map of context attributes. Since I just need to  read an attribute from
it, I believe this approach should suffice.

You may face a few issues though. I've thought briefly about EJB + Struts2
lately and I'll admit to a lack of experience with EJB, but it seems to me
that it would be somewhat difficult to combine the two easily. Many of the
EJB
annotations can appear on private members (i.e. @PersistenceContext). In
Struts2, we create actions via our own ObjectFactory, which can be
overridden
by a plugin.

On application startup we collect information about all classes which need
injection. Then when instances of classes are created, we use that
information to perform injection. The plugin which I wanted to write would
be an ObjectFactory and I intended to override the buildBean method and
perform the injection there. Actually, I just realized that I could get
access to the Map of ServletContext attributes as shown below:
  public class OpenEJBObjectFactory extends ObjectFactory{
   public Object buildBean(Class clazz, Map map) throws Exception {
        Map application = (Map)map.get("application");
       // THIS IS WHERE I COULD READ THE ATTRIBUTE AND
      // CREATE THE ACTION INSTANCE AND PERFORM INJECTION
   }
}


I'm not particularly familiar with OpenEJB, but I'd like to help however I
can. So, let me know if you need the help.

Excellent. I really appreciate it. You are already helping in a great way
by answering my questions. Thank you so much.

-Wes
--

Wes Wannemacher
Author - Struts 2 In Practice
Includes coverage of Struts 2.1, Spring, JPA, JQuery, Sitemesh and more
http://www.manning.com/wannemacher


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org



--
Karan Singh Malhi





---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org

Reply via email to