Robert,
See comments inline.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On
> Behalf Of Robert Lerner
> Sent: Wednesday, 25 February 2004 11:45 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Spring integration (revisited)
>
> Hoya Compadres!
>
> First of all, thanks everybody for the help.
>
> I've now managed to get our actions "spring enabled" the
> XW-122 way. I guess I should have tried it out earlier but i
> got kind of confused by the patch, thinking this was
> something that applied to xw-beta1 :-/.
>
> Although the ExternalReferenceResolver approach was not the
> way i first had in mind, guess I was thinking it would be
> done the pico way with an action factory that instantiates my
> actions. Imoh the action factory approach has one benefit,
> over the ExtRefResolver, which I feel is that u get one
> central point for managing/configuring your IoC. With the
> ExtRefRes I somewhat feel that u get the IoC both in spring
> and in xwork. On the other hand it's kind of nice to
> configure your actions at one central point (xwork.xml),
> maybe in a large application with many actions it would be
> messy to have your actions IoC:ed in the spring context and
> configured in the xwork context? (What do u think?) I guess
> in the end the ExtRefRes wins but for me it's more of a
> feeling in the gut then something i can motivate really strong.
>
I have tried it both ways, and I didn't like the fact that there was
duplicate configuration, which is why I stick to keeping the business
objects in spring, and the actions configuration in xwork.xml. Then either
using external-ref or a auto wire interceptor, inject the dependencies.
> What exactly is this ww-extras project referred to from a
> little here and there? I would be more then happy to help out
> in any way i can, but I guess I'm a little to new to webwork
> to really be able to do any coding :---]. I was thinking that
> maybe I'll write some kind of tutorial/docs on how to get the
> ExtRefResolver up'n running with spring, would that be of interest?
>
> One last thought. As far as my understanding goes, the
> ExternalReferenceResolver is one component doing the
> resolving for a particular "xwork-package". Would it be
> useful to have some kind of stack for resolvers? Say that one
> action needs some kind of component from spring and an other
> action (in the same package) needs some kind of component
> from jndi. Would it then be useful to have a stack of one
> spring resolver and one jndi resolver? Or is it safe to
> assume that the components needed are always "enabled" from
> either an IoC container xor jndi?
>
I had implemented a patch to support multiple external ref resolvers, but
since nobody needed this feature, it was not accepted.
Read about it here
http://www.mail-archive.com/[EMAIL PROTECTED]/msg06
928.html
Since then, I moved to the auto wire interceptor approach, using spring for
the container.
In the case of using a JNDI resource, get spring to look up the jndi bean
http://www.springframework.org/docs/api/org/springframework/jndi/JndiObjectF
actoryBean.html
Then use the external-ref tag to give it to the action.
This pattern will work for pretty much any external refrence that you will
need... i.e. there probably isn't any need to support multiple IoC
containers within xwork.
Cameron
> Regards
> Rob X - Saviour of the spring
>
> >There are multiple ways to integrate spring into webwork2/xwork
> >
> >It really depends on what you want.
> >
> >The most simple soloution that I have buit for our apps is:
> >
> >1) All of our business logic are implemented in beans that
> are managed by
> >spring. They all implement the com.datacodex.Service interface
> >2) I wrote a XWorkInterceptor to auto wire the webwork2
> actions by type. It
> >is attached.
> >
> >That is it - quite simple - and automatic.
> >
> >Some problems that may arise with this technique are :
> >
> >1) multiple beans in spring of the same type
> > a) you could modify the provided interceptor to autowire
> by type AND by
> >name
> >
> >2) your business objects don't implement a set interface
> > a) you could attach a marker interface to them quite easily, or
> > b) you could autowire by Name only, or
> > c) you could use spring as an action factory (more complex
> integration and
> >confgiuration)
> >
> >I will, when time permits update the webwork2/xwork wiki
> describing this
> >pattern, and these options.
> >
> >I also plan on adding this code into the webwork-optional or
> >webwork-extensions project.
> >
> >One thing that may help with 2c is if webwork/xwork
> supported configuration
> >for factories, rather than hardcoding them in. - Pat / Jason
> .. Any comments
> >here
> >
> >Cameron
> >
> >
> >
> >>-----Original Message-----
> >>From: [EMAIL PROTECTED]
> >>[mailto:[EMAIL PROTECTED] On
> >>Behalf Of Patrick Lightbody
> >>Sent: Tuesday, 24 February 2004 10:07 AM
> >>To: [EMAIL PROTECTED]
> >>Subject: RE: [OS-webwork] Spring integration (revisited)
> >>
> >>We want to get this stuff in to the webwork-extras project
> >>asap so that there is a common place for these types of
> >>integrations. If anyone wants to try their hand at this, just
> >>drop me an email and request developer access to
> >>webwork-extras project to get commit access.
> >>
> >>Patrick
> >>
> >>
> >>
> >>>-----Original Message-----
> >>>From: [EMAIL PROTECTED]
> >>>[mailto:[EMAIL PROTECTED]
> >>>
> >>>
> >>On Behalf Of
> >>
> >>
> >>>Francisco Hernandez
> >>>Sent: Saturday, February 21, 2004 10:09 AM
> >>>To: [EMAIL PROTECTED]
> >>>Subject: Re: [OS-webwork] Spring integration (revisited)
> >>>
> >>>I was able to get this working by following the directions
> >>>
> >>>
> >>on the jira
> >>
> >>
> >>>issue:
> >>>http://jira.opensymphony.com/secure/ViewIssue.jspa?key=XW-122
> >>>
> >>>check out the SpringSupport.zip and look at the tests,
> they are also
> >>>
> >>>
> >>of
> >>
> >>
> >>>help to see how all if this works together.
> >>>
> >>>
> >>>
> >>>Robert Lerner wrote:
> >>>
> >>>
> >>>
> >>>>Hola compadres!
> >>>>
> >>>>[I'm kind of new to both webwork and spring but strongly
> >>>>
> >>>>
> >>feel that
> >>
> >>
> >>>>they are great projects... so please go easy on me if I ask some
> >>>>incredibly stupid questions :-)]
> >>>>
> >>>>I'm working on a project where we are using webwork, and
> >>>>
> >>>>
> >>spring for
> >>
> >>
> >>>>both IoC and AOP (specifically for the transactions).
> >>>>
> >>>>
> >>What I would
> >>
> >>
> >>>>like to do is to have my actions "aware" of the dao that is
> >>>>
> >>>>
> >>configured
> >>
> >>
> >>>>in spring. I've tried to read the previous discussions in the
> >>>>
> >>>>
> >>mailing
> >>
> >>
> >>>>lists on this subject but have not really been able to figure out
> >>>>
> >>>>
> >>how
> >>
> >>
> >>>>to do this. Is it even possible with ww2.0 and xw1.0? If not does
> >>>>someone have any idea of how to get this working?
> >>>>The KW-122 issue in the jira seem to provide a working
> >>>>
> >>>>
> >>solution, but
> >>
> >>
> >>>>how do I integrate this in my application?
> >>>>The xwork-ext stuff, which i assume that this KW-122
> >>>>
> >>>>
> >>stuff has gone
> >>
> >>
> >>>>in to where can i find that?
> >>>>
> >>>>Any help greatly appreciated!
> >>>>/Robert Lerner
> >>>>
> >>>>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Opensymphony-webwork mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
>
-------------------------------------------------------
SF.Net is sponsored by: Speed Start Your Linux Apps Now.
Build and deploy apps & Web services for Linux with
a free DVD software kit from IBM. Click Now!
http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
_______________________________________________
Opensymphony-webwork mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
