If you replaced the word bundle with the word jar, you would still have the same problem. The issue is that the execution path will traverse across bundle (or jar) boundaries. We you need to account for something such as a resource allocation (or logging), to which bundle (or jar) should the allocation be charged? The answer to that question is: it depends. There is no one answer. It is up to you. You can either have the caller set a fence which the callee can see (option 2) or have the callee try to determine the caller (options 1 and 2). The former is more reliable I think. The latter is prone to misunderstandings and error. --
BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [email protected] office: +1 386 848 1781 mobile: +1 386 848 3788 From: Laurens van Uijthoven <[email protected]> To: [email protected] Date: 2010/10/13 23:04 Subject: [osgi-dev] Logging problems with osgi Sent by: [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 stacktrace. 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] https://mail.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
