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