incubator-empire-db-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rainer Döbele <doeb...@esteam.de>
Subject re: XMLWriter & co?
Date Tue, 25 Jan 2011 21:56:40 GMT
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:benjamin.venditti@arcor.de]
> to: empire-db-dev@incubator.apache.org
> 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
> > <benjamin.venditti@arcor.de>  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<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