mybatis-3.4.0.jar on IBM's Websphere Application Server 8.5.5.9

[moonfruit]

MyBatis version

3.4.0

Mybatis 3.4.0 use shade to integrate javassist and ognl with relocation.

But when deploy war which has mybatis-3.4.0.jar to IBM's Websphere Application Server 8.5.5.9 (Java 7), the war cannot start because of the relocation of javassist.

Then I create a mybatis-3.4.0.jar without javassist and a independent javassist jar put it to my war. And deploy it to IBM's Websphere Application Server, everything is right.

[emacarron]

Can you please add some more information about the error? For example the error shown in the log during startup?

Looks the same error that the one reported here:
https://groups.google.com/forum/#!topic/mybatis-user/ZhI4cPe7cq8

You will find a workaround there:

"Well you are right the issue was around javassist pkg in the mybatis jar file. I just got around the issue by adding the the following entries in META-INFMANIFEST.MF now the app starts up fine with no issues.

Manifest-Version: 1.0
Ignore-Scanning-Archives: WEB-INF/lib/mybatis-3.4.0.jar
Ignore-Scanning-Packages: org.apache.ibatis.javassist"

Anyway we should need to find the root cause for this. I will open an issue in the shade tracker.

[emacarron]

@moonfruit can you open a ticket to IBM so they can bring more information about why is this happening?

[moonfruit]

https://groups.google.com/forum/#!topic/mybatis-user/ZhI4cPe7cq8
The above is exactly the same one that I met.

[moonfruit]

Sorry, I cannot open a ticket to IBM.
Because I develop application on WAS for my client, so my client has the license for WAS and I have not.

[harawata]

The exception in this SO question looks very similar.
By any chance, isn't it possible that the deployed mybatis jar is recompiled during the process?

Please try the following command on the mybatis-3.4.0.jar causing the problem.

$ javap -classpath PATH_TO/mybatis-3.4.0.jar -v org.apache.ibatis.javassist.ByteArrayClassPath | grep major

major version 50 means it's compiled with 1.6 and 52 means 1.8.

[harawata]

And one more thing. What is your Gradle version?

[moonfruit]

@harawata
No, the question that you mentioned is not the one I met.

As I say, this one below is the one that I met.
https://groups.google.com/forum/#!topic/mybatis-user/ZhI4cPe7cq8

And I do not use Gradle...

[harawata]

So, did you try the javap command and it returned major version 50?
And what is your Gradle version?

[moonfruit]

I use Maven to download the jar from central repository, and DO NOT use Gradle.
And I run the command that you give me, yes, it returned major version 50.

[harawata]

OK...thanks for the answer. :-)

By the way, the report on the forum was using Java 8, so it's not exactly the same.

[harawata]

In another ticket, a user informed me that Javassist 3.20.0-GA is incorrectly built with '-parameters' compiler option.
javap shows that there is parameter information attached and it could confuse ASM depending on WebSphere implementation, I think.

For testing, I have attached a custom version of mybatis 3.4.0 (you must change the extension to .jar after download).
The only difference from the release version is that it includes Javassist built without parameters info.
It's a long shot as the original Javassist JAR does not cause any problem, but I would appreciate if you could test it and see if it resolves the problem.

FYI, here is how I built it:

• Clone Javassist and checkout 3.20.0-GA tag.

  $ git clone https://github.com/jboss-javassist/javassist
  $ cd javassist
  $ git checkout refs/tags/rel_3_20_0_ga 

• Edit pom.xml to apply <source> and <target> is 1.6, but <compilerArgument> "-parameters" in1.8 jboss-javassist/javassist#54

• Install it to local repo.

  $ mvn clean install -Dmaven.test.skip=true

• Re-build mybatis 3.4.0 using the new Javassist.

  $ git clone https://github.com/mybatis/mybatis-3
  $ cd mybatis-3
  $ git checkout refs/tags/mybatis-3.4.0
  $ mvn clean package -Dmaven.test.skip=true

[emacarron]

Good research Iwao!!

Looks like using 3.18 instead of 3.20 may fix the problem:
http://stackoverflow.com/questions/25279729/tomcat-7-annotation-scanner-and-jdk-8-with-parameters-compiler-flag-exceptions

@moonfruit please we need a confirmation.

update: Looks like current Javassist trunk has already fixed the problem:
jboss-javassist/javassist@0e40ca2#diff-600376dffeb79835ede4a0b285078036

[harawata]

Hi Eduardo,

If the fix is verified and we release 3.4.1 soon, I think it's OK to use the custom build of Javassist 3.20.0-GA considering that the difference is just a compiler option and the fix is already committed.

Anyway, first thing first, I'll ask the reporter on the forum if he could test the fix.