I added a build.xml to each of these projects so you can make one of your very own. The default target will produce a sources and binaries JAR for each module.
What about mavenizing them? ;-)
Ugh, that sounds like work :)
I don't really know anything about maven, but if someone wants to do it I won't stop them. Probably of greater importance would be to move these projects out of the sandbox repository. :-)
For your LogManager, why not support a log4j.xml style of configuration with a proper object model that can be extended via jaxb?
Because that doesn't belong in the LogManager. The underlying problem with the JDK LogManager is that it is not equipped to handle the job it is designed for - so the best solution is to strip configuration/etc out of it and let it basically just be a holder for the root Logger and that is all. Essentially my LogManager is the minimum needed to do the job (also taking into account factors like the fact that it has to be on the boot classpath, so it really ought to be as small as possible).
That's why this is split into two parts. The first part is the LogManager (namely, fixing the zillion bugs with the JDK one), and the second part is a JAR which is deployable into the MC to insert a Handler into the root logger to map the log messages over.
That's not to say that what you propose shouldn't be done though. There are a bunch of things around logging that *could* be done, and that I've contemplated:
1) Make a native MetaData model for j.u.l.Loggers using SchemaResolverDeployer (pluggable handlers, filters, etc).
2) Make a compatibility MetaData model for [jboss-]log4j.xml configuration deployments (with adapter classes to allow log4j appenders to be called directly from j.u.l Handlers) using SchemaResolverDeployer
3) Whip up a compatibility log4j API that maps transparently to j.u.l, use jboss-classloading.xml to make it available to components
4) Or ditch 1-3 and stick with logbridge to map j.u.l to log4j, and instead come up with a MetaData model for log4j using SchemaResolverDeployer and rewrite that service
The reason I held back (apart from my 100-mile-long todo list) was that I don't know that log4j needs to be replaced. I mean, maybe it does but I'm not familiar with the issues surrounding it within the AS. I noticed that it's still deployed the Old Way as an MBean, and the configuration seems a bit crusty, but it seems functional at least. Maybe log4j is still OK as the framework but the configuration needs to be updated? Do we have the issues surrounding the current logging framework documented somewhere?
The log4j services are being pulled out of AS into http://anonsvn.jboss.org/repos/jbossas/projects/log-services/ and will be updated to be pojos.
The only real issue with log4j is that its another dependency that tends to conflict with users version. We can't agree on a logging framework across projects currently. It seems the most likely would be a j.u.l extension that ultimately could make it back into open jdk.
On the conflict problem - surely having proper classloader isolation will mitigate that a lot? I mean if we do this right then it won't matter whether the backend framework is log4j or j.u.l or some other thing. I guess the following points would be most important:
1) Apps and components which use any of JUL, log4j, clogging, slf4j, etc should all have their output going to the same log system in the end
1a) log4j emulation API? (#3 above)
2) Whatever framework we use (if it is other than JUL) should be hidden (classloader-wise) from the application
3) We should support old log4j.xml deployments (#2 above)
4) It would save a lot of work if we could provide a way to use log4j formatters and appenders in any case (also #2 above)
From the perspective of #1/1a and #2, I don't think it matters at all (to the user) what framework we ultimately choose. I just think it's important to remember that there are two aspects of a logging framework - the backend logger structure and the user logging API. And every project on the planet is likely to use a different user logging API, so we should be prepared to accommodate that. We just need to make sure that our backend logger supports everything the users want (formats, appenders, filtering, so-called MDC, i18n, etc).
I just hate that feeling of rewriting something that already works. :-)
. I just think it's important to remember that there are two aspects of a logging framework - the backend logger structure and the user logging API. And every project on the planet is likely to use a different user logging API, so we should be prepared to accommodate that. We just need to make sure that our backend logger supports everything the users want (formats, appenders, filtering, so-called MDC, i18n, etc).
I just hate that feeling of rewriting something that already works. :-)
Maybe there will be one less logging api in the future:
On Dec 3, 2008, at 5:41 AM, Ceki Gulcu wrote:
> As you are probably aware, more and more projects are adopting the
> SLF4J API. I would venture say that SLF4J's adoption rate is roughly
> equivalent to that of log4j itself. Although the SLF4J API is not
> perfect, most SLF4J users seem to be extremely happy with it.
> Harry Metske synthesized various logging paths in JSPWiki
> I was taken aback by the picture he paints. I think we as log4j
> committers owe it to Java developers to propose a saner logging model.
> Given the multiplicity of logging APIs in the Java world, I propose
> that log4j implement the SLF4J API directly. This can be done in the
> next version of log4j, say 1.3 or 2.0.
> Unfortunately, the adoption of the SLF4J API by log4j will be break
> 100% compatibility with existing log4j clients. More precisely,
> logging statements passing java.lang.Object as the message parameter
> will need to be changed to java.lang.String. Assuming that the
> proportion of logging statements using objects instead string is
> extremely small, comparatively few users will be affected. More
> importantly, in my experience, even very large projects can be
> migrated to the SLF4J API within half an hour.
> There is even a tool called slf4j-migrator to help with such
> migration .
> Is there support for my proposal?
>  http://www.slf4j.org/migrator.html
> -- Ceki GÃ¼lcÃ¼
I've logged this issue as https://issues.apache.org/jira/browse/LOG4J2-27 and Scott's desire for increased support for properties as https://issues.apache.org/jira/browse/LOG4J2-28. I've attached a PDF version of the referenced OpenOffice file to LOG4J2-27.
If the proposal is that direct support for SLF4J be considered as a potential feature of log4j 2.0 as previously described on this list (a designed for Java 5 replacement for log4j 1.x with fine grained concurrency), then LOG4J2-27 captures that potential feature for consideration at the proper time.
If the proposal is to create a branch of the log4j 1.2 code base that directly implements SLF4J, that is a different matter. I could recount all sorts of previous discussions on the issues involved, but I don't want to do that if that is not the proposal.
Two random thoughts:
One logging feature that we seem to be missing in JBossAS that could be desirable is the notion of segregated logging contexts. Looks like log4j has some support for this via RepositorySelector but I don't think we're really using it...? In any case, JDK logging doesn't have this notion; though it shouldn't be too tough to modify the LogManager to support this.
Also, there's currently a deficiency in the LogBridge design. It relies on a root JDK logger with a permissive log level like ALL, which would defeat the usual "isLoggable(level)" checks for things using JDK logging (JSF in particular would probably suffer from this). The solution would be to make sure that level changes are propagated between log4j and JDK logging, which might take some fiddling.