Actually Bootstrap has a comment // Copied from ExceptionUtils since that class is not visible during start
So it seems like perhaps the change should be ported. - Ray On Fri, Jun 12, 2020 at 10:45 PM Raymond Auge <raymond.a...@liferay.com> wrote: > 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) > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
