Jeanfrancois Arcand wrote:
>> I'll remove stuff in the Cluster API, modify some of the session >> classes to allow extending them in a different package, and everything >> in the core is then independent of the clustering. > > No security problems if we kept the current package protection > mechanism. Making those classes "public" can be dangerous if the package > protection is not enabled. That depends on the class loader - if tomcat is embedded in something else ( like J2EE or some other app ) I'm not sure how it'll protect this. Also, a number of classes are public because they are intended to be used, and a number of security problems may happen ( as we learned ) even if the class is not accessible ( like the recent web.xml entity issues ). >>> Bloat is not about MB or storage. It's about code complexity, potential >>> security, etc. >> >> >> Ok. All distributions need to be thought as secure, though. > > Does that implies re-writting the current set of classloader? It might > be a good time to revisit classloader and security :-) Do you have so much free time :-) ? I'm +1 BTW. If we reach consensus on JMX - it may be a good idea to use its class loading mechanism, or something very close - the model in theory is very good. You have full control ( using mlet tags or API ) over the class loaders and hierarchy. >> +1 for JMX (as there's MX4J); as well as JNDI, BTW. > > +1 I'll send a separate mail with a VOTE subject. Costin -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
