springframework-developer — Spring Framework developers list

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

[Seth L. <se...@eh...>]

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

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

Re: [Springframework-developer] Where's "Resolve Issue" gone in our JIRA?

[Mike Cannon-B. <mi...@at...>]

Ooops - indexing was turned off - should be on now, I've reindexed the =20=

data (via the Administration section) and all appears to be right with =20=

the world.

Any dramas, let us know.

Cheers,
Mike

--
ATLASSIAN - http://www.atlassian.com/

Confluence - the professional J2EE wiki - tried it yet?
http://www.atlassian.com/confluence/

On 06/04/2004, at 8:37 PM, j=FCrgen h=F6ller [werk3AT] wrote:

> Thanks, Mike - resolving works again now! :-)
>
> Unfortunately, the issue browser still shows outdated associations: =20=

> For example, I associated SPR-77 with fix version 1.0.2 last week, but =
=20
> it's still shown in the 1.1 RC1 list. Funnily enough, the overview =20
> correctly shows one entry for 1.0.2, but when you click at it, you'll =20=

> see an empty list rather than SPR-77.
>
> http://opensource.atlassian.com/projects/spring/browse/SPR-77
> http://opensource.atlassian.com/projects/spring/secure/=20
> BrowseProject.jspa
>
> Thanks for all your efforts, they are much appreciated!
>
> Juergen
>
>
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]On =
Behalf
> Of Mike Cannon-Brookes
> Sent: Tuesday, April 06, 2004 12:17 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Where's "Resolve Issue" gone =20=

> in
> our JIRA?
>
>
> J=FCrgen,
>
> Sorry about this - it seems (after much investigation today) that in
> fixing your instance we also managed to break it with the previous
> investigations. Many apologies, it should be fixed now - the errant
> debug JAR has been removed.
>
> I've resolved SPR-86 (to test) and it worked fine this time. I hope
> that's OK :)
>
> Any more problems, please do let us know.
>
> Cheers,
> Mike
>
> --
> ATLASSIAN - http://www.atlassian.com/
>
> Confluence - the professional J2EE wiki - tried it yet?
> http://www.atlassian.com/confluence/
>
> On 06/04/2004, at 4:43 AM, j=FCrgen h=F6ller [werk3AT] wrote:
>
>> Mike,
>>
>> The problem with resolving issues in our JIRA is still there.
>> Furthermore, I've noticed that after a fix date has been set, the
>> issue is still visible in the "unscheduled list": Funnily enough, the
>> correct number of issues is given in the overview list, but the =
actual
>> list of issues is outdated.
>>
>> As I'd like to resolve all fixed issues for the upcoming Spring
>> release 1.0.1, I'd really appreciate if "resolve issue" would work
>> again :-)
>>
>> Juergen
>>
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag
>> von j=FCrgen h=F6ller [werk3AT]
>> Gesendet: Di 30.03.2004 15:51
>> An: spr...@li...
>> Betreff: Re: [Springframework-developer] Where's "Resolve Issue" gone
>> in our JIRA?
>>
>>
>>
>> I still can't resolve issues (for example SPR-86), getting:
>>
>>   Form Errors:
>>   Action 1 is invalid
>>
>> Juergen
>>
>>
>> -----Original Message-----
>> From: spr...@li...
>> [mailto:spr...@li...]On =20
>> Behalf
>> Of Mike Cannon-Brookes
>> Sent: Tuesday, March 30, 2004 3:06 AM
>> To: spr...@li...
>> Subject: Re: [Springframework-developer] Where's "Resolve Issue" gone
>> in
>> our JIRA?
>>
>>
>> Apologies for this guys - we upgraded all the Open Source JIRA
>> instances as well as moving them to a new, much faster box (you can =20=

>> see
>> the speed increase!). The Spring workflow had some problems, but =
those
>> should all be ironed out now.
>>
>> There are plenty of fun new things to play with in 2.6.1 and 2.6 - =
see
>> here for full details:
>>
>>     =20
>> http://confluence.atlassian.com/display/JIRA/JIRA+2.6+Release+Notes
>>
>> Any further problems, please let me know - you can always contact me
>> via IM at any time, details:
>>
>>     http://confluence.atlassian.com/display/~mi...@at...
>>
>> Cheers,
>> Mike
>>
>> --
>> ATLASSIAN - http://www.atlassian.com/
>>
>> Confluence - the professional J2EE wiki - tried it yet?
>> http://www.atlassian.com/confluence/
>>
>> On 27/03/2004, at 12:03 AM, Dmitriy Kopylenko wrote:
>>
>>> Ahhhhhhhhh Juergen, I noticed something.... I looked at the bottom =
of
>>> the
>>> screen and I saw: "Enterprise Edition, Version: 2.6.1-#65" We've =
been
>>> running 2.5 before. Looks like they've upgraded to the latest =20
>>> version.
>>> Something must have changed.
>>>
>>> Mike, do you know what the problem might be? Also when I tried to
>>> assign any
>>> issue "to me", I got a stack trace screen.
>>>
>>> Regards,
>>> Dmitriy.
>>>
>>> -----Original Message-----
>>> From: spr...@li...
>>> [mailto:spr...@li...] On
>>> Behalf Of
>>> j=FCrgen h=F6ller [werk3AT]
>>> Sent: Friday, March 26, 2004 3:36 AM
>>> To: spr...@li...
>>> Subject: [Springframework-developer] Where's "Resolve Issue" gone in
>>> our
>>> JIRA?
>>>
>>>
>>> For some odd reason, "Resolve Issue"  is not available in our JIRA.
>>> All
>>> administration options are available to me, so I wonder whether this
>>> is a
>>> problem with my account or with JIRA. It did work until Wednesday; =
at
>>> least
>>> I've not noted any problems.
>>>
>>> 2 of the 3 issues I've fixed for 1.0.1 are ready to be closed; I =20
>>> can't
>>> do
>>> this without a "resolve" command...
>>>
>>> Juergen
>>>
>>>
>>> -------------------------------------------------------
>>> 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=3Dclick
>>> _______________________________________________
>>> 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=CCk
>>> _______________________________________________
>>> 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=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
>>
>
>
>
> -------------------------------------------------------
> 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
>

[Springframework-developer] Graphviz Visualization of Bean Defs (was Re: Creating documentation from Spring beans definition files)

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

I merged my version I created this morning with yours - attached is the 
result.

Differences:
 * Use of the Mrecord shape to embed properties inside of bean objects
 * Seperate structure for lists and maps
 * No duplication of beans, ie refs don't get their own structure
 * Referenced beans connect at the property they are referenced

For fun, I applied it to a moderately complex Spring config file for a 
pet project of mine:
http://www.twdata.org/dakine/beans.png

Don

Daniel Potter wrote:

>Here is the stylesheet and an Ant snippet that shows how to generate a graph (as
>postscript and gif) as part of a build.  The XSL is not pretty and would need
>some work for it to handle all possible configuration options allowed by the
>Spring DTD.  It should work as-is for most Spring config files, but it doesn't
>handle nested maps and lists, and doesn't even recognize sets (altho that would
>be trivial to add).  It could be a good starting point for something more
>thorough however.
>
>Also, this XSL includes all property values in the graph (not just bean
>dependencies).  This can clutter the graph up pretty quickly for
>moderate-to-complex configurations.  It would probably be more useful to only
>include bean dependencies in the graph, not all configuration properties
>(basically, <value/> properties).
>
>If anyone makes improvements to the XSL, please post them back to this (or the
>user) list so everyone can benefit.
>
>Enjoy.
>
>Daniel
>  
>

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

