Develop Reference

How to configure Weblogic 12.1.3 to use older version of Jersey while deploying Enterprise App

I have installed Weblogic 12.1.3 as part of upgrade from Weblogic 10.3.6 to Weblogic 12.1.3
My application uses Jersey version 1.17 jars
However, after we install Weblogic 12.1.3, we get Jersey 1.18 Jars inside folder ORACLE_HOME/oracle_common/modules
The Jersey 1.18 Jars override the Jersey 1.17 jars which are bundled in our application and causes error in deploying our application.
We get error/warning messages as give below
WARNING: Return type javax.xml.bind.JAXBElement of method public javax.xml.bind.JAXBElement com.ipc.dms.dsfs.service.rs.DSFSResource.getEnterpriseContacts(java.lang.String,java.lang.Integer,java.lang.Integer,java.lang.String) is not resolvable to a concrete type
WARNING: Return type javax.xml.bind.JAXBElement of method public javax.xml.bind.JAXBElement com.ipc.dms.dsfs.service.rs.DSFSResource.getMediaServiceConfigList(java.lang.String) is not resolvable to a concrete type
The application is using ServletContainerInitializer class com.sun.jersey.server.impl.container.servlet.JerseyServletContainerInitializer that is loaded from:file:/opt/oracle/oracle_common/modules/jersey-servlet-1.18.jar. This initializer overrides the one available in the system.
**********>
java.lang.NoClassDefFoundError: Could not initialize class org.jgroups.conf.XmlConfigurator
at org.jgroups.conf.ConfiguratorFactory.getXmlConfigurator(ConfiguratorFactory.java:216)
at org.jgroups.conf.ConfiguratorFactory.getStackConfigurator(ConfiguratorFactory.java:93)
at org.jgroups.JChannel.(JChannel.java:142)
If we remove the Jersey 1.18 Jars from ORACLE_HOME/oracle_common/modules we DO NOT get these error messages.
However, removing jars from installation folder causes other issues.To be specific I get the issue mentioned below if I remove the Jersey 1.18 jars from from ORACLE_HOME/oracle_common/modules
weblogic.kernel.Default (self-tuning)'> <> <> <> <1467281457661> < BEA-149231 > < Unable to set the activation state to true for the application "dunkin".
weblogic.application.ModuleException: java.lang.ArrayStoreException: sun.reflect.annotation.TypeNotPresentExceptionProxy
at weblogic.application.internal.ExtensibleModuleWrapper.start(ExtensibleModuleWrapper.java:140)
at weblogic.application.internal.flow.ModuleListenerInvoker.start(ModuleListenerInvoker.java:124)
So, I need to know if we can configure our EAR to use older version of Jersey i.e Jersey 1.17 while deploying the application on Weblogic 12.1.3.
If yes, please provide configuration details.

You have got 2 options:
To include the <prefer-application-packages> tag in the weblogic-application.xml of your ear as below:
<weblogic-application>
<prefer-application-packages>
<package-name>com.sun.jersey.*</package-name>
</prefer-application-packages>
</weblogic-application>
To inlcude the <wls:prefer-web-inf-classes> tag in the weblogic.xml of your war file as below:
<wls:container-descriptor>
<wls:prefer-web-inf-classes>true</wls:prefer-web-inf-classes>
</wls:container-descriptor>
If you decide to use option 2 then all the common libs of weblogic will be overidden by the libs of your application. So I would suggest to go with option 1.

Provider com.bea.xml.stream.MXParserFactory not found with JCL

