I am trying to get a RESTful web service (JAX-RS) going with Tomcat7. I have tried 3 different implementations (Jersey, RESTeasy and Restlet) with no success. This should be easy but somehow it is not. I am looking for an up to date tutorial/documentation for annotations, web.xml and sample code.
I know it has been a while since you posted this question. Most likely you figured it out by now but I would like to answer in case anyone else might benefit.
Here are some tutorials that could get you started:
http://www.javacodegeeks.com/2011/01/restful-web-services-with-resteasy-jax.html
http://www.vogella.de/articles/REST/article.html
http://www.mastertheboss.com/web-interfaces/273-resteasy-tutorial-.html
If you want to create a Servlet container deployable Jersey web application use
mvn archetype:generate -DarchetypeGroupId=org.glassfish.jersey.archetypes \
-DarchetypeArtifactId=jersey-quickstart-webapp -DarchetypeVersion=2.26
I'm using both Apache Wink and Jersey with Tomcat 7 and have no problems.
In web.xml I have:
<servlet>
<servlet-name>restSdkService</servlet-name>
<!-- When running with Jersey use the following class: com.sun.jersey.spi.container.servlet.ServletContainer -->
<!-- When running with Wink use the following class: org.apache.wink.server.internal.servlet.RestServlet -->
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>mypackage.MyApplication</param-value>
</init-param>
</servlet>
May be you should elaborate what problems/exceptions you get.
tomcat 7.0.29
<dependency>
<groupId>org.apache.cxf</groupId>
<artifactId>cxf-rt-rs-extension-providers</artifactId>
<version>2.7.7</version>
</dependency>
Tomcat 7 should not require RESTEasy, Jersey or any other proprietary implementation if JAX-RS is an integral part of Java EE 6 web-profile, which it is.
Related
I'm trying to deploy this example to Google Cloud. I'm following the exact instructions,
When I go to Cloud Console -> App Engine -> versions, I did see a new version deployed, but the size of the version is 0, and going to the module url returns 503 server error even after I waited 30 minutes.
Error: Server Error The service you requested is not available yet.
Please try again in 30 seconds.
Since I didn't modify anything in the example except the PROJECT_ID, CLUSTER_UNIQUE_ID, etc. What could be the problem here?
I was facing similar issue. I resolved it by doing the following changes:
Within web.xml:
<servlet>
<servlet-name>test</servlet-name>
<servlet-class>com.example.cloud.bigtable.helloworld.HelloServlet </servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>test</servlet-name>
<url-pattern>/test/*</url-pattern>
</servlet-mapping>
Added an index.html file within WebApp folder.
Within pom.xml, added the following:
<dependency>
<groupId>org.apache.hbase</groupId>
<artifactId>hbase-client</artifactId>
<version>1.1.1</version>
</dependency>
I've found conflicting answers to this question and I've failed to successfully run an example.
Can JAX-RS be implemented using Servlet 3.0 (in particular, Tomcat 7) with annotations, only, without having to implement another Servlet Container?
If no, please explain why the following quote from this book is either, incorrect or I'm interpreting it, wrong.
Because this example deploys within a Java EE application server or
standalone Servlet 3.x container, all we need is an empty web.xml
file. The server will detect that an Application class is within your
WAR and automatically deploy it. (RESTful Java with JAX-RS 2.0, Bill Burke)
To clarify what I don't need help with... I've, successfully, implemented JAX-RS in Tomcat 7 with Jersey using a web.xml, so, I don't need any explanation of how to do so. Also, I'm fully aware that other Java EE/Servlet Containers (TomEE, Glassfish, Jersey, Websphere, etc...) are all JAX-RS aware out of the box. I just need to know if I'm chasing my tail trying to get Tomcat 7 (Servlet 3.0) to work with JAX-RS without adding a Servlet Container and without web.xml entries.
In a Servlet environment, Jersey runs as a servlet or servlet filter. No way around that. So how does it work without declaring it in the web.xml? Two main components to this functionality
Programmatic registration of Servlet components (i.e. servlets and fitlers). You can do a Google search, and you should find some hits of examples.
Servlet pluggability introduced in Servlet 3.x. How it works is you implement a ServletContainerInitializer, list that implementation in a file named javax.servlet.ServletContainerInitializer, and put that file in the META-INF/services directory of the jar. The servlet container should scan jars looking for this file. When it finds on, it sees the implementation, finds the implementation, instantiates it, then calls it onStartup method.
Jersey has such an implementation of the SevletContainerInitializer in the JerseyServletContainerInitializer. This class is located in the jersey-container-servlet jar. So you need this jar for this to work. If you look at this method, this is where you will see the programmatic registration of the ServletContainer (the same one that yo would declare in the web.xml
But that's not all. We still need some way of configuring our application, at the least declare the servlet mapping. That's where the Application class and the #ApplicationPath annotation come in. We would extend the Application class and and annotate the #ApplicationPath("/path") where "path" is the same as the servlet mapping in the web.xml
#ApplicationPath("/api")
public class MyApplication extends Application {}
This is standard JAX-RS. With Jersey normally instead of an Application class, we use a ResourceConfig class (which is a subclass of Application)
#ApplicationPath("/api")
public class MyApplication extends ResourceConfig {
public MyApplication() {
packages("package.to.scan");
}
}
You can see more about Jersey deployment options in a Servlet 3.x environment, here.
It should also be noted, that a Java EE server has the JAX-RS implementation, so we only need to add the javaee-api jar to our application as provided dependency. But in a servlet container, we need to provide our own implementation, Jersey being such an implementation.
If you are using Maven, the main dependency you'll need is this one
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet</artifactId>
<version>${jersey2.version}</version>
</dependency>
This will pull a bunch of other jars in. You you aren't using Maven, then you can download all the jars here (the JAX-RS 2.0 RI bundle), and put all those into your application.
See Also:
How to use Jersey as JAX-RS implementation without web.xml?
Could someone explain the main differences (or provide a link to) between glassfish-web.xml, sun-web.xml and web.xml?
Can I use just glassfish-web.xml in my webapp and skip the others?
web.xml: Standard deployment descriptor defined by Java EE (Servlet JSR in particular, but used by many JSRs). It is used to specify the metadata used by the web container to deploy the application in a portable manner across application servers (such as the URL endpoint of a servlet). In Java EE 6 and beyond, it is optional (depending on technologies that you use) when metadata is provided by annotations in your Java code, like #WebServlet.
glassfish-web.xml: Each application server offers implementation-specific features. To configure these features for GlassFish, use glassfish-web.xml. This is documented in the GlassFish Documentation.
sun-web.xml: Legacy application-server specific deployment descriptor, and has been replaced by glassfish-web.xml. It no longer made sense to have this name after Sun was acquired by Oracle. This file name is still supported for backwards compatibility, but you should migrate to glassfish-web.xml.
You may or may not need a web.xml file. It depends on the Java EE features you use. By default, don't use any of these files and simply use Java EE annotations like #WebServlet. As you build out your app and perhaps begin using some features that require the web.xml file (like to define the JavaServer Faces FacesServlet), then use a web.xml file. As for the glassfish-web.xml, you only use one if you have GlassFish-specific features to configure for your application.
The Java EE tutorial is also a good way to learn Java EE, and is bundled with the Java EE 7 SDK along with GlassFish 4.
Web.xml
<?xml version="1.0" encoding="UTF-8"?>
<web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns="http://java.sun.com/xml/ns/javaee"
xsi:schemaLocation="http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" id="WebApp_ID" version="2.5">
<display-name>BusProject</display-name>
<welcome-file-list>
<welcome-file>login.jsp</welcome-file>
</welcome-file-list>
<servlet>
<servlet-name>spring</servlet-name>
<servlet-class>org.springframework.web.servlet.DispatcherServlet</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>spring</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>/WEB-INF/spring-servlet.xml</param-value>
</context-param>
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
</web-app>
can somebody please help me how to make a war of a simple mule application.
My mule application consists of a single mule-config.xml file.
I have made this mule project in ecplise and can run it as a mule server.
My requirement is to make a war and deploy it in a tomcat or tcat server.
Thanks and Regards,
Arijit
As explained in the user guide:
To embed Mule inside a webapp, you provide one or more configuration file locations as context params and include a context listener to initialize the Mule Server.
So just add this in your web.xml, with mule-config.xml at the root of your classpath (for ex. in src/main/resources):
<context-param>
<param-name>org.mule.config</param-name>
<param-value>mule-config.xml</param-value>
</context-param>
<listener>
<listener-class>org.mule.config.builders.MuleXmlBuilderContextListener</listener-class>
</listener>
EDIT I've open-sourced a running demo: https://github.com/ddossot/mule-webapp-example
I'm porting a legacy application from JBoss 4.2.3 to JBoss 7 (the web profile version). They used a custom login module and used a valve to capture the login failure reason into j_exception. They did this by putting context.xml into the web-inf directory of the war, with the following contents:
<!-- Add the ExtendedFormAuthenticator to get access to the username/password/exception ->
<Context cookies="true" crossContext="true">
<Valve className="org.jboss.web.tomcat.security.ExtendedFormAuthenticator"
includePassword="true" ></Valve>
</Context>
The login is working for me, but not that valve. When there's a login exception, the j_exception is still empty and the logic that depends on analyzing why the login was rejected fails. According to this link: http://community.jboss.org/wiki/ExtendedFormAuthenticator, everything looks right. However that link is very old, and it's possible things have changed since then. What's the new way?
It seems that security valves are now defined directly in jboss-web.xml, like this:
<jboss-web>
<security-domain>mydomain</security-domain>
<valve>
<class-name>org.jboss.web.tomcat.security.ExtendedFormAuthenticator</class-name>
<param>
<param-name>includePassword</param-name>
<param-value>true</param-value>
</param>
</valve>
</jboss-web>
However, the ExtendedFormAuthenticator class wasn't ported to JBoss 7.0.1. A ticket has been opened for me, so it should be present in JBoss 7.1.0:
https://issues.jboss.org/browse/AS7-1963