Re: [Springframework-developer] Creating documentation from Spring beans definition files (e.g. like HiveMind's HiveDoc)

[Daniel P. <po...@ci...>]

Here is the stylesheet and an Ant snippet that shows how to generate a graph (as
postscript and gif) as part of a build.  The XSL is not pretty and would need
some work for it to handle all possible configuration options allowed by the
Spring DTD.  It should work as-is for most Spring config files, but it doesn't
handle nested maps and lists, and doesn't even recognize sets (altho that would
be trivial to add).  It could be a good starting point for something more
thorough however.

Also, this XSL includes all property values in the graph (not just bean
dependencies).  This can clutter the graph up pretty quickly for
moderate-to-complex configurations.  It would probably be more useful to only
include bean dependencies in the graph, not all configuration properties
(basically, <value/> properties).

If anyone makes improvements to the XSL, please post them back to this (or the
user) list so everyone can benefit.

Enjoy.

Daniel

Quoting Torsten Juergeleit <tju...@ya...>:
> Daniel,
> 
> sounds good. Is it possible to share this stylesheet?
> 
> Thanx.
> Torsten
> 
> --- Daniel Potter <po...@ci...> wrote:
> > I know it's not quite what you had in mind with this
> > question, but we've
> > used Graphviz
> > (www.research.att.com/sw/tools/graphviz/) to
> > generate dependency graphs based on Spring
> > configuration files.  The
> > basic process involves using an XSL stylesheet to
> > transform the Spring
> > XML config files into the .dot syntax used by
> > Graphviz, then running
> > Graphviz on the .dot files to generate png, gif,
> > postscript, etc.
> > dependency graphs.  Of course, this wouldn't work
> > for autowired
> > configurations, but it generates interesting and
> > useful graphs for
> > explicit configurations.
> > 
> > Daniel
> > 
> > On Tue, Apr 06, 2004 at 01:02:39AM -0700, Torsten
> > Juergeleit wrote:
> > > Is anyone already working on a way to create
> > > documentation from Spring beans definition files?
> > > 
> > > Howard's HiveMind / HiveDoc
> > > (http://jakarta.apache.org/hivemind/hivedoc.html)
> > uses
> > > XSL stylesheets to transform the HiveMind config
> > files
> > > into a set of HTML files. Sample output:
> > >
> >
> http://jakarta.apache.org/hivemind/hivedocs/index.html
> > > 
> > > Does it make sense to create something similar for
> > > Spring?
> > > 
> > > Torsten
> > > 
> > > __________________________________
> > > 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
> > 
> > 
> >
> -------------------------------------------------------
> > 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
> 
> 
> __________________________________
> 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
> 




-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

Re: [Springframework-developer] Keep Spring Focused

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

Brandon, all,=20

That's a tough issue: It is far from trivial to decide whether to keep =
third-party integrations within the core framework. We currently focus =
on a quite extensive main project whose packages are strictly decoupled =
despite being in the same source directory. Our current strategy of =
providing both a spring.jar and fine-grained individual jar files has =
received very positive feedback.

A completely different strategy can be seen at Jakarta: Everything's a =
separate project there. Have a look at Commons: 28 individual components =
with separate distributions, plus 20 more in the sandbox. Commons seems =
to become a collection of largely unrelated utilities, some of them with =
hard-to-see cross-dependencies. The quality of concepts and =
implementations varies widely.

I guess that Spring cannot really be compared with Jakarta Commons in =
that respect: Its vision is much more focused, even if covering a broad =
field and numerous third-party integrations. Most importantly, Spring's =
implementation is pretty consistent: We try very hard to apply similar =
patterns and reuse other parts of the framework wherever we can. This is =
much easier within the same project, when the affected class versions =
definitely match.

I guess hardly anyone will argue that *all* third-party integrations =
should be moved outside the Spring core. JTA, JDO, Hibernate, iBATIS SQL =
Maps, JavaMail, JSTL, Velocity, Commons FileUpload, etc are all =
well-placed in the main project, I assume. Tiles and FreeMarker =
integrations are debatable but IMO still candidates for the main =
project: Where to draw the line? Why include Velocity integration in the =
main project but not FreeMarker?

This is also related to the current Struts Spring integration =
discussion. Where do such integration classes naturally fit: in Struts? =
in Spring? in a separate project, like the Struts Spring Plugin? Each =
separate project increases the number of jars to combine for typical =
applications, with matching dependencies... Particularly if the =
integration code is very small, there is a point in *not* making it a =
separate project, IMO.

Juergen=20


-----Original Message-----=20
From: spr...@li...=20
[mailto:spr...@li...]On Behalf=20
Of Brandon Goodin=20
Sent: Tuesday, April 06, 2004 5:18 PM=20
To: spr...@li...=20
Subject: [Springframework-developer] Keep Spring Focused WAS:=20
commons-validator adapter=20


Here is a summary of the previous threads that lead up to this =
discussion.=20
Please read an comment.=20

--- Brandon Goodin Mon 4/6/2004 ---=20

Do what you like. But, these are the same kind of near sighted arguments =

I've heard from the Struts group over the last 2 years. If you provide=20
integrated support for commons validator NOW people will grow to be used =
to=20
it as "the Spring" solution. Then when you introduce the "real" Spring=20
declarative validation you will have competing products within the =
framework=20
creating confusion. If commons validator is NOT going to be the =
"official"=20
Spring declarative validation then keep it OUT of the core distro. I do =
not=20
believe you are keeping focused in doing these type of things. You CAN=20
support things and help to keep them focused WITHOUT making it part of =
the=20
core. Use a little collaboration for goodness sakes.=20

Brandon=20

--- Keith Donald Mon 4/6/2004 ---=20

Spring to me is about making it easier to build real applications =
quicker.=20
Since most applications (mine included) demand syntax and semantic=20
validation of business objects, I would argue a good declarative =
validation=20
framework managed by the Spring team is a good fit.  Personally, I don't =

think commons-validator is that answer for us long term.  I think we can =

offer better and do so in a "cleaner" (more true Spring) fashion, and =
that's=20
the focus of the 1.1 declarative validation efforts.  However, we =
recognize=20
a substantial number of people out there already have an investment in=20
Struts/commons-validator--thus for us to provide a  _thin_ adapter for =
it=20
that facilitates integration with the rest of Spring helps those people. =

And taking responsiblity for managing that piece helps ensure it stays=20
consistent with the rest of the framework in terms of quality (including =

documentation and test coverage.)=20

So my point is when I see that the Spring team has taken responsibility =
for=20
an area and put their name on it, that says something about its quality: =

that is, that it is useful for one (it addresses a need, is documented, =
is=20
tested), and that it will be managed and supported carefully over time.  =
Rod=20
and Juergen are not going to move something out of the sandbox into the =
core=20
and into a release without first making sure it's ready and there is a =
real=20
need for it, for example.=20

We wouldn't want the emergence of a ton of decentralized Spring sub =
projects=20
to produce a sourceforge-like effect over time--that is, a lot of =
projects=20
that are inconsistent in terms of support-level/documentation/activity, =
etc=20
(and personally I prefer Spring as my one-stop-shop, reducing the =
headache=20
generally associated with managing technology integration [even then =
though,=20
it's still modular...]).   Please note this is not to say subprojects =
that=20
leverage Spring are a bad idea!  Heck no, just look at the new Acegi=20
Security Framework, for example!  There just needs to be a separation=20
between _what is_ Spring and what is a _separately managed_ project that =

builds on Spring.=20

I agree we don't need a million validator options, and we should say =
"no" to=20
things that aren't a good fit or don't address a clear, substantial user =

need.  So again the goal here is to allow those already with an =
investment=20
in commons-validator or Struts a way to easily integrate it with Spring. =

The adapter is to be quite thin and optional and there for people =
wanting to=20
use Spring but also needing it.  Long term, I'd like to see everyone =
using=20
our own declarative validation stuff that we're working on now, because =
we=20
feel we can offer something better and with some unique capabilities.  =
But=20
it's not ready yet (and even if it was people can't be expected to =
migrate=20
everything on a dime, right?)=20

Keith=20

--- Brandon Goodin Mon 4/5/2004 ---=20

This is exactly what I mean. Thanks Karl. I hope developers of Spring =
take=20
what Karl is saying to heart. To me this is vitally important in keeping =
the=20
reality and perception of Spring light and focused. I would hate to see=20
Spring suffer from what Struts suffers from... "fascination with =
gadgetry"=20
or BSOS (Bright Shiny Object Syndrome)...distraction from what is =
important.=20

Any developers reading this?=20

Brandon=20

--- Karl Baum Mon 4/5/2004 ---=20

It's great that Spring offers a developer so many options, but after a =
while=20
it may be difficult to separate core Spring from the convenient add ons. =

What must a developer read up on before he or she understands what =
spring is=20
really about?  I would tend to side towards IOC, AOP, and the =
BeanFactory=20
before the commons validator plugin, but this does not mean a commons=20
validator plugin is not a great idea (I for one am trying to integrate =
it=20
into my current project.).  Each plugin that is integrated directly into =
the=20
project is yet another responsibility for the community of Spring =
developers=20
when it comes to documentation and maintenance.  This documentation, =
with=20
all of the add ons and plugins, will eventually become so bloated, the=20
average developer may become overwhelmed by it's size and complexity.=20

Why not farm these plugins out to smaller subprojects with teams of=20
developers focused on delivering a specific add on to the Spring =
project.=20
This leaves everyone with all of the great Spring options, but in the =
end=20
the Spring Framework never loses site of it's purpose  This isn't just =
about=20
the commons validator project.  With each new popular open source =
component,=20
we will need yet another package checked into the Spring project.  We =
can=20
start now with the spring-commons-validator subproject.=20

--- Brandon Goodin Mon 4/5/2004 ---=20

I understand that. I'm simply saying... leave the choices on other =
websites=20
and focus on what spring is. Not on all the neat toys you can plug into =
it.=20
So, where do you draw the line on what does and does not get included. =
Why=20
not setup a directory of tools that can be used in spring instead of =
feeling=20
compelled to include support for every permutation into the distro or in =
the=20
spring cvs. Just cuz you can doesn't mean you should. I think moves like =

this will cause confusion around spring not help it.=20

Brandon=20

--- Seth Ladd Mon 4/5/2004 ---=20

A nice aspect of Spring is that it attempts to give developers different =

choices for a particular task.  For validation, commons-validator is =
just=20
one choice.  Other choices include metadata validator or programmatic=20
validation.  IMHO, the commons-validator fills a nice=20
niche: when you want to do declarative validation but can't mark up the=20
source code (if, for example, you're using generated source or 3rd party =

classes).=20

With Spring, you get to Pick and Choose!=20
Seth.=20




-------------------------------------------------------=20
This SF.Net email is sponsored by: IBM Linux Tutorials=20
Free Linux tutorial presented by Daniel Robbins, President and CEO of=20
GenToo technologies. Learn everything from fundamentals to system=20
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck=20
_______________________________________________=20
Springframework-developer mailing list=20
Spr...@li...=20
https://lists.sourceforge.net/lists/listinfo/springframework-developer=20

Re: [Springframework-developer] RE: commons-validator adapter

[Seth L. <se...@eh...>]

> you. XDoclet has 10million dependencies (ok.. I exaggerate.. 999,999 
> dependencies) and most of them are broken which results in a XDoclet2 
> that does not build out of CVS. VERY VERY aggrevating.
> Can I make a suggestion and vote to take a page from Maven's book?
> Let's create a Spring-Plugin project of these "add-ons" they never have 
> to get mixed with the main code and the main code will NEVER have to 
> break due to breakages in the plugin's dependencies.

That's a great point, and which is why I never build against CVS. 
Here's where maven is nice: it let's you specify a particular version of 
a jar as a dependency and then your project is stuck with that.  You 
become immune to all the new versions of that jar (which can be very 
dangerous).  If you're not using maven, you could just capture any jars 
needed for compilation/runtime and check them into your project's source 
control.  The same effect is achieved: locking into a version of a 
dependency.

So far, the Spring developers have done a great job in not introducing 
any code into the source tree that would jeopardize the integrity of the 
project or the build process.  Many, including myself, view Spring as 
production ready code and not a playground (which is how I view 
xdoclet2, for instance).  I trust the Spring developers to Do The Right 
Thing.

Seth

ps OK, I've got to be quiet now and get some work done. :)

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

RE: [Springframework-developer] Where's "Resolve Issue" gone in our JIRA?

[Stefan K. <ste...@kl...>]

Hi J=FCrgen,

this is not that important, but is the order of the versions in Jira as
desired?  I think it'd be best to sort them by release dates:
  * 1.0.1
  * 1.0.2
  * 1.1RC1
  * 1.2RC1

(Versions can be easily re-scheduled somewhere in the project
adminstration interface.)

-Stefan


PS:  Thanks for that great Framework!  ... and i'm really looking
forward to see the new features and improvements to be implemented in
Spring.  :-)




> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of j=FCrgen h=F6ller [werk3AT]
> Sent: Tuesday, April 06, 2004 12:37 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Where's "Resolve=20
> Issue" gone in our JIRA?
>=20
>=20
> Thanks, Mike - resolving works again now! :-)
>=20
> Unfortunately, the issue browser still shows outdated=20
> associations: For example, I associated SPR-77 with fix=20
> version 1.0.2 last week, but it's still shown in the 1.1 RC1=20
> list. Funnily enough, the overview correctly shows one entry=20
> for 1.0.2, but when you click at it, you'll see an empty list=20
> rather than SPR-77.
>=20
> http://opensource.atlassian.com/projects/spring/browse/SPR-77
> http://opensource.atlassian.com/projects/spring/secure/BrowseP
> roject.jspa
>=20
> Thanks for all your efforts, they are much appreciated!
>=20
> Juergen
>=20
>=20
> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]
> On Behalf
> Of Mike Cannon-Brookes
> Sent: Tuesday, April 06, 2004 12:17 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Where's "Resolve=20
> Issue" gone in
> our JIRA?
>=20
>=20
> J=FCrgen,
>=20
> Sorry about this - it seems (after much investigation today) that in=20
> fixing your instance we also managed to break it with the previous=20
> investigations. Many apologies, it should be fixed now - the errant=20
> debug JAR has been removed.
>=20
> I've resolved SPR-86 (to test) and it worked fine this time. I hope=20
> that's OK :)
>=20
> Any more problems, please do let us know.
>=20
> Cheers,
> Mike
>=20
> --
> ATLASSIAN - http://www.atlassian.com/
>=20
> Confluence - the professional J2EE wiki - tried it yet?
> http://www.atlassian.com/confluence/
>=20
> On 06/04/2004, at 4:43 AM, j=FCrgen h=F6ller [werk3AT] wrote:
>=20
> > Mike,
> >
> > The problem with resolving issues in our JIRA is still there.=20
> > Furthermore, I've noticed that after a fix date has been set, the=20
> > issue is still visible in the "unscheduled list": Funnily=20
> enough, the=20
> > correct number of issues is given in the overview list, but=20
> the actual=20
> > list of issues is outdated.
> >
> > As I'd like to resolve all fixed issues for the upcoming Spring=20
> > release 1.0.1, I'd really appreciate if "resolve issue" would work=20
> > again :-)
> >
> > Juergen
> >
> >
> > ________________________________
> >
> > Von: spr...@li...=20
> im Auftrag=20
> > von j=FCrgen h=F6ller [werk3AT]
> > Gesendet: Di 30.03.2004 15:51
> > An: spr...@li...
> > Betreff: Re: [Springframework-developer] Where's "Resolve=20
> Issue" gone=20
> > in our JIRA?
> >
> >
> >
> > I still can't resolve issues (for example SPR-86), getting:
> >
> >   Form Errors:
> >   Action 1 is invalid
> >
> > Juergen
> >
> >
> > -----Original Message-----
> > From: spr...@li...
> >=20
> [mailto:spr...@li...]
> On Behalf
> > Of Mike Cannon-Brookes
> > Sent: Tuesday, March 30, 2004 3:06 AM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] Where's "Resolve=20
> Issue" gone=20
> > in
> > our JIRA?
> >
> >
> > Apologies for this guys - we upgraded all the Open Source JIRA
> > instances as well as moving them to a new, much faster box=20
> (you can see
> > the speed increase!). The Spring workflow had some=20
> problems, but those
> > should all be ironed out now.
> >
> > There are plenty of fun new things to play with in 2.6.1=20
> and 2.6 - see
> > here for full details:
> >
> >    =20
> http://confluence.atlassian.com/display/JIRA/JIRA+2.6+Release+Notes
> >
> > Any further problems, please let me know - you can always contact me
> > via IM at any time, details:
> >
> >     http://confluence.atlassian.com/display/~mi...@at...
> >
> > Cheers,
> > Mike
> >
> > --
> > ATLASSIAN - http://www.atlassian.com/
> >
> > Confluence - the professional J2EE wiki - tried it yet?
> > http://www.atlassian.com/confluence/
> >
> > On 27/03/2004, at 12:03 AM, Dmitriy Kopylenko wrote:
> >
> >> Ahhhhhhhhh Juergen, I noticed something.... I looked at=20
> the bottom of
> >> the
> >> screen and I saw: "Enterprise Edition, Version: 2.6.1-#65"=20
> We've been
> >> running 2.5 before. Looks like they've upgraded to the=20
> latest version.
> >> Something must have changed.
> >>
> >> Mike, do you know what the problem might be? Also when I tried to
> >> assign any
> >> issue "to me", I got a stack trace screen.
> >>
> >> Regards,
> >> Dmitriy.
> >>
> >> -----Original Message-----
> >> From: spr...@li...
> >> [mailto:spr...@li...] On
> >> Behalf Of
> >> j=FCrgen h=F6ller [werk3AT]
> >> Sent: Friday, March 26, 2004 3:36 AM
> >> To: spr...@li...
> >> Subject: [Springframework-developer] Where's "Resolve=20
> Issue" gone in
> >> our
> >> JIRA?
> >>
> >>
> >> For some odd reason, "Resolve Issue"  is not available in=20
> our JIRA.=20
> >> All
> >> administration options are available to me, so I wonder=20
> whether this
> >> is a
> >> problem with my account or with JIRA. It did work until=20
> Wednesday; at
> >> least
> >> I've not noted any problems.
> >>
> >> 2 of the 3 issues I've fixed for 1.0.1 are ready to be=20
> closed; I can't
> >> do
> >> this without a "resolve" command...
> >>
> >> Juergen
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email is sponsored by: IBM Linux Tutorials
> >> Free Linux tutorial presented by Daniel Robbins, President=20
> and CEO of
> >> GenToo
> >> technologies. Learn everything from fundamentals to system
> >> =
administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dclick
> >> _______________________________________________
> >> Springframework-developer mailing list
> >> Spr...@li...
> >>=20
> 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=20
> 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...
> >>=20
> 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=20
> 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...
> >=20
> 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=20
> 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...
> >=20
> https://lists.sourceforge.net/lists/listinfo/s>
pringframework-developer
> >
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President=20
> 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...
> >=20
> https://lists.sourceforge.net/lists/listinfo/s>
pringframework-developer
> >
>=20
>=20
>=20
> -------------------------------------------------------
> 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
>=20
>=20
> -------------------------------------------------------
> 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
>=20

