I've successfully managed to create a HTTP Basic Authentication Client.
There is a particular operation that I'm having some doubts as to it's purpose.
I tried a tutorial for a simple helloworld script and some other tutorials are the internet and I saw this:
options.setAction("urn:echo");
If I comment this line of code, the client works anyway.
So what does it do? I can't find specific information about this.
I know that my service has an "echo" operation.
So if I had both an "echo" and "echo2" operations, I would have to call setAction for each one?
Regards,
Nuno.
This is the soapAction attribute in wsdl binding for operation element. If nothing is specified in the WSDL then its value should be blank string or the exact value mentioned in the WSDL should be used here.
Its purpose is not very well defined but it can be used for filtering the traffic.
Related
I just stumbled upon the fact that there are two classes that apparently do very similar things and it is not clear to me from the documentation when to use which.
ServletBearerExchangeFilterFunction and
ServerBearerExchangeFilterFunction
both live in the same package of Spring-Boot-Security-oauth2-resource-server and serve the same purpose of transporting a bearer token from the Context into outgoing http requests.
From the names I would have guessed that the Servlet option would be used for non Reactor projects while the Server version would be used with project Reactor. However that doesn't seem to be the case. At least the Servlet version seems to be working with Spring-WebFlux.
Can anyone please explain when to use which implementation?
We apparently had a false observation when using the ServletBearerExchangeFilterFunction. I corrected this in the original Question.
It turns out the ServletBearerExchangeFilterFunction can be used to configure a WebClient for use in a WebMVC (Thread based request processing) context while the ServerBearerExchangeFilterFunction works when using SpringWebFlux.
We're trying to do a POC showing we can call an external REST service using JBPM in business-central.
We've created a new BPM, then added a REST service task. We notice at this point that a WID file is created that has REST definition. Inside the WID file, it defines things like URL, Method, and authentication.
We've sifted through all the 7.2 docs, but for the life of us, we cannot figure out how to actually set those parameters and do something useful. Does anyone have a simple "Hello World" using business central 7.2 calling out to an external process?
We see there's a predefinied REST handler: https://github.com/kiegroup/jbpm/blob/master/jbpm-workitems/jbpm-workitems-rest/src/main/java/org/jbpm/process/workitem/rest/RESTWorkItemHandler.java
We're lacking how to assemble all of this; we can't find documentation or examples on something that seems so simple.
Thank you!
If you're using Busines Central, you can edit the process model and check the data assignments for the specific REST node. In there you can set the values of the variables or use some process variable to map dynamic values. Hope it helps.
I am using jersey for REST service. I am deploying the REST service using apache tomcat. How do i set the session key in every response.
I have tried the below piece of code
return Response.ok(response.toString(), MediaType.APPLICATION_JSON).cookie(new NewCookie("JSESSIONID", request.getSession().getId())).build();
where request is instance of HttpServletRequest. I want to is there any configuration in web.xml so that the JSESSIONID is set for every response
Generally speaking (this holds true for many frameworks!) anything you want to be used in multiple places is best done with a filter. I'm not going to show you exactly how you do it, as it is very simple and it is better for you to read the docs, but have a look here:
https://jersey.java.net/documentation/latest/filters-and-interceptors.html
You can apply these to both methods and classes, so you only need to place annotations in a couple of places.
A very useful thing for writing clean code!
When I publish a web service created from a WSDL, the WSDL which is created after publishing is different than the original one. The difference is that WSDL/XSD created after publishing had additional element(ARG0) which wraps all root elements.
Because of the reason above, I could not share original WSDL/XSD to client developers since original WSDL and the one created after publishing is not same.
I am using Java as a programming language and JAX-WS.
using API javax.xml.ws.Endpoint to publish the web service without needing any Application server.
Endpoint.publish(url,webserviceinstance)
Thanks in advance.
Since the problem is unneccesary wrapping issue, I focused on wrapping annotations. Eventually I have found out that there is a related annotation for this issue. After adding following annotation statement at the beginning of Class ,problem has been solved.
#SOAPBinding(parameterStyle=SOAPBinding.ParameterStyle.BARE)
public class WebServiceHandler implements WebService {
//....
}
From now on, I can make succesfull request created from original WSDL to deployed machine.
If you post the wsdl, a better assessment can be made. Given that you are seeing an unexpected wrapper, my guess is that jax-ws is interpreting your original wsdl differently than you intend. The page here (http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/) discusses different wsdl configurations. My suggestion is that you follow the instructions for using the document/literal/wrapped convention as it is more or less in the mainstream for soap-based services.
The resulting published wsdl will still likely be a little different in terms of service name, port name or namespace unless you use the #Webservice annotation attributes to force these to particular values, but they will be consistent such that you can provide the published wsdl to your clients and expect success.
The most common reason for this type of issue is that the class implementing the Web service doesn't have an #WebService annotation with the correct endpointInterface attribute. In fact, it is not sufficient to implement the endpoint interface generated from the WSDL.
I am currently developing a RESTful Webservice in Java using the Jersey library.
For security reasons, we want a custom authentication similar to Amazons Simple Storage Service. This requires, however, that I calculate an MD5 hash of the body (if there is any) to authenticate the request.
So far, I have used a custom Authenticator and Realm and plugged them into my context.
Upon trying to calculate the hash I first used the request itself resulting in an IllegalStateException, since the body can only be read once.
After investigating the problem I tried to wrap the request inside a HttpServletRequestWrapper but hasn't been successful so far.
I am basically using a wrapper like the one shown here:
http://forums.oracle.com/forums/thread.jspa?threadID=2156814&tstart=0
Inside my realm, where I do the authentication, I am first creating the wrapper like so:
MyRequestWrapper requestWrapper = new MyRequestWrapper(request);
then I am calculating the MD5 using the requestWrapper
and finally forwarding it
request.getRequestDispatcher("/*").forward(requestWrapper, response);
The processing works fine but I get an error like this after that:
Servlet.service() for servlet Jersey REST Service threw exception
java.lang.IllegalStateException
at org.apache.catalina.connector.ResponseFacade.sendError(ResponseFacade.java:407)
at com.sun.jersey.spi.container.servlet.WebComponent$Writer.finish(WebComponent.java:285)
at com.sun.jersey.spi.container.ContainerResponse.write(ContainerResponse.java:241)
Note that there is no mentioning of the getReader or getInputStream being called before (like I got without using any wrapper at all).
Now I am sure I am doing something wrong here but I really don't know much about this and would be really glad if someone could help me out here :)
Best Regards,
Lukas
As stated in my comment to my question:
I was accessing getReader() from the request. Response I did not touch. However I found that the problem was forwarding the wrapper. I didn't explicitly state this in my question but I am using tomcat and tried to use the above code inside a valve. I am still interested in the question if this is also possible from a valve, since this fits better into the tomcat model. I have now moved to using a filter which is not so nice, but works
I found however that this solution is quite nice (using a filter) instead of a tomcat valve.