springframework-developer — Spring Framework developers list

RE: [Springframework-developer] Any plans to add support for multiple handlers per request

[Keith D. <ke...@in...>]

While webflow does indeed make chaining actions (commands) together =
easy,
I'm not clear if it is your best choice here or not.  Is there really a
workflow that spans some steps in play here?

I'm not sure if multiple controllers forwarding to each other would be =
the
best solution here either--seems quite brittle.  It seems like what you =
want
is a generic form of the ChainOfResponsibility pattern--maybe something
similar to what commons chain does.  I could see a single controller, =
and
behind it a chain of commands, where each command in the chain invokes =
some
method on a service object, and puts the return value in some context =
which
is add to the model.  If that's what you need...

--

In any case web flow is pretty easy to setup.  It is powerful but not
complex to use.  Download PR2 and head to the Quick Start.  If it =
doesn't
pass the 15 minute test please let us know.

There are a wealth of sample applications available with the =
distribution as
well that should help you get up and running fast (see samples/webflow).

Keith

-----Original Message-----
From: spr...@li...
[mailto:spr...@li...] On Behalf =
Of
March, Andres
Sent: Thursday, April 21, 2005 1:02 PM
To: spr...@li...
Subject: RE: [Springframework-developer] Any plans to add support for
multiple handlers per request

Thanks for the reply.  I am interested in webflow but wow there is a lot
of stuff in there.  I was not sure that it was focused on multiple
actions per request.  I thought it was generally for multipage actions.

Good to hear that it has that capability.  I will take another look.  It
seems like a little overkill for what I need to do.

Basically I just want to call 1-to-many service methods for a single
request.  I want to be able to configure this in the app-context
preferably, so that I don't have to create a controller for every
request. I opened  SPR-871 to track this stuff.  I attached some code
that basically does what I want but is kinda ugly. =20

Then I thought it would be simpler if multiple controllers/handlers
could be specified for each request.  I could easily make a generic
controller bean that would have a property to know which service method
to call and would just stick the result in the model.  At the end of all
those, a final controller would return the ModelAndView.

I guess it would be nice to use webflow if it already has this
capability but I hope it is not too much trouble to set up. =20

Thoughts?=20

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of Seth Ladd
> Sent: Wednesday, April 20, 2005 7:08 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Any plans to add support for
> multiple handlers per request
>=20
> > Any plans to add support for multiple handlers per request?  Any
> > architectural reasons for not doing this?  For what I'm doing,
> interceptors
> > really do not suit my needs.
>=20
> Have you looked at Web Flows for this?  It's quite easy to string
> together many actions in a flow before you end up at your view state.
>=20
> As for the MVC world, you could write a HandlerInterceptor that merely
> delegates to a Controller (your handler).  What part of the
> interceptor is falling short of your needs?
>=20
> Seth
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime
> info,
> new features, or free trial, at:
http://www.businessobjects.com/devxi/728
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer


-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_ide95&alloc_id=14396&op=3Dick
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Any plans to add support for multiple handlers per request

[Seth L. <set...@gm...>]

On 4/21/05, March, Andres <am...@so...> wrote:
> Thanks for the reply.  I am interested in webflow but wow there is a lot
> of stuff in there.  I was not sure that it was focused on multiple
> actions per request.  I thought it was generally for multipage actions.

Using webflow, you would configure multiple <action>'s to string
together, finally landing on a <view>.  So it's a simple way to model
a flow diagram (often coming from management) as a webflow workflow.=20
It's actually very simple to setup.  If you understand Spring MVC then
setting up webflow will be very straight forward.

> Basically I just want to call 1-to-many service methods for a single
> request.  I want to be able to configure this in the app-context
> preferably, so that I don't have to create a controller for every
> request. I opened  SPR-871 to track this stuff.  I attached some code
> that basically does what I want but is kinda ugly.

Ahh... so you want to bind N service calls directly to a request
without a controller?  How would you marshall request parameters into
the service layer and back?  This is the job for the controller, imho.
 So the controller is pretty thin, but does glue my service layer to
the web mvc world.

If this is what you want, webflow will still require you to write an
Action method for each step along the way.

>=20
> Then I thought it would be simpler if multiple controllers/handlers
> could be specified for each request.  I could easily make a generic
> controller bean that would have a property to know which service method
> to call and would just stick the result in the model.  At the end of all
> those, a final controller would return the ModelAndView.

Again, how do you know what the method parameters would be for each
service call?

>=20
> I guess it would be nice to use webflow if it already has this
> capability but I hope it is not too much trouble to set up.

Now that you have explained this, webflow (afaik) does not have
exactly this feature.  You will still need to write a method that
handles the Action, taking a RequestContext and returning an Event.

Seth

Re: [Springframework-developer] Re: Major bug not marked for resolution in 1.2

[Juergen H. <ju...@in...>]

SPR-889 is already fixed, committed to CVS for a couple of hours :-)

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Matt Sgarlata
Sent: Thursday, April 21, 2005 7:17 PM
To: spr...@li...
Subject: [Springframework-developer] Re: Major bug not marked for
resolution in 1.2


I would also consider SPR-889, "Dependency checking doesn't work for 
beans using method injection" as a bug that should be fixed before 
Spring 1.2 final.

Matt

Matt Sgarlata wrote:
> I view SPR-879 as a major bug in Spring that I would hope could be fixed 
> before Spring 1.2 final.  The underlying issue is that beans that are 
> designated for auto-autoproxying don't always get auto-proxied. Instead, 
> beans that are marked for auto-proxying are only proxied if they aren't 
> needed before the auto-proxy machinery kicks in.  As a user I would 
> expect a bean marked for auto-proxying to be auto-proxied. Instead, the 
> current symantics implemented by Spring are "autoproxy if you can, but 
> if you can't then swallow the error and leave me scratching my head" ;)  
> SPR-879 is to at least warn the user that a bean they've marked for 
> autoproxying isn't going to be autoproxied.
> 
> Thanks,
> 
> Matt
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click



-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

[Springframework-developer] Re: Major bug not marked for resolution in 1.2

[Matt S. <sga...@us...>]

I would also consider SPR-889, "Dependency checking doesn't work for 
beans using method injection" as a bug that should be fixed before 
Spring 1.2 final.

Matt

Matt Sgarlata wrote:
> I view SPR-879 as a major bug in Spring that I would hope could be fixed 
> before Spring 1.2 final.  The underlying issue is that beans that are 
> designated for auto-autoproxying don't always get auto-proxied. Instead, 
> beans that are marked for auto-proxying are only proxied if they aren't 
> needed before the auto-proxy machinery kicks in.  As a user I would 
> expect a bean marked for auto-proxying to be auto-proxied. Instead, the 
> current symantics implemented by Spring are "autoproxy if you can, but 
> if you can't then swallow the error and leave me scratching my head" ;)  
> SPR-879 is to at least warn the user that a bean they've marked for 
> autoproxying isn't going to be autoproxied.
> 
> Thanks,
> 
> Matt
> 
> 
> 
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click

[Springframework-developer] Major bug not marked for resolution in 1.2

[Matt S. <sga...@us...>]

I view SPR-879 as a major bug in Spring that I would hope could be fixed 
before Spring 1.2 final.  The underlying issue is that beans that are 
designated for auto-autoproxying don't always get auto-proxied. 
Instead, beans that are marked for auto-proxying are only proxied if 
they aren't needed before the auto-proxy machinery kicks in.  As a user 
I would expect a bean marked for auto-proxying to be auto-proxied. 
Instead, the current symantics implemented by Spring are "autoproxy if 
you can, but if you can't then swallow the error and leave me scratching 
my head" ;)  SPR-879 is to at least warn the user that a bean they've 
marked for autoproxying isn't going to be autoproxied.

Thanks,

Matt

RE: [Springframework-developer] Any plans to add support for multiple handlers per request

[March, A. <am...@so...>]

Thanks for the reply.  I am interested in webflow but wow there is a lot
of stuff in there.  I was not sure that it was focused on multiple
actions per request.  I thought it was generally for multipage actions.

Good to hear that it has that capability.  I will take another look.  It
seems like a little overkill for what I need to do.

Basically I just want to call 1-to-many service methods for a single
request.  I want to be able to configure this in the app-context
preferably, so that I don't have to create a controller for every
request. I opened  SPR-871 to track this stuff.  I attached some code
that basically does what I want but is kinda ugly. =20

Then I thought it would be simpler if multiple controllers/handlers
could be specified for each request.  I could easily make a generic
controller bean that would have a property to know which service method
to call and would just stick the result in the model.  At the end of all
those, a final controller would return the ModelAndView.

I guess it would be nice to use webflow if it already has this
capability but I hope it is not too much trouble to set up. =20

Thoughts?=20

> -----Original Message-----
> From: spr...@li...
> [mailto:spr...@li...] On
Behalf
> Of Seth Ladd
> Sent: Wednesday, April 20, 2005 7:08 PM
> To: spr...@li...
> Subject: Re: [Springframework-developer] Any plans to add support for
> multiple handlers per request
>=20
> > Any plans to add support for multiple handlers per request?  Any
> > architectural reasons for not doing this?  For what I'm doing,
> interceptors
> > really do not suit my needs.
>=20
> Have you looked at Web Flows for this?  It's quite easy to string
> together many actions in a flow before you end up at your view state.
>=20
> As for the MVC world, you could write a HandlerInterceptor that merely
> delegates to a Controller (your handler).  What part of the
> interceptor is falling short of your needs?
>=20
> Seth
>=20
>=20
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime
> info,
> new features, or free trial, at:
http://www.businessobjects.com/devxi/728
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] WAS 6.0 TransactionManager Lookup

[Mark St G. <stg...@ca...>]

Hi Juergen,

I am using WAS 6, Spring 1.2 RC2 and Hibernate 3.0 ... I am pretty sure the
standard Transaction Manager Factory lookup still works.

i.e.  WebSphereTransactionManagerFactoryBean

private static final String FACTORY_CLASS_5_1 =
"com.ibm.ws.Transaction.TransactionManagerFactory";

I think the stuff Gavin has in the
org.hibernate.transaction.WebSphereExtendedJTATransactionLookup is
to support the WebSphere JTA extensions to the spec..... basically
transaction synchronization callbacks.
That said, I still think the Spring WebSphereTransactionManagerFactoryBean
needs to change... or
a more likely create a new
WebSphere(6/Extended)TransactionManagerFactoryBean.

Cheers,
Mark



                                                                           
             "Juergen Hoeller"                                             
             <juergen@interfac                                             
             e21.com>                                                   To 
             Sent by:                  <spr...@li... 
             springframework-d         urceforge.net>                      
             eveloper-admin@li                                          cc 
             sts.sourceforge.n                                             
             et                                                    Subject 
                                       Re: [Springframework-developer] WAS 
                                       6.0 TransactionManager Lookup       
             04/21/2005 07:03                                              
             AM                                                            
                                                                           
                                                                           
             Please respond to                                             
             springframework-d                                             
                 eveloper                                                  
                                                                           
                                                                           




Yes, we should cover WebSphere 6.0 too - I'll do that for 1.2 final.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Dmitriy Kopylenko
Sent: Thursday, April 21, 2005 2:01 PM
To: spr...@li...
Subject: Re: [Springframework-developer] WAS 6.0 TransactionManager
Lookup


There is WebSphereTransactionManagerFactoryBean which is used to lookup
jta TransactionManager implementation for WebSphere versions 4, 5.0, and
5.1, not 6.0

May be we should modify it to add 6.0 lookup code?

Dmitriy.


Claus Ibsen wrote:

>Hi
>
>I was reading the changelog for Hibernate 3.01 and discovered:
>* fixed TransactionManager lookup (again) for WAS 6.0
>
>I recall there was something about Spring using a similar strategy to
lookup the
>TM in WAS as Hibernate does.
>
>Just though I would raise a flag if there could be a issue.
>
>
>Kind regards
>
>Claus
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: New Crystal Reports XI.
>Version 11 adds new functionality designed to reduce time involved in
>creating, integrating, and deploying reporting solutions. Free runtime
info,
>new features, or free trial, at: http://www.businessobjects.com/devxi/728
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime
info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime
info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] WAS 6.0 TransactionManager Lookup

[Juergen H. <ju...@in...>]

Yes, we should cover WebSphere 6.0 too - I'll do that for 1.2 final.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Dmitriy Kopylenko
Sent: Thursday, April 21, 2005 2:01 PM
To: spr...@li...
Subject: Re: [Springframework-developer] WAS 6.0 TransactionManager
Lookup


There is WebSphereTransactionManagerFactoryBean which is used to lookup
jta TransactionManager implementation for WebSphere versions 4, 5.0, and
5.1, not 6.0

May be we should modify it to add 6.0 lookup code?

Dmitriy.


Claus Ibsen wrote:

>Hi
>
>I was reading the changelog for Hibernate 3.01 and discovered:
>* fixed TransactionManager lookup (again) for WAS 6.0
>
>I recall there was something about Spring using a similar strategy to
lookup the
>TM in WAS as Hibernate does.
>
>Just though I would raise a flag if there could be a issue.
>
>
>Kind regards
>
>Claus
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: New Crystal Reports XI.
>Version 11 adds new functionality designed to reduce time involved in
>creating, integrating, and deploying reporting solutions. Free runtime
info,
>new features, or free trial, at: http://www.businessobjects.com/devxi/728
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] WAS 6.0 TransactionManager Lookup

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

There is WebSphereTransactionManagerFactoryBean which is used to lookup 
jta TransactionManager implementation for WebSphere versions 4, 5.0, and 
5.1, not 6.0

May be we should modify it to add 6.0 lookup code?

Dmitriy.


