Okay, thanks for the quick reply!
On 9/23/25 12:13, Mark Thomas wrote:
External Message - Please be cautious when opening links or attachments
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.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
