I have a scenario that Jersey 2.13 (with HK2 as DI) is loaded up in Tomcat and on the same JVM (I start it up from a startup servlet) a netty-socket-io server is running. I want this second server's methods to have access to the injected classes that the rest of my web app is using and I wouldn't like to introduce another dependency injection framework just for that.
I read that you can get a ServiceLocatorProvider in Jersey for doing this here but you need to have a context provided while my methods are completely separated.
Related
I would like to know is there any api/tool which automatically deploys ear/war/war-inside-ear and then injects mocks in the facade layer to make it suitable for testing.
I heard that rest assured api is one such api. But I did not come across tutorials or example which explains how to write code to deploy the ear/war/war-inside-ear in a default web server(netty/jetty) and test the web services.
Till now we are deploying our ear in jboss(without any mock data) and testing the web services using aur own custom apis.
P.S.
I have an ear which contains a war module. All my web service classes are in it. To test the request and response of the web services, I am deploying the actual web services and other ejbs in a jboss instance which requires lot of effort and setup. And then I am testing the requests and responses of all web services.
I am looking for a tool which deploys the ear and inject mocks in the web service classes instead of initializing all the ejbs inside the ear. This will reduce my effort for the setup I have to do to get the ejbs run.
Java EE 6 provides a way to activate JAX-RS Application on startup.
The problem is I am (and certainly many of us are still) using web server not compliant to Java EE/Servlet 3.0 so that if we tried to use load-on-startup servlet mapping on a JAX-RS Application, the web server (at least that is the case for jetty) would croak
"class is not a servlet"
and hence refuse to load the Application.
The gist of the matter is - to load the contextresolver, the only way which can be done only is through the jax-rs Application subclass.
The method to activate Application subclass should work similarly both on Jetty and Tomcat/JBoss because I am using jetty for development (due to GWT - what else?) and Tomcat/JBoss for production. I wish to avoid writing different loaders for jetty and tomcat.
There are exist already implemented start up servlets and context listeners in jax-rs providers like cxf or resteasy, just read docs carefully
I have a client server application. The server is made of restful services with jersey and is deployed on tomcat 7. Actually, I need to create the context of the services (read some high sized files) before the client access to the services. Is it possible to create a main class of my webapp or not?
A web application in JavaEE doesn't have a "main class" in the same sense that a desktop application does; surely, the execution must start on a main method somewhere, but it'll be managed by the web container (Tomcat in your case) and outside of your reach.
What you can do instead, is create a servlet which preloads the data you need in the application context using its init method (assuming that the data will be the same for all the clients, and ideally, it won't be modified by them). Also, in the servlet configuration, you specify that the servlet must be loaded on startup, and in that way you make sure that the data will be loaded once at the beginning of the application, and that all the clients will be able to access it from the application context.
EDIT :
In more recent versions of the Servlet specification (2.3+) the preferred way is to use context listeners, see this answer for details.
I'm wondering if it is possible to create XML-RPC server component within EJB module without servlets. I know EJB typically uses RMI as communication protocol but what if I want to omit RMI. What if i want to exchange data between EJB and web module (WAR) or other clients by different way like XML-RPC.
Can EJB-module work as stand-alone unit which will expose its state and services as XML-RPC server?
I still can do EJB module connected with WAR via RMI while this WAR will expose those services via servlet. Then other WARs or whatever-they-are clients can call this first WAR. Is this right or there is some other possibility?
What you probably want is to use Spring Remoting to expose your EJBs via for instance JAX-WS. Spring will create automatically servlets for handling the requests for you. The bad news is that you have to call your EJBs from the remoting services you build - meaning some boilerplate code. It should be quite straight forward though.
An other possibility you might take a look at is Restlet which can be used to build restful services.
In EJB3, your service beans are just annotated POJOs. You can simply annotate the same POJOs with #WebService (and the rest of this family of annotations) to expose the same services as web services.
I realize this isn't strictly what you asked for as the implementation for services exposed in this way is JAX-WS which uses SOAP messages. But I think it achieves your intent.
I have set up a CXF web service which works well. My service primarily loads data from an ftp to a db.
I would like to create a web interface through which the invoker can view the progress of their package. I thought it would be easy to integrate Spring MVC with CXF but there doesn't seem to be any good solution. I searched all over the net and could not find any thing simpler than this http://ayax79.wordpress.com/2009/02/19/making-spring-mvc-and-cxf-play-well-together/
The reason I would like to integrate Spring MVC with CXF and not create a stand alone web interface is because I have some custom Spring beans with in the CXF service which I can make use off to start and stop the process.
Is it that difficult to build an interface on CXF? Or am I just not thinking in the right direction?
The article you linked to has more to do with handling 1) web requests and 2) CXF requests within the same webapp, i.e. building a web application which can accept traditional http requests for MVC pages and also accept web service requests.
The author of that article seems to be pretty confused about Spring and how ApplicationContexts work, as the commenter Felix provides a good and simple solution for what the original author wants to accomplish (reuse the same bean definitions and instances within two contexts, having some URLs mapped to DispatcherServlet and other URLs mapped to a CXF dispatcher).
If you simply want your Spring MVC web application to be able to interact with and make requests to a CXF service, this is simple - you write code to consume the services as you would in any other type of application that interacted with a CXF/Soap/etc web service.
I'd recommend taking a look at the following sections in the Spring manual about access JAXRPC or JAXWS web services:
Accessing web services using JAX-RPC
Accessing web services using JAX-WS
Another option that you have is to simply generate client proxies for your CXF service using a tool like wsdl2java. Note that the next two options on this page I linked to, "JAX-WS Proxy" and "JAX-WS Dipatch APIs" do the same thing functionally as the Spring option above (creating a dynamic proxy at runtime).