Menu
▾
▴
springframework-developer
|
From: <jue...@we...> - 2004-04-06 22:10:16
|
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
|
|
From: Don B. <mr...@tw...> - 2004-04-06 23:37:46
|
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 > > > > |
|
From: Matt R. <ma...@ra...> - 2004-04-07 02:37:27
|
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 >> >> >> |
|
From: Seth L. <se...@eh...> - 2004-04-07 02:48:52
|
Matt Raible wrote: > 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. I integrated Struts + Spring by creating a SpringRequestController and overriding the createAction method to return from the Spring context. This is working really well for us, because no changes to our Actions. We use xdoclet to make the struts-config, so we didn't want to use Don's code. I passed this idea by Don, but he said this way isn't compatible w/ Tiles, and something else possibly. He definitely knows better than I. :) And you're right Matt, you have to declare your Actions twice (though XDoclet handles the struts-config declaration). Seth |
|
From: Lars H. <ho...@ar...> - 2004-04-07 13:22:13
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all, Am 07.04.2004 um 04:48 schrieb Seth Ladd: > Matt Raible wrote: >> 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. > > I integrated Struts + Spring by creating a SpringRequestController and > overriding the createAction method to return from the Spring context. > > This is working really well for us, because no changes to our Actions. > We use xdoclet to make the struts-config, so we didn't want to use > Don's code. > > I passed this idea by Don, but he said this way isn't compatible w/ > Tiles, and something else possibly. He definitely knows better than > I. :) Agreed! I faced the same problem with SAIF. My first implementation ended up with two RequestProcessors: one default and one derived from TilesRequestProcessor. Unfortunately there is now real clean solution due to the bad design of the API. In order to "wrap" any possible other RequestController I ended up with using CGLIB ... Yours, Lars -----BEGIN PGP SIGNATURE----- Version: PGP 8.0.3 iQA/AwUBQHQAzLcyzbDWnRDCEQIrVwCgr0kcdGdnLwiajVvxoLnqhoXdomAAn1LZ EHf/nNV86mQEb7THSSV038p5 =uwss -----END PGP SIGNATURE----- |
