2012/3/19 Radim Kolar <email@example.com>
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.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.
Also if you look at http://www.slideshare.net/rayploski/jboss-application-server-7 slide 6:
* 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.