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ü <[EMAIL PROTECTED]> 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ü <[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> > > -- > === message truncated === __________________________________________________ Do you Yahoo!? U2 on LAUNCH - Exclusive greatest hits videos http://launch.yahoo.com/u2 -- 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>
