Though I'm not fully sure I understand your requirement, it sounds like ServiceFactory may help. Using this you can register a single service, but when each consumer bundle gets the service you can give it a slightly customised result.
This allows you to distinguish which bundle is calling your service, and then you can decide what to do with the information. The standard OSGi LogService implements this pattern. Regards Neil On Thu, Oct 14, 2010 at 2:32 PM, John W Ross <[email protected]> wrote: > Have you considered the possibility of having bundle X and Z register their > own implementations of LogService and distinguishing them based on one or > more service properties? Bundle Y would then retrieve the appropriate > service from the registry using a filter and log to it. This would, of > course, require some knowledge of other bundles on the part of Y in order to > create the right filter. I think it would be similar to what you proposed in > (2) only more decoupled. > > John > > > [image: Inactive hide details for Laurens van Uijthoven ---10/14/2010 > 12:32:17 AM---Thank you for your reply John,]Laurens van Uijthoven > ---10/14/2010 12:32:17 AM---Thank you for your reply John, > > > *Laurens van Uijthoven <[email protected]>* > Sent by: [email protected] > > 10/14/2010 12:23 AM > Please respond to > OSGi Developer Mail List <[email protected]> > > > > To > > OSGi Developer Mail List <[email protected]> > cc > > > Subject > > Re: [osgi-dev] Logging problems with osgi > > Thank you for your reply John, > > We have thought of this solution but this will only solve it partially. The > problem is when we have 2 bundles X and Z calling bundle Y then their are 2 > log messages but both belong to one of the two bundles(message 1 belongs to > bundle X and message 2 belongs to bundle Z) in other words we don't want to > pollute the log file with messages of other calling bundles. > > Kind regards, > Laurence > > 2010/10/14 John W Ross <*[email protected]* <[email protected]>> > > So bundle X apparently has knowledge of bundle Y. Have you considered > having bundle X register a LogListener with the LogReaderService then > filtering the LogEntry objects received based on LogEntry.getBundle()? This > would necessitate bundle Y logging to the LogService, of course. > > Thank you. > > ____________________________ > John W Ross > Software Engineer > IBM Software Group > Office: 919.254.7348 > Notes: John W Ross/Atlanta > Internet: *[email protected]* <[email protected]> > > "It is my belief these sheep are laboring under the misapprehension > that they're birds.... Witness their attempts to fly from tree to tree. > Notice how they not so much fly as plummet." > > [image: Inactive hide details for Laurens van Uijthoven ---10/13/2010 > 11:04:50 PM---Hello, We have the following problem:]Laurens van > Uijthoven ---10/13/2010 11:04:50 PM---Hello, We have the following problem: > > > > *Laurens van Uijthoven > <**[email protected]*<[email protected]> > *>* > Sent by: > *[email protected]*<[email protected]> > > 10/13/2010 10:59 PM > > > Please respond to > OSGi Developer Mail List <*[email protected]*<[email protected]> > > > To > * > **[email protected]* <[email protected]> > cc > Subject > > [osgi-dev] Logging problems with osgi > > > 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. > > kind regards, > > Laurens_______________________________________________ > OSGi Developer Mail List* > **[email protected]* <[email protected]>* > > **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> > > _______________________________________________ > OSGi Developer Mail List* > **[email protected]* <[email protected]>* > > **https://mail.osgi.org/mailman/listinfo/osgi-dev*<https://mail.osgi.org/mailman/listinfo/osgi-dev> > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev >
<<ecblank.gif>>
<<graycol.gif>>
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
