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. > >>> > >> > > > >
