You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@geronimo.apache.org by Radim Kolar <hs...@filez.com> on 2012/03/19 07:54:28 UTC
classloading
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:]
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.
Re: classloading
Posted by David Jencks <da...@yahoo.com>.
On Mar 19, 2012, at 7:25 AM, Ivan wrote:
>
>
> 2012/3/19 Radim Kolar <hs...@filez.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.
>
> 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
Re: classloading
Posted by Ivan <xh...@gmail.com>.
2012/3/19 Radim Kolar <hs...@filez.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.
>
> 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.
>
> Also if you look at http://www.slideshare.net/**
> rayploski/jboss-application-**server-7<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