+1 On Tue, Jan 25, 2011 at 10:56 PM, Rainer Döbele <[email protected]> wrote: > Hi Folks, > > I am so busy, I can only answer at night. > > Thanks for removing that module again. > I really would not like to have yet another jar. > > So basically we agree on the following (don't we): > > 1. we don't need another module, XMLConfiguration stays in core > > 2. Logging configuration is not our business - so we remove that code from > XMLConfiguration > > 3. JCL gets replaced by SLF4J. The Examples still use Log4J over brigde. > Logging configuration can go in a separate file (or we copy the current code > over) > > Regards > Rainer > > > Benjamin Venditti wrote: >> from: Benjamin Venditti [mailto:[email protected]] >> to: [email protected] >> re: Re: XMLWriter & co? >> >> Am 24.01.2011 23:57, schrieb Francis De Brabandere: >> > On Mon, Jan 24, 2011 at 11:54 PM, Benjamin Venditti >> > <[email protected]> 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<[email protected]> >> 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:[email protected]] >> >>>>> to: [email protected] >> >>>>> 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. >> >>> >> >> >> > >> > > >
-- http://www.somatik.be Microsoft gives you windows, Linux gives you the whole house.
