Eclipse Community Forums: Equinox » Bundling Berkeley DBXML

Home » Eclipse Projects » Equinox » Bundling Berkeley DBXML - Advice from the experts requested

Bundling Berkeley DBXML - Advice from the experts requested [message #64757]

Mon, 10 April 2006 16:11

Eclipse User

I'm suffering an infatuation with native XML databases - specifically -
Berkeley DBXML. To fall in love I need a friendly environment to
explore the technology. Being a big fan of both the OSGi and Eclipse
Extensions model, I intend to mold an environment that leverages these
approaches as much as possible.

I've successfully created a bundle containing the required jars and
native libraries - but the implementation isn't "clean".

My bundle has an activator that hardcodes the list of native libs to
load (with load order implied) and does a System.loadLibrary() on all
of them because there is a chain of dependency between the native libs.
I've tested this part and everything works well.

I took a stab at seperating the platform specific stuff (which turns
out to be pretty much everything from the jars to the native libraries
- no matter) into fragments. I also want move the hardcoded native
library list into the MANIFEST.MF.

Even though you can specify Bundle-NativeCode: in each of the fragments
there doesn't seem to be a way specify that I want all the native code
libraries to be loaded at once - in order - when the plugin is
activated.

So as a compromise I'd like to still specify the native code in the
Bundle-NativeCode stanza but have my host plugin find the
Bundle-NativeCode statement in the platform specific fragment at bundle
activation time and use that list to System.loadLibrary() each of them.

I tried using Bundle.findEntries("META-INF", "MANIFEST.MF", false).
This gives me an Enumeration of bundle entry URLs. The URLs are of the
form bundleentry://.... I can't seem to find API that takes one if
these URLs and resolves it to something useful for me to get at the
ManifestElement in the fragment.

Feels like I'm heading the wrong direction - it shouldn't be difficult
to get at a fragment's MANIFEST.MF.

Pointers from those more knowledgeable than I are greatly appreciated.

--
Thanks,

Ron
rpomeroy at mac.com

Re: Bundling Berkeley DBXML - Advice from the experts requested [message #64780 is a reply to message #64757]

Tue, 11 April 2006 04:56

Eclipse User

Originally posted by: yavin.gmx.com

> I tried using Bundle.findEntries("META-INF", "MANIFEST.MF", false).
> This gives me an Enumeration of bundle entry URLs. The URLs are of the
> form bundleentry://.... I can't seem to find API that takes one if
> these URLs and resolves it to something useful for me to get at the
> ManifestElement in the fragment.

Have a look at the function Bundle.getHeaders() or use
Bundle.getResource("META-INF/MANIFEST.MF") to get the URL to your
manifest. If you got the URL you can get the InputStream by
URL.openStream(). Pass this to the constructor java.util.jar.Manifest
and you will get a representation of the manifest.

Re: Bundling Berkeley DBXML - Advice from the experts requested [message #64802 is a reply to message #64780]

Tue, 11 April 2006 14:29

Eclipse User

On 2006-04-11 01:56:26 -0700, Kai <yavin@gmx.com> said:

>> I tried using Bundle.findEntries("META-INF", "MANIFEST.MF", false).
>> This gives me an Enumeration of bundle entry URLs. The URLs are of the
>> form bundleentry://.... I can't seem to find API that takes one if
>> these URLs and resolves it to something useful for me to get at the
>> ManifestElement in the fragment.
>
> Have a look at the function Bundle.getHeaders() or use
> Bundle.getResource("META-INF/MANIFEST.MF") to get the URL to your
> manifest. If you got the URL you can get the InputStream by
> URL.openStream(). Pass this to the constructor java.util.jar.Manifest
> and you will get a representation of the manifest.

The problem is features are logically merged with their host bundle.
In a merged bundle there are
more than one MANIFEST.MF files - hence the API Bundle.findEntries().

I can't specifically reference the fragment's MANIFEST.MF from the host
bundle code - that would go against the whole purpose of fragments.

Thanks anyway for taking a shot at it.

I'm really confused. Why would we have "bundleentry://" protocol URLs
if no API makes use of it. Is this internal API leakage? One method
that could take this sort of URL and resolve it to a physical artifact
is what I'm looking for.

Anyone?....Bueller?

--
Thanks,

Ron
rpomeroy at mac.com

Re: Bundling Berkeley DBXML - Advice from the experts requested [message #64847 is a reply to message #64802]

Tue, 11 April 2006 14:46

Eclipse User

You don't need to care about the URL protocol used :

Enumeration e = bundle.findEntries("META-INF", "MANIFEST.MF", false);
while (e.hasMoreElements()) {
URL url = (URL)e.nextElement();
Manifest m = new Manifest(url.openStream());
}

Ronald Pomeroy wrote:
> On 2006-04-11 01:56:26 -0700, Kai <yavin@gmx.com> said:
>
>>> I tried using Bundle.findEntries("META-INF", "MANIFEST.MF", false).
>>> This gives me an Enumeration of bundle entry URLs. The URLs are of the
>>> form bundleentry://.... I can't seem to find API that takes one if
>>> these URLs and resolves it to something useful for me to get at the
>>> ManifestElement in the fragment.
>>
>>
>> Have a look at the function Bundle.getHeaders() or use
>> Bundle.getResource("META-INF/MANIFEST.MF") to get the URL to your
>> manifest. If you got the URL you can get the InputStream by
>> URL.openStream(). Pass this to the constructor java.util.jar.Manifest
>> and you will get a representation of the manifest.
>
>
> The problem is features are logically merged with their host bundle. In
> a merged bundle there are
> more than one MANIFEST.MF files - hence the API Bundle.findEntries().
>
> I can't specifically reference the fragment's MANIFEST.MF from the host
> bundle code - that would go against the whole purpose of fragments.
>
> Thanks anyway for taking a shot at it.
>
> I'm really confused. Why would we have "bundleentry://" protocol URLs
> if no API makes use of it. Is this internal API leakage? One method
> that could take this sort of URL and resolve it to a physical artifact
> is what I'm looking for.
>
> Anyone?....Bueller?
>

Re: Bundling Berkeley DBXML - Advice from the experts requested [message #64870 is a reply to message #64802]

Tue, 11 April 2006 15:01

Eclipse User

Ronald Pomeroy wrote:
> I'm really confused. Why would we have "bundleentry://" protocol URLs
> if no API makes use of it. Is this internal API leakage? One method
> that could take this sort of URL and resolve it to a physical artifact
> is what I'm looking for.

Have you tried
new URL("bundleentry://...").getContent()
??

The URL class should be able to use the "bundleentry://" URLs -- the
framework registers a URLStreamHandlerFactory that allows these URLs to
be resolved.

Harald

Re: Bundling Berkeley DBXML - Advice from the experts requested [message #64946 is a reply to message #64870]

Wed, 12 April 2006 13:06

Eclipse User

On 2006-04-11 12:01:18 -0700, Harald Niesche <harald@brokenerror.de> said:

> Ronald Pomeroy wrote:
>> I'm really confused. Why would we have "bundleentry://" protocol URLs
>> if no API makes use of it. Is this internal API leakage? One method
>> that could take this sort of URL and resolve it to a physical artifact
>> is what I'm looking for.
>
> Have you tried
> new URL("bundleentry://...").getContent()
> ??
>
> The URL class should be able to use the "bundleentry://" URLs -- the
> framework registers a URLStreamHandlerFactory that allows these URLs to
> be resolved.
>
> Harald

Thanks Harald. I'm sure this will come in handy but I've decided to
package each platform implementation in a single plugin instead of one
plugin with platform specific fragments. Once it sunk in that the jars
were also platform specific and there's no separation of API and
implementation, I realized the case for using fragments here is greatly
diminished. I also realized you can use platform filters on plugins
too. Neat. I'll still try to capture the native lib refs in
Bundle-NativeCode in the plugins MANIFEST.MF. It would be nice if OSGi
added something like Bundle-NativeCode-Preload:=true and solved this
problem generically.

--
Thanks,

Ron
rpomeroy at mac.com

Previous Topic:	serverside OSGi property org.eclipse.equinox.servlet.bridge.enabled
Next Topic:	bundling by reference

Goto Forum:

-=] Back to Top [=-

Current Time: Sat Jul 26 00:02:21 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter