commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Adam R. B. Jack" <aj...@trysybase.com>
Subject [logging] jakarta-commons/commons-logging failed
Date Tue, 18 May 2004 14:53:31 GMT
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" <imario@apache.org>
To: "Jakarta Commons Developers List" <commons-dev@jakarta.apache.org>
Sent: Tuesday, May 18, 2004 1:58 AM
Subject: Re: [GUMP@brutus]: 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message