Erik,
Either of your options should work. I prefer option 1 though :)
Can you open a bug against Equinox->Framework and record your usecase in
the bug report. We may need to consider using the port to indicate a
classpath entry in the bundle instead of an entry into the list of
duplicate resources. I think the OSGi spec is also vague in the area of
bundle resource URLs. We may need to go back to OSGi and ask for
clarification. Thanks.
Tom
Erik Bengtson <[EMAIL PROTECTED]>
Sent by: [EMAIL PROTECTED]
08/27/2007 05:08 PM
Please respond to
Equinox development mailing list <equinox-dev@eclipse.org>
To
Equinox development mailing list <equinox-dev@eclipse.org>
cc
Subject
Re: [equinox-dev] getResources : bundleresource
Thomas,
You got my use case, and answered very well :). my bundles are deployed as
inner
libraries.
Two options I know to solve my issue:
1) use bundles as real bundles :)
2) use FileLocator.resolve() to resolve the URL and load MANIFEST.MF files
from
there.
If you have more options, I would appreciate.
Thanks,
Erik Bengtson
Quoting Thomas Watson <[EMAIL PROTECTED]>:
> I'm a bit confused by the usecase. Are these real bundles or just inner
> jars which you use as inner libraries? If they are real bundles then
why
> don't you install them as real bundles instead?
>
> The bundleresource protocol uses the port as an index into the list of
> resources of a given name (e.g plugin.xml). In your case it sounds like
> you have more resources named META-INF/MANIFEST.MF in your bundle than
you
> do plugin.xml so the two lists and indexes do not match up. For
example,
> imagine you have a bundle which has jars A, B, C, D which all have
> META-INF/MANIFEST.MF resources but only C and D have plugin.xml. A call
> to classloader.getResources("plugin.xml") gives you something like this:
>
> bundleresource://26:0/plugin.xml (C)
> bundleresource://26:1/plugin.xml (D)
>
> A call to classloader.getResources("META-INF/MANIFEST.MF") gives you
> something like this:
>
> bundleresource://26:0/META-INF/MANIFEST.MF (base bundle)
> bundleresource://26:1/META-INF/MANIFEST.MF (A)
> bundleresource://26:2/META-INF/MANIFEST.MF (B)
> bundleresource://26:3/META-INF/MANIFEST.MF (C)
> bundleresource://26:4/META-INF/MANIFEST.MF (D)
>
> As you can see the resource indexes will not match for the two different
> resources (plugin.xml and METE-INF/MANIFEST.MF) from C and D.
>
> Tom
>
>
>
>
> Erik Bengtson <[EMAIL PROTECTED]>
> Sent by: [EMAIL PROTECTED]
> 08/27/2007 01:58 PM
> Please respond to
> Equinox development mailing list <equinox-dev@eclipse.org>
>
>
> To
> Equinox development mailing list <equinox-dev@eclipse.org>
> cc
>
> Subject
> [equinox-dev] getResources : bundleresource
>
>
>
>
>
>
> Hi,
>
> I have some bundles (B,C,D) that are not deployed as osgi bundles, but
as
> libraries within a bundle (A).
>
> In bundle A, I have a custom internal registry of the plugin.xml from
> files
> (B,C,D).
>
> 1) find and load all plugin.xml files using classloader.getResources()
>
> I get an enumeration of:
>
> bundleresource://26:3/plugin.xml (D)
> bundleresource://26:2/plugin.xml (C)
> bundleresource://26:1/plugin.xml (B)
>
> So far so good, but now I have to load the corresponding
> /META-INF/MANIFEST.MF
> files from each bundle (B,C,D).
>
> 2) do: -- new URL("bundleresource://26:3/META-INF/MANIFEST.MF");
>
> My problem is that it returns the MANIFEST.MF from bundle (C), instead
of
> bundle
> (D).
>
> What am I doing wrong?
>
> Background: My project JPOX, a JDO/JPA implementation, is OSGi
compatible
> and
> uses Eclipse Extension/Extension Points for declarative services. I have
> an
> internal registry of bundles/extension/extension points when running
> outside an
> osgi container.
>
> Regards,
>
> Erik Bengtson
> http://jpox.org
> _______________________________________________
> equinox-dev mailing list
> equinox-dev@eclipse.org
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
_______________________________________________
equinox-dev mailing list
equinox-dev@eclipse.org
https://dev.eclipse.org/mailman/listinfo/equinox-dev
