Please see updated https://github.com/apache/tomcat/pull/296
- Ray On Sat, Jun 13, 2020 at 3:35 PM Raymond Auge <raymond.a...@liferay.com> wrote: > 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 >> >> -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
