I am new to SOAP-UI. When I am trying to parse WSDL using soapui-4.0.1.0.jar it is throwing exception
ClassNotFoundException:
org.xmlsoap.schemas.ws.x2004.x09.policy.PolicyDocument$Factory
Please help me to sort out this problem.
Stack Trace: [com.eviware.soapui.impl.wsdl.support.policy.PolicyUtils.getAddressingPolicy(PolicyUtils.java:303), com.eviware.soapui.impl.wsdl.support.policy.PolicyUtils.getPolicy(PolicyUtils.java:287), com.eviware.soapui.impl.wsdl.support.policy.PolicyUtils.getAttachedPolicy(PolicyUtils.java:249), com.eviware.soapui.impl.wsdl.support.soap.AbstractSoapBindingImporter.initWsAddressing(AbstractSoapBindingImporter.java:43), com.eviware.soapui.impl.wsdl.support.soap.Soap12HttpBindingImporter.importBinding(Soap12HttpBindingImporter.java:88), com.eviware.soapui.impl.wsdl.support.wsdl.WsdlImporter.importBinding(WsdlImporter.java:264), com.eviware.soapui.impl.wsdl.support.wsdl.WsdlImporter.importWsdl(WsdlImporter.java:154), com.eviware.soapui.impl.wsdl.support.wsdl.WsdlImporter.importWsdl(WsdlImporter.java:80), com.eviware.soapui.impl.wsdl.support.wsdl.WsdlImporter.importWsdl(WsdlImporter.java:75),
I have tested/executed and able to parse WSDL's using policy-xmlbeans-1.5.jar and later commons-beanutils-1.9.3.jar is also required.
OC4J jar referred on findjar didn't worked for me...
A ClassNotFoundException indicates that you may not have included the necessary dependencies/jars in your project. The org.xmlsoap.schemas.ws.x2004.x09.policy.PolicyDocument class you seek may be found on the OC4J page according to findjar.com.
Related
I'm getting the below error while trying to create JWTVerifier object in order to decode the token. Can you please help me understand what could be the root cause? Thanks in advance.
java.lang.NoSuchMethodError: com.fasterxml.jackson.databind.ObjectMapper.readerFor(Ljava/lang/Class;)Lcom/fasterxml/jackson/databind/ObjectReader;
at com.auth0.jwt.impl.JWTParser.<init>(JWTParser.java:25)
at com.auth0.jwt.impl.JWTParser.<init>(JWTParser.java:20)
at com.auth0.jwt.JWTDecoder.<init>(JWTDecoder.java:27)
at com.auth0.jwt.JWT.decode(JWT.java:45)
I believe, you are using the wrong jackson-databind library version. The error you see appears, when you have a library containing a class but the class is missing a method. Why? Well, probably the method is not in the version you are using or has been deprecated and removed.
Please check your maven/gradle/whatever you are using and play with the version definition a bit. If this does not help, see the output of mvn dependency:tree or similar in the build tool of your choice.
I want to call webservice from flex3. Webservice works as util jar without fault but ı can't run it from flex. It gives the following error
java.lang.NoSuchMethodError : com.sun.xml.ws.api.pipe.ClientTubeAssemblerContext.getPortInfo()
Lcom/sun/xml/ws/api/client/WSPortInfo;:null error.
Any idea how to resolve it?
You need to add correct version of library file.
jaxws-rt-2.2.5.jar file contain the required method com.sun.xml.ws.api.pipe.ClientTubeAssemblerContext.getPortInfo().
Test adding above mentioned library.
I've seen many issues related to this exception here in so and most of them are being solved by adding a "commons-file-upload" jar from apache. I tried to use this solution and I've added the same version of the jar for all my projects, but it does not seem to fix the problem, I'm still facing the problem. I know this question has been already asked, but I wonder if somebody could give me a hand with this specific problem. This is my stacktrace:
java.lang.NoSuchMethodError: javax.servlet.http.HttpServletRequest.getParts()Ljava/util/Collection;
at fr.synomia.v4.ws.remotelayer.ws.rest.RESTServer.getParameters(RESTServer.java:378)
at fr.synomia.v4.ws.remotelayer.ws.rest.RESTServer.parseURLRequest(RESTServer.java:367)
at fr.synomia.v4.ws.remotelayer.ws.rest.RESTServer.access$0(RESTServer.java:354)
at fr.synomia.v4.ws.remotelayer.ws.rest.RESTServer$1.handle(RESTServer.java:67)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:346)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:442)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:924)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:582)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:218)
at org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:662)
The exception is thrown when I invoke the method getParts from my class RestServer using HttpServletRequest, I've been looking for information and it says that the version of the jar used must be the same for all the projects and I did it that way, but not working.
The piece of code invoking the getParts() :
private Map<String,Object> getParameters(HttpServletRequest request,boolean jsonp, String callback) {
Map<String,Object> lsParameteres = new HashMap<String, Object>();
Collection<Part> parts = null;
try {
parts = request.getParts();//The exception begins here!
I will be grateful if somebody could help me, thanks for your time. Best regards.
javax.servlet.http.HttpServletRequest.getParts() is only available starting with Servlet API 3.0
Things to check:
Be sure you are running Jetty 9 (or newer)
Make sure you have your WEB-INF/web.xml configured to use Servlet API 3.0 (or newer)
Make sure your build tool is using the servlet-api 3.1 (or newer) jars.
(Optionally) Make sure you have the same servlet api 3.1 jar in your WEB-INF/lib directory.
I encountered the same issue. It happened when I switched to Tomcat 6. When I switched back to Tomcat 7, the issue disappeared.
Spring framework throws
Exception in thread "main" java.lang.NoSuchMethodError: org.slf4j.spi.LocationAwareLogger.log(Lorg/slf4j/Marker;Ljava/lang/String;ILjava/lang/String;Ljava/lang/Throwable;)V
at org.apache.commons.logging.impl.SLF4JLocationAwareLog.info(SLF4JLocationAwareLog.java:159)
at org.springframework.context.support.AbstractApplicationContext.prepareRefresh(AbstractApplicationContext.java:454)
at org.springframework.context.support.AbstractApplicationContext.refresh(AbstractApplicationContext.java:392)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:139)
at org.springframework.context.support.ClassPathXmlApplicationContext.<init>(ClassPathXmlApplicationContext.java:93)
what's the reason?
The reason is wrong version of library added (version conflict).
Check for the version of slf4j 's javadoc and try to figure out ,this method exist with which version ?
If you are running OSX you might find this is because the following files are included as java extensions:
/Library/Java/Extensions/slf4j-api-1.5.8.jar
/Library/Java/Extensions/slf4j-log4j12-1.5.8.jar
These are loaded by the extension classloader, before your application classloader, so these will be resolved first.
I have no idea why these are there or when they were added but i've only seen this on OSX and in the last year, which might imply they were introduced in java 6.
You can remove\move the files to workaround the problem, but there might be some applications which depend on them.
You might be having a class twice in your classpath.
Check the classpath for the occurrences.
I'm looking for a few days for the solution to an UnresolvedAddressException I can't figure out!
It seems it's quite a challenging problem, since I couldn't even find other info on the net!
I'm working with OSGi framework on JamVM.
I get this exception when using Date.toString o SimpleDateFormat on a Calendar object. I can't understand why the bundle tries to connect after the getZoneStrings function. It seems it cannot find the locale but I'm not sure this is the problem.
I tried adding the file /etc/timezone (that was missing) but it didn't solve the problem.
Here's the complete stack trace of the exception:
adsdebian:/usr/local/bundle# org.osgi.framework.BundleException: Activator start error in bundle zApp_RoadPricing [24].
at org.apache.felix.framework.Felix.startBundle(Felix .java:1506)
at org.apache.felix.framework.BundleImpl.start(Bundle Impl.java:774)
at org.apache.felix.shell.impl.StartCommandImpl.execu te(StartCommandImpl.java:105)
at org.apache.felix.shell.impl.Activator$ShellService Impl.executeCommand(Activator.java:291)
at org.apache.felix.shell.remote.Shell.run(Shell.java :109)
at java.lang.Thread.run(Thread.java:743)
Caused by: java.nio.channels.UnresolvedAddressException
at gnu.java.nio.SocketChannelImpl.connect(SocketChann elImpl.java:160)
at gnu.java.net.PlainSocketImpl.connect(PlainSocketIm pl.java:281)
at java.net.Socket.connect(Socket.java:454)
at java.net.Socket.connect(Socket.java:414)
at gnu.java.net.protocol.http.HTTPConnection.getSocke t(HTTPConnection.java:719)
at gnu.java.net.protocol.http.HTTPConnection.getOutpu tStream(HTTPConnection.java:800)
at gnu.java.net.protocol.http.Request.dispatch(Reques t.java:291)
at gnu.java.net.protocol.http.HTTPURLConnection.conne ct(HTTPURLConnection.java:219)
at gnu.java.net.protocol.http.HTTPURLConnection.getHe aderField(HTTPURLConnection.java:582)
at java.net.URLConnection.getHeaderFieldInt(URLConnec tion.java:426)
at java.net.URLConnection.getContentLength(URLConnect ion.java:302)
at gnu.java.net.loader.RemoteURLLoader.getResource(Re moteURLLoader.java:79)
at java.net.URLClassLoader.findResources(URLClassLoad er.java:720)
at java.lang.ClassLoader.getResources(ClassLoader.jav a:640)
at gnu.classpath.ServiceFactory.lookupProviders(Servi ceFactory.java:286)
at java.util.ServiceLoader$1.hasNext(ServiceLoader.ja va:163)
at java.text.DateFormatSymbols.getZoneStrings(DateFor matSymbols.java:123)
at java.text.DateFormatSymbols.<init>(DateFormatSymbo ls.java:192)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat .java:448)
at java.text.SimpleDateFormat.<init>(SimpleDateFormat .java:430)
at crf.opengate.app.roadpricing.RoadPricing.<init>(Ro adPricing.java:109)
at java.lang.reflect.Constructor.constructNative(Nati ve Method)
at java.lang.reflect.Constructor.newInstance(Construc tor.java:328)
at java.lang.Class.newInstance(Class.java:1154)
at org.apache.felix.framework.Felix.createBundleActiv ator(Felix.java:3341)
at org.apache.felix.framework.Felix.startBundle(Felix .java:1453)
...5 more
Is there anyone who could help me, please?
Thanks,
Andrea
Add to andre26's Reputation
Found this link which talks of a similar issue that got resolved by switching to Felix version 2.0.2. Maybe you could try that?
It's hard to be definitive without looking at the JamVM source code, but the stacktrace tells me that inside getZoneStrings there is an attempt to load a class or other file via the classloader (hence the call to ClassLoader and URLClassLoader three layers down the stack).
That attempt at classloading is not finding the address a URL that is in the classpath. That could be because you have a problem later on in your classpath and since it didn't find the file where you are putting your classes it went looking in the next place, which had an UnresolvedAddressException (by the way, that seems like an odd violation of the spec, the classloader should throw its checked exception. Here it seems that GNU classpath is letting a runtime exception leak out which should instead be converted into an exception indicating that the class cannot be found), or it could just be that that is what it does when it can't find a resource.
As for what class is not being found, it seems to be one of the ServiceProviders configured, perhaps in GNU Classpath:
at gnu.classpath.ServiceFactory.lookupProviders(Servi ceFactory.java:286)
The above is the core of the problem. It is looking up a provider, and attempted to get a resource from the classpath that likely doesn't exist.
It is impossible to say what exactly it is looking for without examining the source code. Fortunately you seem to be using all open source stuff, so it should be fairly easy to find.
Thanks JRL, the solution posted in the link you suggested me solved the problem!
I couldn't expect in such a bug of felix even because I thought I had already used Date and Calendar classes on the same platform and in the same conditions!
Just sum up of solution:
download newer version of felix (from at least 2.0.2) - from http://felix.apache.org/site/downloads.cgi get the .jar named Main (i.e. the bundle for the OSGi framework)
save it in the bin/ directory where your current felix.jar resides
rename felix.jar as felix.jar_old (after shutting down the OSGi FX if it's running!)
rename the newer version of felix (ex. org.apache.felix.main-2.0.3.jar) as felix.jar
restart the OSGi framework with your app
Hope this helps to someone else!
Bye,
Andrea
(Sorry for the second username...I register quite long time ago but I forgot about the google identification! :-) )