java.lang.VerifyError on deployment

[Peter Helgren, modificado 6 Anos atrás.]

Not a great way to start a Monday. I am chasing a very peculiar error:

Caused by: java.lang.VerifyError: Stack map does not match the one at exception handler 384_Exception 
Details:_  
Location:_    org/bsfinternational/api/core/service/impl/EmailLocalServiceImpl.sendEmail(Ljava/lang/String;Lorg/bsfinternational/api/core/service/impl/EmailLocalServiceImpl$EmailAddrList;Ljava/lang/String;Ljava/lang/String;ZLorg/bsfinternational/api/core/model/MLTVolunteerNotification;)V @384: astore_  
Reason:_    Type 'de/agitos/dkim/SMTPDKIMMessage' (current frame, locals[16]) is not assignable to 'javax/mail/Message' (stack map, locals[16])_  
Current Frame:_    bci: @370_    flags: { }_    locals: { 'org/bsfinternational/api/core/service/impl/EmailLocalServiceImpl', 'java/lang/String', 'org/bsfinternational/api/core/service/impl/EmailLocalServiceImpl$EmailAddrList', 'java/lang/String', 'java/lang/String', integer, 'org/bsfinternational/api/core/model/MLTVolunteerNotification', 'java/lang/String', 'javax/mail/internet/InternetAddress', 'java/lang/String', 'java/util/Iterator', 'org/bsfinternational/api/core/service/impl/EmailLocalServiceImpl$EmailAddr', 'org/bsfinternational/api/core/service/impl/Personalizer', 'org/bsfinternational/api/core/model/Email', 'javax/mail/Session', 'de/agitos/dkim/DKIMSigner', 'de/agitos/dkim/SMTPDKIMMessage', null }_    
stack: { 'javax/mail/internet/AddressException' }_  Stackmap Frame:_    bci: @384_    flags: { }_    
locals: { 'org/bsfinternational/api/core/service/impl/EmailLocalServiceImpl', 'java/lang/String', 'org/bsfinternational/api/core/service/impl/EmailLocalServiceImpl$EmailAddrList', 'java/lang/String', 'java/lang/String', integer, 'org/bsfinternational/api/core/model/MLTVolunteerNotification', 'java/lang/String', 'javax/mail/internet/InternetAddress', 'java/lang/String', 'java/util/Iterator', 'org/bsfinternational/api/core/service/impl/EmailLocalServiceImpl$EmailAddr', 'org/bsfinternational/api/core/service/impl/Personalizer', 'org/bsfinternational/api/core/model/Email', 'javax/mail/Session', 'de/agitos/dkim/DKIMSigner', 'javax/mail/Message', 'javax/mail/internet/InternetAddress' }_    
stack: { 'javax/mail/internet/AddressException' }_  
[ a bunch of byte code references here]
	at java.lang.Class.getDeclaredConstructors0(Native Method)
	at java.lang.Class.privateGetDeclaredConstructors(Class.java:2671)
	at java.lang.Class.getConstructor0(Class.java:3075)
	at java.lang.Class.getDeclaredConstructor(Class.java:2178)
	at org.springframework.beans.factory.support.SimpleInstantiationStrategy.instantiate(SimpleInstantiationStrategy.java:80)
	at org.springframework.beans.factory.support.AbstractAutowireCapableBeanFactory.instantiateBean(AbstractAutowireCapableBeanFactory.java:1092)
	... 75 more

As far as I can tell, and I can't tell much, somewhere in the bowels of my modules there is a mismatch of byte code that the deployment is complaining about. I just can't quite figure out what the complaint is. First I see this:

Reason:_    Type 'de/agitos/dkim/SMTPDKIMMessage' (current frame, locals[16]) is not assignable to 'javax/mail/Message' (stack map, locals[16])_

So, it kind of looks like a class cast exception but it isn't. But, WHAT is the complaint? I changed the code back to match my 6.0.6 code and then I get this:

Reason:_    Type 'com/sun/mail/smtp/SMTPMessage' (current frame, stack[1]) is not assignable to 'javax/mail/Message'_

The code I changed is from this:

Message msg = new SMTPDKIMMessage(session, dkimSigner);

to this:

<this is working in 6.0.6>
SMTPMessage msg = new SMTPDKIMMessage(session, dkimSigner);
</this>

to this:

SMTPDKIMMessage msg = new SMTPDKIMMessage(session, dkimSigner);

So, I don't that it is the object type mismatch it is complaining about. Could it be a compilation issue with either the javax.mail-1.4.1.jar I am using or the DKIMforJavaMail.jar I am using? I just don't get it and I can't seem to find a clear posting on a solution. It *seems* to be a JDK issue but most of what I saw related to Java 7, not 8. So, I am a bit perplexed. Any Java Guru's out there that can unpack this error? Thanks!

[Peter Helgren, modificado 6 Anos atrás.]

WOW! I would *REALLY* like some help here because I am at a dead halt. This will take someone with some Java experience to help me sort out. My Java internals knowledge is pretty limited so I am not sure what the next step should be. Can anyone step in here and help?

[David H Nebinger, modificado 6 Anos atrás.]

Peter Helgren:

Reason:_    Type 'de/agitos/dkim/SMTPDKIMMessage' (current frame, locals[16]) is not assignable to 'javax/mail/Message' (stack map, locals[16])_

So, it kind of looks like a class cast exception but it isn't.

So, I don't that it is the object type mismatch it is complaining about. Could it be a compilation issue with either the javax.mail-1.4.1.jar I am using or the DKIMforJavaMail.jar I am using?

So there is a case where a subclass of a class cannot be cast to the parent class - when there is a class loader difference. That's what I think you're running into here.

