Geir W. wrote:

The changes needs to be done on every logging statement using an object,
*)log.debug(object)->log.debug(object.toString()) *)log.fatal("") needs to be modified to log.error("");
   *)NDC statements must be migrated to MDC
   *)...

Modifying log.debug(object) to log.debug(object.toString()) can be done very quickly, for two reasons. Usually, there are very few such statements. Just as importantly, they are detected and shown by the compiler.

 >>Ceki Gulcu writes:
>>"even very large projects can be migrated to the SLF4J API within half an hour"

from sl4j.org:
"Suppose that your CRM application uses log4j for its logging. However, one of your important clients request that logging be performed through JDK 1.4 logging. If your application is riddled with thousands of direct log4j calls, migration to JDK 1.4 would be a long and error-prone process."

So why is it that moving from log4j -> to jdk 1.4 would be a long and error-prone process
but going from log4j -> sl4j is smoother than a baby's bottom?

The statement in slf4j.org is not accurate. In the case of source code migration for the CRM, you would have to maintain two code bases, one for log4j and one for jul, that is bound to be difficult. As for the migration itself, there are no public tools for such migration. There is one for log4j to slf4j migration.

But please, maintain 100% compatibility in log4j!

There is actually a way to maintain 100% source code compatibility. The org.apache.log4j.Logger/Category classes would cetain their existing method signatures but would delegate to org.apache.log4j.impl.Logger class which would implement the org.slf4j.Logger interface. This is feasible as demonstrated by the log4j-over-slf4j module in SLF4J.

Clients wishing to use the existing log4j classes could continue to do so. Those wishing to standardize on the SLF4J API could do so as well. Direct use of org.apache.log4j.impl.Logger would technically be possible but discouraged.

As described above, there is a way to converge on the SLF4J API without breaking compatibility.

--
Ceki Gülcü

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to