Recently I was asked to migrate a legacy web application from an old environment:

• JBoss EAP 4.0.2
• JDK 1.5 (Java SE Development Kit 5.0u22)

to a less old target environment:

• JBoss EAP 5.0.1
• JDK 1.6 (Java SE Development Kit 6u45)

Tests passed successfully and we put the migrated web application in production.

All was going well when suddenly the production log began to grow.

The problem

All was going well when suddenly the production log began to grow filled with lots of the following errors:

java.lang.ClassCastException: com.sun.script.javascript.RhinoScriptEngineFactory cannot be cast to javax.script.ScriptEngineFactory
    at javax.script.ScriptEngineManager.initEngines(ScriptEngineManager.java:109)
    at javax.script.ScriptEngineManager.access$0(ScriptEngineManager.java:86)
    at javax.script.ScriptEngineManager$1.run(ScriptEngineManager.java:80)
    at java.security.AccessController.doPrivileged(Native Method)
    at javax.script.ScriptEngineManager.init(ScriptEngineManager.java:78)
    at javax.script.ScriptEngineManager.<init>(ScriptEngineManager.java:51)
    ...
    at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
    at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
    at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
    ...
    at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:235)
    at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
    at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:190)
    at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:92)
    at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.process(SecurityContextEstablishmentValve.java:126)
    at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:70)
    at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
    at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
    at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:158)
    at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
    at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:330)
    at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:829)
    at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:598)
    at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
    at java.lang.Thread.run(Thread.java:619)

What caused the problem

We quickly understood the problem was related to a feature based on Groovy Scripting Language.

The web application used the jsr223-1.0.jar which provides the support for scripting language. However JDK 1.6 has included JSR 223 Scripting for the Java™ Platform API.

All worked fine on JDK 1.5 but on JDK 1.6 the JBoss class loader incurred in conflicts loading classes from the jsr223-1.0.jar and from the JDK 1.6, generating the log above.

Have you ever heard about JBoss class loader issue before? Sadly a too much common one.

The Solution

The solution consisted in removing the jsr223-1.0.jar from the legacy web application and re-deploying it.

Many thanks to Joseph Valerio and Santosh Singh who documented the problem five years ago!

Lesson Learned

1. When you face a problem track log error messages and relative solution on the Internet, especially if you worked with free or open source software: you are part of the community!
2. Test extensively legacy software during the migration process.
3. Automate tests in order to repeat them on the production target environment
4. As a safety net make sure you can restore the original environment from which you are migrating in case arose unexpected problems on the production target one.
5. Keep the safety net available for enough time after the migration, and throw it away only when you are really confident the migrated situation is stable.

Share your experience about migrating legacy software

I look forward to hearing from you other hints which could be useful migrating a legacy software.