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ü <[EMAIL PROTECTED]> 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:
> <mailto:log4j-dev-unsubscribe@;jakarta.apache.org>
> >For additional commands, e-mail:
> <mailto:log4j-dev-help@;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:
> <mailto:log4j-dev-unsubscribe@;jakarta.apache.org>
> For additional commands, e-mail:
> <mailto:log4j-dev-help@;jakarta.apache.org>
>
__________________________________________________
Do you Yahoo!?
HotJobs - Search new jobs daily now
http://hotjobs.yahoo.com/
--
To unsubscribe, e-mail: <mailto:log4j-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@;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: <mailto:log4j-dev-unsubscribe@;jakarta.apache.org>
For additional commands, e-mail: <mailto:log4j-dev-help@;jakarta.apache.org>
