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.
Related
I have the azure spring boot service up and running, I have the configuration of Application insights in Azure. I have below code changes
pom.xml is as follows
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>applicationinsights-spring-boot-starter</artifactId>
<version>2.6.4</version>
</dependency>
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>applicationinsights-logging-logback</artifactId>
<version>2.6.4</version>
</dependency>
<dependency>
<groupId>com.microsoft.azure</groupId>
<artifactId>applicationinsights-core</artifactId>
<version>2.6.4</version>
</dependency>
and my logback-spring.xml is as follows.
<springProperty scope="context" name="INSTRUMENTATION_KEY"
source="azure.application-insights.instrumentation-key"/>
<appender name="aiAppender"
class="com.microsoft.applicationinsights.logback.ApplicationInsightsAppender">
<instrumentationKey>${INSTRUMENTATION_KEY}</instrumentationKey>
</appender>
and my application.yml file as below,
azure:
application-insights:
instrumentation-key: <my_instrumentation_key>
enabled: true
web:
enabled: true
logger:
level: info
This configuration is working fine and pushing the logs to Azure AI if I run my application locally. But when I push the same to Azure, I see none of the logs being pushed. Please help me on this since am banging my head for past 3 days.
This has been resolved after changing the version of applicationinsights-agent.jar to 3.2.4
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.
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.
I'm going through this tutorial example on RestEasy:
http://www.mkyong.com/webservices/jax-rs/resteasy-hello-world-example/
I downloaded their code and made modification so that I can deploy it to tomcat 7 and java 1.7.
If I leave the pom.xml as specified by the site,
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jaxrs</artifactId>
<version>2.2.1.GA</version>
</dependency>
then everything appears to be fine and can be accessed through:
http://localhost:8080/RESTfulExample/rest/message/hello
However, if I were to increase the version level to 3.0.8.Final or "RELEASE",
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-jaxrs</artifactId>
<version>3.0.8.Final</version>
</dependency>
then I can't access it via the above URL. Instead, I get this message in my localhost_access_log.txt
127.0.0.1 - - [19/Aug/2014:16:02:55 -0700] "GET /RESTfulExample/rest/message/hello HTTP/1.1" 404 -
Question: Does anyone know how I can get the pom.xml to work if I really want to use RESTeasy 3.0.8.Final? I'm new to Rest.
Thanks in advance.
As the documentation describes you can initialize RESTeasy in a standalone Servlet 3.0 compliant container by adding this dependency:
<dependency>
<groupId>org.jboss.resteasy</groupId>
<artifactId>resteasy-servlet-initializer</artifactId>
<version>3.0.8.Final</version>
</dependency>
You should also update the web.xml with the correct Servlet version. Most of the old configuration stuff can be removed so you end up with:
<web-app 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"
version="3.0">
<display-name>Restful Web Application</display-name>
</web-app>
Last thing to do is tell RESTeasy on which path you want to map your application by adding javax.ws.rs.ApplicationPath to the MessageApplication class:
#ApplicationPath("/rest")
public class MessageApplication extends Application {
...
}
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.