As of my understanding java EE application servers have mainly two types of containers. Namely web container and EJB container.
I managed to run a JAX-RS application which used Jersey as its implementation, in Tomcat. As I know Tomcat is only a web container. In order to run the web service in tomcat, the jersey jars had to be bundled into the war file because out of the box, Tomcat did not have the jersey jars. This raised me a question.
Does tomcat uses another implementation of JAX-RS other than Jersey? If Yes what is it?
if No,
I could not run the Jax-RS application without the jars bundled into the war file, this means JAX-RS apps need something more than what the web containers offer. It means they do not run in a web container. then in which container does it run?
"Does tomcat uses another implementation of JAX-RS other than Jersey?"
I don't know if you're asking if Tomcat has an implementation or if it is capable of running other implementations beside Jersey.
The answer to the former is no. Vanilla Tomcat does not support JAX-RS out the box. It is not an EE server, but simply a Servlet container. But TomEE+ (built on Tomcat) has support (using CXF).
The answer to the latter is yes. You just need to add that implementations jars and configure the app properly
"I could not run the Jax-RS application without the jars bundled into the war file"
Yup, you can't. For the simple fact there is no implementation to support the JAX-RS runtime.
"It means they do not run in a web container. then in which container does it run?"
It does run in the Servlet container. JAX-RS is actually built on top of Servlets. For Jersey, it uses the ServletContainer. Tomcat will ship off requests to the Jersey Servlet, and Jersey will process the request through configured provider and resources and spit out the response back to the container. The container will send the response to the client. (See first link below)
If you are looking for a Java EE application server, that supports the whole EE spec, you can look at Glassfish (it uses Jersey as it's implementation), JBoss/Wildfly (it uses Resteasy), TomEE+ mentioned above (uses CXF)
Here are some related reads you might find interesting:
Confusion with JAX-RS and Jersey with JAX-RS
JAX-RS specification - 2.3 Publication
Java-ee REST server with IntelliJ and Tomcat
How to use Jersey as JAX-RS implementation without web.xml?
Related
Can I deploy a Spring java application on all (or at least most) of JavaEE servers ? like Weblogic, JBoss, Webshpere, Tomcat, Jettty etc.
And is there is preferred Java EE server for Spring ?
Yes you can. And no - there isn´t. Errata: you can take a look at the SpringSource dm Server. Be aware that spring is not a java EE implementation. Read this post here.
Yes, you can deploy it on any server, and you can use it on standalone applications and even on mobile applications. It is in no way restricted to web deployment. It is not even restricted to java, there is Spring.NET and even a Python version. However, java and web servers are a common if not the most common use for it.
Currently recommended web server by VMWare/Pivotal (current owner of Spring) is VFabric tcServer, which is a Tomcat fork containing some extra tools and functionality. But server in itself does not matter, Spring is container agnostic.
There is no preferred EE server. VFabric tcServer is a servlet container, not an EE server. It contains "enterprise capabilities" instead, but that's not the same thing. As said however, you can use whichever EE server you want.
I am trying to call a web service from java. I am using JBoss as the client application server. The Web server is written in jax-ws and is running in some other server (which i dont know).
My requirement is to call the web service from my application running in JBoss. After doing enough search, I found that, jax-ws is a Standard and now included in jdk. Metro is a reference implementation of jax-ws and is provided in the Glassfish App server.
My Question is: -
Is there any other jax-ws implementation present in the market?
Just like each container provides its own implementation of Servlet API, do all of them provide implementation of Jax-ws?
Do I need to copy the Metro api to my Jboss application?
Where does JBossWS comes into play here?
A sample code provided by the Web Service host specifies that, the client needs to have to add a authentication token to the SOAPHeader, and in the sample code they have used com.sun.xml.ws package.
When I used MessageFactory to create a new SOAPMessage, will it use the Metro RI or JbossWS?
If Metro is glassfish's implementation of Jax-ws, then will it run in other app servers?
Added to that, my application exposes another Web service also (although it uses Axis 1).
I am getting a bit confused regarding this.
Can someone help me with some details regarding jax-ws, Metro, JbossWS. And where do each of them stand.
JBossWS is the Web-Service stack provided by the JBoss Application Server, and yes, it is also an implementation of the JAX-WS standard. As far as I know, JBossWS is based on Apache CXF.
Glassfish uses another implemetation of JAX-WS, Metro.
In order to communicate with a remote WebService (the implementation is not important, as long as it uses standards), you can simply use JAX-WS api and any Application Server which provides an implementation for it. JBoss does, so you have just to write your client following the JAX-WS api (and it should run on both JBoss and Glassfish or any other JAX-WS compliant container).
About the authentication, you should provide some more information, since there are a lot of options in the standards here.
If I use Glassfish and only need jersey for jax-rs and grizzly for servlet/jsp, will glassfish load all other Java EE components I don't need and take more up more resources than just running jersey/tomcat or will glassfish just load jersey/grizzly and will use almost the same resources? I have tried running starting default glassfish and default tomcat, glassfish takes much more ram.
Is there any reason not to run jersey with tomcat? maybe because the integration is done better by Glassfish?
There are lots of people who use Jersey with Tomcat. Tomcat is a servlet container only but will not interfere with other Java EE technologies that you choose to support through other means (e.g. Jersey). You may have to manage some of the initialization of the frameworks, etc. that other full-J2EE containers like Glassfish already provide, but it shouldn't be too painful.
You can use the 'web profile' to help minimize the download, initial memory and start-up time.
The most recent web profile is http://dlc.sun.com.edgesuite.net/glassfish/3.1.2.2/release/glassfish-3.1.2.2-web.zip
The start-up time is between Tomcat and the GlassFish 'full' profile.
The web profile includes an integrated implementation of Jersey.
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 am not much aware about the details as to which web servers support Web services written in Java.
Would Like to know the following three things:
1) What is required to have support for Web Services : Only Servlet Container or An Application Server + Web container?
2) Would like to know that do all Web Server supporting web development in Java support Web Services?
3) How to identify whether a particular server supports Web Services or not?
Thanking you in advance.
Your question is somewhat unclear. The term web service is applied to anything from a REST style API to SOAP based services to JSON based, etc etc. Wikipedia says an equivalent is a Web API, and an API can be pretty much anything.
So to answer your question. A servlet container is enough to support most common types of web services, it doesn't require an application server. Take a look at Apache CXF, which is a framework catering for a lot of web services styles (notably SOAP and REST).
Apache CXF is a rather large framework, and can take some time to get your head around. If you need something simpler, you may be better off looking at some object serialization frameworks and implement the servlets yourself (this is what I do mostly). To serialize to XML, use out-of-the box Java JAXB annotations. To serialize to JSON, use Jackson.
Assuming you're talking about SOAP WS-* web services via JAX-WS.
Java EE 5+ stipulates support for JAX-WS compatible web services within the container, both at the Web App level, and at the EJB level. So, any full boat, modern, App Server will have JAX-WS support built in.
Servlet 2.x and 3.0 do not have a requirement to support JAX-WS at the container level, but all of the major implementation of JAX-WS can be deployed within a WAR in a modern Servlet container (like Tomcat).
Java EE 6 offers a Web Profile, but the Web Profile does not include JAX-WS. Java EE 6 Full Profile includes both JAX-WS (SOAP, WS-* web services), and JAX-RS (for HTTP and more RESTful web services).
So.
If you bundle your own implementation, all of the containers should accommodate you. If you want it built it to the container, you'll need a full Java EE 5 or Java EE 6 App Server.