Re: [Springframework-developer] Re: Struts Spring Plugin

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

I'm in agreement with Don here.  I'm just looking for the best/easiest=20=

solution to integrate the two.  When I first looked at this plugin, I=20
didn't like the fact that I had to declare my Action twice (once in=20
struts-config.xml and once in applicationContext.xml).  However, the=20
fact that I could use MockStrutsTestCase, as well as set my Managers=20
declaratively on my Actions made me really like it.  I'd like a=20
minimal-intrusion mechanism, but I'm willing to do whatever you feel is=20=

best.  By minimal-intrusion, I mean I'd like to use an existing Action=20=

with very little or no changes - only some tweaking in an XML file.  I=20=

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=20=

> and Spring integration.   To be honest, I don't really have any plans=20=

> for the plugin so feel free to improve it as you see fit.  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 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 starting point is a recent discussion via private email that=20
>> resulted in variations on how to integrate Struts with Spring. As a=20=

>> result, I've got two support classes lying around now, namely=20
>> ActionSupport and DispatchActionSupport, providing easy access to the=20=

>> Spring root application context (and to other goodies like a=20
>> MessageSourceAccessor), similar to the Tiles=20
>> ComponentControllerSupport and JAX-RPC 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 themselves but=20=

>> rather allow for access to a Spring context. The Actions themselves=20=

>> are still set up in the usual way in struts-config.xml.
>> I believe 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 ApplicationContext=20=

>> functionality needs to be used in an Action implementation. As Struts=20=

>> is currently the most important third-party web framework 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 the Struts=20=

>> web tier of JPetStore, so this doesn't introduce any new=20
>> dependencies.
>> That was when I noticed the planned reworking of Don's Spring Struts=20=

>> Plugin on Matt's blog. The original idea of the plugin is different=20=

>> to the "make the Spring context accessible" approach outlined above:=20=

>> I do consider it a valuable alternative, if one wants to actually=20
>> wire the Struts Actions *themselves* as Spring-managed beans. As this=20=

>> just involves two rather simple classes, a context loader PlugIn and=20=

>> a delegating Action proxy, inclusion in Spring can be considered here=20=

>> too, just like with the two Action support classes above. Of course,=20=

>> we all need to agree on this; sorry for me shooting forward=20
>> overeagerly here.
>> Regarding the implementation of the plugin approach, I see the=20
>> potential for a variety of improvements: most importantly, using an=20=

>> XmlWebApplicationContext rather than an XmlBeanFactory for hosting=20
>> the plugin context (similar to Spring's own DispatcherServlet), and=20=

>> automatically wiring it with the Spring root application context (if=20=

>> any). This would allow for defining the Struts Actions in the plugin=20=

>> context, referencing beans in the root web application context from=20=

>> there. IMO, this is important for clear layering: web tier components=20=

>> (Struts Actions) are defined in the plugin context, middle tier=20
>> components remain in the root web application context (same as with=20=

>> Spring's own web MVC). struts-config simply delegates to the Actions=20=

>> in the plugin context.
>> Furthermore, the naming of the Actions in the plugin context can now=20=

>> match the Struts Action names in struts-config in a literal fashion,=20=

>> by using <bean name=3D"..."> rather than <bean id=3D"...">. Such =
alias=20
>> names can contain any special characters like slashes, so names like=20=

>> "/login" or "/module/login" are possible. I believe that keeping=20
>> these names in sync is more intuitive than stripping the leading=20
>> slash off or replacing slashes with underscores. This simply wasn't=20=

>> possible in the early Spring milestones that the original plugin was=20=

>> written for, but I think it's the most viable way now.
>> An important point for thread safety is the passing of the=20
>> ActionServlet to the Spring-wired Action instances. This currently=20
>> happens in the SpringAction proxy, but unfortunately in a=20
>> non-thread-safe manner (if I grasp it correctly). A preferable way is=20=

>> to register a corresponding BeanPostProcessor with the BeanFactory=20
>> that wires the Actions, passing the ActionServlet to Actions at bean=20=

>> initialization time. In general, this works very similar to a Spring=20=

>> FrameworkServlet/DispatcherServlet; it's quite easy to keep these=20
>> classes analogous and consistent.
>> I did a clean-room implementation of this plugin idea yesterday, and=20=

>> it worked out nicely. ContextLoaderPlugIn is the equivalent of=20
>> Spring's FrameworkServlet, loading a ActionServlet-specific context,=20=

>> by default from "<servlet-name>-servlet.xml" (just like with=20
>> DispatcherServlet). DelegatingActionProxy is a small Action=20
>> implementation that delegates to the Spring-wired Action of the same=20=

>> name. These classes correspond to the original SpringPlugIn and=20
>> SpringAction, respectively. Note that ContextLoaderPlugIn supports=20
>> all the configuration options of FrameworkServlet, including=20
>> "contextConfigLocation", and automatically takes the Spring root=20
>> application context as parent (just like FrameworkServlet).
>> In total, I now have the two Action support classes from above=20
>> (ActionSupport, DispatchActionSupport), plus the two classes for the=20=

>> plugin approach (ContextLoaderPlugIn, DelegatingActionProxy). The=20
>> question is: Should we include them in the Spring main distribution,=20=

>> should we update the Struts Spring Plugin project with them, or=20
>> should we scrap them? ;-) As we're talking about 4 small classes here=20=

>> (2 for the plugin approach), I tend to want to include in the Spring=20=

>> distro, as that little code doesn't seem like a good candidate for a=20=

>> separate project. As I understand, Matt seems to agree in that=20
>> respect.
>> Most importantly: Don, what do you think about this? I do by no means=20=

>> intend to pass you over, despite my eagerness in reworking the plugin=20=

>> ;-) Of course, such a plugin shipped with Spring would still accredit=20=

