On 13/06/2020 03:53, Raymond Auge wrote: > 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.
Agreed. So if we do that and make the other changes I outlined where does that leave things from a JPMS / OSGi point of view? Mark > > - Ray > > On Fri, Jun 12, 2020 at 10:45 PM Raymond Auge <raymond.a...@liferay.com > <mailto: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 > <mailto: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> > > <mailto: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>> > > >> <mailto: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>> > > >> <mailto: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>> > > >> <mailto: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>> > > >> <mailto: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>> > > >> <mailto: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> > > <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>> > > > > > > > > > > --------------------------------------------------------------------- > > 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) > > > --------------------------------------------------------------------- > 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
