[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [equinox-dev] getResources : bundleresource


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 <erik@xxxxxxxx>
Sent by: equinox-dev-bounces@xxxxxxxxxxx

08/27/2007 05:08 PM

Please respond to
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>

To
Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
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 <tjwatson@xxxxxxxxxx>:

> 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 <erik@xxxxxxxx>
> Sent by: equinox-dev-bounces@xxxxxxxxxxx
> 08/27/2007 01:58 PM
> Please respond to
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
>
>
> To
> Equinox development mailing list <equinox-dev@xxxxxxxxxxx>
> 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@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/equinox-dev
>
>



_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev