springframework-developer — Spring Framework developers list

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

[Dirk M. <pos...@gm...>]

Hello Jürgen,

I just had a look at the implementation of DelegatingActionProxy. I
wonder why you are using a membar attribute delegateAction. The class has to
be thread safe, and I thing using this attribute it isn't. In getDelegateAction
your synchronized access does not include the return statement.

Do I miss something?


Best regards,
Dirk

Re: [Springframework-developer] Preparing for 1.0.1

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

>As we're about to release Spring 1.0.1 by the beginning of 
next week, we need to re-test the current CVS contents 
thoroughly. 
Yes. I'd like to see a code freeze on the /src tree before 
the release--say tomorrow?--except for any bug fixes. 
Juergen, is this feasible?

Stability is paramount with 1.0.1. We have some worthwhile 
new features, like sophisticated Struts integration, that we 
should definitely include, but we need to try to bed down 1.0 
with this release so we can focus on 1.1.

Regards,
Rod

Re: [Springframework-developer] Preparing for 1.0.1

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

Everybody,
=20
As we're about to release Spring 1.0.1 by the beginning of next week, we =
need to re-test the current CVS contents thoroughly. The most important =
area is Hibernate/JTA integration: Flushing failures should now be =
handled properly; and ThreadLocal Sessions should work without =
JtaTransactionManager too, as long as there's a Hibernate =
TransactionManagerLookup configured.=20
=20
As a side note: Hibernate's TransactionManagerLookup can be configured =
via Spring too, passing a javax.transaction.TransactionManager into =
LocalSessionFactoryBean's "jtaTransactionManager" property. Normally, =
this will be a JndiObjectFactoryBean reference, possibly shared with =
JtaTransactionManager (i.e. passed into the latter's =
"transactionManager" property too).
=20
If anyone finds some further areas in the documentation that need =
completion or polishing, please address them this week rather than next =
one :-)
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: Fr 09.04.2004 07:57
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



"AbstractPrototypeBasedTargetSource" may be a bit wordy, but I like it, =
as it hits the nail: "prototype-based" is what it is. I've got a new =
favourite :-)

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: Do 08.04.2004 20:21
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



AbstractDynamicTargetSource is OK by me, although I'm not in love with =
it.
Technically of course a dynamic target source need not use the bean =
factory
at all. But AbstractPrototypeBasedTargetSource is a bit wordy...

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, April 08, 2004 5:27 PM
Subject: Re: [Springframework-developer] Preparing for 1.0.1


Final decision here? I still vote for "AbstractDynamicTargetSource"; at
least against "AbstractPrototypeTargetSource".

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Monday, April 05, 2004 9:51 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.0.1


Actually, I still prefer "AbstractDynamicTargetSource": Target beans =
being
defined as prototypes is a requirement for any meaningful dynamic target
source strategy (no matter if one-shot, ThreadLocal or pooled), =
therefore I
consider it fine that AbstractDynamicTargetSource implicitly works with
prototype target beans. But just PrototypeTargetSource delivers actual
one-instance-per-method-invocation semantics, rather than pooling =
instances
or the like.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
j=FCrgen h=F6ller [werk3AT]
Gesendet: So 04.04.2004 16:25
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



That's what I meant with the different meaning of the term "prototype":
AbstractPrototypeTargetSource just assumes that the bean that it =
references
is a prototype, allowing to expose targets with ThreadLocal or pooling
semantics. On the other hand, PrototypeTargetSource actually exposes a
"prototype" target, i.e. a new target object on each method invocation
(analogous to the term "prototype" used in bean definitions).

I agree that the term "prototype" isn't wrong in
AbstractPrototypeTargetSource, but it's used with somewhat different =
meaning
than in PrototypeTargetSource. To avoid confusion for people that dig =
into
Spring's javadoc or even implementation, we should use different terms =
here,
i.e. use the term "prototype" for a more specific meaning (preferably =
the
one analogous to bean definitions).

I'm open for other suggestions, of course!

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Rod Johnson
Gesendet: So 04.04.2004 16:08
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



I guess AbstractDynamicTargetSource is an improvement. I agree the =
naming
pattern isn't great, but the abstract base class _does_ work with =
prototype
definitions, so having Prototype in its name does make sense. It's not a
generic "Dynamic" TargetSource because it works with bean names and
getBeans() assuming a prototype.

Any other suggestions? If this is renamed, I'd rather that it was
undebatably right.

R


----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, April 03, 2004 6:46 PM
Subject: Re: [Springframework-developer] Preparing for 1.0.1


A minor naming issue that I've noticed: We have an
AbstractPrototypeTargetSource, which serves as base class for
PrototypeTargetSource, ThreadLocalTargetSource and
AbstractPoolingTargetSource. We don't have the AbstractXxx/Xxx naming
pattern anywhere else in the framework. (I've actually removed a similar
naming pattern in the AbstractAutoProxyCreator area before 1.0 final.)

Furthermore, "AbstractPrototypeTargetSource" is actually a bit =
misleading,
as we're using a broader meaning of the word prototype here than found =
in
bean definitions. "PrototypeTargetSource" matches the bean definition =
term
exactly, but the base class is more generic: So what about renaming it =
to
"AbstractDynamicTargetSource" or the like, indicating that it serves as =
base
class for all non-singleton TargetSources?

Like the AopUtils move, this should be fine in terms of compatibility =
level,
as the base class is not part of the public API but rather an internal
implementation detail. PrototypeTargetSource and co will still be fully
backward compatible after that change, and I doubt that anyone has
implemented custom TargetSources yet (and even if, it's trivial to =
adapt).

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Rod Johnson
Gesendet: Fr 02.04.2004 16:53
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



I suggest that we sit on this code for at least a week until we release =
it,
so we can catch anything else. How about we target Monday week for =
release?

A 1.0.1 release should be driven by stability, not date, so we should =
see if
any more issues come out of the woodwork.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, April 02, 2004 10:57 AM
Subject: [Springframework-developer] Preparing for 1.0.1


Hi everybody,

From my point of view, the code is ready for release 1.0.1. There were a
couple of bug fixes and minor enhancements since 1.0 final. The most
important fix is proper Hibernate/JTA resource management when flush =
fails.
Enhancements include the introduction of the MessageCodesResolver =
interface
in the validation package, and a more efficient internal implementation =
of
AbstractMessageSource. See the changelog for details.

Please give the current CVS snapshot a try. There shouldn't be any =
issues,
as changes are minor and just affect specific functionality. I'd like to
target mid next week for the release, i.e. two weeks after 1.0 final. In =
the
meantime, the only thing I plan to address is the lack of remoting =
coverage
in the reference docs. If anyone feels the need to improve other parts =
of
the docs, please do so till mid next week!

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

Re: [Springframework-developer] Struts Spring Plugin

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

Matt,
=20
First of all, thanks for testing this stuff! :-)
=20
Regarding test suites: If you define all your beans in the =
ContextLoaderPlugIn context, Struts will load them via its PlugIn =
mechanism, thus ServletContextListeners and load-on-startup Servlets do =
not matter. However, in the typical Spring case, you'll have =
ContextLoaderListener or ContextLoaderServlet loading the root context, =
and this is by no means an odd choice. So I consider that as a severe =
limit of MockStrutsTestCase: It really should be able to invoke =
ServletContextListeners and load-on-startup Servlets.
=20
Note that you can load the root application context in a programmatic =
fashion too: If you have already a mock ServletContext, simply invoke =
ContextLoader.initWebApplicationContext(servletContext) in your test =
setup - this is exactly what ContextLoaderListener respectively =
ContextLoaderServlet does. You could also instantiate an =
XmlWebApplicationContext yourself, configure the location of the root =
context definition files, refresh it, and set it as ServletContext =
attribute using the attribute name defined in the WebApplicationContext =
interface.
=20
It would be excellent to have all remaining issues sorted out by the end =
of the week, as we'll probably release Spring 1.0.1 Sunday night. I'd =
really like to have this new plugin in there...
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Matt Raible
Gesendet: Mo 12.04.2004 14:25
An: spr...@li...
Betreff: RE: [Springframework-developer] Struts Spring Plugin



I tried this out this morning...

1.  It works just like the Struts Spring Plugin using the
ContextLoaderPlugIn and DelegatingActionProxy.  All I had to do was
change class and property names and everything worked as before.  This
approach still seems to be necessary to use MockStrutsTestCase with
Spring.

2.  I changed my Action to extend DispatchActionSupport and then
retrieved my Manager using
getWebApplicationContext().getBean("userManager").  This worked as well,
but only when running in the servlet container.  This means that
CactusStrutsTestCase will work, but not MockStrutsTestCase.

3.  I tried to migrate the struts-example app to use this new plugin -
and it seems to have worked for the most part.  However, there are some
validator issues that might be related to this.  I'll get with Don to
try and solve these.

HTH,

Matt

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...]
>  On Behalf Of j=FCrgen h=F6ller [werk3AT]
> Sent: Friday, April 09, 2004 2:50 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Struts Spring Plugin
>
>
> I've just finished the new Struts integration classes, now in
> the org.springframework.web.struts package, including a
> corresponding test suite.
>=20
> For the "proxy delegates to Spring-managed Action" approach,
> there are ContextLoaderPlugIn and DelegatingActionProxy
> (corresponding to the original SpringPlugIn and SpringAction
> classes, respectively). The former is analogous to
> FrameworkServlet in its context-loading capabilities, loading
> from "/WEB-INF/<servlet-name>-servlet.xml" by default (using
> the servlet-name of the Struts ActionServlet), supporting a
> "contextConfigLocation" property.
>=20
> A ContextLoaderPlugIn context will automatically refer to the
> root application context (loaded by
> ContextLoaderListener/Servlet) as parent, if any, just like
> FrameworkServlet. Action beans defined there receive the
> ActionServlet via a corresponding BeanPostProcessor, also
> resetting the servlet reference to null on destruction.
>=20
> For the "Action has easy access to a Spring context"
> approach, there are the ActionSupport and
> DispatchActionSupport classes, providing convenient
> getWebApplicationContext etc methods. Both will first check
> for a ContextLoaderPlugIn context, then fall back to the root
> web application context. The latter should be the typical
> usage, making middle tier beans available to any web component.
>=20
> Matt, can you please give these classes a try, possibly till
> early next week? They should be as easy to use as the
> original Spring Struts Plugin, but offer more powerful and
> flexible options. The javadocs should hopefully clarify usage
> and configuration options.
>=20
> I wonder what to do about the adapted Struts sample app from
> the Spring Struts Plugin distribution: Might it be worthwhile
> to deprecate the original plugin itself but provide a
> revamped version of the sample app within the Struts Apps
> project, using Spring's new integration classes now?
>=20
> Juergen
>=20
>
> ________________________________
>
> Von: spr...@li... im
> Auftrag von Matt Raible
> Gesendet: Mi 07.04.2004 04:37
> An: spr...@li...; Don Brown
> Betreff: Re: [Springframework-developer] Re: Struts Spring Plugin
>
>
>
> I'm in agreement with Don here.  I'm just looking for the
> best/easiest solution to integrate the two.  When I first
> looked at this plugin, I didn't like the fact that I had to
> declare my Action twice (once in struts-config.xml and once
> in applicationContext.xml).  However, the fact that I could
> use MockStrutsTestCase, as well as set my Managers
> declaratively on my Actions made me really like it.  I'd like
> a minimal-intrusion mechanism, but I'm willing to do whatever
> you feel is best.  By minimal-intrusion, I mean I'd like to
> use an existing Action with very little or no changes - only
> some tweaking in an XML file.  I don't know if that's possible.
>
> Matt
>
>
> On Apr 6, 2004, at 5:37 PM, Don Brown wrote:
>
> > I like your approach and think it is much stronger solution
> to Struts
> > and Spring integration.   To be honest, I don't really have
> any plans
> > for the plugin so feel free to improve it as you see fit.=20
> I put the
> > plugin out there to hopefully spark interest in integrating the two
> > projects closer, and I'd glad to see that progressing.  Let
> me know if
> > I can be of help, but please keep me informed as I'm anxious to see
> > where else Spring might be useful, particularly in Struts itself.
> >
> > Don
> >
> > j=FCrgen h=F6ller [werk3AT] wrote:
> >
> >> Matt, Don, Rod, all,
> >> We need to thoroughly consider this. I guess I've been a bit too
> >> eager in wanting the Struts plugin to get into the Spring main
> >> project ASAP (but that's me, can't do anything about it) ;-) My
> >> starting point is a recent discussion via private email
> that resulted
> >> in variations on how to integrate Struts with Spring. As a result,
> >> I've got two support classes lying around now, namely
> ActionSupport
> >> and DispatchActionSupport, providing easy access to the
> Spring root
> >> application context (and to other goodies like a
> >> MessageSourceAccessor), similar to the Tiles
> >> ComponentControllerSupport and JAX-RPC
> ServletEndpointSupport classes
> >> that we already ship with Spring. As with the latter, those two
> >> Struts Action support classes are not wired by Spring
> themselves but
> >> rather allow for access to a Spring context. The Actions
> themselves
> >> are still set up in the usual way in struts-config.xml. I believe
> >> that such Struts Action support classes are a valuable and
> >> straightforward addition to similar integration classes that we
> >> already ship, particularly if a variety of Spring
> ApplicationContext
> >> functionality needs to be used in an Action
> implementation. As Struts
> >> is currently the most important third-party web framework
> that Spring
> >> needs to integrate with, it's an obvious option to ship those two
> >> classes with the Spring distribution. Note that we ship the Struts
> >> jars with Spring anyway, for our Tiles integration and for
> the Struts
> >> web tier of JPetStore, so this doesn't introduce any new
> >> dependencies. That was when I noticed the planned
> reworking of Don's
> >> Spring Struts Plugin on Matt's blog. The original idea of
> the plugin
> >> is different to the "make the Spring context accessible" approach
> >> outlined above: I do consider it a valuable alternative,
> if one wants
> >> to actually wire the Struts Actions *themselves* as Spring-managed
> >> beans. As this just involves two rather simple classes, a context
> >> loader PlugIn and a delegating Action proxy, inclusion in
> Spring can
> >> be considered here too, just like with the two Action
> support classes
> >> above. Of course, we all need to agree on this; sorry for
> me shooting
> >> forward overeagerly here.
> >> Regarding the implementation of the plugin approach, I see the
> >> potential for a variety of improvements: most importantly, using an
> >> XmlWebApplicationContext rather than an XmlBeanFactory for hosting
> >> the plugin context (similar to Spring's own DispatcherServlet), and
> >> automatically wiring it with the Spring root application
> context (if
> >> any). This would allow for defining the Struts Actions in
> the plugin
> >> context, referencing beans in the root web application context from
> >> there. IMO, this is important for clear layering: web tier
> components
> >> (Struts Actions) are defined in the plugin context, middle tier
> >> components remain in the root web application context (same as with
> >> Spring's own web MVC). struts-config simply delegates to
> the Actions
> >> in the plugin context.
> >> Furthermore, the naming of the Actions in the plugin
> context can now
> >> match the Struts Action names in struts-config in a
> literal fashion,
> >> by using <bean name=3D"..."> rather than <bean id=3D"...">. Such =
alias
> >> names can contain any special characters like slashes, so
> names like
> >> "/login" or "/module/login" are possible. I believe that keeping
> >> these names in sync is more intuitive than stripping the leading
> >> slash off or replacing slashes with underscores. This simply wasn't
> >> possible in the early Spring milestones that the original
> plugin was
> >> written for, but I think it's the most viable way now.
> >> An important point for thread safety is the passing of the
> >> ActionServlet to the Spring-wired Action instances. This currently
> >> happens in the SpringAction proxy, but unfortunately in a
> >> non-thread-safe manner (if I grasp it correctly). A
> preferable way is
> >> to register a corresponding BeanPostProcessor with the BeanFactory
> >> that wires the Actions, passing the ActionServlet to
> Actions at bean
> >> initialization time. In general, this works very similar
> to a Spring
> >> FrameworkServlet/DispatcherServlet; it's quite easy to keep these
> >> classes analogous and consistent.
> >> I did a clean-room implementation of this plugin idea
> yesterday, and
> >> it worked out nicely. ContextLoaderPlugIn is the equivalent of
> >> Spring's FrameworkServlet, loading a
> ActionServlet-specific context,
> >> by default from "<servlet-name>-servlet.xml" (just like with
> >> DispatcherServlet). DelegatingActionProxy is a small Action
> >> implementation that delegates to the Spring-wired Action
> of the same
> >> name. These classes correspond to the original SpringPlugIn and
> >> SpringAction, respectively. Note that ContextLoaderPlugIn supports
> >> all the configuration options of FrameworkServlet, including
> >> "contextConfigLocation", and automatically takes the Spring root
> >> application context as parent (just like FrameworkServlet).
> >> In total, I now have the two Action support classes from above
> >> (ActionSupport, DispatchActionSupport), plus the two
> classes for the
> >> plugin approach (ContextLoaderPlugIn, DelegatingActionProxy). The
> >> question is: Should we include them in the Spring main
> distribution,
> >> should we update the Struts Spring Plugin project with them, or
> >> should we scrap them? ;-) As we're talking about 4 small
> classes here
> >> (2 for the plugin approach), I tend to want to include in
> the Spring
> >> distro, as that little code doesn't seem like a good
> candidate for a
> >> separate project. As I understand, Matt seems to agree in that
> >> respect.
> >> Most importantly: Don, what do you think about this? I do
> by no means
> >> intend to pass you over, despite my eagerness in reworking
> the plugin
> >> ;-) Of course, such a plugin shipped with Spring would
> still accredit
> >> the original idea and implementation to you. I just
> believe that the
> >> reworked versions are significantly more powerful and flexible than
> >> the originals, leveraging all that Spring can offer for Struts at
> >> this point of time, similar to Spring's FrameworkServlet.
> And as this
> >> is about so little but very useful code, I feel that
> including it in
> >> Spring itself is a viable option, particularly given that
> Struts 1.1
> >> and the upcoming 1.2 will be around for quite some time to
> come, and
> >> be a dominant web framework choice in combination with a
> >> Spring-managed middle tier.
> >> I understand that Struts 2.0 might be a different matter, providing
> >> its own means of Spring integration, but I assume that referencing
> >> Spring beans should then be possible in the Struts config
> file itself
> >> (similar to XWork's external reference mechanism) rather than with
> >> the proxy/delegation approach of the current plugin. I consider the
> >> current Struts integration classes as solutions for Struts 1.1 and
> >> 1.2, both the Action support classes and the plugin
> approach (as two
> >> alternative ways). And as there are already enough projects to
> >> combine for typical users, I suggest to include those
> classes in the
> >> Spring distribution, in up-to-date versions.
> >> Of course, I don't want to interfere with other plans of
> >> Struts/Spring integration. We can also integrate my
> reworked versions
> >> into the Struts Spring Plugin project, or possibly host
> the code in a
> >> separate module within the main Spring project (spring-struts?
> >> spring-integration?). I'm open for suggestions. What does everybody
> >> think? Feedback welcome :-)
> >> Regards,
> >> Juergen
> >>
> >> ________________________________
> >>
> >> Von: spr...@li...
> im Auftrag
> >> von Matt Raible
> >> Gesendet: Mo 05.04.2004 22:19
> >> An: spr...@li...
> >> Cc: str...@li...
> >> Betreff: [Springframework-developer] Re: Struts Spring Plugin
> >>
> >>
> >>
> >> Juergen,
> >>
> >> That's funny - I was just talking with Don about refactoring some
> >> stuff.  Good timing!
> >> +1 for moving it to Spring's repository where it belongs.
> >>
> >> I made a few changes today (just checked them in) you
> might want to
> >> know about:
> >>
> >> How to use the SpringPlugin:
> >>
> >> 1.  Put nothing to initialize Spring in web.xml.  Use the
> Plugin to
> >> do this.
> >>    - Specifying a "beansConfig" path will load it from a
> custom path.
> >>    - No path will default to "/WEB-INF/applicationContext.xml".
> >>    - If your webapp has multiple config files - use #2 below or
> >> specify
> >>      a "contextConfigLocation" variable as a <context-param> in
> >> web.xml.
> >>      The values for this parameter should be comma-delimited.
> >>   2.  Put Spring initializers (ContextLoaderListener or
> >> ContextLoaderServlet)
> >>    in web.xml and put nothing in struts-config.xml.
> >>   Note that only #1 will work if you are using
> MockStrutsTestCase to
> >> test your actions.  IMO, this is quite powerful b/c you
> can use it to
> >> test your Struts
> >> Actions w/o a container.
> >>
> >> I've cc'd the struts-apps mailing list so Don Brown (the original
> >> author) can
> >> help us make this transition.
> >>
> >> Matt
> >>
> >> P.S.  Since SF's anonymous CVS takes a while to catch up, I've
> >> uploaded the latest source to
> >> http://static.raibledesigns.com/downloads/struts-spring-0.3.zip.
> >> It's a 6 MB
> >> download b/c of the refactored struts-example app.
> >>
> >> --- j=FCrgen_h=F6ller_[werk3AT] <jue...@we...> =
wrote:
> >>
> >>> Matt,
> >>>
> >>> I've just read that on the Spring Live blog that you're
> refining Don
> >>> Brown's Struts Spring Plugin. That reminded me that I've
> repeatedly
> >>> considered
> >>> including something like this Plugin in the main Spring
> 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/s>
pringframework-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=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

