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]
