On 6/24/13 12:23 , Roland wrote:
hello Felix, Ok - I understand that. But what happen if a second bundle like apache.felix.log is started? I would get the same problem. So, this not the final conclusion. I suppose that it would be cleaner if such packages like org.osgi.log are in the osgi.core because it is needed as a basic functionality and we just need only one bundle / version at runtime. But your hint not to deploy osgi.compendium is great!
First of all, you can't force every bundle to use the same version of a package, even if the package is a common one like logging. If importing bundles import non-intersecting version ranges, then we have to live with the fact that there will be multiple class spaces.
Ultimately, this shouldn't impact an individual bundle, though, since the framework should keep it isolated from other bundles with incompatible class spaces.
The important thing to understand, is that bundles with incompatible class spaces will likely not be able to interact because your system is partitioned. But this is just a fact of life in Java...you can't have stuff interact via incompatible types even though using the class path sometimes fools us into thinking everything is ok.
Further, multiple exporters are not necessarily a problem per se. First, if no one imports from them, then no harm. Second, if service providers only import service API or also import it if they export it, then this leaves the framework free to try to wire everyone up to the same provider.
There are a couple of issues about this in our OSGi FAQ: http://felix.apache.org/documentation/tutorials-examples-and-presentations/apache-felix-osgi-faq.html
Maybe I push the boundaries of OSGi...
No, it just sounds like you want your cake and to eat it too. -> richard
Thanks & Regards Roland -- View this message in context: http://apache-felix.18485.x6.nabble.com/Loader-constraint-violation-gogo-command-exports-org-osgi-service-log-tp5004055p5004104.html Sent from the Apache Felix - Users mailing list archive at Nabble.com. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
--------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
