Simon Kitching wrote: > ---- Apache Wiki <[EMAIL PROTECTED]> schrieb: >> set up. Therefore adding OSGi attributes to > commons-logging is not useful, as commons-logging >> is not usable in an OSGi environment. >> >> + ''niallp: Can't be? But what if it is, logging is used by > many so I would be surprised if its not.'' > > Well, I'm basing my info on an email sent to this list about > two weeks ago. But it seems sensible to me: commons-logging > plays lots of tricks with classloaders to try to accomodate the needs > of (a) dumb logging libs, > (b) dumb servlet engines, > (c) dump jee specs, and > (d) dumb users. > > OSGi sets up its own complicated classloader hierarchies to > try to hide certain java classes from each other, allow > dynamic reloading of class hierarchies, etc. > > I haven't specifically looked into it, but the original > poster was quite definite that they are not compatible, and I > would actually be very surprised if they were. (He was also > unnecessarily rude, but that's another matter). > > Supposedly, there is a library out there somewhere that > implements the commons-logging api (ie provides classes in > the org.apache.commons.logging namespace) but implements > things in an OSGi-aware manner. > > As OSGi is becoming more popular, it would be nice if a link > to that package was present on the commons-logging wiki.
Obviously it can be turned into an OSGi bundle, since TPTP delivers one for CL. Although not without problems: https://bugs.eclipse.org/bugs/show_bug.cgi?id=209144 (don't be confused about the bug report speaking of Log4j, my app uses CL and bundles Log4J here). - Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
