ClassNotFoundException: ma.glasnost.orika.impl.GeneratedMapperBase on remote jetty server about orika

[idelpivnitskiy]

Another strange fact:
For chat implementation I'm using Stomp and SockJS, like this: https://spring.io/guides/gs/messaging-stomp-websocket/
This implementation supports different protocols: https://github.com/sockjs/sockjs-client#supported-transports-by-name
And the excpection caused only when it works through websocket protocol. If I will change the protocol to xhr-streaming in my frontend implementation, it will works fine!

[elaatifi]

Sorry for the late reply
Did you have a unit test (or small project) to reproduce the error ?

[idelpivnitskiy]

@elaatifi I'll prepare a small project next month, I haven't got enough time now.
Thanks!

[newcgen]

Hello!

I am using Orika in Java EE 6 environment.
I get following exception.

Caused by: java.lang.NoClassDefFoundError: name/of/my/Class
    at java.lang.Class.getDeclaredConstructors0(Native Method)
    at java.lang.Class.privateGetDeclaredConstructors(Class.java:2483)
    at java.lang.Class.getConstructor0(Class.java:2793)
    at java.lang.Class.newInstance(Class.java:345)
    at ma.glasnost.orika.impl.generator.SourceCodeContext.getInstance(SourceCodeContext.java:266)
    at ma.glasnost.orika.impl.generator.MapperGenerator.build(MapperGenerator.java:75)
    at ma.glasnost.orika.impl.DefaultMapperFactory.buildMapper(DefaultMapperFactory.java:1372)
    at ma.glasnost.orika.impl.DefaultMapperFactory.build(DefaultMapperFactory.java:1199)
    at ma.glasnost.orika.impl.DefaultMapperFactory.getMapperFacade(DefaultMapperFactory.java:859)

A similar problem exists and Dozer.
But Dozer allows to replace the default ClassLoader with a custom one.
This workaround solves the problem.

[rickla]

I got these also in a grails environment when I updated to 1.4.6, so had to revert back.

[Jtalk]

This is because JavassistCompilerStrategy uses it's own ClassLoader to load mapping bean classes. Deployment artifacts (WAR, EJB-JAR) and deployment dependencies (/lib/*.jar) are being loaded by different class loaders in some application servers (e.g. in Glassfish). Deployment loader is usually a child of the libraries' one, so JavassistCompilerStrategy cannot access you deployment classes from the parent CL.

The simple workaround is to subclass JavassistCompilerStrategy in your deployment so it's class is loaded by deployment CL. Your overridden class should then be manually applied to the Orika MapperFactory (new DefaultMapperFactory.Builder().compilerStrategy(new YourSubclass()).build() should do the trick).

The actual fix would be to provide JavassistCompilerStrategy with a dependency injection capability allowing it to use custom ClassLoader and ProtectionDomain for mapping classes.

[dickerpulli]

@idelpivnitskiy Have you solved the problem by now?

[idelpivnitskiy]

@dickerpulli no, I decided to use runnable version with embedded Jetty instead of separate Jetty container