empire-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francis De Brabandere <franci...@gmail.com>
Subject Re: XMLWriter & co?
Date Tue, 25 Jan 2011 22:00:29 GMT
+1

On Tue, Jan 25, 2011 at 10:56 PM, Rainer Döbele <doebele@esteam.de> 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: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.
>> >>>
>> >>
>> >
>> >
>
>



-- 
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.

Mime
View raw message