You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@empire-db.apache.org by Francis De Brabandere <fr...@gmail.com> on 2011/01/24 18:18:28 UTC
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.
Re: empire-db-config?
Posted by Francis De Brabandere <fr...@gmail.com>.
Hi Rainer,
On Mon, Jan 24, 2011 at 11:22 PM, Rainer Döbele <do...@esteam.de> wrote:
> Hi Franics,
>
> thanks for your opinion.
> IMO it is OK to remove the XMLWriter class as it is not being used in core. The examples (basic and spring) use it though. On the other hand it's not doing any harm in core either.
Must have done something wrong as I did not find that dependency. And
indeed it does no harm but it's not clean either. Shouldn't we focus
on the DB side and remove other cruft? These are all things that
certainly should not be part of our public api, we don't want users
depending on those...
>
> The utility-class and the addXml() are a different story. They are used for retrieving data in XML format including metadata which can then be transformed to another format using XSLT. We can talk about a different way to generate the XML, but XML generation is part of the core functionality.
I see, do we have an example of that?
>
> In general I do also appreciate the change to SLF4J - although I wasn't sure whether it's still the best thing available (things change so rapidly these days).
> It's just a shame they have not included configuration in their facade. IMO logging configuration is as important as logging itself.
> What we need is a SLCF4J - i.e. a Simple Log Configuration Fascade for Java :-)
As empire-db merely is a db abstraction layer logging configuration is
out of it's scope, that's how I see it. You most of the time configure
that on the container or using a unified logfile for your whole
application.
>
> Still, I don't see the point in having this empire-db-config module.
> Why can't we just remove the logging configuration form XMLConfiguration and keep it in core?
> Just keep it small and simple - that what people like us for.
I agree, I'll revert my previous commit. Can you then take care of
moving the log4j stuff to the examples? Personally I don't see what's
wrong with a separate log4j file like most people are used to...
Cheers,
Francis
>
> Regards
> Rainer
>
>
> Francis De Brabandere wrote:
>> from: Francis De Brabandere [mailto:francisdb@gmail.com]
>> to: empire-db-dev@incubator.apache.org
>> re: Re: XMLWriter & co?
>>
>> Hi Rainer,
>>
>> Inline reply...
>>
>> On Mon, Jan 24, 2011 at 9:47 PM, Rainer Döbele <do...@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.
>
--
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.
empire-db-config?
Posted by Rainer Döbele <do...@esteam.de>.
Hi Franics,
thanks for your opinion.
IMO it is OK to remove the XMLWriter class as it is not being used in core. The examples (basic and spring) use it though. On the other hand it's not doing any harm in core either.
The utility-class and the addXml() are a different story. They are used for retrieving data in XML format including metadata which can then be transformed to another format using XSLT. We can talk about a different way to generate the XML, but XML generation is part of the core functionality.
In general I do also appreciate the change to SLF4J - although I wasn't sure whether it's still the best thing available (things change so rapidly these days).
It's just a shame they have not included configuration in their facade. IMO logging configuration is as important as logging itself.
What we need is a SLCF4J - i.e. a Simple Log Configuration Fascade for Java :-)
Still, I don't see the point in having this empire-db-config module.
Why can't we just remove the logging configuration form XMLConfiguration and keep it in core?
Just keep it small and simple - that what people like us for.
Regards
Rainer
Francis De Brabandere wrote:
> from: Francis De Brabandere [mailto:francisdb@gmail.com]
> to: empire-db-dev@incubator.apache.org
> re: Re: XMLWriter & co?
>
> Hi Rainer,
>
> Inline reply...
>
> On Mon, Jan 24, 2011 at 9:47 PM, Rainer Döbele <do...@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.
Re: XMLWriter & co?
Posted by Benjamin Venditti <be...@arcor.de>.
Hi there,
okay so i'll go and remove the logging configuration from
"XMLConfiguration" in the core and replace apache JCL with SLF4J.
Cheerio
Benjamin
Am 25.01.2011 23:00, schrieb Francis De Brabandere:
> +1
>
> On Tue, Jan 25, 2011 at 10:56 PM, Rainer Döbele<do...@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
>>>> <be...@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<do...@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.
>>>>
>>
>
>
Re: XMLWriter & co?
Posted by Francis De Brabandere <fr...@gmail.com>.
+1
On Tue, Jan 25, 2011 at 10:56 PM, Rainer Döbele <do...@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
>> > <be...@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<do...@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.
re: XMLWriter & co?
Posted by Rainer Döbele <do...@esteam.de>.
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
> > <be...@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<do...@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.
> >>>
> >>
> >
> >
Re: XMLWriter & co?
Posted by Benjamin Venditti <be...@arcor.de>.
Am 24.01.2011 23:57, schrieb Francis De Brabandere:
> On Mon, Jan 24, 2011 at 11:54 PM, Benjamin Venditti
> <be...@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<do...@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.
>>>
>>
>
>
Re: XMLWriter & co?
Posted by Francis De Brabandere <fr...@gmail.com>.
On Mon, Jan 24, 2011 at 11:54 PM, Benjamin Venditti
<be...@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().
>
> 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<do...@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.
Re: XMLWriter & co?
Posted by Benjamin Venditti <be...@arcor.de>.
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.
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<do...@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.
>
>
Re: XMLWriter & co?
Posted by Francis De Brabandere <fr...@gmail.com>.
Hi Rainer,
Inline reply...
On Mon, Jan 24, 2011 at 9:47 PM, Rainer Döbele <do...@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.
re: XMLWriter & co?
Posted by Rainer Döbele <do...@esteam.de>.
Hi Francis and Benjamin,
I am not at all happy with the idea to move all XML classes into a separate module.
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.
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.
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.
So do we really want to use SLF4J or are there other (better) alternatives?
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.
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.