springframework-developer

[Springframework-developer] Spring 1.2 RC2 and Acegi Security

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

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

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

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

Everybody,

Please report any other libraries that have issues with the refactored
PathMatcher, or with any other changes in Spring 1.2 RC1/RC2. We should
catch all of those before the 1.2 final release.

If there are severe obstacles caused by this, we could also revert
PathMatcher back to a static utility class, as of 1.2 final. I would really
prefer to keep it as interface + implementation, though, which it should
have been from the start,

Juergen


-----Original Message-----
From: spr...@li...
[mailto:spr...@li...]On Behalf
Of Juergen Hoeller
Sent: Tuesday, April 19, 2005 9:11 PM
To: ben...@ac...
Cc: spr...@li...
Subject: [Springframework-developer] Spring 1.2 RC2 and Acegi Security


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 1.2 RC2 and Acegi Security

[Andy D. <an...@ma...>]

I should note that I ran across this earlier and posted a patch to the Aceg=
i=20
developer's list (see=20
http://article.gmane.org/gmane.comp.java.springframework.acegisecurity.deve=
l/864 ). =20
I didn't officially submit this patch, as it breaks backward compatibility=
=20
with Spring (it will only run with the very latest Spring).  If a goal of t=
he=20
Acegi project is to maintain such compability, it will probably either want=
=20
to remove the dependency (by copying the code into the Acegi project), or u=
se=20
reflection or other technique at runtime to dynamically adapt to the Spring=
=20
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.
>
> =95 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 u=
se
> 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 1.2 RC2 and Acegi Security

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

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.devel
/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

[Luke T. <ne...@fr...>]

Hi,

I discussed this with Ben the other night and the Acegi Maven build is 
now building against a Spring daily snapshot (generated by the Spring 
Maven build) so any inconsistencies will hopefully be detected right away.

I modified the Acegi code earlier today to use an explicit 
AntPathMatcher to get the build working again. I don't think Ben will 
have any worries about requiring Spring 1.2 for the next release but it 
should be easy to accomodate either way.

Luke.

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


-- 
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk

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

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

Hi Luke / Ben

Any idea when an official  0.9 or 0.8.2 Acegi build will be planned...
(I assume in the next few weeks to coincide with the Spring 1.2 release ?)

Cheers
Mark



                                                                           
             Luke Taylor                                                   
             <negaton@freesurf                                             
             .ch>                                                       To 
             Sent by:                  spr...@li... 
             springframework-d         rceforge.net                        
             eveloper-admin@li                                          cc 
             sts.sourceforge.n                                             
             et                                                    Subject 
                                       Re: [Springframework-developer]     
                                       Spring 1.2 RC2 and Acegi Security   
             04/19/2005 05:30                                              
             PM                                                            
                                                                           
                                                                           
             Please respond to                                             
             springframework-d                                             
                 eveloper                                                  
                                                                           
                                                                           




Hi,

I discussed this with Ben the other night and the Acegi Maven build is
now building against a Spring daily snapshot (generated by the Spring
Maven build) so any inconsistencies will hopefully be detected right away.

I modified the Acegi code earlier today to use an explicit
AntPathMatcher to get the build working again. I don't think Ben will
have any worries about requiring Spring 1.2 for the next release but it
should be easy to accomodate either way.

Luke.

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


--
  Luke Taylor.                      Monkey Machine Ltd.
  PGP Key ID: 0x57E9523C            http://www.monkeymachine.ltd.uk


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

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

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.devel
>/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
>>    
>>

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

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

