Hey Mark, I tested those changes and they solve the packaging issue for both jpms and OSGi.
I'll update the pr to reflect the change later today I hope. I did encounter some further jpms related issues but those were beyond packaging and need other questions answered before moving forward. - Ray On Sat, Jun 13, 2020, 12:49 Mark Thomas, <ma...@apache.org> wrote: > 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 > >
