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