RE: [Springframework-developer] Struts Spring Plugin

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

I tried this out this morning...

1.  It works just like the Struts Spring Plugin using the
ContextLoaderPlugIn and DelegatingActionProxy.  All I had to do was
change class and property names and everything worked as before.  This
approach still seems to be necessary to use MockStrutsTestCase with
Spring.=20

2.  I changed my Action to extend DispatchActionSupport and then
retrieved my Manager using
getWebApplicationContext().getBean("userManager").  This worked as well,
but only when running in the servlet container.  This means that
CactusStrutsTestCase will work, but not MockStrutsTestCase.

3.  I tried to migrate the struts-example app to use this new plugin -
and it seems to have worked for the most part.  However, there are some
validator issues that might be related to this.  I'll get with Don to
try and solve these.

HTH,

Matt

> -----Original Message-----
> From: spr...@li...=20
> [mailto:spr...@li...]
>  On Behalf Of j=FCrgen h=F6ller [werk3AT]
> Sent: Friday, April 09, 2004 2:50 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Struts Spring Plugin
>=20
>=20
> I've just finished the new Struts integration classes, now in=20
> the org.springframework.web.struts package, including a=20
> corresponding test suite.
> =20
> For the "proxy delegates to Spring-managed Action" approach,=20
> there are ContextLoaderPlugIn and DelegatingActionProxy=20
> (corresponding to the original SpringPlugIn and SpringAction=20
> classes, respectively). The former is analogous to=20
> FrameworkServlet in its context-loading capabilities, loading=20
> from "/WEB-INF/<servlet-name>-servlet.xml" by default (using=20
> the servlet-name of the Struts ActionServlet), supporting a=20
> "contextConfigLocation" property.
> =20
> A ContextLoaderPlugIn context will automatically refer to the=20
> root application context (loaded by=20
> ContextLoaderListener/Servlet) as parent, if any, just like=20
> FrameworkServlet. Action beans defined there receive the=20
> ActionServlet via a corresponding BeanPostProcessor, also=20
> resetting the servlet reference to null on destruction.
> =20
> For the "Action has easy access to a Spring context"=20
> approach, there are the ActionSupport and=20
> DispatchActionSupport classes, providing convenient=20
> getWebApplicationContext etc methods. Both will first check=20
> for a ContextLoaderPlugIn context, then fall back to the root=20
> web application context. The latter should be the typical=20
> usage, making middle tier beans available to any web component.
> =20
> Matt, can you please give these classes a try, possibly till=20
> early next week? They should be as easy to use as the=20
> original Spring Struts Plugin, but offer more powerful and=20
> flexible options. The javadocs should hopefully clarify usage=20
> and configuration options.
> =20
> I wonder what to do about the adapted Struts sample app from=20
> the Spring Struts Plugin distribution: Might it be worthwhile=20
> to deprecate the original plugin itself but provide a=20
> revamped version of the sample app within the Struts Apps=20
> project, using Spring's new integration classes now?
> =20
> Juergen
> =20
>=20
> ________________________________
>=20
> Von: spr...@li... im=20
> Auftrag von Matt Raible
> Gesendet: Mi 07.04.2004 04:37
> An: spr...@li...; Don Brown
> Betreff: Re: [Springframework-developer] Re: Struts Spring Plugin
>=20
>=20
>=20
> I'm in agreement with Don here.  I'm just looking for the=20
> best/easiest solution to integrate the two.  When I first=20
> looked at this plugin, I didn't like the fact that I had to=20
> declare my Action twice (once in struts-config.xml and once=20
> in applicationContext.xml).  However, the fact that I could=20
> use MockStrutsTestCase, as well as set my Managers=20
> declaratively on my Actions made me really like it.  I'd like=20
> a minimal-intrusion mechanism, but I'm willing to do whatever=20
> you feel is best.  By minimal-intrusion, I mean I'd like to=20
> use an existing Action with very little or no changes - only=20
> some tweaking in an XML file.  I don't know if that's possible.
>=20
> Matt
>=20
>=20
> On Apr 6, 2004, at 5:37 PM, Don Brown wrote:
>=20
> > I like your approach and think it is much stronger solution=20
> to Struts
> > and Spring integration.   To be honest, I don't really have=20
> any plans
> > for the plugin so feel free to improve it as you see fit. =20
> 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=20
> 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=20
> >> starting point is a recent discussion via private email=20
> that resulted=20
> >> in variations on how to integrate Struts with Spring. As a result,=20
> >> I've got two support classes lying around now, namely=20
> ActionSupport=20
> >> and DispatchActionSupport, providing easy access to the=20
> Spring root=20
> >> application context (and to other goodies like a=20
> >> MessageSourceAccessor), similar to the Tiles=20
> >> ComponentControllerSupport and JAX-RPC=20
> 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=20
> themselves but=20
> >> rather allow for access to a Spring context. The Actions=20
> themselves=20
> >> are still set up in the usual way in struts-config.xml. I believe=20
> >> 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=20
> ApplicationContext=20
> >> functionality needs to be used in an Action=20
> implementation. As Struts=20
> >> is currently the most important third-party web framework=20
> 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=20
> the Struts=20
> >> web tier of JPetStore, so this doesn't introduce any new=20
> >> dependencies. That was when I noticed the planned=20
> reworking of Don's=20
> >> Spring Struts Plugin on Matt's blog. The original idea of=20
> the plugin=20
> >> is different to the "make the Spring context accessible" approach=20
> >> outlined above: I do consider it a valuable alternative,=20
> if one wants=20
> >> to actually wire the Struts Actions *themselves* as Spring-managed=20
> >> beans. As this just involves two rather simple classes, a context=20
> >> loader PlugIn and a delegating Action proxy, inclusion in=20
> Spring can=20
> >> be considered here too, just like with the two Action=20
> support classes=20
> >> above. Of course, we all need to agree on this; sorry for=20
> me shooting=20
> >> 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=20
> context (if
> >> any). This would allow for defining the Struts Actions in=20
> the plugin
> >> context, referencing beans in the root web application context from
> >> there. IMO, this is important for clear layering: web tier=20
> 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=20
> the Actions
> >> in the plugin context.
> >> Furthermore, the naming of the Actions in the plugin=20
> context can now
> >> match the Struts Action names in struts-config in a=20
> literal fashion,
> >> by using <bean name=3D"..."> rather than <bean id=3D"...">. Such =
alias
> >> names can contain any special characters like slashes, so=20
> 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=20
> 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=20
> preferable way is
> >> to register a corresponding BeanPostProcessor with the BeanFactory
> >> that wires the Actions, passing the ActionServlet to=20
> Actions at bean
> >> initialization time. In general, this works very similar=20
> 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=20
> yesterday, and
> >> it worked out nicely. ContextLoaderPlugIn is the equivalent of
> >> Spring's FrameworkServlet, loading a=20
> 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=20
> 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=20
> classes for the
> >> plugin approach (ContextLoaderPlugIn, DelegatingActionProxy). The
> >> question is: Should we include them in the Spring main=20
> distribution,
> >> should we update the Struts Spring Plugin project with them, or
> >> should we scrap them? ;-) As we're talking about 4 small=20
> classes here
> >> (2 for the plugin approach), I tend to want to include in=20
> the Spring
> >> distro, as that little code doesn't seem like a good=20
> 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=20
> by no means
> >> intend to pass you over, despite my eagerness in reworking=20
> the plugin
> >> ;-) Of course, such a plugin shipped with Spring would=20
> still accredit
> >> the original idea and implementation to you. I just=20
> 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.=20
> And as this
> >> is about so little but very useful code, I feel that=20
> including it in
> >> Spring itself is a viable option, particularly given that=20
> Struts 1.1
> >> and the upcoming 1.2 will be around for quite some time to=20
> 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=20
> 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=20
> approach (as two
> >> alternative ways). And as there are already enough projects to
> >> combine for typical users, I suggest to include those=20
> 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=20
> reworked versions
> >> into the Struts Spring Plugin project, or possibly host=20
> 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...=20
> 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=20
> might want to=20
> >> know about:
> >>
> >> How to use the SpringPlugin:
> >>
> >> 1.  Put nothing to initialize Spring in web.xml.  Use the=20
> Plugin to=20
> >> do this.
> >>    - Specifying a "beansConfig" path will load it from a=20
> 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
> >> ContextLoaderServlet)
> >>    in web.xml and put nothing in struts-config.xml.
> >>   Note that only #1 will work if you are using=20
> MockStrutsTestCase to=20
> >> test your actions.  IMO, this is quite powerful b/c you=20
> can use it to=20
> >> 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=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=20
> refining Don=20
> >>> Brown's Struts Spring Plugin. That reminded me that I've=20
> repeatedly
> >>> considered
> >>> including something like this Plugin in the main Spring=20
> distribution.
> >>> Particularly if it is just two classes, I don't have worries about
> >>> size and
> >>> scope. A main benefit is that it would be available out-of-the-box
> >>> with
> >>> Spring, just like all the integrated data access and view
> >>> technologies.
> >>>
> >>> Actually, I intend to completely rework the Plugin far beyond its=20
> >>> current implementation. It should properly have its own
> >>> XmlWebApplicationContext, by
> >>> default loaded from "/WEB-INF/<servlet-name>.xml", having=20
> 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=20
> >>> corresponding Actions in struts-config.xml. Simply don't=20
> use <bean=20
> >>> 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=20
> >>> setting the ActionServlet can be significantly optimized.=20
> Actually,=20
> >>> I consider the
> >>> current implementation unsafe: It first sets the ActionServlet on
> >>> the located
> >>> Action (a shared instance) and then resets it to null=20
> again (on each
> >>> execution!). This is not at all thread-safe.
> >>>
> >>> If noone objects, I'll come up with an optimized=20
> implementation for=20
> >>> the standard Spring codebase within the next couple of=20
> days. We're=20
> >>> 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=20
> 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=20
> >> http://promotions.yahoo.com/design_giveaway/
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.Net email is sponsored by: IBM Linux Tutorials
> >> Free Linux tutorial presented by Daniel Robbins, President=20
> and CEO of=20
> >> GenToo technologies. Learn everything from fundamentals to system=20
> >>=20
> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dcli=
ck
> >> _______________________________________________
> >> Springframework-developer mailing list=20
> >> Spr...@li...
> >>=20
> https://lists.sourceforge.net/lists/listinfo/s>
pringframework-develope
> >> r
> >>
> >>
> >>
>=20
>=20
>=20
> -------------------------------------------------------
> 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=20
> fundamentals to system=20
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20
>=20
>=20
>=20
> -------------------------------------------------------
> 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=20
> fundamentals to system=20
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list=20
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>=20

[Springframework-developer] BeanWrapperImpl and PropertyEditors: possible extension?

[SimonG <Sim...@gm...>]

BeanWrapperImpl javadoc states that applications can register
PropertyEditors either on PropertyEditorManager or by means of registerCustomEditor(). I
see two problems with the current functionality:
1) PropertyEditorManager: First of all, this might not be an option in a
restircted environment. Also it only provides the possibility to specify a
PropertyEditor per type, and not per property.
2) custom editor: 
Potentially many BeanWrapperImpl instances have to be "initialized" with
PropertyEditors, especially if different bean hierarchies are used.

As the BeanWrapper already uses PropertyEditors anyway, we could consult the
wrapped bean's PropertyEditor in it's doFindCustomEditor() method like this:
   PropertyDescriptor propertyDescriptor =
getPropertyDescriptor(propertyName);
   Class editorClass = propertyDescriptor.getPropertyEditorClass();
   ...

This approach is not completely satisfying though for two reasons:
1) only classes and no (customizable) instances of PropertyEditors can be
registered
2) it uses a singleton registry (which is even shared by all applications in
a container environment)

I think it would be very useful if one could pass a configuration object to
the BeanWrapperImpl, from where it could find out which PropertyEditors to
use for which class and property. If the mapping of property to PropertyEditor
would be independent of the property-path, this configuration object could
even be used for all BeanWrapperImpls independent of the type of their "wrapped
bean".

Wonder what you think

Simon

-- 
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/info

Re: [Springframework-developer] Struts Spring Plugin

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

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

Matt

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

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

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

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

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

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

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

> von Matt Raible
> Gesendet: Mi 07.04.2004 04:37
> An: spr...@li...; Don Brown
> Betreff: Re: [Springframework-developer] Re: Struts Spring Plugin
>
>
>
> I'm in agreement with Don here.  I'm just looking for the best/easiest
> solution to integrate the two.  When I first looked at this plugin, I
> didn't like the fact that I had to declare my Action twice (once in
> struts-config.xml and once in applicationContext.xml).  However, the
> fact that I could use MockStrutsTestCase, as well as set my Managers
> declaratively on my Actions made me really like it.  I'd like a
> minimal-intrusion mechanism, but I'm willing to do whatever you feel =
is
> best.  By minimal-intrusion, I mean I'd like to use an existing Action
> with very little or no changes - only some tweaking in an XML file.  I
> don't know if that's possible.
>
> Matt
>
>
> On Apr 6, 2004, at 5:37 PM, Don Brown wrote:
>
>> I like your approach and think it is much stronger solution to Struts
>> and Spring integration.   To be honest, I don't really have any plans
>> for the plugin so feel free to improve it as you see fit.  I put the
>> plugin out there to hopefully spark interest in integrating the two
>> projects closer, and I'd glad to see that progressing.  Let me know =
if
>> I can be of help, but please keep me informed as I'm anxious to see
>> where else Spring might be useful, particularly in Struts itself.
>>
>> Don
>>
>> j=FCrgen h=F6ller [werk3AT] wrote:
>>
>>> Matt, Don, Rod, all,
>>> We need to thoroughly consider this. I guess I've been a bit too
>>> eager in wanting the Struts plugin to get into the Spring main
>>> project ASAP (but that's me, can't do anything about it) ;-)
>>> My starting point is a recent discussion via private email that
>>> resulted in variations on how to integrate Struts with Spring. As a
>>> result, I've got two support classes lying around now, namely
>>> ActionSupport and DispatchActionSupport, providing easy access to =
the
>>> Spring root application context (and to other goodies like a
>>> MessageSourceAccessor), similar to the Tiles
>>> ComponentControllerSupport and JAX-RPC ServletEndpointSupport =
classes
>>> that we already ship with Spring. As with the latter, those two
>>> Struts Action support classes are not wired by Spring themselves but
>>> rather allow for access to a Spring context. The Actions themselves
>>> are still set up in the usual way in struts-config.xml.
>>> I believe that such Struts Action support classes are a valuable and
>>> straightforward addition to similar integration classes that we
>>> already ship, particularly if a variety of Spring ApplicationContext
>>> functionality needs to be used in an Action implementation. As =
Struts
>>> is currently the most important third-party web framework that =
Spring
>>> needs to integrate with, it's an obvious option to ship those two
>>> classes with the Spring distribution. Note that we ship the Struts
>>> jars with Spring anyway, for our Tiles integration and for the =
Struts
>>> web tier of JPetStore, so this doesn't introduce any new
>>> dependencies.
>>> That was when I noticed the planned reworking of Don's Spring Struts
>>> Plugin on Matt's blog. The original idea of the plugin is different
>>> to the "make the Spring context accessible" approach outlined above:
>>> I do consider it a valuable alternative, if one wants to actually
>>> wire the Struts Actions *themselves* as Spring-managed beans. As =
this
>>> just involves two rather simple classes, a context loader PlugIn and
>>> a delegating Action proxy, inclusion in Spring can be considered =
here
>>> too, just like with the two Action support classes above. Of course,
>>> we all need to agree on this; sorry for me shooting forward
>>> overeagerly here.
>>> Regarding the implementation of the plugin approach, I see the
>>> potential for a variety of improvements: most importantly, using an
>>> XmlWebApplicationContext rather than an XmlBeanFactory for hosting
>>> the plugin context (similar to Spring's own DispatcherServlet), and
>>> automatically wiring it with the Spring root application context (if
>>> any). This would allow for defining the Struts Actions in the plugin
>>> context, referencing beans in the root web application context from
>>> there. IMO, this is important for clear layering: web tier =
components
>>> (Struts Actions) are defined in the plugin context, middle tier
>>> components remain in the root web application context (same as with
>>> Spring's own web MVC). struts-config simply delegates to the Actions
>>> in the plugin context.
>>> Furthermore, the naming of the Actions in the plugin context can now
>>> match the Struts Action names in struts-config in a literal fashion,
>>> by using <bean name=3D"..."> rather than <bean id=3D"...">. Such =
alias
>>> names can contain any special characters like slashes, so names like
>>> "/login" or "/module/login" are possible. I believe that keeping
>>> these names in sync is more intuitive than stripping the leading
>>> slash off or replacing slashes with underscores. This simply wasn't
>>> possible in the early Spring milestones that the original plugin was
>>> written for, but I think it's the most viable way now.
>>> An important point for thread safety is the passing of the
>>> ActionServlet to the Spring-wired Action instances. This currently
>>> happens in the SpringAction proxy, but unfortunately in a
>>> non-thread-safe manner (if I grasp it correctly). A preferable way =
is
>>> to register a corresponding BeanPostProcessor with the BeanFactory
>>> that wires the Actions, passing the ActionServlet to Actions at bean
>>> initialization time. In general, this works very similar to a Spring
>>> FrameworkServlet/DispatcherServlet; it's quite easy to keep these
>>> classes analogous and consistent.
>>> I did a clean-room implementation of this plugin idea yesterday, and
>>> it worked out nicely. ContextLoaderPlugIn is the equivalent of
>>> Spring's FrameworkServlet, loading a ActionServlet-specific context,
>>> by default from "<servlet-name>-servlet.xml" (just like with
>>> DispatcherServlet). DelegatingActionProxy is a small Action
>>> implementation that delegates to the Spring-wired Action of the same
>>> name. These classes correspond to the original SpringPlugIn and
>>> SpringAction, respectively. Note that ContextLoaderPlugIn supports
>>> all the configuration options of FrameworkServlet, including
>>> "contextConfigLocation", and automatically takes the Spring root
>>> application context as parent (just like FrameworkServlet).
>>> In total, I now have the two Action support classes from above
>>> (ActionSupport, DispatchActionSupport), plus the two classes for the
>>> plugin approach (ContextLoaderPlugIn, DelegatingActionProxy). The
>>> question is: Should we include them in the Spring main distribution,
>>> should we update the Struts Spring Plugin project with them, or
>>> should we scrap them? ;-) As we're talking about 4 small classes =
here
>>> (2 for the plugin approach), I tend to want to include in the Spring
>>> distro, as that little code doesn't seem like a good candidate for a
>>> separate project. As I understand, Matt seems to agree in that
>>> respect.
>>> Most importantly: Don, what do you think about this? I do by no =
means
>>> intend to pass you over, despite my eagerness in reworking the =
plugin
>>> ;-) Of course, such a plugin shipped with Spring would still =
accredit
>>> the original idea and implementation to you. I just believe that the
>>> reworked versions are significantly more powerful and flexible than
>>> the originals, leveraging all that Spring can offer for Struts at
>>> this point of time, similar to Spring's FrameworkServlet. And as =
this
>>> is about so little but very useful code, I feel that including it in
>>> Spring itself is a viable option, particularly given that Struts 1.1
>>> and the upcoming 1.2 will be around for quite some time to come, and
>>> be a dominant web framework choice in combination with a
>>> Spring-managed middle tier.
>>> I understand that Struts 2.0 might be a different matter, providing
>>> its own means of Spring integration, but I assume that referencing
>>> Spring beans should then be possible in the Struts config file =
itself
>>> (similar to XWork's external reference mechanism) rather than with
>>> the proxy/delegation approach of the current plugin. I consider the
>>> current Struts integration classes as solutions for Struts 1.1 and
>>> 1.2, both the Action support classes and the plugin approach (as two
>>> alternative ways). And as there are already enough projects to
>>> combine for typical users, I suggest to include those classes in the
>>> Spring distribution, in up-to-date versions.
>>> Of course, I don't want to interfere with other plans of
>>> Struts/Spring integration. We can also integrate my reworked =
versions
>>> into the Struts Spring Plugin project, or possibly host the code in =
a
>>> separate module within the main Spring project (spring-struts?
>>> spring-integration?). I'm open for suggestions. What does everybody
>>> think? Feedback welcome :-)
>>> Regards,
>>> Juergen
>>>
>>> ________________________________
>>>
>>> Von: spr...@li... im =
Auftrag
>>> von Matt Raible
>>> Gesendet: Mo 05.04.2004 22:19
>>> An: spr...@li...
>>> Cc: str...@li...
>>> Betreff: [Springframework-developer] Re: Struts Spring Plugin
>>>
>>>
>>>
>>> Juergen,
>>>
>>> That's funny - I was just talking with Don about refactoring some
>>> stuff.  Good
>>> timing!
>>> +1 for moving it to Spring's repository where it belongs.
>>>
>>> I made a few changes today (just checked them in) you might want to
>>> know about:
>>>
>>> How to use the SpringPlugin:
>>>
>>> 1.  Put nothing to initialize Spring in web.xml.  Use the Plugin to
>>> do this.
>>>    - Specifying a "beansConfig" path will load it from a custom =
path.
>>>    - No path will default to "/WEB-INF/applicationContext.xml".
>>>    - If your webapp has multiple config files - use #2 below or
>>> specify
>>>      a "contextConfigLocation" variable as a <context-param> in
>>> web.xml.
>>>      The values for this parameter should be comma-delimited.
>>>   2.  Put Spring initializers (ContextLoaderListener or
>>> ContextLoaderServlet)
>>>    in web.xml and put nothing in struts-config.xml.
>>>   Note that only #1 will work if you are using MockStrutsTestCase to
>>> test your
>>> actions.  IMO, this is quite powerful b/c you can use it to test =
your
>>> Struts
>>> Actions w/o a container.
>>>
>>> I've cc'd the struts-apps mailing list so Don Brown (the original
>>> author) can
>>> help us make this transition.
>>>
>>> Matt
>>>
>>> P.S.  Since SF's anonymous CVS takes a while to catch up, I've
>>> uploaded the
>>> latest source to
>>> http://static.raibledesigns.com/downloads/struts-spring-0.3.zip.
>>> It's a 6 MB
>>> download b/c of the refactored struts-example app.
>>>
>>> --- j=FCrgen_h=F6ller_[werk3AT] <jue...@we...> wrote:
>>>
>>>> Matt,
>>>>
>>>> I've just read that on the Spring Live blog that you're refining =
Don
>>>> Brown's
>>>> Struts Spring Plugin. That reminded me that I've repeatedly
>>>> considered
>>>> including something like this Plugin in the main Spring =20
>>>> distribution.
>>>> Particularly if it is just two classes, I don't have worries about
>>>> size and
>>>> scope. A main benefit is that it would be available out-of-the-box
>>>> with
>>>> Spring, just like all the integrated data access and view
>>>> technologies.
>>>>
>>>> Actually, I intend to completely rework the Plugin far beyond its
>>>> current
>>>> implementation. It should properly have its own
>>>> XmlWebApplicationContext, by
>>>> default loaded from "/WEB-INF/<servlet-name>.xml", having the =
Spring
>>>> root
>>>> application context (if any) as parent, just like a Spring
>>>> DispatcherServlet.
>>>>
>>>> The beans in the Spring context can have the same name as the
>>>> corresponding
>>>> Actions in struts-config.xml. Simply don't use <bean id=3D"..."/> =
but
>>>> rather
>>>> <bean name=3D"..."/>, which allows any special characters like in
>>>> "/logon.do".
>>>> The original Plugin was written against Spring 1.0 M1 where this
>>>> wasn't
>>>> available, IIRC.
>>>>
>>>> SpringAction's looking up of the corresponding Spring bean and
>>>> setting the
>>>> ActionServlet can be significantly optimized. Actually, I consider
>>>> the
>>>> current implementation unsafe: It first sets the ActionServlet on
>>>> the located
>>>> Action (a shared instance) and then resets it to null again (on =
each
>>>> execution!). This is not at all thread-safe.
>>>>
>>>> If noone objects, I'll come up with an optimized implementation for
>>>> the
>>>> standard Spring codebase within the next couple of days. We're =
about
>>>> to
>>>> release Spring 1.0.1 next week, and I'd be willing to already
>>>> include this
>>>> special Struts support in that release, if the stuff is as simple =
as
>>>> I assume
>>>> (or in 1.0.2, if it takes longer).
>>>>
>>>> Juergen
>>>>
>>>>
>>>>
>>>>
>>>
>>> __________________________________
>>> Do you Yahoo!?
>>> Yahoo! Small Business $15K Web Design Giveaway
>>> http://promotions.yahoo.com/design_giveaway/
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by: IBM Linux Tutorials
>>> Free Linux tutorial presented by Daniel Robbins, President and CEO =
of
>>> GenToo technologies. Learn everything from fundamentals to system
>>> =
administration.http://ads.osdn.com/?ad_id=3D1470&alloc_id=3D3638&op=3Dclic=
k
>>> _______________________________________________
>>> Springframework-developer mailing list
>>> Spr...@li...
>>> https://lists.sourceforge.net/lists/listinfo/springframework-=20
>>> developer
>>>
>>>
>>>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=3Dick
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IBM Linux Tutorials
> Free Linux tutorial presented by Daniel Robbins, President and CEO of
> GenToo technologies. Learn everything from fundamentals to system
> administration.http://ads.osdn.com/?ad_id=1470&alloc_id638&op=CCk
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] proposal for jstlview

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

Seth Ladd wrote:
> Hello,
> 
> I looked through the code for JstlView, and it does not set the 
> content-type passed to it via AbstractView.  The javadocs for 
> setContentType state that it might be ignored by subclasses.
> 
> I'd like to propose that JstlView ignores that value if its null, or if 
> not null, it should use it.  I think it makes sense that if 
> setContentType is called to a View, then the View should use it.  If 
> it's null, then go ahead and ignore it.  Is that a fair request?

