You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Simon Kitching <sk...@apache.org> on 2005/10/01 02:49:23 UTC
Re: [logging] log4j 1.3 support
On Fri, 2005-09-30 at 13:30 +0200, Boris Unckel wrote:
> Hello,
>
> > > Level.Trace was introduced in 1.2.12
> > >
> > http://logging.apache.org/log4j/docs/api/org/apache/log4j/Level.html#TRACE
> > You are right. Thanks!
> > And 1.2.12 is released. As soon as it is in the ibiblio, I will update the
> > version in project.xml
> > Only a little confusing that Log4J13Logger is for Log4j 1.2.12+
> > I will also add this as comment to the Log4J13Logger.
>
> Since these are internal classes I would recommend to detect the log4j
> Feature, not it's version, and rename the Log4J??Logger to
> feature dependend name (i.E. Log4JWithTraceLogger and Log4JLegacyLogger).
> The older one could be depraceted (first step/version) and afterwards
> made be final to make users who extended it, are forced to migrate
> in a definded timeframe.
>
Hi Boris/Joerg,
It's nice to see commons-logging getting some attention. Unfortunately I
don't have time to write a proper reply just now, but I will try to
address this tomorrow. Sorry I haven't joined the discussion earlier.
I did the Log4J12Logger/Log4J13Logger stuff, and the Trace support
currently in SVN.
Basically, Log4j 1.2 and log4j 1.3 are not binary compatible. There is
no way for us to write a single class that will run against both these
log4j versions. This is due to the way that the log4j team decided to
phase out the Category/Priority classes. This was discussed at length on
the log4j lists, and they were basically committed to that approach. So
we *must* have separate logger implementations for these two lib
versions. And we must compile each logger class against the appropriate
lib version, which basically makes using Maven to do the builds
impossible; Maven assumes one classpath is used to compile all the code.
So builds are ant-only.
Both the Log4j12Logger and Log4j13Logger classes *should* support the
Trace level if it exists. I thought I implemented this; if it isn't in
the trunk then maybe it is in one of the branches and I haven't merged
the changes into trunk yet.
Whether log4j12logger should be called Log4JLogger is debatable. There
are drawbacks to this. Yes, renaming the class will break setups where
someone has a config file that specifies Log4JLogger. However this setup
will fail anyway if they try to use log4j 1.3 in the classpath instead
of log4j 1.2. Given log4j's binary incompatibility between the two
versions we *can't* guarantee smooth upgrades for all combinations, and
I think the rename approach currently implemented will give the most
obvious error message, and have the most obvious fix for the users. This
is up for debate though.
[NB: I did the unit test changes too; I'll reply to the emails on that
topic tomorrow too].
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] log4j 1.3 support
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi there,
Simon Kitching wrote:
> nb: top-posting, esp. in reply to a thread that already uses
> bottom-posting, makes an email *really* hard to read!
>
> On Sun, 2005-10-09 at 22:59 -0500, Jacob Kjome wrote:
>
>>Can the problem be restated? Seems like this email catches the end of a
>>conversation. What is the issue at hand?
I am sorry for this. I wanted to have the issue raised on this list, but
very little time at the moment. Thanks to Simon for making this clear.
>
>
>
> This bugzilla entry has some of the relevant history.
> http://issues.apache.org/bugzilla/show_bug.cgi?id=34437
>
> This thread has more discussion:
> http://www.mail-archive.com/log4j-dev@logging.apache.org/msg04408.html
>
>
>
>>As for TRACE, that is new to Log4j-1.2.12 and didn't exist in versions
>>previous to it. If it doesn't exist in a 1.3 alpha binary release yet, it
>>will. There are plans to get a new 1.3 alpha build out soon. There's been
>>a lot of work done in the source to make 1.3 more compatible with 1.2,
>>which wasn't the plan early on in 1.3's development. But now the thought
>>is try to keep 1.3 as compatible with 1.2 as possible. If you are worried
>>that the current alpha is incompatible with the 1.2.xx branch, please try
>>building Log4j-1.3 from source and then compile against that. That will
>>provide a much better test of JCL 1.2.xx and 1.3 compatibility.
>
>
> That's nice to hear.
I agree. I will let you know when I checked the latest 1.3 from HEAD.
>
> Regards,
>
> Simon
Take care
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDTDI4mPuec2Dcv/8RAhyEAKCA6+UI8bnOxxel5VO1gDjKl3MNbgCfWoI1
D0lwKcJRlU+LfiGsjG3iMfo=
=EQ4z
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] log4j 1.3 support
Posted by Simon Kitching <sk...@apache.org>.
nb: top-posting, esp. in reply to a thread that already uses
bottom-posting, makes an email *really* hard to read!
On Sun, 2005-10-09 at 22:59 -0500, Jacob Kjome wrote:
> Can the problem be restated? Seems like this email catches the end of a
> conversation. What is the issue at hand?
This bugzilla entry has some of the relevant history.
http://issues.apache.org/bugzilla/show_bug.cgi?id=34437
This thread has more discussion:
http://www.mail-archive.com/log4j-dev@logging.apache.org/msg04408.html
>
> As for TRACE, that is new to Log4j-1.2.12 and didn't exist in versions
> previous to it. If it doesn't exist in a 1.3 alpha binary release yet, it
> will. There are plans to get a new 1.3 alpha build out soon. There's been
> a lot of work done in the source to make 1.3 more compatible with 1.2,
> which wasn't the plan early on in 1.3's development. But now the thought
> is try to keep 1.3 as compatible with 1.2 as possible. If you are worried
> that the current alpha is incompatible with the 1.2.xx branch, please try
> building Log4j-1.3 from source and then compile against that. That will
> provide a much better test of JCL 1.2.xx and 1.3 compatibility.
That's nice to hear.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] log4j 1.3 support
Posted by Jess Holle <je...@ptc.com>.
Jacob Kjome wrote:
> Can the problem be restated? Seems like this email catches the end of
> a conversation. What is the issue at hand?
>
> As for TRACE, that is new to Log4j-1.2.12 and didn't exist in versions
> previous to it. If it doesn't exist in a 1.3 alpha binary release
> yet, it will. There are plans to get a new 1.3 alpha build out soon.
> There's been a lot of work done in the source to make 1.3 more
> compatible with 1.2, which wasn't the plan early on in 1.3's
> development. But now the thought is try to keep 1.3 as compatible
> with 1.2 as possible. If you are worried that the current alpha is
> incompatible with the 1.2.xx branch, please try building Log4j-1.3
> from source and then compile against that. That will provide a much
> better test of JCL 1.2.xx and 1.3 compatibility.
I've written code that listens to the logger hierachy for appender
addition and in that case at least writing one batch of code that is 1.2
and 1.3 compatible seems impossible -- at least without using dynamic
proxies or some such, which I've not yet ventured to do.
The issue is that there are still 1.2 APIs that do not provide an
equivalent based on Level or Logger and are still based on Priority and
Category.
There were other issues too, but I'd figured out less ways around them.
This is where I gave up.
--
Jess Holle
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] log4j 1.3 support
Posted by Jacob Kjome <ho...@visi.com>.
Can the problem be restated? Seems like this email catches the end of a
conversation. What is the issue at hand?
As for TRACE, that is new to Log4j-1.2.12 and didn't exist in versions
previous to it. If it doesn't exist in a 1.3 alpha binary release yet, it
will. There are plans to get a new 1.3 alpha build out soon. There's been
a lot of work done in the source to make 1.3 more compatible with 1.2,
which wasn't the plan early on in 1.3's development. But now the thought
is try to keep 1.3 as compatible with 1.2 as possible. If you are worried
that the current alpha is incompatible with the 1.2.xx branch, please try
building Log4j-1.3 from source and then compile against that. That will
provide a much better test of JCL 1.2.xx and 1.3 compatibility.
Jake
At 10:47 PM 10/9/2005 +0200, you wrote:
>This mail was signed (Inlined PGP-Message).
>
>,-----GnuPG output follows (current time: Sun, Oct 09 2005 - 22:35:32)--
>|
>| Signature made 10/09/05 15:47:15 using DSA key ID 60DCBFFF
>| Can't check signature: public key not found
>|
>`---------------------------------------------------------------------------
>-BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hello world!
>
>Joerg Hohwiller wrote:
>> Joerg Hohwiller wrote:
>>
>>>>Jörg Schaible wrote:
>>>>
>>>>
>>>>>>Simon Kitching wrote:
>>>>
>>>>Hi there,
>>
>> Hi again,
>>
>>>>[snip]
>>>>
>>>>I can not see all your guyz problems. I replaced Priority with Level and
>removed
>>>>the "isAsignableFrom" section and everyting works and compiles fine. Even
>the
>>>>TRACE is defined in Level and Priority so there is not even reflection
magic
>>>>required.
>>>>Am I missing something??? Maybe I should get the 1.3 alpha release and
>have a
>>>>look if I can find the problem Simon was talking about...
>>>>The tests all worked excellent with 1.2.12 and Log4j12Logger works
fine with
>>>>prior versions. And as I said that is how the log4j guyz told to do it a
>long
>>>>time ago. I did not check this with log4j versions prior than 1.2.6. But
>as I
>>>>pointed out earlier, the Log4J12Logger is using the log4j type "Logger"
>anyways
>>>>and that came together with the type "Level".
>>>>Maybe we do not even need two Log4j Loggers - what do you think?
>>
>> Is it if you compile the jcl againts log4j 1.2 and then run it with 1.3
>and vice
>> versa? Maybe that is the point I did not think about earlier...
>> I will check when I find the time.
>Exactly this is the point. This issue really hurts. Has someone already
pointed
>this out on the log4j mailing list. I am not sure if they see this issue so
>clearly, do they?
>
>In the end I have to agree that there is no clean and easy way to support
both
>log4j 1.2 and 1.3 in one logger. There is a way though, but nobody will want
>it.
>Additionally the Log4J12Logger has to be compiled against log4j-1.2 and
>Log4J13Logger has to be compiled againts log4j-1.3 but both go to the
same jar.
>This issue could not even be handled with m2 (maven2).
>>
>>>>>>- Jörg
>>>>
>>>>Regards
>>>> Jörg
>>
>> Jörg
>and me again ;)
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDSYHTmPuec2Dcv/8RAkjBAJ9huGHVNhQqWWahkNt2+MV0FKnyGwCfQK9e
>jPOLGQXBTEvT3DkZCkkUTQg=
>=Q927
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.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] log4j 1.3 support
Posted by Jacob Kjome <ho...@visi.com>.
Can the problem be restated? Seems like this email catches the end of a
conversation. What is the issue at hand?
As for TRACE, that is new to Log4j-1.2.12 and didn't exist in versions
previous to it. If it doesn't exist in a 1.3 alpha binary release yet, it
will. There are plans to get a new 1.3 alpha build out soon. There's been
a lot of work done in the source to make 1.3 more compatible with 1.2,
which wasn't the plan early on in 1.3's development. But now the thought
is try to keep 1.3 as compatible with 1.2 as possible. If you are worried
that the current alpha is incompatible with the 1.2.xx branch, please try
building Log4j-1.3 from source and then compile against that. That will
provide a much better test of JCL 1.2.xx and 1.3 compatibility.
Jake
At 10:47 PM 10/9/2005 +0200, you wrote:
>This mail was signed (Inlined PGP-Message).
>
>,-----GnuPG output follows (current time: Sun, Oct 09 2005 - 22:35:32)--
>|
>| Signature made 10/09/05 15:47:15 using DSA key ID 60DCBFFF
>| Can't check signature: public key not found
>|
>`---------------------------------------------------------------------------
>-BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1
>
>Hello world!
>
>Joerg Hohwiller wrote:
>> Joerg Hohwiller wrote:
>>
>>>>Jörg Schaible wrote:
>>>>
>>>>
>>>>>>Simon Kitching wrote:
>>>>
>>>>Hi there,
>>
>> Hi again,
>>
>>>>[snip]
>>>>
>>>>I can not see all your guyz problems. I replaced Priority with Level and
>removed
>>>>the "isAsignableFrom" section and everyting works and compiles fine. Even
>the
>>>>TRACE is defined in Level and Priority so there is not even reflection
magic
>>>>required.
>>>>Am I missing something??? Maybe I should get the 1.3 alpha release and
>have a
>>>>look if I can find the problem Simon was talking about...
>>>>The tests all worked excellent with 1.2.12 and Log4j12Logger works
fine with
>>>>prior versions. And as I said that is how the log4j guyz told to do it a
>long
>>>>time ago. I did not check this with log4j versions prior than 1.2.6. But
>as I
>>>>pointed out earlier, the Log4J12Logger is using the log4j type "Logger"
>anyways
>>>>and that came together with the type "Level".
>>>>Maybe we do not even need two Log4j Loggers - what do you think?
>>
>> Is it if you compile the jcl againts log4j 1.2 and then run it with 1.3
>and vice
>> versa? Maybe that is the point I did not think about earlier...
>> I will check when I find the time.
>Exactly this is the point. This issue really hurts. Has someone already
pointed
>this out on the log4j mailing list. I am not sure if they see this issue so
>clearly, do they?
>
>In the end I have to agree that there is no clean and easy way to support
both
>log4j 1.2 and 1.3 in one logger. There is a way though, but nobody will want
>it.
>Additionally the Log4J12Logger has to be compiled against log4j-1.2 and
>Log4J13Logger has to be compiled againts log4j-1.3 but both go to the
same jar.
>This issue could not even be handled with m2 (maven2).
>>
>>>>>>- Jörg
>>>>
>>>>Regards
>>>> Jörg
>>
>> Jörg
>and me again ;)
>-----BEGIN PGP SIGNATURE-----
>Version: GnuPG v1.4.1 (GNU/Linux)
>Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
>iD8DBQFDSYHTmPuec2Dcv/8RAkjBAJ9huGHVNhQqWWahkNt2+MV0FKnyGwCfQK9e
>jPOLGQXBTEvT3DkZCkkUTQg=
>=Q927
>-----END PGP SIGNATURE-----
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
>For additional commands, e-mail: log4j-dev-help@logging.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] log4j 1.3 support
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello world!
Joerg Hohwiller wrote:
> Joerg Hohwiller wrote:
>
>>>Jörg Schaible wrote:
>>>
>>>
>>>>>Simon Kitching wrote:
>>>
>>>Hi there,
>
> Hi again,
>
>>>[snip]
>>>
>>>I can not see all your guyz problems. I replaced Priority with Level and removed
>>>the "isAsignableFrom" section and everyting works and compiles fine. Even the
>>>TRACE is defined in Level and Priority so there is not even reflection magic
>>>required.
>>>Am I missing something??? Maybe I should get the 1.3 alpha release and have a
>>>look if I can find the problem Simon was talking about...
>>>The tests all worked excellent with 1.2.12 and Log4j12Logger works fine with
>>>prior versions. And as I said that is how the log4j guyz told to do it a long
>>>time ago. I did not check this with log4j versions prior than 1.2.6. But as I
>>>pointed out earlier, the Log4J12Logger is using the log4j type "Logger" anyways
>>>and that came together with the type "Level".
>>>Maybe we do not even need two Log4j Loggers - what do you think?
>
> Is it if you compile the jcl againts log4j 1.2 and then run it with 1.3 and vice
> versa? Maybe that is the point I did not think about earlier...
> I will check when I find the time.
Exactly this is the point. This issue really hurts. Has someone already pointed
this out on the log4j mailing list. I am not sure if they see this issue so
clearly, do they?
In the end I have to agree that there is no clean and easy way to support both
log4j 1.2 and 1.3 in one logger. There is a way though, but nobody will want it.
Additionally the Log4J12Logger has to be compiled against log4j-1.2 and
Log4J13Logger has to be compiled againts log4j-1.3 but both go to the same jar.
This issue could not even be handled with m2 (maven2).
>
>>>>>- Jörg
>>>
>>>Regards
>>> Jörg
>
> Jörg
and me again ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDSYHTmPuec2Dcv/8RAkjBAJ9huGHVNhQqWWahkNt2+MV0FKnyGwCfQK9e
jPOLGQXBTEvT3DkZCkkUTQg=
=Q927
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: [logging] log4j 1.3 support
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello world!
Joerg Hohwiller wrote:
> Joerg Hohwiller wrote:
>
>>>Jörg Schaible wrote:
>>>
>>>
>>>>>Simon Kitching wrote:
>>>
>>>Hi there,
>
> Hi again,
>
>>>[snip]
>>>
>>>I can not see all your guyz problems. I replaced Priority with Level and removed
>>>the "isAsignableFrom" section and everyting works and compiles fine. Even the
>>>TRACE is defined in Level and Priority so there is not even reflection magic
>>>required.
>>>Am I missing something??? Maybe I should get the 1.3 alpha release and have a
>>>look if I can find the problem Simon was talking about...
>>>The tests all worked excellent with 1.2.12 and Log4j12Logger works fine with
>>>prior versions. And as I said that is how the log4j guyz told to do it a long
>>>time ago. I did not check this with log4j versions prior than 1.2.6. But as I
>>>pointed out earlier, the Log4J12Logger is using the log4j type "Logger" anyways
>>>and that came together with the type "Level".
>>>Maybe we do not even need two Log4j Loggers - what do you think?
>
> Is it if you compile the jcl againts log4j 1.2 and then run it with 1.3 and vice
> versa? Maybe that is the point I did not think about earlier...
> I will check when I find the time.
Exactly this is the point. This issue really hurts. Has someone already pointed
this out on the log4j mailing list. I am not sure if they see this issue so
clearly, do they?
In the end I have to agree that there is no clean and easy way to support both
log4j 1.2 and 1.3 in one logger. There is a way though, but nobody will want it.
Additionally the Log4J12Logger has to be compiled against log4j-1.2 and
Log4J13Logger has to be compiled againts log4j-1.3 but both go to the same jar.
This issue could not even be handled with m2 (maven2).
>
>>>>>- Jörg
>>>
>>>Regards
>>> Jörg
>
> Jörg
and me again ;)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDSYHTmPuec2Dcv/8RAkjBAJ9huGHVNhQqWWahkNt2+MV0FKnyGwCfQK9e
jPOLGQXBTEvT3DkZCkkUTQg=
=Q927
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] log4j 1.3 support
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Joerg Hohwiller wrote:
> Jörg Schaible wrote:
>
>>>Simon Kitching wrote:
>
> Hi there,
Hi again,
>
>[snip]
>
> I can not see all your guyz problems. I replaced Priority with Level and removed
> the "isAsignableFrom" section and everyting works and compiles fine. Even the
> TRACE is defined in Level and Priority so there is not even reflection magic
> required.
> Am I missing something??? Maybe I should get the 1.3 alpha release and have a
> look if I can find the problem Simon was talking about...
> The tests all worked excellent with 1.2.12 and Log4j12Logger works fine with
> prior versions. And as I said that is how the log4j guyz told to do it a long
> time ago. I did not check this with log4j versions prior than 1.2.6. But as I
> pointed out earlier, the Log4J12Logger is using the log4j type "Logger" anyways
> and that came together with the type "Level".
> Maybe we do not even need two Log4j Loggers - what do you think?
Is it if you compile the jcl againts log4j 1.2 and then run it with 1.3 and vice
versa? Maybe that is the point I did not think about earlier...
I will check when I find the time.
>
>>>- Jörg
>
> Regards
> Jörg
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDQSu/mPuec2Dcv/8RAo4FAJ9dPLKLP8YMXlQwykbSVBXmotd2WwCdFuI3
GGk6Qte7pLgfWRFZyL0rkRE=
=Coh/
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] log4j 1.3 support
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jörg Schaible wrote:
> Simon Kitching wrote:
Hi there,
>
> [snip]
>
>>In Log4J1.2, Level extends Priority and Logger extends Category.
>>The log method on Category only takes Priority parameters.
>>So any calls to the log method resolves to a method on a Category
>>instance that takes a Priority parameter, even when the source code is
>>invoking the method on a reference of type Logger and passing a
>>parameter of type Level. [1]
>>
>>In Log4J1.3, Priority extends Level, and all the constants on the
>>Priority class are actually of type Level.
>>
>>The result is that no code compiled against 1.2 will run with 1.3 at
>>runtime. And that no code compiled against 1.3 will run with 1.2 at
>>runtime.
>>
>>If you *can* find a way to write one logger class that (compiled against
>>either version) will run against both libs that would be great - but
>>please *test* that after compiling your code (against either library) it
>>works at runtime with either lib version in the classpath. I've spent
>>some time thinking about this and believe it can't be done.
>
>
> [snip]
>
> You can do something like this with reflection, but this might impact the
> performance and has consequences for secure environments :(
I can not see all your guyz problems. I replaced Priority with Level and removed
the "isAsignableFrom" section and everyting works and compiles fine. Even the
TRACE is defined in Level and Priority so there is not even reflection magic
required.
Am I missing something??? Maybe I should get the 1.3 alpha release and have a
look if I can find the problem Simon was talking about...
The tests all worked excellent with 1.2.12 and Log4j12Logger works fine with
prior versions. And as I said that is how the log4j guyz told to do it a long
time ago. I did not check this with log4j versions prior than 1.2.6. But as I
pointed out earlier, the Log4J12Logger is using the log4j type "Logger" anyways
and that came together with the type "Level".
Maybe we do not even need two Log4j Loggers - what do you think?
>
> - Jörg
Regards
Jörg
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDQRNgmPuec2Dcv/8RAov7AJ9h8KClx4OLUva1y4nh7kt3UT6oNQCff9Ag
vmmncN1sx9UGEKyvxY8CYXk=
=MQ7y
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] log4j 1.3 support
Posted by Jörg Schaible <jo...@gmx.de>.
Simon Kitching wrote:
[snip]
> In Log4J1.2, Level extends Priority and Logger extends Category.
> The log method on Category only takes Priority parameters.
> So any calls to the log method resolves to a method on a Category
> instance that takes a Priority parameter, even when the source code is
> invoking the method on a reference of type Logger and passing a
> parameter of type Level. [1]
>
> In Log4J1.3, Priority extends Level, and all the constants on the
> Priority class are actually of type Level.
>
> The result is that no code compiled against 1.2 will run with 1.3 at
> runtime. And that no code compiled against 1.3 will run with 1.2 at
> runtime.
>
> If you *can* find a way to write one logger class that (compiled against
> either version) will run against both libs that would be great - but
> please *test* that after compiling your code (against either library) it
> works at runtime with either lib version in the classpath. I've spent
> some time thinking about this and believe it can't be done.
[snip]
You can do something like this with reflection, but this might impact the
performance and has consequences for secure environments :(
- Jörg
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] log4j 1.3 support
Posted by Simon Kitching <sk...@apache.org>.
On Sun, 2005-10-02 at 10:23 +0200, Joerg Hohwiller wrote:
> > I suggest you look at the current code again. Log4J12Logger has:
> > <code>
> > // Releases of log4j1.2 >= 1.2.12 have
> > // Priority.TRACE available, earlier
> > // versions do not. If TRACE is not available, then we have to map
> > // calls to Log.trace(...) onto the DEBUG level.
> >
> > try {
> > traceLevel = (Priority) Priority.class.getDeclaredField("TRACE").get(null);
> > } catch(Exception ex) {
> > // ok, trace not available
> > traceLevel = Priority.DEBUG;
> > }
> > </code>
> Jep, I have looked at the code before.
> But only the use of Priority makes this be incompatible with log4j 1.3
> This check could be changed so it is only using Level and it would still
> compile. The check would not work as easy then, but it is still possible to
> figure this out without using Priority.
In Log4J1.2, Level extends Priority and Logger extends Category.
The log method on Category only takes Priority parameters.
So any calls to the log method resolves to a method on a Category
instance that takes a Priority parameter, even when the source code is
invoking the method on a reference of type Logger and passing a
parameter of type Level. [1]
In Log4J1.3, Priority extends Level, and all the constants on the
Priority class are actually of type Level.
The result is that no code compiled against 1.2 will run with 1.3 at
runtime. And that no code compiled against 1.3 will run with 1.2 at
runtime.
If you *can* find a way to write one logger class that (compiled against
either version) will run against both libs that would be great - but
please *test* that after compiling your code (against either library) it
works at runtime with either lib version in the classpath. I've spent
some time thinking about this and believe it can't be done.
[1]
You may find the output of
javap -c org.apache.commons.logging.impl.Log4J12Logger
useful to see exactly what method was bound to at compile-time.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] log4j 1.3 support
Posted by Joerg Hohwiller <jo...@j-hohwiller.de>.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hi Simon, Hi everybody,
Simon Kitching wrote:
> Well, rain has unexpectedly started this afternoon, so I've got some
> time to talk about this now...
>
> On Sat, 2005-10-01 at 12:49 +1200, Simon Kitching wrote:
>
>>On Fri, 2005-09-30 at 13:30 +0200, Boris Unckel wrote:
>>
>>>Hello,
>>>
>>>
>>>>>Level.Trace was introduced in 1.2.12
>>>>>
>>>>
>>>>http://logging.apache.org/log4j/docs/api/org/apache/log4j/Level.html#TRACE
>>>>You are right. Thanks!
>>>>And 1.2.12 is released. As soon as it is in the ibiblio, I will update the
>>>>version in project.xml
>>>>Only a little confusing that Log4J13Logger is for Log4j 1.2.12+
>>>>I will also add this as comment to the Log4J13Logger.
>>>
>>>Since these are internal classes I would recommend to detect the log4j
>>>Feature, not it's version, and rename the Log4J??Logger to
>>>feature dependend name (i.E. Log4JWithTraceLogger and Log4JLegacyLogger).
>>>The older one could be depraceted (first step/version) and afterwards
>>>made be final to make users who extended it, are forced to migrate
>>>in a definded timeframe.
>
>
> I suggest you look at the current code again. Log4J12Logger has:
> <code>
> // Releases of log4j1.2 >= 1.2.12 have
> // Priority.TRACE available, earlier
> // versions do not. If TRACE is not available, then we have to map
> // calls to Log.trace(...) onto the DEBUG level.
>
> try {
> traceLevel = (Priority) Priority.class.getDeclaredField("TRACE").get(null);
> } catch(Exception ex) {
> // ok, trace not available
> traceLevel = Priority.DEBUG;
> }
> </code>
Jep, I have looked at the code before.
But only the use of Priority makes this be incompatible with log4j 1.3
This check could be changed so it is only using Level and it would still
compile. The check would not work as easy then, but it is still possible to
figure this out without using Priority.
So my suggestion is to kick out the dependency on Priority and change it to
Level but keeping the behaviour in Log4j12Logger. I could do that if you want.
>
> So TRACE is supported in log4j12Logger as long as there is a TRACE member on the
> Priority class, ie it is already implemented as you request above: detecting
> the feature, not the version.
>
> The Log4J13Logger class can (and does) simply assume TRACE is available.
>
>
>>Basically, Log4j 1.2 and log4j 1.3 are not binary compatible. There is
>>no way for us to write a single class that will run against both these
>>log4j versions. This is due to the way that the log4j team decided to
>>phase out the Category/Priority classes. This was discussed at length on
>>the log4j lists, and they were basically committed to that approach. So
>>we *must* have separate logger implementations for these two lib
>>versions. And we must compile each logger class against the appropriate
>>lib version, which basically makes using Maven to do the builds
>>impossible; Maven assumes one classpath is used to compile all the code.
>>So builds are ant-only.
>
>
> This binary incompatibility is the reason the two logger classes exist,
> not to support the TRACE feature. The two different classes need to be
> compiled against different versions of log4j.
As I wrote above my oppinion is that we can change the code so jcl will
compile with all log4j > 1.2.12 and the resulting Log4j12Logger will work
with older versions. Since Log4J12Logger is using the log4j Logger interface
it will not work with log4j versions before Level was added because Level was
introduced together with Logger as far as I know. So there will be no
incompatibility added by my suggestion.
>
>
>>Whether log4j12logger should be called Log4JLogger is debatable. There
>>are drawbacks to this. Yes, renaming the class will break setups where
>>someone has a config file that specifies Log4JLogger. However this setup
>>will fail anyway if they try to use log4j 1.3 in the classpath instead
>>of log4j 1.2. Given log4j's binary incompatibility between the two
>>versions we *can't* guarantee smooth upgrades for all combinations, and
>>I think the rename approach currently implemented will give the most
>>obvious error message, and have the most obvious fix for the users. This
>>is up for debate though.
>>
>
>
> To expand on this: assume for the moment that we provide a Log4JLogger
> class compiled against the 1.2 log4j library, and a Log4J13Logger
> compiled against the 1.3 log4j library.
Anyways, I liked the suggestion from Boris for this issue.
If I do not get it wrong, Log4J13Logger works fine with log4j 1.2.12
so the Names Boris suggested will make more sense.
>
> An app which has a commons-logging.properties file that specifies
> Log4JLogger as the logger to use will continue to work fine when
> commons-logging is upgraded. But when they upgrade log4j, they will
> start getting strange "incompatible class definition" or "no such
> method" exceptions, because the code is compiled to expect to call
> Category.log(Priority p, ...) but that method no longer exists [the
> details might not be entirely correct here; I'm working from memory].
> That's a rather confusing message to deal with, and no hint that the
> fix is to change their commons-logging configuration.
>
> Now if we instead provide only Log4J12Logger/Log4J13Logger then when
> they upgrade their commons-logging implementation they get the message
> "Log4JLogger not found" which seems reasonably clear. They will
> (hopefully) immediately refer to the commons-logging release notes which
> will tell them how to resolve this by changing their
> commons-logging.properties file. Yes, this is a nuisance, but it's one
> imposed by the fact that the log4j releases are binary incompatible.
>
> It's also confusing to provide "Log4JLogger" when it doesn't work
> against the current Log4J release; I think the
> Log4J12Logger/Log4J13Logger names are clearer. Of course this will get
> interesting when/if Log4J 1.4 is released...
>
> It would be possible to provide a Log4JLogger class that auto-detected
> which version of log4j is in the classpath, and delegated to the
> relevant implementation, but that would have to be implemented by
> delegating calls at runtime as far as I can tell, which would have a
> performance impact. If someone could come up with an auto-detect
> solution that *doesn't* have a runtime impact I would be very happy to
> see that included. Note that here we're *not* talking about the generic
> commons-logging auto-detection, but where an app has explicitly provided
> a logger class name that happens to be o.a.c.l.impl.Log4JLogger.
Well after all I think it is okay if we do that change and people have to
edit one line of config as far as we point this out with the release notes and
in bold letters on the download page promoting the new release.
>
> Regards,
>
> Simon
Regards
Jörg
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDP5j6mPuec2Dcv/8RAp/SAJ958Pr/yiJKd/OPrgLFkkbFsJ4/mgCfYqbH
K/oR2l9DkP/JjyBmNKnrpEw=
=PdAR
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org
Re: [logging] log4j 1.3 support
Posted by Simon Kitching <sk...@apache.org>.
Well, rain has unexpectedly started this afternoon, so I've got some
time to talk about this now...
On Sat, 2005-10-01 at 12:49 +1200, Simon Kitching wrote:
> On Fri, 2005-09-30 at 13:30 +0200, Boris Unckel wrote:
> > Hello,
> >
> > > > Level.Trace was introduced in 1.2.12
> > > >
> > > http://logging.apache.org/log4j/docs/api/org/apache/log4j/Level.html#TRACE
> > > You are right. Thanks!
> > > And 1.2.12 is released. As soon as it is in the ibiblio, I will update the
> > > version in project.xml
> > > Only a little confusing that Log4J13Logger is for Log4j 1.2.12+
> > > I will also add this as comment to the Log4J13Logger.
> >
> > Since these are internal classes I would recommend to detect the log4j
> > Feature, not it's version, and rename the Log4J??Logger to
> > feature dependend name (i.E. Log4JWithTraceLogger and Log4JLegacyLogger).
> > The older one could be depraceted (first step/version) and afterwards
> > made be final to make users who extended it, are forced to migrate
> > in a definded timeframe.
I suggest you look at the current code again. Log4J12Logger has:
<code>
// Releases of log4j1.2 >= 1.2.12 have
// Priority.TRACE available, earlier
// versions do not. If TRACE is not available, then we have to map
// calls to Log.trace(...) onto the DEBUG level.
try {
traceLevel = (Priority) Priority.class.getDeclaredField("TRACE").get(null);
} catch(Exception ex) {
// ok, trace not available
traceLevel = Priority.DEBUG;
}
</code>
So TRACE is supported in log4j12Logger as long as there is a TRACE member on the
Priority class, ie it is already implemented as you request above: detecting
the feature, not the version.
The Log4J13Logger class can (and does) simply assume TRACE is available.
> Basically, Log4j 1.2 and log4j 1.3 are not binary compatible. There is
> no way for us to write a single class that will run against both these
> log4j versions. This is due to the way that the log4j team decided to
> phase out the Category/Priority classes. This was discussed at length on
> the log4j lists, and they were basically committed to that approach. So
> we *must* have separate logger implementations for these two lib
> versions. And we must compile each logger class against the appropriate
> lib version, which basically makes using Maven to do the builds
> impossible; Maven assumes one classpath is used to compile all the code.
> So builds are ant-only.
This binary incompatibility is the reason the two logger classes exist,
not to support the TRACE feature. The two different classes need to be
compiled against different versions of log4j.
> Whether log4j12logger should be called Log4JLogger is debatable. There
> are drawbacks to this. Yes, renaming the class will break setups where
> someone has a config file that specifies Log4JLogger. However this setup
> will fail anyway if they try to use log4j 1.3 in the classpath instead
> of log4j 1.2. Given log4j's binary incompatibility between the two
> versions we *can't* guarantee smooth upgrades for all combinations, and
> I think the rename approach currently implemented will give the most
> obvious error message, and have the most obvious fix for the users. This
> is up for debate though.
>
To expand on this: assume for the moment that we provide a Log4JLogger
class compiled against the 1.2 log4j library, and a Log4J13Logger
compiled against the 1.3 log4j library.
An app which has a commons-logging.properties file that specifies
Log4JLogger as the logger to use will continue to work fine when
commons-logging is upgraded. But when they upgrade log4j, they will
start getting strange "incompatible class definition" or "no such
method" exceptions, because the code is compiled to expect to call
Category.log(Priority p, ...) but that method no longer exists [the
details might not be entirely correct here; I'm working from memory].
That's a rather confusing message to deal with, and no hint that the
fix is to change their commons-logging configuration.
Now if we instead provide only Log4J12Logger/Log4J13Logger then when
they upgrade their commons-logging implementation they get the message
"Log4JLogger not found" which seems reasonably clear. They will
(hopefully) immediately refer to the commons-logging release notes which
will tell them how to resolve this by changing their
commons-logging.properties file. Yes, this is a nuisance, but it's one
imposed by the fact that the log4j releases are binary incompatible.
It's also confusing to provide "Log4JLogger" when it doesn't work
against the current Log4J release; I think the
Log4J12Logger/Log4J13Logger names are clearer. Of course this will get
interesting when/if Log4J 1.4 is released...
It would be possible to provide a Log4JLogger class that auto-detected
which version of log4j is in the classpath, and delegated to the
relevant implementation, but that would have to be implemented by
delegating calls at runtime as far as I can tell, which would have a
performance impact. If someone could come up with an auto-detect
solution that *doesn't* have a runtime impact I would be very happy to
see that included. Note that here we're *not* talking about the generic
commons-logging auto-detection, but where an app has explicitly provided
a logger class name that happens to be o.a.c.l.impl.Log4JLogger.
Regards,
Simon
---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org