On 11/11/09 10:20, lukewpatterson wrote:
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.
Yes.
-> richard
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)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
