I am trying to intercept SOAP message of a JWS webservice using SOAPHandlerJax-ws SoapHandler.
Below is the snapshot of what I have done.
Wrote a class JwsSoapRequestValidationHandler which extends SOAPHandler
Created HandlerConfig.xml with the below entry:
<jws:handler-chain>
<jws:handler>
<jws:handler-name>SoapRequestValidator</jws:handler-name>
<jws:handler-class>com.service.ws.jws.JwsSoapRequestValidationHandler</jws:handler-class>
</jws:handler>
</jws:handler-chain>
I have placed the xml in the same folder as my webservice.
I have annotated my webservice with #HandlerChain(file = "HandlerConfig.xml")
But strangly anf frustratingly, my handler is not invoked. I have deployed my war file in Weblogic 10.3.2
Please help me resolve this issue. I have spent 2 days without any result.......
Thanks a lot for your help.
At last, I got the solution to this problem. We need to make sure that the HandlerConfig.xml file is present in the generated artifact as well.
As soon as I included the xml in my war file, it started invoking the handler. So easy at the end :) ...
Thanks to all. Hope this will be helpful to others.
Related
I've implemented a simple SOAP webservice client to test the functionality but whether my client or in iex, and regardless of the target service I always get {:ok, :undefined, :undefined}
Here is my code:
wsdl_url = "http://www.webservicex.net/convertVolume.asmx?WSDL"
action = "ChangeVolumeUnit"
parameters = ["100", "dry", "centiliter"]
Detergentex.call(wsdl_url, action, parameters)
I'm using Versions:
Elixir: 1.2.0
Detergentex: 0.0.7
My mix.exs deps:
[{:erlsom, github: "willemdj/erlsom"},{:detergentex, "0.0.7"}]
Any suggestions on what I'm missing would be greatly appreciated.
1.) It's got a dependency on the detergent package.
Have you added the dependency for detergent? If not modify your mix.exs to this:
[{:erlsom, github: "willemdj/erlsom"},{:detergentex, "0.0.7"}, {:detergent, "~> 0.3.0"}]
2.) You also need to add detergentex to the list of applications as well:
def application do
[applications: [:logger, :detergentex]]
end
3.) The fact that it's returning {:ok, :undefined, :undefined} may simply indicate an issue with the endpoint or the message you're passing. Therefore I'd try it against an endpoint you're sure is good with a message you're sure will work. Perhaps the valid parameters to the endpoint they mention in their docs have changed since the docs were prepared.
By the way, I did see that you mentioned "regardless of the target service" but given it seems that you failed to add that detergent dependency and the fact that it looks like you forgot to add detergent to the application list, I'd still try some of those other SOAP endpoints again since you've changed things.
I'm getting some error with some connection to our web server.
I saw that a bug causing this was solved in Jetty 7.6. Yes we get this error on our application running under Jetty 7.5.4 but we also get this with another apps running on a newer version 9.
Do you have any idea what this can be?
We are getting this error randomly:
java.lang.IllegalStateException: zip file closed
at java.util.zip.ZipFile.ensureOpen(ZipFile.java:632)
at java.util.zip.ZipFile.access$200(ZipFile.java:56)
at java.util.zip.ZipFile$1.hasMoreElements(ZipFile.java:485)
at java.util.jar.JarFile$1.hasMoreElements(JarFile.java:239)
at org.eclipse.jetty.util.resource.JarFileResource.exists(JarFileResource.java:163)
at org.eclipse.jetty.webapp.WebAppContext$Context.getResource(WebAppContext.java:1223)
at org.eclipse.jetty.servlet.DefaultServlet.getResource(DefaultServlet.java:366)
at org.eclipse.jetty.server.ResourceCache.lookup(ResourceCache.java:188)
at org.eclipse.jetty.servlet.DefaultServlet.doGet(DefaultServlet.java:445)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:707)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:820)
at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:547)
at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:480)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:483)
at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:227)
at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:941)
at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:409)
at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:186)
at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:875)
at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:219)
at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:345)
at org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:441)
at org.eclipse.jetty.server.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:919)
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:722)
There are 2 main causes for this.
A bad/corrupt JAR file in your classpath.
The JVM built-in URL caching getting in the way.
For a bad/corrupt JAR file, you'll have to isolate that on your own, figure out which one it is. Maybe by just unjaring all of them one by one till you find the problematic one.
As for the JVM URL caching, this seems to cause problems with dynamic classloaders like OSGi or hot-deploy scenarios the most.
For this scenario, you can tell jetty to set the URLConnection.setUseCaches(boolean) for each URLConnection attempt of its own.
To disable the JVM caches, add the following snippet of XML to your etc/jetty.xml
<Set class="org.eclipse.jetty.util.resource.Resource"
name="defaultUseCaches">false</Set>
You don't need to test all files to ensure the correctness of them. Just put a break point at java.util.zip.ZipFile.ensureOpen(ZipFile.java:632) and check the name field in ZipFile class: private final String name
I had the same problem after deploying jenkins war; all I had to do was to restart the server after the deploy.
Hope it helps.
This issue can also occur if you are doing any of your own reflection in that code path.
I was having the same issue because of the actual WAR being corrupt. Try rerunning mvn clean install and redeploy.
I had the same problem, after deleting all .jar files and build the path to all .jar file once again. Now it's working properly
I am using CXF JAXWS Client for retrieving some information from an external web services. So, basically, we have .xsd and .wsdl files from the external and try to implement our ws consumer by generating the client stubs using cxf-codegen-plugin. We cannot change the .xsd and .wsdl files. Everything works fine, we are able to send and retrieve soap messges from the external services.
However, when I look into the soap request message from the log, I find a lot of unused namespaces in the soap (body) message sent from our ws client.
Below is an example
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:aheaderns="http://xxx.xxx.xxx.xxx/header.xsd">
<soap:Header>
...
</soap:Header>
<soap:Body>
<ns7:requestQuery xmlns:ns15="http://xxx.xxx.xxx.xxx/AAA" xmlns:ns14="http://xxx.xxx.xxx.xxx/BBB" xmlns:ns13="http://xxx.xxx.xxx.xxx/DDD" xmlns:ns12="http://xxx.xxx.xxx.xxx/CCC" xmlns:ns11="http://xxx.xxx.xxx.xxx/EEE" xmlns:ns10="http://xxx.xxx.xxx.xxx/FFF" xmlns:ns9="http://xxx.xxx.xxx.xxx/GGG" xmlns:ns8="http://xxx.xxx.xxx.xxx/HHH" xmlns:ns7="http://xxx.xxx.xxx.xxx/III" xmlns:ns6="http://xxx.xxx.xxx.xxx/JJJ" xmlns:ns5="http://xxx.xxx.xxx.xxx/KKK">
<ns7:sample>
<ns7:type>A</ns7:type>
<ns7:ref>1</ns7:ref>
</ns7:sample>
</ns7:requestQuery>
</soap:Body>
Is there any way to remove the unused namespaces from the outbound soap message sending from the client?
You could move your client proxy classes to the same package and map it to the proposed namespace specified in the wsdl.
Put this code into the package-info.java class:
#XmlSchema(xmlns = { #XmlNs(prefix = "ns1", namespaceURI = "http://xxx.xxx.xxx") },
namespace = "http://xxx.xxx.xxx")
package clinet.sample.proxy;
import javax.xml.bind.annotation.XmlNs;
Hope this helps.
After digging into this problem for quite sometime, I found the solution. However, I think my solution is not to solve the problem at the root cause but it works for now.
Basically, I use XSLTOutInterceptor from CXF to apply the XSL to the out message. However, the default PRE_STEAM phase is not working for me. Then, I decide to extend the XSLTOutInterceptor so as to change its PHASE to WRITE. So that, the unused namespaces will be removed during the writing of the protocol message before sending it out.
The XSL I use is from how to remove unused namespaces from source xml
By the way, I still have no idea why those unused namespaces have been generated. If anyone could give me a suggestion, I would appreciate it.
Thanks :)
I am new to the wsdl\soapmessage query\reply world( if i can put it in this way), and I am facing some difficulties using the following wsdl( which I really really hope, one will be so kind to look at at least one of the services described there)
http://almdemo.polarion.com/polarion/ws/services/TrackerWebService?wsdl
which was provided to me to develop a matlab webinterface. Right now my matlab code looks like this:
targetNamespace = 'http://ws.polarion.com/TrackerWebService';
method = 'queryWorkItems';
values= {'Query','Sort'}
names = {'query', 'sort'}
types ={'xsd:string','xsd:string'}
message = createSoapMessage( targetNamespace, method, values, names, types)
response = callSoapService('http://almdemo.polarion.com/polarion/ws/services',...
% Service's endpoint
'http://almdemo.polarion.com/polarion/#/workitems',...
% Server method to run
message)
% SOAP message created using createSoapMessage
author = parseSoapResponse(response)
Herewith to save you time I will just enonce my two problems:
Is the code correct?
Could someone tell me if such a wsdl link is just a definition of webservices or it is also a service's endpoint?
Normally to execute manually\per clicks this services on the weppage
http://almdemo.polarion.com/polarion, you have to login!
So how do I send a message in matlab which first log me in? Or must such a service be introduced into that wsdl for me to do it?? Could you be kind enough to write how it must be defined, because I don't really
write wsdl files, but I shall learn!**
I will be really thankful for your help and I wish you a happy week(-end) guys(& girls)!!!
Regards
Chrysmac
ps: I tried to use Soapui and gave that webpage as endpoint, but the toool crashes each time I enter my credentials! Maybe because of the dataload!??
A weird case is happening in my application, some code that is in a Guice EagerSingleton is being run twice. I printed a stack trace (Below) and it shows that the public static main of jetty is being called twice. Where could I have miss-configured it?
//Stack trace (Is printing in logs twice)
at com.ea.wsop.GraphiteReporterConfig.<init>(GraphiteReporterConfig.java:50)
at com.ea.wsop.GraphiteReporterConfig$$FastClassByGuice$$22005e5b.newInstance(<generated>)
at com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)
...
at org.eclipse.jetty.start.Main.invokeMain(Main.java:477)
at org.eclipse.jetty.start.Main.start(Main.java:623)
at org.eclipse.jetty.start.Main.parseCommandLine(Main.java:273)
at org.eclipse.jetty.start.Main.main(Main.java:81)
I am running Jetty 7.2.2 & Guice Version 3.0, Please comment on which other config files would be useful to post here.
or you can use either the webapp provider or the context provider but not both in this case
I am a fan of just using contexts personally, more nimble.
just remove the jetty-webapps.xml line in your start.ini
Figured it out,
I was setting up the web app in /home/j2play/j2play/jetty/contexts/app.xml and it was in the standard Jetty/webapps directory so jetty was scanning and starting it automatically too. I moved my war outside the standard location and it works fine.