OK. I would be a lot happier moving to jaxb objects for this. How much work do you think it would be to use jaxb for web.xml? I'd think the major problem would be in the naming builders. I wonder if we could put some default jaxb <> xmlbeans conversion methods in the AbstractNamingBuilder and each builder could override one to do the actual processing.
I think we need to change when the security calculations take place so the conversion from constraints to permissions happens once after these runtime constraints are added. Even after we've added the security constraints, we might need a way of programatically adding principal<> role mappings as well. Do you think it would be practical to allow adding/removing security constraints and principal<> role mappings after the app has started? I was thinking of letting you change the security model with arbitrary calls and then have "commit" method that would replace the existing model with the new, modified model. thanks! david jencks On Apr 20, 2010, at 7:39 AM, Ivan wrote: > Hi, > While working to support some new security configurations in Servlet 3.0 > web deployment xml file, I realized that we might need to support dynamic > security configuration for web access control. As in Servlet 3.0, it is > allowed to configure the security constrait while initializing the web > modules using ServletRegistration.Dynamic interface. However, in the past, > all of the permissions are calculated in the deployment process. So now, from > my view, we might need to re-envaluate the security constraint configurations > from scratch. Currently, My initial mind is to create a Geronimo > servletcontext and servletregistration.dynamic impl based on Tomcat's , and > add all the new security configuration data to the xmlbean object while users > invoke setSerlvetSecurity methods, then we re-calculate the permissions again. > Anyone has other better ideas ? Thanks ! > -- > Ivan
