Re: [Springframework-developer] Struts Spring Plugin

[<jue...@we...>]

I've just finished the new Struts integration classes, now in the =
org.springframework.web.struts package, including a corresponding test =
suite.
=20
For the "proxy delegates to Spring-managed Action" approach, there are =
ContextLoaderPlugIn and DelegatingActionProxy (corresponding to the =
original SpringPlugIn and SpringAction classes, respectively). The =
former is analogous to FrameworkServlet in its context-loading =
capabilities, loading from "/WEB-INF/<servlet-name>-servlet.xml" by =
default (using the servlet-name of the Struts ActionServlet), supporting =
a "contextConfigLocation" property.
=20
A ContextLoaderPlugIn context will automatically refer to the root =
application context (loaded by ContextLoaderListener/Servlet) as parent, =
if any, just like FrameworkServlet. Action beans defined there receive =
the ActionServlet via a corresponding BeanPostProcessor, also resetting =
the servlet reference to null on destruction.
=20
For the "Action has easy access to a Spring context" approach, there are =
the ActionSupport and DispatchActionSupport classes, providing =
convenient getWebApplicationContext etc methods. Both will first check =
for a ContextLoaderPlugIn context, then fall back to the root web =
application context. The latter should be the typical usage, making =
middle tier beans available to any web component.
=20
Matt, can you please give these classes a try, possibly till early next =
week? They should be as easy to use as the original Spring Struts =
Plugin, but offer more powerful and flexible options. The javadocs =
should hopefully clarify usage and configuration options.
=20
I wonder what to do about the adapted Struts sample app from the Spring =
Struts Plugin distribution: Might it be worthwhile to deprecate the =
original plugin itself but provide a revamped version of the sample app =
within the Struts Apps project, using Spring's new integration classes =
now?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Matt Raible
Gesendet: Mi 07.04.2004 04:37
An: spr...@li...; Don Brown
Betreff: Re: [Springframework-developer] Re: Struts Spring Plugin



I'm in agreement with Don here.  I'm just looking for the best/easiest
solution to integrate the two.  When I first looked at this plugin, I
didn't like the fact that I had to declare my Action twice (once in
struts-config.xml and once in applicationContext.xml).  However, the
fact that I could use MockStrutsTestCase, as well as set my Managers
declaratively on my Actions made me really like it.  I'd like a
minimal-intrusion mechanism, but I'm willing to do whatever you feel is
best.  By minimal-intrusion, I mean I'd like to use an existing Action
with very little or no changes - only some tweaking in an XML file.  I
don't know if that's possible.

Matt


On Apr 6, 2004, at 5:37 PM, Don Brown wrote:

> I like your approach and think it is much stronger solution to Struts
> and Spring integration.   To be honest, I don't really have any plans
> for the plugin so feel free to improve it as you see fit.  I put the
> plugin out there to hopefully spark interest in integrating the two
> projects closer, and I'd glad to see that progressing.  Let me know if
> I can be of help, but please keep me informed as I'm anxious to see
> 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
>> eager in wanting the Struts plugin to get into the Spring main
>> project ASAP (but that's me, can't do anything about it) ;-)
>> My starting point is a recent discussion via private email that
>> resulted in variations on how to integrate Struts with Spring. As a
>> result, I've got two support classes lying around now, namely
>> ActionSupport and DispatchActionSupport, providing easy access to the
>> Spring root application context (and to other goodies like a
>> MessageSourceAccessor), similar to the Tiles
>> ComponentControllerSupport and JAX-RPC ServletEndpointSupport classes
>> that we already ship with Spring. As with the latter, those two
>> Struts Action support classes are not wired by Spring themselves but
>> rather allow for access to a Spring context. The Actions themselves
>> are still set up in the usual way in struts-config.xml.
>> I believe that such Struts Action support classes are a valuable and
>> straightforward addition to similar integration classes that we
>> already ship, particularly if a variety of Spring ApplicationContext
>> functionality needs to be used in an Action implementation. As Struts
>> is currently the most important third-party web framework that Spring
>> needs to integrate with, it's an obvious option to ship those two
>> classes with the Spring distribution. Note that we ship the Struts
>> jars with Spring anyway, for our Tiles integration and for the Struts
>> web tier of JPetStore, so this doesn't introduce any new
>> dependencies.
>> That was when I noticed the planned reworking of Don's Spring Struts
>> Plugin on Matt's blog. The original idea of the plugin is different
>> to the "make the Spring context accessible" approach outlined above:
>> I do consider it a valuable alternative, if one wants to actually
>> wire the Struts Actions *themselves* as Spring-managed beans. As this
>> just involves two rather simple classes, a context loader PlugIn and
>> a delegating Action proxy, inclusion in Spring can be considered here
>> too, just like with the two Action support classes above. Of course,
>> we all need to agree on this; sorry for me shooting 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 context (if
>> any). This would allow for defining the Struts Actions in the plugin
>> context, referencing beans in the root web application context from
>> there. IMO, this is important for clear layering: web tier 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 the Actions
>> in the plugin context.
>> Furthermore, the naming of the Actions in the plugin context can now
>> match the Struts Action names in struts-config in a literal fashion,
>> by using <bean name=3D"..."> rather than <bean id=3D"...">. Such =
alias
>> names can contain any special characters like slashes, so 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 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 preferable way is
>> to register a corresponding BeanPostProcessor with the BeanFactory
>> that wires the Actions, passing the ActionServlet to Actions at bean
>> initialization time. In general, this works very similar 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 yesterday, and
>> it worked out nicely. ContextLoaderPlugIn is the equivalent of
>> Spring's FrameworkServlet, loading a 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 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 classes for the
>> plugin approach (ContextLoaderPlugIn, DelegatingActionProxy). The
>> question is: Should we include them in the Spring main distribution,
>> should we update the Struts Spring Plugin project with them, or
>> should we scrap them? ;-) As we're talking about 4 small classes here
>> (2 for the plugin approach), I tend to want to include in the Spring
>> distro, as that little code doesn't seem like a good 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 by no means
>> intend to pass you over, despite my eagerness in reworking the plugin
>> ;-) Of course, such a plugin shipped with Spring would still accredit
>> the original idea and implementation to you. I just 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. And as this
>> is about so little but very useful code, I feel that including it in
>> Spring itself is a viable option, particularly given that Struts 1.1
>> and the upcoming 1.2 will be around for quite some time to 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 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 approach (as two
>> alternative ways). And as there are already enough projects to
>> combine for typical users, I suggest to include those 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 reworked versions
>> into the Struts Spring Plugin project, or possibly host 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... im Auftrag
>> 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
>> 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 might want to
>> know about:
>>
>> How to use the SpringPlugin:
>>
>> 1.  Put nothing to initialize Spring in web.xml.  Use the Plugin to
>> do this.
>>    - Specifying a "beansConfig" path will load it from a custom path.
>>    - No path will default to "/WEB-INF/applicationContext.xml".
>>    - If your webapp has multiple config files - use #2 below or
>> specify
>>      a "contextConfigLocation" variable as a <context-param> in
>> 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 MockStrutsTestCase to
>> test your
>> actions.  IMO, this is quite powerful b/c you can use it to 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
>> 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 refining Don
>>> Brown's
>>> Struts Spring Plugin. That reminded me that I've repeatedly
>>> considered
>>> including something like this Plugin in the main Spring =
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
>>> current
>>> implementation. It should properly have its own
>>> XmlWebApplicationContext, by
>>> default loaded from "/WEB-INF/<servlet-name>.xml", having 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
>>> corresponding
>>> Actions in struts-config.xml. Simply don't use <bean 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
>>> setting the
>>> ActionServlet can be significantly optimized. Actually, I consider
>>> the
>>> current implementation unsafe: It first sets the ActionServlet on
>>> the located
>>> Action (a shared instance) and then resets it to null again (on each
>>> execution!). This is not at all thread-safe.
>>>
>>> If noone objects, I'll come up with an optimized implementation for
>>> the
>>> standard Spring codebase within the next couple of days. We're 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 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
>> http://promotions.yahoo.com/design_giveaway/
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: IBM Linux Tutorials
>> Free Linux tutorial presented by Daniel Robbins, President and CEO of
>> GenToo technologies. Learn everything from fundamentals to system
>> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>



-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer