I am developing a SOAP client with CXF.
I have the code generated by wsdl2java.
I have done a JAR executable to test.
When I try to make a request, I do this first:
Service ss = Service.create(wsdlURL, SERVICE_NAME);
MiNTService port = ss.getPort(MiNTServiceSOAP, MiNTService.class);
wsdl is the URL to the web service.
SERVICE_NAME is a QName of the service.
MiNTService is the class generated from wsdl2java code.
MiNTServiceSOAP is a QName of the endpoint
MintSErvice.class is the name of the class generated by wsld2java
The service.create expends 10 minutes
The gerPort() expends 10 minutes too.
And after all that time... the request is done.
I have try put all wsdl locally, but the same result.
What could be happening????.
The system has:
4GB RAM
5GB free space disk.
CPU 2.5 GHz
Ping to the server is normal...
The connection is over https
With Axis2 there is no problem of time request, but we cant use axis2 because has a lot of problems with signed request... and we are trying CXF.
Thanks to all
Solution:
The problem was the way to export a "runnable jar file" from Eclipse.
If you package the libraies into the jar... it becomes slow.
The solution is select the option of "Copy required libraries into a sub-folder next to the generated jar" in the export process.
Tremendo el asunto.....
Bye
I am also having the same problem of direct calling below Service constructor when the provided web service is down. Service.create(wsdlURL, SERVICE_NAME) also internally calls below constructor.
In my case, When the web service is online everything works fine.
What I expect is a quick response from the Service initialization if it is not possible to initialize without hanging long time.
Can we set a timeout to this call?
Are there any specific way of doing this?
Or is this a known problem of CXF?
here is the Service Constructor I am using:
protected Service(java.net.URL wsdlDocumentLocation, QName serviceName) {
delegate = Provider.provider().createServiceDelegate(wsdlDocumentLocation,
serviceName,
this.getClass());
}
Related
I have a web application running on Wildfly 26 that uses SSE broadcasting and works correctly with http. However, when I switch to using an https endpoint, I get Wildfly log entries of:
WARN [org.jboss.resteasy.resteasy_jaxrs.i18n] (default task-1)
RESTEASY002186: Failed to set servlet request into asynchronous mode,
server sent events may not work
This happens with each registration attempt of the https endpoint but I never see this when registering with the http endpoint.
Testing with curl against the http endpoint results in curl waiting for events to show up (and keeps printing them out as it receives them) until I quit. Using curl to test the https endpoint, I will see the same headers I got from the http endpoint, namely:
HTTP/1.1 200 OK
Connection: keep-alive
Transfer-Encoding: chunked
Content-Type: text/event-stream
But after printing out my registration successful event, curl seems to believe the stream is closed and exits -- giving me my command prompt back.
My #GET MediaType.SERVER_SENT_EVENTS registration endpoint will create an OutboundSseEvent and send it to the SseEventSink to acknowledge successful registration to my SseBroadcaster instance (this is the event curl sees and prints before exiting). I then log a registration successful message before exiting the method. All of this appears to work correctly for both http and https but the stream doesn't stay open once the request endpoint completes because of the failure to run asynchronously as outlined above.
I have not found information on the causes and/or workaround solutions for my RESTEASY002186 problem. I posted a question on this issue last week using the Wildfly Google Group (https://groups.google.com/g/wildfly/c/SO2eHdvMEko) but thought I would try a wider audience since this doesn't seem to be a commonly experienced condition. I don't see any indications during initialization that WildFly will be unable to use asynchronous mode, it just complains when it tries and fails... Any help would be greatly appreciated!
Edit 6/6/2022
The code is running on an isolated network so I can't just cut/paste the code here, but I gutted the resources file to a bare minimum -- just leaving enough for the client to be able to register. The problem remains unchanged. The code is now essentially:
#Path("sse")
public class SseResources {
#GET
#Produces(MediaType.SERVER_SENT_EVENTS)
public void listen(#Context Sse sse, #Context SseEventSink sseEventSink) {
SseRegComplete regComplete = new SseRegComplete("sse-server");
OutboundSseEvent event = sse.newEventBuilder().
name(regComplete.getType().toString()).
id(regComplete.getEventId()).
mediaType(MediaType.APPLICATION_JSON_TYPE).
data(SseRegComplete.class, regComplete).
comment("Event Stream Registration Completed Successfully").
build();
sseEventSink.send(event);
}
}
Before the above simplified code, I had declared the resource as #ApplicationScoped, had Sse injected into it, and kept a reference to the SseBroadcaster so I could use it whenever an event would come in. I was catching the events to broadcast by using an #Observes method (which I also got rid of). I was calling register(sseEventSink) on the SseBroadcaster in the listen method so I could later call broadcast(outboundEvent) whenever I had updates to publish. I got rid of all that just to see if I could get the stream to stay open but to no avail. I still get the RESTEASY002186 message and curl still exits after printing out the regComplete event sent to it in the code above.
Edit 6/7/2022
Yesterday I was able to get my code working in a new vanilla Wildfly 26 install using an https endpoint URL by following these configuration instructions. Something I hadn't mentioned in the original post is that I am trying to add SSE functionality to an already existing app. It is several years old and we actually moved to Wildfly 26 about 6 months ago because of the log4j vulnerability in the earlier version of Wildfly we were using. I suspect that the problem is related to either our Wildfly configuration (perhaps because old settings were brought over that shouldn't have been) or some 3rd party dependency that is preventing Wildfly from using asynchronous mode.
We are using Shiro for authentication and authorization against an LDAP server -- perhaps Shiro has some hooks into the Wildfly runtime that are causing issues? After initial login, we use a session cookie in all subsequent calls. That is a difference from my test server but I don't think it is relevant because the call definitely passed authentication before executing the registration code. The only other thing that comes to mind right now is our web app ships with LogBack and tells Wildfly not to use the default logging framework.
I plan to start today by comparing the two standalone.xml files to see if anything jumps out at me as being fundamentally different. Is there anything else I should be checking for differences (I think there is a domain.xml file somewhere...)?
Edit 6/14/2022
This definitely has something to do with Shiro being in the loop. When I edit the web.xml file to have Shiro's filter-mapping url-pattern to not include the SSE endpoint, everything works as expected.
I put de url and try load, but happen this error.
I'm sure that it's work, because I can call this url in SOAPUI...
What you report are two different things:
In your first screenshot, there is an error message that your program cannot load the WSDL document, because one of the referenced XML Schema is not accessible.
In SoapUI you demonstrate that the target service is alive.
Please note that SoapUI is very tolerant when parsing the WSDL. Your WSDL might have errors, but when you import the WSDL into SoapUI, SoapUI skips and ignores the errors. You can consume the target service then.
You need to check your WSDL and all referenced XML Schemas and to make sure they are accessible (it can be a network issue or other cause).
I have to implement a simple client to a XDS.b server (SubmitObjectRequest and RetrieveDocumentSetRequest operations), but I'm struggling to get even a simple example of use to work.
I've tried using Mirth Connect's Channel for XDS.b also, but with no use. I even tried to copy its SOAP envelope to use with SoapUI. Didn't work.
I'm using HIEOS deployed on Glassfish as my XDS.b server.
I'm lost and confused. Could anyone give me a guidance on how to make this work?
If the HIEOS is deployed correctly within the Glassfish the service endpoint provides a wsdl definition where the interface is specified. Check the Glassfish for the wsdl of the service.
http://localhost:8080/my-ws/simple?WSDL
Quelle: docs.oracle.com/cd/E18930_01/html/821-2418/gbiyw.html
The list of provided endpoints you can see here:
https://kenai.com/projects/hieos/pages/WebServices
So to retrieve the wsdl you should use for example:
http://localhost:8080/axis2/services/xdsrepositoryb?wsdl
which applies for the ProvideAndRegisterDocumentSet-b transaction of the XDS Repository actor.
You can use the WSDL definition to create a WS request using SOAP UI at first.
SOAP UI creates a request based upon the wsdl definition which can be used to
test a against your XDS repo.
When you know how a SOAP request must be constructed you can try it using Mirth or
create your own client using Apache CXF http://cxf.apache.org/ for example.
Or you use AXIS2 to create a client from the WSDL. Of course does Visual Studio and C# also offer mechanisms to create a WS client directly from a WSDL definition.
I have been going through the google tutorial ( which I find very good ) at
https://developers.google.com/web-toolkit/doc/latest/tutorial/RPC
I have the service up and running on my local server and my JavaScript client can call it fine. OK so far. Now, what I want to do is deploy the service on a remote server JoeSoapHost:8080
How do I now tell my client where to send it's requests? I can't see any server/url being created in my RPC call. It just works by magic but now I want to get under the bonnet and start breaking it.
[Edit}
This is the Interface my client uses to know what service on the Server is to be called. I know that my Web.xml web descriptor must have a url that matches this. It has this because my server is invoked ok. Problem is, if I now decide to deploy my server elsewhere how do I tell my client what server/domain name to use?
#RemoteServiceRelativePath("stockPrices")
public interface StockPriceService extends RemoteService
{
StockPrice[] getPrices(String[] symbols);
}
What I want to achieve first is have a simple GWT client calling into an RPC service. I have this working but only when the server is localhost.
Next step, I deploy my app to the Google App Engine. What must I change now because my RPC service in my JavaScript is not being called when I deploy my app to
http://stockwatcherjf.appspot.com/StockWatcher.html
1) Brian Slesinsky excellent document on RPC - https://docs.google.com/document/d/1eG0YocsYYbNAtivkLtcaiEE5IOF5u4LUol8-LL0TIKU/edit#heading=h.amx1ddpv5q4m
2) #RemoteServiceRelativePath("stockPrices") allows GWT code to determine relative to your host/server/domain i.e http//mydomain.com/gwtapp/stockPrices
3) You can search GOOGle IO Sessions from 2009 - 2012 for some more in depth stuff on GWT RPC usage.
#RemoteServiceRelativePath gives the path of the servlet relative to the GWT.getModuleBaseURL() (which is more or less the URL of the *.nocache.js script); it doesn't "just work by magic".
If you deploy your services on a different server than the one serving your client code, then you'll likely hit the Same Origin Policy. CORS can help here, but you'll lose compatibility with IE (up to IE9 included). You'd better stick serving everything from the same origin.
I'm writing, or trying to write, Baby's First MDB on WebSphere 7. I have nearly no hair left, having pulled it all out trying to get the thing to work. It appears that I've got everything set up right, but I get no response when I put a message to the associated queue.
Here's the EAR file setup:
simplemdb.ear
META-INF
Manifest.mf
application.xml
simplemdb.jar
META-INF
Manifest.mf
ejb-jar.xml
com
[ classes go here ]
I can't find any syntax for defining the queue's JNDI name in ejb-jar.xml, so instead I:
Define a WebSphere activation spec. Name SimpleMDBActivationSpec, JNDI name jms/SimpleActivationSpec, Destination jms/SimpleMDBQueue.
Define a WebSphere queue. Name SimpleMDBQueue, JNDI name jms/SimpleMDBQueue, Queue name SIMPLE.MDB.QUEUE.
Define an MQ queue, name SIMPLE.MDB.QUEUE.
Deploy the EAR file. During the deployment, I'm asked to enter binding information. I select Activation Specification, then point the Target Resource JNDI Name and Destination JNDI name at the activation spec and queue, respectively.
(The MDB code has no annotations.) At this point, the app points to the spec and queue, and the spec points to the queue - belt and suspenders. Naturally, I imagine that the app therefore knows about the queue. Full of hope, I put a message on the queue, and ... nothing. The onMessage event is supposed to use System.out to log a message. I see no message.
Clear documentation on this is conspicuous by its absence. Google gives LOTS of results, but none of them details how the configuration all fits together. There's lots of hand-waving about ibm-ejb-jar-bnd.xmi, but examples of the file are arcane, full of opaque numbers with no explanation about how they were generated, or how they relate to other parts of the configuration.
For goodness' sake. All I want to do is deploy an MDB, and have it write "Hello, world" when I put a message to a queue. I'm using vi and ant as my development and build tools. Can anybody out there give me an idea about what I'm missing?
Edit: "zos" tag added.
I found the problem. It's specific to WebSphere running on z/OS. For an activation spec to be fully available in that environment, the Control Region Adjunct (CRA) process must be started. I told WAS to start it up, recycled the app server, and lo! My MDB started responding.
To make the CRA start via the WebSphere Admin Console, go to ...
Application servers > [server name] > Communications > Messaging > WebSphere MQ CRA Settings
... and check the box that says "Start CRA". Hit OK, save it to the master configuration, and to make the CRA actually start, bring the app server down and back up. (This is for WAS 7.0.)
Thanks to everyone for their time and thoughtspace.
have a quick look at this and see if there is anything here that helps you.
http://publib.boulder.ibm.com/infocenter/ieduasst/v1r1m0/topic/com.ibm.iea.wasfpejb/wasfpejb/6.1/DevelopmentTools/WASv61_EJB3FP_MDBLab.pdf
I haven't played with this for the last one year so i am not able to comment straight away but i thought the PDF might be of some assistance to you.
HTH
Manglu