You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Ceki Gülcü <ce...@qos.ch> on 2004/05/19 15:53:05 UTC
Re: [logging][PROPOSAL] a solution to incompatibility between
log4j versions
With some changes to log4j HEAD and the following patch to
commons-logging, it is now possible to compile commons-logging with
1.3alpha and run it with both 1.3 *and* 1.2.8. Unfortunately, I was
unable to get a c-l version compiled with 1.2.8 to also run with 1.3.
Mostly because I am unable to grok the java.lang.VerifyError.
[java] No suitable Log constructor [Ljava.lang.Class;@f9f9d8 for
org.apache.commons.logging.impl.Log4JLogger
[java] java.lang.VerifyError: (class:
org/apache/commons/logging/impl/Log4JLogger, method: warn signature:
(Ljava/lang/Object;Ljava/lang/Throwable;)V) Incom
patible argument to function
[java] at java.lang.Class.getDeclaredConstructors0(Native Method)
[java] at
java.lang.Class.privateGetDeclaredConstructors(Class.java:1590)
[java] at java.lang.Class.getConstructor0(Class.java:1762)
[java] at java.lang.Class.getConstructor(Class.java:1002)
[java] at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
[java] at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:531)
[java] at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
[java] at
org.apache.commons.logging.LogFactory.getLog(LogFactory.java:369)
[java] at
org.apache.commons.logging.log4j.DefaultConfigTestCase.setUpLog(DefaultConfigTestCase.java:179)
[java] at
org.apache.commons.logging.log4j.DefaultConfigTestCase.setUp(DefaultConfigTestCase.java:81)
[java] at junit.framework.TestCase.runBare(TestCase.java:125)
[java] at junit.framework.TestResult$1.protect(TestResult.java:106)
[java] at
junit.framework.TestResult.runProtected(TestResult.java:124)
[java] at junit.framework.TestResult.run(TestResult.java:109)
[java] at junit.framework.TestCase.run(TestCase.java:118)
[java] at junit.framework.TestSuite.runTest(TestSuite.java:208)
[java] at junit.framework.TestSuite.run(TestSuite.java:203)
[java] at junit.textui.TestRunner.doRun(TestRunner.java:116)
[java] at junit.textui.TestRunner.start(TestRunner.java:172)
[java] at junit.textui.TestRunner.main(TestRunner.java:138)
I would be interested if someone could explain the source of the error.
Anyway, to get 1.3 compiled code to also run on 1.2.8, the trick is to
detect if running on 1.2 and to cast a Level instance as a Priority.
The detection is straightforward:
private static final boolean is12 =
Priority.class.isAssignableFrom(Level.class);
In Log4jLogger class, the various method calls become:
public void debug(Object message) {
if(is12) {
getLogger().log(FQCN, (Priority) Level.DEBUG, message, null );
} else {
getLogger().log(FQCN, Level.DEBUG, message, null );
}
}
Refer to the included patch file for exact details.
Note also that the CustomConfigTestCase.java was modified to reflect
the fact that the throwable is no longer available in ThrowableInfo.
At 02:57 PM 5/19/2004, Mario Ivankovits wrote:
>Shapira, Yoav wrote:
>
>>It'd be easy to do conditional stuff, as Joran for example is completely
>>new in log4j 1.3, with Ant's <available> tasks and related conditionals.
>>
>I am not sure, if the "conditional stuff" helps. If you end up not being
>binary-compatible, i think commons-logging needs two compile-steps.
>One with log4j-1.2.8 in the classpath, and one with log4j-1.3 for the
>Log4J13Logger and then package them together in one jar.
>
>If we would like to avoid this, we could also use reflection at all to
>call those log( methods, but this might result in an performance loss.
>
>-- Mario
>
--
Ceki Gülcü
For log4j documentation consider "The complete log4j manual"
ISBN: 2970036908 http://www.qos.ch/shop/products/clm_t.jsp
Re: [logging][PROPOSAL] a solution to incompatibility between
log4j versions
Posted by Ceki Gülcü <ce...@qos.ch>.
At 11:08 PM 5/19/2004, robert burrell donkin wrote:
>hi ceki
>
>i've committed a patch along the lines you've proposed. many thanks :)
You are welcome.
>i've added some optional unit tests that give me confidence that a
>version of commons-logging compiled against log4j CVS HEAD will run
>against 1.2.7. it'd be a good idea to find a way for gump to run this
>test (but i'm not too sure at the moment how to do this). i'll probably
>add another where the log4j 1.3 jar is explicitly specified tomorrow.
Why 1.2.7? The latest official release is 1.2.8. It won't make any
difference in practice but I'm curious nonetheless.
>running a version compiled against 1.2.x to run against 1.3 would be
>nice but not critical. i suspect that your code will only work one way
>but i'd be glad to be proved wrong. maybe i'll find time to take a look
>into this tomorrow.
As I mentioned in a previous message, the patch makes C-L compiled with
current CVS head
(1.3pre-alpha) both compile time and runtime (binary) compatible with 1.2.x
and obviously 1.3 itself.
As you correctly guessed, the patch does not work when C-L is compiled
against 1.2.x. More specifically, it wont run with 1.3. One gets the
following java.lang.VerifyError:
No suitable Log constructor [Ljava.lang.Class;@f9f9d8 for
org.apache.commons.logging.impl.Log4JLogger
java.lang.VerifyError: (class:
org/apache/commons/logging/impl/Log4JLogger, method: warn signature:
(Ljava/lang/Object;Ljava/lang/Throwable;)V) Incompatible argument to function
at java.lang.Class.getDeclaredConstructors0(Native Method)
at java.lang.Class.privateGetDeclaredConstructors(Class.java:1590)
at java.lang.Class.getConstructor0(Class.java:1762)
at java.lang.Class.getConstructor(Class.java:1002)
at
org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
at
org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:531)
at
org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
at org.apache.commons.logging.LogFactory.getLog(LogFactory.java:369)
at
org.apache.commons.logging.log4j.DefaultConfigTestCase.setUpLog(DefaultConfigTestCase.java:179)
at
org.apache.commons.logging.log4j.DefaultConfigTestCase.setUp(DefaultConfigTestCase.java:81)
The above error does not make any sense to me. Do you have an idea of
what's going on?
>- robert
--
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][PROPOSAL] a solution to incompatibility between log4j versions
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 19 May 2004, at 23:11, Adam R. B. Jack wrote:
<snip>
>> i haven't found time to fix digester, beanutils and struts gump runs
>> yet but i hope to do so tomorrow. i you could give me some quick
>> pointers to the best way to do the additional targets, i'll add them
>> to
>> my list of stuff to do...
>
> Thanks for doing that.
don't thank me too early...
i've spend all tonight porting content from the old to the new wiki.
fridays is pub-straight-from-work night for me, so most likely it'll be
the weekend before i get a chance to look at this.
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> > If so, the trick would be to run commons-logging unit tests separately
> > from
> > the compile, and run two of them with a dependency on logging-log4j and
> > logging-log4j-12.
>
> something along those lines would probably work.
Basically depend upon C-L to get what you just built, and then set an
environment to suit, then call ant with a 'test' target. You might wish to
change C-L from a 'dist' (compile/test/jar) to a simple compile/jar.
<project name="commons-logging-test-<SUITABLE-NAME>">
<description>Logging Tests</description>
<url href="http://jakarta.apache.org/commons/"/>
<ant basedir="logging" target="test"/>
<depend project="ant" inherit="runtime"/>
<depend project="commons-logging"/>
<depend project="xml-xerces"/>
<depend project="logging-log4j-12"/>
or
<depend project="logging-log4j"/>
or
<depend project="avalon-logkit"/>
or
... missing (to test Simple)
<nag to="commons-dev@jakarta.apache.org"
from="robert burrell donkin
<robertburrelldonkin@blueyonder.co.uk>"/>
</project>
Note: I made the three mandatory dependencies, not optional. Better to fail
explicitly than fallback to simple.
This is in Gump CVS at ./project/jakarta-commons.xml. If you get too
much/too fancy, you might wish to pull it out into your own module
descriptor [like http-client chose], but I wouldn't yet.
> a second gump target which tested just the log4j1.2.x compatibility
> would probably do the trick. a third which allows us to test the avalon
> framework logger would be cool as well.
and a forth to fallback to Simple? Your call.
BTW: C-L doesn't set runtime dependences within Gump, which is good for
this, bad for other things. AXIS failed when I set C-L to use log4j-12, but
sucked in it's own log4j ('cos C-L didn't provide). In the future we might
wish to address this, with the default C-L project setting things runtime,
but one step at a time.
> i haven't found time to fix digester, beanutils and struts gump runs
> yet but i hope to do so tomorrow. i you could give me some quick
> pointers to the best way to do the additional targets, i'll add them to
> my list of stuff to do...
Thanks for doing that.
regards
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On 19 May 2004, at 22:32, Adam R. B. Jack wrote:
>> i've added some optional unit tests that give me confidence that a
>> version of commons-logging compiled against log4j CVS HEAD will run
>> against 1.2.7. it'd be a good idea to find a way for gump to run this
>> test (but i'm not too sure at the moment how to do this). i'll
>> probably
>> add another where the log4j 1.3 jar is explicitly specified tomorrow.
>
> We have both 'CVS HEAD' and 'v1_2-branch' available to Gump. Is that
> close
> enough to 1.2.7?
yep
> If so, the trick would be to run commons-logging unit tests separately
> from
> the compile, and run two of them with a dependency on logging-log4j and
> logging-log4j-12.
something along those lines would probably work.
a second gump target which tested just the log4j1.2.x compatibility
would probably do the trick. a third which allows us to test the avalon
framework logger would be cool as well.
i haven't found time to fix digester, beanutils and struts gump runs
yet but i hope to do so tomorrow. i you could give me some quick
pointers to the best way to do the additional targets, i'll add them to
my list of stuff to do...
- robert
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> i've added some optional unit tests that give me confidence that a
> version of commons-logging compiled against log4j CVS HEAD will run
> against 1.2.7. it'd be a good idea to find a way for gump to run this
> test (but i'm not too sure at the moment how to do this). i'll probably
> add another where the log4j 1.3 jar is explicitly specified tomorrow.
We have both 'CVS HEAD' and 'v1_2-branch' available to Gump. Is that close
enough to 1.2.7?
If so, the trick would be to run commons-logging unit tests separately from
the compile, and run two of them with a dependency on logging-log4j and
logging-log4j-12.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
hi ceki
i've committed a patch along the lines you've proposed. many thanks :)
i've added some optional unit tests that give me confidence that a
version of commons-logging compiled against log4j CVS HEAD will run
against 1.2.7. it'd be a good idea to find a way for gump to run this
test (but i'm not too sure at the moment how to do this). i'll probably
add another where the log4j 1.3 jar is explicitly specified tomorrow.
running a version compiled against 1.2.x to run against 1.3 would be
nice but not critical. i suspect that your code will only work one way
but i'd be glad to be proved wrong. maybe i'll find time to take a look
into this tomorrow.
- robert
On 19 May 2004, at 14:53, Ceki Gülcü wrote:
> With some changes to log4j HEAD and the following patch to
> commons-logging, it is now possible to compile commons-logging with
> 1.3alpha and run it with both 1.3 *and* 1.2.8. Unfortunately, I was
> unable to get a c-l version compiled with 1.2.8 to also run with 1.3.
> Mostly because I am unable to grok the java.lang.VerifyError.
>
> [java] No suitable Log constructor [Ljava.lang.Class;@f9f9d8 for
> org.apache.commons.logging.impl.Log4JLogger
> [java] java.lang.VerifyError: (class:
> org/apache/commons/logging/impl/Log4JLogger, method: warn signature:
> (Ljava/lang/Object;Ljava/lang/Throwable;)V) Incom
> patible argument to function
> [java] at java.lang.Class.getDeclaredConstructors0(Native
> Method)
> [java] at
> java.lang.Class.privateGetDeclaredConstructors(Class.java:1590)
> [java] at java.lang.Class.getConstructor0(Class.java:1762)
> [java] at java.lang.Class.getConstructor(Class.java:1002)
> [java] at
> org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFac
> toryImpl.java:410)
> [java] at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryIm
> pl.java:531)
> [java] at
> org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryIm
> pl.java:235)
> [java] at
> org.apache.commons.logging.LogFactory.getLog(LogFactory.java:369)
> [java] at
> org.apache.commons.logging.log4j.DefaultConfigTestCase.setUpLog(Default
> ConfigTestCase.java:179)
> [java] at
> org.apache.commons.logging.log4j.DefaultConfigTestCase.setUp(DefaultCon
> figTestCase.java:81)
> [java] at junit.framework.TestCase.runBare(TestCase.java:125)
> [java] at
> junit.framework.TestResult$1.protect(TestResult.java:106)
> [java] at
> junit.framework.TestResult.runProtected(TestResult.java:124)
> [java] at junit.framework.TestResult.run(TestResult.java:109)
> [java] at junit.framework.TestCase.run(TestCase.java:118)
> [java] at
> junit.framework.TestSuite.runTest(TestSuite.java:208)
> [java] at junit.framework.TestSuite.run(TestSuite.java:203)
> [java] at junit.textui.TestRunner.doRun(TestRunner.java:116)
> [java] at junit.textui.TestRunner.start(TestRunner.java:172)
> [java] at junit.textui.TestRunner.main(TestRunner.java:138)
>
> I would be interested if someone could explain the source of the error.
>
> Anyway, to get 1.3 compiled code to also run on 1.2.8, the trick is to
> detect if running on 1.2 and to cast a Level instance as a Priority.
>
> The detection is straightforward:
>
> private static final boolean is12 =
> Priority.class.isAssignableFrom(Level.class);
>
> In Log4jLogger class, the various method calls become:
>
> public void debug(Object message) {
> if(is12) {
> getLogger().log(FQCN, (Priority) Level.DEBUG, message, null );
> } else {
> getLogger().log(FQCN, Level.DEBUG, message, null );
> }
> }
>
> Refer to the included patch file for exact details.
>
> Note also that the CustomConfigTestCase.java was modified to reflect
> the fact that the throwable is no longer available in ThrowableInfo.
>
>
> At 02:57 PM 5/19/2004, Mario Ivankovits wrote:
>> Shapira, Yoav wrote:
>>
>>> It'd be easy to do conditional stuff, as Joran for example is
>>> completely
>>> new in log4j 1.3, with Ant's <available> tasks and related
>>> conditionals.
>>>
>> I am not sure, if the "conditional stuff" helps. If you end up not
>> being binary-compatible, i think commons-logging needs two
>> compile-steps.
>> One with log4j-1.2.8 in the classpath, and one with log4j-1.3 for the
>> Log4J13Logger and then package them together in one jar.
>>
>> If we would like to avoid this, we could also use reflection at all
>> to call those log( methods, but this might result in an performance
>> loss.
>>
>> -- Mario
>>
>
> --
> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [Ant] bootstrap-ant no longer builds
Posted by Peter Reilly <pe...@corvil.com>.
Opps,
I had tested with java1.5, java1.4.2 and java1.2.
The build.xml should work now.
Peter
Michael Davey wrote:
> Adam R. B. Jack wrote:
>
>> someone wrote:
>>
>>> Moreover, we have provided very clear set of instructions that safely
>>> address the c-l compilation problems. I think log4j is the wrong tree
>>> to bark at.
>>>
>>> I noticed that
>>> <http://gump.covalent.net/log/bootstrap-ant.html>bootstrap-ant no
>>> longer
>>> builds. Is it a related problem?
>>>
>>
>>
>> Hmm, good question. Seems possible, but odd that it works here:
>> http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/index.html
>>
>> http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/gump_work/buildscript_ant_bootstrap-ant.html
>>
>>
>>
> This fails on my private Gump too. Looks like it is caused by a
> recent commit of Ant's build.xml:
>
> http://cvs.apache.org/viewcvs.cgi/ant/build.xml?r1=1.418&r2=1.419&diff_format=h
>
>
>
> The "-source" option does not support the "1.2" argument in Java
> 1.4.0, but it is supported in Java 1.4.2 and 1.5.0-beta. "1.3" is
> supported in Java 1.4.0 - I don't know when it was added.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [Ant] bootstrap-ant no longer builds
Posted by Peter Reilly <pe...@corvil.com>.
Opps,
I had tested with java1.5, java1.4.2 and java1.2.
The build.xml should work now.
Peter
Michael Davey wrote:
> Adam R. B. Jack wrote:
>
>> someone wrote:
>>
>>> Moreover, we have provided very clear set of instructions that safely
>>> address the c-l compilation problems. I think log4j is the wrong tree
>>> to bark at.
>>>
>>> I noticed that
>>> <http://gump.covalent.net/log/bootstrap-ant.html>bootstrap-ant no
>>> longer
>>> builds. Is it a related problem?
>>>
>>
>>
>> Hmm, good question. Seems possible, but odd that it works here:
>> http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/index.html
>>
>> http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/gump_work/buildscript_ant_bootstrap-ant.html
>>
>>
>>
> This fails on my private Gump too. Looks like it is caused by a
> recent commit of Ant's build.xml:
>
> http://cvs.apache.org/viewcvs.cgi/ant/build.xml?r1=1.418&r2=1.419&diff_format=h
>
>
>
> The "-source" option does not support the "1.2" argument in Java
> 1.4.0, but it is supported in Java 1.4.2 and 1.5.0-beta. "1.3" is
> supported in Java 1.4.0 - I don't know when it was added.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
[Ant] bootstrap-ant no longer builds (was: Re: [logging][PROPOSAL]
a solution to incompatibility between log4j versions)
Posted by Michael Davey <Mi...@coderage.org>.
Adam R. B. Jack wrote:
> someone wrote:
>
>>Moreover, we have provided very clear set of instructions that safely
>>address the c-l compilation problems. I think log4j is the wrong tree
>>to bark at.
>>
>>I noticed that
>><http://gump.covalent.net/log/bootstrap-ant.html>bootstrap-ant no longer
>>builds. Is it a related problem?
>>
>>
>
>Hmm, good question. Seems possible, but odd that it works here:
> http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/index.html
>
>http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/gump_work/buildscript_ant_bootstrap-ant.html
>
>
This fails on my private Gump too. Looks like it is caused by a recent
commit of Ant's build.xml:
http://cvs.apache.org/viewcvs.cgi/ant/build.xml?r1=1.418&r2=1.419&diff_format=h
The "-source" option does not support the "1.2" argument in Java 1.4.0,
but it is supported in Java 1.4.2 and 1.5.0-beta. "1.3" is supported in
Java 1.4.0 - I don't know when it was added.
--
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [logging][PROPOSAL] a solution to incompatibility between
log4j versions
Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:08 PM 5/19/2004, Adam R. B. Jack wrote:
> > On the log4j we are making a very serious effort to keep everyone
> > happy.
>
>And that is greatly appreciated. :)
>
>I really wish you weren't having to go through this, I can hardly imagine
>how frustrating it must be to maintain an old interface for two years,
>attempting a clean deprecation, only run into such a gotcha. I do feel for
>you, and think users appreciate anything you can do to help.
>
> > Tell us specifically what fails and we will do our best to fix
> > it. Rolling back everything is not specific enough.
>
>Then can I say, whatever "changed in the public API"? ;-) Seriously though,
>I'd mentioned them previous in thread. That said, this thread has morphed,
>moved over 4 list, etc, so here again:
>
>Best I can tell from here:
>
> http://lsd.student.utwente.nl/gump/project_todos.html
>
>These two are the Priority deprecation:
>
>http://lsd.student.utwente.nl/gump/jakarta-commons/commons-logging/index.html
On the c-l front the problem is clearly identified. A clear and safe
solution has been provided.
>http://lsd.student.utwente.nl/gump/jakarta-velocity/jakarta-velocity/index.html
From what I could gather from [1] and [2] velocity needs to change
logger.setPriority(Priority.DEBUG);
to
logger.setLevel(Level.DEBUG);
This will work in both 1.2.x and 1.3, both at compile and at runtime.
[1] http://marc.theaimsgroup.com/?l=velocity-dev&m=108442380518687&w=2
[2] [javac]
/data3/gump/jakarta-velocity/bin/src/org/apache/velocity/runtime/log/Simple \
Log4JLogSystem.java:119: cannot resolve symbol [javac] symbol : method
setPriority \
(org.apache.log4j.Priority) [javac] location: class org.apache.log4j.Category
[javac] logger.setPriority(Priority.DEBUG);
>You already reverted this one, thanks (it was RootCategory, I think):
>http://lsd.student.utwente.nl/gump/avalon-excalibur/excalibur-logger/index.html
>
>Again, these are only the ones I can tell from within Apacge/Gump. External
>users who've not moved from Priority, are probably the same.
>
> > Moreover, we have provided very clear set of instructions that safely
> > address the c-l compilation problems. I think log4j is the wrong tree
> > to bark at.
> >
> > I noticed that
> > <http://gump.covalent.net/log/bootstrap-ant.html>bootstrap-ant no longer
> > builds. Is it a related problem?
>
>Hmm, good question. Seems possible, but odd that it works here:
> http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/index.html
>
>http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/gump_work/buildscript_ant_bootstrap-ant.html
>
>(although here it assumes no log4j).
>
>The check does look for :
>
> <available property="log4j.present"
> classname="org.apache.log4j.Category"
> classpathref="classpath"/>
>
>Did that change?
>
>I'll ask a Gumpmeister (who has access to that box) to take a closer look,
>and get back to you.
>
>regards,
>
>Adam
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
>For additional commands, e-mail: general-help@gump.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: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[Ant] bootstrap-ant no longer builds (was: Re: [logging][PROPOSAL]
a solution to incompatibility between log4j versions)
Posted by Michael Davey <Mi...@coderage.org>.
Adam R. B. Jack wrote:
> someone wrote:
>
>>Moreover, we have provided very clear set of instructions that safely
>>address the c-l compilation problems. I think log4j is the wrong tree
>>to bark at.
>>
>>I noticed that
>><http://gump.covalent.net/log/bootstrap-ant.html>bootstrap-ant no longer
>>builds. Is it a related problem?
>>
>>
>
>Hmm, good question. Seems possible, but odd that it works here:
> http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/index.html
>
>http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/gump_work/buildscript_ant_bootstrap-ant.html
>
>
This fails on my private Gump too. Looks like it is caused by a recent
commit of Ant's build.xml:
http://cvs.apache.org/viewcvs.cgi/ant/build.xml?r1=1.418&r2=1.419&diff_format=h
The "-source" option does not support the "1.2" argument in Java 1.4.0,
but it is supported in Java 1.4.2 and 1.5.0-beta. "1.3" is supported in
Java 1.4.0 - I don't know when it was added.
--
Michael
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org
Re: [logging][PROPOSAL] a solution to incompatibility between
log4j versions
Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:08 PM 5/19/2004, "Adam R. B. Jack" wrote:
>Hmm, good question. Seems possible, but odd that it works here:
> http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/index.html
>
>http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/gump_work/buildscript_ant_bootstrap-ant.html
>
>(although here it assumes no log4j).
>
>The check does look for :
>
> <available property="log4j.present"
> classname="org.apache.log4j.Category"
> classpathref="classpath"/>
>
>Did that change?
As far as I am aware, no.
>regards,
>
>Adam
--
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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [logging][PROPOSAL] a solution to incompatibility between
log4j versions
Posted by Ceki Gülcü <ce...@qos.ch>.
At 07:08 PM 5/19/2004, Adam R. B. Jack wrote:
> > On the log4j we are making a very serious effort to keep everyone
> > happy.
>
>And that is greatly appreciated. :)
>
>I really wish you weren't having to go through this, I can hardly imagine
>how frustrating it must be to maintain an old interface for two years,
>attempting a clean deprecation, only run into such a gotcha. I do feel for
>you, and think users appreciate anything you can do to help.
>
> > Tell us specifically what fails and we will do our best to fix
> > it. Rolling back everything is not specific enough.
>
>Then can I say, whatever "changed in the public API"? ;-) Seriously though,
>I'd mentioned them previous in thread. That said, this thread has morphed,
>moved over 4 list, etc, so here again:
>
>Best I can tell from here:
>
> http://lsd.student.utwente.nl/gump/project_todos.html
>
>These two are the Priority deprecation:
>
>http://lsd.student.utwente.nl/gump/jakarta-commons/commons-logging/index.html
On the c-l front the problem is clearly identified. A clear and safe
solution has been provided.
>http://lsd.student.utwente.nl/gump/jakarta-velocity/jakarta-velocity/index.html
From what I could gather from [1] and [2] velocity needs to change
logger.setPriority(Priority.DEBUG);
to
logger.setLevel(Level.DEBUG);
This will work in both 1.2.x and 1.3, both at compile and at runtime.
[1] http://marc.theaimsgroup.com/?l=velocity-dev&m=108442380518687&w=2
[2] [javac]
/data3/gump/jakarta-velocity/bin/src/org/apache/velocity/runtime/log/Simple \
Log4JLogSystem.java:119: cannot resolve symbol [javac] symbol : method
setPriority \
(org.apache.log4j.Priority) [javac] location: class org.apache.log4j.Category
[javac] logger.setPriority(Priority.DEBUG);
>You already reverted this one, thanks (it was RootCategory, I think):
>http://lsd.student.utwente.nl/gump/avalon-excalibur/excalibur-logger/index.html
>
>Again, these are only the ones I can tell from within Apacge/Gump. External
>users who've not moved from Priority, are probably the same.
>
> > Moreover, we have provided very clear set of instructions that safely
> > address the c-l compilation problems. I think log4j is the wrong tree
> > to bark at.
> >
> > I noticed that
> > <http://gump.covalent.net/log/bootstrap-ant.html>bootstrap-ant no longer
> > builds. Is it a related problem?
>
>Hmm, good question. Seems possible, but odd that it works here:
> http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/index.html
>
>http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/gump_work/buildscript_ant_bootstrap-ant.html
>
>(although here it assumes no log4j).
>
>The check does look for :
>
> <available property="log4j.present"
> classname="org.apache.log4j.Category"
> classpathref="classpath"/>
>
>Did that change?
>
>I'll ask a Gumpmeister (who has access to that box) to take a closer look,
>and get back to you.
>
>regards,
>
>Adam
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
>For additional commands, e-mail: general-help@gump.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: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> On the log4j we are making a very serious effort to keep everyone
> happy.
And that is greatly appreciated. :)
I really wish you weren't having to go through this, I can hardly imagine
how frustrating it must be to maintain an old interface for two years,
attempting a clean deprecation, only run into such a gotcha. I do feel for
you, and think users appreciate anything you can do to help.
> Tell us specifically what fails and we will do our best to fix
> it. Rolling back everything is not specific enough.
Then can I say, whatever "changed in the public API"? ;-) Seriously though,
I'd mentioned them previous in thread. That said, this thread has morphed,
moved over 4 list, etc, so here again:
Best I can tell from here:
http://lsd.student.utwente.nl/gump/project_todos.html
These two are the Priority deprecation:
http://lsd.student.utwente.nl/gump/jakarta-commons/commons-logging/index.html
http://lsd.student.utwente.nl/gump/jakarta-velocity/jakarta-velocity/index.html
You already reverted this one, thanks (it was RootCategory, I think):
http://lsd.student.utwente.nl/gump/avalon-excalibur/excalibur-logger/index.html
Again, these are only the ones I can tell from within Apacge/Gump. External
users who've not moved from Priority, are probably the same.
> Moreover, we have provided very clear set of instructions that safely
> address the c-l compilation problems. I think log4j is the wrong tree
> to bark at.
>
> I noticed that
> <http://gump.covalent.net/log/bootstrap-ant.html>bootstrap-ant no longer
> builds. Is it a related problem?
Hmm, good question. Seems possible, but odd that it works here:
http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/index.html
http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/gump_work/buildscript_ant_bootstrap-ant.html
(although here it assumes no log4j).
The check does look for :
<available property="log4j.present"
classname="org.apache.log4j.Category"
classpathref="classpath"/>
Did that change?
I'll ask a Gumpmeister (who has access to that box) to take a closer look,
and get back to you.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@gump.apache.org
For additional commands, e-mail: general-help@gump.apache.org
Re: [logging][PROPOSAL] a solution to incompatibility between log4j versions
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> On the log4j we are making a very serious effort to keep everyone
> happy.
And that is greatly appreciated. :)
I really wish you weren't having to go through this, I can hardly imagine
how frustrating it must be to maintain an old interface for two years,
attempting a clean deprecation, only run into such a gotcha. I do feel for
you, and think users appreciate anything you can do to help.
> Tell us specifically what fails and we will do our best to fix
> it. Rolling back everything is not specific enough.
Then can I say, whatever "changed in the public API"? ;-) Seriously though,
I'd mentioned them previous in thread. That said, this thread has morphed,
moved over 4 list, etc, so here again:
Best I can tell from here:
http://lsd.student.utwente.nl/gump/project_todos.html
These two are the Priority deprecation:
http://lsd.student.utwente.nl/gump/jakarta-commons/commons-logging/index.html
http://lsd.student.utwente.nl/gump/jakarta-velocity/jakarta-velocity/index.html
You already reverted this one, thanks (it was RootCategory, I think):
http://lsd.student.utwente.nl/gump/avalon-excalibur/excalibur-logger/index.html
Again, these are only the ones I can tell from within Apacge/Gump. External
users who've not moved from Priority, are probably the same.
> Moreover, we have provided very clear set of instructions that safely
> address the c-l compilation problems. I think log4j is the wrong tree
> to bark at.
>
> I noticed that
> <http://gump.covalent.net/log/bootstrap-ant.html>bootstrap-ant no longer
> builds. Is it a related problem?
Hmm, good question. Seems possible, but odd that it works here:
http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/index.html
http://lsd.student.utwente.nl/gump/ant/bootstrap-ant/gump_work/buildscript_ant_bootstrap-ant.html
(although here it assumes no log4j).
The check does look for :
<available property="log4j.present"
classname="org.apache.log4j.Category"
classpathref="classpath"/>
Did that change?
I'll ask a Gumpmeister (who has access to that box) to take a closer look,
and get back to you.
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging][PROPOSAL] a solution to incompatibility between
log4j versions
Posted by Ceki Gülcü <ce...@qos.ch>.
At 05:48 PM 5/19/2004, Adam R. B. Jack wrote:
> > With some changes to log4j HEAD and the following patch to
> > commons-logging, it is now possible to compile commons-logging with
> > 1.3alpha and run it with both 1.3 *and* 1.2.8.
>
>Is it too late to ask if things in log4j could be put back to where they
>were a week ago, while we work together for a clean longer term plan
>together? Even if C-L can manage this, there are other direct users (both
>inside Apache and *end users*) that will have to handle the situation.
On the log4j we are making a very serious effort to keep everyone
happy. Tell us specifically what fails and we will do our best to fix
it. Rolling back everything is not specific enough.
Moreover, we have provided very clear set of instructions that safely
address the c-l compilation problems. I think log4j is the wrong tree
to bark at.
I noticed that
<http://gump.covalent.net/log/bootstrap-ant.html>bootstrap-ant no longer
builds. Is it a related problem?
>regards,
>
>Adam
--
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][PROPOSAL] a solution to incompatibility between log4j versions
Posted by "Adam R. B. Jack" <aj...@trysybase.com>.
> With some changes to log4j HEAD and the following patch to
> commons-logging, it is now possible to compile commons-logging with
> 1.3alpha and run it with both 1.3 *and* 1.2.8.
Is it too late to ask if things in log4j could be put back to where they
were a week ago, while we work together for a clean longer term plan
together? Even if C-L can manage this, there are other direct users (both
inside Apache and *end users*) that will have to handle the situation.
I know this has been 'on the way out' for long time, but it seems that the
transition isn't as smooth as was hoped. Could a plan be put in place,
guaranteed compatible changes put in place, and the clock start ticking on
the 'overlap window'?
regards,
Adam
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging][PROPOSAL] a solution to incompatibility between
log4j versions
Posted by Ceki Gülcü <ce...@qos.ch>.
The patch did not make it to the list but it is available
in bugzilla.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=28933
At 03:53 PM 5/19/2004, you wrote:
>With some changes to log4j HEAD and the following patch to
>commons-logging, it is now possible to compile commons-logging with
>1.3alpha and run it with both 1.3 *and* 1.2.8. Unfortunately, I was
>unable to get a c-l version compiled with 1.2.8 to also run with 1.3.
>Mostly because I am unable to grok the java.lang.VerifyError.
>
> [java] No suitable Log constructor [Ljava.lang.Class;@f9f9d8 for
> org.apache.commons.logging.impl.Log4JLogger
> [java] java.lang.VerifyError: (class:
> org/apache/commons/logging/impl/Log4JLogger, method: warn signature:
> (Ljava/lang/Object;Ljava/lang/Throwable;)V) Incom
>patible argument to function
> [java] at java.lang.Class.getDeclaredConstructors0(Native Method)
> [java] at
> java.lang.Class.privateGetDeclaredConstructors(Class.java:1590)
> [java] at java.lang.Class.getConstructor0(Class.java:1762)
> [java] at java.lang.Class.getConstructor(Class.java:1002)
> [java] at
> org.apache.commons.logging.impl.LogFactoryImpl.getLogConstructor(LogFactoryImpl.java:410)
> [java] at
> org.apache.commons.logging.impl.LogFactoryImpl.newInstance(LogFactoryImpl.java:531)
> [java] at
> org.apache.commons.logging.impl.LogFactoryImpl.getInstance(LogFactoryImpl.java:235)
> [java] at
> org.apache.commons.logging.LogFactory.getLog(LogFactory.java:369)
> [java] at
> org.apache.commons.logging.log4j.DefaultConfigTestCase.setUpLog(DefaultConfigTestCase.java:179)
> [java] at
> org.apache.commons.logging.log4j.DefaultConfigTestCase.setUp(DefaultConfigTestCase.java:81)
> [java] at junit.framework.TestCase.runBare(TestCase.java:125)
> [java] at junit.framework.TestResult$1.protect(TestResult.java:106)
> [java] at
> junit.framework.TestResult.runProtected(TestResult.java:124)
> [java] at junit.framework.TestResult.run(TestResult.java:109)
> [java] at junit.framework.TestCase.run(TestCase.java:118)
> [java] at junit.framework.TestSuite.runTest(TestSuite.java:208)
> [java] at junit.framework.TestSuite.run(TestSuite.java:203)
> [java] at junit.textui.TestRunner.doRun(TestRunner.java:116)
> [java] at junit.textui.TestRunner.start(TestRunner.java:172)
> [java] at junit.textui.TestRunner.main(TestRunner.java:138)
>
>I would be interested if someone could explain the source of the error.
>
>Anyway, to get 1.3 compiled code to also run on 1.2.8, the trick is to
>detect if running on 1.2 and to cast a Level instance as a Priority.
>
>The detection is straightforward:
>
> private static final boolean is12 =
> Priority.class.isAssignableFrom(Level.class);
>
>In Log4jLogger class, the various method calls become:
>
> public void debug(Object message) {
> if(is12) {
> getLogger().log(FQCN, (Priority) Level.DEBUG, message, null );
> } else {
> getLogger().log(FQCN, Level.DEBUG, message, null );
> }
> }
>
>Refer to the included patch file for exact details.
>
>Note also that the CustomConfigTestCase.java was modified to reflect
>the fact that the throwable is no longer available in ThrowableInfo.
>
>
>At 02:57 PM 5/19/2004, Mario Ivankovits wrote:
>>Shapira, Yoav wrote:
>>
>>>It'd be easy to do conditional stuff, as Joran for example is completely
>>>new in log4j 1.3, with Ant's <available> tasks and related conditionals.
>>I am not sure, if the "conditional stuff" helps. If you end up not being
>>binary-compatible, i think commons-logging needs two compile-steps.
>>One with log4j-1.2.8 in the classpath, and one with log4j-1.3 for the
>>Log4J13Logger and then package them together in one jar.
>>
>>If we would like to avoid this, we could also use reflection at all to
>>call those log( methods, but this might result in an performance loss.
>>
>>-- Mario
>
>--
>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
--
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