|
|
|
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: springframework-developer-admin <at> lists.sourceforge.net
[mailto:springframework-developer-admin <at> lists.sourceforge.net]On Behalf
Of Juergen Hoeller
Sent: Wednesday, April 20, 2005 10:53 AM
To: springframework-developer <at> lists.sourceforge.net
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:juergen <at> interface21.com]
Sent: Wednesday, April 20, 2005 10:06 AM
To: springframework-developer <at> lists.sourceforge.net
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: springframework-developer-admin <at> lists.sourceforge.net
[mailto:springframework-developer-admin <at> lists.sourceforge.net]On Behalf
Of Colin Sampaleanu
Sent: Wednesday, April 20, 2005 4:27 AM
To: springframework-developer <at> lists.sourceforge.net
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: springframework-developer-admin <at> lists.sourceforge.net
>[mailto:springframework-developer-admin <at> lists.sourceforge.net]On Behalf
>Of Andy Depue
>Sent: Tuesday, April 19, 2005 10:52 PM
>To: springframework-developer <at> lists.sourceforge.net
>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
Springframework-developer <at> lists.sourceforge.net
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
Springframework-developer <at> lists.sourceforge.net
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
|
|
