RE: [Springframework-developer] Struts Spring Plugin

[Matt R. <li...@ra...>]

I tried this out this morning...

1.  It works just like the Struts Spring Plugin using the
ContextLoaderPlugIn and DelegatingActionProxy.  All I had to do was
change class and property names and everything worked as before.  This
approach still seems to be necessary to use MockStrutsTestCase with
Spring.=20

2.  I changed my Action to extend DispatchActionSupport and then
retrieved my Manager using
getWebApplicationContext().getBean("userManager").  This worked as well,
but only when running in the servlet container.  This means that
CactusStrutsTestCase will work, but not MockStrutsTestCase.

3.  I tried to migrate the struts-example app to use this new plugin -
and it seems to have worked for the most part.  However, there are some
validator issues that might be related to this.  I'll get with Don to
try and solve these.

HTH,

Matt

> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of j=FCrgen h=F6ller [werk3AT]
> Sent: Friday, April 09, 2004 2:50 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Struts Spring Plugin
>=20
>=20
> I've just finished the new Struts integration classes, now in=20
> the org.springframework.web.struts package, including a=20
> corresponding test suite.
> =20
> For the "proxy delegates to Spring-managed Action" approach,=20
> there are ContextLoaderPlugIn and DelegatingActionProxy=20
> (corresponding to the original SpringPlugIn and SpringAction=20
> classes, respectively). The former is analogous to=20
> FrameworkServlet in its context-loading capabilities, loading=20
> from "/WEB-INF/<servlet-name>-servlet.xml" by default (using=20
> the servlet-name of the Struts ActionServlet), supporting a=20
> "contextConfigLocation" property.
> =20
> A ContextLoaderPlugIn context will automatically refer to the=20
> root application context (loaded by=20
> ContextLoaderListener/Servlet) as parent, if any, just like=20
> FrameworkServlet. Action beans defined there receive the=20
> ActionServlet via a corresponding BeanPostProcessor, also=20
> resetting the servlet reference to null on destruction.
> =20
> For the "Action has easy access to a Spring context"=20
> approach, there are the ActionSupport and=20
> DispatchActionSupport classes, providing convenient=20
> getWebApplicationContext etc methods. Both will first check=20
> for a ContextLoaderPlugIn context, then fall back to the root=20
> web application context. The latter should be the typical=20
> usage, making middle tier beans available to any web component.
> =20
> Matt, can you please give these classes a try, possibly till=20
> early next week? They should be as easy to use as the=20
> original Spring Struts Plugin, but offer more powerful and=20
> flexible options. The javadocs should hopefully clarify usage=20
> and configuration options.
> =20
> I wonder what to do about the adapted Struts sample app from=20
> the Spring Struts Plugin distribution: Might it be worthwhile=20
> to deprecate the original plugin itself but provide a=20
> revamped version of the sample app within the Struts Apps=20
> project, using Spring's new integration classes now?
> =20
> Juergen
> =20
>=20
> ________________________________
>=20
> Von: spr...@li... im=20
> Auftrag von Matt Raible
> Gesendet: Mi 07.04.2004 04:37
> An: spr...@li...; Don Brown
> Betreff: Re: [Springframework-developer] Re: Struts Spring Plugin
>=20
>=20
>=20
> I'm in agreement with Don here.  I'm just looking for the=20
> best/easiest solution to integrate the two.  When I first=20
> looked at this plugin, I didn't like the fact that I had to=20
> declare my Action twice (once in struts-config.xml and once=20
> in applicationContext.xml).  However, the fact that I could=20
> use MockStrutsTestCase, as well as set my Managers=20
> declaratively on my Actions made me really like it.  I'd like=20
> a minimal-intrusion mechanism, but I'm willing to do whatever=20
> you feel is best.  By minimal-intrusion, I mean I'd like to=20
> use an existing Action with very little or no changes - only=20
> some tweaking in an XML file.  I don't know if that's possible.
>=20
> Matt
>=20
>=20
> On Apr 6, 2004, at 5:37 PM, Don Brown wrote:
>=20
> > I like your approach and think it is much stronger solution=20
> to Struts
> > and Spring integration.   To be honest, I don't really have=20
> any plans
> > for the plugin so feel free to improve it as you see fit. =20
> I put the=20
> > plugin out there to hopefully spark interest in integrating the two=20
> > projects closer, and I'd glad to see that progressing.  Let=20
> me know if=20
> > I can be of help, but please keep me informed as I'm anxious to see=20
> > where else Spring might be useful, particularly in Struts itself.
> >
> > Don
> >
> > j=FCrgen h=F6ller [werk3AT] wrote:
> >
> >> Matt, Don, Rod, all,
> >> We need to thoroughly consider this. I guess I've been a bit too=20
> >> eager in wanting the Struts plugin to get into the Spring main=20
> >> project ASAP (but that's me, can't do anything about it) ;-) My=20
> >> starting point is a recent discussion via private email=20
> that resulted=20
> >> in variations on how to integrate Struts with Spring. As a result,=20
> >> I've got two support classes lying around now, namely=20
> ActionSupport=20
> >> and DispatchActionSupport, providing easy access to the=20
> Spring root=20
> >> application context (and to other goodies like a=20
> >> MessageSourceAccessor), similar to the Tiles=20
> >> ComponentControllerSupport and JAX-RPC=20
> ServletEndpointSupport classes=20
> >> that we already ship with Spring. As with the latter, those two=20
> >> Struts Action support classes are not wired by Spring=20
> themselves but=20
> >> rather allow for access to a Spring context. The Actions=20
> themselves=20
> >> are still set up in the usual way in struts-config.xml. I believe=20
> >> that such Struts Action support classes are a valuable and=20
> >> straightforward addition to similar integration classes that we=20
> >> already ship, particularly if a variety of Spring=20
> ApplicationContext=20
> >> functionality needs to be used in an Action=20
> implementation. As Struts=20
> >> is currently the most important third-party web framework=20
> that Spring=20
> >> needs to integrate with, it's an obvious option to ship those two=20
> >> classes with the Spring distribution. Note that we ship the Struts=20
> >> jars with Spring anyway, for our Tiles integration and for=20
> the Struts=20
> >> web tier of JPetStore, so this doesn't introduce any new=20
> >> dependencies. That was when I noticed the planned=20
> reworking of Don's=20
> >> Spring Struts Plugin on Matt's blog. The original idea of=20
> the plugin=20
> >> is different to the "make the Spring context accessible" approach=20
> >> outlined above: I do consider it a valuable alternative,=20
> if one wants=20
> >> to actually wire the Struts Actions *themselves* as Spring-managed=20
> >> beans. As this just involves two rather simple classes, a context=20
> >> loader PlugIn and a delegating Action proxy, inclusion in=20
> Spring can=20
> >> be considered here too, just like with the two Action=20
> support classes=20
> >> above. Of course, we all need to agree on this; sorry for=20
> me shooting=20
> >> forward overeagerly here.
> >> Regarding the implementation of the plugin approach, I see the
> >> potential for a variety of improvements: most importantly, using an
> >> XmlWebApplicationContext rather than an XmlBeanFactory for hosting
> >> the plugin context (similar to Spring's own DispatcherServlet), and
> >> automatically wiring it with the Spring root application=20
> context (if
> >> any). This would allow for defining the Struts Actions in=20
> the plugin
> >> context, referencing beans in the root web application context from
> >> there. IMO, this is important for clear layering: web tier=20
> components
> >> (Struts Actions) are defined in the plugin context, middle tier
> >> components remain in the root web application context (same as with
> >> Spring's own web MVC). struts-config simply delegates to=20
> the Actions
> >> in the plugin context.
> >> Furthermore, the naming of the Actions in the plugin=20
> context can now
> >> match the Struts Action names in struts-config in a=20
> literal fashion,
> >> by using <bean name=3D"..."> rather than <bean id=3D"...">. Such =
alias
> >> names can contain any special characters like slashes, so=20
> names like
> >> "/login" or "/module/login" are possible. I believe that keeping
> >> these names in sync is more intuitive than stripping the leading
> >> slash off or replacing slashes with underscores. This simply wasn't
> >> possible in the early Spring milestones that the original=20
> plugin was
> >> written for, but I think it's the most viable way now.
> >> An important point for thread safety is the passing of the
> >> ActionServlet to the Spring-wired Action instances. This currently
> >> happens in the SpringAction proxy, but unfortunately in a
> >> non-thread-safe manner (if I grasp it correctly). A=20
> preferable way is
> >> to register a corresponding BeanPostProcessor with the BeanFactory
> >> that wires the Actions, passing the ActionServlet to=20
> Actions at bean
> >> initialization time. In general, this works very similar=20
> to a Spring
> >> FrameworkServlet/DispatcherServlet; it's quite easy to keep these
> >> classes analogous and consistent.
> >> I did a clean-room implementation of this plugin idea=20
> yesterday, and
> >> it worked out nicely. ContextLoaderPlugIn is the equivalent of
> >> Spring's FrameworkServlet, loading a=20
> ActionServlet-specific context,
> >> by default from "<servlet-name>-servlet.xml" (just like with
> >> DispatcherServlet). DelegatingActionProxy is a small Action
> >> implementation that delegates to the Spring-wired Action=20
> of the same
> >> name. These classes correspond to the original SpringPlugIn and
> >> SpringAction, respectively. Note that ContextLoaderPlugIn supports
> >> all the configuration options of FrameworkServlet, including
> >> "contextConfigLocation", and automatically takes the Spring root
> >> application context as parent (just like FrameworkServlet).
> >> In total, I now have the two Action support classes from above
> >> (ActionSupport, DispatchActionSupport), plus the two=20
> classes for the
> >> plugin approach (ContextLoaderPlugIn, DelegatingActionProxy). The
> >> question is: Should we include them in the Spring main=20
> distribution,
> >> should we update the Struts Spring Plugin project with them, or
> >> should we scrap them? ;-) As we're talking about 4 small=20
> classes here
> >> (2 for the plugin approach), I tend to want to include in=20
> the Spring
> >> distro, as that little code doesn't seem like a good=20
> candidate for a
> >> separate project. As I understand, Matt seems to agree in that
> >> respect.
> >> Most importantly: Don, what do you think about this? I do=20
> by no means
> >> intend to pass you over, despite my eagerness in reworking=20
> the plugin
> >> ;-) Of course, such a plugin shipped with Spring would=20
> still accredit
> >> the original idea and implementation to you. I just=20
> believe that the
> >> reworked versions are significantly more powerful and flexible than
> >> the originals, leveraging all that Spring can offer for Struts at
> >> this point of time, similar to Spring's FrameworkServlet.=20
> And as this
> >> is about so little but very useful code, I feel that=20
> including it in
> >> Spring itself is a viable option, particularly given that=20
> Struts 1.1
> >> and the upcoming 1.2 will be around for quite some time to=20
> come, and
> >> be a dominant web framework choice in combination with a
> >> Spring-managed middle tier.
> >> I understand that Struts 2.0 might be a different matter, providing
> >> its own means of Spring integration, but I assume that referencing
> >> Spring beans should then be possible in the Struts config=20
> file itself
> >> (similar to XWork's external reference mechanism) rather than with
> >> the proxy/delegation approach of the current plugin. I consider the
> >> current Struts integration classes as solutions for Struts 1.1 and
> >> 1.2, both the Action support classes and the plugin=20
> approach (as two
> >> alternative ways). And as there are already enough projects to
> >> combine for typical users, I suggest to include those=20
> classes in the
> >> Spring distribution, in up-to-date versions.
> >> Of course, I don't want to interfere with other plans of
> >> Struts/Spring integration. We can also integrate my=20
> reworked versions
> >> into the Struts Spring Plugin project, or possibly host=20
> the code in a
> >> separate module within the main Spring project (spring-struts?
> >> spring-integration?). I'm open for suggestions. What does everybody
> >> think? Feedback welcome :-)
> >> Regards,
> >> Juergen
> >>
> >> ________________________________
> >>
> >> Von: spr...@li...=20
> im Auftrag=20
> >> von Matt Raible
> >> Gesendet: Mo 05.04.2004 22:19
> >> An: spr...@li...
> >> Cc: str...@li...
> >> Betreff: [Springframework-developer] Re: Struts Spring Plugin
> >>
> >>
> >>
> >> Juergen,
> >>
> >> That's funny - I was just talking with Don about refactoring some=20
> >> stuff.  Good timing!
> >> +1 for moving it to Spring's repository where it belongs.
> >>
> >> I made a few changes today (just checked them in) you=20
> might want to=20
> >> know about:
> >>
> >> How to use the SpringPlugin:
> >>
> >> 1.  Put nothing to initialize Spring in web.xml.  Use the=20
> Plugin to=20
> >> do this.
> >>    - Specifying a "beansConfig" path will load it from a=20
> custom path.
> >>    - No path will default to "/WEB-INF/applicationContext.xml".
> >>    - If your webapp has multiple config files - use #2 below or=20
> >> specify
> >>      a "contextConfigLocation" variable as a <context-param> in=20
> >> web.xml.
> >>      The values for this parameter should be comma-delimited.
> >>   2.  Put Spring initializers (ContextLoaderListener or
> >> ContextLoaderServlet)
> >>    in web.xml and put nothing in struts-config.xml.
> >>   Note that only #1 will work if you are using=20
> MockStrutsTestCase to=20
> >> test your actions.  IMO, this is quite powerful b/c you=20
> can use it to=20
> >> test your Struts
> >> Actions w/o a container.
> >>
> >> I've cc'd the struts-apps mailing list so Don Brown (the original
> >> author) can
> >> help us make this transition.
> >>
> >> Matt
> >>
> >> P.S.  Since SF's anonymous CVS takes a while to catch up, I've=20
> >> uploaded the latest source to
> >> http://static.raibledesigns.com/downloads/struts-spring-0.3.zip.=20
> >> It's a 6 MB
> >> download b/c of the refactored struts-example app.
> >>
> >> --- j=FCrgen_h=F6ller_[werk3AT] <jue...@we...> =
wrote:
> >>
> >>> Matt,
> >>>
> >>> I've just read that on the Spring Live blog that you're=20
> refining Don=20
> >>> Brown's Struts Spring Plugin. That reminded me that I've=20
> repeatedly
> >>> considered
> >>> including something like this Plugin in the main Spring=20
> distribution.
> >>> Particularly if it is just two classes, I don't have worries about
> >>> size and
> >>> scope. A main benefit is that it would be available out-of-the-box
> >>> with
> >>> Spring, just like all the integrated data access and view
> >>> technologies.
> >>>
> >>> Actually, I intend to completely rework the Plugin far beyond its=20
> >>> current implementation. It should properly have its own
> >>> XmlWebApplicationContext, by
> >>> default loaded from "/WEB-INF/<servlet-name>.xml", having=20
> the Spring
> >>> root
> >>> application context (if any) as parent, just like a Spring
> >>> DispatcherServlet.
> >>>
> >>> The beans in the Spring context can have the same name as the=20
> >>> corresponding Actions in struts-config.xml. Simply don't=20
> use <bean=20
> >>> id=3D"..."/> but rather
> >>> <bean name=3D"..."/>, which allows any special characters like in
> >>> "/logon.do".
> >>> The original Plugin was written against Spring 1.0 M1 where this
> >>> wasn't
> >>> available, IIRC.
> >>>
> >>> SpringAction's looking up of the corresponding Spring bean and=20
> >>> setting the ActionServlet can be significantly optimized.=20
> Actually,=20
> >>> I consider the
> >>> current implementation unsafe: It first sets the ActionServlet on
> >>> the located
> >>> Action (a shared instance) and then resets it to null=20
> again (on each
> >>> execution!). This is not at all thread-safe.
> >>>
> >>> If noone objects, I'll come up with an optimized=20
> implementation for=20
> >>> the standard Spring codebase within the next couple of=20
> days. We're=20
> >>> about to
> >>> release Spring 1.0.1 next week, and I'd be willing to already
> >>> include this
> >>> special Struts support in that release, if the stuff is=20
> as simple as
> >>> I assume
> >>> (or in 1.0.2, if it takes longer).
> >>>
> >>> Juergen
> >>>
> >>>
> >>>
> >>>
> >>
> >> __________________________________
> >> Do you Yahoo!?
> >> Yahoo! Small Business $15K Web Design Giveaway=20
> >> http://promotions.yahoo.com/design_giveaway/
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email is sponsored by: IBM Linux Tutorials
> >> Free Linux tutorial presented by Daniel Robbins, President=20
> and CEO of=20
> >> GenToo technologies. Learn everything from fundamentals to system=20
> >>=20
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> >> _______________________________________________
> >> Springframework-developer mailing list=20
> >> Spr...@li...
> >>=20
> https://lists.sourceforge.net/lists/listinfo/s>
pringframework-develope
> >> r
> >>
> >>
> >>
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President=20
> and CEO of GenToo technologies. Learn everything from=20
> fundamentals to system=20
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President=20
> and CEO of GenToo technologies. Learn everything from=20
> fundamentals to system=20
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20