Re: [Springframework-developer] RE: commons-validator adapter

[Tim C. <tc...@ta...>]

I know that I'm new to the Spring world but just to make another note on 
this subject.
Anyone that is on the Struts dev list can tell you that the latest 
release of Commons Validator has been a huge sticking point in the 
release of a new Struts version. I don't want to see the same thing 
happen to Spring as to XDoclet neither as though on THAT list can tell 
you. XDoclet has 10million dependencies (ok.. I exaggerate.. 999,999 
dependencies) and most of them are broken which results in a XDoclet2 
that does not build out of CVS. VERY VERY aggrevating.
Can I make a suggestion and vote to take a page from Maven's book?
Let's create a Spring-Plugin project of these "add-ons" they never have 
to get mixed with the main code and the main code will NEVER have to 
break due to breakages in the plugin's dependencies.
Even with this course the developers should still be careful what goes 
into the core of course. XDoclet 2 came up with that same architecture 
but unfortunately it's own core was tied too closely with other 
*currently* broken packages.
-Tim

Rod Johnson wrote:

>Guys
>
>We are aware of the dangers here. We do not want Spring to become bloated,
>and it won't.
>
>So far we have the following strategies:
>
>- ** Keep the core separate from the add-ons ** E.g. the IoC container
>doesn't
>even depend on AOP, let alone Commons Validator/whatever. This means that
>it's possibly to use say the BeanFactory or JDBC without extensive
>dependencies: indeed, the whole of Spring (except integration) without
>extensive dependencies.
>- Keep the focus of the core developers on the core.
>- Set the bar high in terms of the quality of what we accept. This is one
>argument for keeping commonly-used add-ins in the Spring project.
>Let's suppose we don't address integration with a popular product such as
>Quartz. Several Spring/Quartz libraries then emerge, all but one of them
>bad. Now users are confused and it reflects poorly on Spring.
>- Ensure that the correct message gets out. Marketing is important. We must
>ensure that people know that the core doesn't depend on the extensions.
>
>However, I think this thread does show that we need to be careful in
>accepting too many add-ons into the core. Perhaps we could have an add-ons
>project for the second tier of integration: e.g. Hibernate is obviously
>core, Commons Validator could be shipped along with a Spring addons
>distribution, but which is still under the Spring Framework umbrella. Such
>integrations likely to be used commonly are definitely in a separate
>category from integration with highly specialized products, that are
>unlikely to see wide use. And we can always promote code into Spring proper.
>
>Perhaps all integrations could start off in the add-ons project, and only be
>promoted if there's user demand.
>
>Regarding documentation, good point, we should separate out the core from
>the add ons. Maybe 2 volumes of the reference manual. Also perhaps we should
>provide a section on the web site helping users to understand what they need
>to understand. This could be geared to real user situations, like "web
>development with Hibernate", "looking for a replacement for SLSBs", "looking
>for quicker/easier JDBC".
>
>Regards,
>Rod
>
>----- Original Message -----
>From: "Baum, Karl" <Kar...@Ta...>
>To: <spr...@li...>
>Sent: Tuesday, April 06, 2004 4:33 AM
>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>
>
>  
>
>>It's great that Spring offers a developer so many options, but after a
>>    
>>
>while
>  
>
>>it may be difficult to separate core Spring from the convenient add ons.
>>What must a developer read up on before he or she understands what spring
>>    
>>
>is
>  
>
>>really about?  I would tend to side towards IOC, AOP, and the BeanFactory
>>before the commons validator plugin, but this does not mean a commons
>>validator plugin is not a great idea (I for one am trying to integrate it
>>into my current project.).  Each plugin that is integrated directly into
>>    
>>
>the
>  
>
>>project is yet another responsibility for the community of Spring
>>    
>>
>developers
>  
>
>>when it comes to documentation and maintenance.  This documentation, with
>>all of the add ons and plugins, will eventually become so bloated, the
>>average developer may become overwhelmed by it's size and complexity.
>>
>>Why not farm these plugins out to smaller subprojects with teams of
>>developers focused on delivering a specific add on to the Spring project.
>>This leaves everyone with all of the great Spring options, but in the end
>>the Spring Framework never loses site of it's purpose  This isn't just
>>    
>>
>about
>  
>
>>the commons validator project.  With each new popular open source
>>    
>>
>component,
>  
>
>>we will need yet another package checked into the Spring project.  We can
>>start now with the spring-commons-validator subproject.
>>
>>----- Original Message -----
>>From: "Brandon Goodin" <ma...@ph...>
>>To: <spr...@li...>
>>Sent: Monday, April 05, 2004 10:08 PM
>>Subject: RE: [Springframework-developer] RE: commons-validator adapter
>>
>>
>>    
>>
>>>I understand that. I'm simply saying... leave the choices on other
>>>      
>>>
>>websites
>>    
>>
>>>and focus on what spring is. Not on all the neat toys you can plug into
>>>      
>>>
>>it.
>>    
>>
>>>So, where do you draw the line on what does and does not get included.
>>>      
>>>
>Why
>  
>
>>>not setup a directory of tools that can be used in spring instead of
>>>      
>>>
>>feeling
>>    
>>
>>>compelled to include support for every permutation into the distro or in
>>>      
>>>
>>the
>>    
>>
>>>spring cvs. Just cuz you can doesn't mean you should. I think moves like
>>>this will cause confusion around spring not help it.
>>>
>>>B
>>>
>>>-----Original Message-----
>>>From: spr...@li...
>>>[mailto:spr...@li...] On Behalf
>>>      
>>>
>>Of
>>    
>>
>>>Seth Ladd
>>>Sent: Monday, April 05, 2004 5:29 PM
>>>To: spr...@li...
>>>Subject: Re: [Springframework-developer] RE: commons-validator adapter
>>>
>>>Brandon Goodin wrote:
>>>      
>>>
>>>>commons validator? gack! Don't pollute spring with all of this crap. I
>>>>don't want to see spring turn into the 8000 pound gorilla that struts
>>>>has. Please consider making this stuff peripheral.
>>>>        
>>>>
>>>A nice aspect of Spring is that it attempts to give developers different
>>>choices for a particular task.  For validation, commons-validator is
>>>just one choice.  Other choices include metadata validator or
>>>programmatic validation.  IMHO, the commons-validator fills a nice
>>>niche: when you want to do declarative validation but can't mark up the
>>>source code (if, for example, you're using generated source or 3rd party
>>>classes).
>>>
>>>With Spring, you get to Pick and Choose!
>>>Seth
>>>
>>>
>>>-------------------------------------------------------
>>>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
>>>
>>>
>>>
>>>
>>>
>>>-------------------------------------------------------
>>>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
>>>      
>>>
>>-------------------------------------------------------
>>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
>>
>>    
>>
>
>
>
>
>-------------------------------------------------------
>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
>
>  
>

RE: [Springframework-developer] Creating documentation from Spring beans definition files (e.g. like HiveMind's HiveDoc)

[Faizan H. <fa...@ru...>]

Guys,
I might be able to help you in writing xsl stylesheets for spring configs.
It will be great if you can provide/explain the desired output for a
particular xml file. 

If Daniel can also send me the xsl file that he mentioned that will also be
a help.

Faizan 


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf Of
Daniel Potter
Sent: Tuesday, April 06, 2004 11:10 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Creating documentation from Spring
beans definition files (e.g. like HiveMind's HiveDoc)

I know it's not quite what you had in mind with this question, but we've
used Graphviz (www.research.att.com/sw/tools/graphviz/) to
generate dependency graphs based on Spring configuration files.  The
basic process involves using an XSL stylesheet to transform the Spring
XML config files into the .dot syntax used by Graphviz, then running
Graphviz on the .dot files to generate png, gif, postscript, etc.
dependency graphs.  Of course, this wouldn't work for autowired
configurations, but it generates interesting and useful graphs for
explicit configurations.

Daniel

On Tue, Apr 06, 2004 at 01:02:39AM -0700, Torsten Juergeleit wrote:
> Is anyone already working on a way to create
> documentation from Spring beans definition files?
> 
> Howard's HiveMind / HiveDoc
> (http://jakarta.apache.org/hivemind/hivedoc.html) uses
> XSL stylesheets to transform the HiveMind config files
> into a set of HTML files. Sample output:
> http://jakarta.apache.org/hivemind/hivedocs/index.html
> 
> Does it make sense to create something similar for
> Spring?
> 
> Torsten
> 
> __________________________________
> 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


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

Re: [Springframework-developer] Keep Spring Focused WAS: commons-validatoradapter

[Brandon G. <Bra...@pl...>]

ya matt I am aware of the different distros...Thanks for your input.

>>> li...@ra... 4/6/2004 1:41:04 PM >>>
> Make the 
> Spring core it's own product, make the MVC it's own product, make 
> the ibatis support it's own product, etc... This is not a difficult 
> concept and it is being used quite successfully. I think this would 
> be a better move towards the scalability of the Spring community. 

I'm assuming you're aware that Spring ships as 1 JAR or 7 separate
JARs?

http://jroller.com/page/raible?anchor=yeah_it_s_good

This might not be what's in the CVS tree - but I'd argue that the
distribution is more important than 
the CVS hierarchy.  As for "too many choices" - that can easily be
resolved with a sample app that 
shows the recommended choices.  

Matt


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

Re: [Springframework-developer] RE: commons-validator adapter

[Brandon G. <Bra...@pl...>]

Thanks for the post Rod. Perhaps this should be part of the Spring
manifesto and stated on the site. :D
 
Also...
"Hibernate is obviously core," - wouldn't this be better worded as
"part of the core distribution"? Cuz it isn't part of the
spring-core.jar ;-) You are communicating the wrong message from the
previous statement of "- ** Keep the core separate from the add-ons **
E.g. the IoC container doesn't even depend on AOP, let alone Commons
Validator/whatever." How can us lemmings expect to follow such confusing
statements?
 
Hoping you guys have a sense of humor ;)
Brandon Goodin

>>> rod...@in... 4/6/2004 11:56:19 AM >>>

Guys

We are aware of the dangers here. We do not want Spring to become
bloated,
and it won't.

So far we have the following strategies:

- ** Keep the core separate from the add-ons ** E.g. the IoC container
doesn't
even depend on AOP, let alone Commons Validator/whatever. This means
that
it's possibly to use say the BeanFactory or JDBC without extensive
dependencies: indeed, the whole of Spring (except integration) without
extensive dependencies.
- Keep the focus of the core developers on the core.
- Set the bar high in terms of the quality of what we accept. This is
one
argument for keeping commonly-used add-ins in the Spring project.
Let's suppose we don't address integration with a popular product such
as
Quartz. Several Spring/Quartz libraries then emerge, all but one of
them
bad. Now users are confused and it reflects poorly on Spring.
- Ensure that the correct message gets out. Marketing is important. We
must
ensure that people know that the core doesn't depend on the
extensions.

However, I think this thread does show that we need to be careful in
accepting too many add-ons into the core. Perhaps we could have an
add-ons
project for the second tier of integration: e.g. Hibernate is
obviously
core, Commons Validator could be shipped along with a Spring addons
distribution, but which is still under the Spring Framework umbrella.
Such
integrations likely to be used commonly are definitely in a separate
category from integration with highly specialized products, that are
unlikely to see wide use. And we can always promote code into Spring
proper.

Perhaps all integrations could start off in the add-ons project, and
only be
promoted if there's user demand.

Regarding documentation, good point, we should separate out the core
from
the add ons. Maybe 2 volumes of the reference manual. Also perhaps we
should
provide a section on the web site helping users to understand what they
need
to understand. This could be geared to real user situations, like "web
development with Hibernate", "looking for a replacement for SLSBs",
"looking
for quicker/easier JDBC".

Regards,
Rod

----- Original Message -----
From: "Baum, Karl" <Kar...@Ta...>
To: <spr...@li...>
Sent: Tuesday, April 06, 2004 4:33 AM
Subject: Re: [Springframework-developer] RE: commons-validator adapter


> It's great that Spring offers a developer so many options, but after
a
while
> it may be difficult to separate core Spring from the convenient add
ons.
> What must a developer read up on before he or she understands what
spring
is
> really about?  I would tend to side towards IOC, AOP, and the
BeanFactory
> before the commons validator plugin, but this does not mean a
commons
> validator plugin is not a great idea (I for one am trying to
integrate it
> into my current project.).  Each plugin that is integrated directly
into
the
> project is yet another responsibility for the community of Spring
developers
> when it comes to documentation and maintenance.  This documentation,
with
> all of the add ons and plugins, will eventually become so bloated,
the
> average developer may become overwhelmed by it's size and
complexity.
>
> Why not farm these plugins out to smaller subprojects with teams of
> developers focused on delivering a specific add on to the Spring
project.
> This leaves everyone with all of the great Spring options, but in the
end
> the Spring Framework never loses site of it's purpose  This isn't
just
about
> the commons validator project.  With each new popular open source
component,
> we will need yet another package checked into the Spring project.  We
can
> start now with the spring-commons-validator subproject.
>
> ----- Original Message -----
> From: "Brandon Goodin" <ma...@ph...>
> To: <spr...@li...>
> Sent: Monday, April 05, 2004 10:08 PM
> Subject: RE: [Springframework-developer] RE: commons-validator
adapter
>
>
> > I understand that. I'm simply saying... leave the choices on other
> websites
> > and focus on what spring is. Not on all the neat toys you can plug
into
> it.
> > So, where do you draw the line on what does and does not get
included.
Why
> > not setup a directory of tools that can be used in spring instead
of
> feeling
> > compelled to include support for every permutation into the distro
or in
> the
> > spring cvs. Just cuz you can doesn't mean you should. I think moves
like
> > this will cause confusion around spring not help it.
> >
> > B
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On
Behalf
> Of
> > Seth Ladd
> > Sent: Monday, April 05, 2004 5:29 PM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] RE: commons-validator
adapter
> >
> > Brandon Goodin wrote:
> > > commons validator? gack! Don't pollute spring with all of this
crap. I
> > > don't want to see spring turn into the 8000 pound gorilla that
struts
> > > has. Please consider making this stuff peripheral.
> >
> >
> > A nice aspect of Spring is that it attempts to give developers
different
> > choices for a particular task.  For validation, commons-validator
is
> > just one choice.  Other choices include metadata validator or
> > programmatic validation.  IMHO, the commons-validator fills a nice
> > niche: when you want to do declarative validation but can't mark up
the
> > source code (if, for example, you're using generated source or 3rd
party
> > classes).
> >
> > With Spring, you get to Pick and Choose!
> > Seth
> >
> >
> > -------------------------------------------------------
> > 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
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
>
>
> -------------------------------------------------------
> 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
>




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

