I had a discussion with Craig about this off list, and that code will need to be changed as you point out, regardless of this logging discussion. I also want to support seamless deployment in OSGi
On Mon, Jul 14, 2008 at 4:13 PM, Niklas Gustavsson <[EMAIL PROTECTED]> wrote: > On Mon, Jul 14, 2008 at 7:20 PM, Les Hazlewood <[EMAIL PROTECTED]> wrote: >> The most important implementation is JSecurityLogFactory - please look >> at the source code and you'll see how I do my graceful degredation >> check. That is really all there is to it, plus the one-liner methods >> of the respective Log implementations. > > I had a look at the code, and while not the uttermost expert on this > topic, I think it would break pretty badly in an OSGi environment > unless the user takes careful steps. Reason is that the TCCL would > commonly return the application class loader: > "If not set, the default is the ClassLoader context of the parent > Thread. The context ClassLoader of the primordial thread is typically > set to the class loader used to load the application." > > Since the application class loader would have no knowledge of SLF4J > loaded by a bundle classloader, ClassUtils won't find SLF4J, even it > if where to import it. The common way to get around this is for the > client to set the TCCL to the bundle classloader but that's not a > pretty solution. But, I'll let someone better versed in OSGi correct > me before making any final decision based on this analysis ;-) > > Of course, the basic SLF4J approach would work fine in an OSGi > environment since it doesn't have to do any classloading magic. > > /niklas >