I'm trying to develop an application which uses a library with a stax-api as a dependency. Build as stand-alone application it works fine, but when I'm trying to load JAR with dependencies assembled in my application using JCL, I get the following error:
javax.xml.stream.FactoryConfigurationError: Provider com.bea.xml.stream.MXParserFactory not found
at javax.xml.stream.FactoryFinder.newInstance(FactoryFinder.java:72)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:178)
at javax.xml.stream.FactoryFinder.find(FactoryFinder.java:92)
at javax.xml.stream.XMLInputFactory.newInstance(XMLInputFactory.java:136)
at org.codehaus.xfire.util.STAXUtils.<clinit>(STAXUtils.java:48)
at org.codehaus.xfire.transport.http.HttpChannel.writeWithoutAttachments(HttpChannel.java:54)
at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.getByteArrayRequestEntity(CommonsHttpMessageSender.java:422)
at org.codehaus.xfire.transport.http.CommonsHttpMessageSender.send(CommonsHttpMessageSender.java:360)
at org.codehaus.xfire.transport.http.HttpChannel.sendViaClient(HttpChannel.java:123)
at org.codehaus.xfire.transport.http.HttpChannel.send(HttpChannel.java:48)
at org.codehaus.xfire.handler.OutMessageSender.invoke(OutMessageSender.java:26)
at org.codehaus.xfire.handler.HandlerPipeline.invoke(HandlerPipeline.java:131)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:79)
at org.codehaus.xfire.client.Invocation.invoke(Invocation.java:114)
at org.codehaus.xfire.client.Client.invoke(Client.java:336)
at eu.unicore.security.xfireutil.client.ReliableProxy.handleRequest(ReliableProxy.java:122)
at eu.unicore.security.xfireutil.client.ReliableProxy.doInvoke(ReliableProxy.java:102)
at eu.unicore.security.xfireutil.client.ReliableProxy.invoke(ReliableProxy.java:69)
at com.sun.proxy.$Proxy71.QueryResourceProperties(Unknown Source)
at de.fzj.unicore.wsrflite.xmlbeans.client.BaseWSRFClient.queryResourceProperties(BaseWSRFClient.java:372)
at de.fzj.unicore.wsrflite.xmlbeans.client.RegistryClient.listServices(RegistryClient.java:199)
at de.fzj.unicore.wsrflite.xmlbeans.client.RegistryClient.listAccessibleServices(RegistryClient.java:214)
at org.caebeans.wsrf.UNICOREModule.initialize(UNICOREModule.java:53)
... 9 more
It's rather strange, this class is assembled into the JAR, I can find it in archive.

I've seen this kind of message when application server libraries are loaded before application ones. Usually there's a setting that lets you specify the inverse order. If, as it seems, you're using Weblogic this may be achieved by inserting the following definition in your weblogic.xml file:
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>

Try adding this Maven dependency:
<dependency>
<groupId>stax</groupId>
<artifactId>stax</artifactId>
<version>1.2.0</version>
</dependency>

How can I integrate Jersey with TomEE / openEJB

