Hey Mark, I'll have to get back to this convo in a day or so.
I'll test your theory but at first glance it sounds like going in the right direction. - Ray On Thu, Jun 11, 2020 at 5:08 PM Mark Thomas <ma...@apache.org> wrote: > 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 > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
