[jira] [Updated] (GERONIMO-6482) Ensure loading of JVM ext classloader classes from Geronimo bundles

["Andy McCright (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/GERONIMO-6482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Andy McCright updated GERONIMO-6482:
------------------------------------

    Attachment: sys-prop-patch.txt

This patch adds this system property to the <geronimo-home>/etc/system.properties file:

org.osgi.framework.bundle.parent=framework
                
> Ensure loading of JVM ext classloader classes from Geronimo bundles
> -------------------------------------------------------------------
>
>                 Key: GERONIMO-6482
>                 URL: https://issues.apache.org/jira/browse/GERONIMO-6482
>             Project: Geronimo
>          Issue Type: Bug
>      Security Level: public(Regular issues) 
>          Components: osgi
>    Affects Versions: 3.0.1
>            Reporter: Andy McCright
>            Assignee: Andy McCright
>            Priority: Minor
>         Attachments: sys-prop-patch.txt
>
>
> IBM has changed the classloader used to load com.sun.* (specifically com.sun.script.javascript) classes in JDK 7.  In JDK 6, these classes were loaded by the JVM's boot classloader - in JDK 7, they are loaded via the JVM's ext classloader (a child classloader of the boot loader).  This change has the effect of breaking servlet code like this:
>         ScriptEngineManager manager = new ScriptEngineManager();
>         ScriptEngine engine = manager.getEngineByName("JavaScript");
>         if(engine == null) {
>          throw new RuntimeException("Oh no, unable to find a script engine found for JavaScript");
>         }
> When running Geronimo 3.0.1 on JDK 6, this code works (engine is non-null, no exception is thrown).  When I switch to JDK7, I see:
> ScriptEngineManager providers.next(): javax.script.ScriptEngineFactory: Provider com.sun.script.javascript.RhinoScriptEngineFactory not found
> java.lang.RuntimeException: Oh no, unable to find a script engine found for JavaScript
>     at org.apache.jsp.HelloWorld_jsp._jspService(HelloWorld_jsp.java:96)
>     at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>     at org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:432)
>     at org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:390)
>     at org.apache.jasper.servlet.JspServlet.service(JspServlet.java:334)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:668)
>     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:305)
>     at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
>     at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
>     at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
>     at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(GeronimoStandardContext.java:731)
>     at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(GeronimoBeforeAfterValve.java:48)
>     at org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(ProtectedTargetValve.java:53)
>     at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
>     at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
>     at org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:947)
>     at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
>     at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
>     at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1009)
>     at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
>     at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
>     at org.apache.geronimo.pool.ThreadPool$1.run(ThreadPool.java:267)
>     at org.apache.geronimo.pool.ThreadPool$ContextClassLoaderRunnable.run(ThreadPool.java:397)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1121)
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:614)
>     at java.lang.Thread.run(Thread.java:769)
> The reason this fails is that the bundle's classloader's parent loader is the JVM's boot classloader, not the ext loader - so it cannot load the com.sun.* classes that it needs (and that it could in JDK6).
> One solution to this is to add the following line to <geronimo_home>/etc/system.properties:
> osgi.parentClassloader=ext
> This forces the bundle's to search the ext loader (in addition to the boot loader) on boot delegated loads.
> Jarek suggested using the following system property, which similarly resovles the problem (by forcing all bundles to use the framework classloader as its parent) and is a property used in Karaf:
> org.osgi.framework.bundle.parent=framework

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira