On Fri, Dec 7, 2018 at 6:53 PM Mark Thomas <ma...@apache.org> wrote: > On 06/12/2018 14:08, Rémy Maucherat wrote: > > On Thu, Dec 6, 2018 at 2:42 PM Mark Thomas <ma...@apache.org> wrote: > > > >>> Ok, why not. > >> > >> Apart from the fact it would mean touching almost every class in Tomcat? > >> > >> Seriously, the more I think about it the more I like it. Move the res > >> package from o.a.tomcat.util.res o.a.juli.res and deprecate the old one > >> along with the copy in tribes. And then remove the old ones in 10.x > >> > > > > There's another problem with that startup package where the bundles of > the > > actual bootstrap are shared with the rest (ContextConfig, etc). Also, is > it > > really good to start shipping plenty of resources in a "small" bootstrap > ? > > Open questions. > > Indeed. I don't think we are under any pressure to find an answer in a > hurry. We can keep discussing until we have a solution that everyone is > happy with. > > Should we move the bootstrap classes to a separate package? > > That won't address the issues of how to package the resource files for > that package. > > Size shouldn't be too much of an issue with the scope limited to just > bootstrap. But if they are all in a single JAR disabling a language by > deleting the JAR won't work for the bootstrap resources. I don't think > per language bootstrap resource JARs are the solution. >
As a refinement, the bootstrap resources could go in a subpackage of startup, that avoids any API change issue. For packaging, I would put them in bootstrap.jar, there's no real way to do otherwise. Anyway, it's not really important, there's nothing very interesting in those strings, so maybe it's only a rhetorical issue and nothing will be done. I still have about 200 strings to go for the core Tomcat, excluding DBCP and others. Rémy
