You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2020/06/11 19:01:04 UTC
Bootstrap and modules
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
- 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
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bootstrap and modules
Posted by Raymond Auge <ra...@liferay.com>.
Please see updated https://github.com/apache/tomcat/pull/296
- Ray
On Sat, Jun 13, 2020 at 3:35 PM Raymond Auge <ra...@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.auge@liferay.com
>> > <ma...@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 <markt@apache.org
>> > <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 <markt@apache.org
>> > <ma...@apache.org>
>> > > <mailto:markt@apache.org <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.auge@liferay.com
>> > <ma...@liferay.com>
>> > <mailto:raymond.auge@liferay.com <mailto:
>> raymond.auge@liferay.com>>
>> > > >> <mailto:raymond.auge@liferay.com
>> > <ma...@liferay.com>
>> > > <mailto:raymond.auge@liferay.com
>> > <ma...@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
>> > > <remm@apache.org <ma...@apache.org>
>> > <mailto:remm@apache.org <ma...@apache.org>>
>> > > >> <mailto:remm@apache.org <ma...@apache.org>
>> > <mailto:remm@apache.org <ma...@apache.org>>>> wrote:
>> > > >>
>> > > >> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas
>> > > <markt@apache.org <ma...@apache.org>
>> > <mailto:markt@apache.org <ma...@apache.org>>
>> > > >> <mailto:markt@apache.org
>> > <ma...@apache.org> <mailto:markt@apache.org
>> > <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-unsubscribe@tomcat.apache.org
>> > <ma...@tomcat.apache.org>
>> > > <mailto:dev-unsubscribe@tomcat.apache.org
>> > <ma...@tomcat.apache.org>>
>> > > >> <mailto:dev-unsubscribe@tomcat.apache.org
>> > <ma...@tomcat.apache.org>
>> > > <mailto:dev-unsubscribe@tomcat.apache.org
>> > <ma...@tomcat.apache.org>>>
>> > > >> For additional commands, e-mail:
>> > > dev-help@tomcat.apache.org
>> > <ma...@tomcat.apache.org>
>> > <mailto:dev-help@tomcat.apache.org
>> > <ma...@tomcat.apache.org>>
>> > > >> <mailto:dev-help@tomcat.apache.org
>> > <ma...@tomcat.apache.org>
>> > > <mailto:dev-help@tomcat.apache.org
>> > <ma...@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-unsubscribe@tomcat.apache.org
>> > <ma...@tomcat.apache.org>
>> > > <mailto:dev-unsubscribe@tomcat.apache.org
>> > <ma...@tomcat.apache.org>>
>> > > > For additional commands, e-mail:
>> > dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
>> > > <mailto:dev-help@tomcat.apache.org
>> > <ma...@tomcat.apache.org>>
>> > > >
>> > >
>> > >
>> > >
>> >
>> ---------------------------------------------------------------------
>> > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> > <ma...@tomcat.apache.org>
>> > > <mailto:dev-unsubscribe@tomcat.apache.org
>> > <ma...@tomcat.apache.org>>
>> > > For additional commands, e-mail:
>> > dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
>> > > <mailto:dev-help@tomcat.apache.org
>> > <ma...@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-unsubscribe@tomcat.apache.org
>> > <ma...@tomcat.apache.org>
>> > For additional commands, e-mail: dev-help@tomcat.apache.org
>> > <ma...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Re: Bootstrap and modules
Posted by Raymond Auge <ra...@liferay.com>.
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.auge@liferay.com
> > <ma...@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 <markt@apache.org
> > <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 <markt@apache.org
> > <ma...@apache.org>
> > > <mailto:markt@apache.org <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.auge@liferay.com
> > <ma...@liferay.com>
> > <mailto:raymond.auge@liferay.com <mailto:
> raymond.auge@liferay.com>>
> > > >> <mailto:raymond.auge@liferay.com
> > <ma...@liferay.com>
> > > <mailto:raymond.auge@liferay.com
> > <ma...@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
> > > <remm@apache.org <ma...@apache.org>
> > <mailto:remm@apache.org <ma...@apache.org>>
> > > >> <mailto:remm@apache.org <ma...@apache.org>
> > <mailto:remm@apache.org <ma...@apache.org>>>> wrote:
> > > >>
> > > >> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas
> > > <markt@apache.org <ma...@apache.org>
> > <mailto:markt@apache.org <ma...@apache.org>>
> > > >> <mailto:markt@apache.org
> > <ma...@apache.org> <mailto:markt@apache.org
> > <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-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > > <mailto:dev-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>>
> > > >> <mailto:dev-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > > <mailto:dev-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>>>
> > > >> For additional commands, e-mail:
> > > dev-help@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > <mailto:dev-help@tomcat.apache.org
> > <ma...@tomcat.apache.org>>
> > > >> <mailto:dev-help@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > > <mailto:dev-help@tomcat.apache.org
> > <ma...@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-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > > <mailto:dev-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>>
> > > > For additional commands, e-mail:
> > dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
> > > <mailto:dev-help@tomcat.apache.org
> > <ma...@tomcat.apache.org>>
> > > >
> > >
> > >
> > >
> >
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > > <mailto:dev-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>>
> > > For additional commands, e-mail:
> > dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
> > > <mailto:dev-help@tomcat.apache.org
> > <ma...@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-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> > <ma...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Bootstrap and modules
Posted by Mark Thomas <ma...@apache.org>.
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.auge@liferay.com
> <ma...@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 <markt@apache.org
> <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 <markt@apache.org
> <ma...@apache.org>
> > <mailto:markt@apache.org <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.auge@liferay.com
> <ma...@liferay.com>
> <mailto:raymond.auge@liferay.com <ma...@liferay.com>>
> > >> <mailto:raymond.auge@liferay.com
> <ma...@liferay.com>
> > <mailto:raymond.auge@liferay.com
> <ma...@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
> > <remm@apache.org <ma...@apache.org>
> <mailto:remm@apache.org <ma...@apache.org>>
> > >> <mailto:remm@apache.org <ma...@apache.org>
> <mailto:remm@apache.org <ma...@apache.org>>>> wrote:
> > >>
> > >> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas
> > <markt@apache.org <ma...@apache.org>
> <mailto:markt@apache.org <ma...@apache.org>>
> > >> <mailto:markt@apache.org
> <ma...@apache.org> <mailto:markt@apache.org
> <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-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>
> > <mailto:dev-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>>
> > >> <mailto:dev-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>
> > <mailto:dev-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>>>
> > >> For additional commands, e-mail:
> > dev-help@tomcat.apache.org
> <ma...@tomcat.apache.org>
> <mailto:dev-help@tomcat.apache.org
> <ma...@tomcat.apache.org>>
> > >> <mailto:dev-help@tomcat.apache.org
> <ma...@tomcat.apache.org>
> > <mailto:dev-help@tomcat.apache.org
> <ma...@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-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>
> > <mailto:dev-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>>
> > > For additional commands, e-mail:
> dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
> > <mailto:dev-help@tomcat.apache.org
> <ma...@tomcat.apache.org>>
> > >
> >
> >
> >
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>
> > <mailto:dev-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>>
> > For additional commands, e-mail:
> dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
> > <mailto:dev-help@tomcat.apache.org
> <ma...@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-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org
> <ma...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bootstrap and modules
Posted by Raymond Auge <ra...@liferay.com>.
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 <ra...@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 <markt@apache.org
>> > <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.auge@liferay.com <ma...@liferay.com>
>> > >> <mailto:raymond.auge@liferay.com
>> > <ma...@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
>> > <remm@apache.org <ma...@apache.org>
>> > >> <mailto:remm@apache.org <ma...@apache.org>>> wrote:
>> > >>
>> > >> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas
>> > <markt@apache.org <ma...@apache.org>
>> > >> <mailto:markt@apache.org <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-unsubscribe@tomcat.apache.org
>> > <ma...@tomcat.apache.org>
>> > >> <mailto:dev-unsubscribe@tomcat.apache.org
>> > <ma...@tomcat.apache.org>>
>> > >> For additional commands, e-mail:
>> > dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
>> > >> <mailto:dev-help@tomcat.apache.org
>> > <ma...@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-unsubscribe@tomcat.apache.org
>> > <ma...@tomcat.apache.org>
>> > > For additional commands, e-mail: dev-help@tomcat.apache.org
>> > <ma...@tomcat.apache.org>
>> > >
>> >
>> >
>> >
>> ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
>> > <ma...@tomcat.apache.org>
>> > For additional commands, e-mail: dev-help@tomcat.apache.org
>> > <ma...@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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@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)
Re: Bootstrap and modules
Posted by Raymond Auge <ra...@liferay.com>.
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 <markt@apache.org
> > <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.auge@liferay.com <ma...@liferay.com>
> > >> <mailto:raymond.auge@liferay.com
> > <ma...@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
> > <remm@apache.org <ma...@apache.org>
> > >> <mailto:remm@apache.org <ma...@apache.org>>> wrote:
> > >>
> > >> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas
> > <markt@apache.org <ma...@apache.org>
> > >> <mailto:markt@apache.org <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-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > >> <mailto:dev-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>>
> > >> For additional commands, e-mail:
> > dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
> > >> <mailto:dev-help@tomcat.apache.org
> > <ma...@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-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > > For additional commands, e-mail: dev-help@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > >
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> > <ma...@tomcat.apache.org>
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> > <ma...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Re: Bootstrap and modules
Posted by Mark Thomas <ma...@apache.org>.
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 <markt@apache.org
> <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.auge@liferay.com <ma...@liferay.com>
> >> <mailto:raymond.auge@liferay.com
> <ma...@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
> <remm@apache.org <ma...@apache.org>
> >> <mailto:remm@apache.org <ma...@apache.org>>> wrote:
> >>
> >> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas
> <markt@apache.org <ma...@apache.org>
> >> <mailto:markt@apache.org <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-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>
> >> <mailto:dev-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>>
> >> For additional commands, e-mail:
> dev-help@tomcat.apache.org <ma...@tomcat.apache.org>
> >> <mailto:dev-help@tomcat.apache.org
> <ma...@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-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> <ma...@tomcat.apache.org>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org
> <ma...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bootstrap and modules
Posted by Raymond Auge <ra...@liferay.com>.
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.
- Ray
On Thu, Jun 11, 2020 at 5:08 PM Mark Thomas <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.auge@liferay.com
> >> <ma...@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 <remm@apache.org
> >> <ma...@apache.org>> wrote:
> >>
> >> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas <markt@apache.org
> >> <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-unsubscribe@tomcat.apache.org
> >> <ma...@tomcat.apache.org>
> >> For additional commands, e-mail: dev-help@tomcat.apache.org
> >> <ma...@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-unsubscribe@tomcat.apache.org
> > For additional commands, e-mail: dev-help@tomcat.apache.org
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Re: Bootstrap and modules
Posted by Mark Thomas <ma...@apache.org>.
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.auge@liferay.com
>> <ma...@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 <remm@apache.org
>> <ma...@apache.org>> wrote:
>>
>> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas <markt@apache.org
>> <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-unsubscribe@tomcat.apache.org
>> <ma...@tomcat.apache.org>
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>> <ma...@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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bootstrap and modules
Posted by Mark Thomas <ma...@apache.org>.
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?
Mark
>
> :)
>
> - Ray
>
> On Thu, Jun 11, 2020 at 3:25 PM Raymond Auge <raymond.auge@liferay.com
> <ma...@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 <remm@apache.org
> <ma...@apache.org>> wrote:
>
> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas <markt@apache.org
> <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-unsubscribe@tomcat.apache.org
> <ma...@tomcat.apache.org>
> For additional commands, e-mail: dev-help@tomcat.apache.org
> <ma...@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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Bootstrap and modules
Posted by Raymond Auge <ra...@liferay.com>.
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.
:)
- Ray
On Thu, Jun 11, 2020 at 3:25 PM Raymond Auge <ra...@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 <re...@apache.org> wrote:
>
>> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas <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-unsubscribe@tomcat.apache.org
>>> For additional commands, e-mail: dev-help@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)
Re: Bootstrap and modules
Posted by Raymond Auge <ra...@liferay.com>.
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 <re...@apache.org> wrote:
> On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas <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-unsubscribe@tomcat.apache.org
>> For additional commands, e-mail: dev-help@tomcat.apache.org
>>
>>
--
*Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile>
(@rotty3000)
Senior Software Architect *Liferay, Inc.* <http://www.liferay.com>
(@Liferay)
Re: Bootstrap and modules
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Jun 11, 2020 at 9:01 PM Mark Thomas <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-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>