-
1. Re: Updates to the logging framework for JBossAS 4.2.x
In the same general area is an upgrade to commons-logging 1.10:
http://jira.jboss.com/jira/browse/JBAS-2823 -
2. Re: Updates to the logging framework for JBossAS 4.2.x
My vote is that we move to our own logging framework (merging with the Arjuna logging api), and any touch points to other logging systems in the core use obfuscation to avoid type pollution between user deployments and jboss.
-
3. Re: Updates to the logging framework for JBossAS 4.2.x
I think I'll start with log4j/jboss-commons updates for 4.2 (those are outdated anyway) and proceed with some isolation (JBAS-1853).
I need to see what the Arjuna logging infrastructure looks like, to understand how those can be merge, but my feeling is this should be tried on trunk. -
4. Re: Updates to the logging framework for JBossAS 4.2.x
I'd like to better understand the obfuscation concept. Was what was done with dom4j in $JBOSS_HOME/lib basically to rename the packages, and then alter a relatively small number of AS-specific classes to make calls against the obfuscated packages?
If so, how does that map to something like commons-logging, which AFAIK is on the classpath due to needs of thirdparty libraries like JBC, JGroups, and the Tomcat jars? -
5. Re: Updates to the logging framework for JBossAS 4.2.x
Yes, its just a renaming of the package.
For tomcat/jbossweb, we need to remove the dependency either through obfuscation or replacing the api usage.
For jbc/jgroups, separarte releases that are obfuscated along with the commons logging jars. jarjar can do this.