Plugin Development X-Fire Conflicts

Hi..

I'm writing a Plugin for TC which uses WebServices with XFire. Furthermore this WebServices require authentification, so I'm using WSS4J. I've put my Plugin and all necessary libraries into ..TeamCity\webapps\ROOT\WEB-INF\plugins\myplugin. The Plugin seems to be loaded without any problems (at least no exceptions are thrown when server is started), but when I run a Build and my Plugin is executed server throws following exception:

-



WARN - ildServer.util.EventDispatcher - org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: NamespaceURI cannot be null
org.codehaus.xfire.XFireRuntimeException: Could not invoke service.. Nested exception is org.codehaus.xfire.fault.XFireFault: NamespaceURI cannot be null
org.codehaus.xfire.fault.XFireFault: NamespaceURI cannot be null
at org.codehaus.xfire.fault.XFireFault.createFault(XFireFault.java:89)
at org.codehaus.xfire.util.dom.DOMSerializer.writeMessage(DOMSerializer.java:47)
at org.codehaus.xfire.transport.http.HttpChannel.writeWithoutAttachments(HttpChannel.java:56)
at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.getByteArrayRequestEntity(CommonsHttpMessageSender.java:422)
at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.send(CommonsHttpMessageSender.java:360)
at org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:123)
at org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48)
at org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26)
at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:79)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:114)
at org.codehaus.xfire.client.Client.invoke(Client.java:336)
at org.codehaus.xfire.client.XFireProxy.handleRequest(XFireProxy.java:77)
at org.codehaus.xfire.client.XFireProxy.invoke(XFireProxy.java:57)
at $Proxy22.retrieveAll(Unknown Source)
at de.lineas.lit.TargetProcessAddon.JU2TP.TPFactory.ProjectFactory.getAllProjects(ProjectFactory.java:35)
at de.lineas.lit.TeamCityPlugIn.serverSide.TCListener.buildFinished(TCListener.java:60)
at sun.reflect.GeneratedMethodAccessor55.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at jetbrains.buildServer.util.EventDispatcher.dispatch(EventDispatcher.java:5)
at jetbrains.buildServer.serverSide.ServerSideEventDispatcher.access$000(ServerSideEventDispatcher.java:3)
at jetbrains.buildServer.serverSide.ServerSideEventDispatcher$1$1.run(ServerSideEventDispatcher.java:2)
at jetbrains.buildServer.serverSide.impl.auth.SecurityContextImpl.runAs(SecurityContextImpl.java:2)
at jetbrains.buildServer.serverSide.impl.auth.SecurityContextImpl.runAsSystem(SecurityContextImpl.java:20)
at jetbrains.buildServer.serverSide.ServerSideEventDispatcher$1.invoke(ServerSideEventDispatcher.java:2)
at $Proxy1.buildFinished(Unknown Source)
at jetbrains.buildServer.serverSide.impl.BuildServerImpl.finishBuild(BuildServerImpl.java:267)
at jetbrains.buildServer.serverSide.impl.BuildServerImpl.buildFinished(BuildServerImpl.java:377)
at jetbrains.buildServer.serverSide.impl.XmlRpcBasedServer.buildFinished(XmlRpcBasedServer.java:118)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:597)
at jetbrains.buildServer.serverSide.impl.ExceptionCollectorWrapper.execute(ExceptionCollectorWrapper.java:15)
at jetbrains.buildServer.controllers.XmlRpcController$2.execute(XmlRpcController.java:0)
at jetbrains.buildServer.serverSide.impl.MonitoringWrapper.execute(MonitoringWrapper.java:3)
at org.apache.xmlrpc.XmlRpcWorker.invokeHandler(XmlRpcWorker.java:84)
at org.apache.xmlrpc.XmlRpcWorker.execute(XmlRpcWorker.java:146)
at jetbrains.buildServer.controllers.XmlRpcController$1$1.execute(XmlRpcController.java:4)
at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java:139)
at org.apache.xmlrpc.XmlRpcServer.execute(XmlRpcServer.java:114)
at jetbrains.buildServer.controllers.XmlRpcController.handleRequestInternal(XmlRpcController.java:25)
at org.springframework.web.servlet.mvc.AbstractController.handleRequest(AbstractController.java:153)
at org.springframework.web.servlet.mvc.SimpleControllerHandlerAdapter.handle(SimpleControllerHandlerAdapter.java:48)
at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:875)
at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:809)
at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:523)
at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:463)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:710)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:803)
at jetbrains.spring.web.TeamCityDispatcherServlet.service(TeamCityDispatcherServlet.java:9)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:286)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Thread.java:619)
Caused by: javax.xml.stream.XMLStreamException: NamespaceURI cannot be null
at com.sun.xml.internal.stream.writers.XMLStreamWriterImpl.writeAttribute(XMLStreamWriterImpl.java:605)
at org.codehaus.xfire.util.STAXUtils.writeElement(STAXUtils.java:366)
at org.codehaus.xfire.util.STAXUtils.writeNode(STAXUtils.java:391)
at org.codehaus.xfire.util.STAXUtils.writeElement(STAXUtils.java:380)
at org.codehaus.xfire.util.STAXUtils.writeNode(STAXUtils.java:391)
at org.codehaus.xfire.util.STAXUtils.writeElement(STAXUtils.java:380)
at org.codehaus.xfire.util.STAXUtils.writeNode(STAXUtils.java:391)
at org.codehaus.xfire.util.STAXUtils.writeElement(STAXUtils.java:380)
at org.codehaus.xfire.util.STAXUtils.writeNode(STAXUtils.java:391)
at org.codehaus.xfire.util.STAXUtils.writeElement(STAXUtils.java:380)
at org.codehaus.xfire.util.STAXUtils.writeDocument(STAXUtils.java:285)
at org.codehaus.xfire.util.dom.DOMSerializer.writeMessage(DOMSerializer.java:40)
... 62 more

