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. Yep. There will be issues with OSGi for sure. SLF4J with static binding removes this. > 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 ;-) Not that I'm an expert but your delineation for ClassUtils not finding SLF4J is right on. I highly recommend on technical points that you avoid this tactic. This, I think, is one of the reasons why the Spring folks are considering switching to SLF4J. > > Of course, the basic SLF4J approach would work fine in an OSGi > environment since it doesn't have to do any classloading magic. > Right on Niklas! I think this is very important to consider. Alex -- Microsoft gives you Windows, Linux gives you the whole house ...