Claus Ibsen wrote:

>Hi
>
>I was reading the changelog for Hibernate 3.01 and discovered:
>* fixed TransactionManager lookup (again) for WAS 6.0
>
>I recall there was something about Spring using a similar strategy to lookup the
>TM in WAS as Hibernate does.
>
>Just though I would raise a flag if there could be a issue.
>
>
>Kind regards
>
>Claus
>
>
>
>-------------------------------------------------------
>This SF.Net email is sponsored by: New Crystal Reports XI.
>Version 11 adds new functionality designed to reduce time involved in
>creating, integrating, and deploying reporting solutions. Free runtime info,
>new features, or free trial, at: http://www.businessobjects.com/devxi/728
>_______________________________________________
>Springframework-developer mailing list
>Spr...@li...
>https://lists.sourceforge.net/lists/listinfo/springframework-developer
>  
>

[Springframework-developer] WAS 6.0 TransactionManager Lookup

[Claus I. <cib...@ya...>]

Hi

I was reading the changelog for Hibernate 3.01 and discovered:
* fixed TransactionManager lookup (again) for WAS 6.0

I recall there was something about Spring using a similar strategy to lookup the
TM in WAS as Hibernate does.

Just though I would raise a flag if there could be a issue.


Kind regards

Claus

[Springframework-developer] more on the neater XML configuration support: XSD generation & more concise & easily validated custom XML files

[<jas...@ma...>]

I had a couple of beers last night with Huw Roberts, an old colleague I 
keep bumping into at lots of different companies over the last 15 years 
or so - and the subject of configuration came up. The topic was touched 
on recently & Rod's mentioned its something to think about for 1.3 
(e.g. see the thread 'integrating custom XML spring dialects into the 
standard Spring XML config file')

Right now the spring configuration mechanism rocks for developers; but 
could be much better for end users who know nothing of the codebase & 
available POJOs and their properties/constructors etc. So the idea is 
to support a custom XML format for specific applications or service 
which has its own self-documented XSD so that configuration tools (or 
any decent XML tool) can provide a rich user interface for managing the 
configuration (so end users don't have to know anything about beans or 
their APIs, just use a UI which groks what options are allowed etc); 
yet keep Spring's immense flexibility of allowing any old Java code to 
be integrated and configured using the bean/constructor/property type 
route.

i.e. the best of both worlds; constrained, concise, validated, 
introspectable configuration for rich UIs and tools for end users 
rather than developers - or great, flexible generic bean/property stuff 
for when developers wanna wire anything into the spring configuration.

So instead of the normal Spring which is hard to validate (in an XML 
way for end users unaware of the Java code) and can be a little verbose

<bean id="foo" class="Bar">
     <property name="foo" value="1234"/> ....
     <property name="whatnot" value="1234"/> ....

we could have something like this. We add some annotations to our 
POJOs..


package org.acme.xyx;

// the @Xml annotation is optional, we can default to 'Bar' if not 
present
// also namespace can be defaulted from the package

@Xml(element="bar")
class Bar {

     @Mandatory
     public String getFoo() {....}

     // assumed optional if no mandatory
     public int getWhatnot() {...}


     @Cardinality(min=1, max=100000)
     public List<Cheese> getCheeses() {...}
}


which would auto-generate the 'mapping configuration' for spring so we 
could use this in any spring.xml...

<beans xmlns="http://xyz.acme.org">

     <bar foo="1234" whatnot="1234">...

We can then auto-generate an XSD file that can be used when editing 
documents using the new <bar> element - including all of the 
optional/mandatory and cardinality validation logic (along with XSD 
data type validation etc). So then we can give really good error 
messages to users who edit <bar> and miss off mandatory properties 
before we even start creating and wiring the POJOs together.

Then from the annotations we could also auto-generate the 'mapping' 
code so that the standard Spring XmlBeanFactory can auto-detect the new 
elements available (<bar> in this case).  e.g. we could autogenerate 
some META-INF/services/spring/xyz/acme/org.mapping file which contains 
the mapping configuration details of how the <bar> element (with 
namespace) maps to the fully qualified Bar class etc. The schema could 
also be introspectable on the classpath at 
META-INF/services/spring/xyz/acme/org.xsd.

This would allow components to provide their own XML mappings and 
inbuilt XSD for validation as parts of their build & folks could use 
them if they wish without explicit registration in the spring.xml. Neat 
eh :)


To avoid components clashing (e.g. having the same element name in 
different components) namespaces are used at the XSD and XML level - 
and using the Java package names (maybe with a version postfix) would 
seem the simplest default unless folks override this in the 
annotations.

The only downside with heavily namespaced XML is its a bit ugly and 
verbose to read - so maybe we could add a 'namespace alias' tag to 
Spring to allow Spring to map non-namespaced elements into namespaced 
elements under the covers.

e.g.  here's a regular Spring.xml which uses this new namespaced XML 
above using aliases...

<beans>
< namespaceAlias uri="http://xyz.acme.org">

<!-- we can now use the <bar> element without any namespace stuff... -->
<bar foo="1234" whatnot="1234">...
</beans>

without the <namespaceAlias> tag we'd have to use fully qualified 
namespaces instead - which is OK as often namespaces will be used for 
one tree of configuration stuff, but sometimes lots of namespaces in a 
document can be a little messy...

<beans>

<bar xmlns="http://xyz.acme.org" foo="1234" whatnot="1234">...

</beans>

I guess using namespaces for different component/service libraries is 
no biggie really. Its definitely better to start with full namespace 
support then see if/how to hide it later on rather than the other way 
around and get clashes etc.

In the above, coming up with the annotations and tool to auto-generate 
the XSD is pretty simple - the only tricker part is modifying the 
XmlBeanFactory to be able to auto-detect the 'custom mappings' which I 
hope could just be some XML configuration file we can find on the 
classpath (or on the file system in the usual spring way) which defines 
which beans map to elements and what properties map to attributes etc.

To start with we don't need to support particularly complex mappings of 
XML <-> POJOs; just aliasing beans to specific element names, 
properties to elements or attributes and support for XSD validation 
would do - further down the road we might wanna get more clever & 
flexible.

Thoughts?

James
-------
http://radio.weblogs.com/0112098/

[Springframework-developer] webflow: validator invocation strategy

[Steven D. <ste...@gm...>]

Hi guys,

You recently extended validator invocation functionality in Web Flow
by calling a specific method on a validator instance. I propose to
make this behavior more generic. While I think calling a specific
method on the validator is a great way to do validation across
multiple pages there's a comparable strategy I would like to see
implemented.

I would like to call a collection of validators linked to a specific
string token in a map. The string token would be the equivalent of a
method name and would be defined in the flow config.

In order to implement this I propose to call specific validator
invocations through an interface that would allow different strategies
to be implemented.

Kind regards

Steven
=20
--=20
"If you want to be a different fish, you gotta jump out of the school."
-- Captain Beefheart

Re: [Springframework-developer] Any plans to add support for multiple handlers per request