-



I found in some forums that it is an issue with incompatible jars (or jars not in the right order in the classpath), but how to solve this problem.??

BTW: Discussion of this problem started in this thread http://www.intellij.net/forums/thread.jspa?threadID=275985&tstart=60

Edited by: Nico on Jul 9, 2008 5:13 PM

Edited by: Nico on Jul 9, 2008 5:14 PM

6 comments

Hi,

I had this problem myself but in a different context. I had created an ANT task to create a document in Clearspace using their SOAP api. In their WebServices, they use both XFire and WSS4J. If I had all my CS jars located in a folder outside of ANT_HOME/lib (referred to by a taskdef in my build.xml), they I would get this stacktrace. I had to move the CS jars directly into ANT_HOME/lib. Not ideal!

I then discovered it had to do something with my classpath and ANT's classloader. I forget what I had to do specifically to fix this, but it definitely had something to do with duplicate jars in my classpath.

I found this post -- http://www.nabble.com/Cannot-request-WSDL-with-CXF-2.1-deployed-to-Tomcat-td17766300.html. They talk about having the wrong XML streaming parser...

Hope this helps.

Scott

0

Current implementation of plugins uses URLClassLoader to load all plugins classes. Is there some conflicting classes in you plugin and TeamCity? I plan to replace that Classloader with one being similar to WebApplication classloader. So now all resources and classes lookup starts with parent classloader, thus it is impossible to override any class definitions form TeamCity.

Is that related to you issue?

0

I think that's exactly the problem. I'm using libraries TeamCity uses too. When I remove this libraries, TC can't resolve some imports. Is there a way to tell TC to use its libraries for my plugin.?

0

I have added an issue in our tracker for that. Please watch it at http://www.jetbrains.net:8888/tracker/issue/TW-5393

0

One more workaround, please try to use jarjar. http://code.google.com/p/jarjar/
This tool may help to overcome library versions conflicts.
Thanks!

0

i have renamed all classes in xfire-all.jar, but nothing changed.. later i found on google that wstx-asl-3.9.2.jar (http://woodstox.codehaus.org) can reslove such "NamespaceURI can not be null"-conflicts, but replacing stax.jar with it also didn't have any effect.. though, as my application runs pretty good alone, it may be interesting, that it thows exactly the same exceptions, when stax.jar and accordingly wstx-asl-3.9.2 is removed from classpath.. I'm becoming really desperate.. when do you suppose to be able to give me a beta version of the new classloader.?

Edited by: Nico on Jul 20, 2008 7:57 PM

0

Please sign in to leave a comment.