geronimo-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: classloading
Date Mon, 19 Mar 2012 16:34:30 GMT

On Mar 19, 2012, at 7:25 AM, Ivan wrote:

> 2012/3/19 Radim Kolar <>
> Is possible to make stack traces like they are on Jboss 7.1? These traces includes jar
from which was class loaded, this is highly useful when hunting classloading problems.
>        at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.registerConnection(
>        at org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(
>        at org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(
>        at org.apache.jsp.index_jsp._jspService(
>        at org.apache.jasper.runtime.HttpJspBase.service( [jbossweb-7.0.13.Final.jar:]
>        at javax.servlet.http.HttpServlet.service( [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final]
>        at org.apache.jasper.servlet.JspServletWrapper.service(
>  Seems an interesting function, I am thinking that there maybe two ways to do this in
> a. With the StackTraceElement, it is possible to get the class name, then with the class
name, it should be able to find the bundle name with package admin service, but need to consider
more for the current classloading configuration.
> b. Use the internal class,e.g. sun.reflect.Reflection.getCallerClass, seems that it is
able to get the Class instance, then it is easy to find the classloader, then the bundle name.

OSGI logging service provides the bundle that the logging event came from.  I haven't entirely
figured out pax logging but I think that the bundle is already available as something you
can include in the output.

david jencks

> Also if you look at slide
> * Modular
>  * Only API, no AS implementation exposure
>  * True isolation
> this is what should be done in AS because its time consuming to hunt app jars vs application
server jars classloading issues. At geronimo i was not able to run some application at all.
> Yes, you are right, current classloading model in Geronimo 3.0-beta is still following
the multiparent strategy in the past Geronimo versions, and it does bring issues about class
loading conflict. Although hidden-classes could somewhat solve the issue, it is not easy to
find the correct configuration for the users. The possible solution has been discussed for
many times in the past, need to have a minimal public class set. Actually, in those plugin
builder, there has a default environment for this purpose, hope that Geronimo could do that
in the future versions.
> -- 
> Ivan

View raw message