On Mar 19, 2012, at 7:25 AM, Ivan wrote: > > > 2012/3/19 Radim Kolar <[email protected]> > 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. > > STACKTRACE > at > org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.registerConnection(CachedConnectionManagerImpl.java:265) > at > org.jboss.jca.core.connectionmanager.AbstractConnectionManager.allocateConnection(AbstractConnectionManager.java:495) > at > org.jboss.jca.adapters.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:129) > at org.apache.jsp.index_jsp._jspService(index_jsp.java:256) > at org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:70) > [jbossweb-7.0.13.Final.jar:] > at javax.servlet.http.HttpServlet.service(HttpServlet.java:847) > [jboss-servlet-api_3.0_spec-1.0.0.Final.jar:1.0.0.Final] > at > org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:369) > [jbossweb-7.0.13.Final.jar:] > > Seems an interesting function, I am thinking that there maybe two ways to do > this in Geronimo > 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 > http://www.slideshare.net/rayploski/jboss-application-server-7 slide 6: > > * 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