Ahh... never mind, I see why it is ignored.  It seems that even if you 
set response.setContentType(), the JSP will ignore it and look for the 
content type given in the <%@ page %> declaration.

sigh

Thanks, though,
Seth

[Springframework-developer] proposal for jstlview

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

Hello,

I looked through the code for JstlView, and it does not set the 
content-type passed to it via AbstractView.  The javadocs for 
setContentType state that it might be ignored by subclasses.

I'd like to propose that JstlView ignores that value if its null, or if 
not null, it should use it.  I think it makes sense that if 
setContentType is called to a View, then the View should use it.  If 
it's null, then go ahead and ignore it.  Is that a fair request?

I can easily provide a patch if others agree with this.

Thanks!
Seth

Re: [Springframework-developer] Portlet and JSFs

[William G. T. Jr. <wg...@ru...>]

Ben Alex wrote:
> Hi Bill
> 
> 
>>Rutgers is very interested in Spring support for the Portlet 
>>API in the form of a PortletDispatcher as it were.  We run 
>>the uPortal[1] platform and the latest release embeds Pluto.  
>>We are just now embarking on dev cycle for new porlets that 
>>takes us thru september, if possible these new portlets would 
>>live behind a Spring PortletDispatcher.
>>
>>We have had some preliminary dicussions with Alef about what 
>>it might look like, and should be in a better positition to 
>>try out some ideas/code in a few weeks.
> 
> 
> I took a look at uPortal but wondered how hard it would be to get Spring MVC
> capabilities living within a portlet window. Have you actually done anything
> like this as yet, or are your Spring applications essentially "traditional"
> (dedicated JSP/VM etc)?
> 

So far all of our Spring apps are "traditional"; leveraging the full 
compliment of the Spring stack (WebMVC, DAO, JDBC Abstraction, 
ApplicationContext, declaritive transaction management, AOP, etc.) and 
living in a dedicated Servlet context.

We have used Spring DAO/JDBC support for a few simple Channels 
(Portlets), but that is the extent of it.

We are extremely pleased with the Spring development model and would 
like to bring our portal project in line.

I don't think it should be too hard to bring SerlvetDispatcher behavior 
to the Portlet API.  The big difference is that Portlets participated in 
a two step call (ActionRequest/Response and RenderRequest/Response) and 
also have additional lifecycle events, PortletMode (View, Edit, 
Help,...) and WindowMode (min, max, normal, etc.) that impact behavior 
of the service.

later.
Bill

Re: RE: [Springframework-developer] Portlet and JSFs

[Dmitriy K. <dko...@ru...>]

Ben,

currently our Spring apps are traditional n-tier web apps (Spring MVC/middle tier IoC managed/DAOs). Eventually they would have to be available behind Portlet API.

Alef, did you make any progress with Portlet API support?

Regards,
Dmitriy.

----- Original Message -----
From: Ben Alex <ben...@ac...>
Date: Friday, April 9, 2004 5:55 pm
Subject: RE: [Springframework-developer] Portlet and JSFs

> Hi Bill
> 
> > Rutgers is very interested in Spring support for the Portlet 
> > API in the form of a PortletDispatcher as it were.  We run 
> > the uPortal[1] platform and the latest release embeds Pluto.  
> > We are just now embarking on dev cycle for new porlets that 
> > takes us thru september, if possible these new portlets would 
> > live behind a Spring PortletDispatcher.
> > 
> > We have had some preliminary dicussions with Alef about what 
> > it might look like, and should be in a better positition to 
> > try out some ideas/code in a few weeks.
> 
> I took a look at uPortal but wondered how hard it would be to get 
> Spring MVC
> capabilities living within a portlet window. Have you actually 
> done anything
> like this as yet, or are your Spring applications essentially 
> "traditional"(dedicated JSP/VM etc)?
> 
> Best regards
> Ben
> 
> 
> 
> -------------------------------------------------------
> 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] Portlet and JSFs

[Ben A. <ben...@ac...>]

Hi Bill

> Rutgers is very interested in Spring support for the Portlet 
> API in the form of a PortletDispatcher as it were.  We run 
> the uPortal[1] platform and the latest release embeds Pluto.  
> We are just now embarking on dev cycle for new porlets that 
> takes us thru september, if possible these new portlets would 
> live behind a Spring PortletDispatcher.
> 
> We have had some preliminary dicussions with Alef about what 
> it might look like, and should be in a better positition to 
> try out some ideas/code in a few weeks.

I took a look at uPortal but wondered how hard it would be to get Spring MVC
capabilities living within a portlet window. Have you actually done anything
like this as yet, or are your Spring applications essentially "traditional"
(dedicated JSP/VM etc)?

Best regards
Ben

Re: [Springframework-developer] Struts Spring Plugin

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

I've just finished the new Struts integration classes, now in the =
org.springframework.web.struts package, including a corresponding test =
suite.
=20
For the "proxy delegates to Spring-managed Action" approach, there are =
ContextLoaderPlugIn and DelegatingActionProxy (corresponding to the =
original SpringPlugIn and SpringAction classes, respectively). The =
former is analogous to FrameworkServlet in its context-loading =
capabilities, loading from "/WEB-INF/<servlet-name>-servlet.xml" by =
default (using the servlet-name of the Struts ActionServlet), supporting =
a "contextConfigLocation" property.
=20
A ContextLoaderPlugIn context will automatically refer to the root =
application context (loaded by ContextLoaderListener/Servlet) as parent, =
if any, just like FrameworkServlet. Action beans defined there receive =
the ActionServlet via a corresponding BeanPostProcessor, also resetting =
the servlet reference to null on destruction.
=20
For the "Action has easy access to a Spring context" approach, there are =
the ActionSupport and DispatchActionSupport classes, providing =
convenient getWebApplicationContext etc methods. Both will first check =
for a ContextLoaderPlugIn context, then fall back to the root web =
application context. The latter should be the typical usage, making =
middle tier beans available to any web component.
=20
Matt, can you please give these classes a try, possibly till early next =
week? They should be as easy to use as the original Spring Struts =
Plugin, but offer more powerful and flexible options. The javadocs =
should hopefully clarify usage and configuration options.
=20
I wonder what to do about the adapted Struts sample app from the Spring =
Struts Plugin distribution: Might it be worthwhile to deprecate the =
original plugin itself but provide a revamped version of the sample app =
within the Struts Apps project, using Spring's new integration classes =
now?
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Matt Raible
Gesendet: Mi 07.04.2004 04:37
An: spr...@li...; Don Brown
Betreff: Re: [Springframework-developer] Re: Struts Spring Plugin



I'm in agreement with Don here.  I'm just looking for the best/easiest
solution to integrate the two.  When I first looked at this plugin, I
didn't like the fact that I had to declare my Action twice (once in
struts-config.xml and once in applicationContext.xml).  However, the
fact that I could use MockStrutsTestCase, as well as set my Managers
declaratively on my Actions made me really like it.  I'd like a
minimal-intrusion mechanism, but I'm willing to do whatever you feel is
best.  By minimal-intrusion, I mean I'd like to use an existing Action
with very little or no changes - only some tweaking in an XML file.  I
don't know if that's possible.

Matt


On Apr 6, 2004, at 5:37 PM, Don Brown wrote:

> I like your approach and think it is much stronger solution to Struts
> and Spring integration.   To be honest, I don't really have any plans
> for the plugin so feel free to improve it as you see fit.  I put the
> plugin out there to hopefully spark interest in integrating the two
> projects closer, and I'd glad to see that progressing.  Let me know if
> I can be of help, but please keep me informed as I'm anxious to see
> where else Spring might be useful, particularly in Struts itself.
>
> Don
>
> j=FCrgen h=F6ller [werk3AT] wrote:
>
>> Matt, Don, Rod, all,
>> We need to thoroughly consider this. I guess I've been a bit too
>> eager in wanting the Struts plugin to get into the Spring main
>> project ASAP (but that's me, can't do anything about it) ;-)
>> My starting point is a recent discussion via private email that
>> resulted in variations on how to integrate Struts with Spring. As a
>> result, I've got two support classes lying around now, namely
>> ActionSupport and DispatchActionSupport, providing easy access to the
>> Spring root application context (and to other goodies like a
>> MessageSourceAccessor), similar to the Tiles
>> ComponentControllerSupport and JAX-RPC ServletEndpointSupport classes
>> that we already ship with Spring. As with the latter, those two
>> Struts Action support classes are not wired by Spring themselves but
>> rather allow for access to a Spring context. The Actions themselves
>> are still set up in the usual way in struts-config.xml.
>> I believe that such Struts Action support classes are a valuable and
>> straightforward addition to similar integration classes that we
>> already ship, particularly if a variety of Spring ApplicationContext
>> functionality needs to be used in an Action implementation. As Struts
>> is currently the most important third-party web framework that Spring
>> needs to integrate with, it's an obvious option to ship those two
>> classes with the Spring distribution. Note that we ship the Struts
>> jars with Spring anyway, for our Tiles integration and for the Struts
>> web tier of JPetStore, so this doesn't introduce any new
>> dependencies.
>> That was when I noticed the planned reworking of Don's Spring Struts
>> Plugin on Matt's blog. The original idea of the plugin is different
>> to the "make the Spring context accessible" approach outlined above:
>> I do consider it a valuable alternative, if one wants to actually
>> wire the Struts Actions *themselves* as Spring-managed beans. As this
>> just involves two rather simple classes, a context loader PlugIn and
>> a delegating Action proxy, inclusion in Spring can be considered here
>> too, just like with the two Action support classes above. Of course,
>> we all need to agree on this; sorry for me shooting forward
>> overeagerly here.
>> Regarding the implementation of the plugin approach, I see the
>> potential for a variety of improvements: most importantly, using an
>> XmlWebApplicationContext rather than an XmlBeanFactory for hosting
>> the plugin context (similar to Spring's own DispatcherServlet), and
>> automatically wiring it with the Spring root application context (if
>> any). This would allow for defining the Struts Actions in the plugin
>> context, referencing beans in the root web application context from
>> there. IMO, this is important for clear layering: web tier components
>> (Struts Actions) are defined in the plugin context, middle tier
>> components remain in the root web application context (same as with
>> Spring's own web MVC). struts-config simply delegates to the Actions
>> in the plugin context.
>> Furthermore, the naming of the Actions in the plugin context can now
>> match the Struts Action names in struts-config in a literal fashion,
>> by using <bean name=3D"..."> rather than <bean id=3D"...">. Such =
alias
>> names can contain any special characters like slashes, so names like
>> "/login" or "/module/login" are possible. I believe that keeping
>> these names in sync is more intuitive than stripping the leading
>> slash off or replacing slashes with underscores. This simply wasn't
>> possible in the early Spring milestones that the original plugin was
>> written for, but I think it's the most viable way now.
>> An important point for thread safety is the passing of the
>> ActionServlet to the Spring-wired Action instances. This currently
>> happens in the SpringAction proxy, but unfortunately in a
>> non-thread-safe manner (if I grasp it correctly). A preferable way is
>> to register a corresponding BeanPostProcessor with the BeanFactory
>> that wires the Actions, passing the ActionServlet to Actions at bean
>> initialization time. In general, this works very similar to a Spring
>> FrameworkServlet/DispatcherServlet; it's quite easy to keep these
>> classes analogous and consistent.
>> I did a clean-room implementation of this plugin idea yesterday, and
>> it worked out nicely. ContextLoaderPlugIn is the equivalent of
>> Spring's FrameworkServlet, loading a ActionServlet-specific context,
>> by default from "<servlet-name>-servlet.xml" (just like with
>> DispatcherServlet). DelegatingActionProxy is a small Action
>> implementation that delegates to the Spring-wired Action of the same
>> name. These classes correspond to the original SpringPlugIn and
>> SpringAction, respectively. Note that ContextLoaderPlugIn supports
>> all the configuration options of FrameworkServlet, including
>> "contextConfigLocation", and automatically takes the Spring root
>> application context as parent (just like FrameworkServlet).
>> In total, I now have the two Action support classes from above
>> (ActionSupport, DispatchActionSupport), plus the two classes for the
>> plugin approach (ContextLoaderPlugIn, DelegatingActionProxy). The
>> question is: Should we include them in the Spring main distribution,
>> should we update the Struts Spring Plugin project with them, or
>> should we scrap them? ;-) As we're talking about 4 small classes here
>> (2 for the plugin approach), I tend to want to include in the Spring
>> distro, as that little code doesn't seem like a good candidate for a
>> separate project. As I understand, Matt seems to agree in that
>> respect.
>> Most importantly: Don, what do you think about this? I do by no means
>> intend to pass you over, despite my eagerness in reworking the plugin
>> ;-) Of course, such a plugin shipped with Spring would still accredit
>> the original idea and implementation to you. I just believe that the
>> reworked versions are significantly more powerful and flexible than
>> the originals, leveraging all that Spring can offer for Struts at
>> this point of time, similar to Spring's FrameworkServlet. And as this
>> is about so little but very useful code, I feel that including it in
>> Spring itself is a viable option, particularly given that Struts 1.1
>> and the upcoming 1.2 will be around for quite some time to come, and
>> be a dominant web framework choice in combination with a
>> Spring-managed middle tier.
>> I understand that Struts 2.0 might be a different matter, providing
>> its own means of Spring integration, but I assume that referencing
>> Spring beans should then be possible in the Struts config file itself
>> (similar to XWork's external reference mechanism) rather than with
>> the proxy/delegation approach of the current plugin. I consider the
>> current Struts integration classes as solutions for Struts 1.1 and
>> 1.2, both the Action support classes and the plugin approach (as two
>> alternative ways). And as there are already enough projects to
>> combine for typical users, I suggest to include those classes in the
>> Spring distribution, in up-to-date versions.
>> Of course, I don't want to interfere with other plans of
>> Struts/Spring integration. We can also integrate my reworked versions
>> into the Struts Spring Plugin project, or possibly host the code in a
>> separate module within the main Spring project (spring-struts?
>> spring-integration?). I'm open for suggestions. What does everybody
>> think? Feedback welcome :-)
>> Regards,
>> Juergen
>>
>> ________________________________
>>
>> Von: spr...@li... im Auftrag
>> von Matt Raible
>> Gesendet: Mo 05.04.2004 22:19
>> An: spr...@li...
>> Cc: str...@li...
>> Betreff: [Springframework-developer] Re: Struts Spring Plugin
>>
>>
>>
>> Juergen,
>>
>> That's funny - I was just talking with Don about refactoring some
>> stuff.  Good
>> timing!
>> +1 for moving it to Spring's repository where it belongs.
>>
>> I made a few changes today (just checked them in) you might want to
>> know about:
>>
>> How to use the SpringPlugin:
>>
>> 1.  Put nothing to initialize Spring in web.xml.  Use the Plugin to
>> do this.
>>    - Specifying a "beansConfig" path will load it from a custom path.
>>    - No path will default to "/WEB-INF/applicationContext.xml".
>>    - If your webapp has multiple config files - use #2 below or
>> specify
>>      a "contextConfigLocation" variable as a <context-param> in
>> web.xml.
>>      The values for this parameter should be comma-delimited.
>>   2.  Put Spring initializers (ContextLoaderListener or
>> ContextLoaderServlet)
>>    in web.xml and put nothing in struts-config.xml.
>>   Note that only #1 will work if you are using MockStrutsTestCase to
>> test your
>> actions.  IMO, this is quite powerful b/c you can use it to test your
>> Struts
>> Actions w/o a container.
>>
>> I've cc'd the struts-apps mailing list so Don Brown (the original
>> author) can
>> help us make this transition.
>>
>> Matt
>>
>> P.S.  Since SF's anonymous CVS takes a while to catch up, I've
>> uploaded the
>> latest source to
>> http://static.raibledesigns.com/downloads/struts-spring-0.3.zip.=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
>>> 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
>>
>>
>>



