We Keep Coding

How to trigger Spark Java Web Framework request programmatically

Is there a way for Spark Framework to trigger request programmatically? Say we have
http.get("/hello/:route_param") { "Hello Spark!" }
How it could be called, with proper path, query, body etc, something like:
http.call(
url = "/hello/alex?a=b",
body = "{ value: 20 }"
) // => "Hello Spark!"
P.S.
I need it to add batch /batch route - so it will be possible to call it with the list of other routes and parameters and get back list of results.

If by "programmatically" you mean "without firing up an HTTP server and performing an HTTP request" than I think the answer is no. Spark does not provide such a capability out of the box.
There are a few possible workarounds:
You could start Spark in your application and fire an HTTP request. An example of this approach is in an integration test I wrote for my Spark add-on
Use MockRunner's Servlet module to create a (fake) HttpServletRequest. Use RequestResponseFactory.create(HttpServletRequest) to turn that into a Spark Request. Similarly for responses. Refactor the Spark Route to be a separate class, and invoke that using the Request and Response variables that you just created.

Java Web service client can't connect to BPEL webservice when SoapUI can

I am experiencing the following error and after extensive research on the matter with a few similar issues, none seem to help.
My error:
com.sun.xml.internal.ws.client.ClientTransportException: HTTP transport error: java.net.ConnectException: Connection refused: connect
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:121)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.process(HttpTransportPipe.java:142)
at com.sun.xml.internal.ws.transport.http.client.HttpTransportPipe.processRequest(HttpTransportPipe.java:83)
at com.sun.xml.internal.ws.transport.DeferredTransportPipe.processRequest(DeferredTransportPipe.java:105)
at com.sun.xml.internal.ws.api.pipe.Fiber.__doRun(Fiber.java:587)
at com.sun.xml.internal.ws.api.pipe.Fiber._doRun(Fiber.java:546)
at com.sun.xml.internal.ws.api.pipe.Fiber.doRun(Fiber.java:531)
at com.sun.xml.internal.ws.api.pipe.Fiber.runSync(Fiber.java:428)
at com.sun.xml.internal.ws.client.Stub.process(Stub.java:211)
at com.sun.xml.internal.ws.client.sei.SEIStub.doProcess(SEIStub.java:124)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:98)
at com.sun.xml.internal.ws.client.sei.SyncMethodHandler.invoke(SyncMethodHandler.java:78)
at com.sun.xml.internal.ws.client.sei.SEIStub.invoke(SEIStub.java:107)
at com.sun.proxy.$Proxy33.onboardPerson(Unknown Source)
at com.paychex.corp.fileloader.FileloaderMain.callWebService(FileloaderMain.java:202)
at com.paychex.corp.fileloader.FileloaderMain.main(FileloaderMain.java:104)
Caused by: java.net.ConnectException: Connection refused: connect
at java.net.PlainSocketImpl.socketConnect(Native Method)
at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:351)
at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:213)
at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:200)
at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366)
at java.net.Socket.connect(Socket.java:529)
at java.net.Socket.connect(Socket.java:478)
at sun.net.NetworkClient.doConnect(NetworkClient.java:163)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:411)
at sun.net.www.http.HttpClient.openServer(HttpClient.java:525)
at sun.net.www.http.HttpClient.<init>(HttpClient.java:208)
at sun.net.www.http.HttpClient.New(HttpClient.java:291)
at sun.net.www.http.HttpClient.New(HttpClient.java:310)
at sun.net.www.protocol.http.HttpURLConnection.getNewHttpClient(HttpURLConnection.java:987)
at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:966)
at sun.net.www.protocol.http.HttpURLConnection.connect(HttpURLConnection.java:841)
at sun.net.www.protocol.http.HttpURLConnection.getOutputStream(HttpURLConnection.java:1031)
at com.sun.xml.internal.ws.transport.http.client.HttpClientTransport.getOutput(HttpClientTransport.java:109)
My client is generated from wsimport using the WSDL file that IS visible from the active service. Code connection sample: URL and service name, etc are correct, can't list for security
URL url = new URL("http://correctserviceurl?WSDL");
QName qname = new QName("http://correct servicelocation","nameofService");
CorporateEmployeeOnboardingService service = new CorporateEmployeeOnboardingService(url, qname);
//CorporateEmployeeOnboardingService service = new CorporateEmployeeOnboardingService();
CorporateEmployeeOnboardingProcess process = service.getICorporateEmployeeOnboardingProcess();
OnboardRequestType onboardRequest = new OnboardRequestType();
/**
* TESTING SECTION FOR PROCESS CALL
*/
//create necessary complex types:
GregorianCalendar gregorianCalendar = new GregorianCalendar();
DatatypeFactory datatypeFactory;
datatypeFactory = DatatypeFactory.newInstance();
XMLGregorianCalendar testDate =
datatypeFactory.newXMLGregorianCalendar(gregorianCalendar);
testDate.setYear(1991);
testDate.setMonth(4);
testDate.setDay(3);
AssignmentComplexType testAssignment = new AssignmentComplexType();
testAssignment.setHiringManagerID("123445");
//set person to send
person.setSSN("333-33-3333");
person.setFirstName("testFname");
person.setLastName("testLname");
person.setDOB(testDate);
person.setHireDate(testDate);
person.setAssignment(testAssignment);
/**
* end testing section of the person creation
*/
onboardRequest.getPerson().add(person);//add a person to the array of people for the request
ServiceResponse response = process.onboardPerson(onboardRequest);
As stated SoapUI can send this same test information and get a perfectly valid request from the service. All information the same. I have been digging around for awhile and confirmed that there is no proxy, both are same bit (32/64 in this case both 32), service name and WSDL are correct and objects are named properly, etc. I did further debugging trying to get around this awful error code that has seemingly no usable information and using wireshark compared the SoapUI request to the java request to find that SoapUI was using POST and the java client was using GET which has me leaning on this right now as the source of the generic refused connection error.
The service is using BPEL to run and was created using BPEL so all code was basically generated. I will be looking at the Get/post find as of now but wanted to get this out there as I am doubtful it could be the cause.
Any help is greatly appreciated. Let me know if I forgot any key information I might be able to share.
EDIT
I wanted to add that I am able to access the endpoint URL in the web browser from the machine that I am using to try and connect to the BPEL service. It seems the issue is solely with the client generated from the WSDL stubs I got using wsimport for the service's WSDL.
Edit 2: Development/Progress
The issue seems to be that the client is sending the response to local host even after setting up the qname to the correct address. I am now trying to figure out where this local host is being set. Any ideas on this development would be greatly appreciated.

It's been a while, but I believe this line: URL url = new URL("http://correctserviceurl?WSDL");
Needs to read: URL url = new URL("http://correctserviceurl");

K! This one was an issue with BPEL I believe. Quite frustrating. Apparently after initializing the service in the following lines:
URL url = new URL("http://serviceaddresshere?WSDL");
QName qname = new QName("http://servicelocationaddress","NameOfService");
CorporateEmployeeOnboardingService service = new CorporateEmployeeOnboardingService(url, qname);
CorporateEmployeeOnboardingProcess process = service.getICorporateEmployeeOnboardingProcess();
BPEL gets the request with the service WSDL and the CORRECT address. However, BPEL seems to think "O? you want this service, here you go I'll give you that, only the WSDL you want is wrapper, so here's the REAL WSDL." In plain english, you get back the BPEL WSDL that it thinks is for the service, and this has the Localhost address in it. Now I tried changing the address in this WSDL but BPEL through errors up the wazzoo. So the work around was adding in this line after the process variable is make: (AKA THE FIX)
((BindingProvider) process).getRequestContext().put(Dispatch.ENDPOINT_ADDRESS_PROPERTY, "http://the serviceaddress");
Bassically you set the endpoint AGAIN after you make the process, because BPEL overwrites what you sent it the first time. This is of course a sort of work around, but the process now works good. If you can think of a way to bypass this work around and dynamically fix the service so we don't have to keep changing the service WSDL when we move ti to new enviornments like Dev, etc. I am all ears. Thanks and as always I will read comments for suggestions. =)

You can use bpel configuration plans to switch between environments.
Configuration plans are the recommended option to use for making composites environment specific.
Efficient use of configuration plans can greatly reduce the work required per process.
A configuration plan can be generated from the composite.xml file.
Please consider this link:
http://biemond.blogspot.com.br/2010/02/web-service-references-and-soa.html