Re: [Springframework-developer] Keep Spring Focused WAS: commons-validatoradapter

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

> Make the 
> Spring core it's own product, make the MVC it's own product, make 
> the ibatis support it's own product, etc... This is not a difficult 
> concept and it is being used quite successfully. I think this would 
> be a better move towards the scalability of the Spring community. 

I'm assuming you're aware that Spring ships as 1 JAR or 7 separate JARs?

http://jroller.com/page/raible?anchor=yeah_it_s_good

This might not be what's in the CVS tree - but I'd argue that the distribution is more important than 
the CVS hierarchy.  As for "too many choices" - that can easily be resolved with a sample app that 
shows the recommended choices.  

Matt

Re: [Springframework-developer] Keep Spring Focused WAS: commons-validatoradapter

[Larry M. <Lar...@pl...>]

HAHAH! OK, OK, point taken. :)

My fear is that the spring core gets too bloated. It seems like spring
is starting to move down the same path that struts did (adding stuff
arbitrarily), and I really hope that does not happen here. 

It is always easier to add stuff than to remove it, so I hope that there
will be alot of careful thought before adding things in that will be
difficult to extract later.

Larry

>>> se...@eh... 04/06/04 1:24 PM >>>
Larry Meadors wrote:
> I hate downloading 300M of stuff I will never use. 
> 
> Remember cocoon? :)