javax.mail.* is coming from the global class loader because the jar is in the tomcat lib/ext directory. So javax.mail.Message is available via the global class loader (regardless of whether you have a local mail jar or not, global always comes first).

Your SMTPDKIMMessage extends javax.mail.message, but it is loaded in your OSGi module's loader, not in the global loader. Because of the class loader differences, you end up typically with a class cast exception or, as in this case, the "is not assignable" thing.

How to fix, well that is challenging. javax.mail has to stay in global, so obvious solution is to put the DKIM jar also in global. The challenge here, though, is that any super classes or transitive dependencies also have to be global lest you continue with the "is not assignable" error.

If you can get them to work, you also need a portal-ext.properties override to allow the classes exposed from the global class loader to be available to the OSGi class loader hierarchy. Look for the module.framework.system.packages.extra property in portal.properties, copy the whole value to your portal-ext.properties file and then add your packages from global to expose.








Come meet me at Devcon 2017 or 2017 LSNA!

[Peter Helgren, modificado 6 Anos atrás.]

OK. Thanks....that makes some sense. You are saying that even if the same mail.jar was used in the /lib/ext is also present in the OSGI container, I'll get this error? So here comes the next question and this goes WAY back to my initial forays into LR 7 and OSGI:

How do I properly reference these jars in build.gradle and bnd.bnd (if necessary). I get the heads up on adding the DKIM stuff to portal-ext.properties but then if it is in the /lib/ext folder how do I tell my build processes where to find them? That is always the issue: *I* know where to find stuff, what folder they live in, etc but how do I tell the build process where to find these things? Could be in /lib/ext? How do I reference them? In webapps\ROOT\WEB-INF\lib ? How do I reference them? My own module jars ? How do I reference them and include them?

Just basic stuff like that is what *usually* trips me up (along with some boneheaded stupidity on occasion...)

So, starting with jars in lib/ext that your module needs at runtime. What build.gradle and bnd.bnd entries are needed?

[David H Nebinger, modificado 6 Anos atrás.]

Peter Helgren:

OK. Thanks....that makes some sense. You are saying that even if the same mail.jar was used in the /lib/ext is also present in the OSGI container, I'll get this error?

Class loaders are hierarchical - when loading a class it starts at the root and works it's way to all of the ends until it finds the class, but classes from a different class loader cannot be cast between each other.

How do I properly reference these jars in build.gradle and bnd.bnd (if necessary).

If the jar is global, in lib/ext, then just use the "compile" dependency type, not "compileInclude". Compile ensures the dependency is satisfied for compile but will not be included in the module itself.

That is always the issue: *I* know where to find stuff, what folder they live in, etc but how do I tell the build process where to find these things? Could be in /lib/ext? How do I reference them? In webapps\ROOT\WEB-INF\lib ? How do I reference them? My own module jars ? How do I reference them and include them?

Two different issues. First there's the compile/building step. In that case, it doesn't matter where they are as long as the build process can resolve dependencies to satisfy the compilation. Here you just have to worry about "compile" vs "compileInclude" to ensure dependencies will be resolved.

Next is the runtime issue, there you're dealing with the classes being loaded in the class loader hierarchy, and there it also doesn't matter where they are as long as the runtime can resolve classes appropriately. Here you have to worry about what packages are provided by the runtime, what packages your module exports and what packages your modules import and that all packages are available and resolvable.

Just basic stuff like that is what *usually* trips me up (along with some boneheaded stupidity on occasion...)

I wouldn't say that. I too struggled w/ all of the OSGi stuff when introduced to it. It takes awhile to get beyond the learning curve. Once you get there, you'll realize things are easier than what they seem at this point in your journey.










Come meet me at Devcon 2017 or 2017 LSNA!

[Peter Helgren, modificado 6 Anos atrás.]

Thanks again...and I have some success for now.....

MailEngine lives in TWO different jars. It is in the util-java.jar that is in webapps\ROOT\WEB-INF\lib AND it's available in Petra mail in maven (com.liferay.petra.mail-1.1.1.jar) I have chosen both (individually) and recompiled using both (individually) Gradle entry for the util-java option uses this:

compile group: 'com.liferay.portal', name: 'util-java', version: '6.2.5'

and when I switch to the petra option I use this:

compileInclude group: 'com.liferay', name: 'com.liferay.petra.mail', version: '1.1.1'

When I build and deploy with util-java I get "Installed" in the gogo shell with this error:

Unresolved requirement: Import-Package: com.liferay.util.mail; version="[6.2.0,7.0.0)"

So, not sure if that is the wrong version to use...usually the version="[6.2.0,7.0.0)" means something ain't right....

The PetraMail option is currently working and it took some careful retracing of my steps to make sure all vestiges of former compiles were gone in other dependent jars. I have a few more errors to chase but they are the more "normal" variety: NPE's and the like. I can fix those.

Again David, you have been extremely helpful. My only hope is that I can become well-versed in this enough to be a help to others at some point....

[David H Nebinger, modificado 6 Anos atrás.]

Peter Helgren:

MailEngine lives in TWO different jars. It is in the util-java.jar that is in webapps\ROOT\WEB-INF\lib AND it's available in Petra mail in maven (com.liferay.petra.mail-1.1.1.jar) I have chosen both (individually) and recompiled using both (individually).

Okay, util-java is not OSGi friendly but the petra jar is. Util-java has a lot more dependencies, etc., that the petra version will not.

The PetraMail option is currently working and it took some careful retracing of my steps to make sure all vestiges of former compiles were gone in other dependent jars. I have a few more errors to chase but they are the more "normal" variety: NPE's and the like. I can fix those.

Again David, you have been extremely helpful. My only hope is that I can become well-versed in this enough to be a help to others at some point....

I'm sure you'll get there Pete.










Come meet me at Devcon 2017 or 2017 LSNA!