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 Benjamin Venditti <be...@arcor.de> on 2011/01/24 01:22:38 UTC
EMPIREDB-38, switch to slf4j
Hey there,
i thought i could contribute a little for the next release and had a
look at the open-issues list for the upcoming release. I picked up
EMPIREDB-38 "switch to slf4j" as i think i can handle it (not so sure
with the other issues), and it shows to be unassigned.
My first impression is that it involves not to much work, we would have
to get rid of calls to "log.fatal(...)" as slf4j just offers 5 instead
of 6 logging levels. Do we make any destinction between fatal and
"normal" errors? If not, we can simply map fatal to error.
slf4j.Logger: debug, error,
info, trace, warn
apache.commons.logging.Log: trace, debug, info, warn, error, fatal
And there is a "LogFactory.releaseAll();" which i'm not sure how to map
in slf4j.
The "DOMConfiguration" stuff will be removed as far is i understood, as
this is neccessary for the configuration of the specific logging
implementation which will now go into a different config file.
I suggest to switch logging to slf4j in the whole project. That way i
could start with non crutial parts of the project, like the examples,
and i wouldn't have to worry about messing up the core. And in the end
we will have consistent logging in the whole project.
Please let me know what you think?
Best Regards
Am 22.01.2011 19:34, schrieb Francis De Brabandere:
> Hello there.
>
> As empire-db is struggling a bit to grow a community, and we need a
> bigger community to graduate, we want to involve our users in the
> decision on where to go with the project.
>
> Below you'll find some questions and we would be delighted to hear
> your comments!
>
> * Where do you use empire-db? or what keeps you from using empire-db?
> * If you evaluated empire-db but switched to something else we would
> like to know what you are using.
> * How do you feel about the project?
> * Is there anything we could do better?
> * What should we put more effort into?
> * Would you be interested in contributing. For example helping with
> documentation, examples, blog posts, or adding functionality.
>
> Thanks,
>
> The empire-db team.
>
> -- our incubator report as reference below --
> http://wiki.apache.org/incubator/January2011
>
> Empire-db
>
> Apache Empire-db is a relational database abstraction layer that
> allows developers to take a more SQL-centric approach in application
> development than traditional ORM frameworks. Its focus is to allow
> highly efficient database operations in combination with a maximum of
> compile-time-safety and DBMS independence.
>
> Project development since the last report
>
> Last December we have finished and published release 2.0.7 that
> features some minor improvements and bug fixes. Currently we are
> working on release 2.1.0 with more significant improvements.
>
> Issues to address in the move towards graduation and community development
>
> After now being 2 and a half years in the incubator we have managed to
> successfully implement and establish the Apache development and
> release cycle, we have published several releases and we have received
> good feedback from users who are subscribed to the dev and user lists.
>
> However during all this time, we have still not managed to get
> ourselves known to a wider audience and to get a significant amount of
> public attention, most certainly due to the fact that have not managed
> to work on publicity as much as on code. Also our community currently
> consists of only 3 active committers that are regularly contributing
> to the project.
>
> For this reason questions about the future of the project and whether
> we will ever be able to graduate have been raised. While the remaining
> active committers are determined to continue their project commitment
> and to work towards graduation it is still unclear by which measures
> new committers can be won to join the project.
>
> Hence, for the coming months answering this question and establishing
> the corresponding measures should be our focus. One way of answering
> this question could be to move this discussion to the dev list in
> order to find out how our subscribers feel about the status of the
> project. Also it might make sense to combine the user and dev lists in
> order to prevent subscribers from missing information and getting them
> more involved in the project.
>
Re: EMPIREDB-38, switch to slf4j
Posted by Francis De Brabandere <fr...@gmail.com>.
In fact his is quite flexible as we could use the commons logging to
slf4j bridge to have both working but I would go for all in one anyway
as I don't want our users to be forced to include the bridge.
Just remove commons logging in all poms and that should point you to
what to change.
The examples can keep using log4j for logging, all we need is to have
a runtime dependency on the slf4j to log4j bindings in those. so that
slf4j logging is forwarded to log4j.
I can help out this evening if you have problems with the conversion.
Cheers,
Francis
On Mon, Jan 24, 2011 at 12:14 PM, Benjamin Venditti
<be...@arcor.de> wrote:
> Hi Francis,
>
> would be great if you could put the org.apache.empire.xml package to a
> separate module.
> I'll start switching to slf4j later this evening.
>
> What do you think would be best? Switch each module successively or all in
> one step?
>
> Cheerio,
> Benjamin
>
>
>
> Am 24.01.2011 09:50, schrieb Francis De Brabandere:
>>
>> Hi Benjamin,
>>
>> Maybe I would first split off the org.apache.empire.xml package to a
>> empire-db-config module that can still depend on log4j.
>>
>> I can take care of that today. Afterwards we can switch everything to
>> slf4j except that config. We need to make sure we sync here and work
>> fast so that not everybody is blocked waiting for this big change...
>>
>> Shall I make that change?
>>
>> Also for slf4j make sure we switch to the parametrized logging and you
>> could also remove a lot of unneeded String.valueOf() calls.
>>
>> Cheers,
>> Francis
>>
>> On Mon, Jan 24, 2011 at 1:22 AM, Benjamin Venditti
>> <be...@arcor.de> wrote:
>>>
>>> Hey there,
>>>
>>> i thought i could contribute a little for the next release and had a look
>>> at
>>> the open-issues list for the upcoming release. I picked up EMPIREDB-38
>>> "switch to slf4j" as i think i can handle it (not so sure with the other
>>> issues), and it shows to be unassigned.
>>>
>>> My first impression is that it involves not to much work, we would have
>>> to
>>> get rid of calls to "log.fatal(...)" as slf4j just offers 5 instead of 6
>>> logging levels. Do we make any destinction between fatal and "normal"
>>> errors? If not, we can simply map fatal to error.
>>>
>>> slf4j.Logger: debug, error, info,
>>> trace, warn
>>> apache.commons.logging.Log: trace, debug, info, warn, error,
>>> fatal
>>>
>>> And there is a "LogFactory.releaseAll();" which i'm not sure how to map
>>> in
>>> slf4j.
>>>
>>> The "DOMConfiguration" stuff will be removed as far is i understood, as
>>> this
>>> is neccessary for the configuration of the specific logging
>>> implementation
>>> which will now go into a different config file.
>>>
>>> I suggest to switch logging to slf4j in the whole project. That way i
>>> could
>>> start with non crutial parts of the project, like the examples, and i
>>> wouldn't have to worry about messing up the core. And in the end we will
>>> have consistent logging in the whole project.
>>>
>>> Please let me know what you think?
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Am 22.01.2011 19:34, schrieb Francis De Brabandere:
>>>>
>>>> Hello there.
>>>>
>>>> As empire-db is struggling a bit to grow a community, and we need a
>>>> bigger community to graduate, we want to involve our users in the
>>>> decision on where to go with the project.
>>>>
>>>> Below you'll find some questions and we would be delighted to hear
>>>> your comments!
>>>>
>>>> * Where do you use empire-db? or what keeps you from using empire-db?
>>>> * If you evaluated empire-db but switched to something else we would
>>>> like to know what you are using.
>>>> * How do you feel about the project?
>>>> * Is there anything we could do better?
>>>> * What should we put more effort into?
>>>> * Would you be interested in contributing. For example helping with
>>>> documentation, examples, blog posts, or adding functionality.
>>>>
>>>> Thanks,
>>>>
>>>> The empire-db team.
>>>>
>>>> -- our incubator report as reference below --
>>>> http://wiki.apache.org/incubator/January2011
>>>>
>>>> Empire-db
>>>>
>>>> Apache Empire-db is a relational database abstraction layer that
>>>> allows developers to take a more SQL-centric approach in application
>>>> development than traditional ORM frameworks. Its focus is to allow
>>>> highly efficient database operations in combination with a maximum of
>>>> compile-time-safety and DBMS independence.
>>>>
>>>> Project development since the last report
>>>>
>>>> Last December we have finished and published release 2.0.7 that
>>>> features some minor improvements and bug fixes. Currently we are
>>>> working on release 2.1.0 with more significant improvements.
>>>>
>>>> Issues to address in the move towards graduation and community
>>>> development
>>>>
>>>> After now being 2 and a half years in the incubator we have managed to
>>>> successfully implement and establish the Apache development and
>>>> release cycle, we have published several releases and we have received
>>>> good feedback from users who are subscribed to the dev and user lists.
>>>>
>>>> However during all this time, we have still not managed to get
>>>> ourselves known to a wider audience and to get a significant amount of
>>>> public attention, most certainly due to the fact that have not managed
>>>> to work on publicity as much as on code. Also our community currently
>>>> consists of only 3 active committers that are regularly contributing
>>>> to the project.
>>>>
>>>> For this reason questions about the future of the project and whether
>>>> we will ever be able to graduate have been raised. While the remaining
>>>> active committers are determined to continue their project commitment
>>>> and to work towards graduation it is still unclear by which measures
>>>> new committers can be won to join the project.
>>>>
>>>> Hence, for the coming months answering this question and establishing
>>>> the corresponding measures should be our focus. One way of answering
>>>> this question could be to move this discussion to the dev list in
>>>> order to find out how our subscribers feel about the status of the
>>>> project. Also it might make sense to combine the user and dev lists in
>>>> order to prevent subscribers from missing information and getting them
>>>> more involved in the project.
>>>>
>>>
>>
>>
>
>
--
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.
re: EMPIREDB-38, switch to slf4j
Posted by Rainer Döbele <do...@esteam.de>.
Hi Benjamin,
glad to hear that you want to take on this issue.
But before you start, we should make our minds up what exactly we want to achieve and how we are going to do this.
I don't think it is necessary or desirable to put all org.apache.empire.xml classes into a separate module.
Regards
Rainer
Benjamin Venditti wrote:
> from: Benjamin Venditti [mailto:benjamin.venditti@arcor.de]
> to: empire-db-dev@incubator.apache.org
> re: Re: EMPIREDB-38, switch to slf4j
>
> Hi Francis,
>
> would be great if you could put the org.apache.empire.xml package to a
> separate module.
> I'll start switching to slf4j later this evening.
>
> What do you think would be best? Switch each module successively or all
> in one step?
>
> Cheerio,
> Benjamin
>
>
>
> Am 24.01.2011 09:50, schrieb Francis De Brabandere:
> > Hi Benjamin,
> >
> > Maybe I would first split off the org.apache.empire.xml package to a
> > empire-db-config module that can still depend on log4j.
> >
> > I can take care of that today. Afterwards we can switch everything to
> > slf4j except that config. We need to make sure we sync here and work
> > fast so that not everybody is blocked waiting for this big change...
> >
> > Shall I make that change?
> >
> > Also for slf4j make sure we switch to the parametrized logging and
> you
> > could also remove a lot of unneeded String.valueOf() calls.
> >
> > Cheers,
> > Francis
> >
> > On Mon, Jan 24, 2011 at 1:22 AM, Benjamin Venditti
> > <be...@arcor.de> wrote:
> >> Hey there,
> >>
> >> i thought i could contribute a little for the next release and had a
> look at
> >> the open-issues list for the upcoming release. I picked up EMPIREDB-
> 38
> >> "switch to slf4j" as i think i can handle it (not so sure with the
> other
> >> issues), and it shows to be unassigned.
> >>
> >> My first impression is that it involves not to much work, we would
> have to
> >> get rid of calls to "log.fatal(...)" as slf4j just offers 5 instead
> of 6
> >> logging levels. Do we make any destinction between fatal and
> "normal"
> >> errors? If not, we can simply map fatal to error.
> >>
> >> slf4j.Logger: debug, error,
> info,
> >> trace, warn
> >> apache.commons.logging.Log: trace, debug, info, warn,
> error, fatal
> >>
> >> And there is a "LogFactory.releaseAll();" which i'm not sure how to
> map in
> >> slf4j.
> >>
> >> The "DOMConfiguration" stuff will be removed as far is i understood,
> as this
> >> is neccessary for the configuration of the specific logging
> implementation
> >> which will now go into a different config file.
> >>
> >> I suggest to switch logging to slf4j in the whole project. That way
> i could
> >> start with non crutial parts of the project, like the examples, and
> i
> >> wouldn't have to worry about messing up the core. And in the end we
> will
> >> have consistent logging in the whole project.
> >>
> >> Please let me know what you think?
> >>
> >> Best Regards
> >>
> >>
> >>
> >> Am 22.01.2011 19:34, schrieb Francis De Brabandere:
> >>> Hello there.
> >>>
> >>> As empire-db is struggling a bit to grow a community, and we need a
> >>> bigger community to graduate, we want to involve our users in the
> >>> decision on where to go with the project.
> >>>
> >>> Below you'll find some questions and we would be delighted to hear
> >>> your comments!
> >>>
> >>> * Where do you use empire-db? or what keeps you from using empire-
> db?
> >>> * If you evaluated empire-db but switched to something else we
> would
> >>> like to know what you are using.
> >>> * How do you feel about the project?
> >>> * Is there anything we could do better?
> >>> * What should we put more effort into?
> >>> * Would you be interested in contributing. For example helping with
> >>> documentation, examples, blog posts, or adding functionality.
> >>>
> >>> Thanks,
> >>>
> >>> The empire-db team.
> >>>
> >>> -- our incubator report as reference below --
> >>> http://wiki.apache.org/incubator/January2011
> >>>
> >>> Empire-db
> >>>
> >>> Apache Empire-db is a relational database abstraction layer that
> >>> allows developers to take a more SQL-centric approach in
> application
> >>> development than traditional ORM frameworks. Its focus is to allow
> >>> highly efficient database operations in combination with a maximum
> of
> >>> compile-time-safety and DBMS independence.
> >>>
> >>> Project development since the last report
> >>>
> >>> Last December we have finished and published release 2.0.7 that
> >>> features some minor improvements and bug fixes. Currently we are
> >>> working on release 2.1.0 with more significant improvements.
> >>>
> >>> Issues to address in the move towards graduation and community
> development
> >>>
> >>> After now being 2 and a half years in the incubator we have managed
> to
> >>> successfully implement and establish the Apache development and
> >>> release cycle, we have published several releases and we have
> received
> >>> good feedback from users who are subscribed to the dev and user
> lists.
> >>>
> >>> However during all this time, we have still not managed to get
> >>> ourselves known to a wider audience and to get a significant amount
> of
> >>> public attention, most certainly due to the fact that have not
> managed
> >>> to work on publicity as much as on code. Also our community
> currently
> >>> consists of only 3 active committers that are regularly
> contributing
> >>> to the project.
> >>>
> >>> For this reason questions about the future of the project and
> whether
> >>> we will ever be able to graduate have been raised. While the
> remaining
> >>> active committers are determined to continue their project
> commitment
> >>> and to work towards graduation it is still unclear by which
> measures
> >>> new committers can be won to join the project.
> >>>
> >>> Hence, for the coming months answering this question and
> establishing
> >>> the corresponding measures should be our focus. One way of
> answering
> >>> this question could be to move this discussion to the dev list in
> >>> order to find out how our subscribers feel about the status of the
> >>> project. Also it might make sense to combine the user and dev lists
> in
> >>> order to prevent subscribers from missing information and getting
> them
> >>> more involved in the project.
> >>>
> >>
> >
> >
Re: EMPIREDB-38, switch to slf4j
Posted by Benjamin Venditti <be...@arcor.de>.
Hi Francis,
would be great if you could put the org.apache.empire.xml package to a
separate module.
I'll start switching to slf4j later this evening.
What do you think would be best? Switch each module successively or all
in one step?
Cheerio,
Benjamin
Am 24.01.2011 09:50, schrieb Francis De Brabandere:
> Hi Benjamin,
>
> Maybe I would first split off the org.apache.empire.xml package to a
> empire-db-config module that can still depend on log4j.
>
> I can take care of that today. Afterwards we can switch everything to
> slf4j except that config. We need to make sure we sync here and work
> fast so that not everybody is blocked waiting for this big change...
>
> Shall I make that change?
>
> Also for slf4j make sure we switch to the parametrized logging and you
> could also remove a lot of unneeded String.valueOf() calls.
>
> Cheers,
> Francis
>
> On Mon, Jan 24, 2011 at 1:22 AM, Benjamin Venditti
> <be...@arcor.de> wrote:
>> Hey there,
>>
>> i thought i could contribute a little for the next release and had a look at
>> the open-issues list for the upcoming release. I picked up EMPIREDB-38
>> "switch to slf4j" as i think i can handle it (not so sure with the other
>> issues), and it shows to be unassigned.
>>
>> My first impression is that it involves not to much work, we would have to
>> get rid of calls to "log.fatal(...)" as slf4j just offers 5 instead of 6
>> logging levels. Do we make any destinction between fatal and "normal"
>> errors? If not, we can simply map fatal to error.
>>
>> slf4j.Logger: debug, error, info,
>> trace, warn
>> apache.commons.logging.Log: trace, debug, info, warn, error, fatal
>>
>> And there is a "LogFactory.releaseAll();" which i'm not sure how to map in
>> slf4j.
>>
>> The "DOMConfiguration" stuff will be removed as far is i understood, as this
>> is neccessary for the configuration of the specific logging implementation
>> which will now go into a different config file.
>>
>> I suggest to switch logging to slf4j in the whole project. That way i could
>> start with non crutial parts of the project, like the examples, and i
>> wouldn't have to worry about messing up the core. And in the end we will
>> have consistent logging in the whole project.
>>
>> Please let me know what you think?
>>
>> Best Regards
>>
>>
>>
>> Am 22.01.2011 19:34, schrieb Francis De Brabandere:
>>> Hello there.
>>>
>>> As empire-db is struggling a bit to grow a community, and we need a
>>> bigger community to graduate, we want to involve our users in the
>>> decision on where to go with the project.
>>>
>>> Below you'll find some questions and we would be delighted to hear
>>> your comments!
>>>
>>> * Where do you use empire-db? or what keeps you from using empire-db?
>>> * If you evaluated empire-db but switched to something else we would
>>> like to know what you are using.
>>> * How do you feel about the project?
>>> * Is there anything we could do better?
>>> * What should we put more effort into?
>>> * Would you be interested in contributing. For example helping with
>>> documentation, examples, blog posts, or adding functionality.
>>>
>>> Thanks,
>>>
>>> The empire-db team.
>>>
>>> -- our incubator report as reference below --
>>> http://wiki.apache.org/incubator/January2011
>>>
>>> Empire-db
>>>
>>> Apache Empire-db is a relational database abstraction layer that
>>> allows developers to take a more SQL-centric approach in application
>>> development than traditional ORM frameworks. Its focus is to allow
>>> highly efficient database operations in combination with a maximum of
>>> compile-time-safety and DBMS independence.
>>>
>>> Project development since the last report
>>>
>>> Last December we have finished and published release 2.0.7 that
>>> features some minor improvements and bug fixes. Currently we are
>>> working on release 2.1.0 with more significant improvements.
>>>
>>> Issues to address in the move towards graduation and community development
>>>
>>> After now being 2 and a half years in the incubator we have managed to
>>> successfully implement and establish the Apache development and
>>> release cycle, we have published several releases and we have received
>>> good feedback from users who are subscribed to the dev and user lists.
>>>
>>> However during all this time, we have still not managed to get
>>> ourselves known to a wider audience and to get a significant amount of
>>> public attention, most certainly due to the fact that have not managed
>>> to work on publicity as much as on code. Also our community currently
>>> consists of only 3 active committers that are regularly contributing
>>> to the project.
>>>
>>> For this reason questions about the future of the project and whether
>>> we will ever be able to graduate have been raised. While the remaining
>>> active committers are determined to continue their project commitment
>>> and to work towards graduation it is still unclear by which measures
>>> new committers can be won to join the project.
>>>
>>> Hence, for the coming months answering this question and establishing
>>> the corresponding measures should be our focus. One way of answering
>>> this question could be to move this discussion to the dev list in
>>> order to find out how our subscribers feel about the status of the
>>> project. Also it might make sense to combine the user and dev lists in
>>> order to prevent subscribers from missing information and getting them
>>> more involved in the project.
>>>
>>
>
>
Re: EMPIREDB-38, switch to slf4j
Posted by Francis De Brabandere <fr...@gmail.com>.
Hi Benjamin,
Maybe I would first split off the org.apache.empire.xml package to a
empire-db-config module that can still depend on log4j.
I can take care of that today. Afterwards we can switch everything to
slf4j except that config. We need to make sure we sync here and work
fast so that not everybody is blocked waiting for this big change...
Shall I make that change?
Also for slf4j make sure we switch to the parametrized logging and you
could also remove a lot of unneeded String.valueOf() calls.
Cheers,
Francis
On Mon, Jan 24, 2011 at 1:22 AM, Benjamin Venditti
<be...@arcor.de> wrote:
> Hey there,
>
> i thought i could contribute a little for the next release and had a look at
> the open-issues list for the upcoming release. I picked up EMPIREDB-38
> "switch to slf4j" as i think i can handle it (not so sure with the other
> issues), and it shows to be unassigned.
>
> My first impression is that it involves not to much work, we would have to
> get rid of calls to "log.fatal(...)" as slf4j just offers 5 instead of 6
> logging levels. Do we make any destinction between fatal and "normal"
> errors? If not, we can simply map fatal to error.
>
> slf4j.Logger: debug, error, info,
> trace, warn
> apache.commons.logging.Log: trace, debug, info, warn, error, fatal
>
> And there is a "LogFactory.releaseAll();" which i'm not sure how to map in
> slf4j.
>
> The "DOMConfiguration" stuff will be removed as far is i understood, as this
> is neccessary for the configuration of the specific logging implementation
> which will now go into a different config file.
>
> I suggest to switch logging to slf4j in the whole project. That way i could
> start with non crutial parts of the project, like the examples, and i
> wouldn't have to worry about messing up the core. And in the end we will
> have consistent logging in the whole project.
>
> Please let me know what you think?
>
> Best Regards
>
>
>
> Am 22.01.2011 19:34, schrieb Francis De Brabandere:
>>
>> Hello there.
>>
>> As empire-db is struggling a bit to grow a community, and we need a
>> bigger community to graduate, we want to involve our users in the
>> decision on where to go with the project.
>>
>> Below you'll find some questions and we would be delighted to hear
>> your comments!
>>
>> * Where do you use empire-db? or what keeps you from using empire-db?
>> * If you evaluated empire-db but switched to something else we would
>> like to know what you are using.
>> * How do you feel about the project?
>> * Is there anything we could do better?
>> * What should we put more effort into?
>> * Would you be interested in contributing. For example helping with
>> documentation, examples, blog posts, or adding functionality.
>>
>> Thanks,
>>
>> The empire-db team.
>>
>> -- our incubator report as reference below --
>> http://wiki.apache.org/incubator/January2011
>>
>> Empire-db
>>
>> Apache Empire-db is a relational database abstraction layer that
>> allows developers to take a more SQL-centric approach in application
>> development than traditional ORM frameworks. Its focus is to allow
>> highly efficient database operations in combination with a maximum of
>> compile-time-safety and DBMS independence.
>>
>> Project development since the last report
>>
>> Last December we have finished and published release 2.0.7 that
>> features some minor improvements and bug fixes. Currently we are
>> working on release 2.1.0 with more significant improvements.
>>
>> Issues to address in the move towards graduation and community development
>>
>> After now being 2 and a half years in the incubator we have managed to
>> successfully implement and establish the Apache development and
>> release cycle, we have published several releases and we have received
>> good feedback from users who are subscribed to the dev and user lists.
>>
>> However during all this time, we have still not managed to get
>> ourselves known to a wider audience and to get a significant amount of
>> public attention, most certainly due to the fact that have not managed
>> to work on publicity as much as on code. Also our community currently
>> consists of only 3 active committers that are regularly contributing
>> to the project.
>>
>> For this reason questions about the future of the project and whether
>> we will ever be able to graduate have been raised. While the remaining
>> active committers are determined to continue their project commitment
>> and to work towards graduation it is still unclear by which measures
>> new committers can be won to join the project.
>>
>> Hence, for the coming months answering this question and establishing
>> the corresponding measures should be our focus. One way of answering
>> this question could be to move this discussion to the dev list in
>> order to find out how our subscribers feel about the status of the
>> project. Also it might make sense to combine the user and dev lists in
>> order to prevent subscribers from missing information and getting them
>> more involved in the project.
>>
>
>
--
http://www.somatik.be
Microsoft gives you windows, Linux gives you the whole house.