Loader constraint violation when using sendMail action with attachment

[mhilbush]

I'm seeing this error when calling the sendMail action with an attachment. The error doesn't occur when calling the sendMail action without an attachment.

019-01-05 20:21:47.282 [ERROR] [ntime.internal.engine.RuleEngineImpl] - Rule 
'TestRuleOn': loader constraint violation: when resolving method
 "javax.mail.BodyPart.setDataHandler(Ljavax/activation/DataHandler;)V" the class 
loader (instance of org/eclipse/osgi/internal/loader/EquinoxClassLoader) of the 
current class, org/apache/commons/mail/MultiPartEmail, and the class 
loader (instance of org/eclipse/osgi/internal/loader/EquinoxClassLoader) for 
the method's defining class, javax/mail/Part, have different Class objects for the 
type javax/activation/DataHandler used in the signature

I'm seeing this on snapshot build 1484 (also 1489). I'm seeing the error on two separate systems. When I restore an earlier build (in this case 1458), the error doesn't occur.

The sendMail call in my rule is this

sendMail("my@email.address", "Email subject", "Email body", "file:///path/to/image.jpg")

or this

sendMail("my@email.address", "Email subject", "Email body", "http://my.host/path/to/image.jpg")

It didn't look like anything had changed with the sendMail action in the openhab1 repo (hence the reason for not opening the issue in that repo).

[kaikreuzer]

I can confirm the issue. It happens since #834 as Karaf 4.2.2 contained this change in order to fix https://issues.apache.org/jira/browse/KARAF-5989.

I am not fully sure for whom this fix actually helped and for whom it broke the feature. We belong to the latter group :-(.
Our mail action resolves against the servicemix bundle:

org.openhab.action.mail_1.13.0.201901061828 [261] requires:
-----------------------------------------------------------
osgi.wiring.package; (osgi.wiring.package=javax.activation) resolved by:
   osgi.wiring.package; javax.activation 1.1.0 from org.apache.servicemix.specs.activation-api-1.1_2.5.0 [12]

but I assume that Equinox resolves against the JRE as we use osgi.compatibility.bootdelegation = true.

If I put the line javax.activation line in jre.properties back, it again works as the mail action is then also resolved against the JRE.

I am not sure how we should best solve this issue. Customising jre.properties will work, but it's a bit of a hack against Karaf, I guess.

@wborn Any good suggestion?

[wborn]

Maybe @ffang has some suggestions for fixing it?

[ffang]

@wborn

Yes, this problem comes from that javax/activation/DataHandler are loaded by different classloaders, and with Karaf 4.2.2, we now expect this class get loaded from the org.apache.servicemix.specs.activation-api bundle.

The osgi.compatibility.bootdelegation property from equinox will use OSGi normal classloader delegation way first, if can't find the required class, it will use the one from boot classloader as fallback. So I believe even with osgi.compatibility.bootdelegation=true, other bundles which require javax/activation/DataHandler should still try to load it from org.apache.servicemix.specs.activation-api bundle.

So we should firstly check why javax/activation/DataHandler from jre is loaded by some bundles.

Could you please check the header of bundles(bundle contains org/apache/commons/mail/MultiPartEmail and bundle contains javax/mail/Part) in question to see if it can reveal more?

[kaikreuzer]

@ffang The manifest of the bundle can be found here: https://github.com/openhab/openhab1-addons/blob/master/bundles/action/org.openhab.action.mail/META-INF/MANIFEST.MF

It currently indeed does not have an import-package statement for javax.activation, but when analysing it, I also added this to my test bundle and it unfortunately didn't make any difference.

I agree with you that the boot delegation is supposed to be a last resort only and that resolution should happen against OSGi bundles first - so I am not quite sure, why it still wasn't working with such an import...

[kaikreuzer]

I've created openhab/openhab1-addons#5767 in any case as this should be there. Maybe my tests weren't correct and this will fix it after all - let's try a distro after this has been merged.

[kaikreuzer]

Argh, stupid me. I should have read my earlier comment, where I already said that this bundle correctly resolves the dependency against the org.apache.servicemix.specs.activation-api bundle - so adding the import definitely won't fix anything...

The problem is probably rather somewhere in the rule engine, which does not know about that package and still needs to resolve some classes in order to execute the action. Not sure where to look for this, though...

[maggu2810]

Do you still need osgi.compatibility.bootdelegation = true at all?

[kaikreuzer]

From what I remember: YES, very much so! At least as long as we have openHAB 1 compatibility as those add-ons have many issues and many of them broke without the boot delegation.

[mhilbush]

@kaikreuzer I just retested this on build 1502. Your change here seems to have fixed the issue for me.

[yveshanoulle]

@mhilbush I assume this means i can install the lastest version and it's fixed?

[mhilbush]

@yveshanoulle Yes, it is working again for me after installing the latest snapshot.

[kaikreuzer]

Indeed, for me as well!
So openhab/openhab1-addons#5767 indeed fixed it, pfew.

[yveshanoulle]

Also on my side this works.