[Seth L. <set...@gm...>]

> Any plans to add support for multiple handlers per request?  Any
> architectural reasons for not doing this?  For what I'm doing, intercepto=
rs
> really do not suit my needs.=20

Have you looked at Web Flows for this?  It's quite easy to string
together many actions in a flow before you end up at your view state.

As for the MVC world, you could write a HandlerInterceptor that merely
delegates to a Controller (your handler).  What part of the
interceptor is falling short of your needs?

Seth

[Springframework-developer] Acegi Security - new release 0.8.2

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

Dear Spring Community

I'm pleased to announce that Acegi Security release 0.8.2 is now 
available. This release fixes a number of non-critical bugs, resolves an 
incompatibility with Spring 1.2-RC2 refactorings, updates JAR 
dependencies to match Spring 1.2-RC2, and refactors 
AbstractProcessingFilter exception mappings. As per the Apache APR 
project versioning guidelines, this is a minor release. Users of release 
0.8.0 or 0.8.1 should be able to simply drop the new 0.8.2 JARs into 
their applications, although please be aware:

1. Spring 1.2-RC2 (or above, such as a CVS snapshot) is the minimum 
requirement for Acegi Security 0.8.2
2. Users of AbstractProcessingFilter (typically 
AuthenticationProcessingFilter) must modify their exception setters as 
per 
http://acegisecurity.sourceforge.net/multiproject/acegi-security/apidocs/net/sf/acegisecurity/ui/AbstractProcessingFilter.html

Please note that Acegi Security releases prior to 0.8.2 will not operate 
with Spring 1.2-RC2. You will need to use the latest Acegi Security 
release (0.8.2) if you wish to operate with Spring 1.2-RC2.

For Maven users, Acegi Security's latest JARs are now available from 
http://acegisecurity.sourceforge.net/maven/acegisecurity/jars. Release 
0.8.2 will be added to iBiblio shortly.

Please visit http://acegisecurity.sourceforge.net to learn more about 
Acegi Security's features, browse online documentation, or download the 
latest release.

We hope you find this new release useful in your projects.

Cheers
Ben

[Springframework-developer] spring build.250 Build Successful

[<al...@in...>]

View results here -> http://opensource.jteam.nl/build/buildresults/spring?log=log20050421001703Lbuild.250

Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

[Colin S. <col...@ex...>]

Juergen Hoeller wrote:

>Yes, that's what I've been thinking of too...
>
>I'd prefer to reimplement FilterToBeanProxy as DelegatingFilterProxy in
>org.springframework.web.filter, though, in a stripped-down fashion: deriving
>from GenericFilterBean, offering a "targetBeanName" bean property,
>defaulting to the filter name as target bean name.
>
>The name "DelegatingFilterProxy" is analogous to our "DelegatingActionProxy"
>in org.springframework.web.struts. We also have a "DelegatingDataSource",
>"DelegatingMessageSource", etc.
>
>I'm not sure whether we should keep the class-based delegate lookup. If we
>do, I would introduce a "targetBeanClass" property, with a strict check - if
>there isn't exactly one matching bean in the context, we'll fail. However, I
>prefer lookup by bean name, in particular if we simply use the filter name
>as target bean name.
>  
>
I would keep it if it doesn't get in the way of the bean name default 
strategy (which it doesn't seem to), as it's potentially useful to some 
people.

>Regarding the lifecycle concerns: init and destroy should probably always be
>delegated to the target Filter bean instance. If the target Filter uses bean
>lifecycle callbacks, it's gonna implement Filter.init/destroy as empty
>anyway. So I guess we don't really need an explicit config setting for this.
>  
>
I'm not sure I agree about this. If the methods are always delegated, 
then it somewhat precludes for example somebody subclassign an existing 
filter to try to use that codebase as-is. If the init/destroy doesn't 
happen by default, then the filter class in question can decide when/if 
to call the Filter interface lifecycle methods...

>I've kept the lazy initialization of the delegate Filter, which was
>obviously introduced for the case where the Filter proxy gets started before
>the root WebApplicationContext (which can happen with ContextLoaderServlet).
>
>I've just prototyped this; if we agree on the approach, I could document it
>and commit it quickly. I guess the main question is whether the above
>DelegatingFilterProxy suggestion is sufficient for Acegi's needs. Could it
>replace the current FilterToBeanProxy, as used by Acegi?
>
>As a side note: For completeness' sake, we could also add a
>DelegatingServletProxy to org.springframework.web.servlet, providing similar
>delegation to a target Servlet bean instance. However, that would probably
>be a rather academic exercise.
>
>Juergen
>
>  
>

-- 
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com

[Springframework-developer] Any plans to add support for multiple handlers per request

[March, A. <am...@so...>]

Any plans to add support for multiple handlers per request?  Any
architectural reasons for not doing this?  For what I'm doing,
interceptors really do not suit my needs.

=20

-----------------------------------------

Andres March

Platform - Apps Engineering

Sony Online Entertainment

desk: 858.577.3373

cell:   619.519.1519

=20

Re: [Springframework-developer] [ANN] Spring Modules 0.1 Released

[Rob H. <ro...@ca...>]

Thanks,

I'll clean that up now and replace it.

Rob

Matt Raible wrote:

> FYI... the Validator JAR seems to have a bunch of $__CLOVER_*.class  
> files in it.  It's 44K in the download and if I build it using "ant  
> alljars" on my machine, it's 24K.  Obviously, not a big deal - but  
> thought you might like to know.
>
> Matt
>
> On Apr 20, 2005, at 4:59 AM, Rob Harrop wrote:
>
>> Dear Spring community,
>>
>> I am pleased to announce that Spring Modules 0.1 has just been  
>> released.
>>
>> Downloads can be found at: http://springmodules.dev.java.net.
>>
>> This release includes:
>>
>> * Integration with HiveMind, allowing for HiveMind services to be  
>> exposed as
>> Spring beans
>> * Spring-style integration classes for JSR-94 rules engines such as  
>> Jess and
>> Drools
>> * Spring-style configuration for OSWorkflow
>> * Integration classes for Commons Validator (taken from Spring sandbox)
>>
>> For a detailed list of features, see the changelog.
>>
>> The HiveMind and Commons Validator support classes are considered to be
>> stable and ready for use in production. Modifications to the JavaScript
>> handling in Commons Validator will appear in 0.2.
>>
>> The OSWorkflow configuration support is ready for use in production,  
>> but 0.2
>> will introduce the OSWorkflowTemplate, which will bring full Spring
>> semantics to workflow usage.
>>
>> We have successfully used the JSR-94 integration classes in a  
>> production
>> setting, but are planning to overhaul session handling in 0.2.
>>
>> We are planning to release 0.2 within the next three weeks, 
>> hopefully  just
>> after Spring 1.2 goes final. This is in keeping with our plan to  
>> release new
>> features as often as possible.
>>
>> The full roadmap can be found at:
>> http://opensource.atlassian.com/projects/spring/secure/ 
>> BrowseProject.jspa?id
>> =10030&report=roadmap.
>>
>> We are still looking to recruit more developers to work on more  
>> modules, and
>> any feedback on new or existing features will be much appreciated.
>>
>> Regards,
>>
>> Rob
>>
>> -- 
>> Rob Harrop
>> Interface21 - Spring Services from the Source
>> http://www.springframework.com
>>
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by: New Crystal Reports XI.
>> Version 11 adds new functionality designed to reduce time involved in
>> creating, integrating, and deploying reporting solutions. Free 
>> runtime  info,
>> new features, or free trial, at:  
>> http://www.businessobjects.com/devxi/728
>> _______________________________________________
>> Springframework-developer mailing list
>> Spr...@li...
>> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime 
> info,
> new features, or free trial, at: http://www.businessobjects.com/devxi/728
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer
>
>

Re: [Springframework-developer] [ANN] Spring Modules 0.1 Released

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

FYI... the Validator JAR seems to have a bunch of $__CLOVER_*.class  
files in it.  It's 44K in the download and if I build it using "ant  
alljars" on my machine, it's 24K.  Obviously, not a big deal - but  
thought you might like to know.

Matt

On Apr 20, 2005, at 4:59 AM, Rob Harrop wrote:

> Dear Spring community,
>
> I am pleased to announce that Spring Modules 0.1 has just been  
> released.
>
> Downloads can be found at: http://springmodules.dev.java.net.
>
> This release includes:
>
> * Integration with HiveMind, allowing for HiveMind services to be  
> exposed as
> Spring beans
> * Spring-style integration classes for JSR-94 rules engines such as  
> Jess and
> Drools
> * Spring-style configuration for OSWorkflow
> * Integration classes for Commons Validator (taken from Spring sandbox)
>
> For a detailed list of features, see the changelog.
>
> The HiveMind and Commons Validator support classes are considered to be
> stable and ready for use in production. Modifications to the JavaScript
> handling in Commons Validator will appear in 0.2.
>
> The OSWorkflow configuration support is ready for use in production,  
> but 0.2
> will introduce the OSWorkflowTemplate, which will bring full Spring
> semantics to workflow usage.
>
> We have successfully used the JSR-94 integration classes in a  
> production
> setting, but are planning to overhaul session handling in 0.2.
>
> We are planning to release 0.2 within the next three weeks, hopefully  
> just
> after Spring 1.2 goes final. This is in keeping with our plan to  
> release new
> features as often as possible.
>
> The full roadmap can be found at:
> http://opensource.atlassian.com/projects/spring/secure/ 
> BrowseProject.jspa?id
> =10030&report=roadmap.
>
> We are still looking to recruit more developers to work on more  
> modules, and
> any feedback on new or existing features will be much appreciated.
>
> Regards,
>
> Rob
>
> --
> Rob Harrop
> Interface21 - Spring Services from the Source
> http://www.springframework.com
>
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: New Crystal Reports XI.
> Version 11 adds new functionality designed to reduce time involved in
> creating, integrating, and deploying reporting solutions. Free runtime  
> info,
> new features, or free trial, at:  
> http://www.businessobjects.com/devxi/728
> _______________________________________________
> Springframework-developer mailing list
> Spr...@li...
> https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

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

Juergen Hoeller wrote:

>I've also taken the two convenience methods in Acegi's StringSplitUtils
>class and moved them over to Spring's StringUtils. In the course of this,
>I've transformed the "splitEachArrayElementAndCreateMap" method into
>"splitArrayElementsIntoProperties", essentially returning a Properties
>instance instead of a Map (since all we ever get back is String-String
>pairs).
>
>My goal for Spring 1.2 final is that the Acegi util package should only
>contain Acegi-specific utilities, no general utility stuff anymore. With the
>addition of DelegatingFilterProxy and the String split methods to core
>Spring, we should be pretty there... An Acegi release 0.9 alongside Spring
>1.2 final would be appropriate, I guess. Opinions welcome, of course :-)
>
>Ben, when do you plan to go to 1.0 RC with Acegi? Maybe alongside Spring 1.3
>RC, which is currently scheduled for right before JavaOne? I think that
>would be a great message, to show that Acegi is fully active and supported.
>
>(BTW, FilterChainProxy in net.sf.acegisecurity.util has dependencies on the
>net.sf.acegisecurity and net.sf.acegisecurity.intercept.web packages, so
>arguably doesn't belong in the low-level util package...)
>
Hi Juergen

All of this sounds great. Our general release plan at this stage is:

- Release 0.8.2. To release ASAP. It will require Spring 1.2-RC2, and 
fix the current 0.8.1 to 1.2-RC2 incompatibility.
- Release 0.9.0. Refactor to use a dedicated SecurityContext ThreadLocal 
and also Spring 1.2-Final util package migration.
- Release 1.0.0-RC1. A Spring 1.3 pre-JavaOne release sounds like a good 
target.

In terms of your other email's suggestion to use a SecurityContext 
ThreadLocal instead of ContextHolder, I've given this some more thought 
and we can do this and still offer a clean migration path for 99% of 
existing ContextHolder users. Whilst I know some people (myself 
included) have found ContextHolder's general-purpose approach useful, it 
seems more important overall to achieve standardization with Spring Core 
in the ThreadLocal approach, and as such it seems worthwhile refactoring 
to SecurityContext.

Any comments from the community are welcome.

Cheers
Ben

[Springframework-developer] [ANN] Spring Modules 0.1 Released

[Rob H. <rob...@in...>]

Dear Spring community,

I am pleased to announce that Spring Modules 0.1 has just been released.

Downloads can be found at: http://springmodules.dev.java.net.

This release includes:

* Integration with HiveMind, allowing for HiveMind services to be exposed as
Spring beans
* Spring-style integration classes for JSR-94 rules engines such as Jess and
Drools
* Spring-style configuration for OSWorkflow
* Integration classes for Commons Validator (taken from Spring sandbox)

For a detailed list of features, see the changelog.

The HiveMind and Commons Validator support classes are considered to be
stable and ready for use in production. Modifications to the JavaScript
handling in Commons Validator will appear in 0.2.

The OSWorkflow configuration support is ready for use in production, but 0.2
will introduce the OSWorkflowTemplate, which will bring full Spring
semantics to workflow usage.

We have successfully used the JSR-94 integration classes in a production
setting, but are planning to overhaul session handling in 0.2.

We are planning to release 0.2 within the next three weeks, hopefully just
after Spring 1.2 goes final. This is in keeping with our plan to release new
features as often as possible.

The full roadmap can be found at:
http://opensource.atlassian.com/projects/spring/secure/BrowseProject.jspa?id
=10030&report=roadmap.

We are still looking to recruit more developers to work on more modules, and
any feedback on new or existing features will be much appreciated.

Regards,

Rob

--
Rob Harrop
Interface21 - Spring Services from the Source
http://www.springframework.com 

Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

[Juergen H. <ju...@in...>]

While we're at it: As I recently indicated, I think Acegi should only
provide a SecurityContext in its context package, in combination with a
SecurityContextHolder. The generic Context abstraction there could confuse
people, in particular alongside stuff like the LocaleContext (plus
LocaleContextHolder) that we've introduced in Spring 1.2.

A single central thread-bound Context raises a hard issue: Who determines
the Context instance (and thus the Context implementation class) to be held
there? Such a generic Context holder is unfortunately not as extensible as
it may seem. The consequence has to be several domain-specific contexts,
IMO, such as a LocaleContext and a SecurityContext.

Regarding the name "SecureContext" vs "SecurityContext": I tend to prefer
the latter, because the context itself isn't "secure", it just holds
security-related data. Not sure whether a name change there is feasible for
Acegi 0.9, though, so it will probably have to wait till Acegi 1.0 or stay
as it is.

In general, I think that the term "context" is overused already, so if we're
referring to a context, we should usually prepend the type of context that
we mean: servlet, web application, locale, security, etc.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Juergen Hoeller
Sent: Wednesday, April 20, 2005 10:53 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring 1.2 RC2 and Acegi
Security


I've also taken the two convenience methods in Acegi's StringSplitUtils
class and moved them over to Spring's StringUtils. In the course of this,
I've transformed the "splitEachArrayElementAndCreateMap" method into
"splitArrayElementsIntoProperties", essentially returning a Properties
instance instead of a Map (since all we ever get back is String-String
pairs).

My goal for Spring 1.2 final is that the Acegi util package should only
contain Acegi-specific utilities, no general utility stuff anymore. With the
addition of DelegatingFilterProxy and the String split methods to core
Spring, we should be pretty there... An Acegi release 0.9 alongside Spring
1.2 final would be appropriate, I guess. Opinions welcome, of course :-)

