At 04:53 PM 5/18/2004, Adam R. B. Jack wrote:
First, this deprecation seems to be also taking down jakarta-velocity (for the same reason) and excalibur-logger (for a slightly new reason) and is responsible for affecting 249 projects. [That is the bad/good news].
http://lsd.student.utwente.nl/gump/project_todos.html
http://lsd.student.utwente.nl/gump/jakarta-commons/commons-logging/index.html
http://lsd.student.utwente.nl/gump/jakarta-velocity/jakarta-velocity/index.html
http://lsd.student.utwente.nl/gump/avalon-excalibur/excalibur-logger/index.html
If we can determine if a migration from Priority to Level is indeed backwards compatible (as intended) then hopefully the change can be made w/o a disconnect. [The excalibur problem is RootCategory] Sadly though, 'stale classes' are what we need to be backwards compatible against (we need new code, tweaked to new APIs, to run against old log4j) so it is worrying.
Maybe this method does not exist in older log4j (despite intentions) but maybe there is one similar that could be used. Input appreciated.
> >> java.lang.NoSuchMethodError: > >> org.apache.log4j.Logger.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljava/ lang/Object;Ljava/lang/Throwable;)V > >>
Not meaning to 'jump the gump' as Ceki so nicely put it, but what if we can't handle this gracefully? Have we lost the two years of overlap that seem so nice for smoothing transition? Do we need to revert things, mark the deprecated (to get compile warning), add what will be needed (and prove it is backwards compatible) and start the clock ticking again?
regards,
Adam ----- Original Message ----- From: "Mario Ivankovits" <[EMAIL PROTECTED]> To: "Jakarta Commons Developers List" <[EMAIL PROTECTED]> Sent: Tuesday, May 18, 2004 1:58 AM Subject: Re: [EMAIL PROTECTED]: jakarta-commons/commons-logging failed
> Ceki G�lc� schrieb: > > >> > >> But it looks like the change isnt really backward compatible, i have > >> tried this now and got the following exception (patched > >> commons-logging and log4j-1.2.8): > >> > >> java.lang.NoSuchMethodError: > >> org.apache.log4j.Logger.log(Ljava/lang/String;Lorg/apache/log4j/Level;Ljava/ lang/Object;Ljava/lang/Throwable;)V > >> > >> at > >> org.apache.commons.logging.impl.Log4JLogger.fatal(Log4JLogger.java:161) > >> at org.apache.commons.vfs.test.RunTest.main(RunTest.java:31) > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >> at > >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) > >> > >> at > >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) > >> > >> at java.lang.reflect.Method.invoke(Method.java:324) > >> at com.intellij.rt.execution.application.AppMain.main(Unknown Source) > > > > The change was in the Category class, formerly the log methods > > accepted a priority but this has change to a level now. > > The above looks wrong to me. Are you sure you don't have stale classes > > around during compilation? > > Here you wrote > http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=108436289322053&w=2 > > >getLogger().log(FQCN, Priority.FATAL, message, t ); > > > >need to be changed to > > > >getLogger().log(FQCN, Logger.FATAL, message, t ); > > > In fact you meant Level.xxx instead of Logger.xxx, or? > > I compiled commons-logging against the log4j cvs-head and tried to run > it with 1.2.8, that failed as above. > > Now i tried commons-logging againt log4j-1.2.8 and tried to run it with > cvs-head, that failed too. > > Exception during startup processing > java.lang.reflect.InvocationTargetException > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39 ) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl .java:25) > at java.lang.reflect.Method.invoke(Method.java:324) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:203) > Caused by: java.lang.NoSuchMethodError: > org.apache.log4j.Logger.log(Ljava/lang/String;Lorg/apache/log4j/Priority;Lja va/lang/Object;Ljava/lan > g/Throwable;)V > at > org.apache.commons.logging.impl.Log4JLogger.info(Log4JLogger.java:152) > at > org.apache.coyote.http11.Http11Protocol.init(Http11Protocol.java:155) > at > org.apache.coyote.tomcat4.CoyoteConnector.initialize(CoyoteConnector.java:11 17) > at > org.apache.catalina.core.StandardService.initialize(StandardService.java:579 ) > at > org.apache.catalina.core.StandardServer.initialize(StandardServer.java:2246) > at org.apache.catalina.startup.Catalina.start(Catalina.java:511) > at org.apache.catalina.startup.Catalina.execute(Catalina.java:400) > at org.apache.catalina.startup.Catalina.process(Catalina.java:180) > ... 5 more > > > For me it looks like the change is for sure compile-time compatible, but > not runtime compatible. I watched out not to do something wrong, > hopfully this was the case. > > >> Maybe we relly need a new Log4J implementation depending on its > >> version .... this is bad, isnt it? > > > > Don't gump the gun yet. > > No - sorry, wont be destructive. > > -- Mario > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- Ceki G�lc�
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
