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 affected. I
Is there anything on action 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,
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
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.
I wanted to know if there was any technical reason why dependency versions
are scattered throughout the POMs? I find it much cleaner to use
dependencyManagement in the S1 parent POM. But I don't want to make any
change unless I find out otherwise first.
Paul
On Dec 9, 2007 12:18 PM, Paul Benedict [EMAIL PROTECTED] wrote:
I wanted to know if there was any technical reason why dependency versions
are scattered throughout the POMs? I find it much cleaner to use
dependencyManagement in the S1 parent POM. But I don't want to make any
change unless I
On Dec 9, 2007 7:42 AM, Tom Schneider [EMAIL PROTECTED] wrote:
Just wanted to chime in here. I have very specific goals that I am
trying to achieve, so I thought I would explain them in detail. (this
is something I've been tasked with at work)
[snip]
So that's where I'm currently at. I