[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

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

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

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

Colin,

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

I rather see it like this: If there is no compelling use case for specifying
the fully qualified class name of the target filter instead of the bean name
there, I'd like to only provide the option to specify the target bean name
(which makes the interaction easier to track and results in shorter
configuration).

>>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'm not sure if I understand that use case. Subclassing a Filter is
certainly possible, and if someone defines a DelegatingFilterProxy for that
class, I would expect the Filter lifecycle to always be called there, as the
target *is* a Filter. If someone wants to suppress those Filter.init/destroy
calls, there's always the option to override those methods with empty
implementations.

Alternatively, any existing Filter can be held as a delegate within some
wrapper class, whether exposing the Filter interface or not. That allows to
have full control over the lifecycle, only calling stuff on the delegate
that you really want to call. I consider this preferable to subclassing an
existing Filter if you don't want to inherit the existing Filter's lifecycle
behavior.

Juergen

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

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

Juergen Hoeller wrote:

>Colin,
>
>  
>
>>>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.
>>    
>>
>
>I rather see it like this: If there is no compelling use case for specifying
>the fully qualified class name of the target filter instead of the bean name
>there, I'd like to only provide the option to specify the target bean name
>(which makes the interaction easier to track and results in shorter
>configuration).
>  
>
Well, I think the class name has some value for part of the same reason 
byType matching exists in the context. I mean it's not autowired in this 
casse, but it's still a simpler config sometimes. If you know there 
should be exactly one filter of that type (which is usually the case for 
most filters), then you can just put the classname. And if you ever 
refactor, the IDE will take care of fixing the name, etc. I'm not 
incredibly hung up on this, but it probably provides some value.

>  
>
>>>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'm not sure if I understand that use case. Subclassing a Filter is
>certainly possible, and if someone defines a DelegatingFilterProxy for that
>class, I would expect the Filter lifecycle to always be called there, as the
>target *is* a Filter. If someone wants to suppress those Filter.init/destroy
>calls, there's always the option to override those methods with empty
>implementations.
>
>Alternatively, any existing Filter can be held as a delegate within some
>wrapper class, whether exposing the Filter interface or not. That allows to
>have full control over the lifecycle, only calling stuff on the delegate
>that you really want to call. I consider this preferable to subclassing an
>existing Filter if you don't want to inherit the existing Filter's lifecycle
>behavior.
>  
>
I guess my main objection is that it just seems weird to be calling 
lifecycle methods you know don't do anything (or shouldn't do anything), 
if you know Spring is really managing the lifecycle. But I guess it 
doesn't hurt. This also means you can't make the Filter interface 
destroy() method the bean destroy method called by the bean container 
(since it would be called twice), but I guess that's not that big a deal.


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

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

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

Colin

>>I rather see it like this: If there is no compelling use case for
specifying
>>the fully qualified class name of the target filter instead of the bean
name
>>there, I'd like to only provide the option to specify the target bean name
>>(which makes the interaction easier to track and results in shorter
>>configuration).
>>
>>
>Well, I think the class name has some value for part of the same reason
>byType matching exists in the context. I mean it's not autowired in this
>casse, but it's still a simpler config sometimes. If you know there
>should be exactly one filter of that type (which is usually the case for
>most filters), then you can just put the classname. And if you ever
>refactor, the IDE will take care of fixing the name, etc. I'm not
>incredibly hung up on this, but it probably provides some value.

I think the main difference is that autowire-by-type determines the types to
match through *reflection*, with no need to specify the class name
explicitly. Specifying the target class name instead of the target bean name
in web.xml just does't feel appropriate to me.

I guess my main concern is that we don't support this for any other Filters
that we ship either: OpenSessionInViewFilter,
OpenPersistenceManagerInViewFilter, MultipartFilter all delegate to a
Spring-managed bean, to be found by name rather than by type. If we
introduce by-class lookup to any Filter, we would have to do this for all
these Filters, to stay consistent.

>I guess my main objection is that it just seems weird to be calling
>lifecycle methods you know don't do anything (or shouldn't do anything),
>if you know Spring is really managing the lifecycle. But I guess it
>doesn't hurt. This also means you can't make the Filter interface
>destroy() method the bean destroy method called by the bean container
>(since it would be called twice), but I guess that's not that big a deal.

OK, convinced. I have added a "targetFilterLifecycle" flag to
DelegatingFilterProxy, specifying whether the servlet container will control
the lifecycle of the target Filter bean. Default is false, similar to
Acegi's original FilterToBeanProxy.

Of course, the Spring bean container can never populate the
init(FilterConfig) method of a Filter bean. But admittedly, this often isn't
needed: that method can be considered an alternative to bean-style
initialization, not accessing the FilterConfig object at all.

Juergen