On Feb 27, 2009, at 12:11 AM, Rene Gielen wrote:
While ususally DI containers build up a complete configuration of
known beans at application startup, the pluggable DI container
support for Struts2 works different. It is based on the assumption
that each Action, Interceptor and Validator will only need to get
it's dependencies injected, but will never be subject to being
injected to other beans - which makes perfect sense, since they are
endpoints by design.
If you look at how the ObjectFactory mechanism is implemented, you
will see that everything happens at runtime - the bean is created,
and then handled over to the DI container to have it scanned for
injection candidates (usually determined by a name or type strategy)
and wired up based on the configuration the container built at
application startup. The SpringObjectFactory in XWork gives a good
overview on how this is solved.
AFAICS this mechanism is also applicable to EJB- and Common-
Annotations - when ObjectFactory is requested to build a certain
bean, scan it for it's annotation configuration, optionally remember
these results in a cache, and have either the EJB container
component do the wiring if it provides a suitable extension point,
or use a kind of active proxy to interpret he annotations, ask the
container for the needed resources, and wire the bean up finally.
That doesn't work so well for us in the current design. The code we
have now more or less relies on knowing all the ejb, datasource, jms,
env entry, persistence unit, persistence context, web service, and
j2ee connector references up front so we can resolve them all, build
the required infrastructure and objects for the app (entity managers,
datasources, topics/queues, connection factories, orbs, mail sessions,
web service handler chains and endpoints, connector resources), bind
it all to jndi, and finally boot the app or report any errors or
misuse of annotations.
For at least the first iteration, it's going to be way easier to treat
the struts objects the same as servlets or ejbs and scan them at app
startup time.
There are plenty of people who want more dynamic annotation processing
(mostly to expand injection to test cases, plain clients, and misc
java objects not managed by the container). If we had that code, it
would definitely be useful in this situation. Might be something we
can do down the road.
-David
David Blevins schrieb:
On Feb 26, 2009, at 9:27 AM, Karan Malhi wrote:
Thanks Rene. I am trying to avoid a situation where I would have
to scan the
whole classpath on web app startup. Does struts cache the
information about
all action classes somewhere?
We actually do scan the entire webapp classpath for ejbs now. So
it shouldn't be that bad.
Though definitely if we can get that information from struts
directly, even better. I wonder if there's a chicken and egg issue
with that approach though. When exactly does struts do the
searching? Right now we do all our scanning before the webapp
starts up.
-David
On Tue, Feb 24, 2009 at 4:46 PM, Rene Gielen <gie...@it-
neering.net> wrote:
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
--
Karan Singh Malhi
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
