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 > >
