Rony,
On 9/23/25 12:10 PM, Rony G. Flatscher (Apache) wrote:
On 23.09.2025 12:13, Mark Thomas wrote:
On 23/09/2025 10:49, Christian Ortlepp wrote:
<snip/>
So my concrete questions are:
1. Am I correct in saying that there is no way to make the tomcat
webapp classloader load (some of) my classes onto the module-path
instead of the class-path?
Yes.
And if that is the case, is this a deliberate decision (or just not
implemented yet) by tomcat or are there other, bigger reasons?
The Servlet spec (and Jakarta EE more generally) defines the web
application class loader behaviour in terms of class path, not modules.
I'll add that I'm not seeing a great deal of interest in doing the
work to change that.
2. Could I circumvent this by including my JPMS modules in the `java`
command line which would otherwise only start the tomcat classes (As
I understand I should be able to access them from the webapp if I
enabled the delegate option in the loader, see https://
tomcat.apache.org/ tomcat-10.1-doc/config/loader.html)?
Maybe. It should work...
Then I suppose I should be able to restrict native access to this
module, but I'm wondering if that would break something else in
tomcat/my webapp?
A single web application would be fine. However, there are potential
complications. The issues are:
- You can no longer just deploy a WAR file or a directory. You need to
update these other libraries too and none of the standard deployment
tooling will do that for you.
- If you have multiple web applications and they need different
versions of the same library you can't support that.
3. Is there any other way except giving ALL-UNNAMED access to native
access (and all of the other restricted Java features which may be in
use by parts of my webapp) that I'm missing? It just seems like a bad
idea to me so I thought that maybe I'm missing something. (I know
that this is how java always used to work, but it's clearly not the
direction Java is moving in right now)
In Tomcat, no.
As long as "--enable-native-access=ALL-UNNAMED" can be issued for Tomcat
this situation can be solved, not only for Christian, but also for others.
Being affected with a taglib [1] that allows for any
javax.script.ScriptEngine to be deployed in JSPs, it may be the case
that some scripting engines employ JNI (like BSF4ooRexx bridging Java
and the scripting language ooRexx). As one cannot know which scripting
engines may be deployed (with or without a JNI bridge), this is
something, that cannot be foreseen. Allowing "--enable-native-
access=ALL-UNNAMED" for good for Tomcat would therefore also solve this
problem for that taglib (and any other library that employs JNI, and FFM).
We can't add --enable-native-access to any Tomcat below Tomcat 11 due to
minimum-java-versions. If we did, someone running pre-Java-17 would get
a failure to start the JVM, so that's a hard "no" in those situations.
For Tomcat 11, guessing that we might have to add --enable-native-access
in some way, shape, or form since it will be required for FFM in the
future (Java 25, I assume). It would be best for us to package the
libtcnative FFM wrapper as a module that can be enabled in this way, for
safety and security, in a default Tomcat configuration.
If you want to run native code, ideally you'd have to add
--enable-native-access options yourself in e.g. setenv.sh|bat.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