Ben, when do you plan to go to 1.0 RC with Acegi? Maybe alongside Spring 1.3
RC, which is currently scheduled for right before JavaOne? I think that
would be a great message, to show that Acegi is fully active and supported.

(BTW, FilterChainProxy in net.sf.acegisecurity.util has dependencies on the
net.sf.acegisecurity and net.sf.acegisecurity.intercept.web packages, so
arguably doesn't belong in the low-level util package...)

Juergen


-----Original Message-----
From: Juergen Hoeller [mailto:ju...@in...]
Sent: Wednesday, April 20, 2005 10:06 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring 1.2 RC2 and Acegi
Security


Yes, that's what I've been thinking of too...

I'd prefer to reimplement FilterToBeanProxy as DelegatingFilterProxy in
org.springframework.web.filter, though, in a stripped-down fashion: deriving
from GenericFilterBean, offering a "targetBeanName" bean property,
defaulting to the filter name as target bean name.

The name "DelegatingFilterProxy" is analogous to our "DelegatingActionProxy"
in org.springframework.web.struts. We also have a "DelegatingDataSource",
"DelegatingMessageSource", etc.

I'm not sure whether we should keep the class-based delegate lookup. If we
do, I would introduce a "targetBeanClass" property, with a strict check - if
there isn't exactly one matching bean in the context, we'll fail. However, I
prefer lookup by bean name, in particular if we simply use the filter name
as target bean name.

Regarding the lifecycle concerns: init and destroy should probably always be
delegated to the target Filter bean instance. If the target Filter uses bean
lifecycle callbacks, it's gonna implement Filter.init/destroy as empty
anyway. So I guess we don't really need an explicit config setting for this.

I've kept the lazy initialization of the delegate Filter, which was
obviously introduced for the case where the Filter proxy gets started before
the root WebApplicationContext (which can happen with ContextLoaderServlet).

I've just prototyped this; if we agree on the approach, I could document it
and commit it quickly. I guess the main question is whether the above
DelegatingFilterProxy suggestion is sufficient for Acegi's needs. Could it
replace the current FilterToBeanProxy, as used by Acegi?

As a side note: For completeness' sake, we could also add a
DelegatingServletProxy to org.springframework.web.servlet, providing similar
delegation to a target Servlet bean instance. However, that would probably
be a rather academic exercise.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, April 20, 2005 4:27 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring 1.2 RC2 and Acegi
Security


This reminds me that Spring 1.2 is probably the appropriate time for
Acegi's FilterToBeanProxy to move over from Acegi to Spring. While I
know we deferred on this before because you had some concerns about
lifecycle owneship, in practice the class is very useful, and it (or
something like it) really belongs in Spring...

Colin

Juergen Hoeller wrote:

>Yes, there are essentially these two options: either require Spring 1.2 as
>of the next Acegi release (which should probably be called 0.9 then), or
>copy the old PathMatcher over. In the former case, Acegi should follow the
>new Spring pattern there: components that need path-matching functionality
>receive a PathMatcher implementation through dependency injection, using an
>AntPathMatcher as default.
>
>BTW, it would be good to unify the codebases in the mid term, for example
>moving some of the generic Acegi utility stuff over to the main Spring
>codebase. IMO, we should do this for Acegi Security 1.0 at the latest, with
>Acegi concentrating on the actual security support only. In any case, I
>guess it's inevitable to depend on a specific Spring release level at some
>point.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Andy Depue
>Sent: Tuesday, April 19, 2005 10:52 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring 1.2 RC2 and Acegi
>Security
>
>
>I should note that I ran across this earlier and posted a patch to the
Acegi
>developer's list (see
>http://article.gmane.org/gmane.comp.java.springframework.acegisecurity.deve
l
>/864 ).
>I didn't officially submit this patch, as it breaks backward compatibility
>with Spring (it will only run with the very latest Spring).  If a goal of
>the
>Acegi project is to maintain such compability, it will probably either want
>to remove the dependency (by copying the code into the Acegi project), or
>use
>reflection or other technique at runtime to dynamically adapt to the Spring
>version.
>
>  - Andy
>
>On Tuesday 19 April 2005 12:11 pm, Juergen Hoeller wrote:
>
>
>>Hi Ben,
>>
>>as Matt has noticed, there is a change in Spring 1.2 RC2 that breaks Acegi
>>Security:
>>
>><matt>
>>It's cool to see that the Spring Team has released 1.2 RC2, but there's a
>>change that causes Acegi Security (v0.8.1) to fail.
>>
>>• refactored static PathMatcher class into PathMatcher interface and
>>AntPathMatcher implementation
>>
>>This change seems to cause this issue with Acegi Security. Right now, I
>>have Spring 1.2 RC1 and Hibernate 3.0.1 bundled into AppFuse 1.8. I was
>>hoping to upgrade to Spring 1.2 RC2, but it doesn't look like this will
>>work - unless the Acegi Team releases a new version that supports 1.2 RC2
>>(hint, hint ;-). </matt>
>>
>>I've refactored the static PathMatcher into a PathMatcher interface and
>>AntPathMatcher implementation class, after repeated questions in that
>>respect. I must admit I haven't really considered that other *libraries*
>>might access that code, just that users might.
>>
>>Hence, I've accepted the tradeoff of backwards-incompatibility for 1.2,
>>because it's easy enough for users to migrate affected code - and the
>>utilities in Spring's util package are considered somewhat for internal
>>
>>
>use
>
>
>>in the first place. But unfortunately, there's the issue of collaborating
>>libraries...
>>
>>Anyway, I would like to keep the refactored PathMatcher, so I'd like to
>>encourage you to release an Acegi update release (0.8.2?) at your earliest
>>convenience, ideally alongside Spring 1.2 final (in about two weeks) or
>>earlier. Users should have a fully working combo then again.
>>
>>Sorry for the inconveniences caused,
>>
>>Juergen
>>
>>



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

