Given I have WebLogic Server Version: 12.1.3.0.0
How can I find with which libraries, jars it ships with?
I'd like to figure out what to specify in weblogic.xml in <prefer-application-packages>, e.g.:
<container-descriptor>
<prefer-web-inf-classes>false</prefer-web-inf-classes>
<prefer-application-packages>
<package-name>org.slf4j.*</package-name>
</prefer-application-packages>
</container-descriptor>
Please use the following app for classloader filtering. Its shipped with weblogic server and available from the adminserver.
http://yourhost:yourport/wls-cat
example:
http://localhost:7001/wls-cat/
Related
I updated from guava 14.0.1 to 15.0 in an application that deploys on WebLogic 12c, and I get a java.lang.NoSuchMethodException during deployment that I've been unable to resolve:
Caused By: java.lang.NoSuchMethodException: com.google.common.base.internal.Finalizer.startFinalizer(java.lang.Class, java.lang.ref.ReferenceQueue, java.lang.ref.PhantomReference)
at java.lang.Class.getMethod(Class.java:1624)
at com.google.common.base.FinalizableReferenceQueue.getStartFinalizer(FinalizableReferenceQueue.java:302)
at com.google.common.base.FinalizableReferenceQueue.<clinit>(FinalizableReferenceQueue.java:90)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:266)
at com.oracle.injection.provider.weld.BasicResourceLoader.classForName(BasicResourceLoader.java:27)
at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:107)
at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:77)
at org.jboss.weld.bootstrap.BeanDeployer.addClasses(BeanDeployer.java:135)
at org.jboss.weld.bootstrap.BeanDeployment.createBeans(BeanDeployment.java:184)
at org.jboss.weld.bootstrap.WeldBootstrap.deployBeans(WeldBootstrap.java:349)
at com.oracle.injection.provider.weld.WeldInjectionContainer.deploy(WeldInjectionContainer.java:99)
at com.oracle.injection.integration.CDIAppDeploymentExtension.initCdi(CDIAppDeploymentExtension.java:68)
at com.oracle.injection.integration.CDIAppDeploymentExtension.activate(CDIAppDeploymentExtension.java:47)
at weblogic.application.internal.flow.AppDeploymentExtensionFlow.activate(AppDeploymentExtensionFlow.java:37)
at weblogic.application.internal.BaseDeployment$2.next(BaseDeployment.java:729)
at weblogic.application.utils.StateMachineDriver.nextState(StateMachineDriver.java:42)
at weblogic.application.internal.BaseDeployment.activate(BaseDeployment.java:258)
at weblogic.application.internal.EarDeployment.activate(EarDeployment.java:61)
at weblogic.application.internal.DeploymentStateChecker.activate(DeploymentStateChecker.java:165)
at weblogic.deploy.internal.targetserver.AppContainerInvoker.activate(AppContainerInvoker.java:80)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.activate(AbstractOperation.java:586)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.activateDeployment(ActivateOperation.java:148)
at weblogic.deploy.internal.targetserver.operations.ActivateOperation.doCommit(ActivateOperation.java:114)
at weblogic.deploy.internal.targetserver.operations.AbstractOperation.commit(AbstractOperation.java:339)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleDeploymentCommit(DeploymentManager.java:846)
at weblogic.deploy.internal.targetserver.DeploymentManager.activateDeploymentList(DeploymentManager.java:1275)
at weblogic.deploy.internal.targetserver.DeploymentManager.handleCommit(DeploymentManager.java:442)
at weblogic.deploy.internal.targetserver.DeploymentServiceDispatcher.commit(DeploymentServiceDispatcher.java:176)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.doCommitCallback(DeploymentReceiverCallbackDeliverer.java:195)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer.access$100(DeploymentReceiverCallbackDeliverer.java:13)
at weblogic.deploy.service.internal.targetserver.DeploymentReceiverCallbackDeliverer$2.run(DeploymentReceiverCallbackDeliverer.java:68)
at weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl.run(SelfTuningWorkManagerImpl.java:550)
at weblogic.work.ExecuteThread.execute(ExecuteThread.java:295)
at weblogic.work.ExecuteThread.run(ExecuteThread.java:254)
I already have been using the WebLogic prefer-application-packages classloader filtering in my weblogic.xml file as described here in order to resolve a runtime conflict in WebLogic 12c as it seems to repackage an older version of the library. This had been working in guava 14.0.1, but does not in 15.0.
As far as I can tell, preferring the com.google.common.* package should include everything. Does this Finalizer class do something special that is happening before the classloader filtering happens, thereby trying to load the old version that appears to have a different API?
Is there an alternative solution to use the guava-15.0.jar packaged with the application instead of what is bundled with the server?
There's an open issue #1527 targeting this problem (Guava 15 cannot be deployed to any JEE6 container) which occured after fixing this one. Please star and / or comment and wait for the fix (comment #33 suggests that version 15.0.1 could be released in near furture).
EDIT:
Meanwhile, the issue was resolved by new maven release:
A note on JEE6 / CDI 1.0
A workaround added in Guava 15.0 to make it compatible with CDI 1.1
(used in JEE7 containers) caused problems for Guava with CDI 1.0 (used
in JEE6 containers).
If you're using Guava in a CDI 1.0 environment, you should use
guava-15.0-cdi1.0.jar instead of the normal Guava jar. In Maven, the
dependency can be specified as:
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>15.0</version>
<classifier>cdi1.0</classifier>
</dependency>
If you want to deploy on both JEE 6 and 7 servers, you must use Guava 13 or wait until 16 is released.
As an aditional information, I landed on this question with a similar problem while upgrading to Weblogic 12c due to a conflit between WL and Guava (have tried with versions 11 and 18 of Guava).
I found the solution to be to explicitly prefer my application's lib. I set this on my weblogic.xml:
<prefer-application-packages>
<package-name>com.google.common</package-name>
</prefer-application-packages>
Look at http://docs.oracle.com/middleware/1212/wls/WLPRG/classloading.htm#WLPRG315 for the reference.
I currrently try to run Docx4j in WebLogic Server 12c. WebLogic Server 12c comes with EclipseLink 2.3.2.
There is a similar Post describing the situation which unfortunately yield no answer.
Docx4j does not work with the JAXB (MOXy) implementation which is part of EclipseLink 2.3.2. I got Docx4j running standalone with EclipseLink 2.5. So I am very confident that using EclipseLink 2.5 with Weblogic Server 12c will solve the issue with Docx4j.
How can I replace the EclipseLink Vesion 2.3.2 the WebLogic Server 12c is running on with EclipseLink Version 2.5?
You can created a shared library in WebLogic to update the version of EclipseLink.
CREATE THE SHARED LIBRARY
EclipseLink25_SharedLibrary.ear
The shared library is an EAR with the following contents
lib/eclipselink.jar
META-INF/application.xml
<application>
<display-name>EclipseLink 2.5 Shared Library</display-name>
<module>
<java></java>
</module>
</application>
META-INF/MANIFEST.MF
Manifest-Version: 1.0
Ant-Version: Apache Ant 1.8.2
Created-By: 1.7.0_04-b21 (Oracle Corporation)
Extension-Name: EclipseLink-2.5.0
Specification-Version: 2.5.0
Implementation-Version: 2.5.0.v20130507
META-INF/weblogic-application.xml
<weblogic-application>
<prefer-application-packages>
<package-name>org.eclipse.persistence.*</package-name>
</prefer-application-packages>
</weblogic-application>
USE THE SHARED LIBRARY
Belowis how you would package your application to use the shared library,
SampleApplication.ear
META-INF/MANIFEST.MF
META-INF/weblogic-application.xml
<?xml version="1.0" encoding="UTF-8"?>
<wls:weblogic-application xmlns:wls="http://xmlns.oracle.com/weblogic/weblogic-application" 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/javaee_5.xsd http://xmlns.oracle.com/weblogic/weblogic-application http://xmlns.oracle.com/weblogic/weblogic-application/1.2/weblogic-application.xsd">
<!--weblogic-version:10.3.4-->
<wls:application-param>
<wls:param-name>webapp.encoding.default</wls:param-name>
<wls:param-value>UTF-8</wls:param-value>
</wls:application-param>
<wls:library-ref>
<wls:library-name>EclipseLink-2.5.0</wls:library-name>
<wls:specification-version>2.5.0</wls:specification-version>
<wls:implementation-version>2.5.0.v20130507</wls:implementation-version>
<wls:exact-match>true</wls:exact-match>
</wls:library-ref>
</wls:weblogic-application>
SampleApplication.war
FOR MORE INFORMATION
http://blog.bdoughan.com/2012/10/updating-eclipselink-in-weblogic.html
The solution provided by Blaise in his Blogpost does not work with WebLogic 12c. The solution to get it working is a minor change to the application.xml by explicitly defining the used library:
<application>
<display-name>EclipseLink 2.5 Shared Library</display-name>
<module>
<java>lib/eclipselink.jar</java>
</module>
</application>
I prefered to switch back to the JAXB RI instead of using the buggy moxy JAXB.
Here is how you can do it:
http://docs.oracle.com/cd/E24329_01/web.1211/e24964/data_types.htm#CIHBHDGI
I used the Methode where the following jar module file is put in the "startWebLogic.cmd":
set PRE_CLASSPATH=$wls_home/modules/databinding.override_1.0.0.0.jar
to have it first in the classpath.
I'm currently trying to upgrade my web application from jboss 5.1 to jboss 7.1.1.Final
In my jboss.xml I have configured some custom ejb timeouts like the following:
<session>
<ejb-name>MSServiceEJB</ejb-name>
<jndi-name>ejb/MSServiceEJB</jndi-name>
<local-jndi-name>ejb/LocalMSServiceEJB</local-jndi-name>
<method-attributes>
<method>
<method-name>*</method-name>
<transaction-timeout>3600</transaction-timeout>
</method>
</method-attributes>
</session>
jboss 7 ignores jboss.xml, where can I specify my ejb 2.1 transaction timeouts?
Per
Source
Replace the jboss.xml deployment descriptor file
The jboss-ejb3.xml deployment descriptor replaces the jboss.xml deployment descriptor to
override and add to the features provided by the Java Enterprise
Edition (EE) defined ejb3-jar.xml deployment descriptor. The new file
is incompatible with jboss.xml, and the jboss.xml is now ignored in
deployments.
You need to create a jboss-ejb3.xml and put the configuration inside it.
It would look something like this:
<assembly-descriptor>
<container-transaction>
<method>
<ejb-name>EJBName</ejb-name>
<method-name>methodName</method-name>
<method-intf>Local</method-intf>
</method>
<tx:trans-timeout>
<tx:timeout>500</tx:timeout>
<tx:unit>Seconds</tx:unit>
</tx:trans-timeout>
</container-transaction>
</assembly-descriptor>
You are using EJB2.x , so it would be better and wise to configure it in ejb-jar.xml
It should be created in META-INF of the EJB jar.
You can specify on the Bean method with #TransactionTimeOut annotation.
#TransactionTimeout(value = 10, unit = TimeUnit.SECONDS)
For detailed description of how to set, please refer here
Maddy
we are planned to migrate the server file which are working in jboss 4.2 to jboss 6.0,
application.xml
http://java.sun.com/xml/ns/j2ee/application_1_4.xsd">
ModuleMenuEar
<ejb>ModuleMenuBean.jar</ejb>
<web>
<web-uri>ModuleMenuWeb.war</web-uri>
<context-root>/ModuleMenuWeb</context-root>
</web>
In jboss 4.2, if is not available it takes as context-root, but if we deploy the same file in jboss 6.0 its throwing error like required context-root, is the any xml confoguration which make jboss 6.0 work like jboss 4.0
IN ejb-jar.xml
<session>
<display-name>ModuleRightsSB</display-name>
<ejb-name>ModuleRightsBean</ejb-name>
<local-home>lrp.settings.modulerights.shared.ModuleRightsLocalHome</local-home>
<local>lrp.settings.modulerights.shared.ModuleRightsLocal</local>
<ejb-class>lrp.settings.modulerights.bean.ModuleRightsBean</ejb-class>
<session-type>Stateless</session-type>
<transaction-type>Container</transaction-type>
<resource-ref>
<res-ref-name>jdbc/ReportDB</res-ref-name>
<jndi-name>java:/REPORTDS</jndi-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
<resource-ref>
<res-ref-name>jdbc/ClientDB</res-ref-name>
<jndi-name>java:/MSSQLDS</jndi-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
</session>
</enterprise-beans>
in some ejb-jar.xml file, we used in ejb -jar.xml file itself , which is working properly in jboss 4.2, if we deploy the same file in jboss 6.0, its throwing error like required res-type, but its already available in ejb-jar.xml file,
Is there any xml configuration can be removed, so that it works without throeing any error,
kindly refer the attachment for more details
kindly help me to resolve this,
thanks in advance,
Vairam S
<jndi-name>java:/MSSQLDS</jndi-name> is not a valid tag for <resource-ref>. Try removing that, then make sure the sub-tags are in the following order:
<res-ref-name>jdbc/ClientDB</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
If that doesn't work, providing your stack trace might be helpful.
As part of our application we are using apache's xerces jaxp parser. When we deploy the application on weblogic 9.2, we are getting the following error.
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.apache.cxf.wsdl.WSDLManager' defined in class path resource [META-INF/cxf/cxf.xml]: Instantiation of bean failed; nested exception is org.springframework.beans.BeanInstantiationException: Could not instantiate bean class [org.apache.cxf.wsdl11.WSDLManagerImpl]: Constructor threw exception; nested exception is java.lang.ClassCastException: org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
As per our analysis, weblogic is trying to to load its own DocumentBuilderFactoryImpl which is present in weblogic.jar instead of apache's xerces.
We tried the following to force the weblogic to load DocumentBuilderFactoryImpl from xerces
i) we have added the following tag into weblogic.xml
<prefer-web-inf-classes>true</prefer-web-inf-classes>
ii) we have put latest versions of xalan in jre/lib/endorced folder. this didn't resolve our problem.
ii) we have added entries in weblogic-application.xml
<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>
<package-name>org.apache.xerces.*</package-name>
<package-name>org.apache.xerces.jaxp.*</package-name>
</prefer-application-packages>
</weblogic-application>
ii)Added the following entry in weblogic-application.xml
<xml>
<parser-factory>
<saxparser-factory>org.apache.xerces.jaxp.SAXParserFactoryImpl</saxparser-factory>
<document-builder-factory>org.apache.xerces.jaxp.DocumentBuilderFactoryImpl</document-builder-factory>
<transformer-factory>org.apache.xalan.processor.TransformerFactoryImpl</transformer-factory>
</parser-factory>
</xml>
iii) Added jaxp.properties to load DocumentBuilderFactoryImpl from xerces to the jre/lib and started the server.In this case, the weblogic didnt start.
iv) Then we started the server first and then copied the jaxp.properties file during the run time when server starts.But no success
None of the above worked for us.
Any help is highly appreciated.
You did so many things that I don't understand the exact status. My advice would be to strictly follow the Application Server Specific Configuration Guide for WebLogic that I've successfully used in the past with WLS 9.2.
<?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>
You'll certainly have to add more packages under prefer-application-packages to setup Weblogic ClassLoader filtering but in the current state of the question, it's impossible to provide a precise answer.
Just in case, you can maybe try to blindly use the weblogic-application.xml from this thread:
<?xml version="1.0" encoding="UTF-8"?>
<weblogic-application xmlns="http://www.bea.com/ns/weblogic/90">
<xml>
<parser-factory>
<saxparser-factory>
org.apache.xerces.jaxp.SAXParserFactoryImpl
</saxparser-factory>
<document-builder-factory>
org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
</document-builder-factory>
<transformer-factory>
org.apache.xalan.processor.TransformerFactoryImpl
</transformer-factory>
</parser-factory>
</xml>
<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>
<package-name>org.apache.xerces.*</package-name>
<package-name>org.apache.xalan.*</package-name>
</prefer-application-packages>
</weblogic-application>
But this is a shot in the dark.
You could try forcing the use of the specified document builder factory as a command line option:
-Djavax.xml.parsers.DocumentBuilderFactory=org.apache.xerces.jaxp.DocumentBuilderFactoryImpl
This is assuming that you have the required Xerces builder factory class in your classpath.
In general, you shouldn't use a separate xerces.jar anymore, unless required by some legacy code. The Xerces parser classes come with the JRE, the package names just start with com.sun.org.apache instead of org.apache. You could try also
-Djavax.xml.parsers.DocumentBuilderFactory=com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderFactoryImpl
and remove xerces.jar from your classpath altogether (this is what we did on WLS 10.3 and Java 1.6).
I managed to resolve the issue DocumentBuilderFactory not found with simple solution.
Try to copy xercesImpl.jar to the domain specific lib directory on weblogic MyDomain\servers\MyServer\lib.
In my case the problem was that i made a dependency on commons-digester which in turn used another version of xerces (that caused the conflict). So you can review your dependencies in case some other version of xerces was transitively included.