I told you 1 million times not to exaggerate! :)

Seth


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

Re: [Springframework-developer] Keep Spring Focused WAS: commons-validatoradapter

[Seth L. <se...@eh...>]

Larry Meadors wrote:
> I hate downloading 300M of stuff I will never use. 
> 
> Remember cocoon? :)

I told you 1 million times not to exaggerate! :)

Seth

Re: [Springframework-developer] Automagic creation of concrete class from interface/abstract classes

[Rod J. <rod...@in...>]

Oliver

Ok I see what you mean--I misunderstood last time.  Your approach sounds
fine: generate a subclass with CGLIB that means you can instantiate the
abstract class, and use an introduction to actually provide the behaviour
for those methods. The subclass could simply throw
UnsupportedOperationException for all methods, as the "implementation" of
these methods is purely to allow class instantiation, not for real usage.

Regards,
Rod

----- Original Message -----
From: "Oliver Hutchison" <Oli...@ou...>
To: <spr...@li...>
Sent: Monday, April 05, 2004 11:38 PM
Subject: RE: [Springframework-developer] Automagic creation of concrete
class from interface/abstract classes


Rod,

For interfaces I see how you would do it but how would it be done for
abstract classes?

The only way I can see is to extract an interface which has all the
abstract methods and then introduce it to the original abstract class
but I'd still have to fall back to CGLIB to generate the interface...
Not the most elegant solution but I guess it would work.

Thanks,
Oliver

-----Original Message-----
From: rod...@in... [mailto:rod...@in...]
Sent: Monday, 5 April 2004 6:21 PM
To: spr...@li...
Subject: Re: [Springframework-developer] Automagic creation of concrete
class from interface/abstract classes


Oliver

Introductions in Spring AOP should work fine for this. I
don't there's any need to use CGLIB independently.
Introductions in Spring work with dynamic proxies also.

Regards,
Rod


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


-------------------------------------------------------
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_id70&alloc_id638&op=ick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] RE: commons-validator adapter

[Rod J. <rod...@in...>]

Guys

We are aware of the dangers here. We do not want Spring to become bloated,
and it won't.

So far we have the following strategies:

- ** Keep the core separate from the add-ons ** E.g. the IoC container
doesn't
even depend on AOP, let alone Commons Validator/whatever. This means that
it's possibly to use say the BeanFactory or JDBC without extensive
dependencies: indeed, the whole of Spring (except integration) without
extensive dependencies.
- Keep the focus of the core developers on the core.
- Set the bar high in terms of the quality of what we accept. This is one
argument for keeping commonly-used add-ins in the Spring project.
Let's suppose we don't address integration with a popular product such as
Quartz. Several Spring/Quartz libraries then emerge, all but one of them
bad. Now users are confused and it reflects poorly on Spring.
- Ensure that the correct message gets out. Marketing is important. We must
ensure that people know that the core doesn't depend on the extensions.

