On Fri, 07 Oct 2005 11:14:29 -0400, Andrus Adamchik
<andru..bjectstyle.org> wrote:
> Log4J -> commons-logging. I thought of that switch as long term plan and
> we definitely need to investigate how most common containers behave. I
> remember Cris also voiced some concerns over it. And the longer we drag
> the foot on it, the higher the chance that that people find solutions to
> the current bugs :-) In 1.2 (a) client stuff will be Log4J-free and (b)
> we deprecated all public references to Log4J in the API - this makes me
> happy for the time being... I don't know if we have any reason to pursue
> the switch immediately.
I guess I'm with Cris on this one. I'm not sure I've ever seen anyone use
commons-logging with anything but log4j. It seems like abstraction for
the sake of abstraction, only adding additional overhead.
> Still... I like JDOM and in the past I voted for including it in
> Cayenne. But now that I want to use XML features on the client, and keep
> client library light at the same time, I wouldn't mind if we rid of this
> dependency and stick with JDK. Kevin, how bad do you think this is (even
> if it means that we copy/paste a *few* JDOM utility classes to Cayenne
> utilities)? I am not pushing for this, just wanted to get a feel...
I'd have to look into it and see what could be imported. Generating the
XML is generally a far easier than parsing it, so we may be able to just
do one manually and import some utility functions for the other. Of
course, the motivating factor for using JDOM was to have an easy to use
XML API and not having to muck around with more cumbersome solutions. So,
I'll see how much of a hit this actually would be. At least with the unit
tests in place it'll be easy to tell if something breaks ;-)
-- Kevin
This archive was generated by hypermail 2.0.0 : Fri Oct 07 2005 - 12:17:11 EDT