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 Ricardo Moral <ri...@yahoo.com> on 2002/11/06 20:56:28 UTC
Need Help?
Hi! Mi name is Richard.
I'm writing you because I've been using Log4j for a
long time and I love it!
I think is time for me to give something in
recognition to your hard work. I've been looking to
your plan and there is an item assined to Ceki
involving the DOMConfigurator and the Digester API
from the Commons sub-project.
I've worked a lot with the Digester, using the
included rules and writing my own rules. I know very
well the code of both proyects and I think I can help.
Please let me know If I might be of help. And if so
tell me what are your plans for this item...
Greetings.
Richard.
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need Help?
Posted by Ceki Gülcü <ce...@qos.ch>.
DOM bashing is a popular passtime among Java developers. While it is
true that a Java specific API could have been offered a much nicer
interface, e.g. JDOM, the DOM API gets the job done. It is not pretty
but it works.
I had never given thought to the weight issue. What I like about DOM
is that given its tree-like structure where you can search for elements
forwards and backwards. You can't do that with SAX unless you
artificially recreate the tree structure.
The Ant developers faced a similar choice between SAX and DOM. I
wonder what they chose and why.
Don't let me stifle your creative energies. I am totally open to fresh
ideas and new implementations.
At 06:03 11.11.2002 -0800, Ricardo Moral wrote:
>I agree with you, the answer is not digester but the
>concepts behind digeter.
>
>Digester depends also on the BeansUtils Commons API,
>but if you want to implement your own rules there is
>no need for this API, except maybe for some small
>reflection functions that could be encapsulated inside
>a helper class.
>
>Actually what I had in mind is something more like a
>solution I've implemented once. For that project I
>included a very small edition adapted by me of the
>Digester API on an Applet. I had to adapt the digester
>API because the applet should be small and I needed
>the class to parse XML using SAX (using DOM in a
>applet is very expensive). The resulting API consisted
>on only of 6-7 classes + rules (wich could be included
>in a package in Log4j). This classes where the only
>clases needed to implement the funcionality (there was
>no need for c-l or bean utils or nothing else). Could
>there be some problems with the people from Digester
>if we do something like this?
>
>Also, don't you think that would be better if we could
>implement the XML configuring of Log4J using SAX
>instead of DOM?
>
>--- Ceki Gülcü <ce...@qos.ch> wrote:
> > At 06:43 08.11.2002 -0800, you wrote:
> > >Geki...
> > >
> > >I've been reading and exploring Jelly's source
> > >code/documentation. Although I think this is a very
> > >interesting product, It's too big and needs many
> > >libraries to be used as a solution to this kind of
> > >problem. I think Log4j must be as simple and small
> > as
> > >it could be.
> > >
> > >I think the digester is the ideal product to solve
> > the
> > >problem. As far as I can see the only drawback of
> > >Digester comes from his the SAX nature, and is the
> > >incapacity to obtain information of elements that
> > >wheren't already parsed (e.g. The problem with the
> > >Appenders that must be loaded on demand).
> >
> >
> > Digester depends on a bunch of libraries of which
> > commons-logging is
> > the most troublesome. I have written a document
> > about c-l:
> > http://qos.ch/logging/thinkAgain.html
> >
> > I hope that explains why we should not have log4j
> > depend on digester
> > which depends on c-l.
> >
> > On a more general note, the danger facing log4j
> > today is not
> > competition, but log4j itself. We must not trip over
> > ourselves and
> > fall by introducing serious bugs with new
> > functionality or
> > dependencies that can cause really bad headaches.
> >
> > >A solution for this problem could be to have an
> > >Appender manager class responsable of managing all
> > >appenders on the system... The appender manager
> > class
> > >could be initialized by the Digester with a dummy
> > >Appender implemenetation that represent references
> > to
> > >Appenders (holds only the initialization info for
> > the
> > >appender) and not the actual implementations. The
> > >appender manager could instantiate the real
> > appenders
> > >on demmand with the information extracted from the
> > >dummy appenders and then replace the dummy appender
> > >with the real appender and return it. This solution
> > >would require the Loggers to be initialized with
> > >references by name to the appenders stored on the
> > >AppenderManager and request the real appender in
> > the
> > >moment a log must be registered on the appender.
> > >
> > >What do u think?
> >
> >
> > This approach tries to fit the problem domain to the
> > tool (the
> > digester). This is fine. However, we could also try
> > to fit the tool to
> > the problem domain. More concretely, I think we
> > should concentrate on
> > the ideas behind digester rather than digester
> > itself. The
> > associations of patterns and actions into rules is
> > very powerful yet
> > rather easy to implement.
> >
> > By rolling a DOM based implementation of
> > digester-like functionality
> > we can build on the existing DOMConfigurator which
> > got pretty smart as
> > of late.
> >
> > If I am being too cryptic please do not hesitate to
> > ask for clarifications.
> >
> > >pd. Excuse my english but I do not have much
> > >experience writing in this language. :-)
> >
> > No worries, I think you are communicating very well.
> >
> > >Richard.
> > >
> > >--- Ceki Gülcü <ce...@qos.ch> wrote:
> > > >
> > > > Hi Richard,
> > > >
> > > > There was discussion about extensible log4j
> > config
> > > > files on this list and
> > > > commons-dev.
> > > >
> > > > Here are some mails I find relevant:
> > > >
> > > > I started with this:
> > > >
> > > > http://www.qos.ch/specs/joran-specs.html
> > > >
> > > > Then, started a commons-sandbox project called
> > > > joran. Then the following
> > > > happened:
> > > >
> > > >
> >
> >http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103461128905013&w=2
> > > >
> >
> >http://marc.theaimsgroup.com/?t=103462610700004&r=1&w=2
> > > >
> > > > James Strachan's commit:
> > > >
> >
> >http://marc.theaimsgroup.com/?t=103462610700004&r=1&w=2
> > > >
> > > > My response:
> > > >
> > > >
> >
> >http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103479543318721&w=2
> > > >
> > > > I hope it makes sense.
> > > >
> > > > At 11:56 06.11.2002 -0800, Ricardo Moral wrote:
> > > > >Hi! Mi name is Richard.
> > > > >
> > > > >I'm writing you because I've been using Log4j
> > for a
> > > > >long time and I love it!
> > > > >
> > > > >I think is time for me to give something in
> > > > >recognition to your hard work. I've been
> > looking to
> > > > >your plan and there is an item assined to Ceki
> > > > >involving the DOMConfigurator and the Digester
> > API
> > > > >from the Commons sub-project.
> > > > >
> > > > >I've worked a lot with the Digester, using the
> > > > >included rules and writing my own rules. I know
> > > > very
> > > > >well the code of both proyects and I think I
> > can
> > > > help.
> > > > >
> > > > >Please let me know If I might be of help. And
> > if so
> > > > >tell me what are your plans for this item...
> > > > >
> > > > >Greetings.
> > > > >Richard.
> > > > >
> > > >
> > >__________________________________________________
> > > > >Do you Yahoo!?
> > > > >HotJobs - Search new jobs daily now
> > > > >http://hotjobs.yahoo.com/
> > > > >
> > > > >--
> > > > >To unsubscribe, e-mail:
> > > >
> > <ma...@jakarta.apache.org>
> > > > >For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > > > --
> > > > Ceki
> > > >
> > > > TCP implementations will follow a general
> > principle
> > > > of robustness: be
> > > > conservative in what you do, be liberal in what
> > you
> > > > accept from
> > > > others. -- Jon Postel, RFC 793
> > > >
> > > >
> > > >
> > > > --
> > > > To unsubscribe, e-mail:
> > > >
> > <ma...@jakarta.apache.org>
> > > > For additional commands, e-mail:
> > > > <ma...@jakarta.apache.org>
> > > >
> > >
> > >
> > >__________________________________________________
> > >Do you Yahoo!?
> > >HotJobs - Search new jobs daily now
> > >http://hotjobs.yahoo.com/
> > >
> > >--
> > >To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > >For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> > --
> >
>=== message truncated ===
>
>
>__________________________________________________
>Do you Yahoo!?
>U2 on LAUNCH - Exclusive greatest hits videos
>http://launch.yahoo.com/u2
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Ceki
TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need Help?
Posted by robert burrell donkin <ro...@blueyonder.co.uk>.
On Monday, November 11, 2002, at 02:03 PM, Ricardo Moral wrote:
<snip>
> Could there be some problems with the people from Digester
> if we do something like this?
of course! i'll personally hide outside your house and then read vogon
poetry at your when you come out ;)
ceki discussed this kind of thing on the commons list a while back. no one
have even the merest hint of a problem. feel free to modify - that's what
open source is all about.
- robert
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need Help?
Posted by Ricardo Moral <ri...@yahoo.com>.
I agree with you, the answer is not digester but the
concepts behind digeter.
Digester depends also on the BeansUtils Commons API,
but if you want to implement your own rules there is
no need for this API, except maybe for some small
reflection functions that could be encapsulated inside
a helper class.
Actually what I had in mind is something more like a
solution I've implemented once. For that project I
included a very small edition adapted by me of the
Digester API on an Applet. I had to adapt the digester
API because the applet should be small and I needed
the class to parse XML using SAX (using DOM in a
applet is very expensive). The resulting API consisted
on only of 6-7 classes + rules (wich could be included
in a package in Log4j). This classes where the only
clases needed to implement the funcionality (there was
no need for c-l or bean utils or nothing else). Could
there be some problems with the people from Digester
if we do something like this?
Also, don't you think that would be better if we could
implement the XML configuring of Log4J using SAX
instead of DOM?
--- Ceki G�lc� <ce...@qos.ch> wrote:
> At 06:43 08.11.2002 -0800, you wrote:
> >Geki...
> >
> >I've been reading and exploring Jelly's source
> >code/documentation. Although I think this is a very
> >interesting product, It's too big and needs many
> >libraries to be used as a solution to this kind of
> >problem. I think Log4j must be as simple and small
> as
> >it could be.
> >
> >I think the digester is the ideal product to solve
> the
> >problem. As far as I can see the only drawback of
> >Digester comes from his the SAX nature, and is the
> >incapacity to obtain information of elements that
> >wheren't already parsed (e.g. The problem with the
> >Appenders that must be loaded on demand).
>
>
> Digester depends on a bunch of libraries of which
> commons-logging is
> the most troublesome. I have written a document
> about c-l:
> http://qos.ch/logging/thinkAgain.html
>
> I hope that explains why we should not have log4j
> depend on digester
> which depends on c-l.
>
> On a more general note, the danger facing log4j
> today is not
> competition, but log4j itself. We must not trip over
> ourselves and
> fall by introducing serious bugs with new
> functionality or
> dependencies that can cause really bad headaches.
>
> >A solution for this problem could be to have an
> >Appender manager class responsable of managing all
> >appenders on the system... The appender manager
> class
> >could be initialized by the Digester with a dummy
> >Appender implemenetation that represent references
> to
> >Appenders (holds only the initialization info for
> the
> >appender) and not the actual implementations. The
> >appender manager could instantiate the real
> appenders
> >on demmand with the information extracted from the
> >dummy appenders and then replace the dummy appender
> >with the real appender and return it. This solution
> >would require the Loggers to be initialized with
> >references by name to the appenders stored on the
> >AppenderManager and request the real appender in
> the
> >moment a log must be registered on the appender.
> >
> >What do u think?
>
>
> This approach tries to fit the problem domain to the
> tool (the
> digester). This is fine. However, we could also try
> to fit the tool to
> the problem domain. More concretely, I think we
> should concentrate on
> the ideas behind digester rather than digester
> itself. The
> associations of patterns and actions into rules is
> very powerful yet
> rather easy to implement.
>
> By rolling a DOM based implementation of
> digester-like functionality
> we can build on the existing DOMConfigurator which
> got pretty smart as
> of late.
>
> If I am being too cryptic please do not hesitate to
> ask for clarifications.
>
> >pd. Excuse my english but I do not have much
> >experience writing in this language. :-)
>
> No worries, I think you are communicating very well.
>
> >Richard.
> >
> >--- Ceki G�lc� <ce...@qos.ch> wrote:
> > >
> > > Hi Richard,
> > >
> > > There was discussion about extensible log4j
> config
> > > files on this list and
> > > commons-dev.
> > >
> > > Here are some mails I find relevant:
> > >
> > > I started with this:
> > >
> > > http://www.qos.ch/specs/joran-specs.html
> > >
> > > Then, started a commons-sandbox project called
> > > joran. Then the following
> > > happened:
> > >
> > >
>
>http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103461128905013&w=2
> > >
>
>http://marc.theaimsgroup.com/?t=103462610700004&r=1&w=2
> > >
> > > James Strachan's commit:
> > >
>
>http://marc.theaimsgroup.com/?t=103462610700004&r=1&w=2
> > >
> > > My response:
> > >
> > >
>
>http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103479543318721&w=2
> > >
> > > I hope it makes sense.
> > >
> > > At 11:56 06.11.2002 -0800, Ricardo Moral wrote:
> > > >Hi! Mi name is Richard.
> > > >
> > > >I'm writing you because I've been using Log4j
> for a
> > > >long time and I love it!
> > > >
> > > >I think is time for me to give something in
> > > >recognition to your hard work. I've been
> looking to
> > > >your plan and there is an item assined to Ceki
> > > >involving the DOMConfigurator and the Digester
> API
> > > >from the Commons sub-project.
> > > >
> > > >I've worked a lot with the Digester, using the
> > > >included rules and writing my own rules. I know
> > > very
> > > >well the code of both proyects and I think I
> can
> > > help.
> > > >
> > > >Please let me know If I might be of help. And
> if so
> > > >tell me what are your plans for this item...
> > > >
> > > >Greetings.
> > > >Richard.
> > > >
> > >
> >__________________________________________________
> > > >Do you Yahoo!?
> > > >HotJobs - Search new jobs daily now
> > > >http://hotjobs.yahoo.com/
> > > >
> > > >--
> > > >To unsubscribe, e-mail:
> > >
> <ma...@jakarta.apache.org>
> > > >For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> > > --
> > > Ceki
> > >
> > > TCP implementations will follow a general
> principle
> > > of robustness: be
> > > conservative in what you do, be liberal in what
> you
> > > accept from
> > > others. -- Jon Postel, RFC 793
> > >
> > >
> > >
> > > --
> > > To unsubscribe, e-mail:
> > >
> <ma...@jakarta.apache.org>
> > > For additional commands, e-mail:
> > > <ma...@jakarta.apache.org>
> > >
> >
> >
> >__________________________________________________
> >Do you Yahoo!?
> >HotJobs - Search new jobs daily now
> >http://hotjobs.yahoo.com/
> >
> >--
> >To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> >For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
> --
>
=== message truncated ===
__________________________________________________
Do you Yahoo!?
U2 on LAUNCH - Exclusive greatest hits videos
http://launch.yahoo.com/u2
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need Help?
Posted by Ceki Gülcü <ce...@qos.ch>.
At 06:43 08.11.2002 -0800, you wrote:
>Geki...
>
>I've been reading and exploring Jelly's source
>code/documentation. Although I think this is a very
>interesting product, It's too big and needs many
>libraries to be used as a solution to this kind of
>problem. I think Log4j must be as simple and small as
>it could be.
>
>I think the digester is the ideal product to solve the
>problem. As far as I can see the only drawback of
>Digester comes from his the SAX nature, and is the
>incapacity to obtain information of elements that
>wheren't already parsed (e.g. The problem with the
>Appenders that must be loaded on demand).
Digester depends on a bunch of libraries of which commons-logging is
the most troublesome. I have written a document about c-l:
http://qos.ch/logging/thinkAgain.html
I hope that explains why we should not have log4j depend on digester
which depends on c-l.
On a more general note, the danger facing log4j today is not
competition, but log4j itself. We must not trip over ourselves and
fall by introducing serious bugs with new functionality or
dependencies that can cause really bad headaches.
>A solution for this problem could be to have an
>Appender manager class responsable of managing all
>appenders on the system... The appender manager class
>could be initialized by the Digester with a dummy
>Appender implemenetation that represent references to
>Appenders (holds only the initialization info for the
>appender) and not the actual implementations. The
>appender manager could instantiate the real appenders
>on demmand with the information extracted from the
>dummy appenders and then replace the dummy appender
>with the real appender and return it. This solution
>would require the Loggers to be initialized with
>references by name to the appenders stored on the
>AppenderManager and request the real appender in the
>moment a log must be registered on the appender.
>
>What do u think?
This approach tries to fit the problem domain to the tool (the
digester). This is fine. However, we could also try to fit the tool to
the problem domain. More concretely, I think we should concentrate on
the ideas behind digester rather than digester itself. The
associations of patterns and actions into rules is very powerful yet
rather easy to implement.
By rolling a DOM based implementation of digester-like functionality
we can build on the existing DOMConfigurator which got pretty smart as
of late.
If I am being too cryptic please do not hesitate to ask for clarifications.
>pd. Excuse my english but I do not have much
>experience writing in this language. :-)
No worries, I think you are communicating very well.
>Richard.
>
>--- Ceki Gülcü <ce...@qos.ch> wrote:
> >
> > Hi Richard,
> >
> > There was discussion about extensible log4j config
> > files on this list and
> > commons-dev.
> >
> > Here are some mails I find relevant:
> >
> > I started with this:
> >
> > http://www.qos.ch/specs/joran-specs.html
> >
> > Then, started a commons-sandbox project called
> > joran. Then the following
> > happened:
> >
> >
>http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103461128905013&w=2
> >
>http://marc.theaimsgroup.com/?t=103462610700004&r=1&w=2
> >
> > James Strachan's commit:
> >
>http://marc.theaimsgroup.com/?t=103462610700004&r=1&w=2
> >
> > My response:
> >
> >
>http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103479543318721&w=2
> >
> > I hope it makes sense.
> >
> > At 11:56 06.11.2002 -0800, Ricardo Moral wrote:
> > >Hi! Mi name is Richard.
> > >
> > >I'm writing you because I've been using Log4j for a
> > >long time and I love it!
> > >
> > >I think is time for me to give something in
> > >recognition to your hard work. I've been looking to
> > >your plan and there is an item assined to Ceki
> > >involving the DOMConfigurator and the Digester API
> > >from the Commons sub-project.
> > >
> > >I've worked a lot with the Digester, using the
> > >included rules and writing my own rules. I know
> > very
> > >well the code of both proyects and I think I can
> > help.
> > >
> > >Please let me know If I might be of help. And if so
> > >tell me what are your plans for this item...
> > >
> > >Greetings.
> > >Richard.
> > >
> > >__________________________________________________
> > >Do you Yahoo!?
> > >HotJobs - Search new jobs daily now
> > >http://hotjobs.yahoo.com/
> > >
> > >--
> > >To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > >For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
> > --
> > Ceki
> >
> > TCP implementations will follow a general principle
> > of robustness: be
> > conservative in what you do, be liberal in what you
> > accept from
> > others. -- Jon Postel, RFC 793
> >
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <ma...@jakarta.apache.org>
> > For additional commands, e-mail:
> > <ma...@jakarta.apache.org>
> >
>
>
>__________________________________________________
>Do you Yahoo!?
>HotJobs - Search new jobs daily now
>http://hotjobs.yahoo.com/
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Ceki
TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need Help?
Posted by Ricardo Moral <ri...@yahoo.com>.
Geki...
I've been reading and exploring Jelly's source
code/documentation. Although I think this is a very
interesting product, It's too big and needs many
libraries to be used as a solution to this kind of
problem. I think Log4j must be as simple and small as
it could be.
I think the digester is the ideal product to solve the
problem. As far as I can see the only drawback of
Digester comes from his the SAX nature, and is the
incapacity to obtain information of elements that
wheren't already parsed (e.g. The problem with the
Appenders that must be loaded on demand).
A solution for this problem could be to have an
Appender manager class responsable of managing all
appenders on the system... The appender manager class
could be initialized by the Digester with a dummy
Appender implemenetation that represent references to
Appenders (holds only the initialization info for the
appender) and not the actual implementations. The
appender manager could instantiate the real appenders
on demmand with the information extracted from the
dummy appenders and then replace the dummy appender
with the real appender and return it. This solution
would require the Loggers to be initialized with
references by name to the appenders stored on the
AppenderManager and request the real appender in the
moment a log must be registered on the appender.
What do u think?
pd. Excuse my english but I do not have much
experience writing in this language. :-)
Richard.
--- Ceki G�lc� <ce...@qos.ch> wrote:
>
> Hi Richard,
>
> There was discussion about extensible log4j config
> files on this list and
> commons-dev.
>
> Here are some mails I find relevant:
>
> I started with this:
>
> http://www.qos.ch/specs/joran-specs.html
>
> Then, started a commons-sandbox project called
> joran. Then the following
> happened:
>
>
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103461128905013&w=2
>
http://marc.theaimsgroup.com/?t=103462610700004&r=1&w=2
>
> James Strachan's commit:
>
http://marc.theaimsgroup.com/?t=103462610700004&r=1&w=2
>
> My response:
>
>
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103479543318721&w=2
>
> I hope it makes sense.
>
> At 11:56 06.11.2002 -0800, Ricardo Moral wrote:
> >Hi! Mi name is Richard.
> >
> >I'm writing you because I've been using Log4j for a
> >long time and I love it!
> >
> >I think is time for me to give something in
> >recognition to your hard work. I've been looking to
> >your plan and there is an item assined to Ceki
> >involving the DOMConfigurator and the Digester API
> >from the Commons sub-project.
> >
> >I've worked a lot with the Digester, using the
> >included rules and writing my own rules. I know
> very
> >well the code of both proyects and I think I can
> help.
> >
> >Please let me know If I might be of help. And if so
> >tell me what are your plans for this item...
> >
> >Greetings.
> >Richard.
> >
> >__________________________________________________
> >Do you Yahoo!?
> >HotJobs - Search new jobs daily now
> >http://hotjobs.yahoo.com/
> >
> >--
> >To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> >For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
> --
> Ceki
>
> TCP implementations will follow a general principle
> of robustness: be
> conservative in what you do, be liberal in what you
> accept from
> others. -- Jon Postel, RFC 793
>
>
>
> --
> To unsubscribe, e-mail:
> <ma...@jakarta.apache.org>
> For additional commands, e-mail:
> <ma...@jakarta.apache.org>
>
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Need Help?
Posted by Ceki Gülcü <ce...@qos.ch>.
Hi Richard,
There was discussion about extensible log4j config files on this list and
commons-dev.
Here are some mails I find relevant:
I started with this:
http://www.qos.ch/specs/joran-specs.html
Then, started a commons-sandbox project called joran. Then the following
happened:
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103461128905013&w=2
http://marc.theaimsgroup.com/?t=103462610700004&r=1&w=2
James Strachan's commit:
http://marc.theaimsgroup.com/?t=103462610700004&r=1&w=2
My response:
http://marc.theaimsgroup.com/?l=jakarta-commons-dev&m=103479543318721&w=2
I hope it makes sense.
At 11:56 06.11.2002 -0800, Ricardo Moral wrote:
>Hi! Mi name is Richard.
>
>I'm writing you because I've been using Log4j for a
>long time and I love it!
>
>I think is time for me to give something in
>recognition to your hard work. I've been looking to
>your plan and there is an item assined to Ceki
>involving the DOMConfigurator and the Digester API
>from the Commons sub-project.
>
>I've worked a lot with the Digester, using the
>included rules and writing my own rules. I know very
>well the code of both proyects and I think I can help.
>
>Please let me know If I might be of help. And if so
>tell me what are your plans for this item...
>
>Greetings.
>Richard.
>
>__________________________________________________
>Do you Yahoo!?
>HotJobs - Search new jobs daily now
>http://hotjobs.yahoo.com/
>
>--
>To unsubscribe, e-mail: <ma...@jakarta.apache.org>
>For additional commands, e-mail: <ma...@jakarta.apache.org>
--
Ceki
TCP implementations will follow a general principle of robustness: be
conservative in what you do, be liberal in what you accept from
others. -- Jon Postel, RFC 793
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>