geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andy McCright (JIRA)" <>
Subject [jira] [Updated] (GERONIMO-6482) Ensure loading of JVM ext classloader classes from Geronimo bundles
Date Wed, 10 Jul 2013 16:09:48 GMT


Andy McCright updated GERONIMO-6482:

    Attachment: sys-prop-patch.txt

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

> Ensure loading of JVM ext classloader classes from Geronimo bundles
> -------------------------------------------------------------------
>                 Key: GERONIMO-6482
>                 URL:
>             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
>         }
> 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 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(
>     at org.apache.jasper.runtime.HttpJspBase.service(
>     at javax.servlet.http.HttpServlet.service(
>     at org.apache.jasper.servlet.JspServletWrapper.service(
>     at org.apache.jasper.servlet.JspServlet.serviceJspFile(
>     at org.apache.jasper.servlet.JspServlet.service(
>     at javax.servlet.http.HttpServlet.service(
>     at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(
>     at org.apache.catalina.core.ApplicationFilterChain.doFilter(
>     at org.apache.catalina.core.StandardWrapperValve.invoke(
>     at org.apache.catalina.core.StandardContextValve.invoke(
>     at org.apache.geronimo.tomcat.GeronimoStandardContext$SystemMethodValve.invoke(
>     at org.apache.geronimo.tomcat.valve.GeronimoBeforeAfterValve.invoke(
>     at org.apache.geronimo.tomcat.valve.ProtectedTargetValve.invoke(
>     at org.apache.catalina.core.StandardHostValve.invoke(
>     at org.apache.catalina.valves.ErrorReportValve.invoke(
>     at org.apache.catalina.valves.AccessLogValve.invoke(
>     at org.apache.catalina.core.StandardEngineValve.invoke(
>     at org.apache.catalina.connector.CoyoteAdapter.service(
>     at org.apache.coyote.http11.AbstractHttp11Processor.process(
>     at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(
>     at$
>     at org.apache.geronimo.pool.ThreadPool$
>     at org.apache.geronimo.pool.ThreadPool$
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(
>     at java.util.concurrent.ThreadPoolExecutor$
>     at
> 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/
> 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:

View raw message