Tomcat 6 vs 7 broke default and jsp servlet requests (404) - tomcat7

We're migrating around 20 web contexts from Tomcat 6.0.48 to Tomcat 7.0.76 but we're facing an issue with the requests handled by the servlets configured in the parent web.xml (tomcat7\conf\web.xml). The problem is that requests for /some_file.html, /some_file.jsp, /images/some-image.jpg, /index.xhtml return a 404 NOT FOUND, while other custom servlets declared in the web.xml of the context work fine. All 20 contexts are working fine in Tomcat 6 for years, but only 10 are failing on Tomcat 7. We have compared the ones that work with the ones that don't, but they are very different (unsurprisingly) and we haven't found the problem.
The tests
Projects are deployed using Eclipse under Windows, some test were executed deploying the WAR file directly on /webapps with the same results. All projects are Java 1.8 and they are mavenized. The tests consist in deploying one working context and one that does not work and navigate to: /some_file.html, /some_file.jsp, /images/some-image.jpg and see if the response is 200 or 404.
We've tried to match the version of javax.servlet.servlet-api (2.5 to 3.0.1) and javax.servlet.jsp.jsp-api (2.0 to 2.2) with the ones provided by Tomcat 7 in the dependencies (Parent POM). No change.
<dependency>
<groupId>javax.servlet</groupId>
<!-- <artifactId>servlet-api</artifactId>
<version>2.5</version> -->
<artifactId>javax.servlet-api</artifactId>
<version>3.0.1</version>
<scope>provided</scope>
</dependency>
<dependency>
<groupId>javax.servlet.jsp</groupId>
<artifactId>jsp-api</artifactId>
<!-- <version>2.0</version> -->
<version>2.2</version>
<scope>provided</scope>
</dependency>
We've copied the default and jsp servlet mapping configuration from the web.xml file of Tomcat on the web.xml of the application. No change.
<!-- The mapping for the default servlet -->
<servlet-mapping>
<servlet-name>default</servlet-name>
<url-pattern>/</url-pattern>
</servlet-mapping>
<!-- The mappings for the JSP servlet -->
<servlet-mapping>
<servlet-name>jsp</servlet-name>
<url-pattern>*.jsp</url-pattern>
<url-pattern>*.jspx</url-pattern>
</servlet-mapping>
We've changed the url-pattern / to /* in the tomcat's web.xml file for the default servlet and things started to work with static resources but not for *.jsp and *.xhtml files (Faces). But as read in the servlet specification (JSR-315), it should work with /. Either way, this change broke *.jsp requests for all contexts (¿?).
<servlet-name>default</servlet-name>
<url-pattern>/</url-pattern>
<servlet-name>default</servlet-name>
<url-pattern>/*</url-pattern>
We've deleted all servlet-mapping and filter-mapping from the web.xml file of the context to see if there was any kind of conflict. No change.
We suspect that...
either the tomcat's web.xml is not read, it's overwritten, or the url-pattern for / and *.jsp is broken by some contexts's descriptor.
Any clues?
Thanks in advance.

Related

Spring Boot | Session Replication | Mode COOKIE

I have a spring boot application up and running.
We run it using external standalone tomcat behind LB.
Tomcat version - 9
Springboot - 2.3.4.RELEASE
I have tried with below approach but none works.
web.xml
<session-config>
<session-timeout>30</session-timeout>
<tracking-mode>COOKIE</tracking-mode>
</session-config>
<display-name>availment</display-name>
application.properties
server.session.tracking-modes=cookie
Javax-servlet
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>servlet-api</artifactId>
<version>2.5</version>
</dependency>
But none seems to work, user gets logout as soon as request reaches another server where login request did not come.

Deploying a RAP .war file in jetty

I created an hello-world RAP application following the eclipse tutorial. I have no problems starting it in eclipse.
Now i want to package it as a .war file with maven and deploy it inside a jetty server. That's the point where i'm already unsure if it is the right approach.
My .war file includes all RAP, equinox and maven plugins, a web.xml and a config.ini. I'm building it with Tycho but i'm open to other solutions.
config.ini:
#Product Runtime Configuration File
osgi.bundles=RapHello/BasicEntryPoint#start,\
org.eclipse.core.commands#start,\
org.eclipse.core.jobs#start,\
org.eclipse.equinox.common#start,\
org.eclipse.equinox.console#start,\
org.eclipse.equinox.ds#start,\
org.eclipse.equinox.http.registry#start,\
org.eclipse.equinox.servletbridge.extensionbundle,\
org.eclipse.equinox.http.servlet#start,\
org.eclipse.equinox.http.servletbridge#start,\
org.eclipse.equinox.registry#start,\
org.eclipse.equinox.servletbridge#start,\
org.eclipse.equinox.util#start,\
org.eclipse.osgi.services#start,\
org.eclipse.rap.jface#start,\
org.eclipse.rap.rwt#start,\
org.eclipse.rap.rwt.osgi#start,\
raphello.BasicEntryPoint#start
osgi.bundles.defaultStartLevel=4
web.xml (copied from another sample .war):
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" "http://java.sun.com/j2ee/dtds/web-app_2_2.dtd">
<web-app id="WebApp">
<servlet id="bridge">
<servlet-name>equinoxbridgeservlet</servlet-name>
<display-name>Equinox Bridge Servlet</display-name>
<description>Equinox Bridge Servlet</description>
<servlet-class>org.eclipse.equinox.servletbridge.BridgeServlet</servlet-class>
<!-- Framework Controls could be useful for testing purpose, but
we disable it per default -->
<init-param>
<param-name>enableFrameworkControls</param-name>
<param-value>false</param-value>
</init-param>
<!-- Enable multi-language support for the extension registry -->
<!-- the OSGi console is useful for trouble shooting but will fill up your
appserver log quickly, so deactivate on production use. Uncomment
the -console parameter to enabled OSGi console access. -->
<init-param>
<param-name>commandline</param-name>
<param-value>-registryMultiLanguage <!-- -console --></param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>equinoxbridgeservlet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
When i deploy the file in my jetty server, i get no errors and it seems like the file gets picked up, but all i get are
HTTP ERROR 404
Problem accessing /hellorap. Reason:
ProxyServlet: /hellorap
i think i tried all possible paths. What i read so far is, that the path should be the file name of my .war but that doesn't work.
jetty start log:
INFO::main: Logging initialized #276ms to org.eclipse.jetty.util.log.StdErrLog
INFO:oejs.Server:main: jetty-9.4.10.v20180503; built: 2018-05-03T15:56:21.710Z; git: daa59876e6f384329b122929e70a80934569428c; jvm 1.8.0_181-b13
INFO:oejw.StandardDescriptorProcessor:main: NO JSP Support for /, did not find org.eclipse.jetty.jsp.JettyJspServlet
INFO:oejs.session:main: DefaultSessionIdManager workerName=node0
INFO:oejs.session:main: No SessionScavenger set, using defaults
INFO:oejs.session:main: node0 Scavenging every 600000ms
INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext#561b6512{/,file:///C:/Users/USR/AppData/Local/Temp/jetty-0.0.0.0-8081-raphello.war-_-any-511053963228532950.dir/webapp/,AVAILABLE}{webapps/raphello.war}
INFO:oejs.AbstractConnector:main: Started ServerConnector#2898ac89{HTTP/1.1,[http/1.1]}{0.0.0.0:8081}
INFO:oejs.Server:main: Started #4477ms
So the question is: What am i doing wrong? Is it even the right approach?
This answer doesn't seem to work so my error is propably at an earlier stage.

spring boot application deployment on weblogic throws 404 error

I have done below configurations and tried almost all solutions found but nothing helped. When i am deploying spring boot app in war package. no error got logged in weblogic log but the application throwing 404 error.
web.xml
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:root-context.xml</param-value>
</context-param>
<context-param>
<param-name>spring.profiles.active</param-name>
<param-value>dev</param-value>
</context-param>
<context-param>
<param-name>spring.profiles.default</param-name>
<param-value>dev</param-value>
</context-param>
<context-param>
<param-name>spring.liveBeansView.mbeanDomain</param-name>
<param-value>dev</param-value>
</context-param>
weblogic.xml
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-web-app xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:wls="http://www.bea.com/ns/weblogic/90"
xsi:schemaLocation="http://java.sun.com/xml/ns/j2ee http://java.sun.com/xml/ns/j2ee/web-app_2_4.xsd http://www.bea.com/ns/weblogic/90 http://www.bea.com/ns/weblogic/90/weblogic-web-app.xsd">
<wls:weblogic-version>12.1.2.0.0</wls:weblogic-version>
<wls:context-root>/services/userModule/</wls:context-root>
<wls:container-descriptor>
<wls:prefer-application-packages>
<wls:package-name>com.fasterxml</wls:package-name>
<wls:package-name>org.slf4j</wls:package-name>
<wls:package-name>org.springframework.*</wls:package-name>
</wls:prefer-application-packages>
</wls:container-descriptor>
</wls:weblogic-web-app>
application.properties
spring.profiles.default=default
spring.profiles.active=default
spring.liveBeansView.mbeanDomain=default
cms.config.monitor.dir=/server/location/application/artifacts
application.messages.file.name=application-messages
application.config.file.name=application-config
root-context.xml
it contains application specific configurations.
ApplicationBegin.java
#SpringBootApplication(exclude = {DataSourceAutoConfiguration.class, JpaRepositoriesAutoConfiguration.class})
public class ApplicationBegin extends SpringBootServletInitializer implements WebApplicationInitializer {
#Override
protected SpringApplicationBuilder configure(SpringApplicationBuilder application) {
return application.sources(ApplicationBegin.class);
}
public static void main(String[] args){
SpringApplication.run(ApplicationBegin.class, args);
}
Cannot exclude tomcat server from pom.xml as it is failing the compilation. is there a way to set tomcat as provided while using spring boot starter web?
pom.xml
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-web</artifactId>
<exclusions>
<exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-logging</artifactId>
</exclusion>
<!-- THIS WILL BE EXCLUDE ONLY FOR WEBLOGIC DEPLOYMENT -->
<!-- <exclusion>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-tomcat</artifactId>
</exclusion> -->
</exclusions>
</dependency>
The problem is the application runs fine with embedded tomcat but it is not working even not throwing any error when deploying on weblogic. Where should i look?
Can you try class loading as the parent last? So Spring boot will use it's own container libraries.
After trying the solutions i found from different people , it couldn't solve my issue and somehow i have solved it now. all the similar issues i have seen on this topic and the soultions, i finally understood no answer was actually a solution because in most of the cases the issue happens because of wrong configuration that weblogic dosen't understand. the worst part being it doesn't even throw error. In my case other than application.properties file and a root-context.xml, i explicitly specified web.xml file in /WEB-INF location and defined context-config location there. As soon as i removed the web.xml and refactored/filtered the project dependencies from top to bottom , it resolved the issue.
and also then i realized many handy solutions on the web for this issue wouldn't even be required if your configuration is correct. for an example, configuring a jpavendor won't require if you use spring boot jpa starter correctly.
so.. if you ever face this kind of deployment issue on weblogic , you may follow below steps -
Only deploy a bareminimum part of application and make it workable
on weblogic
then add your critical dependencies / configurations and deploy them one by one on weblogic and check if it is working
you should always run your boot application to other local server first for resolving major configuration issues ..tomcat is
good.
I had the same problem, but I finally managed to solve it.
The problem was the version of web.xml descriptor. If you put the web.xml file in your project with <web-app version="2.5">, even though your Weblogic supports servlet 3.0, the spring controllers would throw 404.
That also explains the behavior of your app - what's why it started working when you removed the web.xml file.

How do I migrate from Jersey 1.0 to Jersey 2.0?

I'm trying to upgrade to Jersey 2.0 and I'm having a lot of trouble because the groupIds and artifactIds of Jersey have completely changed and I can't find a migration plan in the Jersey docs.
Here's what my pom.xml used to look like, and this compiled fine:
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-server</artifactId>
<version>1.17</version>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-servlet</artifactId>
<version>1.17</version>
<scope>runtime</scope>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-server-linking</artifactId>
<version>1.17.1</version>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-client</artifactId>
<version>1.17.1</version>
</dependency>
What should these be changed to? This unrelated StackOverflow question was somewhat helpful, but I'm having trouble finding things like where the #Ref annotation moved to.
Update
It seems that #Ref no longer exists or at least it's not mentioned in the documentation anymore. Now you use a UriBuilder.
I found a very helpful section in the documentation that answers my maven issues.
The HTTPBasicAuthFilter has been renamed to HttpBasicAuthFilter. Notice the capitalization.
Client client = Client.create(); has become Client client = ClientBuilder.newClient();
This:
String json = client
.resource(getBaseUrl() + url)
.accept(MediaType.APPLICATION_JSON_TYPE)
.get(String.class);
has become
String json = client
.target(getBaseUrl())
.path(url)
.request(MediaType.APPLICATION_JSON_TYPE)
.get(String.class);
You don't.
Jersey 2.0 is missing a lot of functionality from Jersey 1.0. Contrary to what the committers will tell you, some things are plain impossible to implement right now (e.g. Guice, Spring integration). Things appear to work on the surface, but once you dig in deeper you will find a lot of features are still broken.
Many of the 1.x plugins do not exist in 2.x, mainly because of the aforementioned breakage.
In light of this, I suggest a holding off on Jersey 2.x for the foreseeable future. Hopefully the committers will clean this up in the coming year.
It is pain in the neck I have to say.
We are currently knee deep into migrating relatively large 3+ years old client-server project and boy do I want to bite my neck off.
Hopefully we are at the end of the struggle...
While there is a migration guide indeed it is not comprehensive by any means.
UniformInterfaceException (and others) is no more.
Instead it is replaced by WebApplication exception and successors. There is not a word about that in the migration guide and this is very very important.
JSON support
The migration guide says:
JSON Support has undergone certain changes in Jersey 2.x. The most
visible difference for the developer is in the initialization and
configuration.
In Jersey 1.x, the JAXB/JSON Support was implemented as a set of
MessageBodyReaders and MessageWriters in the jersey-json module.
Internally, there were several implementations of JSON to Object
mapping ranging from Jersey's own custom solution to third party
providers, such as Jackson or Jettison. The configuration of the JSON
support was centralized in the JSONConfiguration and JSONJAXBContext
classes.
Great. What if you have chosen the "Jersey's own custom solution" (which we did for whatever reason)? There is no alternative to that in jersey 2. I tried to produce the same JSON format using Jettison, Jackson and Moxy providers. I did not succeed. For reference, my unanswered question here: Jersey 2 JSON Jettison unwrapping root element
See the 1.x to 2.0 migration guide in the Jersey docs. (2019 link to 1.x to 2.0 migration guide)
It looks like #InjectLink is the replacement for #Ref.
From that link, I was able to drop this into my pom.xml:
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-declarative-linking</artifactId>
<version>2.6</version>
</dependency>
and then I took an existing #Ref and was able to drop in replace with #InjectLink.
public Long id; // This id is referenced below in the link
#InjectLink(resource = FavoriteResource.class, method = "updateFavorites", bindings = {
#Binding(name = "listId", value = "${instance.id}")
})
public URI linkURI;
It looks like some of the JavaDocs from #Ref are in #InjectLink even, which would be further confirmation that it's the replacement:
/**
* ...
* #Ref(resource=SomeResource.class)
* #Ref(resource=SomeResource.class, bindings={
* #Binding(name="id" value="${instance.id}"}
* )
*/
EDIT:
Tricky stuff. I needed one more piece to make this work for me. In web.xml,
I now have:
<servlet>
<servlet-name>jersey-servlet</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>jersey.config.server.provider.packages</param-name>
<param-value>com.mycompany.root</param-value>
</init-param>
<init-param>
<param-name>jersey.config.server.provider.classnames</param-name>
<param-value>com.mycompany.root.web.filter.AuditResourceFilterFactory;com.mycompany.root.web.filter.OtherAuditResourceFilterFactory</param-value>
</init-param>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>com.mycompany.root.web.resource.config.CustomResourceConfig</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
and finally, CustomResourceConfig.java looks like this
import org.glassfish.jersey.linking.DeclarativeLinkingFeature;
import org.glassfish.jersey.server.ResourceConfig;
public class CustomResourceConfig extends ResourceConfig {
public CustomResourceConfig() {
packages("org.glassfish.jersey.examples.linking");
register(DeclarativeLinkingFeature.class);
}
}
You can follow following steps for migration from Jersey 1 to Jersey 2 :
Add following dependencies in POM file :
Jersey 2.23.2 dependencies
<dependency>
<groupId>org.glassfish.jersey.containers</groupId>
<artifactId>jersey-container-servlet-core</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-spring3</artifactId>
<version>2.23.2</version>
<exclusions>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-beans</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
</exclusion>
<exclusion>
<groupId>org.springframework</groupId>
<artifactId>spring-web</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-client</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-moxy</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.ext</groupId>
<artifactId>jersey-entity-filtering</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-server</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.core</groupId>
<artifactId>jersey-common</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.bundles.repackaged</groupId>
<artifactId>jersey-guava</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-json-jackson</artifactId>
<version>2.23.2</version>
<exclusions>
<exclusion>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
</exclusion>
</exclusions>
</dependency>
<dependency>
<groupId>com.fasterxml.jackson.core</groupId>
<artifactId>jackson-annotations</artifactId>
<version>2.5.4</version>
</dependency>
<dependency>
<groupId>org.glassfish.jersey.media</groupId>
<artifactId>jersey-media-multipart</artifactId>
<version>2.23.2</version>
</dependency>
<dependency>
<groupId>org.jvnet</groupId>
<artifactId>mimepull</artifactId>
<version>1.6</version>
</dependency>
Make Following entry in Web.xml :
<?xml version="1.0" encoding="UTF-8"?>
<web-app id="WebApp_ID" version="3.0" xmlns="http://java.sun.com/xml/ns/javaee" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/web-app_3_0.xsd">
<servlet>
<servlet-name>jersey-servlet</servlet-name>
<servlet-class>org.glassfish.jersey.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>javax.ws.rs.Application</param-name>
<param-value>com.jsg.resource.initializer.RestResourceInitializer</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>jersey-servlet</servlet-name>
<url-pattern>/rest/*</url-pattern>
</servlet-mapping> '
<listener>
<listener-class>org.springframework.web.context.ContextLoaderListener</listener-class>
</listener>
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>classpath:applicationContext.xml</param-value>
</context-param>
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/myAppName</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</web-app>
Write following code in RestResourceIntializer
package com.jsg.resource.initializer;
import java.util.HashSet;
import java.util.Set;
import javax.ws.rs.core.Application;
public class RestResourceInitializer extends Application {
/**
* Gets the classes.
*
* #return the classes
*/
public Set<Class<?>> getClasses() {
Set<Class<?>> classes = new HashSet<Class<?>>();
// Resources
classes.add(org.glassfish.jersey.jackson.JacksonFeature.class);
classes.add(org.glassfish.jersey.server.spring.scope.RequestContextFilter.class);
classes.add(org.glassfish.jersey.media.multipart.MultiPartFeature.class);
//Rest classes within Application.
classes.add(com.jsg.rest.AbcRestService.class);
classes.add(com.jsg.rest.CdeRestService.class);
return classes;
}
}
Now if you will deploy code with above changes on websphere,you will get following exception :
Caused by: java.lang.NoSuchMethodError: javax/ws/rs/core/Application.getProperties()Ljava/util/Map; at org.glassfish.jersey.server.ApplicationHandler.(ApplicationHandler.java:287) at org.glassfish.jersey.servlet.WebComponent.(WebComponent.java:311)
Reason for above exception is that,Websphere supports JAX-RS 1 implementation,however we are deploying Jersey 2 code which is Jax-rs 2 implementation.
Steps for resolving above exception:
So basically what we have to do is to force WebSphere to pick our Jersey 2 jars instead of default Jax-rs 1.We need to follow following steps for that
1) Disable in built JAX-RS by setting following JVM property to true
com.ibm.websphere.jaxrs.server.DisableIBMJAXRSEngine=true
This property can be set through admin console of WebSphere by going to Servers->All Server -> ->Server Infrastructure -> Java and Process Management ->Process Deifinition ->Additional Properties-> Java Virtual Machine ->Additional Properties-> Custom Properties
2) Create Isolated Shared Library having the Jersey 2 Jars and Spring 4 Jars
Isolated shared library can be created through admin Console of Websphere by going to Environment-> Shared Libraries ->New
n the classpath box,we need to enter path of the folder on the server,where we have placed all Jersey 2 and Spring 4 Jars
/var/was/server2/jerseyLib1/spring-context-4.3.4.RELEASE.jar
/var/was/server2/jerseyLib1/spring-core-4.3.4.RELEASE.jar
/var/was/server2/jerseyLib1/spring-beans-4.3.4.RELEASE.jar
/var/was/server2/jerseyLib1/spring-aop-4.3.4.RELEASE.jar
/var/was/server2/jerseyLib1/spring-web-4.3.4.RELEASE.jar
/var/was/server2/jerseyLib1/spring-expression-4.3.4.RELEASE.jar
/var/was/server2/jerseyLib1/spring-bridge-2.5.0-b05.jar
/var/was/server2/jerseyLib1/hk2-locator-2.5.0-b05.jar
/var/was/server2/jerseyLib1/hk2-api-2.5.0-b05.jar
/var/was/server2/jerseyLib1/hk2-utils-2.5.0-b05.jar
/var/was/server2/jerseyLib/javax.inject-2.5.0-b05.jar
/var/was/server2/jerseyLib1/javax.annotation-api-1.2-b03.jar
/var/was/server2/jerseyLib1/javax.ws.rs-api-2.0.1.jar
/var/was/server2/jerseyLib1/jersey-client-2.23.2.jar
/var/was/server2/jerseyLib1/jersey-spring3-2.23.2.jar
/var/was/server2/jerseyLib1/jersey-container-servlet-core-2.23.2.jar
/var/was/server2/jerseyLib1/jersey-server-2.23.2.jar
/var/was/server2/jerseyLib1/jersey-common-2.23.2.jar
/var/was/server2/jerseyLib1/jersey-guava-2.23.2.jar
Also in class loading section ,select "use an isolated class loader for this shared library"
and then finally click on Apply and Ok and we are done with creation of isolated shared library.
Bind this isolated shared library with your application war file as follows in admin Console
a) Application -> All Applications -> Click on your application name
b) Go to References -> Shared Library References -> Reference Shared Libraries ->select your application war(Not ear) and click ok.
c) Select the library that we created in Step 2 in "Available" combo box on left side and put it on right side in "Selected" combo box and click ok.
With this we have associated the isolated shared library with application war file.
Restart Server and application should be up and running.

Spring 3.1 - Servlet 3 code-based configuration using the Jetty Maven Plugin

I try to integrate the new features of spring 3.1 using annotations to specify the configuration information for the web application.
I set up the maven-jetty-plugin version 8.0.4.v20111024 to run my app.
While starting jetty using the mvn jetty:run command, everything seems to be ok and set up correctly.
But when accessing the app through the browser, there is just the output of the default servlet.
It seems to be a simular issue, that tomcat had in previous versions (<=7.0.14)
https://issues.apache.org/bugzilla/show_bug.cgi?id=51278
Currently, I can not use jetty and I had to switch to the tomcat-plugin to deploy my application to tomcat.
Has anyone any suggestions, how to overwrite the jetty default servlet, when no web.xml is available?
You do it by overriding the default jetty config, put this in your plugin:
<configuration>
<scanIntervalSeconds>0</scanIntervalSeconds>
<webAppConfig>
<defaultsDescriptor>src/main/resources/webdefault.xml</defaultsDescriptor>
</webAppConfig>
</configuration>
Copy the webdefault file from Jetty, and comment out this part:
<!-- <servlet-mapping> -->
<!-- <servlet-name>default</servlet-name> -->
<!-- <url-pattern>/</url-pattern> -->
<!-- </servlet-mapping> -->

Resources