You are viewing a plain text version of this content. The canonical link for it is here.
Posted to log4j-dev@logging.apache.org by "Adam R. B. Jack" <aj...@trysybase.com> on 2004/05/18 16:53:31 UTC
[logging] jakarta-commons/commons-logging failed
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" <im...@apache.org>
To: "Jakarta Commons Developers List" <co...@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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] jakarta-commons/commons-logging failed
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> After looking at this more carefully, there is indeed a runtime problem. I
> hope to find a solution preserving both compile time and run time
> compatibility. However, I have to finish another piece of work before
> targeting this problem. Hopefully, the problem will be fixed either
> tomorrow or on Thursday.
Thanks for doing that. If/when you get to this, mind looking into this also?
I'm not trying to say you are responsible for user problems, but this did
occur at about the same time, and if we have another discontinuity I'm sure
folks would appreciate your insights into it.
Thanks in advance.
regards,
Adam
http://brutus.apache.org:8080/gump/avalon-excalibur/excalibur-logger/gump_work/build_avalon-excalibur_excalibur-logger.txt
[javac]
/usr/local/gump/public/workspace/avalon-excalibur/logger/src/java/org/apache
/avalon/excalibur/logger/log4j/Log4JConfAdapter.java:25: cannot resolve
symbol
[javac] symbol : class RootCategory
[javac] location: package spi
[javac] import org.apache.log4j.spi.RootCategory;
[javac] ^
[javac]
/usr/local/gump/public/workspace/avalon-excalibur/logger/src/java/org/apache
/avalon/excalibur/logger/log4j/Log4JConfAdapter.java:67: cannot resolve
symbol
[javac] symbol : class RootCategory
[javac] location: class
org.apache.avalon.excalibur.logger.log4j.Log4JConfAdapter
[javac] super( new Hierarchy( new RootCategory( Level.ALL ) ) );
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -deprecation for details.
[javac] 2 errors
[ant] Exiting
/usr/local/gump/public/workspace/avalon-excalibur/buildsystem/maven-common-g
ump-build.xml.
[antcall] Exiting
/usr/local/gump/public/workspace/avalon-excalibur/logger/gump-build.xml.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] jakarta-commons/commons-logging failed
Posted by Ceki Gülcü <ce...@qos.ch>.
After looking at this more carefully, there is indeed a runtime problem. I
hope to find a solution preserving both compile time and run time
compatibility. However, I have to finish another piece of work before
targeting this problem. Hopefully, the problem will be fixed either
tomorrow or on Thursday.
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" <im...@apache.org>
>To: "Jakarta Commons Developers List" <co...@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: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
--
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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] jakarta-commons/commons-logging failed
Posted by Ceki Gülcü <ce...@qos.ch>.
After looking at this more carefully, there is indeed a runtime problem. I
hope to find a solution preserving both compile time and run time
compatibility. However, I have to finish another piece of work before
targeting this problem. Hopefully, the problem will be fixed either
tomorrow or on Thursday.
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" <im...@apache.org>
>To: "Jakarta Commons Developers List" <co...@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: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
--
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: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org