-------------------------------------------------------
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] commons-validator adapter

[Keith D. <kd...@cs...>]

Juergen,

The core rule interfaces and "building block" classes amount to about =
50K
total.  Most of that is weighted towards the convenience factory =
methods. =20

I don't anticipate that increasing more.  If we just wanted to include =
the
interfaces, we could get it down to about 15K or so.  The advantage of
making those core is they could be more easily reused in different parts =
of
the framework, because they really could be useful in general (any kind =
of
reusable function object could implement one of the Predicate/Function
interfaces, for example, and used for things like filters/pipes, for =
doing
extended bean definition property conversion & validation...or filtering
collections, or whatever...)

However, I agree, various rule implementations we and the user community
develop over time and integrate back will likely grow the library.  For
example, adding the Email Validator, the Date Validator, the Credit Card
Validator, the this-or-that validator.  And I agree the =
commons-validator
adapter should probably be separate from the core as well, since we'll =
be
offering something of our own.

Does it make sense to have part core and the part we anticipate growing =
over
time in a 'rules' (or something like that) subproject?  Or should we =
just
move everything over to a subproject for now, and if we decide that =
parts
are generally useful, factor them into the core at some later point?  I =
am
OK with either approach, the only concern I have about the latter is
isolating some generally useful stuff from the core framework and not =
taking
advantage simplfy b/c it might not get the same level of review.  Of =
course
the argument could be made that maybe it's better that the design prove
itself first.

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
j=FCrgen h=F6ller [werk3AT]
Sent: Friday, April 09, 2004 1:44 AM
To: spr...@li...
Subject: Re: [Springframework-developer] commons-validator adapter


Keith,
=20
As the rules / declarative validation support is already becoming quite
extensive, I wonder whether it is worth creating an own subproject for =
it
(just like "spring-rcp"), maybe "spring-validation" (possibly getting =
the
word "declarative" in too)?
=20
Of course, the basic validation and binding infrastructure should remain =
in
the core Spring codebase. What I consider is to move all extended =
validation
support to a separate subproject. This would also include =
commons-validator
support, and possible future extensions.
=20
In terms of jar file sizes, the extended validation support in the =
sandbox
already amounts to more than 90 KB. I'd expect that people might request =
or
contribute more and more convenience rules over time, so I can imagine =
that
this will grow towards 150 KB or even more.
=20
My basic rule is that everything that's in the core Spring codebase goes
into spring.jar, which should cover typical usage scenarios. It's hard =
to
decide what goes in there, but I'm keen on not growing this =
significantly
beyond 1 MB. Things that have their own potential for rapid growth =
should
not go into the core.
=20
JMX and JMS support are definite candidates for the core, as they are =
rather
small, and I don't see the potential for extensive growth beyond the =
initial
versions there (in terms of size). Declarative validation on the other =
hand
has the potential to become a whole framework itself.
=20
What do you think? This would already give you two Spring subprojects =
then,
but hey, your output demands it ;-) Note that this would also allow for =
a
separate release schedule for the declarative validation project, just =
like
with the Rich Client Platform.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von
Keith Donald
Gesendet: Fr 09.04.2004 00:54
An: spr...@li...
Betreff: RE: [Springframework-developer] Re: commons-validator adapter



Since the purpose of this package is really to support the definition of
declarative rules (like validation rules, transformation/filter rules,
business rules, etc.) just plain old "org.springframework.rules" seems =
to
work.  It's simpler and more concise than expression, and definitely
functor.

I left the term Predicate as is for now, something about =
"BinaryCondition"
just doesn't sound right.  Attached below is a summary of the current =
layout
of the structure.  While there are a good many types, they're _small_ =
and
clients deal primarily with the Rules/PredicateFactory classes for
creating/composing rules (if using programatically), which is similar to
Hibernate's Criteria/Expression API.  Defining your own new rule =
conditions
is simple: just define a new Predicate implementation (which only =
requires
implementing a single test(arg) method.

For example: there is no EmailValidator class yet for validating String
properties that are e-mail addresses. To implement this we say:

public class EmailValidator implements UnaryPredicate {
        public boolean test(Object argument) {
                String email =3D (String)argument;
                return isEmailAddress(email);
        }

        private boolean isEmailAddress(String argument) {
                // the real work....
        }
}

Then, to create a rule that says a property is "required", has a "max
length" of 128 characters, and must be a "email address":

Rules.createRule("emailAddressProperty")
     .add(PredicateFactory.required())
     .add(PredicateFactory.maxLength(128))
     .add(EmailValidator.instance()); =20

The 'add' methods above imply a logical "AND" to all the predicates
(conjunction).   To get fancier, for example, to say that the argument =
is
valid regardless just as long as some other property is present (a =
top-level
OR condition) you can do something like this:

UnaryPredicate rules =3D
        PredicateFactory.or(
                PredicateFactory.
                    conjunction(new UnaryPredicate[] {
PredicateFactory.required(),

PredicateFactory.maxLength(128),

EmailValidator.instance()),
                =
PredicateFactory.propertyPresent("primaryEmailAddress"));

Rules.createRule("emailAddressProperty").add(rules);

That's a bit more complex, but it basically says: "emailAddressProperty =
is
valid if it is required, less than 128 characters, and an email address =
---
OR it's valid regardless as long as the primaryEmailAddress is present.

Just some examples.  This is much more than you can do with
commons-validator! :) Keith

Attached is a break down of the API to date (PLEASE NOTE THIS IS STILL =
VERY
EXPERIMENTAL & SUBJECT TO CHANGE!!!)

org.springframework.rules (your core interfaces and the API/factory for
composing rules programatically.)

Interfaces

BinaryFunction
        Evaluates two arguments and returns a single result.

BinaryPredicate
        Tests two arguments and returns a single boolean result.  A
conditional expression.

UnaryFunction
        Evaluates one argument and returns a single result.

UnaryPredicate
        Tests one argument and returns a single boolean result.  A
conditional expression.

Classes

Rules
        A factory for creating rules.

PredicateFactory
        A factory for easing the construction and composition of =
predicate
conditions.

FunctionFactory
        A factory for easing the construction and composition of =
functions.

LogicalOperator
        Type-safe enums for various conditional or logical operators
(AND/OR)

RelationalOperator
        Type-safe enum class for supported binary operators.

Algorithms
        Convenience utility class which provides a number of algorithms =
that
apply selection rules and filters to collections, for example.


org.springframework.rules.predicates (your rule condition building
blocks...)

BeanPropertyExpression
        A unary predicate that returns the result of a boolean =
expression
that tests two variable bean property values.

ParameterizedBeanPropertyExpression
        A unary predicate that returns the result of a boolean =
expression
that tests a variable bean property value against a constant parameter
value.

EqualTo
        Predicate that tests object equality (not identity.)

ComparisonBinaryPredicate
        Abstract helper superclass for binary predicates involved in
comparison operations.

GreaterThan
        Predicate that tests if one comparable object is greater than
another.

GreaterThanEqualTo
        Predicate that tests if one comparable object is greater than or
equal to another.

LessThan
        Predicate that tests if one comparable object is less than =
another.

LessThanEqualTo
        Predicate that tests if one comparable object is less than or =
equal
to another.

ParameterizedBinaryPredicate
        A unary predicate adapting a binary predicate that uses a
parameterized constant value as the second argument when testing.

UnaryFunctionResultConstraint
        Tests the result returned from evaluating a unary function.

BinaryFunctionResultConstraint
        Tests the result returned from evaluating a binary function =
against
some condition.

UnaryNot
        "Nots" another unary predicate (the inverse) by using =
composition.

CompoundUnaryPredicate
        Abstract base class for unary predicates which compose other
predicates.

UnaryAnd
        A "and" compound predicate (aka conjunction).

UnaryOr
        A "or" compound predicate (aka disjunction).

PropertyPresent
        Predicate that tests if the specified bean property is "present" =
-
that is, passes the "Required" test.

Range
        A range whose edges are defined by a minimum Comparable and a
maximum Comparable.

Required
        Validates a required property.


org.springframework.rules.functions (your "actions" or functions that do
things or execute if a predicate is true...)

Class Summary

GetProperty
        Binary function that gets a bean property.
Maximum
        Returns the maximum of two Comparable objects
Minimum
        Returns the maximum of two Comparable objects. StringLength
        Returns the Integer length of an object's string form, or zero =
if
the object is null. StringTrimmer
        Returns a trimmed copy of the string form of an object.
UnaryFunctionChain
        A chain of unary functions that evaluate their results in an =
ordered
sequence.

The abstract nature of many of the core classes demonstrates the =
"building
block approach" of taking simple little function objects and combining =
them
to create complex rules.  It's a bit different, but certainly
powerful/flexible.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Keith Donald
Sent: Thursday, April 08, 2004 3:02 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Re: commons-validator adapter


ouch, yea I figured that was coming. :-)

"expression" is one suggestion I have.  And to be honest, I'm not really
high on the term Predicate either.  I could rename that "Condition" - or =
we
could adopt Hibernate's Criteria term.

That would result in:
    org.springframework.expression
    org.springframework.expression.conditions
    org.springframework.expression.functions

It is possible to rename "functions" to "actions" as well.  But =
functions
imply a return value...

I'm open to suggestions! Keith


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Rod Johnson
Sent: Thursday, April 08, 2004 3:21 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: commons-validator adapter


functor is truly horrible.

I look forward to looking at this stuff in detail--it sounds cool--but I
think we must be able to find a better name :-)

----- Original Message -----
From: Keith Donald
To: Daniel Miller
Cc: spr...@li...
Sent: Thursday, April 08, 2004 2:44 AM
Subject: [Springframework-developer] Re: commons-validator adapter


Daniel,

The new declarative validation stuff will support both rule definition =
via
source markup via attributes like you said, as well as a xml-based
configuration via Spring IoC.  And there will still be the programmatic
option for configuration (I'm a big believer in having a polished API =
that
works just as well as the config files for those who still prefer that
route.)

