Mirko wrote on 05/21/2006 11:56:29 PM:
> Let's us an example, we just think of three bundles. Bundle A, B and
> C. A depends on B and B on C, a typical line of dependencies. If we
> assume bundle C contains a resource which is needed by bundle A,
> there are several ways to do that, depending on the wiring.
>
> First situation: I exactly know the bundle, so...
> ...I can lookup the bundle instance and call one of the three
> resource handling methods in OSGi
> * bundle.getResource();
> * bundle.getEntry();
> * bundle.findEntries();
> (Depending, on where (which (sub-) folder) the resource is located
> and if this folder is part of the class path.)
Just to be really clear here you should distinguish between classes, resources and files/dirs (or entries). The first two are accessed exclusively via classloaders and so must be on the classpath. Enteries on the other hand are access via direct URLs (e.g., getEntry) with no classloaders or dependencies involved. It seems that you know the difference but are mixing up the terms in the discussion. This may be confusing things.
> Unfortunately the Eclipse GUI (which I use) for doing this doesn't
> like resources in packages (or doesn't recognize them) and therefore
> does not allow to export a package without at least having one java
> file in there. Ok, it is not that hard to add this line to the
> manifest by hand, I know - but why isn't it just possible to
> declaratively export resources like packages with java files? I mean
> in the ClassLoader, one of the key concepts of OSGi, both are treated
> equal in Java, why making here such big difference?
This is just a usability issue in the Eclipse PDE editor, nothing sinister. Please enter a bug report in Eclipse/PDE/UI at
https://bugs.eclipse.org/bugs/enter_bug.cgi
For now you can certainly add the required imports using the Manifest tab of the bundle/plugin editor and add the imports and exports directly. PDE may whine a bit by putting up some warnings but you can safely ignore them in your scenario.
> In Eclipse, there
> is a solution by using buddy class loading, but first of all it is
> not OSGi and secondly not focused on versions, which is very
> important for me (that's one reason, why I don't really like that
> that concept, even if it solves easily many problems).
Yikes! Buddy classloading is not at all intended for this kind of thing. It only helps by eliminating the need for imports but as you observe, it has some real and significant limitations.
> Well, I think I got a bit too talkative, so here is a short summary
> of my key questions:
> Why are resources treated different in OSGi than java classes?
They aren't. What you are seeing is a tooling issue.
> Why is there no (easy) way to get the wired bundles of a given
> bundle, like from the BundleContext or the PackageAdmin? Or how, if I
> missed something in the spec - sorry for that in this case!
Because in general you do not need this information, little work has been put into making it available.
> Why is there no declarative export for resources? (In some cases you
> just don't want your resource in a package)
ALL *resources* are always in a package (even the default package is a package) since classloaders deal only with things that are in packages. There is no support for exporting entries. The expectation is that you would export the desired entries as resources by putting them in a package dir structure and exporting the package. Remember that the export/import space is global so these exported "resources" should generally be in some partitioned namespace (e.g., the package namespace).
> Don't get me wrong, I think the spec is great, I am just trying to
> understand the reasons why it is the way it is.
_______________________________________________ osgi-dev mailing list osgi-dev@bundles.osgi.org http://bundles.osgi.org/mailman/listinfo/osgi-dev
