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

[Don B. <mr...@tw...>]

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ürgen höller [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="..."> rather than <bean id="...">. 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.  It's a 6 MB
>download b/c of the refactored struts-example app.
>
>--- jürgen_höller_[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="..."/> but rather
>><bean name="..."/>, 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=1470&alloc_id=3638&op=click
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>  
>