Can't send or verify email under JBOSS

Lucee version

Java 11.0.10 (Oracle Corporation) 64bit

OS Linux (3.10.0-1160.21.1.el7.x86_64) 64bit

When trying to validate the mail server:
javax.mail.Provider: com.sun.mail.imap.IMAPProvider not a subtype

do you have any additional jars loaded?

Nothing that didn’t come with the install.

JavaMail API (compat) 1.4.6 Feb 7, 2013 509kb Oracle not loaded
javax.mail.activation 712kb Lucee active

Does it happen with different mail servers?

Excuse me if I ask something that might be obvious, I’m just not able to follow. You are mentioning that you’re “validating” an mail server, and not just sending an email. How are you validating the mail server? Are you just using a cfmail? Or some Java libs invoking some Java methods? If so, do you have some code for us to share and test? And: Did you set the sys props in Tomcat with -Dmail.debug=true as @Zackster mentioned in an older post above to get more information?

I think validating refers to the admin UI?

But yeah, can you send a real email is a good question, the validation may fail depending on the mail server

Yes, we can’t validate in the UI. We also have set the smtp params in the application.cfc file and tried to send test emails. That fails as well. I also tried connecting to gmail and received the same error.

The mail works just fine on this Lucee build on our Windows computers.

Where is the setenv file for adding robust debugging?

You can set that in the Apache tomcat service control

That won’t help much, pretty sure it’s a class loader issue

Does it happen with a vanilla express version?

That was what we first tried way back when we were first trying to get Lucee running at all. Never worked. Only got an admin up when we downloaded the war.

express is super easy, you just unzip and run startup.bat in tomcat/bin?

only problem is usually if you have port conflicts, what error did you get?

also, the bundles list in admin, only shows OSGI bundles, normal jars don’t show up and they are the ones which are more likely to cause a problem, because they aren’t OSGI, which prevents exactly the type of class conflicts which can cause these kind of problems

We’ll try reinstalling today and see where we are.

if you’re on win10, the newish windows sandbox is amazingly great for testing this kinda thing

it’s a super lightweight, throw away vm, which uses your existing system files, to create a fresh instance

1 Like

We are having the problem on a Linux box. Windows works fine.

We were able to get express installed and the mail server does verify properly.

So how do we determine what may be causing a conflict on the non-express server?

Using express in a production environment is not an option for us.

that was a smoketest, if express works, then it has to be something with your setup

you most likely have a conflicting jar in your class path, or your app loads ones dynamically

We’re checking for other jars now. Here is a description of our prod environment. We can’t change this because of org requirements.

We have a JBOSS EAP 7.3 container that all our individual Lucee wars are deployed with and not using Tomcat. This is the approved architecture so we must not deviate from it (in case someone asks). JBOSS is configured to use the OS java which is
openjdk version “1.8.0_282”
OpenJDK Runtime Environment (build 1.8.0_282-b08)
OpenJDK 64-Bit Server VM (build 25.282-b08, mixed mode)

We did have two custom jars loading. We removed those and restarted but are getting the same error.

This install is a bare-bones setup just to run a scheduled task that does a report and sends an email.

ahh, you didn’t mention you were running on JBOSS :slight_smile:

I’m guess, probably that the problem, it’s loading a different javax.mail.* version than lucee

Sorry, I’d forgotten that it was more than just a Linux difference.

Would the version jboss is running be showing up in the Lucee admin or is it something possibly loading within jboss that would be invisible to the Lucee admin but still breaking it?

I have one of our guys checking on an extra mail jar. I’ll let you know.

nup, look in the classpath for jboss