I am upgrading a code that uses Jersey JAX-RS to run on an Apache TomEE server. Unfortunately it throws errors when I try to use Jersey with TomEE.
I am using eclipse and have the JAX-RS project facet turned on. It points to the Jersey library. I have also moved the Jersey libraries into the /lib/ directory to try to solve the problem to no avail. The server throws the following error:
May 14, 2012 6:26:44 AM com.sun.jersey.api.core.ScanningResourceConfig logClasses
INFO: Provider classes found:
class org.codehaus.jackson.jaxrs.JsonParseExceptionMapper
class org.codehaus.jackson.jaxrs.JacksonJaxbJsonProvider
class org.codehaus.jackson.jaxrs.JsonMappingExceptionMapper
class org.codehaus.jackson.jaxrs.JacksonJsonProvider
May 14, 2012 6:26:44 AM org.apache.catalina.core.ApplicationContext log
SEVERE: StandardWrapper.Throwable
java.lang.RuntimeException: javax.naming.NameNotFoundException: Name [com] is not bound in this Context. Unable to find [com].
at com.sun.jersey.server.impl.cdi.CDIExtension.getInitializedExtension(CDIExtension.java:177)
at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.<init>(CDIComponentProviderFactory.java:92)
at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:576)
at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)
at com.sun.jersey.spi.container.servlet.WebComponent.load(WebComponent.java:608)
at com.sun.jersey.spi.container.servlet.WebComponent.init(WebComponent.java:210)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:373)
at com.sun.jersey.spi.container.servlet.ServletContainer.init(ServletContainer.java:556)
at javax.servlet.GenericServlet.init(GenericServlet.java:160)
at org.apache.catalina.core.StandardWrapper.initServlet(StandardWrapper.java:1266)
at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1185)
at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:1080)
at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:5015)
at org.apache.catalina.core.StandardContext.startInternal(StandardContext.java:5302)
at org.apache.catalina.util.LifecycleBase.start(LifecycleBase.java:150)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1566)
at org.apache.catalina.core.ContainerBase$StartChild.call(ContainerBase.java:1556)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
Caused by: javax.naming.NameNotFoundException: Name [com] is not bound in this Context. Unable to find [com].
at org.apache.naming.NamingContext.lookup(NamingContext.java:820)
at org.apache.naming.NamingContext.lookup(NamingContext.java:168)
at org.apache.naming.SelectorContext.lookup(SelectorContext.java:158)
at javax.naming.InitialContext.lookup(Unknown Source)
at com.sun.jersey.server.impl.cdi.CDIExtension$2.stepInto(CDIExtension.java:290)
at com.sun.jersey.server.impl.cdi.CDIExtension.diveIntoJNDIContext(CDIExtension.java:267)
at com.sun.jersey.server.impl.cdi.CDIExtension.lookupJerseyConfigJNDIContext(CDIExtension.java:287)
at com.sun.jersey.server.impl.cdi.CDIExtension.getInitializedExtension(CDIExtension.java:175)
... 22 more
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" xmlns:web="http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd" 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>tomeeTest3</display-name>
<servlet>
<description>JAX-RS Tools Generated - Do not modify</description>
<servlet-name>JAX-RS Servlet</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>JAX-RS Servlet</servlet-name>
<url-pattern>/jaxrs/*</url-pattern>
</servlet-mapping>
</web-app>
Does anyone know how I might make this work? I'd also consider using the tomEE+ Jax-rs server, but it doesn't seem to recognize the Jackson annotations.
EDIT: I think the issue is that the openEJB CDI is conflicting with the CDI that comes with Jersey. I have no idea how to fix this.

RESURRECTION! Just in case anyone is still running into this problem.
I had a Jersey application that was running in Tomcat peachy keen and exploded in exactly this manner when I moved it it TomEE. The problem is that TomEE already has its own JAX-RS implementation (tomee-jaxrs-1.5.0 at the time of this writing), which conflicts with the jersey-bundle jars.
All I had to do to get rid of this problem was remove the jersey jars and comment out the servlet declaration and mapping in the web.xml
Give it a restart, and viola! Just remember that the URLs will be slightly different. For example, on a default jersey install you might have http://localhost/rest/represent/me and when you move that same app to TomEE it will be http://localhost/represent/me
If you're using an IDE like eclipse it might bark at you for not being able to find the jars, just go into the project properties and set the target runtime to TomEE (you will have to add a server instance) and you should be good to go.
Share and enjoy.

I too have run into this problem with that exact exception, and unfortunately grauwulf's answer did not work for me.
In my case, I have Tomee+ 1.5.2, Jersey 1.1x, and I am also using Spring 3.x.
The fix was actually quite simple:
Find the Tomee system.properties file ({tomee}/conf/system.properties by default).
Add com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true
From there, it just worked for me. To give the credit where it's due, I found it on this blog post.
Of interest, I also prefer to avoid cluttering my {tomee}/lib folder with my war's dependencies, so I have also found that you can easily add an extra lib by modifying {tomee}/conf/tomee.xml, and adding the following node (inside the root <tomee /> node):
<tomee>
<Service
id="extra-libs-enricher"
class-name="org.apache.openejb.assembler.classic.enricher.AdditionalLibClassLoaderEnricherObserver">
path = /path/to/your/libs
</Service>
</tomee>
With that Service, whose name is arbitrary, you can not pass a path, at which point it defaults to "additional-lib". The passed in path will be used by default, but if it is not a directory, then it will fall back to a system property, which can be added to the system.properties file. The system property is: openejb.enricher.additional-lib.
openejb.enricher.additional-lib=/fallback/path/to/your/libs
This system property is only checked if the path passed to Service, or its default value, does not work and only if a Service is placed in the tomee.xml file. Its id is irrelevant.

Just came across with this problem: TomEE + Jersey... the problem was that I was using TomEE in Eclipse "Use workspace metadata"... and somehow when configured like this the server configurations misses several details of the TomEE configs (namely the conf/system.properties - where we declare: "com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true"). When I changed it to "Use Tomcat installation", the problem went away. You can configure this by double-clicking the TomEE server in Eclipse and select "Use Tomcat installation", as seen in the following image:

You should add the package of the Provider classes as a parameter to the servlet:
<servlet>
<servlet-name>ServletAdaptor</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>your.package.name</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>ServletAdaptor</servlet-name>
<url-pattern>/jaxrs/*</url-pattern>
</servlet-mapping>
Your provider classes should look like this:
package your.package.name;
#Path("/test")
public class StatsServlet {
#PUT
#Produces(MediaType.TEXT_HTML)
public String doPutHtml() {
return "Hello!";
}
}

I traced it down and pickypg is correct. I was able to get this to work with TomEE 1.5.2 using the tomee-maven-plugin. I haven't figured out exactly, but this problem occurs after the jersey figures out there is a bean manager at java:comp/BeanManager and tries to lookup the context.
<plugin>
<groupId>org.apache.openejb.maven</groupId>
<artifactId>tomee-maven-plugin</artifactId>
<version>1.0.1</version>
<configuration>
<tomeeHttpPort>${http.port}</tomeeHttpPort>
<tomeeVersion>1.5.2</tomeeVersion>
<args>-Dcom.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager=true</args>
</configuration>
</plugin>
Here are the excerts of jersey where it is running into the issue.
public CDIComponentProviderFactory(Object bm, ResourceConfig rc, WebApplication wa) {
beanManager = (BeanManager)bm;
// work around proxying bug in Weld
if (CDIExtension.lookupExtensionInBeanManager) {
extension = Utils.getInstance(beanManager, CDIExtension.class);
}
else {
// NOTE THIS IS WHAT IS BEING EXECUTED WHEN FLAG IS SET TO FALSE
extension = CDIExtension.getInitializedExtension();
}
extension.setWebApplication(wa);
extension.setResourceConfig(rc);
}
/*
* Returns the instance of CDIExtension that was initialized previously in this same thread, if any.
*/
public static CDIExtension getInitializedExtension() {
try {
InitialContext ic = InitialContextHelper.getInitialContext();
if (ic == null) {
throw new RuntimeException();
}
return (CDIExtension)lookupJerseyConfigJNDIContext(ic).lookup(JNDI_CDIEXTENSION_NAME);
} catch (NamingException ex) {
throw new RuntimeException(ex);
}
}
...
/*
* Setting this system property to "true" will force use of the BeanManager to look up the bean for the active CDIExtension,
* rather than going through a thread local.
*/
private static final String LOOKUP_EXTENSION_IN_BEAN_MANAGER_SYSTEM_PROPERTY = "com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager";
public static final boolean lookupExtensionInBeanManager = getLookupExtensionInBeanManager();
private static boolean getLookupExtensionInBeanManager() {
return Boolean.parseBoolean(System.getProperty(LOOKUP_EXTENSION_IN_BEAN_MANAGER_SYSTEM_PROPERTY, "false"));
}

I was able to do that and if someone is looking for the solution that's what i did
This what i did:
* i’m using NetBeans 7.3.1
* I added the following lines in Tomee\conf\system.properties
–>com.sun.jersey.server.impl.cdi.lookupExtensionInBeanManager= true
* I added jersey libraries from NetBeans that’s all
* Note that the libraries are in WEB-INF\lib of my apps
* Additional information i was even able to use Mojarra for JSF if someone is interested i can tell you how

CXF + SSL + WebLogic 9.10

I im developing a web application, its a servlet which basically acts as a front end for a web service, im using CXF for the web service client, the application is running on a WebLogic 9.10 server, every thing was working ok until the project owner decided to add ssl supprt, no big problem, since im using cxf whitout spring, i managed to configure the TLS parameters in the http conduit of the service client,also configured a keystore whit the server key, ca root certificate and a client certificate, tested under a development tomcat instance and worked fine.
Problems started when redeployed the app to the weblogic server again and started getting weird errors, first one was:
java.lang.ClassCastException: com.sun.xml.ws.client.sei.SEIStub cannot be cast to org.apache.cxf.frontend.ClientProxy
at org.apache.cxf.frontend.ClientProxy.getClient
then i realized than weblogic was loading its own implementation of JAX-WS, ok no probelm, just added a weblogic.xml whit "prefer-web-inf-classes" set to true, redeployed and now i got this exception:
java.lang.LinkageError: loader constraint violation: when resolving method "javax.xml.ws.Service.<init>(Ljava/net/URL;Ljavax/xml/namespace/QName;)V" the class loader (instance of weblogic/utils/classloaders/ChangeAwareClassLoader) of the current class, com/adinfi/imgsvc/cm/service/CMBGenericWebServiceService, and the class loader (instance of <bootloader>) for resolved class, javax/xml/ws/Service, have different Class objects for the type javax/xml/namespace/QName used in the signature
That one got me, i thought something was wrong whit the class path,so i started removing jars from the application and still got some more linkage errors, last one i got is this:
java.lang.LinkageError: loader constraint violation: loader (instance of <bootloader>) previously initiated loading for a different type with name "org/w3c/dom/UserDataHandler"
and this is how the "Web-Inf/lib/" directory of my application looks like now:
classes12.jar
classes12.zip
common.jar
common.resources.jar
commons-beanutils-1.8.0.jar
commons-discovery.jar
commons-logging-1.1.1.jar
commons-logging-api.jar
commons-logging-api-1.1.1.jar
cxf-2.2.5.jar
log4j-1.2.8.jar
ras.jar
runtimefw.jar
wsdl4j-1.6.2.jar
wss4j-1.5.8.jar
xalan-2.7.1.jar
xml-resolver-1.2.jar
XmlSchema-1.4.5.jar
xmlsec-1.4.3.jar
Any idea what im doing wrong? thanks in advance