[Juergen H. <ju...@in...>]

I've also taken the two convenience methods in Acegi's StringSplitUtils
class and moved them over to Spring's StringUtils. In the course of this,
I've transformed the "splitEachArrayElementAndCreateMap" method into
"splitArrayElementsIntoProperties", essentially returning a Properties
instance instead of a Map (since all we ever get back is String-String
pairs).

My goal for Spring 1.2 final is that the Acegi util package should only
contain Acegi-specific utilities, no general utility stuff anymore. With the
addition of DelegatingFilterProxy and the String split methods to core
Spring, we should be pretty there... An Acegi release 0.9 alongside Spring
1.2 final would be appropriate, I guess. Opinions welcome, of course :-)

Ben, when do you plan to go to 1.0 RC with Acegi? Maybe alongside Spring 1.3
RC, which is currently scheduled for right before JavaOne? I think that
would be a great message, to show that Acegi is fully active and supported.

(BTW, FilterChainProxy in net.sf.acegisecurity.util has dependencies on the
net.sf.acegisecurity and net.sf.acegisecurity.intercept.web packages, so
arguably doesn't belong in the low-level util package...)

Juergen


-----Original Message-----
From: Juergen Hoeller [mailto:ju...@in...]
Sent: Wednesday, April 20, 2005 10:06 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring 1.2 RC2 and Acegi
Security


Yes, that's what I've been thinking of too...

I'd prefer to reimplement FilterToBeanProxy as DelegatingFilterProxy in
org.springframework.web.filter, though, in a stripped-down fashion: deriving
from GenericFilterBean, offering a "targetBeanName" bean property,
defaulting to the filter name as target bean name.

The name "DelegatingFilterProxy" is analogous to our "DelegatingActionProxy"
in org.springframework.web.struts. We also have a "DelegatingDataSource",
"DelegatingMessageSource", etc.

I'm not sure whether we should keep the class-based delegate lookup. If we
do, I would introduce a "targetBeanClass" property, with a strict check - if
there isn't exactly one matching bean in the context, we'll fail. However, I
prefer lookup by bean name, in particular if we simply use the filter name
as target bean name.

Regarding the lifecycle concerns: init and destroy should probably always be
delegated to the target Filter bean instance. If the target Filter uses bean
lifecycle callbacks, it's gonna implement Filter.init/destroy as empty
anyway. So I guess we don't really need an explicit config setting for this.

I've kept the lazy initialization of the delegate Filter, which was
obviously introduced for the case where the Filter proxy gets started before
the root WebApplicationContext (which can happen with ContextLoaderServlet).

I've just prototyped this; if we agree on the approach, I could document it
and commit it quickly. I guess the main question is whether the above
DelegatingFilterProxy suggestion is sufficient for Acegi's needs. Could it
replace the current FilterToBeanProxy, as used by Acegi?

As a side note: For completeness' sake, we could also add a
DelegatingServletProxy to org.springframework.web.servlet, providing similar
delegation to a target Servlet bean instance. However, that would probably
be a rather academic exercise.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, April 20, 2005 4:27 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring 1.2 RC2 and Acegi
Security


This reminds me that Spring 1.2 is probably the appropriate time for
Acegi's FilterToBeanProxy to move over from Acegi to Spring. While I
know we deferred on this before because you had some concerns about
lifecycle owneship, in practice the class is very useful, and it (or
something like it) really belongs in Spring...

Colin

Juergen Hoeller wrote:

>Yes, there are essentially these two options: either require Spring 1.2 as
>of the next Acegi release (which should probably be called 0.9 then), or
>copy the old PathMatcher over. In the former case, Acegi should follow the
>new Spring pattern there: components that need path-matching functionality
>receive a PathMatcher implementation through dependency injection, using an
>AntPathMatcher as default.
>
>BTW, it would be good to unify the codebases in the mid term, for example
>moving some of the generic Acegi utility stuff over to the main Spring
>codebase. IMO, we should do this for Acegi Security 1.0 at the latest, with
>Acegi concentrating on the actual security support only. In any case, I
>guess it's inevitable to depend on a specific Spring release level at some
>point.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Andy Depue
>Sent: Tuesday, April 19, 2005 10:52 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring 1.2 RC2 and Acegi
>Security
>
>
>I should note that I ran across this earlier and posted a patch to the
Acegi
>developer's list (see
>http://article.gmane.org/gmane.comp.java.springframework.acegisecurity.deve
l
>/864 ).
>I didn't officially submit this patch, as it breaks backward compatibility
>with Spring (it will only run with the very latest Spring).  If a goal of
>the
>Acegi project is to maintain such compability, it will probably either want
>to remove the dependency (by copying the code into the Acegi project), or
>use
>reflection or other technique at runtime to dynamically adapt to the Spring
>version.
>
>  - Andy
>
>On Tuesday 19 April 2005 12:11 pm, Juergen Hoeller wrote:
>
>
>>Hi Ben,
>>
>>as Matt has noticed, there is a change in Spring 1.2 RC2 that breaks Acegi
>>Security:
>>
>><matt>
>>It's cool to see that the Spring Team has released 1.2 RC2, but there's a
>>change that causes Acegi Security (v0.8.1) to fail.
>>
>>• refactored static PathMatcher class into PathMatcher interface and
>>AntPathMatcher implementation
>>
>>This change seems to cause this issue with Acegi Security. Right now, I
>>have Spring 1.2 RC1 and Hibernate 3.0.1 bundled into AppFuse 1.8. I was
>>hoping to upgrade to Spring 1.2 RC2, but it doesn't look like this will
>>work - unless the Acegi Team releases a new version that supports 1.2 RC2
>>(hint, hint ;-). </matt>
>>
>>I've refactored the static PathMatcher into a PathMatcher interface and
>>AntPathMatcher implementation class, after repeated questions in that
>>respect. I must admit I haven't really considered that other *libraries*
>>might access that code, just that users might.
>>
>>Hence, I've accepted the tradeoff of backwards-incompatibility for 1.2,
>>because it's easy enough for users to migrate affected code - and the
>>utilities in Spring's util package are considered somewhat for internal
>>
>>
>use
>
>
>>in the first place. But unfortunately, there's the issue of collaborating
>>libraries...
>>
>>Anyway, I would like to keep the refactored PathMatcher, so I'd like to
>>encourage you to release an Acegi update release (0.8.2?) at your earliest
>>convenience, ideally alongside Spring 1.2 final (in about two weeks) or
>>earlier. Users should have a fully working combo then again.
>>
>>Sorry for the inconveniences caused,
>>
>>Juergen
>>
>>



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer

Re: [Springframework-developer] Spring forum down!

[Matthew E. P. <mat...@me...>]

Ross, if you can reply with a the exact page that is causing problems,=20=

we can chase this down.  Feel free to reply off-list.


Cheers,
   Matthew

On Apr 20, 2005, at 2:58 AM, Mason, Ross wrote:

> Hey guys,
> =A0
> I'm getting a 404 on http://forum.springframework.org/
> =A0
> Ross

Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security

[Juergen H. <ju...@in...>]

Yes, that's what I've been thinking of too...

I'd prefer to reimplement FilterToBeanProxy as DelegatingFilterProxy in
org.springframework.web.filter, though, in a stripped-down fashion: deriving
from GenericFilterBean, offering a "targetBeanName" bean property,
defaulting to the filter name as target bean name.

The name "DelegatingFilterProxy" is analogous to our "DelegatingActionProxy"
in org.springframework.web.struts. We also have a "DelegatingDataSource",
"DelegatingMessageSource", etc.

I'm not sure whether we should keep the class-based delegate lookup. If we
do, I would introduce a "targetBeanClass" property, with a strict check - if
there isn't exactly one matching bean in the context, we'll fail. However, I
prefer lookup by bean name, in particular if we simply use the filter name
as target bean name.

Regarding the lifecycle concerns: init and destroy should probably always be
delegated to the target Filter bean instance. If the target Filter uses bean
lifecycle callbacks, it's gonna implement Filter.init/destroy as empty
anyway. So I guess we don't really need an explicit config setting for this.

I've kept the lazy initialization of the delegate Filter, which was
obviously introduced for the case where the Filter proxy gets started before
the root WebApplicationContext (which can happen with ContextLoaderServlet).

I've just prototyped this; if we agree on the approach, I could document it
and commit it quickly. I guess the main question is whether the above
DelegatingFilterProxy suggestion is sufficient for Acegi's needs. Could it
replace the current FilterToBeanProxy, as used by Acegi?

As a side note: For completeness' sake, we could also add a
DelegatingServletProxy to org.springframework.web.servlet, providing similar
delegation to a target Servlet bean instance. However, that would probably
be a rather academic exercise.

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, April 20, 2005 4:27 AM
To: spr...@li...
Subject: Re: [Springframework-developer] Spring 1.2 RC2 and Acegi
Security


This reminds me that Spring 1.2 is probably the appropriate time for
Acegi's FilterToBeanProxy to move over from Acegi to Spring. While I
know we deferred on this before because you had some concerns about
lifecycle owneship, in practice the class is very useful, and it (or
something like it) really belongs in Spring...

Colin

Juergen Hoeller wrote:

>Yes, there are essentially these two options: either require Spring 1.2 as
>of the next Acegi release (which should probably be called 0.9 then), or
>copy the old PathMatcher over. In the former case, Acegi should follow the
>new Spring pattern there: components that need path-matching functionality
>receive a PathMatcher implementation through dependency injection, using an
>AntPathMatcher as default.
>
>BTW, it would be good to unify the codebases in the mid term, for example
>moving some of the generic Acegi utility stuff over to the main Spring
>codebase. IMO, we should do this for Acegi Security 1.0 at the latest, with
>Acegi concentrating on the actual security support only. In any case, I
>guess it's inevitable to depend on a specific Spring release level at some
>point.
>
>Juergen
>
>
>-----Original Message-----
>From: spr...@li...
>[mailto:spr...@li...]On Behalf
>Of Andy Depue
>Sent: Tuesday, April 19, 2005 10:52 PM
>To: spr...@li...
>Subject: Re: [Springframework-developer] Spring 1.2 RC2 and Acegi
>Security
>
>
>I should note that I ran across this earlier and posted a patch to the
Acegi
>developer's list (see
>http://article.gmane.org/gmane.comp.java.springframework.acegisecurity.deve
l
>/864 ).
>I didn't officially submit this patch, as it breaks backward compatibility
>with Spring (it will only run with the very latest Spring).  If a goal of
>the
>Acegi project is to maintain such compability, it will probably either want
>to remove the dependency (by copying the code into the Acegi project), or
>use
>reflection or other technique at runtime to dynamically adapt to the Spring
>version.
>
>  - Andy
>
>On Tuesday 19 April 2005 12:11 pm, Juergen Hoeller wrote:
>
>
>>Hi Ben,
>>
>>as Matt has noticed, there is a change in Spring 1.2 RC2 that breaks Acegi
>>Security:
>>
>><matt>
>>It's cool to see that the Spring Team has released 1.2 RC2, but there's a
>>change that causes Acegi Security (v0.8.1) to fail.
>>
>>• refactored static PathMatcher class into PathMatcher interface and
>>AntPathMatcher implementation
>>
>>This change seems to cause this issue with Acegi Security. Right now, I
>>have Spring 1.2 RC1 and Hibernate 3.0.1 bundled into AppFuse 1.8. I was
>>hoping to upgrade to Spring 1.2 RC2, but it doesn't look like this will
>>work - unless the Acegi Team releases a new version that supports 1.2 RC2
>>(hint, hint ;-). </matt>
>>
>>I've refactored the static PathMatcher into a PathMatcher interface and
>>AntPathMatcher implementation class, after repeated questions in that
>>respect. I must admit I haven't really considered that other *libraries*
>>might access that code, just that users might.
>>
>>Hence, I've accepted the tradeoff of backwards-incompatibility for 1.2,
>>because it's easy enough for users to migrate affected code - and the
>>utilities in Spring's util package are considered somewhat for internal
>>
>>
>use
>
>
>>in the first place. But unfortunately, there's the issue of collaborating
>>libraries...
>>
>>Anyway, I would like to keep the refactored PathMatcher, so I'd like to
>>encourage you to release an Acegi update release (0.8.2?) at your earliest
>>convenience, ideally alongside Spring 1.2 final (in about two weeks) or
>>earlier. Users should have a fully working combo then again.
>>
>>Sorry for the inconveniences caused,
>>
>>Juergen
>>
>>



-------------------------------------------------------
This SF.Net email is sponsored by: New Crystal Reports XI.
Version 11 adds new functionality designed to reduce time involved in
creating, integrating, and deploying reporting solutions. Free runtime info,
new features, or free trial, at: http://www.businessobjects.com/devxi/728
_______________________________________________
Springframework-developer mailing list
Spr...@li...
https://lists.sourceforge.net/lists/listinfo/springframework-developer