Re: [eclipselink-dev] osgi persistence.xml hack

["Tim Hollosy" <hollosyt@xxxxxxxxx>]

The saga finally comes to an end!

Ok, so I've finally figured out what's going on by comparing two
plugins, one that worked when exported and another that didn't.

In the one that didn't work, I was manually adding src/META-INF (the
location of my persistence.xml) to the bundle class path along with .

The one that did work just had . in it's bundle classpath. After
removing the extra class path entry in the non-working bundle it now
works fine. I'm not sure why this happens, and weather this might be
another bug but I'll take that to the ticket.

Thanks for your help guys :)

Tim

On Tue, May 20, 2008 at 4:07 PM, Tim Hollosy <hollosyt@xxxxxxxxx> wrote:
> Thanks Tom,
> We tried to replicate it using a derby example and failed. I'm going
> to do some more debugging to see what's happening with the class
> loader between the time the archive gets created and when the file is
> actually read.
>
> /tim
>
> On Tue, May 20, 2008 at 3:57 PM, Tom Ware <tom.ware@xxxxxxxxxx> wrote:
>> 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
>>>>
>>>
>>>
>>>
>> _______________________________________________
>> eclipselink-dev mailing list
>> eclipselink-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/eclipselink-dev
>>
>
>
>
> --
> ./tch
>



-- 
./tch