Mail library included in jetty-jre11 is not compatible with JDK11 #10
Comments
|
@janbartel what did we do to fix this? |
|
@gregw in jetty-9.4 we have the mail.mod module, which puts javax.mail.glassfish-1.4.1.v201005082020.jar onto the container classpath. That jar contains both the javax.mail apis and the impl. This is tested and working in jdk-11 and beyond. For jetty-10.0 we have removed the mail.mod module altogether. If users wish to use a javax.mail service the they need to provide their own jar/s, preferably by making their own mail mod file. See also jetty issue jetty/jetty.project#2960. |
|
Any chances of having some Jetty 10 preview images? I really don't have a workaround without a baseline Docker image that supports Java 11 and doesn't break email. |
|
Workaround for now: |
|
@brunojcm we should be doing an jetty-10-alpha1 release next week, so I'll try to get a docker image going as well.... feel free to hassle me if I forget! |
|
@janbartel Hi. You seem to be saying that Jetty 9.4 fixes the problem on JDK11+. However on the XWiki project we're using the Jetty docker image Note that we bundle So, is Jetty 9.4 supposed to fix the problem? If so I wonder why it's not working for us. Any idea? Thanks! |
|
Found a solution thanks to a message from @janbartel :) I've put the following in our And it worked :) |
|
@vmassol that's old school syntax (and deprecated) Use ... <Configure class="org.eclipse.jetty.webapp.WebAppContext">
<Get name="systemClasspathPattern">
<Call name="add"><Arg>-javax.mail.</Arg></Call>
</Get>
<Get name="serverClasspathPattern">
<Call name="add"><Arg>javax.mail.</Arg></Call>
</Get> |
|
@joakime BTW note that sadly we're still using this old school syntax because we need it to support both Jetty 9.4.x but also Jetty 9.3.x. I guess there's no way to do an IF in jetty-web.xml, right? :) (it's a bit complex for our use cases to have 2 different distributions). I'm not expecting that to be possible but asking, just in case. |
|
@vmassol No ifs in XML.... that road leads to a very VERY bad programming language :) |
|
@vmassol the old school syntax will work fine for the 9.3 to 9.4 bridge. |
Maybe this can help some users. Just upgrading to Jetty 10 and it seems this has changed again. I've tried using But I got in Jetty 10.0.0: I then checked https://github.com/eclipse/jetty.project/blob/jetty-10.0.x/jetty-webapp/src/main/java/org/eclipse/jetty/webapp/WebAppContext.java#L734 and came up with the following which seems to work: |
|
@joakime Hi. I'm looking for ideas. XWiki is distributed as a WAR and we have included a Thanks! |
|
The move from pattern to matcher was motivated by the introduction of JPMS in Java 11+ and our support for running Jetty 10+ with JPMS. Why are you doing this in the WAR? @janbartel mail on 9.4.x works regardless of JVM version (as the standalone jetty-home selects the appropriate javax.mail behavior based on JVM), right? jetty-home 10 is the same. |
|
@joakime thanks for your quick reply.
We do this in the WAR because we would like that the XWiki WAR works OOB for users trying to use it on Jetty. If we don't provide the jetty-web.xml file then it'll fail on Jetty 9.4 (which we still support) for example. Then the users will complain, post on the forum and in general don't understand why XWiki doesn't work on Jetty... |
@joakime Note that there's also the DTD issue. Starting with Jetty 10.0.0 it seems mandatory to add Maybe there's a config to avoid Jetty doing DTD validation? |
|
I'm confused, OOB on Jetty 10 is literally nothing, no configuration, no defaults. We no longer have a jetty-distribution, only a jetty-home. Surely you are using the ${jetty.home} and ${jetty.base} split we've been encouraging for the past 7 years. |
Yes, I still need to test that I don't need the config (I confirmed it works with it but it's probably not necessary) on Jetty 10.0.0 (it's probably the case since the mail module is no longer provided). But Jetty 10 is not the issue. The issue is to make it work both on Jetty 9.4 and Jetty 10.0 |
You are not required to use the version 10 DTD, you can still use the 9.3 or even the 9.0 DTD just fine. I'm surprised that the low level JVM XML validation is requiring the DTD to be present. I'll have to look into that. This validation was enabled because too many people ignored the warnings from both our XmlConfiguration and the raw JVM XML parser and continued to use features from XmlConfiguration that were deprecated back in the Jetty 7 days, and finally removed in Jetty 10. |
Indeed good point, I should have thought about that... |
The jetty.base for 9.x has The jetty.base for 10.x has no "mail" module, that is correct. If you want to use mail on any Jakarta EE 8 server you have two choices ...
I'm not sure what Tomcat has done here, but I bet it's one of two decisions.
Anyway, you can have a single |
I'm not sure I understand this one. There are several ways to use XWiki and Jetty:
|
|
Uhm ... Why do you have these files here? That tree is incompatible with the desired goal of having support for both Jetty 9.4.x and 10.0.x The xwiki specific modules and etc xml files are good, but can be improved to achieve compatibility. Next, get rid of your jetty-web.xml sections attempting to manipulate the server and system classes. Next, add this section to the bottom of your Edit: typo on the |
|
This is also an option for compatibility. Add this to your This also configures the server level system/server classes used by all webapps (like the proposed lines in your <?xml version="1.0"?>
<!DOCTYPE Configure PUBLIC "-//Jetty//Configure//EN" "http://www.eclipse.org/jetty/configure_9_3.dtd">
<Configure id="Server" class="org.eclipse.jetty.server.Server">
<Call name="addServerClasses" class="org.eclipse.jetty.webapp.WebAppContext">
<Arg><Ref refid="Server"/></Arg>
<Arg>
<Array type="String">
<Item>-javax.mail.</Item>
</Array>
</Arg>
</Call>
<Call name="addSystemClasses" class="org.eclipse.jetty.webapp.WebAppContext">
<Arg><Ref refid="Server"/></Arg>
<Arg>
<Array type="String">
<Item>javax.mail.</Item>
</Array>
</Arg>
</Call>
</Configure> |
The custom packaging we have is just a demo packaging and users don't even know this is running Jetty. We embed it in our packaging. So we control the version of Jetty we use (9.4.36 ATM). The need to support both v9.4 and 10.0 is for the other use cases I mentioned:
|
I hope you advocate using the |
|
Just to be clear: we don't have any issue with the custom jetty packaging we do since we control it fully. All this discussion thread should be about what users use (ie when they install Jetty on their own and we don't control anything about their installation, we just provide an XWiki WAR that they deploy on it). |
|
Thanks for your review of our custom jetty packaging though, I'm sure we can learn new things and improve it. I've been maintaining it but I often don't know what I'm doing ;) (especially when upgrading the jetty version, I try to diff the default files coming from jetty and our versions but it's not always easy). |
We don't. So far we've not had to: the What do you have in mind when you say we should advocate it? (I'm curious). Note that we could always advocate it but most users would still not use it. |
There's a bit more (see https://github.com/xwiki/xwiki-platform/blob/f870173a837d05b3af08fbf76f5b53767974fc9f/xwiki-platform-core/xwiki-platform-web/src/main/webapp/WEB-INF/jetty-web.xml) but the idea is that we would like that the XWiki WAR works OOB as much as possible, when deployed on any Jetty instance, in whatever way it's been configured by the user. This is why I've preferred using a |
I expect you document how to configure their Jetty instance for use with XWiki? Keep in mind that jetty is highly modular, and not all users use Jetty the same. As it's 100% possible (and frequently done) to have Jetty not even support hot deploy (those users that have multiple webapps with ordering requirements, or complex webapp startup) or mail or even the concept of webapps (surprising number of users of jetty.docker use ServletContextHandler directly). Expecting that your war will just work "out of the box" (a meaningless phrase for Jetty) is not realistic without documenting the Jetty configuration requirements for Xwiki. |
This is the crux of the issue. I can show you many valid and common Jetty configurations where your |
We haven't so far and didn't get anyone telling us XWiki wasn't working with their Jetty instance. Again maybe we've been lucky. Or maybe there aren't that many Jetty users (vs Tomcat users). Would not be nice for you ;) We have stats here: https://www.xwiki.org/xwiki/bin/view/ActiveInstalls/ Note: Most of the 13% of Jetty installs (765) are actually our custom packaging/distribution, which can be checked with the distribution graph (we have a unique id for each packaging/distribution): 193+347 = 540. Which means that we currently have 765-540 = 225 active instances of XWiki in the world out there using their own setup of Jetty. |
Yes I'm sure there are plenty. It's just that the "default" or "standard" (whatever this means) jetty configs you get just works for XWiki. For example the official docker image just works for XWiki. |
|
I note your point about documenting the minimal requirements needed in the Jetty setup for XWiki to deploy fine on Jetty. We need to keep that list as small as possible though. |
|
For standalone users of Jetty, (even jetty.docker), advocating the use of |
So basically what you're saying between the lines, is that if users don't use the recommended way (i.e. |
|
The entire xwiki.mod has relevance, even to ensure that other modules are present and required. |
I get that, but it's really limited.
Well, for deploying a webapp that seems pretty obvious ;)
We don't use servlet annotations (ATM at least).
We don't either (not by default at least - xwiki can work fine without it). |
|
PS: Thanks a lot for this discussion @joakime . Much appreciated. :) |
Thanks. I hope you reach a point that you are happy with. Now don't go expecting anything magical with Jetty 11 backward compat, that's a whole other discussion about how xwiki will be impacted by the 'big bang" from Jakarta EE 9. Speaking of which, do you have long term plans to migrate xwiki? Now that javax.servlet is a dead end with no future updates? |
Yeah we know that this will be painful. We haven't discussed it yet so no plan ATM but we've realized recently that we'll need to draw a plan. For example Tomcat 10 is now the latest version and we're forced to not support it FTM (they were not as nice as you guys with 10.0 and 11.0 ;)). We have plenty of diverse users including users not upgrading their servlet containers frequently so it would probably be a mistake for us to stop supporting older servlet container versions too fast. So my guess is that we'll have to not support recent versions of servlet containers for a few years before the whole user ecosystem is ready to move. But this is just my opinion, we need to discuss it. |
|
This issue has been automatically marked as stale because it has been a full year without activity. It will be closed if no further activity occurs. Thank you for your contributions. |
on Java 11. See jetty/jetty.docker#10.
Friday Jul 19, 2019 at 14:28 GMT
Originally opened as appropriate/docker-jetty#108
There is a bug in the jetty:9.4-jre11 docker image.
The following runtime error is thrown when using javax.mail.internet.MimeMessage:
javax.activation was removed from the JDK in Java 11. Adding javax.activation to the WAR file doesn't fix the runtime bug. The reason is that Jetty is bundled with its own mail, which overrides the one in the WAR.
The solution is to delete the mail from the Jetty dockerfile:
This blog post describes the problem in more detail:
https://www.databasesandlife.com/activation-error-jetty-javamail-java11/
The text was updated successfully, but these errors were encountered: