On 12/11/07, Brian Pontarelli <[EMAIL PROTECTED]> wrote:
> At first I thought this might be a problem because SmartURLs was
> sub-classing the ActionConfig object in order to add some additional
> information for performance reasons. However, I have a feeling that I
> can remove the sub-class. All
Don Brown wrote:
Since the commit for this feature involved a rather large XWork change
(properly immutable configuration objects [1]), I decided to commit
what I have and discuss the next steps.
First, due the aforementioned fix [1], Brian, your SmartURL's
migration work will probably be most a
On Dec 9, 2007 9:44 AM, Tom Schneider <[EMAIL PROTECTED]> wrote:
> CMA = container managed authentication for those who haven't memorized
> every three letter acronym under the sun.
>
> What about using an s2 interceptor to enforce role security?
This is what I've done in the past. Yes, it works.
CMA = container managed authentication for those who haven't memorized
every three letter acronym under the sun.
What about using an s2 interceptor to enforce role security? That way
you could have an implementation for whatever security mechanism your
using and it's not tied to the struts co
Is there anything on that allows restricting roles? I
remember this being in S1 and I'm unsure if it exists in S2. If not,
it's something I believe we should add as I believe it's useful when
using CMA. When using Spring Security, I generally keep all my
configuration in my context file, but I can
