I think Laurens needs to shed some more light on his requirements here. As stated, I am not really convinced, that separate logfiles per bundle is what he really wants. To me this becomes dubious at the point, where he wants to log something from Y in the logfile of X. The motivation behind this, probably (I am guessing here) is that he wants to correlate the log information of these bundles.
> 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] > 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.
