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-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
