On 11/06/2020 21:59, Mark Thomas wrote: > On 11/06/2020 21:24, Raymond Auge wrote: >> This can totally be fixed in configuration. There is no problem. I just >> wanted to make sure that in doing so we wouldn't just be pushing some >> dirt under the rug so to speak. > > I'm concerned we might be doing exactly that now we are heading into a > JPMS world and this seems like an opportunity to pause and see if there > is a better way. > > I've yet to get my head around JPMS and I might be mis-remembering some > of the things I have read. > > bootstrap.jar has everything it needs to start, create the class loader > hierarchy, switch to the catalinaLoader (which can see all the JARs > rather than just bootstrap.jar and tomcat-juli.jar) and then continue > with start-up. > > It does things this way because the class loader hierarchy and the > configuration of the class loaders is configurable. So we can't just put > everything on the class path before starting the JVM. > > Any static analysis of bootstrap.jar is always going to show it having > dependencies that won't be visible until Tomcat starts and the > catalinaLoader is up and running. To what extent does this cause > complications for JPMS and/or OSGi? > > Is this completely manageable with configuration? If it is, I think I'd > lean towards a configuration based solution primarily for backwards > compatibility reasons. What are the arguments against this approach? > > If this completely manageable with configuration are there any > particular classes that are causing more than their fair share of pain > where a small packaging change would provide a relatively large benefit?
Sorry. More thoughts occurred to me as I looked at the PRs again. If we created o.a.c.startup.Constants, defined the constants required by the bootstrap classes there and then referenced those from o.a.c.Globals would that help? Is it Tool's use of ExceptionUtils that is causing that class to be needed? If so would making Bootstrap.handleThrowable() package private and using that instead help? Mark > > Mark > > >> >> :) >> >> - Ray >> >> On Thu, Jun 11, 2020 at 3:25 PM Raymond Auge <raymond.a...@liferay.com >> <mailto:raymond.a...@liferay.com>> wrote: >> >> To be clear, it's not necessarily having _all of a package_. It's >> more about all the reachable class references. For instance jdeps >> looks at classes and finds any reachable references. So does bnd for >> calculating OSGi metadata. >> >> So the issue is not really about packages, it's about having missing >> class references and whether those should be elided in >> configuration, or simple fixed in packaging (which again does not >> necessarily mean full packages :) >> >> - Ray >> >> On Thu, Jun 11, 2020 at 3:20 PM Rémy Maucherat <r...@apache.org >> <mailto:r...@apache.org>> wrote: >> >> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas <ma...@apache.org >> <mailto:ma...@apache.org>> wrote: >> >> Hi, >> >> As discussed in PR#298 [1], properly/fully/correctly >> supporting JPMS / >> OSGi gets trickier than necessary with the bootstrap JAR >> because of the >> way we currently package it with the minimum that it needs >> and duplicate >> some classes. >> >> My simplistic understanding is that having all of a Java >> package in a >> single JAR makes JPMS and OSGi a lot simpler. Further, our >> current >> approach may not be 100% compatible with one or both of them. >> >> The trade-offs involved here are: >> - having all of a package in a JAR simplifies JPMS and OSGi >> - We want to keep the bootstrap JAR small (is this much of a >> concern?) >> - We don't want duplicate code (maintenance overhead) >> - Bootstrap uses various utility functions from the Tomcat >> code base >> >> I'm wondering if there is a better approach we could adopt >> that makes >> JPMS / OSGi simpler without compromising too much on the >> other trade-offs. >> >> The sort of thing I have in mind is: >> - move everything out of o.a.c.startup that doesn't need to >> be there to >> either some new package (name TBD) or an existing package >> >> >> That means way too many risky changes IMO, the listeners in the >> startup package are often extended to add features so they need >> to remain in the catalina.startup package. >> >> >> - create an o.a.c.startup.util package and, during the build >> process, >> copy and package rename any utility classes the remaining >> classes in >> o.a.c.startup depend on >> >> >> Good idea, when I read your requirements, I thought about >> package renaming. So I think we could use package renaming for >> everything that bootstrap.jar has to a tomcat.bootstrap or >> catalina.bootstrap package. >> >> Rémy >> >> >> >> The end result should be a nice clean mapping of packages to >> JARs. >> >> Thoughts? >> >> Mark >> >> >> >> [1] https://github.com/apache/tomcat/pull/298 >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org >> <mailto:dev-unsubscr...@tomcat.apache.org> >> For additional commands, e-mail: dev-h...@tomcat.apache.org >> <mailto:dev-h...@tomcat.apache.org> >> >> >> >> -- >> *Raymond Augé* >> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) >> Senior Software Architect *Liferay, Inc.* >> <http://www.liferay.com> (@Liferay) >> >> >> >> -- >> *Raymond Augé* >> <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) >> Senior Software Architect *Liferay, Inc.* >> <http://www.liferay.com> (@Liferay) > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