Amazon Product Advertising API request with Java

Hi My code for the same is
// Initialize Web Service
HandlerResolver handlerResolver=new AwsHandlerResolver(credentials.getAWSSecretKey());
AWSECommerceService service = new AWSECommerceService();
service.setHandlerResolver(handlerResolver);
// Create Web Service Connection
AWSECommerceServicePortType port = service.getAWSECommerceServicePort();
// Add Parameters for the Item Lookup
ItemLookupRequest itemLookup = new ItemLookupRequest();
itemLookup.setIdType("ASIN");
itemLookup.getItemId().add("B000RE216U");
// Wrap Request in Lookup Body
ItemLookup lookup = new ItemLookup();
lookup.setAWSAccessKeyId(credentials.getAWSAccessKeyId());
lookup.getRequest().add(itemLookup);
ItemLookupResponse response = port.itemLookup(lookup);
System.out.println("response: " + response.toString());
I keep getting the error cannot convert from Void to AWSECommerceService in the beginning. I have the AWSHandlerResolver file and codec jar installed and configured.
Error Message:
Exception in thread "main" javax.xml.ws.WebServiceException: {http://webservices.amazon.com/AWSECommerceService/2010-11-01}AWSECommerceService is not a valid service. Valid services are: {http://webservices.amazon.com/AWSECommerceService/2011-08-01}AWSECommerceService
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:223)
at com.sun.xml.internal.ws.client.WSServiceDelegate.<init>(WSServiceDelegate.java:168)
at com.sun.xml.internal.ws.spi.ProviderImpl.createServiceDelegate(ProviderImpl.java:96)
at javax.xml.ws.Service.<init>(Service.java:77)
at com.ECS.client.jax.AWSECommerceService.<init>(AWSECommerceService.java:46)
I have been searching online. I might have to change target namespace for AWSECommerceService. But cannot find how. Please help me

You are using the wrong namespace (actually, the wrong version of WS) for your Webservice client and its port.
Go to AWSECommerceService and AWSECommerceServicePortType classes and replace all namespaces which look like http://webservices.amazon.com/AWSECommerceService/2010-11-01 with http://webservices.amazon.com/AWSECommerceService/2013-08-01.

How do I specify url in JAX-WS call and avoid initial network connection?

I'm using JAX-WS standard stuff with wsimport http://localhost/Order.wsdl to generate client stub classes.
The live web service is on a different host, so I need to supply a url when I make the service call. My approach so far has been like this (classes below are generated from wsimport):
1. OrderService s = new OrderService (
new URL("https://live/WS/Order"),
new QName(...));
2. OrderServicePort port = s.getOrderServicePort();
3. configureHttpCertificatesStuff(port) // Set up ssl stuff with the port
4. port.placeOrder(args); // The actual ws call
First: Is this the correct way of specifying the url?
Second: It seems the constructor in line 1 actually makes a network call to the new URL! This results in an exception (due to https not being configured), so I never get to the next line.
Background: I am implementing two-way ssl auth as outlined in this question. This means I need to configure ssl stuff in the port before the service call. I can't have the constructor make any connection before I've configured the ssl layer correctly for obvious reasons...
Update:
Apparenty the url is to the WSDL, not the endpoint when using jax-ws standard. This tripped me up. Loading the WSDL directly from file solved that problem.
Setting the endpoint url is done like this:
BindingProvider b = (BindingProvider) port;
b.getRequestContext().put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, endpointUrl);

One solution would be to have your build process arrange for the WSDL file processed by wsimport to become a class path resource for your app. There are any number of ways to do this, but lets assume you take a JAR-per-service approach. So, you'd run Order.wsdl through wsimport and take the resulting classes, like OrderService and OrderServicePort, and stuff them into order-service.jar. The other thing you could do would be to stuff a copy of Order.wsdl into that same JAR at META-INF/wsdl/Order.wsdl. Assuming that JAR file is then part of the class path for your app, you can get the WSDL's URL by doing:
URL wsdlLocation = Thread.currentThread().getContextClassLoader().getResource("META-INF/wsdl/Order.wsdl");

SOAP web service calls from Javascript

I'm struggling to successfully make a web service call to a SOAP web service from a web page. The web service is a Java web service that uses JAX-WS.
Here is the web method that I'm trying to call:
#WebMethod
public String sayHi(#WebParam(name="name") String name)
{
System.out.println("Hello "+name+"!");
return "Hello "+name+"!";
}
I've tried doing the web service call using the JQuery library jqSOAPClient (http://plugins.jquery.com/project/jqSOAPClient).
Here is the code that I've used:
var processResponse = function(respObj)
{
alert("Response received: "+respObj);
};
SOAPClient.Proxy = url;
var body = new SOAPObject("sayHi");
body.ns = ns;
body.appendChild(new SOAPObject("name").val("Bernhard"));
var sr = new SOAPRequest(ns+"sayHi",body);
SOAPClient.SendRequest(sr,processResponse);
No response seems to be coming back. When in jqSOAPClient.js I log the xData.responseXML data member I get 'undefined'. In the web service I see the warning
24 Mar 2011 10:49:51 AM com.sun.xml.ws.transport.http.server.WSHttpHandler handleExchange
WARNING: Cannot handle HTTP method: OPTIONS
I've also tried using a javascript library, soapclient.js (http://www.codeproject.com/kb/Ajax/JavaScriptSOAPClient.aspx). The client side code that I use here is
var processResponse = function(respObj)
{
alert("Response received: "+respObj);
};
var paramaters = new SOAPClientParameters();
paramaters.add("name","Bernhard");
SOAPClient.invoke(url,"sayHi",paramaters,true,processResponse);
I've bypassed the part in soapclient.js that fetches the WSDL, since it doesn't work
(I get an: IOException: An established connection was aborted by the software in your host machine on the web service side). The WSDL is only retrieved for the appropriate name space to use, so I've just replaced the variable ns with the actual name space.
I get exactly the same warning on the web service as before (cannot handle HTTP method: OPTIONS) and in the browser's error console I get the error "document is null". When I log the value of req.responseXML in soapclient.js I see that it is null.
Could anyone advise on what might be going wrong and what I should do to get this to work?

I found out what was going on here. It is the same scenario as in this thread: jQuery $.ajax(), $.post sending "OPTIONS" as REQUEST_METHOD in Firefox.
Basically I'm using Firefox and when one is doing a cross domain call (domain of the address of the web service is not the same as the domain of the web page) from Firefox using AJAX, Firefox first sends an OPTIONS HTTP-message (before it transmits the POST message), to determine from the web service if the call should be allowed or not. The web service must then respond to this OPTIONS message to tell if it allows the request to come through.
Now, the warning from JAX-WS ("Cannot handle HTTP method: OPTIONS") suggests that it won't handle any OPTIONS HTTP-messages. That's ok - the web service will eventually run on Glassfish.
The question now is how I can configure Glassfish to respond to the OPTIONS message.
In the thread referenced above Juha says that he uses the following code in Django:
def send_data(request):
if request.method == "OPTIONS":
response = HttpResponse()
response['Access-Control-Allow-Origin'] = '*'
response['Access-Control-Allow-Methods'] = 'POST, GET, OPTIONS'
response['Access-Control-Max-Age'] = 1000
response['Access-Control-Allow-Headers'] = '*'
return response
if request.method == "POST":
# ...
Access-Control-Allow-Origin gives a pattern which indicates which origins (recipient addresses) will be accepted (mine might be a bit more strict than simply allowing any origin) and Access-Control-Max-Age tells after how many seconds the client will have to request permission again.
How do I do this in Glassfish?

Have you actually tested that ws is working properly?
You can use SoapUI for inspecting request/response etc.
When you confirm that ws is working from SoapUI, inspect what is format of raw Soap message. Then try to inspect how it looks before sending with .js method, and compare them.
It might help you understand what is wrong.

Check if this helps
http://bugs.jquery.com/attachment/ticket/6029/jquery-disable-firefox3-cross-domain-magic.patch
it's marked as invalid
http://bugs.jquery.com/ticket/6029
but it might give you some hint
On the other hand, instead to override proper settings for cross-domain scripting might be better if you can create and call local page that will do request to ws and return result.
Or even better, you can create page that will receive url as param and do request to that url and just return result. That way it will be more generic and reusable.