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 Curt Arnold <ca...@apache.org> on 2007/04/10 22:28:13 UTC
Chainsaw dependencies on log4j 1.3
I did an experiment of building chainsaw against the current SVN for
log4j 1.2 and have a rough analysis of the dependencies issues:
[javac] Compiling 102 source files to /Users/curta/ls-svn/
chainsaw/build
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/ChainsawAppender.java:23: cannot find symbol
[javac] symbol : class Constants
[javac] location: package org.apache.log4j.helpers
[javac] import org.apache.log4j.helpers.Constants;
This error occurs in several files where chainsaw attempts to access
string constants APPLICATION_KEY, HOSTNAME_KEY and LOG4J_ID_KEY. The
easiest remedy would add these constants to ChainsawConstants.
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/ChainsawAppenderHandler.java:30: package
org.apache.log4j.rule does not exist
[javac] import org.apache.log4j.rule.ExpressionRule;
[javac] ^
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/ChainsawAppenderHandler.java:31: package
org.apache.log4j.rule does not exist
[javac] import org.apache.log4j.rule.Rule;
Chainsaw makes extension use of the org.apache.log4j.rule package
that supports org.apache.log4j.filter.ExpressionFilter and
org.apache.log4j.LocationInfoFilter. Those filters may be useful to
a log4j 1.2.x user, so it may be useful to backport them to be
compatible with log4j 1.2.x and either incorporate them into log4j
1.2.x or make them available an add-on for log4j 1.2.x.
[javac] ^
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/ChainsawAppenderHandler.java:33: cannot find symbol
[javac] symbol : class LoggerRepositoryEx
[javac] location: package org.apache.log4j.spi
[javac] import org.apache.log4j.spi.LoggerRepositoryEx;
[javac] ^
The LoggerRepositoryEx interface added methods to monitor the
addition of new loggers and appenders and several other functions.
Will need to review how these are used. If they are added, it would
likely have to be implemented in log4j 1.2.x itself.
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/ChainsawAppenderHandler.java:29: cannot find symbol
[javac] symbol : class SocketReceiver
[javac] location: package org.apache.log4j.net
[javac] import org.apache.log4j.net.SocketReceiver;
[javac] ^
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/LogUI.java:107: cannot find symbol
[javac] symbol : class SocketNodeEventListener
[javac] location: package org.apache.log4j.net
[javac] import org.apache.log4j.net.SocketNodeEventListener;
[javac] ^
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/ChainsawAppenderHandler.java:34: cannot find symbol
[javac] symbol : class LoggingEventFieldResolver
[javac] location: package org.apache.log4j.spi
[javac] import org.apache.log4j.spi.LoggingEventFieldResolver;
[javac] ^
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/ChainsawAppenderHandler.java:52: cannot find symbol
[javac] symbol : class LoggingEventFieldResolver
[javac] location: class
org.apache.log4j.chainsaw.ChainsawAppenderHandler
[javac] private final LoggingEventFieldResolver resolver =
LoggingEventFieldResolver
[javac] ^
[javac] ^
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/receivers/PluginPropertyEditorPanel.java:54: cannot find symbol
[javac] symbol : class SocketHubReceiver
[javac] location: package org.apache.log4j.net
[javac] import org.apache.log4j.net.SocketHubReceiver;
[javac] ^
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/receivers/ReceiversPanel.java:71: cannot find symbol
[javac] symbol : class SocketNodeEventListener
[javac] location: package org.apache.log4j.net
[javac] import org.apache.log4j.net.SocketNodeEventListener;
[javac] ^
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/receivers/ReceiversPanel.java:72: cannot find symbol
[javac] symbol : class SocketReceiver
[javac] location: package org.apache.log4j.net
[javac] import org.apache.log4j.net.SocketReceiver;
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/receivers/ReceiversPanel.java:435: cannot find symbol
[javac] symbol : class Receiver
[javac] location: class
org.apache.log4j.chainsaw.receivers.ReceiversPanel
[javac] private Receiver getCurrentlySelectedReceiver() {
[javac] ^
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/FileMenu.java:41: cannot find symbol
[javac] symbol : class UtilLoggingXMLDecoder
[javac] location: package org.apache.log4j.xml
[javac] import org.apache.log4j.xml.UtilLoggingXMLDecoder;
[javac] ^
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/FileMenu.java:42: cannot find symbol
[javac] symbol : class XMLDecoder
[javac] location: package org.apache.log4j.xml
[javac] import org.apache.log4j.xml.XMLDecoder;
[javac] ^
I'm guessing all the receiver stuff is unlikely to be used anywhere
outside of Chainsaw. However, it might still be useful to package
them up as a distinct package.
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/LogUI.java:106: package org.apache.log4j.joran does not exist
[javac] import org.apache.log4j.joran.JoranConfigurator;
[javac] ^
Likely could be changed back to DOMConfigurator.
[javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
chainsaw/LogUI.java:108: package org.apache.log4j.plugins does not exist
[javac] import org.apache.log4j.plugins.Plugin;
Chainsaw uses the plugins package internally and they are also used
in the log4j receivers. I think it would probably be best to keep
them with the receivers.
My suggestions would be to start two new sandbox projects, one for
the rule filters and one for the receivers+plugin. Alternately,
rules could go into log4j 1.2 and receivers+plugin could go
chainsaw. Change the org.apache.log4j.spi.Constant references to
org.apache.log4j.chainsaw.ChainsawConstant references and review the
usage LoggerRepositoryEx and DOMConfigurator.
I've confirmed that log4j 1.2.x does serialize the MDC content, it is
just that the log4j 1.3 deserialization doesn't pick it up. Likely
if Chainsaw was hosted in log4j 1.2, the MDC content would show up
for log4j 1.2 clients and disappear for log4j 1.3 clients. I think
it is possible that you might be able to write a custom serialization
that could read both log4j 1.2 and log4j 1.3 serialization. I'm
skeptical that it could be done with default serialization.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw dependencies on log4j 1.3
Posted by Paul Smith <ps...@aconex.com>.
On 17/04/2007, at 4:38 PM, Curt Arnold wrote:
>
> On Apr 17, 2007, at 12:14 AM, Paul Smith wrote:
>
>> Curt, many thanks for your efforts to get this this far. I've
>> followed the below steps, and it's _almost_ working.
>>
>> I think the Receivers module will need to have a copy of
>> org.apache.log4j.varia.LogFilePatternReceiver as well. I can do
>> an svn copy over from the 1.3 tree, rebuild the receivers module
>> and we should be on our way.
>>
>
> Okay, I didn't see a compile time dependency on it.
>
> The pom.xml will need to be modified to add a dependency from
> receivers to expression-filter.
>
> The code has a lot of style issues (including some tabs) and an old-
> style copyright notice.
>
> The code would need to be modified to use the new LoggingEvent
> constructor.
>
This is now done, but I also see now that the following Receivers are
missing from the receiver pack (not sure why I didn't see it before)
* JMSReceiver
* MulticastReceiver
* UDPReceiver
* XMLSocketReceiver
* also the org.apache.log4j.db package appears to be missing.
I think it's a simply matter of svn copy, I'll do that next and try
it out.
> Chainsaw looks like it still has old style source file headers
> around. Those would need to be changed for any release.
>
> I need to tweak the sandbox projects so they place copies of
> LICENSE and NOTICE in the generated jar files.
Thanks for fixing the source files.
Paul
Re: Chainsaw dependencies on log4j 1.3
Posted by Paul Smith <ps...@aconex.com>.
>
> The WebStart model appears to use X.509 certificates which route
> back to a Certificate Authority, hence dealing with Thawte
> signatories. Doesn't seem to be any bridge between the GPG model
> and the X.509 model which would allow us to use our existing GPG
> code signing keys. The keys are tied to personal identities, so
> sharing signing keys as required by the log4net is inappropriate.
> It should not matter however if Paul signs one release and I sign
> the next (though my Thawte key is just the freemail variety).
>
Yep, it would not matter who signed the release. ALL jars in the
Webstart package must be signed with the same key though I think.
Your freemail Thawte certificate is the same type as mine, the only
difference is that I have had my "full name" verified by 2 other
Thawte notaries. For a while there, Chainsaw was signed just with
'psmith < at > apache.org', but now it shows my full name. That
extra detail is probably irrelevant. if there was an email address
that could be 'controlled' by the Logging PMC, then perhaps we could
sign it with a freemail certificate that had that email address in
it. Should a member get booted out or something else, the
certificate could be revoked, and a new one generated by the PMC.
One wouldn't be able to get a 'Full name' verified by a notary in
this case though, since there isn't a real person to validate! :)
The tricky thing is that Thawte freemail is all done online, so not
sure how to control access to that online account by the PMC if/when
a rogue member decided to get creative...
> I'm getting dizzy and maybe can find some way to reconcile all
> this. I think we have to have our primary distribution means a
> classic .tar.gz and .zip going through the standard release
> process. Whether or how we make a WebStart version available after
> that is a separate issue.
I definitely think continuing to support the Webstart version is
worthwhile, it makes upgrades for everyone really easy. I'm
obviously not tied to having it signed with my certificate, I just
happened to be the first one to get one arranged and fight through
all the stupid keysigning rubbish that Sun has placed on us.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw dependencies on log4j 1.3
Posted by Curt Arnold <ca...@apache.org>.
On Apr 17, 2007, at 5:27 AM, Paul Smith wrote:
>>>
>>> The ant build.xml can has a 'webstart-dist' target and an 'iOrb'
>>> type target. They generate and sign the jar files (it prompts
>>> you for a local keystore and certificate passwords during the
>>> signing process; I have my thawte certificate loaded in a
>>> keystore locally). I think I had a target that uploads those
>>> signed stuff to the area where the Webstart bundle is kept, but
>>> due to symlink weirdness with Webstart, there's still a bit of
>>> hand moving of files around during the deployment.
>>>
>>
>> log4net requires signed assemblies and until recently only Nicko
>> was able to produce them. He has recently placed an encrypted
>> signing key in the SVN so that Ron or I can also produce builds of
>> log4net. Would we'd want to do the same type of thing for Chainsaw?
>>
>
> The main problem here is that the signature being signed with is my
> own personal one containing my @apache.org email address. To get
> the email certificate properly certified, I had to get 2 Thawte
> signatories to meet me in person and check documentation. I'm not
> sure how one gets around that for a generic 'log4j' certificate.
> I'm not sure I'd like to upload my signature that anyone could sign
> it with.
>
> Having said that, if we can work out how we can generate a
> certificate that all the logging services people can use, I'd vote
> for that. Can you explain exactly how the certificate was
> generated for log4net?
The public/private key pair was (most likely) generated by Nicko
using the Strong Name tool (sn.exe) before log4cxx moved to Apache.
There is no web-of-trust or other third-party validation for the
public key and the key is not explicitly tied to a person or entity.
Any change in the key used to sign the assembly would however result
in the new assembly not being recognized as an acceptable replacement
for the old assembly, so drop-in replacement requires the same key be
used regardless of who builds the package. However, you don't just
want anyone having access to the key or spoofed implementations can
get in the wild and would be assumed to be legitimate. The private
key is in the SVN but encrypted so it can be decrypted using Nicko,
Ron and my GPG private key. Any one of the three of us can add
additional individuals who can decrypt the file.
Different GPG keys can be used to sign ASF releases and the keys are
tied to a particular individual. It doesn't matter who signs the
release, just that the validity of the key can be confirmed by the
web of trust. So Mark could sign one release of log4j and I could
sign the next. If someone cares, they could check that Mark and I
have signed the others keys, so our identities are equally trustworthy.
The WebStart model appears to use X.509 certificates which route back
to a Certificate Authority, hence dealing with Thawte signatories.
Doesn't seem to be any bridge between the GPG model and the X.509
model which would allow us to use our existing GPG code signing
keys. The keys are tied to personal identities, so sharing signing
keys as required by the log4net is inappropriate. It should not
matter however if Paul signs one release and I sign the next (though
my Thawte key is just the freemail variety).
I'm getting dizzy and maybe can find some way to reconcile all this.
I think we have to have our primary distribution means a
classic .tar.gz and .zip going through the standard release process.
Whether or how we make a WebStart version available after that is a
separate issue.
>>>
>
>>>> I'm going to sleep now. I may take a run at
>>>> LogFilePatternReceiver tomorrow unless you want to take it.
>>>>
>
> I thought you were going to sleep! Are you still in US Central TZ?
>
Still here in Houston. Was a late night.
>>>
>
>>
>> I've got the source file change tool down, so I'll take a pass at
>> applying the tool to the chainsaw code base tomorrow unless
>> someone calls me off (for example, if you have a lot of
>> uncommitted changes).
>
> Nothing local changed at all, save for the application of that
> patch you sent to change the log4j 1.3->1.2 dependency, which can
> be easily redone if need be.
>
> Paul
>
>
Will commit shortly.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw dependencies on log4j 1.3
Posted by Paul Smith <ps...@aconex.com>.
>>
>> The ant build.xml can has a 'webstart-dist' target and an 'iOrb'
>> type target. They generate and sign the jar files (it prompts you
>> for a local keystore and certificate passwords during the signing
>> process; I have my thawte certificate loaded in a keystore
>> locally). I think I had a target that uploads those signed stuff
>> to the area where the Webstart bundle is kept, but due to symlink
>> weirdness with Webstart, there's still a bit of hand moving of
>> files around during the deployment.
>>
>
> log4net requires signed assemblies and until recently only Nicko
> was able to produce them. He has recently placed an encrypted
> signing key in the SVN so that Ron or I can also produce builds of
> log4net. Would we'd want to do the same type of thing for Chainsaw?
>
The main problem here is that the signature being signed with is my
own personal one containing my @apache.org email address. To get the
email certificate properly certified, I had to get 2 Thawte
signatories to meet me in person and check documentation. I'm not
sure how one gets around that for a generic 'log4j' certificate. I'm
not sure I'd like to upload my signature that anyone could sign it with.
Having said that, if we can work out how we can generate a
certificate that all the logging services people can use, I'd vote
for that. Can you explain exactly how the certificate was generated
for log4net?
>>
>>> I'm going to sleep now. I may take a run at
>>> LogFilePatternReceiver tomorrow unless you want to take it.
>>>
I thought you were going to sleep! Are you still in US Central TZ?
>>
>
> I've got the source file change tool down, so I'll take a pass at
> applying the tool to the chainsaw code base tomorrow unless someone
> calls me off (for example, if you have a lot of uncommitted changes).
Nothing local changed at all, save for the application of that patch
you sent to change the log4j 1.3->1.2 dependency, which can be easily
redone if need be.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw dependencies on log4j 1.3
Posted by Curt Arnold <ca...@apache.org>.
On Apr 17, 2007, at 1:55 AM, Paul Smith wrote:
>
> On 17/04/2007, at 4:38 PM, Curt Arnold wrote:
>
>>
>> On Apr 17, 2007, at 12:14 AM, Paul Smith wrote:
>>
>>> Curt, many thanks for your efforts to get this this far. I've
>>> followed the below steps, and it's _almost_ working.
>>>
>>> I think the Receivers module will need to have a copy of
>>> org.apache.log4j.varia.LogFilePatternReceiver as well. I can do
>>> an svn copy over from the 1.3 tree, rebuild the receivers module
>>> and we should be on our way.
>>>
>>
>> Okay, I didn't see a compile time dependency on it.
>>
>> The pom.xml will need to be modified to add a dependency from
>> receivers to expression-filter.
>>
>> The code has a lot of style issues (including some tabs) and an
>> old-style copyright notice.
>>
>
> Yes, but Chainsaw did have those before, so I'm not fussing over
> the check style issues just yet. The copyright ones are probably a
> higher priority given the legalese of it all. I tried using that
> license-fixy script with no success before, but perhaps I was just
> being dumb. I'd like to get Chainsaw built and running with 1.2.15
> before I tackle that.
>
I had wanted to get the style issues out before branching off from
the 1.3 trunk so we could compare the trunk with sandbox and not have
spurious formatting issues. However, it looks like
LogFilePatternReceiver can be identical in both the sandbox and
trunk, so the order is not as important as I thought it would be.
>> The code would need to be modified to use the new LoggingEvent
>> constructor.
>>
> Yep, I'll do that when I've got that copied over.
It is all yours.
>
>>
>>
>> I'm pretty much in the dark on the Chainsaw build and release
>> process and that is likely to need to change.
>
> The ant build.xml can has a 'webstart-dist' target and an 'iOrb'
> type target. They generate and sign the jar files (it prompts you
> for a local keystore and certificate passwords during the signing
> process; I have my thawte certificate loaded in a keystore
> locally). I think I had a target that uploads those signed stuff
> to the area where the Webstart bundle is kept, but due to symlink
> weirdness with Webstart, there's still a bit of hand moving of
> files around during the deployment.
>
log4net requires signed assemblies and until recently only Nicko was
able to produce them. He has recently placed an encrypted signing
key in the SVN so that Ron or I can also produce builds of log4net.
Would we'd want to do the same type of thing for Chainsaw?
>
>>
>> Any thoughts on potentially Mavenizing Chainsaw?
>
> I have to admit, I'm no big fan of Maven. Mostly because I don't
> use it, nor really understand it's benefit over ant. If you could
> think of why switching to Maven would be a good thing for Chainsaw,
> then I'm all ears, but the current process does work, and there are
> plenty of other things to do in Chainsaw ahead of that, IHMO.
You don't have to go collect all the dependencies, Maven can download
them from ibiblio. Plus you get a lot of site generation stuff for
free. If the build process is pretty simple, it is pretty simple to
adapt it to Maven (and still support the Ant builds if you want to).
It is not essential, but moving things around to conform with the
standard project directory structure is a better long term solution
than overriding Maven's.
>
>>
>> A Chainsaw release would require another pass at a log4j 1.2.15
>> release and some resolution to the home permanent of component,
>> expression-filter and receivers. component and receivers could be
>> merged and/or made a subproject of Chainsaw. I think expression-
>> filters is worthwhile as a log4j 1.2 companion. If we were to do
>> expression-filters as a companion, I'd like to have pattern-layout
>> ready about the same time.
>>
>
> I think bundling Receivers with Chainsaw will hide the usefulness
> of them to a broader audience. I'm happy for them to be standalone
> additional packages like they are now.
>
Okay.
>
>> I'm going to sleep now. I may take a run at
>> LogFilePatternReceiver tomorrow unless you want to take it.
>>
>
> My days seem to fly by so quickly. I'm trying desperately to gain
> control over time so I can get my hands dirty again. I'm happy to
> take on the LogFilePatternReceiver. If you have more knowledge of
> the source header fixy script, it would be well appreciated,
> otherwise I'll tackle that afterwards.
Please take LogFilePatternReceiver.
I've got the source file change tool down, so I'll take a pass at
applying the tool to the chainsaw code base tomorrow unless someone
calls me off (for example, if you have a lot of uncommitted changes).
Re: Chainsaw dependencies on log4j 1.3
Posted by Paul Smith <ps...@aconex.com>.
On 17/04/2007, at 4:38 PM, Curt Arnold wrote:
>
> On Apr 17, 2007, at 12:14 AM, Paul Smith wrote:
>
>> Curt, many thanks for your efforts to get this this far. I've
>> followed the below steps, and it's _almost_ working.
>>
>> I think the Receivers module will need to have a copy of
>> org.apache.log4j.varia.LogFilePatternReceiver as well. I can do
>> an svn copy over from the 1.3 tree, rebuild the receivers module
>> and we should be on our way.
>>
>
> Okay, I didn't see a compile time dependency on it.
>
> The pom.xml will need to be modified to add a dependency from
> receivers to expression-filter.
>
> The code has a lot of style issues (including some tabs) and an old-
> style copyright notice.
>
Yes, but Chainsaw did have those before, so I'm not fussing over the
check style issues just yet. The copyright ones are probably a
higher priority given the legalese of it all. I tried using that
license-fixy script with no success before, but perhaps I was just
being dumb. I'd like to get Chainsaw built and running with 1.2.15
before I tackle that.
> The code would need to be modified to use the new LoggingEvent
> constructor.
>
Yep, I'll do that when I've got that copied over.
>
>
> I'm pretty much in the dark on the Chainsaw build and release
> process and that is likely to need to change.
The ant build.xml can has a 'webstart-dist' target and an 'iOrb' type
target. They generate and sign the jar files (it prompts you for a
local keystore and certificate passwords during the signing process;
I have my thawte certificate loaded in a keystore locally). I think
I had a target that uploads those signed stuff to the area where the
Webstart bundle is kept, but due to symlink weirdness with Webstart,
there's still a bit of hand moving of files around during the
deployment.
>
> Any thoughts on potentially Mavenizing Chainsaw?
I have to admit, I'm no big fan of Maven. Mostly because I don't use
it, nor really understand it's benefit over ant. If you could think
of why switching to Maven would be a good thing for Chainsaw, then
I'm all ears, but the current process does work, and there are plenty
of other things to do in Chainsaw ahead of that, IHMO.
>
> A Chainsaw release would require another pass at a log4j 1.2.15
> release and some resolution to the home permanent of component,
> expression-filter and receivers. component and receivers could be
> merged and/or made a subproject of Chainsaw. I think expression-
> filters is worthwhile as a log4j 1.2 companion. If we were to do
> expression-filters as a companion, I'd like to have pattern-layout
> ready about the same time.
>
I think bundling Receivers with Chainsaw will hide the usefulness of
them to a broader audience. I'm happy for them to be standalone
additional packages like they are now.
> I'm going to sleep now. I may take a run at LogFilePatternReceiver
> tomorrow unless you want to take it.
>
My days seem to fly by so quickly. I'm trying desperately to gain
control over time so I can get my hands dirty again. I'm happy to
take on the LogFilePatternReceiver. If you have more knowledge of
the source header fixy script, it would be well appreciated,
otherwise I'll tackle that afterwards.
cheers,
Paul
Re: Chainsaw dependencies on log4j 1.3
Posted by Curt Arnold <ca...@apache.org>.
On Apr 17, 2007, at 12:14 AM, Paul Smith wrote:
> Curt, many thanks for your efforts to get this this far. I've
> followed the below steps, and it's _almost_ working.
>
> I think the Receivers module will need to have a copy of
> org.apache.log4j.varia.LogFilePatternReceiver as well. I can do an
> svn copy over from the 1.3 tree, rebuild the receivers module and
> we should be on our way.
>
Okay, I didn't see a compile time dependency on it.
The pom.xml will need to be modified to add a dependency from
receivers to expression-filter.
The code has a lot of style issues (including some tabs) and an old-
style copyright notice.
The code would need to be modified to use the new LoggingEvent
constructor.
> If this works ok, I should be able to test this out in our QA
> environment and validate the MDC stuff. If it works, I can't see
> why we shouldn't publish another Chainsaw build with this change...
> Any objections?
>
> cheers,
>
Chainsaw looks like it still has old style source file headers
around. Those would need to be changed for any release.
I need to tweak the sandbox projects so they place copies of LICENSE
and NOTICE in the generated jar files.
I'm pretty much in the dark on the Chainsaw build and release process
and that is likely to need to change.
Any thoughts on potentially Mavenizing Chainsaw?
A Chainsaw release would require another pass at a log4j 1.2.15
release and some resolution to the home permanent of component,
expression-filter and receivers. component and receivers could be
merged and/or made a subproject of Chainsaw. I think expression-
filters is worthwhile as a log4j 1.2 companion. If we were to do
expression-filters as a companion, I'd like to have pattern-layout
ready about the same time.
I'm going to sleep now. I may take a run at LogFilePatternReceiver
tomorrow unless you want to take it.
Re: Chainsaw dependencies on log4j 1.3
Posted by Paul Smith <ps...@aconex.com>.
Curt, many thanks for your efforts to get this this far. I've
followed the below steps, and it's _almost_ working.
I think the Receivers module will need to have a copy of
org.apache.log4j.varia.LogFilePatternReceiver as well. I can do an
svn copy over from the 1.3 tree, rebuild the receivers module and we
should be on our way.
If this works ok, I should be able to test this out in our QA
environment and validate the MDC stuff. If it works, I can't see why
we shouldn't publish another Chainsaw build with this change... Any
objections?
cheers,
Paul
On 13/04/2007, at 9:25 AM, Curt Arnold wrote:
> Okay, I'm now able to successfully compile Chainsaw with only some
> minor changes (more on that later). The preliminaries are pretty
> brutal at the moment, but hopefully they will get better as we
> decide how to package these things. To build Chainsaw on log4j
> 1.2.x, you need
>
> log4j-1.2.15.jar built from SVN
> apache-log4j-component-0.1-SNAPSHOT.jar
> apache-log4j-expression-filters-0.1-SNAPSHOT.jar
> apache-log4j-receivers-0.1-SNAPSHOT.jar
>
> The first you build as always. The next two are build using Maven
> and build against log4j 1.2.14 and should work, but haven't been
> tested in any manner, with earlier log4j 1.2 jars. To build these
> (adjust as appropriate for your platform), each step assumes that
> you've changed back to the base directory after the previous step:
>
> Download and install Maven 2.0.4 or later
> Open command shell
> Place maven-2.0.4/bin on path
>
> Checkout sandbox projects (where PROJECT is component, expression-
> filter or receivers) using
> svn co https://svn.apache.org/repos/asf/logging/sandbox/log4j/
> PROJECT
>
> Build and install expression-filter project
> cd expression-filter; mvn install
>
> Build and install (into local Maven repo) component project:
> cd component; mvn install
>
> Kludge an install of the freshly build log4j-1.2.15 into the local
> maven repo
> cd ~/.m2/repository/log4j/log4j
> mkdir 1.2.15
> cd 1.2.15
> # copy existing log4j-1.2.14.pom, but change version number
> sed s/1.2.14/1.2.15/ ../1.2.14/log4j-1.2.14.pom > log4j-1.2.15.pom
> # copy log4j-1.2.15.jar into same location
>
> Build and install receivers
>
> cd receivers; mvn install
>
> Replace log4j-1.3alpha-8.jar in chainsaw.lib with log4j-1.2.15.jar
> and the three generated apache-log4j-*.jars (located in the target
> subdirectory of each project).
>
> Apply patch described below and build as normal
>
>
> The following patch should allow chainsaw to build either against
> the SVN head of log4j 1.3 or the 1.2 recipe described above:
>
> Index: src/java/org/apache/log4j/chainsaw/LogUI.java
> ===================================================================
> --- src/java/org/apache/log4j/chainsaw/LogUI.java (revision 527248)
> +++ src/java/org/apache/log4j/chainsaw/LogUI.java (working copy)
> @@ -103,7 +103,7 @@
> import org.apache.log4j.chainsaw.receivers.ReceiversPanel;
> import org.apache.log4j.chainsaw.version.VersionManager;
> import org.apache.log4j.helpers.Constants;
> -import org.apache.log4j.joran.JoranConfigurator;
> +import org.apache.log4j.xml.DOMConfigurator;
> import org.apache.log4j.net.SocketNodeEventListener;
> import org.apache.log4j.plugins.Plugin;
> import org.apache.log4j.plugins.PluginEvent;
> @@ -1888,8 +1888,7 @@
> try {
> // we temporarily swap the TCCL so that plugins can
> find resources
> Thread.currentThread().setContextClassLoader
> (classLoader);
> - JoranConfigurator jc = new JoranConfigurator();
> - jc.doConfigure(url, LogManager.getLoggerRepository());
> + DOMConfigurator.configure(url);
> }finally{
> // now switch it back...
> Thread.currentThread().setContextClassLoader
> (previousTCCL);
> Index: src/java/org/apache/log4j/chainsaw/layout/
> EventDetailLayout.java
> ===================================================================
> --- src/java/org/apache/log4j/chainsaw/layout/
> EventDetailLayout.java (revision 527248)
> +++ src/java/org/apache/log4j/chainsaw/layout/
> EventDetailLayout.java (working copy)
> @@ -190,16 +190,15 @@
> li = formatLocationInfo(event);
> }
> Hashtable properties = formatProperties(event);
> - LoggingEvent copy = new LoggingEvent();
> - copy.setLogger(logger);
> - copy.setTimeStamp(event.getTimeStamp());
> - copy.setLevel(event.getLevel());
> - copy.setThreadName(threadName);
> - copy.setMessage(msg);
> - copy.setNDC(ndc);
> - copy.setThrowableInformation(event.getThrowableInformation());
> - copy.setLocationInformation(li);
> - copy.setProperties(properties);
> + LoggingEvent copy = new LoggingEvent(null,
> + logger, event.getTimeStamp(),
> + event.getLevel(),
> + msg,
> + threadName,
> + event.getThrowableInformation(),
> + ndc,
> + li,
> + properties);
>
> return copy;
> }
> Index: src/java/org/apache/log4j/chainsaw/layout/LayoutEditorPane.java
> ===================================================================
> --- src/java/org/apache/log4j/chainsaw/layout/LayoutEditorPane.java
> (revision 527248)
> +++ src/java/org/apache/log4j/chainsaw/layout/LayoutEditorPane.java
> (working copy)
> @@ -181,16 +181,16 @@
>
> ThrowableInformation tsr = new ThrowableInformation(new
> Exception());
>
> - event = new LoggingEvent();
> - event.setLogger(Logger.getLogger("com.mycompany.mylogger"));
> - event.setTimeStamp(new Date().getTime());
> - event.setLevel(org.apache.log4j.Level.DEBUG);
> - event.setThreadName("Thread-1");
> - event.setMessage("The quick brown fox jumped over the lazy dog");
> - event.setNDC("NDC string");
> - event.setThrowableInformation(tsr);
> - event.setLocationInformation(li);
> - event.setProperties(hashTable);
> + event = new LoggingEvent("org.apache.log4j.Logger",
> + Logger.getLogger("com.mycompany.mylogger"),
> + new Date().getTime(),
> + org.apache.log4j.Level.DEBUG,
> + "The quick brown fox jumped over the lazy dog",
> + "Thread-1",
> + tsr,
> + "NDC string",
> + li,
> + hashTable);
>
> }
>
>
>
> Basically, an equivalent DOMConfigurator method is used to replace
> a call to JoranConfigurator and a call to the LoggingEvent
> constructor newly added to both log4j 1.2.x and log4j 1.3 replaces
> the default construction of LoggingEvent and subsequent mutator
> calls. Duplicating the LoggingEvent mutators would have required
> removing "final" qualifiers from most members of LoggingEvent which
> was a more substantial change than I wanted to do in 1.2.x.
>
> I haven't had any success actually starting Chainsaw either against
> log4j 1.2.x or 1.3. So I'd appreciate feedback or fixes to
> anything that I didn't get right. I've now delayed income tax
> preparation by several days and will now start working on that with
> a vengeance and will not take offense if anyone wants to fix things
> directly in the SVN.
>
> Hopefully the expression-filter project is usable with deployed
> versions of log4j 1.2. Any feedback on that would also be
> appreciated.
>
> If anyone wants to add documentation, write test cases, or port
> test cases over from log4j 1.3, more power to you.
>
> For more info on Maven 2, you can download "Better Builds With
> Maven" from http://www.mergere.com/m2book_download.jsp
>
>
Paul Smith
Core Engineering Manager
Aconex
The easy way to save time and money on your project
696 Bourke Street, Melbourne,
VIC 3000, Australia
Tel: +61 3 9240 0200 Fax: +61 3 9240 0299
Email: psmith@aconex.com www.aconex.com
This email and any attachments are intended solely for the addressee.
The contents may be privileged, confidential and/or subject to
copyright or other applicable law. No confidentiality or privilege is
lost by an erroneous transmission. If you have received this e-mail
in error, please let us know by reply e-mail and delete or destroy
this mail and all copies. If you are not the intended recipient of
this message you must not disseminate, copy or take any action in
reliance on it. The sender takes no responsibility for the effect of
this message upon the recipient's computer system.
RE: Chainsaw dependencies on log4j 1.3
Posted by Scott Deboy <sd...@comotivsystems.com>.
Thanks Curt -
I'll build it and let you know how it goes.
Scott Deboy
Principal Engineer
COMOTIV SYSTEMS
111 SW Columbia Street Ste. 950
Portland, OR 97201
Office: 503.224.7496
Direct Line: 503.821.6482
Cell: 503.997.1367
Fax: 503.222.0185
sdeboy@comotivsystems.com
www.comotivsystems.com <http://www.comotivsystems.com/>
________________________________
From: Curt Arnold [mailto:carnold@apache.org]
Sent: Thursday, April 12, 2007 4:26 PM
To: Log4J Developers List
Subject: Re: Chainsaw dependencies on log4j 1.3
Okay, I'm now able to successfully compile Chainsaw with only some minor
changes (more on that later). The preliminaries are pretty brutal at
the moment, but hopefully they will get better as we decide how to
package these things. To build Chainsaw on log4j 1.2.x, you need
log4j-1.2.15.jar built from SVN
apache-log4j-component-0.1-SNAPSHOT.jar
apache-log4j-expression-filters-0.1-SNAPSHOT.jar
apache-log4j-receivers-0.1-SNAPSHOT.jar
The first you build as always. The next two are build using Maven and
build against log4j 1.2.14 and should work, but haven't been tested in
any manner, with earlier log4j 1.2 jars. To build these (adjust as
appropriate for your platform), each step assumes that you've changed
back to the base directory after the previous step:
Download and install Maven 2.0.4 or later
Open command shell
Place maven-2.0.4/bin on path
Checkout sandbox projects (where PROJECT is component, expression-filter
or receivers) using
svn co https://svn.apache.org/repos/asf/logging/sandbox/log4j/PROJECT
Build and install expression-filter project
cd expression-filter; mvn install
Build and install (into local Maven repo) component project:
cd component; mvn install
Kludge an install of the freshly build log4j-1.2.15 into the local maven
repo
cd ~/.m2/repository/log4j/log4j
mkdir 1.2.15
cd 1.2.15
# copy existing log4j-1.2.14.pom, but change version number
sed s/1.2.14/1.2.15/ ../1.2.14/log4j-1.2.14.pom > log4j-1.2.15.pom
# copy log4j-1.2.15.jar into same location
Build and install receivers
cd receivers; mvn install
Replace log4j-1.3alpha-8.jar in chainsaw.lib with log4j-1.2.15.jar and
the three generated apache-log4j-*.jars (located in the target
subdirectory of each project).
Apply patch described below and build as normal
The following patch should allow chainsaw to build either against the
SVN head of log4j 1.3 or the 1.2 recipe described above:
Index: src/java/org/apache/log4j/chainsaw/LogUI.java
===================================================================
--- src/java/org/apache/log4j/chainsaw/LogUI.java (revision 527248)
+++ src/java/org/apache/log4j/chainsaw/LogUI.java (working copy)
@@ -103,7 +103,7 @@
import org.apache.log4j.chainsaw.receivers.ReceiversPanel;
import org.apache.log4j.chainsaw.version.VersionManager;
import org.apache.log4j.helpers.Constants;
-import org.apache.log4j.joran.JoranConfigurator;
+import org.apache.log4j.xml.DOMConfigurator;
import org.apache.log4j.net.SocketNodeEventListener;
import org.apache.log4j.plugins.Plugin;
import org.apache.log4j.plugins.PluginEvent;
@@ -1888,8 +1888,7 @@
try {
// we temporarily swap the TCCL so that plugins can find
resources
Thread.currentThread().setContextClassLoader(classLoader);
- JoranConfigurator jc = new JoranConfigurator();
- jc.doConfigure(url, LogManager.getLoggerRepository());
+ DOMConfigurator.configure(url);
}finally{
// now switch it back...
Thread.currentThread().setContextClassLoader(previousTCCL);
Index: src/java/org/apache/log4j/chainsaw/layout/EventDetailLayout.java
===================================================================
--- src/java/org/apache/log4j/chainsaw/layout/EventDetailLayout.java
(revision 527248)
+++ src/java/org/apache/log4j/chainsaw/layout/EventDetailLayout.java
(working copy)
@@ -190,16 +190,15 @@
li = formatLocationInfo(event);
}
Hashtable properties = formatProperties(event);
- LoggingEvent copy = new LoggingEvent();
- copy.setLogger(logger);
- copy.setTimeStamp(event.getTimeStamp());
- copy.setLevel(event.getLevel());
- copy.setThreadName(threadName);
- copy.setMessage(msg);
- copy.setNDC(ndc);
- copy.setThrowableInformation(event.getThrowableInformation());
- copy.setLocationInformation(li);
- copy.setProperties(properties);
+ LoggingEvent copy = new LoggingEvent(null,
+ logger, event.getTimeStamp(),
+ event.getLevel(),
+ msg,
+ threadName,
+ event.getThrowableInformation(),
+ ndc,
+ li,
+ properties);
return copy;
}
Index: src/java/org/apache/log4j/chainsaw/layout/LayoutEditorPane.java
===================================================================
--- src/java/org/apache/log4j/chainsaw/layout/LayoutEditorPane.java
(revision 527248)
+++ src/java/org/apache/log4j/chainsaw/layout/LayoutEditorPane.java
(working copy)
@@ -181,16 +181,16 @@
ThrowableInformation tsr = new ThrowableInformation(new
Exception());
- event = new LoggingEvent();
- event.setLogger(Logger.getLogger("com.mycompany.mylogger"));
- event.setTimeStamp(new Date().getTime());
- event.setLevel(org.apache.log4j.Level.DEBUG);
- event.setThreadName("Thread-1");
- event.setMessage("The quick brown fox jumped over the lazy dog");
- event.setNDC("NDC string");
- event.setThrowableInformation(tsr);
- event.setLocationInformation(li);
- event.setProperties(hashTable);
+ event = new LoggingEvent("org.apache.log4j.Logger",
+ Logger.getLogger("com.mycompany.mylogger"),
+ new Date().getTime(),
+ org.apache.log4j.Level.DEBUG,
+ "The quick brown fox jumped over the lazy dog",
+ "Thread-1",
+ tsr,
+ "NDC string",
+ li,
+ hashTable);
}
Basically, an equivalent DOMConfigurator method is used to replace a
call to JoranConfigurator and a call to the LoggingEvent constructor
newly added to both log4j 1.2.x and log4j 1.3 replaces the default
construction of LoggingEvent and subsequent mutator calls. Duplicating
the LoggingEvent mutators would have required removing "final"
qualifiers from most members of LoggingEvent which was a more
substantial change than I wanted to do in 1.2.x.
I haven't had any success actually starting Chainsaw either against
log4j 1.2.x or 1.3. So I'd appreciate feedback or fixes to anything
that I didn't get right. I've now delayed income tax preparation by
several days and will now start working on that with a vengeance and
will not take offense if anyone wants to fix things directly in the SVN.
Hopefully the expression-filter project is usable with deployed versions
of log4j 1.2. Any feedback on that would also be appreciated.
If anyone wants to add documentation, write test cases, or port test
cases over from log4j 1.3, more power to you.
For more info on Maven 2, you can download "Better Builds With Maven"
from http://www.mergere.com/m2book_download.jsp
Re: Chainsaw dependencies on log4j 1.3
Posted by Curt Arnold <ca...@apache.org>.
Okay, I'm now able to successfully compile Chainsaw with only some
minor changes (more on that later). The preliminaries are pretty
brutal at the moment, but hopefully they will get better as we decide
how to package these things. To build Chainsaw on log4j 1.2.x, you need
log4j-1.2.15.jar built from SVN
apache-log4j-component-0.1-SNAPSHOT.jar
apache-log4j-expression-filters-0.1-SNAPSHOT.jar
apache-log4j-receivers-0.1-SNAPSHOT.jar
The first you build as always. The next two are build using Maven
and build against log4j 1.2.14 and should work, but haven't been
tested in any manner, with earlier log4j 1.2 jars. To build these
(adjust as appropriate for your platform), each step assumes that
you've changed back to the base directory after the previous step:
Download and install Maven 2.0.4 or later
Open command shell
Place maven-2.0.4/bin on path
Checkout sandbox projects (where PROJECT is component, expression-
filter or receivers) using
svn co https://svn.apache.org/repos/asf/logging/sandbox/log4j/
PROJECT
Build and install expression-filter project
cd expression-filter; mvn install
Build and install (into local Maven repo) component project:
cd component; mvn install
Kludge an install of the freshly build log4j-1.2.15 into the local
maven repo
cd ~/.m2/repository/log4j/log4j
mkdir 1.2.15
cd 1.2.15
# copy existing log4j-1.2.14.pom, but change version number
sed s/1.2.14/1.2.15/ ../1.2.14/log4j-1.2.14.pom > log4j-1.2.15.pom
# copy log4j-1.2.15.jar into same location
Build and install receivers
cd receivers; mvn install
Replace log4j-1.3alpha-8.jar in chainsaw.lib with log4j-1.2.15.jar
and the three generated apache-log4j-*.jars (located in the target
subdirectory of each project).
Apply patch described below and build as normal
The following patch should allow chainsaw to build either against the
SVN head of log4j 1.3 or the 1.2 recipe described above:
Index: src/java/org/apache/log4j/chainsaw/LogUI.java
===================================================================
--- src/java/org/apache/log4j/chainsaw/LogUI.java (revision 527248)
+++ src/java/org/apache/log4j/chainsaw/LogUI.java (working copy)
@@ -103,7 +103,7 @@
import org.apache.log4j.chainsaw.receivers.ReceiversPanel;
import org.apache.log4j.chainsaw.version.VersionManager;
import org.apache.log4j.helpers.Constants;
-import org.apache.log4j.joran.JoranConfigurator;
+import org.apache.log4j.xml.DOMConfigurator;
import org.apache.log4j.net.SocketNodeEventListener;
import org.apache.log4j.plugins.Plugin;
import org.apache.log4j.plugins.PluginEvent;
@@ -1888,8 +1888,7 @@
try {
// we temporarily swap the TCCL so that plugins can
find resources
Thread.currentThread().setContextClassLoader
(classLoader);
- JoranConfigurator jc = new JoranConfigurator();
- jc.doConfigure(url, LogManager.getLoggerRepository());
+ DOMConfigurator.configure(url);
}finally{
// now switch it back...
Thread.currentThread().setContextClassLoader
(previousTCCL);
Index: src/java/org/apache/log4j/chainsaw/layout/EventDetailLayout.java
===================================================================
--- src/java/org/apache/log4j/chainsaw/layout/EventDetailLayout.java
(revision 527248)
+++ src/java/org/apache/log4j/chainsaw/layout/EventDetailLayout.java
(working copy)
@@ -190,16 +190,15 @@
li = formatLocationInfo(event);
}
Hashtable properties = formatProperties(event);
- LoggingEvent copy = new LoggingEvent();
- copy.setLogger(logger);
- copy.setTimeStamp(event.getTimeStamp());
- copy.setLevel(event.getLevel());
- copy.setThreadName(threadName);
- copy.setMessage(msg);
- copy.setNDC(ndc);
- copy.setThrowableInformation(event.getThrowableInformation());
- copy.setLocationInformation(li);
- copy.setProperties(properties);
+ LoggingEvent copy = new LoggingEvent(null,
+ logger, event.getTimeStamp(),
+ event.getLevel(),
+ msg,
+ threadName,
+ event.getThrowableInformation(),
+ ndc,
+ li,
+ properties);
return copy;
}
Index: src/java/org/apache/log4j/chainsaw/layout/LayoutEditorPane.java
===================================================================
--- src/java/org/apache/log4j/chainsaw/layout/LayoutEditorPane.java
(revision 527248)
+++ src/java/org/apache/log4j/chainsaw/layout/LayoutEditorPane.java
(working copy)
@@ -181,16 +181,16 @@
ThrowableInformation tsr = new ThrowableInformation(new
Exception());
- event = new LoggingEvent();
- event.setLogger(Logger.getLogger("com.mycompany.mylogger"));
- event.setTimeStamp(new Date().getTime());
- event.setLevel(org.apache.log4j.Level.DEBUG);
- event.setThreadName("Thread-1");
- event.setMessage("The quick brown fox jumped over the lazy dog");
- event.setNDC("NDC string");
- event.setThrowableInformation(tsr);
- event.setLocationInformation(li);
- event.setProperties(hashTable);
+ event = new LoggingEvent("org.apache.log4j.Logger",
+ Logger.getLogger("com.mycompany.mylogger"),
+ new Date().getTime(),
+ org.apache.log4j.Level.DEBUG,
+ "The quick brown fox jumped over the lazy dog",
+ "Thread-1",
+ tsr,
+ "NDC string",
+ li,
+ hashTable);
}
Basically, an equivalent DOMConfigurator method is used to replace a
call to JoranConfigurator and a call to the LoggingEvent constructor
newly added to both log4j 1.2.x and log4j 1.3 replaces the default
construction of LoggingEvent and subsequent mutator calls.
Duplicating the LoggingEvent mutators would have required removing
"final" qualifiers from most members of LoggingEvent which was a more
substantial change than I wanted to do in 1.2.x.
I haven't had any success actually starting Chainsaw either against
log4j 1.2.x or 1.3. So I'd appreciate feedback or fixes to anything
that I didn't get right. I've now delayed income tax preparation by
several days and will now start working on that with a vengeance and
will not take offense if anyone wants to fix things directly in the SVN.
Hopefully the expression-filter project is usable with deployed
versions of log4j 1.2. Any feedback on that would also be appreciated.
If anyone wants to add documentation, write test cases, or port test
cases over from log4j 1.3, more power to you.
For more info on Maven 2, you can download "Better Builds With Maven"
from http://www.mergere.com/m2book_download.jsp
Re: Chainsaw dependencies on log4j 1.3
Posted by Curt Arnold <ca...@apache.org>.
I've split out the component model from log4j 1.3 to the sandbox as
http://svn.apache.org/repos/asf/logging/sandbox/log4j/component.
Builds with Maven 2.
I've cleaned up the code for the ExpressionFilter spin-off and
committed that and should have the Sandbox project set up tomorrow.
I haven't cleaned up the Receiver code, but have a local project that
works with the uncleaned up code.
With those projects, I was able to get past the unresolved symbols.
Chainsaw uses a frequently uses a few trivial methods
(LoggingEvent.getTimeStamp() and
LoggingEvent.locationInformationExists()) that were introduced in
log4j 1.3. I expect that I'll just add them to the log4j 1.2
branch. Will mean that Chainsaw will need to be deployed with a
log4j 1.2.15 or later, but that is a better solution than trying to
work around their absence.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw dependencies on log4j 1.3
Posted by Paul Smith <ps...@aconex.com>.
>
> That wasn't the intent. I'd like to bundle the thing so that
> Chainsaw could be built (at least in the interim) with log4j 1.3 or
> with log4j 1.2.14 plus some additional jars. The hierarchy
> notification stuff wouldn't be in 1.2.14, but hopefully Chainsaw
> would only be slightly degraded with it missing. After we are
> comfortable that the log4j 1.2.x plus additional jars is working,
> then we can break the link with log4j 1.3.
>
Certainly worth exploring.
>> I like the idea of breaking out the Receiver stuff into an
>> optional jar for 1.2. I can't remember if log4j1.2 had the
>> Plugins stuff, but even if it did, I'm sure I and others have made
>> some changes to that. Again, that could be ported, but we're
>> starting to make a significant 1.2 change, and wouldn't it make
>> more sense to call it....1.3? :)
>>
>
> log4j 1.2 did not have the org.apache.log4j.plugin package. I
> wasn't suggesting reworking that component model into log4j 1.2.
> I'd suspect that log4j 2.0 would use OSGi (likely Apache Felix) or
> some other established component model in place of the log4j 1.3
> plugin package. I guess the plugin stuff could be spun off as a
> distinct package that is a dependency of the receiver package and
> chainsaw.
>
AFAIK, Receivers are really the only plugins at the moment. It
raises the question of how we support any users that have currently
'bound' themselves to log4j1.3 . I guess since it's still marked as
Alpha, then "them's the breaks".
>> As a very quick hack to 1.3, I was considering testing some 1.3
>> LoggingEvent changes to return MDC serialization compatibility,
>> even if it wasn't optimal.
>>
>
> Thought there was an open bug for log4j 1.3 serialization
> compatibility but could not find it.
I'm sure there's one, perhaps marked with Chainsaw instead of 1.3? I
think I saw one relating to MDC.
Paul
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw dependencies on log4j 1.3
Posted by Curt Arnold <ca...@apache.org>.
On Apr 10, 2007, at 5:28 PM, Paul Smith wrote:
> A good summary Curt. You'd be pointing us in the direction of
> making log4j 1.2 more like 1.3 though.
>
That wasn't the intent. I'd like to bundle the thing so that
Chainsaw could be built (at least in the interim) with log4j 1.3 or
with log4j 1.2.14 plus some additional jars. The hierarchy
notification stuff wouldn't be in 1.2.14, but hopefully Chainsaw
would only be slightly degraded with it missing. After we are
comfortable that the log4j 1.2.x plus additional jars is working,
then we can break the link with log4j 1.3.
> I like the idea of breaking out the Receiver stuff into an optional
> jar for 1.2. I can't remember if log4j1.2 had the Plugins stuff,
> but even if it did, I'm sure I and others have made some changes to
> that. Again, that could be ported, but we're starting to make a
> significant 1.2 change, and wouldn't it make more sense to call
> it....1.3? :)
>
log4j 1.2 did not have the org.apache.log4j.plugin package. I wasn't
suggesting reworking that component model into log4j 1.2. I'd
suspect that log4j 2.0 would use OSGi (likely Apache Felix) or some
other established component model in place of the log4j 1.3 plugin
package. I guess the plugin stuff could be spun off as a distinct
package that is a dependency of the receiver package and chainsaw.
> As a very quick hack to 1.3, I was considering testing some 1.3
> LoggingEvent changes to return MDC serialization compatibility,
> even if it wasn't optimal.
>
Thought there was an open bug for log4j 1.3 serialization
compatibility but could not find it.
---------------------------------------------------------------------
To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
For additional commands, e-mail: log4j-dev-help@logging.apache.org
Re: Chainsaw dependencies on log4j 1.3
Posted by Paul Smith <ps...@aconex.com>.
A good summary Curt. You'd be pointing us in the direction of making
log4j 1.2 more like 1.3 though.
I like the idea of breaking out the Receiver stuff into an optional
jar for 1.2. I can't remember if log4j1.2 had the Plugins stuff, but
even if it did, I'm sure I and others have made some changes to
that. Again, that could be ported, but we're starting to make a
significant 1.2 change, and wouldn't it make more sense to call it....
1.3? :)
As a very quick hack to 1.3, I was considering testing some 1.3
LoggingEvent changes to return MDC serialization compatibility, even
if it wasn't optimal.
On 11/04/2007, at 6:28 AM, Curt Arnold wrote:
> I did an experiment of building chainsaw against the current SVN
> for log4j 1.2 and have a rough analysis of the dependencies issues:
>
>
> [javac] Compiling 102 source files to /Users/curta/ls-svn/
> chainsaw/build
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/ChainsawAppender.java:23: cannot find symbol
> [javac] symbol : class Constants
> [javac] location: package org.apache.log4j.helpers
> [javac] import org.apache.log4j.helpers.Constants;
>
> This error occurs in several files where chainsaw attempts to
> access string constants APPLICATION_KEY, HOSTNAME_KEY and
> LOG4J_ID_KEY. The easiest remedy would add these constants to
> ChainsawConstants.
>
>
>
>
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/ChainsawAppenderHandler.java:30: package
> org.apache.log4j.rule does not exist
> [javac] import org.apache.log4j.rule.ExpressionRule;
> [javac] ^
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/ChainsawAppenderHandler.java:31: package
> org.apache.log4j.rule does not exist
> [javac] import org.apache.log4j.rule.Rule;
>
>
> Chainsaw makes extension use of the org.apache.log4j.rule package
> that supports org.apache.log4j.filter.ExpressionFilter and
> org.apache.log4j.LocationInfoFilter. Those filters may be useful
> to a log4j 1.2.x user, so it may be useful to backport them to be
> compatible with log4j 1.2.x and either incorporate them into log4j
> 1.2.x or make them available an add-on for log4j 1.2.x.
>
>
>
> [javac] ^
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/ChainsawAppenderHandler.java:33: cannot find symbol
> [javac] symbol : class LoggerRepositoryEx
> [javac] location: package org.apache.log4j.spi
> [javac] import org.apache.log4j.spi.LoggerRepositoryEx;
> [javac] ^
>
> The LoggerRepositoryEx interface added methods to monitor the
> addition of new loggers and appenders and several other functions.
> Will need to review how these are used. If they are added, it
> would likely have to be implemented in log4j 1.2.x itself.
>
>
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/ChainsawAppenderHandler.java:29: cannot find symbol
> [javac] symbol : class SocketReceiver
> [javac] location: package org.apache.log4j.net
> [javac] import org.apache.log4j.net.SocketReceiver;
> [javac] ^
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/LogUI.java:107: cannot find symbol
> [javac] symbol : class SocketNodeEventListener
> [javac] location: package org.apache.log4j.net
> [javac] import org.apache.log4j.net.SocketNodeEventListener;
> [javac] ^
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/ChainsawAppenderHandler.java:34: cannot find symbol
> [javac] symbol : class LoggingEventFieldResolver
> [javac] location: package org.apache.log4j.spi
> [javac] import org.apache.log4j.spi.LoggingEventFieldResolver;
> [javac] ^
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/ChainsawAppenderHandler.java:52: cannot find symbol
> [javac] symbol : class LoggingEventFieldResolver
> [javac] location: class
> org.apache.log4j.chainsaw.ChainsawAppenderHandler
> [javac] private final LoggingEventFieldResolver resolver =
> LoggingEventFieldResolver
> [javac] ^
> [javac] ^
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/receivers/PluginPropertyEditorPanel.java:54: cannot find
> symbol
> [javac] symbol : class SocketHubReceiver
> [javac] location: package org.apache.log4j.net
> [javac] import org.apache.log4j.net.SocketHubReceiver;
> [javac] ^
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/receivers/ReceiversPanel.java:71: cannot find symbol
> [javac] symbol : class SocketNodeEventListener
> [javac] location: package org.apache.log4j.net
> [javac] import org.apache.log4j.net.SocketNodeEventListener;
> [javac] ^
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/receivers/ReceiversPanel.java:72: cannot find symbol
> [javac] symbol : class SocketReceiver
> [javac] location: package org.apache.log4j.net
> [javac] import org.apache.log4j.net.SocketReceiver;
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/receivers/ReceiversPanel.java:435: cannot find symbol
> [javac] symbol : class Receiver
> [javac] location: class
> org.apache.log4j.chainsaw.receivers.ReceiversPanel
> [javac] private Receiver getCurrentlySelectedReceiver() {
> [javac] ^
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/FileMenu.java:41: cannot find symbol
> [javac] symbol : class UtilLoggingXMLDecoder
> [javac] location: package org.apache.log4j.xml
> [javac] import org.apache.log4j.xml.UtilLoggingXMLDecoder;
> [javac] ^
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/FileMenu.java:42: cannot find symbol
> [javac] symbol : class XMLDecoder
> [javac] location: package org.apache.log4j.xml
> [javac] import org.apache.log4j.xml.XMLDecoder;
> [javac] ^
>
> I'm guessing all the receiver stuff is unlikely to be used anywhere
> outside of Chainsaw. However, it might still be useful to package
> them up as a distinct package.
>
>
>
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/LogUI.java:106: package org.apache.log4j.joran does not exist
> [javac] import org.apache.log4j.joran.JoranConfigurator;
> [javac] ^
>
> Likely could be changed back to DOMConfigurator.
>
>
> [javac] /Users/curta/ls-svn/chainsaw/src/java/org/apache/log4j/
> chainsaw/LogUI.java:108: package org.apache.log4j.plugins does not
> exist
> [javac] import org.apache.log4j.plugins.Plugin;
>
> Chainsaw uses the plugins package internally and they are also used
> in the log4j receivers. I think it would probably be best to keep
> them with the receivers.
>
> My suggestions would be to start two new sandbox projects, one for
> the rule filters and one for the receivers+plugin. Alternately,
> rules could go into log4j 1.2 and receivers+plugin could go
> chainsaw. Change the org.apache.log4j.spi.Constant references to
> org.apache.log4j.chainsaw.ChainsawConstant references and review
> the usage LoggerRepositoryEx and DOMConfigurator.
>
> I've confirmed that log4j 1.2.x does serialize the MDC content, it
> is just that the log4j 1.3 deserialization doesn't pick it up.
> Likely if Chainsaw was hosted in log4j 1.2, the MDC content would
> show up for log4j 1.2 clients and disappear for log4j 1.3 clients.
> I think it is possible that you might be able to write a custom
> serialization that could read both log4j 1.2 and log4j 1.3
> serialization. I'm skeptical that it could be done with default
> serialization.
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: log4j-dev-unsubscribe@logging.apache.org
> For additional commands, e-mail: log4j-dev-help@logging.apache.org
>
Paul Smith
Core Engineering Manager
Aconex
The easy way to save time and money on your project
696 Bourke Street, Melbourne,
VIC 3000, Australia
Tel: +61 3 9240 0200 Fax: +61 3 9240 0299
Email: psmith@aconex.com www.aconex.com
This email and any attachments are intended solely for the addressee.
The contents may be privileged, confidential and/or subject to
copyright or other applicable law. No confidentiality or privilege is
lost by an erroneous transmission. If you have received this e-mail
in error, please let us know by reply e-mail and delete or destroy
this mail and all copies. If you are not the intended recipient of
this message you must not disseminate, copy or take any action in
reliance on it. The sender takes no responsibility for the effect of
this message upon the recipient's computer system.