Re: [Springframework-developer] Struts Spring Plugin

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

I'll try to take a look at this on Monday - thanks for doing all the =20
work!

Matt

On Apr 9, 2004, at 2:50 PM, j=FCrgen h=F6ller [werk3AT] wrote:

> I've just finished the new Struts integration classes, now in the =20
> org.springframework.web.struts package, including a corresponding test =
=20
> suite.
>
> For the "proxy delegates to Spring-managed Action" approach, there are =
=20
> ContextLoaderPlugIn and DelegatingActionProxy (corresponding to the =20=

> original SpringPlugIn and SpringAction classes, respectively). The =20
> former is analogous to FrameworkServlet in its context-loading =20
> capabilities, loading from "/WEB-INF/<servlet-name>-servlet.xml" by =20=

> default (using the servlet-name of the Struts ActionServlet), =20
> supporting a "contextConfigLocation" property.
>
> A ContextLoaderPlugIn context will automatically refer to the root =20
> application context (loaded by ContextLoaderListener/Servlet) as =20
> parent, if any, just like FrameworkServlet. Action beans defined there =
=20
> receive the ActionServlet via a corresponding BeanPostProcessor, also =20=

> resetting the servlet reference to null on destruction.
>
> For the "Action has easy access to a Spring context" approach, there =20=

> are the ActionSupport and DispatchActionSupport classes, providing =20
> convenient getWebApplicationContext etc methods. Both will first check =
=20
> for a ContextLoaderPlugIn context, then fall back to the root web =20
> application context. The latter should be the typical usage, making =20=

> middle tier beans available to any web component.
>
> Matt, can you please give these classes a try, possibly till early =20
> next week? They should be as easy to use as the original Spring Struts =
=20
> Plugin, but offer more powerful and flexible options. The javadocs =20
> should hopefully clarify usage and configuration options.
>
> I wonder what to do about the adapted Struts sample app from the =20
> Spring Struts Plugin distribution: Might it be worthwhile to deprecate =
=20
> the original plugin itself but provide a revamped version of the =20
> sample app within the Struts Apps project, using Spring's new =20
> integration classes now?
>
> Juergen
>
>
> ________________________________
>
> Von: spr...@li... im Auftrag =20=

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