Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipselink-dev] osgi persistence.xml hack

Hi Tim,

  Sorry for the late response.  We had a long weekend in Canada.

I'm afraid I do not have a good answer, but maybe if I explain what is happening someone on the list will have an idea.

Archive provides an abstraction that allows us to read persistence units from different types or URLs. There is a factory class that builds an Archive for us based on the URL where the persistence.xml exists. We get the URL of the persistence.xml by asking for it as a resource from whatever classloader we are given. (in the case of OSGI, it should be the ClassLoader that is passed in to the EntityManagerFactory creation code)

We use Archives to examine the persistence unit. We get classes and resources with the Archive, and we use it to try to discover what classes are in a persistence unit.

  There are a number of types of Archives:

- If the URL has a "file" protocol we either build a DirectoryArchive that is capable of navigating directory structures or a JarFileArchive that uses the Jar's manifest to find files arnd resources - If the URL has a "jar" protocol, there are a number of archives that can be used to examine it depending on what it contains. - If it is another kind of URL that can be resolved to a jar, an Archive is built that can examine a jar by loading it through a URL. - In any other case, we build what is called a URLArchive. The allows us to get basic information, but does not provide the functionality that allows us to do things like discover the classes in the persistence unit. This is the kind of Archive we are likely getting for a URLlike: bundleresource://27/

I suspect that if we can find any functionality that is particular to bundleresources, we will want to build an Archive type that can handle bundle resources. Fortunately the code is fairly simple and, in fact, is completely self contained - i.e. it does not rely on any other part of the EclipseLink code.

  The getEntry() code in URLArchive looks as follows:

