Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <46CC57B5.9000405@optrak.co.uk>
Date: Wed, 22 Aug 2007 16:35:17 +0100
From: Mark Thornton <mthornton@optrak.co.uk>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: Problem with Webstart deployment
References: <14F2F2B716C13E418B68B44FFA3D8AE806F396@server>
In-Reply-To: <14F2F2B716C13E418B68B44FFA3D8AE806F396@server>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Lindsay Holman wrote:
> Hi all,
>
> I hope I have sent this to the appropriate place.
>
> I am developing a webstart application which incorporates an embedded
> Derby DB.
>
> I am having a problem however trying to lookup resources,
> specifically, the getInputStream() method on CPFile.
>
> Running the app against the same DB (deployed as a jar) outside of
> webstart works fine.
>
> To add to the confusion, the particular .dat file being loaded does
> load successfully sometimes, but not at other times.
>
> Debugging, I can see CPFile get's the JNLP class loader, and calls
> getResourceAsStream, passing the path to the required data file (in my
> case QDB/seg0/c49b1.dat).  This simply returns null, resulting in the
> method eventually raising a FileNotFoundException, which appears in
> the Derby log.  Interestingly, it is always at the same spot that this
> method fails.  The same class loader is definitely being referenced by
> the successful and unsuccessful attempts at loading this resource.
>
> Has anyone come across anything like this?  I know it sounds like a
> JNLPClassLoader issue, but I thought someone here may have seen
> something similar.
>
> Regards
>
> Lindsay Holman
>   
How many jar files do you have and if more than one is the jar file 
containing the database explicitly specified in the JNLP file? WebStart 
takes no notice of ClassPath attributes in jar file manifests.

Mark Thornton