avalon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Hohwiller <jo...@j-hohwiller.de>
Subject Re: commons-configuration and commons-logging
Date Mon, 07 Jun 2004 21:00:32 GMT
Hi Niclas,

thanks for your response...

On Saturday 05 June 2004 09:40, Niclas Hedhman wrote:
> On Saturday 05 June 2004 05:31, Jörg Hohwiller wrote:
> > seems that this list is more interested on philosophy about spam and the
> > universe than disscussions about the philosophy of avalon - nice jokes
> > about that spam anyways but I would like to see some response to my mail
> > or is it misplaced here???
> Not at all... Somehow, I have missed your mail, possibly due to it was sent
> in the middle of the transition from CVS to Subversion....
> Also, postings that are very 'neutral' have a tendency of not getting
> responses, i.e. "ok, I read it, but nothing much to add or dispute..."
> Anyway...
> > On Friday 21 May 2004 17:12, Jörg Hohwiller wrote:
> > > I can see there is commons-configuration (which seems as it came from
> > > avalon) and commons-logging. I saw in the archive that there was a
> > > discussion about logkit vs. commons-logging + log4j before.
> > > I would like to know if you are planning to directly use
> > > c-configuration and c-logging in the avalon framework API?
> As for Merlin, the answer to this is "No, we are not.".
> In logging, I think we need a more powerful classloading mechanism than
> commons-logging can support, but I am not sure whether we can provide a
> plugin for commons-logging in Avalon Logging, but that seems to be "cake on
> cake".
I just meant the API what for me is nothing more than given an
org.apache.commons.logging.Log in Configurable instead of
> I am not well versed in commons-configuration, and don't have any comments
> on why. It just hasn't been discussed.
> > > I personally think the commons initiative is a great thing and I can
> > > still remember myself digging deep in apache projects sources to find a
> > > ready to use cache, pool or whatever implementation.
> > > Now why not just using these APIs as part of the avalon API?
> > > I can see that changing an API this way in general is a bad thing
> > > because of loosing downward compatibility but on the other hand it is
> > > not a bid thing to replace org.apache.avalon.framework.configuration to
> > > org.apache.commons.configuration and org.apache.avalon.framework.logger
> > > to org.apache.commons.logging (okay the last one is not just a string
> > > replace).
> Well, being a framework, we have a fair amount of compatibility concerns,
> and replacements are out of the questions. Either a compatibility wrapper
> is provided or both are supported, and the component implementor makes a
> choice.
Of course I see your point.
> > > So all I am suggesting is think about it.
> > > Disscussions welcome...
> Change for the sake of change is not something I would typically spend my
> time on, and if no arguments are put forward of WHY a change should be
> done, I am sure it won't happen. What does the change bring to us (except
> increased maintenance)?
if "us" are the developers of avalon, jep! I only have the user perspective.
I do not know what the philosophy of the commons initiative is and am not
a "member" of the Apache Software Foundation. But I thought the idea would be
to avoid reinventing the wheel and having multiple implementations of the same 
thing. Then if a commons library is improved everything else using it 
benefits. For me this is like the Linux philosophy with the shell where there 
are lots of little basic programms like grep, sort, etc. They all do their 
job and they do it very well with all aspects of their scope. All together 
makes a very powerful conglomerate. 
Now what I see is that there are tons of logger and meta-loggers APIs and 
implementations for java. Why not deciding for a single one.
The packaging namespaces of java starts to make a political impression on
me - maybe the smalltalk approach was better. Seems that I lost the toppic :)
So if you do not like to change maybe you could convince commons-* to use your 
APIs instead ;)
> Cheers
> Niclas


To unsubscribe, e-mail: dev-unsubscribe@avalon.apache.org
For additional commands, e-mail: dev-help@avalon.apache.org

View raw message