Log4j Class missing on Weblogic - log4j

I have deployed a war file on Oracle Weblogic. War files contain all the required libraries in WEB-INF/lib. But whenever I am trying to visit my webpage, it gives error of
java.lang.NoClassDefFoundError: org/apache/log4j/Logger.

try adding to weblogic.xml :
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
(Although this may cause secondary issues with JSF jar's.)

The problem is resolved. One of my custom library using log4j, that one was not able to find log4j. So I created the jar including log4j and its working.

Related

Multiple JSF related files in Weblogic modules folder

I have recently installed the WebLogic 12.1.3 on my local windows 10 desktop. Created a very small webapp and it ran fine until I added the beans.xml.
Adding the beans.xml and starting the server, I get the error : weblogic.management.DeploymentException: java.lang.NoSuchMethodError: com.sun.faces.util.Util.isCdiOneOneOrGreater()Z
I could sort of understand it is something related to a mismatch in JSF versions. Then, I started searching and stumbled upon this beautiful answer from BalusC.
How to find out the current version of Mojarra which my WebLogic is using?
The above answer says "Another way would be to explore the JSF module in /wlserver/modules folder of WebLogic installation. In my 12c installation, the filename says glassfish.jsf_1.0.0.0_2-1-20.jar, which in turn identifies Mojarra 2.1.20".
So I checked to see what is there in my modules folder and I got more than 1 jsf jar. My question (preferably to BalusC :-) but also to anyone who can help) is
- if it is fine or not to have multiple JSF related jars in the modules folder.
- if this multiple JSF jars is the reason for the error ?
- if I can clean up (manually delete) files in this "modules" folder to have one version of JSF related files ?
Note : All these stuff came out of the box with the 12.1.3 installation.
JSF related files found in my "\wlserver\modules" folder
glassfish.jsf_1.2.0.0_1-2-15.jar
glassfish.jsf_2.0.0.0_2-1-20.jar
javax.jsf_1.4.0.0_1-2.jar
weblogic.server.modules.jsf_12.1.3.0.jar
weblogic.server.modules.jsf2.0_12.1.3.0.jar
weblogic.server.merge.modules_12.1.3.0.xml
weblogic.server.modules.extra_12.1.3.0.xml
weblogic.server.modules.jsf_12.1.3.0.xml
weblogic.server.modules.jsf2.0_12.1.3.0.xml
Thanks a lot in advance.
Using JSF and JSTL With Web Applications:
https://docs.oracle.com/middleware/1213/wls/WBAPP/configurejsfandjtsl.htm#WBAPP197
it will depend if you are embedding the JSF jar's.
I think you need to upgrade JSF, embedding the jars and using Filtering Classloading.
<prefer-application-packages>
<package-name>javax.faces.*</package-name>
<package-name>com.sun.faces.*</package-name>
<package-name>com.bea.faces.*</package-name>
</prefer-application-packages>
<prefer-application-resources>
<resource-name>javax.faces.*</resource-name>
<resource-name>com.sun.faces.*</resource-name>
<resource-name>com.bea.faces.*</resource-name>
<resource-name>META-INF/services/javax.servlet.ServletContainerInitializer</resource-name>
<resource-name>META-INF/services/com.sun.faces.*</resource-name>
</prefer-application-resources>
It looks similar (jboss) to: java.lang.NoSuchMethodError: com.sun.faces.util.Util.isCdiOneOneOrGreater()Z

Apache Karaf Deploying .War File

My purpose is to run a JSF application on OSGI Framework. So, I am trying to deploy a WAR file to a servlet container for OSGi web applications, called PAX-WEB. I have a proper working JSF implementation working on WildFly 8.0 application server. I succesfully created OSGi-ified WAR file from this application. When I try to deploy it into PAX-WEB using Maven the following error occurs:
missing requirement: javax.servlet.annotation
I have these JARs in /lib folder of my application: jsf-api-2.1.7, jsf-impl-2.1.7, jsp-api-2.1, jstl-1.2. When I add javax.servlet-api-3.0.1.jar to my WAR file and re-deploy it, this time the following error occurs:
javax.faces.webapp.FacesServlet cannot be cast to javax.servlet.Servlet
With this error, I can run my JSF page, but it is not displaying JSF tags.
You're mixing two issues here.
One, your framework setup is missing the servlet classes. So in that case I propose to use the pax-web-jetty-bundle. It's an uber bundle and also contains and exports the servlet classes. In that case make sure you don't have the servlet jars in your framework setup available. Btw. taking a look at the samples and Integration tests of Pax Web itself helps already to understand which libraries are needed.
The second issue you are facing is an issue of adding the servlet classes to the war, this is per OSGi and servlet spec forbidden to do.
So without any further knowledge of your scenario you might be better of with using the Apache Karaf server (it uses Pax Web), cause there all infrastructure bundles are already included and known to work together.
One more thing, you get more and better feedback at the ops4j mailinglist.

