I'm writing a Spring web application deployed to a WebLogic 10.3.3 server. I've tried to enable logging as described by the Oracle documentation here: http://docs.oracle.com/cd/E14571_01/web.1111/e13739/config_logs.htm#WLLOG154
Both commons-logging-1.1.1.jar and com.bea.core.weblogic.commons.logging_1.4.0.0.jar are placed in the lib folder of the WebLogic domain, and I'm attempting to initialize the logger exactly as described in the Oracle example. I see the following exception in the server console:
Caused by: org.apache.commons.logging.LogConfigurationException: The chosen
LogFactory implementation does not extend LogFactory. Please check your
configuration. (Caused by java.lang.ClassCastException:weblogic.logging.commons.LogFactoryImpl)
Does anyone know of any possible solutions?
Works for me. Seems like a classloader issue.
Check whether another commons-logging lib is not loaded before application provided commons-logging.
Related
I am trying to do session management using tomcat modules in gemFire. Reference link we used is [https://gemfire.docs.pivotal.io/95/geode/tools_modules/http_session_mgmt/tomcat_installing_the_module.html].
Application server that we are using is tomee 7.0.5. After making the changes mentioned in the link. When i tried to make the server up, we were getting an error "getContainer() method not found in class DeltaSessionManager".There is a module geode-modules-9.5.1.jar provided by gemFire(gfsh Client) which helps for session management. Inside that there is a class DeltaSessionManager which extends another class org.apache.catalina.session.ManagerBase . But the ManagerBase class in catalina.jar inside tomee 7.0.5 doesn't have this method. But when we downloaded tomcat catalina jar separately we were able to see this method. Is there any difference in the approach for tomee.
Any help would be appreciable
Looking at the tomee source code, I suspect tomee 7.0.5 is actually embedding Tomcat 8. In that case, you need to use Tomcat8DeltaSessionManager, which supports Tomcat 8 and above.
Good Morning all,
I have problem while deploying my web app in IBM WAS.
I have spring ws and during the deployment, I get the below error,
Caused by: javax.xml.soap.SOAPException: Unable to create message factory for SOAP: Unable to create SAAJ meta-factorycom.ibm.ws.webservices.engine.soap.SAAJMetaFactoryImpl incompatible with javax.xml.soap.SAAJMetaFactory
at javax.xml.soap.MessageFactory.newInstance(Unknown Source)
at org.springframework.ws.soap.saaj.SaajSoapMessageFactory.afterPropertiesSet(SaajSoapMessageFactory.java:145)
I have packaged the saaj-api 1.3 and saaj impl 1.3 jars in my application and i can see them in the lib folder.
I have set the class loading properties in the WAS to parent last.
Any clue or Where am I going wrong?
I'm using WAS version 7.0.0.11
I added this entry to the MANIFEST file to solve this issue,
DisableIBMJAXWSEngine: true
Hope this helps some one.
I am trying to get an apache camel app using CXF working on WebSphere.
Noticed a number of errors
Caused by: java.lang.IncompatibleClassChangeError: org.apache.neethi.AssertionBuilderFactory
at java.lang.ClassLoader.defineClassImpl(Native Method)
at java.lang.ClassLoader.defineClass(ClassLoader.java:262)
at java.security.SecureClassLoader.defineClass(SecureClassLoader.java:69)
This occurs because the org.apache.neethi classes are loaded from the WAS run-time instead of the neeti3.0.2.jar from WEB-INF/lib
here is the info from class loader:
class load: org.apache.neethi.builders.AssertionBuilder from: file:/D:/Tools/WebSphere/AppServer/plugins/org.apache.axis2.jar
The Web Application config has been changed to use the class loader policy. It is set to Parent Last. Yet this class seems to be using the Parent First Policy.
Is there anything in the CXF package that over-rides this policy?
I noticed that using Axis2 and WAS
http://axis.apache.org/axis2/java/core/docs/app_server.html
Avoiding conflicts with WebSphere's JAX-WS runtime has some additional steps mentioned for Axis2. Is there something similar that is required to get this to work?
Thanks
Manglu
Not specific to Camel, but we are dealing with a similar issue.
1) You can use an isolated shared library if you want. This seems to fix the classloader from pulling in these other libraries via OSGi. This solution isn't for everyone.
2) When setting an app that PARENT_LAST, make sure you're doing it in the correct place. If you have jars inside your wars, then you'll have to set PARENT_LAST on the WAR modules, not the application. In the WAS console> Applications > Application Type > websphere enterprise applications> MyEAR > manage Modules > MyWar > Change the "Class loader order" and make it "parent last"
3) After you make your changes, you can export the ear file. In the ear, there is a file META-INF/ibmconfig/cells/defaultCell/applications/defaultApp/deployments/defaultApp/deployment.xml that has this config. For maven ear's, you can put this into src/main/application for it to be packaged up with the ear.
Hope that this helps. Good luck.
We are discussing a similar topic at the Camel mailing lists. I suggest to take a look there: http://camel.465427.n5.nabble.com/camel-cxf-in-WebSphere-without-geronimo-jetty-depdendencies-possible-tp5726490.html
When i am running my application it give me this exception:-
Exception sending context initialized event to listener instance of class
org.springframework.web.util.Log4jConfigListener
java.lang.ExceptionInInitializerError
But this problem is not permanent. If i remove the log4j entries from web.xml and restart p.c and then again add log4j entries and start the server, then the application works fine.
I noticed that when the application is deployed and when i undeploy and again deploy the same application, this problem emerge.
Please help me ........ i am facing this problem from 3 months...
I just investigated it a little and have found the similar issue:
It causes when multiple jar file for log4j is available to application.
From web/application server and from build path(Included from other
path rather than web/application server)
You can see the entire thread here:
http://www.coderanch.com/t/551933/Spring/Exception-sending-context-initialized-event
looks like this is your problem.
I am currently working on a portlet that is using the commons-collections jar file and am getting a NoSuchMethodError. To resolve this issue I need to change the classloader of my WAR file from PARENT_FIRST to PARENT_LAST (in the application.xml file).
However, when I do this my portlet will not launch and when I log into the console it displays the message "The portlet is temporarily disabled". If I change the classloader back to PARENT_FIRST then it will launch again but then I get the NoSuchMethodError.
Does anybody have any suggestions on how to fix this issue ?
I am not sure how, but today I started getting error messages in the logs when I was getting "The portlet is temporarily disabled". I was getting a java.lang.LinkageError which was down to the fact that I had the servlet-api-2.5.jar and a jaxb jar which was conflicting with webshpere j2ee.jar. Once I removed these dependencies and set the classloader to PARENT_LAST, it seems to work properly. It seems that a lot of people face similar issues. The link below is also useful http://forum.springsource.org/showthread.php?33663-dispatcher-servlet-quot-not-a-servlet-class-quot-in-websphere
#MTH,
please try adding commons-collections as a shared library. See here for an example on how others have used shared library support [1]. That will give you the steps, just do it for the jars that you need to override/replace from WAS's classloader
[1] http://portals.apache.org/jetspeed-2/deployguide/deploying-jetspeed-to-websphere.html#section_4_2
thanks,
dims
You haven't provided any logs... but still, one of the most important things to look out for when setting your application to run PARENT_LAST is that your application isn't bundled with any system-level classes that may conflict with the ones provided by WebSphere Portal. For example, classes that pertain to the Portlet specification or the JavaEE specification.