Issues
2 of 2
Lots of RSF apps wrongly bundle log4j in the webapp
Fixed
Description
Created February 2, 2010 at 5:15 AM
Updated March 27, 2013 at 4:47 PM
Resolved March 9, 2012 at 1:06 AM
Activity
Earle NietzelMarch 27, 2013 at 4:47 PM
RSF is already discouraged and we are in the future!
David AdamsMay 31, 2011 at 8:13 AM
Given that RSF has languished for almost three years, it seems like the maint team or someone needs to take ownership of these RSF templates, or we need to discourage the use of RSF in the future. Overlay hacks are a band-aid over the real problem here: RSF is essential to many parts of Sakai, but is unmaintained.
Matthew BuckettMay 31, 2011 at 3:51 AM
This affects all Sakai versions as far as I'm aware.
Jean-François LévêqueMay 31, 2011 at 1:26 AM
Is it still an issue with 2.7 or 2.8.0?
Matthew BuckettFebruary 6, 2010 at 12:55 PM
The patch is for a tool that uses RSF and not for the RSF template artifact itself.
Summary:
On our 2.6.x build it seems that most RSF based tools include a copy of Log4J in their webapp. This doesn't have major consequences for most deployments.
Background:
I was wanting to add an custom PatternLayout for log4j to our build. I added the code to the kernel (kernel-common, which gets deployed to tomcat common) and rebuild and re-deployed, only to find at startup when I referenced this new layout in our configuration I would get a stack trace from some webapps:
log4j:ERROR Could not create the Layout. Reported error follows.
java.lang.ClassCastException: org.sakaiproject.log4j.PatternLayout cannot be cast to org.apache.log4j.Layout
at org.apache.log4j.xml.DOMConfigurator.parseLayout(DOMConfigurator.java:456)
at org.apache.log4j.xml.DOMConfigurator.parseAppender(DOMConfigurator.java:196)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByName(DOMConfigurator.java:150)
at org.apache.log4j.xml.DOMConfigurator.findAppenderByReference(DOMConfigurator.java:163)
at org.apache.log4j.xml.DOMConfigurator.parseChildrenOfLoggerElement(DOMConfigurator.java:425)
at org.apache.log4j.xml.DOMConfigurator.parseRoot(DOMConfigurator.java:394)
at org.apache.log4j.xml.DOMConfigurator.parse(DOMConfigurator.java:829)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:712)
at org.apache.log4j.xml.DOMConfigurator.doConfigure(DOMConfigurator.java:618)
at org.apache.log4j.helpers.OptionConverter.selectAndConfigure(OptionConverter.java:470)
at org.apache.log4j.LogManager.<clinit>(LogManager.java:122)
at org.apache.log4j.Logger.getLogger(Logger.java:104)
at uk.org.ponder.util.Logger.<clinit>(Logger.java:25)
at uk.org.ponder.saxalizer.support.MethodAnalyser.<init>(MethodAnalyser.java:324)
[..snipped..]
This didn't happen when Sakai started but only for some webapps, this lead me to the fact that these webapps were loading their own log4j configuration, it happens that the configuration file was the same for both sakai and the webapps (/common/classes/log4j.xml) but the webapps were loading their own copy of log4j and then they couldn't cast my custom patternlayout as they have different class hierarchies.
An example of a webapp with this problem was site-manage-group-section-role-helper and listing it's dependencies seemed to show everything was fine with the log4j JAR having a provided scope.
[INFO] Building sakai-site-manage-group-section-role-helper
[INFO] task-segment: [dependency:list]
[INFO] ------------------------------------------------------------------------ [INFO] [dependency:list]
[INFO]
[INFO] The following files have been resolved:
[INFO] commons-lang:commons-lang:jar:2.1:provided
[INFO] commons-logging:commons-logging:jar:1.0.4:provided
[INFO] junit:junit:jar:3.8.1:test
[INFO] log4j:log4j:jar:1.2.8:provided
[INFO] org.sakaiproject:sakai-site-manage-util:jar:2.6-SNAPSHOT:compile
[INFO] org.sakaiproject.kernel:sakai-component-manager:jar:1.0.12ox2-SNAPSHOT:provided
[INFO] org.sakaiproject.kernel:sakai-kernel-api:jar:1.0.12ox2-SNAPSHOT:provided
[INFO] org.sakaiproject.kernel:sakai-kernel-util:jar:1.0.12ox2-SNAPSHOT:compile
[INFO] uk.org.ponder:j-servletutil:jar:1.2.4:compile
[INFO] uk.org.ponder:ponderutilcore:jar:1.2.4:compile
[INFO] uk.org.ponder.rsfutil:RSFComponents-evolvers:jar:0.7.4:compile
[INFO] uk.org.ponder.rsfutil:rsfutil:jar:0.7.4:compile
[INFO] uk.org.ponder.sakairsf:SakaiRSFComponents-evolvers:jar:0.7.4-sakai_2.2.x:compile
[INFO] uk.org.ponder.sakairsf:SakaiRSFComponents-templates:war:0.7.4-sakai_2.2.x:compile
[INFO] uk.org.ponder.sakairsf:sakairsf:jar:0.7.4-sakai_2.2.x:compile
[INFO] xpp3:xpp3_min:jar:1.1.3.4.O:compile
But looking in the build artifact (or target folder) showed that log4j was being included ( WEB-INF/lib/log4j-1.2.14.jar ). It was a different version didn't look right. After a little digging it seemed the RSF templates overlay had a copy of log4j included in it and this was getting copied across with everything else when the war overlay was performed.
Solutions:
It looks like there isn't a newer version of the templates with this file excluded:
https://www2.caret.cam.ac.uk/maven2dev/uk/org/ponder/sakairsf/SakaiRSFComponents-templates/
The correct fix is to result the RSF templates artifact and exclude the log4j jar and the update the version pulled in by Sakai.
The alternative fix is to exclude the JAR when performing the overlay. But every tool that uses this overlay has to be updated with the fix.
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.1-beta-1</version> <!-- Need beta-1 for overlay exclusions -->
<configuration>
<overlays>
<overlay>
<groupId>uk.org.ponder.sakairsf</groupId>
<artifactId>SakaiRSFComponents-templates</artifactId>
<type>war</type>
<excludes>
<exclude>WEB-INF/lib/*</exclude>
</excludes>
</overlay>
</overlays>
</configuration>
</plugin>