You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Romain Manni-Bucau <rm...@gmail.com> on 2021/09/15 07:34:51 UTC
Drop module-info from tomcat*.jar?
Hi all,
I was trying to strim down a JDK, all was smooth until I started to work
with Tomcat.
The issues I hit:
- Tomcat is designed to be fully used with JPMS whereas I would like to be
able to use it in the CP if a jlink custom distro (without forking/patching
tomcat jar indeed)
- module-info use "requires" and no optional dependent modules which lead
to way too much dependencies (open the module-info from tomcat-catalina for
ex)
Indeed there are always workaround and way to achieve what I wanted but I
think the JPMS deliveries of Tomat are not friendly so think it is worth
thinking about:
1. dropping it
2. making it optional (I assume it can be released in jars with classifiers
only)
3. making it more accurate - but this highly depends how the user consumes
it (in particular for tomcat embed flavor)
Personally I tend to priviledge 1 cause 3 makes it hard to do right but
happy with other solutions not requiring to fork.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Re: Drop module-info from tomcat*.jar?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
Le mer. 15 sept. 2021 à 13:13, Mark Thomas <ma...@homeinbox.net> a écrit :
> On 15/09/2021 11:07, Romain Manni-Bucau wrote:
> > I think the last option is maybe the target: modularize tomcat properly.
>
> "Properly" is a highly subjective judgement. There are going to be
> wildly differing views on what constitutes a "proper" degree of modularity.
>
Ok, "properly" regarding the dependency graph, ie no reflection done nor
code relying on an optional dependency (all that replaced by a SPI or
alike).
>
> > The people willing to have as few as possible modules would just use a
> new
> > "bundle" module (this is what we do at openjpa, tomee, meecrowave etc)
> > which provides a bundle way of building apps but is not flexible.
> > So regarding JPMS I think it is either being really modular or not being
> > modular since the in between state leads to unsatisfied people and the
> > biggest constraints come from JPMS.
> > Is it something targettable or do you think it is too much work?
>
> Don't know until we try.
>
> My instinct is that making more modules optional and then logging
> warnings if users try to use Tomcat features that depend on a missing
> optional module is doable - but I haven't done any analysis to back that
> up.
>
> I don't have a sense of how many more modules like SSI could be
> realistically created.
>
> Broadly, embedded is going to be the "bundle" module (well, modules) and
> if folks want a finer-grained selection then they can use the JARs from
> the standard distribution.
>
To be honest I never understood why the org.apache.tomcat.embed artifacts,
they are generally the same as org.apache.tomcat ones and embedded server
works very well with org.apache.tomcat artifacts so can be good to drop
embed groupId and replace it by an all in one? Still thinking out loud
indeed but current modularisation is surprising for consumers ;).
>
> Mark
>
>
> >
> > side note: fine for me if it targets only 10.1.
> >
> > Romain Manni-Bucau
> > @rmannibucau <https://twitter.com/rmannibucau> | Blog
> > <https://rmannibucau.metawerx.net/> | Old Blog
> > <http://rmannibucau.wordpress.com> | Github <
> https://github.com/rmannibucau> |
> > LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> > <
> https://www.packtpub.com/application-development/java-ee-8-high-performance
> >
> >
> >
> > Le mer. 15 sept. 2021 à 11:17, Mark Thomas <ma...@apache.org> a écrit :
> >
> >> On 15/09/2021 08:34, Romain Manni-Bucau wrote:
> >>> Hi all,
> >>>
> >>> I was trying to strim down a JDK, all was smooth until I started to
> work
> >>> with Tomcat.
> >>
> >> I am assuming this is with embedded.
> >>
> >>> The issues I hit:
> >>>
> >>> - Tomcat is designed to be fully used with JPMS whereas I would like to
> >> be
> >>> able to use it in the CP if a jlink custom distro (without
> >> forking/patching
> >>> tomcat jar indeed)
> >>> - module-info use "requires" and no optional dependent modules which
> lead
> >>> to way too much dependencies (open the module-info from tomcat-catalina
> >> for
> >>> ex)
> >>>
> >>> Indeed there are always workaround and way to achieve what I wanted
> but I
> >>> think the JPMS deliveries of Tomat are not friendly so think it is
> worth
> >>> thinking about:
> >>>
> >>> 1. dropping it
> >>
> >> Not an option as we have users that have requested it.
> >>
> >>> 2. making it optional (I assume it can be released in jars with
> >> classifiers
> >>> only)
> >>
> >> Maybe, but it adds a bunch of artefacts.
> >>
> >>> 3. making it more accurate - but this highly depends how the user
> >> consumes
> >>> it (in particular for tomcat embed flavor)
> >>
> >> I think a variation of this is the way to go.
> >>
> >> Looking at the list of dependencies, I suspect most of them can be made
> >> optional. That involves fine-tuning the bnd configuration files.
> >>
> >> That does raise the question what we do when a user tries to use the
> >> optional features. I think we need to:
> >> - identify those Tomcat features that depend on optional modules
> >> - add a check for the presence of the module before using the feature
> >> and log an appropriate error message if the module is missing.
> >>
> >> Splitting embedded into lots of little modules where all the
> >> dependencies are correctly declared is another solution but we have
> >> users that have requested we provide Tomcat in as few JARs as possible.
> >>
> >> I think we are approaching "can't please all of the people, all of the
> >> time" territory here.
> >>
> >> Mark
> >>
> >> ---------------------------------------------------------------------
> >> 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: Drop module-info from tomcat*.jar?
Posted by Mark Thomas <ma...@homeinbox.net>.
On 15/09/2021 11:07, Romain Manni-Bucau wrote:
> I think the last option is maybe the target: modularize tomcat properly.
"Properly" is a highly subjective judgement. There are going to be
wildly differing views on what constitutes a "proper" degree of modularity.
> The people willing to have as few as possible modules would just use a new
> "bundle" module (this is what we do at openjpa, tomee, meecrowave etc)
> which provides a bundle way of building apps but is not flexible.
> So regarding JPMS I think it is either being really modular or not being
> modular since the in between state leads to unsatisfied people and the
> biggest constraints come from JPMS.
> Is it something targettable or do you think it is too much work?
Don't know until we try.
My instinct is that making more modules optional and then logging
warnings if users try to use Tomcat features that depend on a missing
optional module is doable - but I haven't done any analysis to back that up.
I don't have a sense of how many more modules like SSI could be
realistically created.
Broadly, embedded is going to be the "bundle" module (well, modules) and
if folks want a finer-grained selection then they can use the JARs from
the standard distribution.
Mark
>
> side note: fine for me if it targets only 10.1.
>
> Romain Manni-Bucau
> @rmannibucau <https://twitter.com/rmannibucau> | Blog
> <https://rmannibucau.metawerx.net/> | Old Blog
> <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
> LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
> <https://www.packtpub.com/application-development/java-ee-8-high-performance>
>
>
> Le mer. 15 sept. 2021 à 11:17, Mark Thomas <ma...@apache.org> a écrit :
>
>> On 15/09/2021 08:34, Romain Manni-Bucau wrote:
>>> Hi all,
>>>
>>> I was trying to strim down a JDK, all was smooth until I started to work
>>> with Tomcat.
>>
>> I am assuming this is with embedded.
>>
>>> The issues I hit:
>>>
>>> - Tomcat is designed to be fully used with JPMS whereas I would like to
>> be
>>> able to use it in the CP if a jlink custom distro (without
>> forking/patching
>>> tomcat jar indeed)
>>> - module-info use "requires" and no optional dependent modules which lead
>>> to way too much dependencies (open the module-info from tomcat-catalina
>> for
>>> ex)
>>>
>>> Indeed there are always workaround and way to achieve what I wanted but I
>>> think the JPMS deliveries of Tomat are not friendly so think it is worth
>>> thinking about:
>>>
>>> 1. dropping it
>>
>> Not an option as we have users that have requested it.
>>
>>> 2. making it optional (I assume it can be released in jars with
>> classifiers
>>> only)
>>
>> Maybe, but it adds a bunch of artefacts.
>>
>>> 3. making it more accurate - but this highly depends how the user
>> consumes
>>> it (in particular for tomcat embed flavor)
>>
>> I think a variation of this is the way to go.
>>
>> Looking at the list of dependencies, I suspect most of them can be made
>> optional. That involves fine-tuning the bnd configuration files.
>>
>> That does raise the question what we do when a user tries to use the
>> optional features. I think we need to:
>> - identify those Tomcat features that depend on optional modules
>> - add a check for the presence of the module before using the feature
>> and log an appropriate error message if the module is missing.
>>
>> Splitting embedded into lots of little modules where all the
>> dependencies are correctly declared is another solution but we have
>> users that have requested we provide Tomcat in as few JARs as possible.
>>
>> I think we are approaching "can't please all of the people, all of the
>> time" territory here.
>>
>> Mark
>>
>> ---------------------------------------------------------------------
>> 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: Drop module-info from tomcat*.jar?
Posted by Romain Manni-Bucau <rm...@gmail.com>.
I think the last option is maybe the target: modularize tomcat properly.
The people willing to have as few as possible modules would just use a new
"bundle" module (this is what we do at openjpa, tomee, meecrowave etc)
which provides a bundle way of building apps but is not flexible.
So regarding JPMS I think it is either being really modular or not being
modular since the in between state leads to unsatisfied people and the
biggest constraints come from JPMS.
Is it something targettable or do you think it is too much work?
side note: fine for me if it targets only 10.1.
Romain Manni-Bucau
@rmannibucau <https://twitter.com/rmannibucau> | Blog
<https://rmannibucau.metawerx.net/> | Old Blog
<http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> |
LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book
<https://www.packtpub.com/application-development/java-ee-8-high-performance>
Le mer. 15 sept. 2021 à 11:17, Mark Thomas <ma...@apache.org> a écrit :
> On 15/09/2021 08:34, Romain Manni-Bucau wrote:
> > Hi all,
> >
> > I was trying to strim down a JDK, all was smooth until I started to work
> > with Tomcat.
>
> I am assuming this is with embedded.
>
> > The issues I hit:
> >
> > - Tomcat is designed to be fully used with JPMS whereas I would like to
> be
> > able to use it in the CP if a jlink custom distro (without
> forking/patching
> > tomcat jar indeed)
> > - module-info use "requires" and no optional dependent modules which lead
> > to way too much dependencies (open the module-info from tomcat-catalina
> for
> > ex)
> >
> > Indeed there are always workaround and way to achieve what I wanted but I
> > think the JPMS deliveries of Tomat are not friendly so think it is worth
> > thinking about:
> >
> > 1. dropping it
>
> Not an option as we have users that have requested it.
>
> > 2. making it optional (I assume it can be released in jars with
> classifiers
> > only)
>
> Maybe, but it adds a bunch of artefacts.
>
> > 3. making it more accurate - but this highly depends how the user
> consumes
> > it (in particular for tomcat embed flavor)
>
> I think a variation of this is the way to go.
>
> Looking at the list of dependencies, I suspect most of them can be made
> optional. That involves fine-tuning the bnd configuration files.
>
> That does raise the question what we do when a user tries to use the
> optional features. I think we need to:
> - identify those Tomcat features that depend on optional modules
> - add a check for the presence of the module before using the feature
> and log an appropriate error message if the module is missing.
>
> Splitting embedded into lots of little modules where all the
> dependencies are correctly declared is another solution but we have
> users that have requested we provide Tomcat in as few JARs as possible.
>
> I think we are approaching "can't please all of the people, all of the
> time" territory here.
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Drop module-info from tomcat*.jar?
Posted by Mark Thomas <ma...@apache.org>.
On 15/09/2021 08:34, Romain Manni-Bucau wrote:
> Hi all,
>
> I was trying to strim down a JDK, all was smooth until I started to work
> with Tomcat.
I am assuming this is with embedded.
> The issues I hit:
>
> - Tomcat is designed to be fully used with JPMS whereas I would like to be
> able to use it in the CP if a jlink custom distro (without forking/patching
> tomcat jar indeed)
> - module-info use "requires" and no optional dependent modules which lead
> to way too much dependencies (open the module-info from tomcat-catalina for
> ex)
>
> Indeed there are always workaround and way to achieve what I wanted but I
> think the JPMS deliveries of Tomat are not friendly so think it is worth
> thinking about:
>
> 1. dropping it
Not an option as we have users that have requested it.
> 2. making it optional (I assume it can be released in jars with classifiers
> only)
Maybe, but it adds a bunch of artefacts.
> 3. making it more accurate - but this highly depends how the user consumes
> it (in particular for tomcat embed flavor)
I think a variation of this is the way to go.
Looking at the list of dependencies, I suspect most of them can be made
optional. That involves fine-tuning the bnd configuration files.
That does raise the question what we do when a user tries to use the
optional features. I think we need to:
- identify those Tomcat features that depend on optional modules
- add a check for the presence of the module before using the feature
and log an appropriate error message if the module is missing.
Splitting embedded into lots of little modules where all the
dependencies are correctly declared is another solution but we have
users that have requested we provide Tomcat in as few JARs as possible.
I think we are approaching "can't please all of the people, all of the
time" territory here.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org