[
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,
Tom
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
plugin.
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.
Tim
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.
Shaun
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 -
https://bugs.eclipse.org/bugs/show_bug.cgi?id=231299
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.
-Tom
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.
Tim
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.
At
the moment, seem to activate for me, but I do not get any kind of UI or
feedback. Is that expected?
-Tom
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: https://bugs.eclipse.org/bugs/show_bug.cgi?id=226361
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
works.
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
only
to
publish PDE projects for the org.eclipse.persistence.* plugins. The
others
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
application.
That does not seem to be sufficient. I'll try some different
strategies
to
see if I can recreate. Anything you can let me know that will help
recreate
will be helpful.
Thanks,
Tom
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>
wrote:
Hi Tim,
We are now creating plugins as part of our build. I was unable to
recreate
the issue you mention below with those plug-ins. I am wondering if
you
still get it with those plugins.
The most recent plugins are published with our nightly builds. Just
look
for: eclipselink-plugins-incubation-20080514.zip for last night's
build
at:
http://www.eclipse.org/eclipselink/downloads/nightly.php
Note: There is an issue with the ant plug-in found in the zip file
right
now, so you will likely have to export that file from our Eclispe PDE
project for now.
-Tom
Tim Hollosy wrote:
HI devs!
After mucking around trying to get OSGi EclipseLink to work
_outside_
of eclipse (an exported eclipse product), We've finally gotten it
to
work:
In
org.eclipse.persistence.internal.jpa.deployment.PersistenceUnitProcessor
in the processPersistenceArchive method
Instead of getting the XML stream from the "Archive" class like:
InputStream pxmlStream =
archive.getEntry("META-INF/persistence.xml");
-- which doesn't work for some reason.
You can instead use the classLoader's getResourceAsStream method
like
this:
InputStream pxmlStream =
loader.getResourceAsStream("META-INF/persistence.xml");
I'm not exactly sure why the Archive class stuff doesn't work
outside
of eclipse, since the getResources() call on the classLoader seems
to
work fine, but I thought someone might be interested in this work
around.
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.
Thanks!
Tim
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
_______________________________________________
eclipselink-dev mailing list
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
--
./tch
--
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
eclipselink-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
--
./tch
--
./tch