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)

Reply via email to