Rollback the prefer-web-inf-classes stuff and follow the WebLogic specific instructions from the Application Server Specific Configuration Guide of CXF's documentation.
More precisely, provide a weblogic-application.xml as explained in the second option Pack war in an ear, deploy the ear with weblogic-application.xml with the following content:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90">
<application-param>
<param-name>webapp.encoding.default</param-name>
<param-value>UTF-8</param-value>
</application-param>
<prefer-application-packages>
<package-name>javax.jws.*</package-name>
</prefer-application-packages>
</weblogic-application>
Follow the additional steps of this post if required.

I am not sure to remember how I solved it.
I think the issue disappeared after removing the import of stax-api in my pom.xml file.
More precisely, in my case I had to exclude it from poi-ooxml.
<dependency>
<groupId>org.apache.poi</groupId>
<artifactId>poi-ooxml</artifactId>
<version>3.9</version>
<exclusions>
<exclusion>
<groupId>stax</groupId>
<artifactId>stax-api</artifactId>
</exclusion>
</exclusions>
</dependency>

How do I use logback-access in combination with Tomcat 5.5?

I've got several Web apps running on a Tomcat 5.5 server, and I'm working on improving/updating the overall logging system used throughout the system. I already had some success with logback-classic. However, when I try to use logback-access (i.e. access the lbAccessStatus servlet), I get this exception:
exception
javax.servlet.ServletException:
Wrapper cannot find servlet class
ch.qos.logback.access.ViewStatusMessagesServlet
or a class it depends on
org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:433)
...
root cause
java.lang.ClassNotFoundException:
ch.qos.logback.access.ViewStatusMessagesServlet
org.apache.catalina.loader.WebappClassLoader.loadClass(WebappClassLoader.java:1386)
...
I have everything set up according to the docs:
common/lib:
logback-classic-0.9.15.jar
logback-core-0.9.15.jar
server/lib:
logback-access-0.9.15.jar
Moving around the libraries doesn't seem to help. logback-classic seems to work fine, it's just logback-access that causes problems.

I've got it working. With maven and logback-classic the jars end in WEB-INF/lib and it works well.
I've seen the same error only when deploying old version of my WAR.
excerpt of dependencies section of my pom.xml
<dependency>
<groupId>org.slf4j</groupId>
<artifactId>slf4j-api</artifactId>
<version>${slf4j.version}</version>
</dependency>
<dependency>
<groupId>ch.qos.logback</groupId>
<artifactId>logback-classic</artifactId>
<version>0.9.21</version>
</dependency>
... and relevant part of my web.xml:
<servlet>
<servlet-name>LogbackViewStatusMessages</servlet-name>
<servlet-class>ch.qos.logback.classic.ViewStatusMessagesServlet</servlet-class>
</servlet>
<!-- see http://localhost:8080/oam-portal-portlets/logs -->
<servlet-mapping>
<servlet-name>LogbackViewStatusMessages</servlet-name>
<url-pattern>/logback</url-pattern>
</servlet-mapping>

I haven't used logback-access with tomcat, yet. I only used it with jetty...
I'd suggest to try the following setup, though:
common/lib:
logback-access-0.9.15.jar
logback-classic-0.9.15.jar
logback-core-0.9.15.jar
server/lib:
logback-access-0.9.15.jar
logback-core-0.9.15.jar
logback-access has logback-core as a dependency. Since you use it both in the server (the Valve) and in your webapp (the ViewStatusMessagesServlet) you should add it to both classpaths.
You could (and should?) also add logback-access, logback-classic and logback-core to your webapp classpath instead of adding it to common/lib, making it available to all webapps.
Hope that helps.

If you put logback-access in common/lib too, so all the jars are there, it should be available everywhere. Have you tried that?
Also logging has been reworked in Tomcat 6. Is upgrading a possibility?