See inline comments
David Blevins schrieb:
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.
I see your point. As others already said, the only correct way to get
the full set of classes to be managed by S2 is to pull them from the
configuration that is built at S2 application start, or more precisely
at the time the StrutsPrepare filter is doing it's init phase. How would
that fit into the OpenEJB lifecycle?
Nevertheless, an ObjectFactory implementation would be responsible for
doing the actual injection based on the collected configuration then.
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.
That would be a great feature IMO.
-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
--
René Gielen
IT-Neering.net
Saarstrasse 100, 52062 Aachen, Germany
Tel: +49-(0)241-4010770
Fax: +49-(0)241-4010771
Cel: +49-(0)177-3194448
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@struts.apache.org
For additional commands, e-mail: dev-h...@struts.apache.org
