Yeah, that's doable to. In order to do so, an MDC attribute needs to be set, attribute which will be used on the sift appender to redirect to a different log file.
On Thu, Oct 14, 2010 at 11:17, Michael Hess <[email protected]> wrote: > 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. > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com
