9:34 p.m.
OK, I'm close, but not done. I've put stuff in branches - if you actually svn co
these two branches, build them the normal way and run them, you will see the problem I
describe below. I'm hoping someone can give me some insight into this if possible
First, the branches are:
RHQ: http://svn.rhq-project.org/repos/rhq/branches/AGENT_PLUGIN_CLASSLOADING/
Jopr: https://svn.jboss.org/repos/jopr/branches/INSTANCE_CLASSLOADERS/
If you run a JbossAS 5 instance, deploy the Jopr branch's plugins and then run the RHQ
branch's server and agent, you will notice that this line from the jboss-as-5 plugin:
RemoteProfileServiceConnectionProvider [line: 98]:
profileService = (ProfileService) lookup(initialContext, PROFILE_SERVICE_JNDI_NAME);
produces a ClassCastException. It is trying to cast an AOP dynamic proxy (that is a proxy
to the interface of ProfileService) and its telling me it can't cast to
ProfileService. But it should be able to.
I have a very bad feeling about this. Like the ProfileService interface class was loaded
in one class loader, but the ProfileService interface used by the proxy was loaded by
another classloader.
While at a breakpoint at line 98, I confirmed that the same classloader instance is
returned by a) the current thread's context classloader, b)
this.getClass().getClassLoader() (that is, this RemoteProfileServiceConnectionProvider
instance) and c) ProfileService.class.getClassLoader(). So that's all goodness.
Haven't figured out yet the classloader of the AOP proxy's interface (can't
get to it from the debugger).
I haven't had a chance to delve any deeper other than to actually find this problem
(I've solved many other problems just to get to this point). I'll try to do so
this weekend, but I was hoping maybe someone saw this kind of thing before or knows the
problem?
John
10:03 a.m.
I suspect this does have something to do with the context classloader. A few weeks back, I
discovered that the AOP proxies use Javaassist, which uses the context classloader to load
classes (see http://www.jboss.org/index.html?module=bb&op=viewforum&f=160). The
code that I added in ResourceContainer and DiscoveryComponentProxyFactory to set the
context classloader to the resource classloader prior to any component invocations was
supposed to fix these type of issues, but perhaps that code needs to be updated to take
into account the per-connection classloaders?
Did you try removing the cast so you can print some debug info about the returned proxy
object and compare its classloader with ProfileService.class.getClassLoader()? i.e.:
Object profileService = lookup(initialContext, PROFILE_SERVICE_JNDI_NAME);
System.out.println("ProfileService: " + profileService);
System.out.println("ProfileService.getClass(): " +
profileService.getClass());
System.out.println("ProfileService.getClass().getClassLoader(): " +
profileService.getClass().getClassLoader());
It's worth posting something at
http://www.jboss.org/index.html?module=bb&op=viewforum&f=160 in case Scott has any
insights. He's the one who wrote the code to remote the Profile Service.
On 7/2/2009 10:34 PM, mazz(a)redhat.com wrote:
OK, I'm close, but not done. I've put stuff in branches - if
you actually svn co these two branches, build them the normal way and run them, you will
see the problem I describe below. I'm hoping someone can give me some insight into
this if possible
First, the branches are:
RHQ: http://svn.rhq-project.org/repos/rhq/branches/AGENT_PLUGIN_CLASSLOADING/
Jopr: https://svn.jboss.org/repos/jopr/branches/INSTANCE_CLASSLOADERS/
If you run a JbossAS 5 instance, deploy the Jopr branch's plugins and then run the
RHQ branch's server and agent, you will notice that this line from the jboss-as-5
plugin:
RemoteProfileServiceConnectionProvider [line: 98]:
profileService = (ProfileService) lookup(initialContext,
PROFILE_SERVICE_JNDI_NAME);
produces a ClassCastException. It is trying to cast an AOP dynamic proxy (that is a proxy
to the interface of ProfileService) and its telling me it can't cast to
ProfileService. But it should be able to.
I have a very bad feeling about this. Like the ProfileService interface class was loaded
in one class loader, but the ProfileService interface used by the proxy was loaded by
another classloader.
While at a breakpoint at line 98, I confirmed that the same classloader instance is
returned by a) the current thread's context classloader, b)
this.getClass().getClassLoader() (that is, this RemoteProfileServiceConnectionProvider
instance) and c) ProfileService.class.getClassLoader(). So that's all goodness.
Haven't figured out yet the classloader of the AOP proxy's interface (can't
get to it from the debugger).
I haven't had a chance to delve any deeper other than to actually find this problem
(I've solved many other problems just to get to this point). I'll try to do so
this weekend, but I was hoping maybe someone saw this kind of thing before or knows the
problem?
John
_______________________________________________
jopr-dev mailing list
jopr-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/jopr-dev
--
Ian Springer
Sr. Software Developer
JBoss Operations Network
Red Hat
ian.springer(a)redhat.com
5650
days inactive
5650
days old
1 comments
2 participants
participants (2)
-
Ian Springer -
mazz＠redhat.com