RTC 6.0.2 error using jetty
Hello,
When I start debugging getting the server up, I get this error:
I have followed this workshop https://jazz.net/library/content/articles/rtc/4.0/extensions-workshop/downloads/RTC4xExtPoT.pdf
using this comments: https://rsjazz.wordpress.com/2016/02/04/running-the-rtc-extensions-workshop-with-rtc-6-0-x/
HTTP ERROR 500
Problem accessing /jazz/admin. Reason:
loading constraint violation: loader "org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader@4afd0a39" previously initiated loading for a different type with name "org/apache/http/params/HttpParams" defined by loader "org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader@2ceadd57"
Caused by:
java.lang.LinkageError: loading constraint violation: loader "org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader@4afd0a39" previously initiated loading for a different type with name "org/apache/http/params/HttpParams" defined by loader "org/eclipse/osgi/internal/baseadaptor/DefaultClassLoader@2ceadd57"
at java.lang.J9VMInternals.verifyImpl(Native Method)
at java.lang.J9VMInternals.verify(J9VMInternals.java:94)
at java.lang.J9VMInternals.verify(J9VMInternals.java:92)
at java.lang.J9VMInternals.initialize(J9VMInternals.java:169)
at com.ibm.team.repository.service.internal.identity.UserIdentityHelper.getTrustingHttpClient(UserIdentityHelper.java:558)
at com.ibm.team.repository.service.internal.identity.UserIdentityHelper.determineAuthMethod(UserIdentityHelper.java:170)
at com.ibm.team.repository.service.internal.identity.UserIdentityHelper.determineAuthMethod(UserIdentityHelper.java:138)
at com.ibm.team.repository.service.internal.identity.UserIdentityHelper.getAuthMethod(UserIdentityHelper.java:422)
at com.ibm.team.repository.servlet.AbstractTeamServerServlet.handleAuthentication(AbstractTeamServerServlet.java:2084)
at com.ibm.team.repository.servlet.AbstractTeamServerServlet.service(AbstractTeamServerServlet.java:1768)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.eclipse.equinox.http.registry.internal.ServletManager$ServletWrapper.service(ServletManager.java:180)
at org.eclipse.equinox.http.servlet.internal.ServletRegistration.service(ServletRegistration.java:61)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.processAlias(ProxyServlet.java:126)
at org.eclipse.equinox.http.servlet.internal.ProxyServlet.service(ProxyServlet.java:76)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:511)
at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:390)
at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:765)
at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:418)
at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
at org.mortbay.jetty.Server.handle(Server.java:326)
at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:924)
at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
at org.mortbay.jetty.bio.SocketConnector$Connection.run(SocketConnector.java:228)
at org.mortbay.jetty.security.SslSocketConnector$SslConnection.run(SslSocketConnector.java:680)
at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
Powered by Jetty://
2 answers
This is happening to me, too. Notably, however, this is happening after I upgraded from the old 6.0.2 SDK to the new one due to RTC Defect 390811 and tried to create a new Jetty server. I've noticed that there are also a couple of plugins missing from the "[RTCExt] Create RTC Test Database" launch when the new 6.0.2 SDK is set as the target platform.
My theory is that when, like Ralph has experienced, some workspaces (presumably created a while ago) have working 6.0.2 Jetty servers and workspaces with newly attempted 6.0.2 Jetty servers do not work, this is because the old workspaces' Jetty server databases were created using the "[RTCExt] Create RTC Test Database" launch when the old 6.0.2 SDK was in use (at the time, the "[RTCExt] Create RTC Test Database" launch saw all the bundles it needed, but the "[RTCExt] Jetty RTC Server" did not see all the bundles it needed due to the defect in the SDK) and the new workspace's Jetty server database was created with the new 6.0.2 SDK as the target platform either by the "[RTCExt] Create RTC Test Database" launch without all bundles visible or by skipping that workshop step and going straight to the "[RTCExt] Jetty RTC Server" launch (which should work on its own, as long as the server setup process is run with the ADMIN login), which sees all of its necessary bundles but for which the new 6.0.2 SDK has another issue.
There are certainly a lot of variables involved in that very long sentence. If I still had the old 6.0.2 SDK, I would be able to test this further. If anyone else has both available to them, that could be helpful. I'm wondering if a viable process would be to use the workshop's "[RTCExt] Create RTC Test Database" launch while pointing to the old 6.0.2 SDK, followed by changing the target platform to the new 6.0.2 SDK to run the "[RTCExt] Jetty RTC Server" launch.
As answer so that I can add some details.
Ian, I don't have a solution for this.
Adam pinged me with the problem and I went to my setup and everything worked fine. I have several workspaces (copied from the first I created) and all worked for me.
During our analysis I decided to re run the Unit Test to create the database. I did and afterwards the error came up for this workspace. All others still work.
I have no idea and can not explain the error. I don't think we can change the order of loading classes, because the Jetty configuration is built and in a Jar file and I don't see how we could change that.
The only option would be to create a defect and get developer involved.
Comments
Thanks for the feedback. I have raised a jazz.net defect.
https://jazz.net/jazz/web/projects/Jazz%20Foundation#action=com.ibm.team.workitem.viewWorkItem&id=414636
Comments
Adam Wereszczynski
Feb 17 '17, 6:19 a.m.I have the same problem. Did you find a way to resolve it?
Ralph Schoon
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Feb 17 '17, 9:24 a.m.I have a setup that works without problems. Another workspace does not work at all. It shows the same error. I have no idea what the difference is and why one works and one does not.
Ian Wark
Mar 10 '17, 5:44 a.m.Ralph
I also have an identical error. I looked at what may be the cause.. It seems to be a classloading issue with there being two of "org.apache.http.params.HttpParams" being loaded. If we can change the classloading order, I think we could fix this. I can find methods for Jetty that say they change the order.. but I am not sure how to implement such a change. For example, org.eclipse.jett .webapp.WebAppContext.setParentLoaderPriority(boolean) . Have you found a solution yet?
http://www.eclipse.org/jetty/documentation/9.3.x/jetty-classloading.html
http://frankkieviet.blogspot.com.au/2009/03/javalanglinkageerror-loader-constraint.html