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).
---rony
[1] ScriptTagLib library with readme and slides:
<https://sourceforge.net/projects/bsf4oorexx/files/Sandbox/rgf/taglibs/ga/>
Using <https://wi.wu.ac.at/rgf/diplomarbeiten/> and selecting "ScriptTagLib" in the keyword box
would show some student's work relating to ScriptTagLib.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
