So maybe another module like we did with the Spring stuff. Perhaps a
container/openejb-struts/ module.
This doesn't necessarily answer how we would plug it into the
deployment process as we wouldn't want openejb-core to be dependent on
the openejb-struts module, but we could potentially add some sort of
classpath discovered abstraction for hooking it in. Basically
something we use the ResourceFinder.mapAllImplementations(Class)
method to discover things that want to participate in some form of
deployment. These types of abstractions are always wrong on their
first go around, so there's no need for it to bite off more than we
can chew in this first iteration. We can totally keep it very struts
focused with the minimal goal of getting the hook in exactly, and
only, where you need it to accomplish this task. I.e. no need to make
a general hook, in fact better not to initially.
My thoughts anyways.
-David
On Mar 4, 2009, at 6:27 PM, Karan Malhi wrote:
Ignore the Jaxb + reflection comment. I dont think I was thinking
right when
i wrote the email.
Regarding how much code, there would atleast be 4-6 struts classes
involved
for the code which goes inside openejb-core, this is the code which
will
discover classes which are candidates for injection. We would also
need a
separate project to create the struts-plugin which will perform the
actual
injection.
On Wed, Mar 4, 2009 at 8:05 PM, David Blevins
<[email protected]>wrote:
On Mar 4, 2009, at 12:08 PM, Karan Malhi wrote:
I am using struts facilities to discover classes which could be
candidates
for injection. Struts provides me with those classes, but that
means add
struts jar to the classpath of openejb-core if we want to add struts
support. Not sure if we want to do that or not. Please advise.
Should i use reflection instead and load our own Jaxb tree from
struts
dtd?
How much code using struts are we talking about? Reflection is
always an
option for eliminating the compile time and even runtime requirement.
Not sure I understood the jaxb + reflection comment. Seems you
have a way
of going directly at Struts without the need for us to parse the
struts.xml
file. If that's the case, seems we could use that way via
reflection.
At any rate, I'm sure we can figure something out.
-David
On Sat, Feb 21, 2009 at 7:26 PM, David Blevins <[email protected]
wrote:
On Feb 21, 2009, at 3:35 PM, Karan Malhi wrote:
Try to add injection support for struts 2 actions, interceptors and
results.
One of the things I have to do is read struts config files and
discover
action classes. Was trying to use JaxbJavaee from the JEE module
and it
did
not work. I had done something similar with JSF without any
issues.
The difference probably is that struts config files are based
off of
DTD's
instead of Schemas. And thats where I think JaxbJavaee blows up.
I am
thinking of bypassing JaxbJavaee to read descriptors , does
anybody have
any
issues with me using straight JAXB API instead?
That's cool. We essentially have one Jaxb* class for each schema
because
of the namespace filtering we do -- i.e. coercing the xml we're
reading
into
the right namespace.
Secondly, when I generated java classes from JSF schema, I put
them under
the JEE module in package org.apache.openejb.jee , where would i
put the
generated classes for struts (module and package)?
It's fine to put it in the openejb-jee module but it has to be in
another
package or Jaxb will get cranky. Maybe in the package
org.apache.openejb.jee.struts or something.
-David
--
Karan Singh Malhi
--
Karan Singh Malhi
