incubator-empire-db-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Venditti <benjamin.vendi...@arcor.de>
Subject Re: XMLWriter & co?
Date Mon, 24 Jan 2011 22:54:59 GMT
Hi Rainer and Francis,

i understand the problem of a big impact on the project without having 
much benefit (just replacing one api with another, a lot of changes in 
the core). Right now i see two benefits on switching to slf4j.
     1. we shouldn't force the users to use a specific implementation 
(it is often dictated of the context the application is developed in)
     2. slf4j is considered as the better logging system.

I think the main benefit is the first one and that does not involve 
switching to a different api at all (please correct me if a am wrong). 
We could stay with JCL for now but remove the log4j dependency. And 
later on we can still go for migrating JCL to slf4j if we want.

Cheerio
     Benjamin



Am 24.01.2011 22:36, schrieb Francis De Brabandere:
> Hi Rainer,
>
> Inline reply...
>
> On Mon, Jan 24, 2011 at 9:47 PM, Rainer Döbele<doebele@esteam.de>  wrote:
>> Hi Francis and Benjamin,
>>
>> I am not at all happy with the idea to move all XML classes into a separate module.
> In fact we want to move the log4j dependency to a separate module to
> to get rid of the dependency to log4j, if we remove log4j code we can
> merge it back into core. I have no problem with that. I'm not moving
> all xml to the module either.
>
>> Before we go too far, we should consider the impacts as well as different options.
>> First of all I don't like the idea of yet another module - even one with just a few
lines of code.
>> Second we need to consider backward compatibility as much as we can. It's OK if we're
not 100% compatible 99% will do, but we cannot just change it all.
> I somewhat agree, this slf4j change is not breaking anything, for
> legacy compatibility you just add slf4j-log4j12-1.6.1.jar to your
> classpath and everything is as before, all slf4j calls are forwarded
> to log4j
>
>> Before we start, can we please define our goal and keep the impact on the existing
code base to a minimum to achieve that goal?
>>
>> I know I revived this issue myself recently, but now I am not so sure anymore whether
this was a good idea.
>> First I would like to discuss whether we really want to replace log4j with SLF4J.
> We replace commons logging with slf4j, not log4j, anyway it's a bad
> idea for a framework to enforce a logging implementation and commons
> logging has its issues:
> http://www.slf4j.org/faq.html#yet_another_facade
>
>> After all its replacing one dependency by another with even losing some functionality.
If you see it from that perspective it's doesn't really sound like a good deal, does it? Besides
you would still need a logger in the example which means adding log4j there again.
> Whatever logger facacade you use you need an implemention behind it. I
> don't care which one we use, slf4j works with all. I have absolutely
> no problem with using log4j in the examples. We just should not force
> log4j to our users.
>
>> So do we really want to use SLF4J or are there other (better) alternatives?
> Slf4j is the standard these days, look around at other apache java projects
> http://www.slf4j.org/ has a small list of examples
>
>> Second I would only remove the logging configuration from XMLConfiguration, nothing
else and leave the rest in place. We must then implement logging configuration in each of
the examples separately, but this is not a big issue.
> I was just asking some questions about the xml, it's my personal
> opinion, I don't want to force anything. But I still have no idea why
> we need that class full of utility methods and the addXml() methods.
>
> My changes until now are minor and can easily be reverted, switching
> to slf4j of course has a bigger impact on the codebase
>
> Cheers,
> Francis
>
>> Regards
>> Rainer
>>
>>
>> Francis De Brabandere wrote:
>>> from: Francis De Brabandere [mailto:francisdb@gmail.com]
>>> to: empire-db-dev@incubator.apache.org
>>> re: XMLWriter&  co?
>>>
>>> Hi Rainer,
>>>
>>> I found this unused class in Empire-DB: XMLWriter. Can I remove it?
>>>
>>> Futher, what are the public abstract Element addXml(Element parent,
>>> long flags); methods in record, column, view and ... used for? I
>>> suppose they can write query info to xml? What would this be used for?
>>> Is there some code that does the reverse?
>>>
>>> I think we should try to keep the number of methods on our classes to
>>> a minimum so that a user can do ctrl-space in his IDE and have a clear
>>> idea what they can/schould do. Should XML export functionality exist
>>> in our core database related classes?
>>>
>>> Greets,
>>>
>>> Francis
>>>
>>> --
>>> http://www.somatik.be
>>> Microsoft gives you windows, Linux gives you the whole house.
>
>


Mime
View raw message