Eclipse Community Forums: Equinox » Bundling Berkeley DBXML

Help

Home

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

Show: Today's Messages :: Show Polls :: Message Navigator

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

Mon, 10 April 2006 20:11

Ronald Pomeroy

Messages: 19
Registered: July 2009

Junior Member

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

Report message to a moderator

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

Tue, 11 April 2006 08: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.

Report message to a moderator

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

Tue, 11 April 2006 18:29

Ronald Pomeroy

Messages: 19
Registered: July 2009

Junior Member

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

Report message to a moderator

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

Tue, 11 April 2006 18:46

Richard Backhouse

Messages: 19
Registered: July 2009

Junior Member

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?
>

Report message to a moderator

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

Tue, 11 April 2006 19:01

Harald Niesche

Messages: 23
Registered: July 2009

Junior Member

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

Report message to a moderator

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

Wed, 12 April 2006 17:06

Ronald Pomeroy

Messages: 19
Registered: July 2009

Junior Member

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

Report message to a moderator

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

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Thu Apr 25 17:36:51 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter