There is one difference between org.apache.tomcat.util.ExceptionUtils.handleThrowable(Throwable)
and org.apache.catalina.startup.Bootstrap.handleThrowable(Throwable) that is that ExceptionUtils also swallows StackOverflowError while Bootstrap does not. Should that be ported over or is it a deal breaker? An option would be to add an additional method to Bootstrap that behaves like ExceptionUtils. - Ray On Fri, Jun 12, 2020 at 9:27 AM Mark Thomas <ma...@apache.org> wrote: > On 12/06/2020 14:15, Raymond Auge wrote: > > 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. > > No rush. I'd rather take time and get this right. > > Thanks, > > Mark > > > > > > - Ray > > > > On Thu, Jun 11, 2020 at 5:08 PM Mark Thomas <ma...@apache.org > > <mailto: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> > > >> <mailto: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> > > >> <mailto: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> > > >> <mailto: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> > > >> <mailto: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> > > >> <mailto: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 > > <mailto:dev-unsubscr...@tomcat.apache.org> > > > For additional commands, e-mail: dev-h...@tomcat.apache.org > > <mailto:dev-h...@tomcat.apache.org> > > > > > > > > > --------------------------------------------------------------------- > > 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) > > > --------------------------------------------------------------------- > 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)