Hi David,

I also agree with Mark that it is a loss not having SLF4J anymore.
As slf4j is facade one can make a choice which logging framework to use behind it.
What are the pros of having your own logging backend?
I don't like handcrafting stuff which already exists with less functionality. If have a look at other enterprise projects SLF4J is kind of defacto standard.
I would very much appreciate to have SLF4J again.

If that is should be no option for you then what about at least providing an optional dependency to SLF4J with a mechanism to switch between your log service and slf4j?


Regards
David
Hi Mark,

Hmmm, I have to say that I don't really like message like: 'please
revert your changes because our product does x, y or z'. Apache Aries
is an opensource community that provides components that are used in
more than one product, not only yours.

I would prefer a more constructive approach where we can weigh the
pros and cons of the various approaches.

* SLF4J brings in dependencies that not everybody may want. In our
use-case in JBoss the SLF4J dep brings in at least 2 additional
bundles, which is unnecessary as we already have our own logging
system.
* SLF4J may have been decided on in Feb 2010, but a vibrant project
must show its agility to work in a number a settings. It's a good
thing that Aries is now used in more and more settings, but this
brings with it the notion of being able to accommodate.

So... I'm not entirely sure what the actual problem is with the
LogService, you mention:
* logging against specific classes
* other behavioural changes (what are they?)

Instead of simply going back to SLF4J, I would like to have a discussion about:
* possible alternatives, can we maybe change how the LogService is
used to accommodate your needs?
* or we could look at other logging alternatives, java.util.logging
comes to mind, since that can be configured to go to anything you like
as well and has the advantage over SLF4J in that the dependencies are
part of the JDK...

Best regards,

David


On 31 January 2012 09:56, Mark Nuttall<[email protected]>  wrote:
Hi David,
We've started running into what are for us serious consequences of your
recent changes to JNDI. I'm sorry that it's taken us a few weeks to notice
this. When JNDI logged via the SLF4J API, we had a pluggable logging API
that allowed us to log to our product's standard infrastructure. In
removing SLF4J, your changes appear to have bound us
to org.osgi.service.log.LogService, which we do not want, removed important
logging capabilities, such as the ability to log against specific classes,
and made other unwanted bahevioural changes. This is a problematic
regression for us. Please can you revert JNDI to logging via the SLF4J API?
SLF4J has been the Apache Aries standard for logging since the "[DISCUSS]
Logging framework" thread in February 2010. Thank you very much in advance.

Regards,
Mark


On 17 January 2012 11:38, David Bosschaert<[email protected]>wrote:

On 16 January 2012 15:54, David Bosschaert<[email protected]>
wrote:
I'll look at changing the SLF4J dependency to an OSGi Log Service
dependency next...
That's done now too: see revision 1232390
Hope this is ok with everyone...

Best regards,

David

Reply via email to