, Java Mail upgraded to 1.6.2

the latest has been upgraded to javamail 1.6.2

anybody who has been having mail problems, can you try it out?

https://luceeserver.atlassian.net/browse/LDEV-2561 https://github.com/lucee/Lucee/commit/b10066e471bdb9cc5a8d51a0f404457a31412b22

the SNAPSHOT CI build process failed, unrelated, so the SNAPSHOT isn’t available yet

Also, 5.3.8 now does the email validation on send, rather than when it’s spooled, so rather than just dying silently, cfmail may now throw an exception if you are missing a from or to address.

This validation was always happening before Lucee attempted to send the mail (actually if it failed, it kept on retrying), now it just happens immediately

1 Like

Hi Zac,

The fix sounds good, but I guess this snapshot is unstable? I am getting regex errors: String index out of range: -1

Regex is used in server startup, so I cannot test this yet.

Yeah it’s a known issue, it breaks Lucee docs too.

I have requested a backport to 5.3.7 :slight_smile:

1 Like

I reverted our lucee version back to what it was before (5.3.2) and have noticed that the newer javax.mail.activation version 1.6.2 is still in there. Which, I guess is good?

I also noticed that the older one is in there too (1.4.7). Will this be a OK, having them side-by-side and having the newer bundle in an older lucee?

1.62 isn’t active right? it’s not loaded, just sitting there

Yes, you are correct. 1.6.2 is not loaded. My mistake :slight_smile:

I modified the MAINIFEST.MF in and to load the new Lucee javamail 1.6.2. Just download a .lco and put it in the deploy folder. Both worked to my test mailtrap.io account.



Cool, FYI, there’s an official snapshot coming for 5.3.7, followed by a second stable 5.3.7 release

As promised, there are now official and builds which includes the JavaMail 1.6.2 update available for testing


Hello Zac and any others that might know,
I have a production server that was consistently showing this error. We are running lucee 5.3.2. As I mentioned in the post above, I upgraded to the 5.3.8 snapshot, but because it wasn’t stable, I downgraded back again. However, despite the new java mail 1.6.2 not being loaded, the server is fixed!

Is there perhaps some residue change, in some sort of internal java mail library or config or properties file that is the real culprit here?

Anyway, glad it is sorted. I will look at updating soon.

what do you see under bundles in the admin for javamail?

I think there is 2 different problems with the old 1.4.7. One is the javax.mail 1.4.7 is in another bundle and can get confused with two. The other is just bugs that were fixed in 1.5.3. It is possible you had the first problem maybe.

What 5.3.2 version are you using? You can make your own fix my modifying the .lco MANIFEST.MF per my instructions in the other thread. Or give me the exact lco number and I can make one for download.

We are using Lucee - so we are due for an upgrade.

As for the mail bundles. This is what I see under admin bundles (I’ve included any that might involve email):

bouncycastle.mail- 1.38.0 - active
javax.mail.activation - - active
javax.mail.activation - - not loaded
org.lucee.commons.email - 1.2.0 - active

The SMTP error still hasn’t raised it’s head on this machine, which is great.

In case you want it, I changed it work with 1.6.2

1 Like

Just tried to build a new server using (previously built with RC).

Upon startup, I get this error:

ERROR: Failed to download the bundle for [javax.mail.activation] in version [] from [http://dev.lucee.org/rest/update/provider/download/javax.mail.activation/], please download manually and copy to [/removed/lucee/lib/lucee-server/bundles]
14-Nov-2020 13:28:20.947 SEVERE [http-apr-8881-exec-3] org.apache.catalina.core.StandardWrapperValve.invoke Allocate exception for servlet [CFMLServlet]
java.io.IOException: Failed to download the bundle for [javax.mail.activation] in version [] from [http://dev.lucee.org/rest/update/provider/download/javax.mail.activation/], please download manually and copy to [/removed/lucee/lib/lucee-server/bundles]
at lucee.loader.engine.CFMLEngineFactory.downloadBundle(CFMLEngineFactory.java:759)
at lucee.loader.osgi.BundleLoader.loadBundles(BundleLoader.java:141)
at lucee.loader.engine.CFMLEngineFactory.initEngine(CFMLEngineFactory.java:368)
at lucee.loader.engine.CFMLEngineFactory.initEngineIfNecessary(CFMLEngineFactory.java:267)
at lucee.loader.engine.CFMLEngineFactory.getInstance(CFMLEngineFactory.java:169)
at lucee.loader.engine.CFMLEngineFactory.getInstance(CFMLEngineFactory.java:207)
at lucee.loader.servlet.CFMLServlet.init(CFMLServlet.java:42)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1144)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1091)
at org.apache.catalina.core.StandardWrapper.allocate(StandardWrapper.java:763)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:134)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:97)
at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:544)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:143)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:81)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:78)
at org.apache.catalina.valves.RemoteIpValve.invoke(RemoteIpValve.java:747)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:343)
at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:616)
at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:65)
at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:818)
at org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:2045)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
at java.lang.Thread.run(Thread.java:748)

Is this related to the java mail upgrade? I built a fresh server with RC and it worked fine.

hmmm, why is it pointing to this website (dev.lucee.org) ?

Did you add a custom update location?
Check context/lucee-server.xml for the <update… setting.
It won’t fix your update location problem but you can always manually download from maven. Just search for maven lucee and find the javamail entry.

So I went back through source control to see when that tag got set to dev;lucee.org. And it appears to have happened when we did the railo -> lucee switch in 2015:

<update location="http://www.getrailo.org" type="manual"/>
<update location="http://dev.lucee.org" type="manual"/>

What is weird is that I’ve rebuilt these app servers with this lucee-server.xml hundreds of times across many versions and never had this problem until trying to bump this latest version.

That would be it. I think it is only used if a .jar gets deleted. Maybe for extension requirements?

FYI. It should be update.lucee.org

It’s all finally https BTW