[
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
