Re: [Proposal] Having a Tomcat.security file.

Jean-Francois Arcand wrote: Hi, I've re-factored Catalina.java and CatalinaService.java and merge the security code into a single class: o.a.c.security.SecurityConfig. This class will manage all the package access/definition security properties. Actually, the list of package

[Proposal] Having a Tomcat.security file.

Hi, I've re-factored Catalina.java and CatalinaService.java and merge the security code into a single class: o.a.c.security.SecurityConfig. This class will manage all the package access/definition security properties. Actually, the list of package access/definition are harcoded in that

Re: [Proposal] Having a Tomcat.security file.

Jean-Francois Arcand wrote: Hi, I've re-factored Catalina.java and CatalinaService.java and merge the security code into a single class: o.a.c.security.SecurityConfig. This class will manage all the package access/definition security properties. Works for me! You might consider moving

Re: [Proposal] Having a Tomcat.security file.

+1 on the proposal. However I'm not sure about the change on o.a.t.util, and neither the other jk packages. I do agree the package should be sealed to protect package fields and methods. But I don't think it should be restricted - or at least it should be possible for webapps to include the

Re: [Proposal] Having a Tomcat.security file.

Glenn Nielsen wrote: Jean-Francois Arcand wrote: Hi, I've re-factored Catalina.java and CatalinaService.java and merge the security code into a single class: o.a.c.security.SecurityConfig. This class will manage all the package access/definition security properties. Works for me!