>> the original idea and implementation to you. I just believe that the=20=

>> reworked versions are significantly more powerful and flexible than=20=

>> the originals, leveraging all that Spring can offer for Struts at=20
>> this point of time, similar to Spring's FrameworkServlet. And as this=20=

>> is about so little but very useful code, I feel that including it in=20=

>> Spring itself is a viable option, particularly given that Struts 1.1=20=

>> and the upcoming 1.2 will be around for quite some time to come, and=20=

>> be a dominant web framework choice in combination with a=20
>> Spring-managed middle tier.
>> I understand that Struts 2.0 might be a different matter, providing=20=

>> its own means of Spring integration, but I assume that referencing=20
>> Spring beans should then be possible in the Struts config file itself=20=

>> (similar to XWork's external reference mechanism) rather than with=20
>> the proxy/delegation approach of the current plugin. I consider the=20=

>> current Struts integration classes as solutions for Struts 1.1 and=20
>> 1.2, both the Action support classes and the plugin approach (as two=20=

>> alternative ways). And as there are already enough projects to=20
>> combine for typical users, I suggest to include those classes in the=20=

>> Spring distribution, in up-to-date versions.
>> Of course, I don't want to interfere with other plans of=20
>> Struts/Spring integration. We can also integrate my reworked versions=20=

>> into the Struts Spring Plugin project, or possibly host the code in a=20=

>> separate module within the main Spring project (spring-struts?=20
>> spring-integration?). I'm open for suggestions. What does everybody=20=

>> think? Feedback welcome :-)
>> Regards,
>> Juergen
>>
>> ________________________________
>>
>> Von: spr...@li... 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 might want to=20=

>> know about:
>>
>> How to use the SpringPlugin:
>>
>> 1.  Put nothing to initialize Spring in web.xml.  Use the Plugin to=20=

>> 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=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=20
>> ContextLoaderServlet)
>>    in web.xml and put nothing in struts-config.xml.
>>   Note that only #1 will work if you are using MockStrutsTestCase to=20=

>> test your
>> actions.  IMO, this is quite powerful b/c you can use it to test your=20=

>> Struts
>> Actions w/o a container.
>>
>> I've cc'd the struts-apps mailing list so Don Brown (the original=20
>> 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 refining Don=20=

>>> Brown's
>>> Struts Spring Plugin. That reminded me that I've repeatedly=20
>>> considered
>>> including something like this Plugin in the main Spring =
distribution.
>>> Particularly if it is just two classes, I don't have worries about=20=

>>> size and
>>> scope. A main benefit is that it would be available out-of-the-box=20=

>>> with
>>> Spring, just like all the integrated data access and view=20
>>> technologies.
>>>
>>> Actually, I intend to completely rework the Plugin far beyond its=20
>>> current
>>> implementation. It should properly have its own=20
>>> XmlWebApplicationContext, by
>>> default loaded from "/WEB-INF/<servlet-name>.xml", having the Spring=20=

>>> root
>>> application context (if any) as parent, just like a Spring=20
>>> DispatcherServlet.
>>>
>>> The beans in the Spring context can have the same name as the=20
>>> corresponding
>>> Actions in struts-config.xml. Simply don't use <bean id=3D"..."/> =
but=20
>>> rather
>>> <bean name=3D"..."/>, which allows any special characters like in=20
>>> "/logon.do".
>>> The original Plugin was written against Spring 1.0 M1 where this=20
>>> wasn't
>>> available, IIRC.
>>>
>>> SpringAction's looking up of the corresponding Spring bean and=20
>>> setting the
>>> ActionServlet can be significantly optimized. Actually, I consider=20=

>>> the
>>> current implementation unsafe: It first sets the ActionServlet on=20
>>> 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=20=

>>> the
>>> standard Spring codebase within the next couple of days. We're about=20=

>>> to
>>> release Spring 1.0.1 next week, and I'd be willing to already=20
>>> include this
>>> special Struts support in that release, if the stuff is as simple as=20=

>>> 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=3Dc=
lick
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> =
https://lists.sourceforge.net/lists/listinfo/springframework-developer
>>
>>
>>