+1 for the change Carsten
2011/9/18 Felix Meschberger <[email protected]>: > Hi > > Right, I missed them when cleaning up the logservice bundle. > > Will fix on commit. > > Thanks and Regards > Felix > > Justin Edelson <[email protected]> wrote: > > > Felix- > I think this separation is a good idea conceptually. > > Two minor comments on the patch: > * README files need updating > * It looks like there are metatype files in the logservice bundle, but > these aren't actually used (I could be misreading this). > > These shouldn't block applying the patch; they can be fixed after the > initial commit. > > Justin > > On Sat, Sep 17, 2011 at 7:38 AM, Felix Meschberger <[email protected]> wrote: >> Hi, >> >> I have created issue SLING-2224 [1] and a patch for this. >> >> Unless there is opposition, I would like to apply this patch early next >> week. >> >> Regards >> Felix >> >> [1] https://issues.apache.org/jira/browse/SLING-2224 >> >> On 14.09.2011 17:32, Felix Meschberger wrote: >>> Hi, >>> >>> At the moment Sling Commons Log bundle consists of the following pieces: >>> >>> * slf4j API >>> * log4j-over-slf4j >>> * jcl-over-slf4j >>> * JUL Adapter >>> * OSGi Log Service over slf4j >>> * Homegrown slf4j implementation >>> >>> We have encapsulated this bundle in that it is not possible to plug a >>> different slf4j implementation or plug extensions to slf4j (such as >>> slf4j-ext). >>> >>> I propose that we break this bundle apart as follows: >>> >>> * We directly deploy the slf4j-api, log4j-over-slf4j, and >>> jcl-over-slf4j bundles. No wrapping needed on our part >>> * Create a separate bundle of the Log Service over slf4j >>> implementation >>> * Keep the remaining pieces (JUL Adapter and slf4j impl) >>> in the commons.log bundle >>> >>> In a future/next step we can replace our homegrown slf4j impl with >>> logback and make sure users/administrators are able to plug-in >>> additional logback logging backends dynamically. >>> >>> WDYT ? >>> >>> Regards >>> Felix >> >> > -- Carsten Ziegeler [email protected]