However, I think this thread does show that we need to be careful in
accepting too many add-ons into the core. Perhaps we could have an add-ons
project for the second tier of integration: e.g. Hibernate is obviously
core, Commons Validator could be shipped along with a Spring addons
distribution, but which is still under the Spring Framework umbrella. Such
integrations likely to be used commonly are definitely in a separate
category from integration with highly specialized products, that are
unlikely to see wide use. And we can always promote code into Spring proper.

Perhaps all integrations could start off in the add-ons project, and only be
promoted if there's user demand.

Regarding documentation, good point, we should separate out the core from
the add ons. Maybe 2 volumes of the reference manual. Also perhaps we should
provide a section on the web site helping users to understand what they need
to understand. This could be geared to real user situations, like "web
development with Hibernate", "looking for a replacement for SLSBs", "looking
for quicker/easier JDBC".

Regards,
Rod

----- Original Message -----
From: "Baum, Karl" <Kar...@Ta...>
To: <spr...@li...>
Sent: Tuesday, April 06, 2004 4:33 AM
Subject: Re: [Springframework-developer] RE: commons-validator adapter


> It's great that Spring offers a developer so many options, but after a
while
> it may be difficult to separate core Spring from the convenient add ons.
> What must a developer read up on before he or she understands what spring
is
> really about?  I would tend to side towards IOC, AOP, and the BeanFactory
> before the commons validator plugin, but this does not mean a commons
> validator plugin is not a great idea (I for one am trying to integrate it
> into my current project.).  Each plugin that is integrated directly into
the
> project is yet another responsibility for the community of Spring
developers
> when it comes to documentation and maintenance.  This documentation, with
> all of the add ons and plugins, will eventually become so bloated, the
> average developer may become overwhelmed by it's size and complexity.
>
> Why not farm these plugins out to smaller subprojects with teams of
> developers focused on delivering a specific add on to the Spring project.
> This leaves everyone with all of the great Spring options, but in the end
> the Spring Framework never loses site of it's purpose  This isn't just
about
> the commons validator project.  With each new popular open source
component,
> we will need yet another package checked into the Spring project.  We can
> start now with the spring-commons-validator subproject.
>
> ----- Original Message -----
> From: "Brandon Goodin" <ma...@ph...>
> To: <spr...@li...>
> Sent: Monday, April 05, 2004 10:08 PM
> Subject: RE: [Springframework-developer] RE: commons-validator adapter
>
>
> > I understand that. I'm simply saying... leave the choices on other
> websites
> > and focus on what spring is. Not on all the neat toys you can plug into
> it.
> > So, where do you draw the line on what does and does not get included.
Why
> > not setup a directory of tools that can be used in spring instead of
> feeling
> > compelled to include support for every permutation into the distro or in
> the
> > spring cvs. Just cuz you can doesn't mean you should. I think moves like
> > this will cause confusion around spring not help it.
> >
> > B
> >
> > -----Original Message-----
> > From: spr...@li...
> > [mailto:spr...@li...] On Behalf
> Of
> > Seth Ladd
> > Sent: Monday, April 05, 2004 5:29 PM
> > To: spr...@li...
> > Subject: Re: [Springframework-developer] RE: commons-validator adapter
> >
> > Brandon Goodin wrote:
> > > commons validator? gack! Don't pollute spring with all of this crap. I
> > > don't want to see spring turn into the 8000 pound gorilla that struts
> > > has. Please consider making this stuff peripheral.
> >
> >
> > A nice aspect of Spring is that it attempts to give developers different
> > choices for a particular task.  For validation, commons-validator is
> > just one choice.  Other choices include metadata validator or
> > programmatic validation.  IMHO, the commons-validator fills a nice
> > niche: when you want to do declarative validation but can't mark up the
> > source code (if, for example, you're using generated source or 3rd party
> > classes).
> >
> > With Spring, you get to Pick and Choose!
> > Seth
> >
> >
> > -------------------------------------------------------
> > 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
> >
> >
> >
> >
> >
> > -------------------------------------------------------
> > 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
>
>
> -------------------------------------------------------
> 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
>

Re: [Springframework-developer] Groovy / Jython (was: Road map)

[Rod J. <rod...@in...>]

The XmlBeanFactory and other such classes are largely preserved for backw=
ard
compatibility. Also, having a separation is important, but users shouldn'=
t
be *forced* to be aware of it.

----- Original Message -----
From: "Alef Arendsen" <al...@jt...>
To: <spr...@li...>
Sent: Monday, April 05, 2004 10:42 PM
Subject: RE: [Springframework-developer] Groovy / Jython (was: Road map)


What about the separation between BeanDefinitionReaders and BeanFactories=
? I
thought BeanDefinitionReaders were supposed to do the stuff specific to t=
he
format (say XML or properties) and BeanFactory is just the container. But
that's confusing because there still is a *Xml*BeanFactory out there.

J=FCrgen, what's your take on this? Is the XmlBeanFactory and XmlWebAppCt=
x
something ancient or does it still have its use?

Alef


> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On Behal=
f
> Of Thomas Risberg
> Sent: Sunday, April 04, 2004 10:35 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Groovy / Jython (was: Road map=
)
>
> I have bee experimenting a bit with Jython.  I have not used it for a
> while, so I'm a bit rusty, but I did load an application context and
> used a data source been that was defined in it.
>
> I think that the different types of bean factories are going to have
> different feature sets - property files are less feature rich than the
> xml files.  With jython and groovy, we will have similar issues where
> some features just does not fit naturally.
>
> Here is my context (applicationContext.py):
>
> from org.springframework.jdbc.datasource import DriverManagerDataSource
> from org.springframework.jdbc.core import JdbcTemplate
>
> dataSource =3D DriverManagerDataSource()
> dataSource.driverClassName=3D"org.hsqldb.jdbcDriver"
> dataSource.url=3D"jdbc:hsqldb:hsql://localhost"
> dataSource.username=3D"sa"
> dataSource.password=3D""
>
> db =3D JdbcTemplate(dataSource)
>
>
> Here is my code (LoadPyContext.java:
>
> import java.util.List;
>
> import org.python.core.PySystemState;
> import org.python.util.PythonInterpreter;
> import org.springframework.jdbc.core.JdbcTemplate;
>
> public class LoadPyContext {
>     public static void main(String[] args) {
>         System.out.println("Start");
>         PySystemState.initialize();
>         PythonInterpreter pyInterp =3D new PythonInterpreter();
>         pyInterp.execfile("applicationContext.py");
>         JdbcTemplate db =3D (JdbcTemplate) pyInterp.get("db",
> JdbcTemplate.class);
>         List l =3D db.queryForList("select brand, price from beer");
>         System.out.println(l);
>     }
> }
>
> I guess the next step is to actually create a PythonBeanFactory.
>
> Thomas
>
> Alef Arendsen wrote:
>
> >Err,
> >
> >Been able to get a beanfactory up-and-running, however, not in a way a=
s
> >elegant as I wanted it to be, but that's something that's probably goi=
ng
> to
> >take some more time and thinking. It's something like this, and I don'=
t
> like
> >it ;-)
> >
> >test =3D new BeanDef (age:8,name:'susan')
> >test.singleton =3D true
> >test.dependencyCheck =3D PRIMITIVES
> >
> >est =3D new BeanDef (age:10)
> >est.name=3D'jim'
> >est.spouse=3Dtest
> >est.singleton =3D false
> >
> >I'm not entirely sure how to go about the dependencies and properties =
of
> a
> >bean versus the behavioral stuff (singleton, dependency checking,
> etcetera).
> >For sure we need some extra stuff here (i.e. some kind of wrapper arou=
nd
> the
> >BeanDefinition class--the BeanDef class in the script above), I don't
> think
> >dealing with MutablePropertyValue objects in a Groovy script directly =
is
> the
> >way to go. But maybe you noticed the problem in the script above alrea=
dy:
> >you can't have dependencies named 'singleton' or 'dependencyCheck' her=
e.
> So
> >maybe including some kind of metadata object might be an option.
> >
> >By the way, from my point of view, there's a difference between readin=
g
> in
> >and modifying a applicationcontext and its beandefinition and actually
> >approaching/using it at runtime. Currently I'm only thinking about the
> >former... Using it from Groovy scripts however could be quite somethin=
g
> as
> >well!
> >
> >Regards,
> >Alef
> >
> >
> >
> >
> >
> >
> >>-----Original Message-----
> >>From: spr...@li...
> >>[mailto:spr...@li...] On Beh=
alf
> >>Of Darren Davison
> >>Sent: Saturday, April 03, 2004 1:01 PM
> >>To: spr...@li...
> >>Subject: [Springframework-developer] Groovy / Jython (was: Road map)
> >>
> >>On Saturday 03 April 2004 09:47, Alef Arendsen wrote:
> >>
> >>
> >>
> >>>It would be nice to have something in the sandbox indeed. I'm curren=
tly
> >>>experimenting with a GroovyBeanDefinitionReader and it seems it's no=
t
> >>>going to be all that tough to get it running!
> >>>
> >>>
> >>snap!
> >>
> >>I started looking at something similar in both Groovy and Jython (par=
tly
> >>to
> >>see which of those two was 'best').  Thought it may be very useful fo=
r
> >>writing tests or certain deployment scripts.
> >>
> >>How far have you got with it?
> >>
> >>--
> >>
> >>Darren Davison
> >>Public Key: http://www.davison.uk.net/key.jsp
> >>
> >>
> >>-------------------------------------------------------
> >>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=3Dclick
> >>_______________________________________________
> >>Springframework-developer mailing list
> >>Spr...@li...
> >>https://lists.sourceforge.net/lists/listinfo/springframework-develope=
r
> >>
> >>
> >
> >
> >
> >-------------------------------------------------------
> >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=3Dclick
> >_______________________________________________
> >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=3Dclick
> _______________________________________________
> 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=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Keep Spring Focused WAS: commons-validatoradapter

