geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jarek Gawor (JIRA)" <>
Subject [jira] [Commented] (GERONIMO-6482) Ensure loading of JVM ext classloader classes from Geronimo bundles
Date Fri, 12 Jul 2013 15:19:49 GMT


Jarek Gawor commented on GERONIMO-6482:

I realized that Karaf sets this property in the etc/ file so I moved your
change to that file as well in Geronimo to make things consistent. The end result is pretty
much the same anyway. Changes committed in revision 1502585 in 3.0 branch. Please double check
if things are still working ok and if so close the bug. 

Thanks for the patch!

> 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