I have a project a-conf with src/main/resources/logback/conf/a/CommonAppenders.xml file:
<included>
<appender name="FILE" class="FileAppender" />
</included>
Also i have another project a-runable with logback.xml config which imports CommonAppenders.xml:
<configuration>
<!-- this is classpath import -->
<include resource="logback/conf/a/CommonAppenders.xml" />
...
</configuration>
I can compile a-runable in standalone jar with all dependencies (a-conf is one of them) included or as an OSGi bundle. When i run standalone app everything is ok - log files appears as specified in CommonAppenders.xml. But when i run OSGi container no log files are created. I think logback just cannot include resource from classpath because every bundle in OSGi container has its own classloaders (logback uses ClassLoader.getResource() to include file).
I've checked Export-Package: logback.conf.a in a-conf.jar/META-INF/MANIFEST.MF (this is done by maven bundlor plug-in) - it is ok. Added Import-Package: logback.conf.a to a-runable with no effect.
I have no ideas what can i do (no code to change, just configs). Any help would be welcome.
P.S. I've found similar problem here, but logback.xml is already in classpath and its own appenders works fine. Also i do not have any FileNotFoundExceptions in existing logs.
By default, I believe Logback's startup errors are simply dropped if you don't configure a listener (but I may be remembering wrong). The key is likely that a-conf needs to be a Fragment of the bundle that contains logback.jar. That's what I've done for my bundle that has some homebrew appenders.
If you want to see a setup where Logback is pre-configured to output its startup errors to the OSGi container, take a look at Pax-Logger 1.7 - https://github.com/ops4j/org.ops4j.pax.logging/tree/master/pax-logging-logback
Related
I have a Keycloak EAR module, deployed on Keycloak 11.0. In my EAR module I want to use log4j2 logging library with slf4j. I successfully accomplished this by adding the following dependencies in the pom directly: log4j-slf4j-impl, log4j-api & log4j-core.
Wildfly logging dependencies are excluded by setting add-logging-api-dependencies to false. log4j2.xml is specified outside the packaged EAR and is referenced with log4j.configurationFile system property.
Now the problem. I also want Keycloak to use log4j2 but I cannot get this to work. Keycloak is using Jboss Logging wrapper which always picks up JbossLogManager no matter which logging provider I set - I always get either ClassNotFoundException or NoClassDefFoundError.
I realize there is a classpath problem but I am out of ideas at this point. I tried creating log4j-slf4j-impl, log4j-api & log4j-core Wildfly modules with the following command but I still get the same error.
./jboss-cli.sh --command="module add --name=org.apache.logging.log4j.log4j-api --resources=/Users/jernej/log4j-api-2.13.3.jar"
If I understand correctly, log4j2 should be in the classpath on Wildfly startup (when searching for LoggerProvider) and Jboss Logging findProvider method should return Log4j2LoggerProvider if modules are correctly added? How can I accomplished this?
Suppose I want to use log4j2 appender, located in separate library. If I add this library as a Wildfly module this log4j2 appender can then be used by other deployments as well - e.g. keycloak-server.war?
Adding a library as a module may not necessary makes it available to your application. Have you defined the dependency to that module in the jboss-deployment-structure.xml in the META-INF folder of your ear file? Something like this:
<?xml version="1.0" encoding="UTF-8"?>
<jboss-deployment-structure xmlns="urn:jboss:deployment-structure:1.3"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:jboss:deployment-structure:1.3 http://www.jboss.org/schema/jbossas/jboss-deployment-structure-1_3.xsd">
<deployment>
<dependencies>
<module name="org.apache.logging.log4j.log4j-api" export="true"/>
</dependencies>
</deployment>
</jboss-deployment-structure>
I have 7 different WARs deployed to the same WildFly / JBoss server. Each WAR is identical in core design and Log4j configuration. Each WAR generates its own log file via its own individual custom log4j.xml. Each log is written to an individual folders.
1 of the 7 deployed WARs keeps getting the logging hijacked by WildFly's console.log. It will begin writing to its own log for 5-10 lines during initialization, then stop; the rest of the logging will be directed to the console.log.
If I re-install the WAR after this happens, it will write to both its own individual log and the WildFly console.log. If I restart WildFly, it will behave as described previously - begin logging to its own log, then continue on console.log.
The only thing unique about this WAR vs the other 6 is that this project uses JAXB; none of the other WARs use JAXB.
Is there some sort of unknown interaction between JAXB and Log4j and WildFly that might be causing this? I suspect, but cannot yet prove, the hijack is happening after the classes using JAXB are loaded by the ClassLoader.
jboss-7.2.0.Final , jdk-7u80x64, Log4j-1.2.13.jar
You may need to try move the logging.properties file to the WAR/WEB-INF/classes. I guess old Jboss EAP 6.4, There may have been a bug where it fails to look in the WAR/WEB-INF directory.
If that doesn't work you have to turn on trace logging for org.jboss.as.logging which should show the logging.properties file is found in your deployment.
The following CLI command will enable trace logging to see the details of what the logging subsystem is doing.
/subsystem=logging/logger=org.jboss.as.logging:add(level=TRACE)
If you want to see these log messages on the console you'll need to enable trace logging for the console tool.
/subsystem=logging/console-handler=CONSOLE:write-attribute(name=level, value=TRACE)
resources:
sect-per-deployment_logging
Logging Configuration
Solved by excluding the log4j module from the application via /WEB-INF/jboss-deployment-structure.xml
<jboss-deployment-structure>
<deployment>
<exclusions>
<module name="org.apache.log4j" />
</exclusions>
</deployment>
</jboss-deployment-structure>
With Weblogic 11g I have done the following:
1 Created log4j.xml file where I created a new appender:
<appender name="WEBLOGIC" class="weblogic.logging.log4j.ServerLoggingAppender">
<param name="Threshold" value="ERROR"/>
</appender>
<root>
<priority value="WARN"/>
<appender-ref ref="CONSOLE"/>
<appender-ref ref="FILE"/>
<appender-ref ref="WEBLOGIC"/>
</root>
2 Updated the ${DOMAIN_HOME}/bin/setDomainEnv.sh script with these changes:
LOG4J_CONFIG_FILE="${DOMAIN_HOME}/config/log4j.xml"
if [ "${LOG4J_CONFIG_FILE}" != "" ] ; then
JAVA_PROPERTIES="${JAVA_PROPERTIES} Dlog4j.configuration=file:${LOG4J_CONFIG_FILE}"
export JAVA_PROPERTIES
fi
JAVA_OPTIONS="${JAVA_OPTIONS} ${JAVA_PROPERTIES} -Dweblogic.log.Log4jLoggingEnabled=true -Dwlw.iterativeDev=${iterativeDevFlag} -Dwlw.testConsole=${testConsoleFlag} -Dwlw.logErrorsToConsole=${logErrorsToConsoleFlag}"
3 Copied the log4j jars to the domain/lib
cp ./wlserver_10.3/server/lib/wllog4j.jar user_projects/domains/my_domain/lib/
cp ./wlserver_10.3/server/lib/consoleapp/APP-INF/lib/log4j-1.2.8.jar user_projects/domains/my_domain/lib/
4 Starts the AdminServer, but I get this error:
java.lang.ClassCastException:
weblogic.logging.log4j.ServerLoggingAppender cannot be cast to
org.apache.log4j.Appender
Keep step 1 and remove changes done in other steps.
Now copy the log4j.xml to $DOMAIN_HOME/lib folder. This will keep your log4j.xml in the server's classpath and the server will use this log4j.xml as its log4j configuration. No additional changes are required.
In setDomainEnv.xml file, please add the set log4j.xml location as below:
set LOG4J_CONFIG_FILE=C:\bea\user_projects\domains\dev\lib\log4j.xml
if NOT "%LOG4J_CONFIG_FILE%"=="" (
set JAVA_PROPERTIES=%JAVA_PROPERTIES% -Dlog4j.configuration=file:%LOG4J_CONFIG_FILE%
)
What you have to see is if despite the warning that you get, if the ServerLogging is effectively not working on your appliction on your domain.
Probably not even there since you are only copying the log4j to the domain/lib folder but not the wllog4j.jar.
So your setup looks like is doomed not to work in any case.
To me, It looks to me that you are undergoing Class Loader Vodoo Messup.
(1) You set a global log4j properties file for the entire app server.
(2) it looks like weblogic console app is itself a ear and it bundles its own LOG4J implementation library, which you are copying into your domain.
When the console app runs, it must for sure make use of Log4j and the class loader loading the Log4j Appender definition is most likely a level lower than the class loader that knows about the ServerLoggin bridge adapter.
I am beting its for reason like this that weblogic is geting rid of LOG4j in future gnerations of the product.
They have too many class loader issues - JUL logging you have the APP class loader behind the core classes - such as Handlers/Adapters.
Anyway.
(3) When weblogic runs, namley when it bootstraps the console it probably runs some sort class loader that gives a level of isolation to the libs bundled in the applicaiton and it sees:
Oh! How nice, LOG4j is here, leets initialize it.
Second, LOG4j bootstraps and hits head on your log4j.properties where you put the server logging appender in there - cross cutingly for everybody (including the weblogic application console).
He goes hunting for this library and where does it find it?
One of them, the wllog4j.jar he finds somewhere in the weblogic generic container libraries. While the base core classes of Log4j he finds a level lower in the domain configuration or in the EAR configuraiton of the console applicaiton.
This is not good.
Try the following:
(a) go into the weblogic console app, go to the Meta Inf folder and re-write the weblogi-application.xml
It will have a prefer applicaiton packages that looks like this:
org.apache.log4j.*</package-name--> <---- here I've commented this line.
If you comment the above line, the application class loader will search for log4j libraries in the highest parent that knows about these classes.
So if you put at the same level where your ServerLogger is found you should be fine.
(b) Pug the log4j implementation library at the same level where the wllog4j.jar will be found.
Check if you still get the casting exceptions.
Be very careful when you make server wide cross cuting configurations.
Good luck.
Project setup:
Logging-1.0.jar
contains a Logger.class which uses slf4j/log4j
depends on slf4j-api.jar, slf4j-log4j.jar, log4j.jar
LoggingOSGI-1.0.jar
wraps the logging project
contains an Activator and MANIFEST.MF
lib/ contains logging-1.0.jar, slf4j-api.jar, slf4j-log4j.jar, log4j.jar
jars from lib/ are added to classpath and packages from logging-1.0.jar are exported
SomeBundle-1.2.jar
contains an Activator and MANIFEST.MF
has a dependency on LoggingOSGI-1.0.jar
Accessing the Logger class from SomeBundle works, but the logging project can't find the log4j.properties (log4j:WARN No appenders could be found for logger).
Questions:
Where do i have to place the log4j.properties?
Any ideas what i could try? (already tried: different directories, Eclipse-Buddies, -Dlog4j.configuration as VM argument)
Would be an extension point, which tells the logging project the location of the log4j.properties, a good solution?
When I last tried this around six years ago, the solution turned to be to create a fragment bundle with the log4j.properties file, and then to attach that fragment (via the Fragment-Host manifest header) to the bundle that loads the logging library ("Logging-1.0.jar," in your case). It felt like a lot of project structure, build time, and deployment overhead for what seems like such a simple goal.
See section 3.14 of the OSGi Service Platform Core Specification for more detail on fragment bundles.
An alternate idea is to consider using the Configuration Admin Service to designate the path to a logging configuration file on disk, outside of your bundles. That would require augmenting your logging library to look up a configuration (or, better, listen for one) and then pass that configuration through to the logging implementation.
I would also be remiss to not point out the OSGi Log Service, specified in section 101 of the OSGi Service Platform Service Compendium.
To solve my problem i added this code to the Activator of the LoggingOSGI-1.0 which configures log4j. The file path is taken from a System property: -Dlog4j.configuration=path/to/log4j.properties.
Still interested in other approaches or opinions to this solution.
private static final String LOG4J_CONFIG_KEY = "log4j.configuration";
public void start(BundleContext bundleContext) throws Exception {
Activator.context = bundleContext;
if (System.getProperties().containsKey(LOG4J_CONFIG_KEY)) {
String file = System.getProperties().getProperty(LOG4J_CONFIG_KEY);
PropertyConfigurator.configure(file);
}
}
For some applications I use ZK, others Hibernate, other Apache Commons, etc.
I don't want to deploy a 75MB war file, just because it uses lots of libraries.
I don't want to add the libraries to my tomcat lib folder, or nor the classpath to it's configuration as I may have an old application using library x.1 and another application using library x.2
For this reason, it would be great to have something in the web.xml or context.xml where I say something like:
<classpath>/usr/local/tomcat/custom-libs/zk-5.0.4</classpath>
Note: The above is pseudo-code
From Tomcat 7 there is no mention of not being able to use the VirtualWebappLoader in production. I tried it and it works like a dream. Simply add the following to META-INF/context.xml:
<?xml version="1.0" encoding="UTF-8"?>
<Context antiJARLocking="true" path="/websandbox">
<Loader className="org.apache.catalina.loader.VirtualWebappLoader"
virtualClasspath="/usr/.../*.jar;/usr/.../*.jar"/>
</Context>
In Netbeans, under packaging, I just untick all the packages, taking the .war size down to nothing, make sure the dependencies are in the correct folders on the server and upload. Yey! No more 100 MB WAR file.
Addition #Spider answer.
Tomcat Context hold Loader element. According to docs deployment descriptor (what in <Context> tag) can be placed in:
$CATALINA_BASE/conf/server.xml - bad - require server restarts in order to reread config
$CATALINA_BASE/conf/context.xml - bad - shared across all applications
$CATALINA_BASE/work/$APP.war:/META-INF/context.xml - bad - require repackaging in order to change config
$CATALINA_BASE/work/[enginename]/[hostname]/$APP/META-INF/context.xml - nice, but see last option!!
$CATALINA_BASE/webapps/$APP/META-INF/context.xml - nice, but see last option!!
$CATALINA_BASE/conf/[enginename]/[hostname]/$APP.xml - best - completely out of application and automatically scanned for changes!!!
Here my config which demonstrate how to use development version of project files out of $CATALINA_BASE hierarchy (note that I place this file into src/test/resources dir and intruct Maven to preprocess ${basedir} placeholders through pom.xml <filtering>true</filtering> so after build in new environment I copy it to $CATALINA_BASE/conf/Catalina/localhost/$APP.xml):
<Context docBase="${basedir}/src/main/webapp"
reloadable="true">
<!-- http://tomcat.apache.org/tomcat-7.0-doc/config/context.html -->
<Resources className="org.apache.naming.resources.VirtualDirContext"
extraResourcePaths="/WEB-INF/classes=${basedir}/target/classes,/WEB-INF/lib=${basedir}/target/${project.build.finalName}/WEB-INF/lib"/>
<Loader className="org.apache.catalina.loader.VirtualWebappLoader"
virtualClasspath="${basedir}/target/classes;${basedir}/target/${project.build.finalName}/WEB-INF/lib"/>
<JarScanner scanAllDirectories="true"/>
<!-- Use development version of JS/CSS files. -->
<Parameter name="min" value="dev"/>
<Environment name="app.devel.ldap" value="USER" type="java.lang.String" override="true"/>
<Environment name="app.devel.permitAll" value="true" type="java.lang.String" override="true"/>
</Context>
UPDATE Tomcat 8 change syntax for <Resources> and <Loader> elements, corresponding part now look like:
<Resources>
<PostResources className="org.apache.catalina.webresources.DirResourceSet"
webAppMount="/WEB-INF/classes" base="${basedir}/target/classes" />
<PostResources className="org.apache.catalina.webresources.DirResourceSet"
webAppMount="/WEB-INF/lib" base="${basedir}/target/${project.build.finalName}/WEB-INF/lib" />
</Resources>
Another a bit hacky alternative.
You can write a 5-6 line custom class loader which derives from urlclassloader, and simply adds your classpath jars using addUrl() method.
Then set it as the context class loader of the thread in your application code.
Thread.setContextClassLoader(new CustomClassloader(path, parentClassLoader)
where parent class loader typically is
Thread.getContextClassloader()
This is what the META-INF/context.xml file can be used for. You defined your own WebappLoader, which loads classes for your particular webapp. This is the reference I used: http://tomcat.apache.org/tomcat-5.5-doc/config/loader.html (Edit: for Tomcat 6: http://tomcat.apache.org/tomcat-6.0-doc/config/loader.html, for Tomcat 7: http://tomcat.apache.org/tomcat-7.0-doc/config/loader.html)
Also this fellow here seems to post a solution to your exact problem (example included): http://java.dzone.com/articles/extending-tomcat-webapploader