[Larry M. <Lar...@pl...>]

I hate downloading 300M of stuff I will never use. 

Remember cocoon? :)

Larry

>>> se...@eh... 04/06/04 1:10 PM >>>

Personally, I hate having to go out and download 20 different jars.  I 
hate having to work out interdependencies.  

Re: [Springframework-developer] Keep Spring Focused WAS: commons-validatoradapter

[Seth L. <se...@eh...>]

> and provide extensions/plugins to the core. All are wildly successful. 
> So, what is the compelling argument to do otherwise? So far everyone one 
> has simply been restating shared goals not really explaining why they 
> prefer the all in one approach of distribution.

To answer your question:


Personally, I hate having to go out and download 20 different jars.  I 
hate having to work out interdependencies.  I hate resolving classpath 
issues after finding out I'm missing yet another jar.  I like it when 
projects include all their 3rd party jars needed to work instead of 
making me go out and get them.  I like it when I download a single 
tarball for a project.  Spring even has the best of two worlds here: I 
can download two different distributions, one w/ dependencies and one 
without.  They also make it really nice and create an uberjar or 
different specific jars.

So, Spring is nice because the distribution is nice.
Seth

Re: [Springframework-developer] Keep Spring Focused WAS: commons-validatoradapter

[Brandon G. <Bra...@pl...>]

Let me be very clear. I have no problem with people writing plugins. I'm
not saying we should limit options. That is silly. What I am saying is
that keeping the choices more cleanly separated is of greater
importance. As the Spring community grows and compelling and useful
products become available are we going to include them all into spring?
Wouldn't it be better to separate them out beyond the spring-*.jar files
and allow for developers to assemble their needs. I don't see how what I
am suggesting contradicts or compromises any of what you guys are
saying. I think the linux model is very compelling. Make the Spring core
it's own product, make the MVC it's own product, make the ibatis support
it's own product, etc... This is not a difficult concept and it is being
used quite successfully. I think this would be a better move towards the
scalability of the Spring community. 
 
What is the philosophy that draws the line with what is and is not part
of Spring? In my opinion that line needs to be drawn a little further
back than it currently is. Take a look at the pear.php.net project or
the gentoo.org linux distro or eclipse.org. All of these focus on a core
and provide extensions/plugins to the core. All are wildly successful.
So, what is the compelling argument to do otherwise? So far everyone one
has simply been restating shared goals not really explaining why they
prefer the all in one approach of distribution.
 
Brandon Goodin
 
>>> se...@eh... 4/6/2004 12:15:48 PM >>>

Peter den Haan wrote:
> The Spring core supports JDBC, iBatis, JDO and Hibernate data access
> technology. It supports Hessian, Burlap, JAX-RPC and RMI remoting. I
don't
> think any of this has proved to be a problem. It supports JSP,
Freemarker
> and Velocity, and I can't remember anyone asking which was the
"official"
> spring view technology. Aren't we fighting windmills here?
> 
> I must admit that I find the Apache Commons validator an infuriating
product
> because it is pretty good in some ways and absolutely horrible in
others,
> and I would look forward to a clean, flexible and pluggable native
Spring
> solution. Until then it seems to me that a validator adapter fits
entirely
> into the Spring philosophy as it stands.

Just wanted to put my support behind this statement.  To me, Spring's 
advantage is that it's engineered so well that many different 
implementations can plug into it.  It gives the developer (me) a
choice. 
  Everything's behind a nice set of interfaces, and I have never felt 
that a technology is integrated poorly.

As long as a particular implementation doesn't impose its whim on the 
core Spring design, I will always welcome the amazing integration and 
choices offered by Spring.

Seth


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

Re: [Springframework-developer] Keep Spring Focused WAS: commons-validator adapter

[Seth L. <se...@eh...>]

Peter den Haan wrote:
> The Spring core supports JDBC, iBatis, JDO and Hibernate data access
> technology. It supports Hessian, Burlap, JAX-RPC and RMI remoting. I don't
> think any of this has proved to be a problem. It supports JSP, Freemarker
> and Velocity, and I can't remember anyone asking which was the "official"
> spring view technology. Aren't we fighting windmills here?
> 
> I must admit that I find the Apache Commons validator an infuriating product
> because it is pretty good in some ways and absolutely horrible in others,
> and I would look forward to a clean, flexible and pluggable native Spring
> solution. Until then it seems to me that a validator adapter fits entirely
> into the Spring philosophy as it stands.

Just wanted to put my support behind this statement.  To me, Spring's 
advantage is that it's engineered so well that many different 
implementations can plug into it.  It gives the developer (me) a choice. 
  Everything's behind a nice set of interfaces, and I have never felt 
that a technology is integrated poorly.

As long as a particular implementation doesn't impose its whim on the 
core Spring design, I will always welcome the amazing integration and 
choices offered by Spring.

Seth

Re: [Springframework-developer] Commons-Validator for Spring

[Seth L. <se...@eh...>]

> generated, so stuff can be changed after compilation.  As far as I 
> understand the attributes stuff - it'll stay hardcoded in your class (no 
> XML generation).  Of course, I rarely change any of this stuff after 
> compilation - but it is a nice option.

Matt,

The commons-attributes stuff actually creates other classes to store the 
attributes in.  So I guess you could change those generated classes 
after the fact, though it might not be too pretty. :)

Seth