I am trying to use Apache CXF with JAX-RS to serve as an embedded REST endpoint within a larger application. I cannot use spring configured CXF because my application needs to manage the lifecycle of the Jetty instance and servlets.
The example here shows how to do this with a service class name, but in my application it will be roundabout and ugly to pass a classname rather than a bean. Can anyone point me toward a way to use a bean here?
You have to leave CXFNonSpringJaxrsServlet create your instance, but you can configure it (=bind it to outside world) by extending CXFNonSpringJaxrsServlet#configureSingleton
See this post: CXF/Jetty equivalent of the following Jersey/Jetty code for a solution. Tested with CXF 3.0.3 and Jety 9.2.5.v20141112.
This is how it's done
Object serviceObject = // your JAX-RS service object
JAXRSServerFactoryBean rs = new JAXRSServerFactoryBean();
rs.setServiceBeanObjects(serviceObject);
Server server = rs.create();
Related
While developing a web application I have the following use case:
a 3rd party Web Service with quite a lot of methods is deployed on a test server A (with a single endpoint, e.g. http://3rdPartyServer/3rdPartySvc?WSDL)
a new method is about to be implemented in the near future, but I need to use it now
the rest of the methods are used throughout my code extensively
So I would like to do the following:
Create a mock service in SoapUI locally, based on the new WSDL which includes the new WS method (i.e. a superset of the WS methods currently on server A)
point my local application server to use the SoapUI mock service endpoint
mock only the response of the new WS method (create a dummy response for it in SoapUI)
let the other WS method calls to reach server A and return whatever it returns normally (i.e. use SoapUI as a proxy for these calls)
I've gone through the SoapUI documentation regarding service mocking and have used it numerous times, but could not find an option for such "pass-through" behavior.
When you read in your WSDL, the endpoint will point to your server.
Open your service, and select the service endpoint.
Add a second endpoint, to point to your mock. SoapUI has little bit of documentation showing this here. Only step "2. Getting Started" applies, not step 3!
In each of your tests, where you are using the mocked method, you will need to select the mock endpoint. Further discussion is here.
How to consume Web service suing Apache CXF client API.
I have generated the client Code using eclispe but I didn't found any document specifying how to use that generated code in my web application.
How to configure CXF? I am using tomcat to run my java web appliation.
How to use the generated code?
Do I need to add anyhting in my my web.xml?
I have downloaded CXF binaries from apache CXF website but don't know which libraries are needed. I am affraid i may end up adding all the jars.
I am using Tomcat 7, Java 1.6 and plane jsp/Servlet for my application
I am new to web services.
Thanks in advance
One sample code that may help.
URL wsdlurl=SOAPWebServiceTransport.class.getClassLoader().
getResource("my.wsdl");
// MyService will be one of the service class that you have generated (with different name ofcourse)and which must be extending Service class
//getOnlineServicePort will be a method (with different name ofcourse) in your service class which will give you the interface referrer using which you'll call the webservice method
OnlinePort service= new MyService(wsdlurl).getOnlineServicePort();
Client proxy = ClientProxy.getClient(service);
//configure security user name password as required
//Add interceptors if needed
//Now you can directly call the webservice methods using the service object
service.method(parameter)
you can also refer to some example one is here
I was wondering how the Dropwizard client module should be implemented.
Source of confusion:
Dropwizard recommends you to separate your project as such:
In general, we recommend you separate your projects into three Maven
modules: project-api, project-client, and project-service.
On the Client section, it shows that you can instantiate the httpClient provided by dropWizard within a run method.
#Override
public void run(ExampleConfiguration config,
Environment environment) {
final Client client = new JerseyClientBuilder().using(config.getJerseyClientConfiguration())
.using(environment)
.build();
environment.addResource(new ExternalServiceResource(client));
}
I thought that the client module would wrap the httpClient, and any other service can use the client module, without caring which httpClient it is using.
So
how would a client module look like
When would you instantiate an httpClient directly within a service's run method (as done in the snippet of code above)
Thanks!
How would a client module look like
This is heavily dependant on your project scope and structure. For example, in one of my projects which is heavily database dependant, the Client module (or Service class in DropWizard's terminology) contains my DAO instantiations as well as hibernate initializations and a bunch of other init stuff (SQS, etc). I also use the HTTP Client and the Service class is where I initialize it. Reason being is that the Service class is the entry point and this is where you end up instantiating your Resource classes, etc. So having the dependancies instantiated here allow me to pass them into my resources as constructor params. If you were using something like Guice, then the way to go would be different since you have access to injection, etc.
When would you instantiate an httpClient directly within a service's run method (as done in the snippet of code above)
The HttpClient shown in the doc and your question is used when your project requires a Http Client. For example, lets say your DW project or one of the resources you are writing requires you to make a HTTP call to a twitter API. This is where the Http Client comes into play. You can actually use any Http Client library you want, however using the ones provided by DW (Apache Http Client, Jersey Http Client) allows you to create a 'Managed' Http Client there by allowing DW to start up, shut down and clean up the HTTP Client when the service is shutdown. So things like thread pools, connection pools, etc are all cleaned up by DW when you use its managed HTTP Client. In addition, the reason why you create this HTTP Client inside the run method is because you are then able to get a reference to the Configuration object's instance which will allow you to control the HTTP Client's settings via DW's configuration system.
Hope this answers your questions
I need to create a client with WSDL. I have a Java web application with JSF, Spring and JPA. In this application I need to create a form and send the info to the SOAP web service. This service should return another object with status.
Please, any idea I will be grateful
regards
sorry by my english
I assume you have generated classes from the WSDL needed for you client. In Spring it is very simple by using Apache CXF. For e.g.:
<jaxws:client id="yourService"
serviceClass="com.something.YourService"
address="the URL of web service"
username="username"
password="password"/>
And in your class where you need to call this web service just autowire it:
#Autowired
#Qualifier("yourService")
private YourService service;
Take a look at the example: http://cxf.apache.org/docs/writing-a-service-with-spring.html
I have two servlets that access two corresponding Axis2 web services on the same host. One of the servlets is read-only, while the other writes to a database.
Each of the Axis2 web services uses BASIC authentication. The read-only web service uses a system account, while the write web service uses the user's credentials (which are submitted as part of a web form).
The problem I'm running into is that the servlet called second always fails authentication to its web service. For example, I can query the read-only service through it's servlet all I want, but I get a "401: Authorization Required" when I try to use the write service. If I call the write service first, I get the same error when I try to use the read-only service.
Here is how I am setting the credentials for the connections in the servlets:
Stub service = new Stub(serviceUrl);
HttpTransportProperties.Authenticator auth = new HttpTransportProperties.Authenticator();
auth.setUsername(username);
auth.setPassword(password);
auth.setPreemptiveAuthentication(true);
service._getServiceClient().getOptions().setProperty(HTTPConstants.AUTHENTICATE, auth);
The servlet that accesses the read-only service has this code in it's constructor. The servlet that accesses the write service has this code in it's doGet/doPost method.
It seems that the credentials for the first service called are getting cached somewhere, but I can't find where that could be. I saw a possible solution here, but I can't find where WSClientConstants.CACHED_HTTP_STATE is defined. The comments in this JIRA issue seems to imply that it's part of org.apache.axis2.transport.http.HTTPConstants but it's not there.
Specifics:
Axis version: 1.5.1
Tomcat Version: 6.0.26
Java version: 1.6.0_23
It turns out the connections to the two different services were using the same JSESSIONID. Thus, the connection to the second web service was trying to use a session authenticated for the first web service, causing the error.
My solution for this was to define an HttpClient for each service, done by the following
MultiThreadedHttpConnectionManager manager = new MuliThreadedHttpConnectionManager();
HttpClient client = new HttpClient(manager);
ConfigurationContext context = ConfigurationContextFactory.createDefaultConfigurationContext();
context.setProperty(HTTPConstants.CACHED_HTTP_CLIENT, client);
context.setProperty(HTTPConstants.REUSE_HTTP_CLIENT, true);
Stub service = new Stub(context, serviceUrl);
This allows both servlets to have a separate session for their corresponding services.
The important point is to create a dedicated ConfigurationContext.
I've solved in a simpler way using a default config context when creating the stub without the multithreaded connection factory
stub = new MyStub(ConfigurationContextFactory.createDefaultConfigurationContext(), myServicesUrl);