Yeah, the latest pax-logging releases include a sift appender and some MDC attributes so that you can have each bundle logging to a different file.
On Thu, Oct 14, 2010 at 10:59, Achim Nierbeck <[email protected]>wrote: > OK, but as far as I know there is something called SiftAppender, which does > actually do this. Just take a look at the current Apache Karaf (latest > release 2.1.0) there is a so called SiftAppender configured but not > activated which does a per bundle logging. > > 2010/10/14 Sander de Groot <[email protected]> > > > I think it's only a partial solution for his question. > > The main issue however isn't solved by using PAX Logging: it seems he > wants > > to be able to use some kind of logging context. > > If I understand correctly then Laurens wants to be able to control the > > output of specific bundles in specific contexts. > > Say for example if I have a bundle (bundle X in your case) which utilizes > > another bundle (Bundle Y) and calls BundleY.MathUtils.multiply(a,b) on > this > > bundle. Somethings goes wrong in Bundle Y and he wants to log a warning, > if > > I understand correctly you want this warning to be logged in the log file > of > > Bundle X? > > You probably want something like this because BundleY is called by > several > > other bundles? > > > > I'm also looking into something like this because this can be really > useful > > if you're debugging your applications since there is only related > > information logged. Say for example if you have webapplications deployed > as > > bundles then you want that application/bundle to log to its own log file > and > > if that application calls any libraries then that library should also log > to > > the log file of the application. (Just like in normal webcontainers) > > > > > > On 10/14/2010 03:58 PM, Achim Nierbeck wrote: > > > >> You might also take a look at PAX-Logging, to me it looks like it would > be > >> the one you are searching for :) > >> > >> 2010/10/14 Michael Hess<[email protected]> > >> > >> > >> > >>> Hello, > >>>> > >>>> We have the following problem: > >>>> > >>>> > >>>> Multiple bundles run on osgi, each of them has a log file. If bundle X > >>>> > >>>> > >>> calls > >>> > >>> > >>>> bundle Y and a warning occurs in bundle Y, we want to log the warning > in > >>>> > >>>> > >>> the > >>> > >>> > >>>> log file of bundle X. But the problem we have at the moment is that > >>>> > >>>> > >>> bundle Y > >>> > >>> > >>>> doesn?t know bundle X and how bundle Y knows who have called him. > >>>> > >>>> We have thought of 3 possible ways to solve the problem: > >>>> > >>>> 1. StackTrace, but we think it is slow and it?s not nice to use > >>>> > >>>> > >>> stackt > >>> > >>> > >>>> race. > >>>> 2. Set the context in another bundle, so bundle Y can use the > >>>> > >>>> > >>> function > >>> > >>> > >>>> getlogger to our own created bundle > >>>> 3. Security Manager, but we don?t know whether it works well with > >>>> > >>>> > >>> osgi. > >>> > >>> > >>>> We want to know which way is the best or maybe someone has the > >>>> > >>>> > >>> experience > >>> > >>> > >>>> with this problem or knows another solution that we haven?t thought of > >>>> > >>>> > >>> yet. > >>> > >>> To me it seems, like the separation of logfiles is not what you want. > >>> > >>> What we did in our project, was to create a Logging Service. It is > pretty > >>> much a wrapper around log4j (or another backend of choice), and the > >>> bundle > >>> exposes a ServiceFactory which gives every bundle its own logger > >>> instance. > >>> In the activator of our bundles, the logger is retrieved and the bundle > >>> can then use it. So what we have, is the "logging bundle" which writes > a > >>> single log file, and all bundles of the system can participate by > >>> issueing > >>> their log statements toward that bundle via the exposed service. > >>> > >>> > >>> > >>>> > >>>> Kind regards, > >>>> > >>>> Laurens > >>>> > >>>> > >>> bye, Michael > >>> > >>> The information included in this e-mail and any files transmitted with > it > >>> is strictly confidential and may be privileged or otherwise protected > >>> from > >>> disclosure. If you are not the intended recipient, please notify the > >>> sender > >>> immediately by e-mail and delete this e-mail as well as any attachment > >>> from > >>> your system. If you are not the intended recipient you are not > authorized > >>> to > >>> use and/or copy this message and/or attachment and/or disclose the > >>> contents > >>> to any other person. > >>> > >>> > >> > >> > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