I think it's going to be quite powerful, more so than commons-validator, =
and
easier to define new rules.  Right now you can define just about any
validation expression you can think up using the rules API - and complex
expressions (including compound expressions using And/Or/Not logical
operators and all the standard binary operators) are possible.  For =
example,
it's possible to define a rule that says: property "foo" is required if
properties "bar" and "apple" are present, but not if "orange" is =
present. If
those rules change, the API is flexible enough tweak them without having =
to
define a new class all together (the API provides very much a "building
block" approach for composing rules.).  Similiary, you can say that =
property
"foo" must be in the range of properties "lowBar" and "highBar" (or you =
can
parameterize the property expressions and say that "foo" must be in the
constant range of "1" to "255" for example...)

The predicate (rules) API is currently in the sandbox under
src/sandbox/org/springframework/functor (functor might not be the best =
name
for it - I just used it because the design is based on a functional =
style of
programming (heavy on the strategy & chain of responsibility patterns)
illustrated by commons-functor and Object space's JGL...) I think it is
looking pretty good.  The next challenge -- what I am working on now -- =
is
to integrate that API with a easy way of declaratively specifying rules =
in
an external file/source attributes (basically nailing down that format, =
with
emphasis on keeping the amount of config needed concise), and then =
hooking
rule definition up to the validation results reporting classes for
generating internationalized error messages and typing hints when bean
validation occurs at runtime.  More advanced features include the =
ability to
fire validation rules automatically when "constrained" set() methods are
called on a javabean, either using AOP or the built in java-beans
VetoChangeListener support.  The biggest challenge I've found there is
figuring out, based on what rules effect what properties, which rules =
should
fire on which set call.  That's not as easy as it seems when a single =
rule
effects multiple properties.

Keith

----- Original Message -----
From: Daniel Miller
To: Keith Donald
Sent: Wednesday, April 07, 2004 8:35 PM
Subject: RE: commons-validator adapter


Keith,

My viewpoint for now is that if Juergen and Rod approve the code then =
its
probably worth having it. I won't even be upset if it gets moved to a
"spring-plugins" jar as long as it's made available for people to use.

I agree, we should probably refactor them to reuse and share as much =
code
between the commons and attributes validators as possible.

I haven't had time to look at your attributes-based validator at all, so
forgive me if I seem a bit ignorant. From what I understand, this
attributes-based validation requires to be placed in the source code of =
the
classes that would be validated. Is that correct? If so, is there any =
way we
could create an XML configuration option like the Commons-Validator has
(i.e. not dependent on attributes at all)? It would be really cool if it
supported the same XML file format that the Commons-Validator does. What =
do
you think?

I'll keep you posted with any bugs that I find.

Daniel
-----Original Message-----
From: Keith Donald [mailto:kd...@cs...]
Sent: Tuesday, April 06, 2004 12:24 PM
To: 'Daniel Miller'
Subject: RE: commons-validator adapter


Daniel,

No problem.

BTW - I didn't realize those were *struts* classes, I assumed they were
commons-validator.  In that case it's probably going to be best for us =
to
just refactor those classes against our own declarative validation =
support
(which will provide a flexible API for defining rules.)  If you want to =
see
some of the API in development, check out
sandbox/src/org/springframework/functor/PredicateFactory.

I'll keep you posted.  In the meantime if you find any bugs send 'em my =
way.

Thanks,
Keith



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

Re: [Springframework-developer] Portlet and JSFs

[William G. T. Jr. <wg...@ru...>]

Ben Alex wrote:
> Hi
> 
> 
>>JSF and Portlet functionality don't have to be provided in 
>>one and the same release. I have been looking a bit into the 
>>portlet stuff and it doesn't same all that difficult.
>>
>>I think I'll experiment with it during the next couple of 
>>weeks. Major issue is the common supporting functionality 
>>(ContextLoader, WebAppCtx,
>>Databinding) between our Web stuff and our future Portlet 
>>stuff (and probably also the JSF stuff). Revising the 
>>supporting functionality right now (or for 1.1) is not an option imo.
>>
>>I probably can't avoid having to copy-and-paste a lot of code 
>>while experimenting and since that's *not* something we want 
>>to have in a release, I'm afraid you're right :(.
> 
> 
> Several people have previously mentioned portlets and JSF. We are trying to
> decide whether to implement portlets in our next project, or just stick to
> include files and/or something like Sitemesh, Tiles etc.
> 
> Regarding portlets, there is the Pico-based Exo project
> (http://exo.sourceforge.net/) and Pluto (http://jakarta.apache.org/pluto/).
> Has anyone done any work on integrating portlets, JSF or projects such as
> these into Spring? Would anyone be willing and have time to collaborate on
> this?

Rutgers is very interested in Spring support for the Portlet API in the 
form of a PortletDispatcher as it were.  We run the uPortal[1] platform 
and the latest release embeds Pluto.  We are just now embarking on dev 
cycle for new porlets that takes us thru september, if possible these 
new portlets would live behind a Spring PortletDispatcher.

We have had some preliminary dicussions with Alef about what it might 
look like, and should be in a better positition to try out some 
ideas/code in a few weeks.

later.
Bill

[1] http://www.uportal.org/

RE: [Springframework-developer] Portlet and JSFs

[Ben A. <ben...@ac...>]

Hi

> JSF and Portlet functionality don't have to be provided in 
> one and the same release. I have been looking a bit into the 
> portlet stuff and it doesn't same all that difficult.
> 
> I think I'll experiment with it during the next couple of 
> weeks. Major issue is the common supporting functionality 
> (ContextLoader, WebAppCtx,
> Databinding) between our Web stuff and our future Portlet 
> stuff (and probably also the JSF stuff). Revising the 
> supporting functionality right now (or for 1.1) is not an option imo.
> 
> I probably can't avoid having to copy-and-paste a lot of code 
> while experimenting and since that's *not* something we want 
> to have in a release, I'm afraid you're right :(.

Several people have previously mentioned portlets and JSF. We are trying to
decide whether to implement portlets in our next project, or just stick to
include files and/or something like Sitemesh, Tiles etc.

Regarding portlets, there is the Pico-based Exo project
(http://exo.sourceforge.net/) and Pluto (http://jakarta.apache.org/pluto/).
Has anyone done any work on integrating portlets, JSF or projects such as
these into Spring? Would anyone be willing and have time to collaborate on
this?

Best regards
Ben

Re: [Springframework-developer] Preparing for 1.0.1

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

"AbstractPrototypeBasedTargetSource" may be a bit wordy, but I like it, =
as it hits the nail: "prototype-based" is what it is. I've got a new =
favourite :-)

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: Do 08.04.2004 20:21
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



AbstractDynamicTargetSource is OK by me, although I'm not in love with =
it.
Technically of course a dynamic target source need not use the bean =
factory
at all. But AbstractPrototypeBasedTargetSource is a bit wordy...

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, April 08, 2004 5:27 PM
Subject: Re: [Springframework-developer] Preparing for 1.0.1


Final decision here? I still vote for "AbstractDynamicTargetSource"; at
least against "AbstractPrototypeTargetSource".

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Monday, April 05, 2004 9:51 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.0.1


Actually, I still prefer "AbstractDynamicTargetSource": Target beans =
being
defined as prototypes is a requirement for any meaningful dynamic target
source strategy (no matter if one-shot, ThreadLocal or pooled), =
therefore I
consider it fine that AbstractDynamicTargetSource implicitly works with
prototype target beans. But just PrototypeTargetSource delivers actual
one-instance-per-method-invocation semantics, rather than pooling =
instances
or the like.

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
j=FCrgen h=F6ller [werk3AT]
Gesendet: So 04.04.2004 16:25
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



That's what I meant with the different meaning of the term "prototype":
AbstractPrototypeTargetSource just assumes that the bean that it =
references
is a prototype, allowing to expose targets with ThreadLocal or pooling
semantics. On the other hand, PrototypeTargetSource actually exposes a
"prototype" target, i.e. a new target object on each method invocation
(analogous to the term "prototype" used in bean definitions).

I agree that the term "prototype" isn't wrong in
AbstractPrototypeTargetSource, but it's used with somewhat different =
meaning
than in PrototypeTargetSource. To avoid confusion for people that dig =
into
Spring's javadoc or even implementation, we should use different terms =
here,
i.e. use the term "prototype" for a more specific meaning (preferably =
the
one analogous to bean definitions).

I'm open for other suggestions, of course!

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Rod Johnson
Gesendet: So 04.04.2004 16:08
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



I guess AbstractDynamicTargetSource is an improvement. I agree the =
naming
pattern isn't great, but the abstract base class _does_ work with =
prototype
definitions, so having Prototype in its name does make sense. It's not a
generic "Dynamic" TargetSource because it works with bean names and
getBeans() assuming a prototype.

Any other suggestions? If this is renamed, I'd rather that it was
undebatably right.

R


----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, April 03, 2004 6:46 PM
Subject: Re: [Springframework-developer] Preparing for 1.0.1


A minor naming issue that I've noticed: We have an
AbstractPrototypeTargetSource, which serves as base class for
PrototypeTargetSource, ThreadLocalTargetSource and
AbstractPoolingTargetSource. We don't have the AbstractXxx/Xxx naming
pattern anywhere else in the framework. (I've actually removed a similar
naming pattern in the AbstractAutoProxyCreator area before 1.0 final.)

Furthermore, "AbstractPrototypeTargetSource" is actually a bit =
misleading,
as we're using a broader meaning of the word prototype here than found =
in
bean definitions. "PrototypeTargetSource" matches the bean definition =
term
exactly, but the base class is more generic: So what about renaming it =
to
"AbstractDynamicTargetSource" or the like, indicating that it serves as =
base
class for all non-singleton TargetSources?

Like the AopUtils move, this should be fine in terms of compatibility =
level,
as the base class is not part of the public API but rather an internal
implementation detail. PrototypeTargetSource and co will still be fully
backward compatible after that change, and I doubt that anyone has
implemented custom TargetSources yet (and even if, it's trivial to =
adapt).

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Rod Johnson
Gesendet: Fr 02.04.2004 16:53
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



I suggest that we sit on this code for at least a week until we release =
it,
so we can catch anything else. How about we target Monday week for =
release?

A 1.0.1 release should be driven by stability, not date, so we should =
see if
any more issues come out of the woodwork.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, April 02, 2004 10:57 AM
Subject: [Springframework-developer] Preparing for 1.0.1


Hi everybody,

From my point of view, the code is ready for release 1.0.1. There were a
couple of bug fixes and minor enhancements since 1.0 final. The most
important fix is proper Hibernate/JTA resource management when flush =
fails.
Enhancements include the introduction of the MessageCodesResolver =
interface
in the validation package, and a more efficient internal implementation =
of
AbstractMessageSource. See the changelog for details.

Please give the current CVS snapshot a try. There shouldn't be any =
issues,
as changes are minor and just affect specific functionality. I'd like to
target mid next week for the release, i.e. two weeks after 1.0 final. In =
the
meantime, the only thing I plan to address is the lack of remoting =
coverage
in the reference docs. If anyone feels the need to improve other parts =
of
the docs, please do so till mid next week!

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

Re: [Springframework-developer] Should JaxRpcPortClientInterceptor implement RemoteAccessor?

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

JaxRpcPortClientInterceptor is indeed a "remote accessor", but it has a =
different base class, therefore it doesn't extend the convenience base =
class org.springframework.remoting.support.RemoteAccessor.
=20
For a working example, have a look at our JPetStore sample app: It =
exports its OrderService via 4 different remoting protocols, namely =
Hessian, Burlap, JAX-RPC and RMI invoker. It also includes a sample =
OrderServiceClient that accesses the service via all of those protocols.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Hunter Kelly
Gesendet: Do 08.04.2004 20:52
An: spr...@li...
Betreff: [Springframework-developer] Should JaxRpcPortClientInterceptor =
implement RemoteAccessor?



I was looking at the various classes and packages in
org.springframework.remoting, and I was looking that JaxRpc stuff.

It seems like JaxRpcPortClientInterceptor has the methods to be =
considered a
"RemoteAccessor"?  Is it a remote accessor?=20

I'll admit that I'm not completely au fait with JaxRPC and whatnot
(I was kinda hoping Spring can help me out :)  and I was just trying
to figure out which classes do what, and how they can help,
when I came across what looks like the above mentioned oversight.

Thanks,

H

P.S.  If anyone has any useful examples of the JaxRpc stuff, I'd be
very appreciative!



-------------------------------------------------------
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] commons-validator adapter

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

Keith,
=20
As the rules / declarative validation support is already becoming quite =
extensive, I wonder whether it is worth creating an own subproject for =
it (just like "spring-rcp"), maybe "spring-validation" (possibly getting =
the word "declarative" in too)?
=20
Of course, the basic validation and binding infrastructure should remain =
in the core Spring codebase. What I consider is to move all extended =
validation support to a separate subproject. This would also include =
commons-validator support, and possible future extensions.
=20
In terms of jar file sizes, the extended validation support in the =
sandbox already amounts to more than 90 KB. I'd expect that people might =
request or contribute more and more convenience rules over time, so I =
can imagine that this will grow towards 150 KB or even more.
=20
My basic rule is that everything that's in the core Spring codebase goes =
into spring.jar, which should cover typical usage scenarios. It's hard =
to decide what goes in there, but I'm keen on not growing this =
significantly beyond 1 MB. Things that have their own potential for =
rapid growth should not go into the core.
=20
JMX and JMS support are definite candidates for the core, as they are =
rather small, and I don't see the potential for extensive growth beyond =
the initial versions there (in terms of size). Declarative validation on =
the other hand has the potential to become a whole framework itself.
=20
What do you think? This would already give you two Spring subprojects =
then, but hey, your output demands it ;-) Note that this would also =
allow for a separate release schedule for the declarative validation =
project, just like with the Rich Client Platform.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von Keith Donald
Gesendet: Fr 09.04.2004 00:54
An: spr...@li...
Betreff: RE: [Springframework-developer] Re: commons-validator adapter



Since the purpose of this package is really to support the definition of
declarative rules (like validation rules, transformation/filter rules,
business rules, etc.) just plain old "org.springframework.rules" seems =
to
work.  It's simpler and more concise than expression, and definitely
functor.

I left the term Predicate as is for now, something about =
"BinaryCondition"
just doesn't sound right.  Attached below is a summary of the current =
layout
of the structure.  While there are a good many types, they're _small_ =
and
clients deal primarily with the Rules/PredicateFactory classes for
creating/composing rules (if using programatically), which is similar to
Hibernate's Criteria/Expression API.  Defining your own new rule =
conditions
is simple: just define a new Predicate implementation (which only =
requires
implementing a single test(arg) method.

For example: there is no EmailValidator class yet for validating String
properties that are e-mail addresses. To implement this we say:

public class EmailValidator implements UnaryPredicate {
        public boolean test(Object argument) {
                String email =3D (String)argument;
                return isEmailAddress(email);
        }

        private boolean isEmailAddress(String argument) {
                // the real work....
        }
}

Then, to create a rule that says a property is "required", has a "max
length" of 128 characters, and must be a "email address":

Rules.createRule("emailAddressProperty")
     .add(PredicateFactory.required())
     .add(PredicateFactory.maxLength(128))
     .add(EmailValidator.instance()); =20

The 'add' methods above imply a logical "AND" to all the predicates
(conjunction).   To get fancier, for example, to say that the argument =
is
valid regardless just as long as some other property is present (a =
top-level
OR condition) you can do something like this:

UnaryPredicate rules =3D
        PredicateFactory.or(
                PredicateFactory.
                    conjunction(new UnaryPredicate[] {
PredicateFactory.required(),

PredicateFactory.maxLength(128),

EmailValidator.instance()),
                =
PredicateFactory.propertyPresent("primaryEmailAddress"));

Rules.createRule("emailAddressProperty").add(rules);

That's a bit more complex, but it basically says: "emailAddressProperty =
is
valid if it is required, less than 128 characters, and an email address =
---
OR it's valid regardless as long as the primaryEmailAddress is present.

Just some examples.  This is much more than you can do with
commons-validator! :) Keith

Attached is a break down of the API to date (PLEASE NOTE THIS IS STILL =
VERY
EXPERIMENTAL & SUBJECT TO CHANGE!!!)

org.springframework.rules (your core interfaces and the API/factory for
composing rules programatically.)

Interfaces

BinaryFunction
        Evaluates two arguments and returns a single result.

BinaryPredicate
        Tests two arguments and returns a single boolean result.  A
conditional expression.

UnaryFunction
        Evaluates one argument and returns a single result.

UnaryPredicate
        Tests one argument and returns a single boolean result.  A
conditional expression.

Classes

Rules
        A factory for creating rules.

PredicateFactory
        A factory for easing the construction and composition of =
predicate
conditions.

FunctionFactory
        A factory for easing the construction and composition of =
functions.

LogicalOperator
        Type-safe enums for various conditional or logical operators
(AND/OR)

RelationalOperator
        Type-safe enum class for supported binary operators.

Algorithms
        Convenience utility class which provides a number of algorithms =
that
apply selection rules and filters to collections, for example.


org.springframework.rules.predicates (your rule condition building
blocks...)

BeanPropertyExpression
        A unary predicate that returns the result of a boolean =
expression
that tests two variable bean property values.

ParameterizedBeanPropertyExpression
        A unary predicate that returns the result of a boolean =
expression
that tests a variable bean property value against a constant parameter
value.

EqualTo
        Predicate that tests object equality (not identity.)

ComparisonBinaryPredicate
        Abstract helper superclass for binary predicates involved in
comparison operations.

GreaterThan
        Predicate that tests if one comparable object is greater than
another.

GreaterThanEqualTo
        Predicate that tests if one comparable object is greater than or
equal to another.

LessThan
        Predicate that tests if one comparable object is less than =
another.

LessThanEqualTo
        Predicate that tests if one comparable object is less than or =
equal
to another.

ParameterizedBinaryPredicate
        A unary predicate adapting a binary predicate that uses a
parameterized constant value as the second argument when testing.

UnaryFunctionResultConstraint
        Tests the result returned from evaluating a unary function.

BinaryFunctionResultConstraint
        Tests the result returned from evaluating a binary function =
against
some condition.

UnaryNot
        "Nots" another unary predicate (the inverse) by using =
composition.

CompoundUnaryPredicate
        Abstract base class for unary predicates which compose other
predicates.

UnaryAnd
        A "and" compound predicate (aka conjunction).

UnaryOr
        A "or" compound predicate (aka disjunction).

PropertyPresent
        Predicate that tests if the specified bean property is "present" =
-
that is, passes the "Required" test.

Range
        A range whose edges are defined by a minimum Comparable and a
maximum Comparable.

Required
        Validates a required property.


org.springframework.rules.functions (your "actions" or functions that do
things or execute if a predicate is true...)

Class Summary

GetProperty
        Binary function that gets a bean property.
Maximum
        Returns the maximum of two Comparable objects
Minimum
        Returns the maximum of two Comparable objects.
StringLength
        Returns the Integer length of an object's string form, or zero =
if
the object is null.
StringTrimmer
        Returns a trimmed copy of the string form of an object.
UnaryFunctionChain
        A chain of unary functions that evaluate their results in an =
ordered
sequence.

The abstract nature of many of the core classes demonstrates the =
"building
block approach" of taking simple little function objects and combining =
them
to create complex rules.  It's a bit different, but certainly
powerful/flexible.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Keith Donald
Sent: Thursday, April 08, 2004 3:02 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Re: commons-validator adapter


ouch, yea I figured that was coming. :-)

"expression" is one suggestion I have.  And to be honest, I'm not really
high on the term Predicate either.  I could rename that "Condition" - or =
we
could adopt Hibernate's Criteria term.

That would result in:
    org.springframework.expression
    org.springframework.expression.conditions
    org.springframework.expression.functions

It is possible to rename "functions" to "actions" as well.  But =
functions
imply a return value...

I'm open to suggestions! Keith


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Rod Johnson
Sent: Thursday, April 08, 2004 3:21 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: commons-validator adapter


functor is truly horrible.

I look forward to looking at this stuff in detail--it sounds cool--but I
think we must be able to find a better name :-)

----- Original Message -----
From: Keith Donald
To: Daniel Miller
Cc: spr...@li...
Sent: Thursday, April 08, 2004 2:44 AM
Subject: [Springframework-developer] Re: commons-validator adapter


Daniel,

The new declarative validation stuff will support both rule definition =
via
source markup via attributes like you said, as well as a xml-based
configuration via Spring IoC.  And there will still be the programmatic
option for configuration (I'm a big believer in having a polished API =
that
works just as well as the config files for those who still prefer that
route.)

I think it's going to be quite powerful, more so than commons-validator, =
and
easier to define new rules.  Right now you can define just about any
validation expression you can think up using the rules API - and complex
expressions (including compound expressions using And/Or/Not logical
operators and all the standard binary operators) are possible.  For =
example,
it's possible to define a rule that says: property "foo" is required if
properties "bar" and "apple" are present, but not if "orange" is =
present.
If those rules change, the API is flexible enough tweak them without =
having
to define a new class all together (the API provides very much a =
"building
block" approach for composing rules.).  Similiary, you can say that =
property
"foo" must be in the range of properties "lowBar" and "highBar" (or you =
can
parameterize the property expressions and say that "foo" must be in the
constant range of "1" to "255" for example...)

The predicate (rules) API is currently in the sandbox under
src/sandbox/org/springframework/functor (functor might not be the best =
name
for it - I just used it because the design is based on a functional =
style of
programming (heavy on the strategy & chain of responsibility patterns)
illustrated by commons-functor and Object space's JGL...) I think it is
looking pretty good.  The next challenge -- what I am working on now -- =
is
to integrate that API with a easy way of declaratively specifying rules =
in
an external file/source attributes (basically nailing down that format, =
with
emphasis on keeping the amount of config needed concise), and then =
hooking
rule definition up to the validation results reporting classes for
generating internationalized error messages and typing hints when bean
validation occurs at runtime.  More advanced features include the =
ability to
fire validation rules automatically when "constrained" set() methods are
called on a javabean, either using AOP or the built in java-beans
VetoChangeListener support.  The biggest challenge I've found there is
figuring out, based on what rules effect what properties, which rules =
should
fire on which set call.  That's not as easy as it seems when a single =
rule
effects multiple properties.

Keith

----- Original Message -----
From: Daniel Miller
To: Keith Donald
Sent: Wednesday, April 07, 2004 8:35 PM
Subject: RE: commons-validator adapter


Keith,

My viewpoint for now is that if Juergen and Rod approve the code then =
its
probably worth having it. I won't even be upset if it gets moved to a
"spring-plugins" jar as long as it's made available for people to use.

I agree, we should probably refactor them to reuse and share as much =
code
between the commons and attributes validators as possible.

I haven't had time to look at your attributes-based validator at all, so
forgive me if I seem a bit ignorant. From what I understand, this
attributes-based validation requires to be placed in the source code of =
the
classes that would be validated. Is that correct? If so, is there any =
way we
could create an XML configuration option like the Commons-Validator has
(i.e. not dependent on attributes at all)? It would be really cool if it
supported the same XML file format that the Commons-Validator does. What =
do
you think?

I'll keep you posted with any bugs that I find.

Daniel
-----Original Message-----
From: Keith Donald [mailto:kd...@cs...]
Sent: Tuesday, April 06, 2004 12:24 PM
To: 'Daniel Miller'
Subject: RE: commons-validator adapter


Daniel,

No problem.

BTW - I didn't realize those were *struts* classes, I assumed they were
commons-validator.  In that case it's probably going to be best for us =
to
just refactor those classes against our own declarative validation =
support
(which will provide a flexible API for defining rules.)  If you want to =
see
some of the API in development, check out
sandbox/src/org/springframework/functor/PredicateFactory.

I'll keep you posted.  In the meantime if you find any bugs send 'em my =
way.

Thanks,
Keith



-------------------------------------------------------
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] Re: commons-validator adapter

[Keith D. <kd...@cs...>]

Since the purpose of this package is really to support the definition of
declarative rules (like validation rules, transformation/filter rules,
business rules, etc.) just plain old "org.springframework.rules" seems =
to
work.  It's simpler and more concise than expression, and definitely
functor.

I left the term Predicate as is for now, something about =
"BinaryCondition"
just doesn't sound right.  Attached below is a summary of the current =
layout
of the structure.  While there are a good many types, they're _small_ =
and
clients deal primarily with the Rules/PredicateFactory classes for
creating/composing rules (if using programatically), which is similar to
Hibernate's Criteria/Expression API.  Defining your own new rule =
conditions
is simple: just define a new Predicate implementation (which only =
requires
implementing a single test(arg) method.

For example: there is no EmailValidator class yet for validating String
properties that are e-mail addresses. To implement this we say:

public class EmailValidator implements UnaryPredicate {
	public boolean test(Object argument) {
		String email =3D (String)argument;
		return isEmailAddress(email);
	}

	private boolean isEmailAddress(String argument) {
		// the real work....
	}
}

Then, to create a rule that says a property is "required", has a "max
length" of 128 characters, and must be a "email address":

Rules.createRule("emailAddressProperty")
     .add(PredicateFactory.required())
     .add(PredicateFactory.maxLength(128))
     .add(EmailValidator.instance());=09

The 'add' methods above imply a logical "AND" to all the predicates
(conjunction).   To get fancier, for example, to say that the argument =
is
valid regardless just as long as some other property is present (a =
top-level
OR condition) you can do something like this:

UnaryPredicate rules =3D
	PredicateFactory.or(
		PredicateFactory.
	   	    conjunction(new UnaryPredicate[] {
PredicateFactory.required(),
=20
PredicateFactory.maxLength(128),
=20
EmailValidator.instance()),
		PredicateFactory.propertyPresent("primaryEmailAddress"));

Rules.createRule("emailAddressProperty").add(rules);

That's a bit more complex, but it basically says: "emailAddressProperty =
is
valid if it is required, less than 128 characters, and an email address =
---
OR it's valid regardless as long as the primaryEmailAddress is present.

Just some examples.  This is much more than you can do with
commons-validator! :) Keith

Attached is a break down of the API to date (PLEASE NOTE THIS IS STILL =
VERY
EXPERIMENTAL & SUBJECT TO CHANGE!!!)

org.springframework.rules (your core interfaces and the API/factory for
composing rules programatically.)

Interfaces

BinaryFunction
	Evaluates two arguments and returns a single result.

BinaryPredicate
	Tests two arguments and returns a single boolean result.  A
conditional expression.

UnaryFunction
	Evaluates one argument and returns a single result.

UnaryPredicate
	Tests one argument and returns a single boolean result.  A
conditional expression.=20
=20
Classes=20

Rules
	A factory for creating rules.

PredicateFactory
	A factory for easing the construction and composition of predicate
conditions.

FunctionFactory
	A factory for easing the construction and composition of functions.

LogicalOperator
	Type-safe enums for various conditional or logical operators
(AND/OR)=20

RelationalOperator
	Type-safe enum class for supported binary operators.=20

Algorithms
	Convenience utility class which provides a number of algorithms that
apply selection rules and filters to collections, for example.


org.springframework.rules.predicates (your rule condition building
blocks...)

BeanPropertyExpression
	A unary predicate that returns the result of a boolean expression
that tests two variable bean property values.=20

ParameterizedBeanPropertyExpression
	A unary predicate that returns the result of a boolean expression
that tests a variable bean property value against a constant parameter
value.

EqualTo
	Predicate that tests object equality (not identity.)=20

ComparisonBinaryPredicate
	Abstract helper superclass for binary predicates involved in
comparison operations.=20

GreaterThan
	Predicate that tests if one comparable object is greater than
another.=20

GreaterThanEqualTo
	Predicate that tests if one comparable object is greater than or
equal to another.=20

LessThan
	Predicate that tests if one comparable object is less than another.=20

LessThanEqualTo
	Predicate that tests if one comparable object is less than or equal
to another.=20
=20
ParameterizedBinaryPredicate
	A unary predicate adapting a binary predicate that uses a
parameterized constant value as the second argument when testing.=20

UnaryFunctionResultConstraint
	Tests the result returned from evaluating a unary function.

BinaryFunctionResultConstraint
	Tests the result returned from evaluating a binary function against
some condition.

UnaryNot
	"Nots" another unary predicate (the inverse) by using composition.=20

CompoundUnaryPredicate
	Abstract base class for unary predicates which compose other
predicates.

UnaryAnd
	A "and" compound predicate (aka conjunction).

UnaryOr
	A "or" compound predicate (aka disjunction).=20

PropertyPresent
	Predicate that tests if the specified bean property is "present" -
that is, passes the "Required" test.=20

Range
	A range whose edges are defined by a minimum Comparable and a
maximum Comparable.

Required
	Validates a required property.


org.springframework.rules.functions (your "actions" or functions that do
things or execute if a predicate is true...)

Class Summary=20

GetProperty
	Binary function that gets a bean property.
Maximum
	Returns the maximum of two Comparable objects=20
Minimum
	Returns the maximum of two Comparable objects.=20
StringLength
	Returns the Integer length of an object's string form, or zero if
the object is null.=20
StringTrimmer
	Returns a trimmed copy of the string form of an object.=20
UnaryFunctionChain
	A chain of unary functions that evaluate their results in an ordered
sequence.=20

The abstract nature of many of the core classes demonstrates the =
"building
block approach" of taking simple little function objects and combining =
them
to create complex rules.  It's a bit different, but certainly
powerful/flexible.

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Keith Donald
Sent: Thursday, April 08, 2004 3:02 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Re: commons-validator adapter


ouch, yea I figured that was coming. :-)

"expression" is one suggestion I have.  And to be honest, I'm not really
high on the term Predicate either.  I could rename that "Condition" - or =
we
could adopt Hibernate's Criteria term.

That would result in:
    org.springframework.expression
    org.springframework.expression.conditions
    org.springframework.expression.functions

It is possible to rename "functions" to "actions" as well.  But =
functions
imply a return value...

I'm open to suggestions! Keith


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Rod Johnson
Sent: Thursday, April 08, 2004 3:21 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: commons-validator adapter


functor is truly horrible.

I look forward to looking at this stuff in detail--it sounds cool--but I
think we must be able to find a better name :-)

----- Original Message -----=20
From: Keith Donald=20
To: Daniel Miller=20
Cc: spr...@li...=20
Sent: Thursday, April 08, 2004 2:44 AM
Subject: [Springframework-developer] Re: commons-validator adapter


Daniel,

The new declarative validation stuff will support both rule definition =
via
source markup via attributes like you said, as well as a xml-based
configuration via Spring IoC.  And there will still be the programmatic
option for configuration (I'm a big believer in having a polished API =
that
works just as well as the config files for those who still prefer that
route.)

I think it's going to be quite powerful, more so than commons-validator, =
and
easier to define new rules.  Right now you can define just about any
validation expression you can think up using the rules API - and complex
expressions (including compound expressions using And/Or/Not logical
operators and all the standard binary operators) are possible.  For =
example,
it's possible to define a rule that says: property "foo" is required if
properties "bar" and "apple" are present, but not if "orange" is =
present.
If those rules change, the API is flexible enough tweak them without =
having
to define a new class all together (the API provides very much a =
"building
block" approach for composing rules.).  Similiary, you can say that =
property
"foo" must be in the range of properties "lowBar" and "highBar" (or you =
can
parameterize the property expressions and say that "foo" must be in the
constant range of "1" to "255" for example...)

The predicate (rules) API is currently in the sandbox under
src/sandbox/org/springframework/functor (functor might not be the best =
name
for it - I just used it because the design is based on a functional =
style of
programming (heavy on the strategy & chain of responsibility patterns)
illustrated by commons-functor and Object space's JGL...) I think it is
looking pretty good.  The next challenge -- what I am working on now -- =
is
to integrate that API with a easy way of declaratively specifying rules =
in
an external file/source attributes (basically nailing down that format, =
with
emphasis on keeping the amount of config needed concise), and then =
hooking
rule definition up to the validation results reporting classes for
generating internationalized error messages and typing hints when bean
validation occurs at runtime.  More advanced features include the =
ability to
fire validation rules automatically when "constrained" set() methods are
called on a javabean, either using AOP or the built in java-beans
VetoChangeListener support.  The biggest challenge I've found there is
figuring out, based on what rules effect what properties, which rules =
should
fire on which set call.  That's not as easy as it seems when a single =
rule
effects multiple properties.

Keith

----- Original Message -----=20
From: Daniel Miller=20
To: Keith Donald=20
Sent: Wednesday, April 07, 2004 8:35 PM
Subject: RE: commons-validator adapter


Keith,

My viewpoint for now is that if Juergen and Rod approve the code then =
its
probably worth having it. I won't even be upset if it gets moved to a
"spring-plugins" jar as long as it's made available for people to use.

I agree, we should probably refactor them to reuse and share as much =
code
between the commons and attributes validators as possible.

I haven't had time to look at your attributes-based validator at all, so
forgive me if I seem a bit ignorant. From what I understand, this
attributes-based validation requires to be placed in the source code of =
the
classes that would be validated. Is that correct? If so, is there any =
way we
could create an XML configuration option like the Commons-Validator has
(i.e. not dependent on attributes at all)? It would be really cool if it
supported the same XML file format that the Commons-Validator does. What =
do
you think?

I'll keep you posted with any bugs that I find.

Daniel
-----Original Message-----
From: Keith Donald [mailto:kd...@cs...]
Sent: Tuesday, April 06, 2004 12:24 PM
To: 'Daniel Miller'
Subject: RE: commons-validator adapter


Daniel,

No problem.

BTW - I didn't realize those were *struts* classes, I assumed they were
commons-validator.  In that case it's probably going to be best for us =
to
just refactor those classes against our own declarative validation =
support
(which will provide a flexible API for defining rules.)  If you want to =
see
some of the API in development, check out
sandbox/src/org/springframework/functor/PredicateFactory.

I'll keep you posted.  In the meantime if you find any bugs send 'em my =
way.

Thanks,
Keith

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

[Keith D. <kd...@cs...>]

ouch, yea I figured that was coming. :-)
=20
"expression" is one suggestion I have.  And to be honest, I'm not really
high on the term Predicate either.  I could rename that "Condition" - or =
we
could adopt Hibernate's Criteria term.
=20
That would result in:
    org.springframework.expression
    org.springframework.expression.conditions
    org.springframework.expression.functions
=20
It is possible to rename "functions" to "actions" as well.  But =
functions
imply a return value...
=20
I'm open to suggestions! Keith
=20
=20
-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
Rod Johnson
Sent: Thursday, April 08, 2004 3:21 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Re: commons-validator adapter



functor is truly horrible.
=20
I look forward to looking at this stuff in detail--it sounds cool--but I
think we must be able to find a better name :-)
=20

----- Original Message -----=20
From: Keith  <mailto:kd...@cs...> Donald=20
To: Daniel Miller <mailto:mi...@pa...> =20
Cc: spr...@li...=20
Sent: Thursday, April 08, 2004 2:44 AM
Subject: [Springframework-developer] Re: commons-validator adapter

Daniel,
=20
The new declarative validation stuff will support both rule definition =
via
source markup via attributes like you said, as well as a xml-based
configuration via Spring IoC.  And there will still be the programmatic
option for configuration (I'm a big believer in having a polished API =
that
works just as well as the config files for those who still prefer that
route.)
=20
I think it's going to be quite powerful, more so than commons-validator, =
and
easier to define new rules.  Right now you can define just about any
validation expression you can think up using the rules API - and complex
expressions (including compound expressions using And/Or/Not logical
operators and all the standard binary operators) are possible.  For =
example,
it's possible to define a rule that says: property "foo" is required if
properties "bar" and "apple" are present, but not if "orange" is =
present.
If those rules change, the API is flexible enough tweak them without =
having
to define a new class all together (the API provides very much a =
"building
block" approach for composing rules.).  Similiary, you can say that =
property
"foo" must be in the range of properties "lowBar" and "highBar" (or you =
can
parameterize the property expressions and say that "foo" must be in the
constant range of "1" to "255" for example...)
=20
The predicate (rules) API is currently in the sandbox under
src/sandbox/org/springframework/functor (functor might not be the best =
name
for it - I just used it because the design is based on a functional =
style of
programming (heavy on the strategy & chain of responsibility patterns)
illustrated by commons-functor and Object space's JGL...) I think it is
looking pretty good.  The next challenge -- what I am working on now -- =
is
to integrate that API with a easy way of declaratively specifying rules =
in
an external file/source attributes (basically nailing down that format, =
with
emphasis on keeping the amount of config needed concise), and then =
hooking
rule definition up to the validation results reporting classes for
generating internationalized error messages and typing hints when bean
validation occurs at runtime.  More advanced features include the =
ability to
fire validation rules automatically when "constrained" set() methods are
called on a javabean, either using AOP or the built in java-beans
VetoChangeListener support.  The biggest challenge I've found there is
figuring out, based on what rules effect what properties, which rules =
should
fire on which set call.  That's not as easy as it seems when a single =
rule
effects multiple properties.
=20
Keith
=20
----- Original Message -----=20

From: Daniel  <mailto:mi...@pa...> Miller=20
To: Keith Donald <mailto:kd...@cs...> =20
Sent: Wednesday, April 07, 2004 8:35 PM
Subject: RE: commons-validator adapter


Keith,
=20
My viewpoint for now is that if Juergen and Rod approve the code then =
its
probably worth having it. I won't even be upset if it gets moved to a
"spring-plugins" jar as long as it's made available for people to use.
=20
I agree, we should probably refactor them to reuse and share as much =
code
between the commons and attributes validators as possible.
=20
I haven't had time to look at your attributes-based validator at all, so
forgive me if I seem a bit ignorant. From what I understand, this
attributes-based validation requires to be placed in the source code of =
the
classes that would be validated. Is that correct? If so, is there any =
way we
could create an XML configuration option like the Commons-Validator has
(i.e. not dependent on attributes at all)? It would be really cool if it
supported the same XML file format that the Commons-Validator does. What =
do
you think?
=20
I'll keep you posted with any bugs that I find.
=20
Daniel

-----Original Message-----
From: Keith Donald [mailto:kd...@cs...]
Sent: Tuesday, April 06, 2004 12:24 PM
To: 'Daniel Miller'
Subject: RE: commons-validator adapter


Daniel,
=20
No problem.
=20
BTW - I didn't realize those were *struts* classes, I assumed they were
commons-validator.  In that case it's probably going to be best for us =
to
just refactor those classes against our own declarative validation =
support
(which will provide a flexible API for defining rules.)  If you want to =
see
some of the API in development, check out
sandbox/src/org/springframework/functor/PredicateFactory.
=20
I'll keep you posted.  In the meantime if you find any bugs send 'em my =
way.
=20
Thanks,
Keith

[Springframework-developer] Should JaxRpcPortClientInterceptor implement RemoteAccessor?

[Hunter K. <re...@ei...>]

I was looking at the various classes and packages in 
org.springframework.remoting, and I was looking that JaxRpc stuff.

It seems like JaxRpcPortClientInterceptor has the methods to be considered a 
"RemoteAccessor"?  Is it a remote accessor?  

I'll admit that I'm not completely au fait with JaxRPC and whatnot 
(I was kinda hoping Spring can help me out :)  and I was just trying
to figure out which classes do what, and how they can help,
when I came across what looks like the above mentioned oversight.

Thanks,

H

P.S.  If anyone has any useful examples of the JaxRpc stuff, I'd be
very appreciative!

Re: [Springframework-developer] Preparing for 1.0.1

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

AbstractDynamicTargetSource is OK by me, although I'm not in love with it.
Technically of course a dynamic target source need not use the bean facto=
ry
at all. But AbstractPrototypeBasedTargetSource is a bit wordy...

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Thursday, April 08, 2004 5:27 PM
Subject: Re: [Springframework-developer] Preparing for 1.0.1


Final decision here? I still vote for "AbstractDynamicTargetSource"; at
least against "AbstractPrototypeTargetSource".

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Monday, April 05, 2004 9:51 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.0.1


Actually, I still prefer "AbstractDynamicTargetSource": Target beans bein=
g
defined as prototypes is a requirement for any meaningful dynamic target
source strategy (no matter if one-shot, ThreadLocal or pooled), therefore=
 I
consider it fine that AbstractDynamicTargetSource implicitly works with
prototype target beans. But just PrototypeTargetSource delivers actual
one-instance-per-method-invocation semantics, rather than pooling instanc=
es
or the like.

Juergen


________________________________

Von: spr...@li... im Auftrag von
j=FCrgen h=F6ller [werk3AT]
Gesendet: So 04.04.2004 16:25
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



That's what I meant with the different meaning of the term "prototype":
AbstractPrototypeTargetSource just assumes that the bean that it referenc=
es
is a prototype, allowing to expose targets with ThreadLocal or pooling
semantics. On the other hand, PrototypeTargetSource actually exposes a
"prototype" target, i.e. a new target object on each method invocation
(analogous to the term "prototype" used in bean definitions).

I agree that the term "prototype" isn't wrong in
AbstractPrototypeTargetSource, but it's used with somewhat different mean=
ing
than in PrototypeTargetSource. To avoid confusion for people that dig int=
o
Spring's javadoc or even implementation, we should use different terms he=
re,
i.e. use the term "prototype" for a more specific meaning (preferably the
one analogous to bean definitions).

I'm open for other suggestions, of course!

Juergen


________________________________

Von: spr...@li... im Auftrag von
Rod Johnson
Gesendet: So 04.04.2004 16:08
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



I guess AbstractDynamicTargetSource is an improvement. I agree the naming
pattern isn't great, but the abstract base class _does_ work with prototy=
pe
definitions, so having Prototype in its name does make sense. It's not a
generic "Dynamic" TargetSource because it works with bean names and
getBeans() assuming a prototype.

Any other suggestions? If this is renamed, I'd rather that it was
undebatably right.

R


----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, April 03, 2004 6:46 PM
Subject: Re: [Springframework-developer] Preparing for 1.0.1


A minor naming issue that I've noticed: We have an
AbstractPrototypeTargetSource, which serves as base class for
PrototypeTargetSource, ThreadLocalTargetSource and
AbstractPoolingTargetSource. We don't have the AbstractXxx/Xxx naming
pattern anywhere else in the framework. (I've actually removed a similar
naming pattern in the AbstractAutoProxyCreator area before 1.0 final.)

Furthermore, "AbstractPrototypeTargetSource" is actually a bit misleading=
,
as we're using a broader meaning of the word prototype here than found in
bean definitions. "PrototypeTargetSource" matches the bean definition ter=
m
exactly, but the base class is more generic: So what about renaming it to
"AbstractDynamicTargetSource" or the like, indicating that it serves as b=
ase
class for all non-singleton TargetSources?

Like the AopUtils move, this should be fine in terms of compatibility lev=
el,
as the base class is not part of the public API but rather an internal
implementation detail. PrototypeTargetSource and co will still be fully
backward compatible after that change, and I doubt that anyone has
implemented custom TargetSources yet (and even if, it's trivial to adapt).

Juergen


________________________________

Von: spr...@li... im Auftrag von
Rod Johnson
Gesendet: Fr 02.04.2004 16:53
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



I suggest that we sit on this code for at least a week until we release i=
t,
so we can catch anything else. How about we target Monday week for releas=
e?

A 1.0.1 release should be driven by stability, not date, so we should see=
 if
any more issues come out of the woodwork.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, April 02, 2004 10:57 AM
Subject: [Springframework-developer] Preparing for 1.0.1


Hi everybody,

From my point of view, the code is ready for release 1.0.1. There were a
couple of bug fixes and minor enhancements since 1.0 final. The most
important fix is proper Hibernate/JTA resource management when flush fail=
s.
Enhancements include the introduction of the MessageCodesResolver interfa=
ce
in the validation package, and a more efficient internal implementation o=
f
AbstractMessageSource. See the changelog for details.

Please give the current CVS snapshot a try. There shouldn't be any issues=
,
as changes are minor and just affect specific functionality. I'd like to
target mid next week for the release, i.e. two weeks after 1.0 final. In =
the
meantime, the only thing I plan to address is the lack of remoting covera=
ge
in the reference docs. If anyone feels the need to improve other parts of
the docs, please do so till mid next week!

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=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=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=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=3Dick
_______________________________________________
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...>]

Messagefunctor is truly horrible.

I look forward to looking at this stuff in detail--it sounds cool--but I =
think we must be able to find a better name :-)

  ----- Original Message -----=20
  From: Keith Donald=20
  To: Daniel Miller=20
  Cc: spr...@li...=20
  Sent: Thursday, April 08, 2004 2:44 AM
  Subject: [Springframework-developer] Re: commons-validator adapter


  Daniel,

  The new declarative validation stuff will support both rule definition =
via source markup via attributes like you said, as well as a xml-based =
configuration via Spring IoC.  And there will still be the programmatic =
option for configuration (I'm a big believer in having a polished API =
that works just as well as the config files for those who still prefer =
that route.)

  I think it's going to be quite powerful, more so than =
commons-validator, and easier to define new rules.  Right now you can =
define just about any validation expression you can think up using the =
rules API - and complex expressions (including compound expressions =
using And/Or/Not logical operators and all the standard binary =
operators) are possible.  For example, it's possible to define a rule =
that says: property "foo" is required if properties "bar" and "apple" =
are present, but not if "orange" is present.  If those rules change, the =
API is flexible enough tweak them without having to define a new class =
all together (the API provides very much a "building block" approach for =
composing rules.).  Similiary, you can say that property "foo" must be =
in the range of properties "lowBar" and "highBar" (or you can =
parameterize the property expressions and say that "foo" must be in the =
constant range of "1" to "255" for example...)

  The predicate (rules) API is currently in the sandbox under =
src/sandbox/org/springframework/functor (functor might not be the best =
name for it - I just used it because the design is based on a functional =
style of programming (heavy on the strategy & chain of responsibility =
patterns) illustrated by commons-functor and Object space's JGL...) I =
think it is looking pretty good.  The next challenge -- what I am =
working on now -- is to integrate that API with a easy way of =
declaratively specifying rules in an external file/source attributes =
(basically nailing down that format, with emphasis on keeping the amount =
of config needed concise), and then hooking rule definition up to the =
validation results reporting classes for generating internationalized =
error messages and typing hints when bean validation occurs at runtime.  =
More advanced features include the ability to fire validation rules =
automatically when "constrained" set() methods are called on a javabean, =
either using AOP or the built in java-beans VetoChangeListener support.  =
The biggest challenge I've found there is figuring out, based on what =
rules effect what properties, which rules should fire on which set call. =
 That's not as easy as it seems when a single rule effects multiple =
properties.

  Keith

  ----- Original Message -----=20
    From: Daniel Miller=20
    To: Keith Donald=20
    Sent: Wednesday, April 07, 2004 8:35 PM
    Subject: RE: commons-validator adapter


    Keith,

    My viewpoint for now is that if Juergen and Rod approve the code =
then its probably worth having it. I won't even be upset if it gets =
moved to a "spring-plugins" jar as long as it's made available for =
people to use.

    I agree, we should probably refactor them to reuse and share as much =
code between the commons and attributes validators as possible.

    I haven't had time to look at your attributes-based validator at =
all, so forgive me if I seem a bit ignorant. From what I understand, =
this attributes-based validation requires to be placed in the source =
code of the classes that would be validated. Is that correct? If so, is =
there any way we could create an XML configuration option like the =
Commons-Validator has (i.e. not dependent on attributes at all)? It =
would be really cool if it supported the same XML file format that the =
Commons-Validator does. What do you think?

    I'll keep you posted with any bugs that I find.

    Daniel
      -----Original Message-----
      From: Keith Donald [mailto:kd...@cs...]
      Sent: Tuesday, April 06, 2004 12:24 PM
      To: 'Daniel Miller'
      Subject: RE: commons-validator adapter


      Daniel,

      No problem.

      BTW - I didn't realize those were *struts* classes, I assumed they =
were commons-validator.  In that case it's probably going to be best for =
us to just refactor those classes against our own declarative validation =
support (which will provide a flexible API for defining rules.)  If you =
want to see some of the API in development, check out =
sandbox/src/org/springframework/functor/PredicateFactory.

      I'll keep you posted.  In the meantime if you find any bugs send =
'em my way.

      Thanks,
      Keith

Re: [Springframework-developer] Preparing for 1.0.1

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

Final decision here? I still vote for "AbstractDynamicTargetSource"; at =
least against "AbstractPrototypeTargetSource".

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of j=FCrgen h=F6ller [werk3AT]
Sent: Monday, April 05, 2004 9:51 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Preparing for 1.0.1


Actually, I still prefer "AbstractDynamicTargetSource": Target beans =
being defined as prototypes is a requirement for any meaningful dynamic =
target source strategy (no matter if one-shot, ThreadLocal or pooled), =
therefore I consider it fine that AbstractDynamicTargetSource implicitly =
works with prototype target beans. But just PrototypeTargetSource =
delivers actual one-instance-per-method-invocation semantics, rather =
than pooling instances or the like.
=20
Juergen
=20

________________________________

Von: spr...@li... im Auftrag =
von j=FCrgen h=F6ller [werk3AT]
Gesendet: So 04.04.2004 16:25
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



That's what I meant with the different meaning of the term "prototype": =
AbstractPrototypeTargetSource just assumes that the bean that it =
references is a prototype, allowing to expose targets with ThreadLocal =
or pooling semantics. On the other hand, PrototypeTargetSource actually =
exposes a "prototype" target, i.e. a new target object on each method =
invocation (analogous to the term "prototype" used in bean definitions).

I agree that the term "prototype" isn't wrong in =
AbstractPrototypeTargetSource, but it's used with somewhat different =
meaning than in PrototypeTargetSource. To avoid confusion for people =
that dig into Spring's javadoc or even implementation, we should use =
different terms here, i.e. use the term "prototype" for a more specific =
meaning (preferably the one analogous to bean definitions).

I'm open for other suggestions, of course!

Juergen


________________________________

Von: spr...@li... im Auftrag =
von Rod Johnson
Gesendet: So 04.04.2004 16:08
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



I guess AbstractDynamicTargetSource is an improvement. I agree the =
naming
pattern isn't great, but the abstract base class _does_ work with =
prototype
definitions, so having Prototype in its name does make sense. It's not a
generic "Dynamic" TargetSource because it works with bean names and
getBeans() assuming a prototype.

Any other suggestions? If this is renamed, I'd rather that it was
undebatably right.

R


----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Saturday, April 03, 2004 6:46 PM
Subject: Re: [Springframework-developer] Preparing for 1.0.1


A minor naming issue that I've noticed: We have an
AbstractPrototypeTargetSource, which serves as base class for
PrototypeTargetSource, ThreadLocalTargetSource and
AbstractPoolingTargetSource. We don't have the AbstractXxx/Xxx naming
pattern anywhere else in the framework. (I've actually removed a similar
naming pattern in the AbstractAutoProxyCreator area before 1.0 final.)

Furthermore, "AbstractPrototypeTargetSource" is actually a bit =
misleading,
as we're using a broader meaning of the word prototype here than found =
in
bean definitions. "PrototypeTargetSource" matches the bean definition =
term
exactly, but the base class is more generic: So what about renaming it =
to
"AbstractDynamicTargetSource" or the like, indicating that it serves as =
base
class for all non-singleton TargetSources?

Like the AopUtils move, this should be fine in terms of compatibility =
level,
as the base class is not part of the public API but rather an internal
implementation detail. PrototypeTargetSource and co will still be fully
backward compatible after that change, and I doubt that anyone has
implemented custom TargetSources yet (and even if, it's trivial to =
adapt).

Juergen


________________________________

Von: spr...@li... im Auftrag =
von
Rod Johnson
Gesendet: Fr 02.04.2004 16:53
An: spr...@li...
Betreff: Re: [Springframework-developer] Preparing for 1.0.1



I suggest that we sit on this code for at least a week until we release =
it,
so we can catch anything else. How about we target Monday week for =
release?

A 1.0.1 release should be driven by stability, not date, so we should =
see if
any more issues come out of the woodwork.

----- Original Message -----
From: "j=FCrgen h=F6ller [werk3AT]" <jue...@we...>
To: <spr...@li...>
Sent: Friday, April 02, 2004 10:57 AM
Subject: [Springframework-developer] Preparing for 1.0.1


Hi everybody,

From my point of view, the code is ready for release 1.0.1. There were a
couple of bug fixes and minor enhancements since 1.0 final. The most
important fix is proper Hibernate/JTA resource management when flush =
fails.
Enhancements include the introduction of the MessageCodesResolver =
interface
in the validation package, and a more efficient internal implementation =
of
AbstractMessageSource. See the changelog for details.

Please give the current CVS snapshot a try. There shouldn't be any =
issues,
as changes are minor and just affect specific functionality. I'd like to
target mid next week for the release, i.e. two weeks after 1.0 final. In =
the
meantime, the only thing I plan to address is the lack of remoting =
coverage
in the reference docs. If anyone feels the need to improve other parts =
of
the docs, please do so till mid next week!

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