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

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

Matt, Don, Rod, all,
=20
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) ;-)
=20
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.
=20
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.
=20
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.
=20
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.
=20
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.
=20
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.
=20
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).
=20
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.
=20
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.
=20
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.
=20
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 :-)
=20
Regards,
Juergen
=20

________________________________

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

+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.
  =20
2.  Put Spring initializers (ContextLoaderListener or =
ContextLoaderServlet)
    in web.xml and put nothing in struts-config.xml.
  =20
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 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