CQ5.6.1- Log4j in Osgi bundle not detecting

I am using a jar file given by my client in CQ5.6.1. Some classes in the jar file requires log4j. So I created a Osgi bundle having the client jar and log4j jar files using Eclipse. I installed this into the Osgi Bundles of CQ and activated the bundle. The class from the client jar is correctly invoked from my components jsp, but the client jar is not able to locate the log4j classes. I am getting the error java.lang.ClassNotFoundException: org.apache.log4j.PropertyConfigurator not found. I also tried putting the log4j jar into the install folder under my app\ in CQ, but that also didn't help. I searched in google but couldn't find a suitable solution yet. Any help to resolve is highly appreciated. Thank you.
Your log4j bundle needs to export the org.apache.log4j package, and the client bundle needs to import it. Sling scripts see all exported packages.
You can use the OSGi console at /system/console/bundles to verify that those exports and imports are correct, the client bundle's status page should show that it imports the package from the log4j bundle.
If the exports are correct, the cause might also be some log4j or client code loading the PropertyConfigurator using a thread context class loader (TCCL) or another mechanism that does not play well with OSGi. If it's TCCL you can work around the issues by setting that TCCL yourself around code that loads the PropertyConfigurator.
CQ does provide the slf4j logging APIs out of the box, so if you can convince your client to switch to those that's probably easier.

Why log4J not working after adding apache CXF?

I have developed small web application using JSF, and i add log4j to handle logging. Everything works perfectly until i implement add web service in my web application. After implement webservice using apache CXF I'm not getting any logs in my log file, but can get logs in eclipse console. I don't know why, it behave like that? My log file simply show messages like
i'm using jdk1.5, log4j 1.2.15 and CXF 2.6.11. Also i was tried some solutions from apache to use log4j instead of cxf default logger. please refer http://cxf.apache.org/docs/debugging-and-logging.html#DebuggingandLogging-LoggingMessages
But recommended solutions are not worked for me. How can i solve this issue?
It is possible that CXF introduces another log mechanism which means adds a yet another logging mechanism, or the imported versions of slf4j/log4j are not compatible.
I would recommend you to check the CXF pom file, and exclude all the log4j/slf4j jar files.
As #Arash said, remove log4j from classpath (if present). Also add the file META-INF/cxf/org.apache.cxf.Logger to the classpath with the following content:
org.apache.cxf.common.logging.Slf4jLogger
Reference: Using SLF4J Instead of java.util.logging
Problem was solved by removing slf4j-jdk14.jar from CXF. Actually Problem is "Class path contains multiple SLF4J bindings". So i removed CXF log4j binding. Now it's working perfectly. Thanks for all.

tomahawk jar not getting loaded weblogic portal 10.3

I have made a jsf 1.1 portlet in weblogic 10.3, but in one scenario I need tomahawk library help. I just dropped the jar file and supporting ones in lib folder in WEB-INF in my portal application, but when I hit the url it gives me error of NoClassdef..... exception for classes in tomahawk jar and jsp compilation fails.
I am new to weblogic, I'll really appreciate if someoe can suggest what I might be doing wrong.
The setup is that whole application goes as ear. Ear contains app-inf and weblogic specific xml files, main portal web application goes as war inside this ear. I am using workshop that ships with weblogic portal 10.3. Well this project was migrated from weblogic portal 9.3.
Note: I dont want to but this jar in domain/lib, when I did so I dont know why it loaded my application and all the class defined in servlet startup with load-on-startups got fired well before time and none of the classes were found by server.
Jsf libraries currently used are in shared mode.
java.lang.NoClassDefFoundError means the runtime version of the class in the classpath is not the same as that at compile time.
Note: it's not a ClassNotFoundException.
Your problem is in fact multiple versions of the class being found.
Also, JSF 1.2 libraries are bundled with Weblogic server, so it can cause this exception if one of those classes is again added into the WEB-INF/lib. Which is the exact class on which the error is thrown, do you have multiple versions of Tomahawk lying around in WEB-INF and domain/lib?
Remove the extras and keep one in WEB-INF/lib only.
Update:
The docs state that Separate JSF 1.2 and JSTL 1.2 JAR files and implementation JAR files are also provided in the WL_HOME/server/lib/api.jar file.
Check for that class javax/faces/webapp/UIComponentELTag in this jar.
I still think you should use the weblogic.xml setting to force the WEB-INF/lib class to get loaded in preference to that in server/lib with
<container-descriptor>
<prefer-web-inf-classes>true</prefer-web-inf-classes>
</container-descriptor>
Being new to weblogic and infrastructure I messed up with different versions. Figured out it was just because of incompatible jars.

Resources