incubator-empire-db-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Venditti <>
Subject EMPIREDB-38, switch to slf4j
Date Mon, 24 Jan 2011 00:22:38 GMT
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 --
> 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.

View raw message