public InputStream getEntry(String entryPath) throws IOException {
    URL subEntry = new URL(url, entryPath);
    InputStream is = null;
    try {
        is = subEntry.openStream();
    } catch (IOException ioe) {
        // we return null when entry does not exist
    return is;

  Looking at that code, I suspect one of two things could be happening:
1. The "bundleresource" URL does not deal well with how we build a sub-entry.
2. Something changes about the classloader between when the persistence unit is created and when it is used. For instance, the classloader the URL came from is no longer usable.

I'm not sure how helpful this is, but if there's anything more specific you need, just let me know,

Tim Hollosy wrote:
Woops, I truncated the rest of that message, the rest:

Once we comment out the reading of the peristence.xml from the Archive
and read directly from the classloader like:
loader.getResourceAsStream("META-INF/persistence.xml"); it works.

So at this point the only thing I can think of is a timing thing, for
whatever reason when the Archive class is created it can't find the
persistence.xml, but when we read it from the loader directly later on
it's there.

Any ideas? Because I'm kind of stumped.

On Fri, May 16, 2008 at 12:20 PM, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:
Ok, I was unable to replicate this using our comics crud rcp example.
I tried many things, like starting it from a different bundle,
creating an EMF in an activator, outside the activator.

I'm kind of stumped, here's what we do know though.

When EclipseLink starts up it creates an Archive class to hold an
instance to the file, this is empty when running with our large

On Fri, May 16, 2008 at 9:44 AM, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:
The only thing I could see is the use of multiple plugins.

We have our EMF loaded from a seperate plugin.

So it goes:

Model (bundle1)->EMFFactory(bundle2)

However the persistence xml is defined in bundle1.

This way we can re-use the EMFFactory in multiple plugins and each
plugin doesn't need to know how to do the dirty work to set up an EMF,
it just gets one.

Today I am going to try to replicate the problem using your comics
derby db, that way I can ship you over the plugins once it breaks and
you can try.


On Fri, May 16, 2008 at 9:21 AM, Shaun Smith <shaun.smith@xxxxxxxxxx> wrote:
Hi Tim,

   I was able to take the Comics RCP demo I'd built and export it as a
product.  It ran fine with the bundles generated from the trunk.

   Can you try doing the same to confirm it works for you?  If it doesn't
run we may have an environmental difference.  If it does then we need to
look at how your code that obtains an EntityManagerFactory differs from the
way it's done in the example that runs.


Tim Hollosy wrote:

Any luck on getting an app built to test outside of Eclipse Tom?

Also, I forgot to mention I did create a bug for this -

On Wed, May 14, 2008 at 4:43 PM, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:

Ya, I think it's a little different once it's on it's own outside of
eclipse.  Once you're outside of eclipse that's when you start using
the build path stuff you setup in your Manifest.MF.

On Wed, May 14, 2008 at 4:39 PM, Tom Ware <tom.ware@xxxxxxxxxx> wrote:

My initial attempt was using Shaun's simple demo.  (the one in
org.eclipse.persistence.demo.jpa.comics.setup).  I was able to run that demo
from a standalone Equinox by deploying the appropriate bundles.  It
sucessfully initializes a persistence unit and does some simple queries.

I'll try packaging one of those demos as an application and see if that
yields the issue.


Tim Hollosy wrote:

Ah, now I see the disconnect -- I forget you guys aren't RCP devs :)

I'm not talking just running with your bundles, those all start up
fine. I'm talking using the bundles. You need to have a project that
actually has a persistence.xml and uses org.eclipse.peristence.jpa --
like one of Shaun's examples. That's where the problem comes in, in
the code that runs when it tries to find the persistence.xml for the
calling bundle!

So if you took one of shaun's osgi examples, made a project out of it
and exported it, that's where you'd see the error, not simply loading
eclipse with your bundles installed & started.


On Wed, May 14, 2008 at 4:18 PM, Tom Ware <tom.ware@xxxxxxxxxx> wrote:

What should I expect to see when I run the example projects in eclipse.
the moment, seem to activate for me, but I do not get any kind of UI or
feedback. Is that expected?


Tim Hollosy wrote:

Unless you have an osgi project that hits a db right now that you can
create a product for and export from the pde then i'm not sure you'll
be able to recreate it. I would do it myself with the comics crud
example I submmited, but I switched dev boxes recently and don't have
the comics derby db handy right now, otherwise i'd just do it. I think
i'll be able to do it tommorow though.

The bug is here:

You could try checking out that project get it running in eclipse,
then creating a product for it, exporting it as an exe and see if it

Let me know if that makes sense.

On Wed, May 14, 2008 at 1:44 PM, Tom Ware <tom.ware@xxxxxxxxxx> wrote:

The nightly bundles we build are built in ant.  The eventual goal is
publish PDE projects for the org.eclipse.persistence.* plugins.  The
will only be shipped as jars.

At the moment, my attempt at recreation is through running equinox
standalone, importing all the required bundles and starting my
 That does not seem to be sufficient.  I'll try some different
see if I can recreate. Anything you can let me know that will help
will be helpful.


Tim Hollosy wrote:

I'll try to duplicate with the nightly plugins, but how are you
testing?  Are you creating a product in eclipse and exporting from
there, or are you using ant?

I'll try to duplicate our issue with the comics example I checked in,
then it'll be easier for you to dup, i'll check back in later.

On Wed, May 14, 2008 at 11:41 AM, Tom Ware <tom.ware@xxxxxxxxxx>

Hi Tim,

 We are now creating plugins as part of our build.  I was unable to
the issue you mention below with those plug-ins.  I am wondering if
still get it with those plugins.

 The most recent plugins are published with our nightly builds.  Just
for: for last night's

Note: There is an issue with the ant plug-in found in the zip file
now, so you will likely have to export that file from our Eclispe PDE
project for now.


Tim Hollosy wrote:

HI devs!

After mucking around trying to get OSGi EclipseLink to work
of eclipse (an exported eclipse product),  We've finally gotten it


in the processPersistenceArchive method

Instead of getting the XML stream from the "Archive" class like:
InputStream pxmlStream =

-- which doesn't work for some reason.

You can instead use the classLoader's getResourceAsStream method

InputStream pxmlStream =

I'm not exactly sure why the Archive class stuff doesn't work
of eclipse, since the getResources() call on the classLoader seems
work fine, but I thought someone might be interested in this work

As an aside -- I think you might want to look at testing outside of
eclipse, since apparently osgi in and outside of eclipse are two
different animals.

eclipselink-dev mailing list

eclipselink-dev mailing list

eclipselink-dev mailing list

eclipselink-dev mailing list

eclipselink-dev mailing list



Shaun Smith | Principal Product Manager, TopLink | +1.905.502.3094
Oracle Fusion Middleware
110 Matheson Boulevard West, Suite 100
Mississauga, Ontario, Canada L5R 3P4

eclipselink-dev mailing list



Back to the top