incubator-empire-db-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francis De Brabandere <>
Subject Re: EMPIREDB-38, switch to slf4j
Date Mon, 24 Jan 2011 11:43:33 GMT
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.


On Mon, Jan 24, 2011 at 12:14 PM, Benjamin Venditti
<> 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
>> <>  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 --
>>>> 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.

Microsoft gives you windows, Linux gives you the whole house.

View raw message