incubator-empire-db-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Venditti <>
Subject Re: XMLWriter & co?
Date Mon, 24 Jan 2011 23:26:02 GMT
Am 24.01.2011 23:57, schrieb Francis De Brabandere:
> On Mon, Jan 24, 2011 at 11:54 PM, Benjamin Venditti
> <>  wrote:
>> 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.
> I'm still for doing this but in fact there is always the commons
> logging slf4j bridge.
> If we would be one of the first projects to migrate to slf4j I would
> understand... But slf4j has been around for a while now and has proven
> its benefits, like the parametrized logging instead of isXxxEnabled().
I'm still for doing this, too.
     - slf4j is considered the better choice
     - it is established
     - we should get rid of the specific implementation anyway

However i have not enough experience with logging (JCL and jsf4l) for 
giving a prognosis on the impact.

>> 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<>    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:
>>>> 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
>>> 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 []
>>>>> to:
>>>>> 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
>>>>> --
>>>>> Microsoft gives you windows, Linux gives you the whole house.

View raw message