Hi David, Could you clarify the issues with SLF4J? It would seem we could end up replacing one logging wrapper API with our own. You mentioned you require two bundles that are unnecessary. Is their size an issue? Is there some refactoring that could be done in SLF4J to improve the situation? Could your own logging sit behind SLF4J or does this cause other issues?
Regards, Graham. On 1 February 2012 12:38, Guillaume Nodet <[email protected]> wrote: > Because the osgi log service has a crappy api which is too limited ? > > On Wed, Feb 1, 2012 at 12:56, Felix Meschberger <[email protected]> wrote: >> Hi >> >> Really ? YALA ? >> >> Why not just settle all Aries on LogService (maybe even through some utility >> to guard against LogService being away) or SLF4J ? >> >> Regards >> Felix >> >> Am 01.02.2012 um 12:51 schrieb David Bosschaert: >> >>> Yes, I'd like to have something that has minimal dependencies, but >>> putting it in Aries Util is fine with me as most components depend on >>> that anyway. >>> >>> While working with the LogService I put some code that I found in the >>> Aries JMX component that makes working with the OSGi LogService easier >>> in Util. You can find it here: >>> http://svn.apache.org/repos/asf/aries/trunk/util/util-r42/src/main/java/org/apache/aries/util/log/Logger.java >>> >>> Maybe we can extend this class to provide a simple API that provides >>> all the needed inputs for all uses (including classname-based >>> initialization) so it can delegate appropriately. >>> >>> David >>> >>> On 1 February 2012 11:05, Graham Charters <[email protected]> wrote: >>>> Guillaume's starter.... >>>> >>>> "Can't we simply do something in aries until that would be shared by >>>> all aries modules (since they kinda all depend on it already) ? >>>> A very small api that could be configured to either use slf4j, jul or >>>> osgi logging ? Using optional imports, it should limit to what's >>>> available and default to a good one, falling back to jul if nothing" >>>> >>>> >>>> ---------- Forwarded message ---------- >>>> From: Guillaume Nodet <[email protected]> >>>> Date: 1 February 2012 10:46 >>>> Subject: Re: Aries JNDI dependencies >>>> To: [email protected] >>>> >>>> >>>> Can't we simply do something in aries until that would be shared by >>>> all aries modules (since they kinda all depend on it already) ? >>>> A very small api that could be configured to either use slf4j, jul or >>>> osgi logging ? Using optional imports, it should limit to what's >>>> available and default to a good one, falling back to jul if nothing >>>> else. >>>> >>>> On Wed, Feb 1, 2012 at 11:26, David Bosschaert >>>> <[email protected]> wrote: >>>>> Hi all, >>>>> >>>>> On 1 February 2012 09:58, Graham Charters <[email protected]> wrote: >>>>>> Hi David, >>>>>> >>>>>> Prior to these changes, Apache Aries had the ability to filter logging >>>>>> per class, and this was consistent across all Aries modules. >>>>> >>>>> Well apparently not because the Aries JMX component used the >>>>> LogService already... >>>>> >>>>>> I don't >>>>>> think we should be doing piecemeal infrastructure dependency changes >>>>>> like these without a proper consideration. >>>>> >>>>> Well, you can see at the beginning of this thread (Jan 16) that I'm >>>>> asking for opinions re removing to the LogService and that the >>>>> responses where positive... >>>>> >>>>>> Although nobody really wants to have a logging conversation, I don't >>>>>> think we can avoid one, and until then, I think we need to go back to >>>>>> the consistent approach that, until now, Aries consumers seemed happy >>>>>> with. >>>>> >>>>> ... sigh ... ok we'll have a logging discussion and I'll revert those >>>>> changes for the moment. >>>>> >>>>> @David J: we can explore the capabilities of the log service in that >>>>> discussion. >>>>> >>>>> Best regards, >>>>> >>>>> David >>>> >>>> >>>> >>>> -- >>>> ------------------------ >>>> Guillaume Nodet >>>> ------------------------ >>>> Blog: http://gnodet.blogspot.com/ >>>> ------------------------ >>>> FuseSource, Integration everywhere >>>> http://fusesource.com >> > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > FuseSource, Integration everywhere > http://fusesource.com
