Richard S. Hall wrote: > >> I'm just trying to understand how the >> "contents of the contents", as you put it, aren't included in "the >> contents". >> > > Just think of how you manually unzip an archive. If you unzip it, you > get its contents. If the contents contain other zip files, they still > need to be unzip to see what is inside of them. Unzipping is not > recursive. >
My analogy with the Matryoshka doll wasn't very good. Like you said, it isn't recursive. It is nested/embedded at most one level deep. Richard S. Hall wrote: > > On 11/10/09 19:38, lukewpatterson wrote: >> So entries in the "Bundle Space" (v4.2, sec. 4.4.14) aren't retrieved >> from >> the "Bundle Class Path" (v4.2, sec. 3.8.1)? Am I missing something >> conceptual or fundamental? >> > > Correct. The term "entry" was used to correlate to the terminology of > ZipFile/JarFile.getEntry(). In OSGi the entry-related methods are > intended to give access to the "raw content" of the bundle. > Now it makes more sense. I could use the "entry" methods to retrieve the actual embedded jar files, for example. In my scenario, I'm trying to detect the presence of "META-INF/services/*" resources which would be present in the "Bundle Space" without resolving. In my bundletracking, I don't want to resolve every bundle I find. (I shouldn't have been trying to use findEntries anyway, cause that resolves) -- View this message in context: http://old.nabble.com/Bundle.findEntries%28...%29-and-Bundle-Classpath-tp26287340p26302677.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]
