I'm not doing the work, but if it were me, I'd try to do it as a resolver first due to the increased flexibility to pass method parameters.
I wouldn't think it'd be any harder to extend or configure a resolver if it were designed properly. However, it's easier to pass the security bean around, and use it programmically. But either one is acceptable to me. On 8/16/06, Cagatay Civici <[EMAIL PROTECTED]> wrote:
Hi, > There's no new functionality here, and it's not reducing any effort in > my opinion. This assumes that we go forward and created a resolver > or a bean. A resolver or a bean makes perfect sense, but a component > doesn't. > So we say goodbye to s:secure :) Ok a bean is a lot more simpler to implement than a resolver for sure, also I'd not favor adding a new resolver to the resolver chain. So +1 for the bean, extending and maintaining the bean is also simpler. I'm planning to open a jira issue and assign it to myself after we all agree on the choice. Cheers, Cagatay On 8/16/06, Mike Kienenberger <[EMAIL PROTECTED]> wrote: > On 8/16/06, Martin Marinschek <[EMAIL PROTECTED]> wrote: > > You're being polemic, Mike ;) > > You're not the first person who's told me that :-) > > > P.S.: What do we go for now? A bean or a resolver? What about > > extending the thing - it would be easier with a bean, right? > > Dunno. Not sure of the details of how a resolver is implemented, but > it seems like it could be configured as easily as anything else. A > resolver will allow you to get around the method parameter > limitations. >
