It's all about the answers!

Ask a question

Classloading problem when using RTC Client libs


Rafael Rezende (431423) | asked Oct 14 '16, 8:07 a.m.
We developed 2 Jenkins plugin that uses RTC Plain Client 6.0.x libs.
Both plugins are called from within a Jenkins build, in a sequence, and the first one to be executed works, while the next fails with the following Exception:

com.ibm.team.repository.common .TeamRepositoryException: com.ibm.team.repository.common .internal.marshal.MarshallingE xception: Cannot find package http://schemas.xmlsoap.org/ soap/envelope/
        at sun
.reflect.NativeConstructorA ccessorImpl.newInstance0(Nativ e Method)
        at sun
.reflect.NativeConstructorA ccessorImpl.newInstance(Native ConstructorAccessorImpl.java:6 2)
        at sun
.reflect.DelegatingConstruc torAccessorImpl.newInstance(De legatingConstructorAccessorImp l.java:45)
        at java
.lang.reflect.Constructor. newInstance(Constructor.java:4 23)
        at com
.ibm.team.repository.transp ort.client.RemoteTeamService.g etAppropriateException(RemoteT eamService.java:812
)
        at com
.ibm.team.repository.transp ort.client.RemoteTeamService.e xecuteMethod(RemoteTeamService .java:573)
        at com
.ibm.team.repository.transp ort.client.RemoteTeamService.i nvoke(RemoteTeamService.java:2 02)
        at com
.ibm.team.repository.transp ort.client.ServiceInvocationHa ndler.invoke(ServiceInvocation Handler.java:43)
        at com
.sun.proxy.$Proxy79.describ e(Unknown Source)
        at sun
.reflect.NativeMethodAccess orImpl.invoke0(Native Method)
        at sun
.reflect.NativeMethodAccess orImpl.invoke(NativeMethodAcce ssorImpl.java:62)
        at sun
.reflect.DelegatingMethodAc cessorImpl.invoke(DelegatingMe thodAccessorImpl.java:43)
        at java
.lang.reflect.Method.invok e(Method.java:498)
        at com
.ibm.team.repository.client .internal.ServiceInterfaceProx y.invokeServiceCall(ServiceInt erfaceProxy.java:25
4)
        at com
.ibm.team.repository.client .internal.ServiceInterfaceProx y.invoke(ServiceInterfaceProxy .java:110)
        at com
.sun.proxy.$Proxy79.describ e(Unknown Source)
        at com
.ibm.team.repository.client .internal.TeamRepository$4.run (TeamRepository.java:1565)
        at com
.ibm.team.repository.client .internal.TeamRepository$4.run (TeamRepository.java:1)
        at com
.ibm.team.repository.client .internal.TeamRepository$3.run (TeamRepository.java:1328)
        at com
.ibm.team.repository.common .transport.CancelableCaller.ca ll(CancelableCaller.java:79)
        at com
.ibm.team.repository.client .internal.TeamRepository.callC ancelableService(TeamRepositor y.java:1323)
        at com
.ibm.team.repository.client .internal.TeamRepository.inter nalLogin(TeamRepository.java:1 558)
        at com
.ibm.team.repository.client .internal.TeamRepository.login (TeamRepository.java:654)
        at com
.ibm.team.repository.client .internal.TeamRepository.login (TeamRepository.java:628)
        at com
.pluginb.ccm.deliveryinfo.D eliveryInfoResolver.resolveDel iveryInfo(DeliveryInfoResolver .java:99)
        at com
. pluginb .jenkins.plugins.de liveryinfo.DeliveryInfoResolve rBuilder$ DeliveryInfoResolverCallable.c all(DeliveryInfoResolverBuilde r.java:292)
        at com
. pluginb .jenkins.plugins.de liveryinfo.DeliveryInfoResolve rBuilder$ DeliveryInfoResolverCallable.c all(DeliveryInfoResolverBuilde r.java:228)

When I restart the Jenkins instance (thus the JVM) and execute the plugins in the inverted order, still the first one succeeds, the second fails.

Both plugins are using exactly the same snippet below to log into the server:

    if (!TeamPlatform.isStarted()) {
        TeamPlatform.startup();
    }
   
    ITeamRepository teamRepo = TeamPlatform.getTeamRepositoryService().getTeamRepository(repositoryAddress, ITeamRepositoryService.UNSHARED);
   
    if (!teamRepo.loggedIn()) {
        teamRepo.registerLoginHandler(new LoginHandler(userId, password));
        teamRepo.login(new NullProgressMonitor());
    }


* LoginHandler implements ILoginHandler and ILoginInfo

If Jenkins classloader is loading only one of the versions -- therefore both plugins have the same set of libs loaded -- how come the second one to execute always fails to find that package?

This is an answer from Jenkins community. Jesse Glick is one of the main contributors of the Jenkins core.

2 answers



permanent link
Sreerupa Sen (1.0k4) | answered Oct 19 '16, 6:38 a.m.
FORUM MODERATOR / JAZZ DEVELOPER
Hi Rafael,
     Didn't you have an RTC work item for this one? Looks familiar.
Cheers
--Rupa

Comments
Rafael Rezende commented Oct 19 '16, 12:08 p.m.

Hi Rupa!
You are probably talking about this one:
https://jazz.net/jazz/web/projects/Rational%20Team%20Concert#action=com.ibm.team.workitem.viewWorkItem&id=386956

That one happened because of a serialization issue in some fields I declared in the load rule extension. It crashes when running on slaves.
The current problem happens much deeper, only when both plugins are executed in the same instance. Individually they run through smoothly in masters and slaves.


Lakshmi Narasimhan T V commented Oct 20 '16, 6:10 a.m.
JAZZ DEVELOPER

Hi Rafael,
Can you create a work item for this issue?


permanent link
Luis Peregrina (18114) | answered Oct 19 '16, 10:33 a.m.
JAZZ DEVELOPER
 Hi Rafael, in previous MarshallingExceptions I have seen it's not because of a marshalling problem, rather because there is an UUID that conflicts. So it's going to be something deeper than marshalling.

Your answer


Register or to post your answer.