Classloading problem when using RTC Client libs
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:
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:
* 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.
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
xcep tion: 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
Hi Rafael,
Didn't you have an RTC work item for this one? Looks familiar.
Cheers
--Rupa
Didn't you have an RTC work item for this one? Looks familiar.
Cheers
--Rupa
Comments
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.
Hi Rafael,
Can you create a work item for this issue?