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<[email protected]> 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:[email protected]]
to: [email protected]
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
<[email protected]> 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<[email protected]>
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:[email protected]]
to: [email protected]
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.
