> -----Original Message----- > From: Rickard Öberg [mailto:[EMAIL PROTECTED]] > > Chris Nokleberg wrote: > >>Here's another way: define the roles that are allowed to access an > >>action in xwork.xml, and create an interceptor that checks > it. Then it > >>can work exactly like how web.xml works, except it can do > so for the > >>case where an unsecure action calls a secure action too. > > > > That is a lot of extra machinery where pinning the action > would work > > instead. > > "A lot of extra machinery"?! You declare what roles may access it in > xwork.xml. One could even provide defaults at the <package> > level. How > is that a lot of extra machinery?
Creating an extra interceptor to re-create J2EE declarative security is at least some extra machinery compared to just using what is there. I'm not saying that it's bad, in fact I kind of like the idea of restricting which roles can run packages of actions, but I would prefer to add that IN ADDITION to being able to pin packages to certain URL paths to enable the use of J2EE declarative security and make it optional. It's sounding to me like we really need 2 configuration files here: 1) xwork.xml : the standard xwork configuration which applies to all Dispatcher types. This would include package and action configuration 2) xwork-web.xml : configures web specific configurations, such as URL paths to pin packages, and view mappings The reason I would say to put the view mappings in the xwork-web.xml is because you might want to use the same set of actions for web and Swing based apps, and you'd want to have different view mappings. Jason ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Opensymphony-webwork mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/opensymphony-webwork
