David,
+1 on that. But when you "bundle" something with something
else, I think the bundled things have to agree on various
interfaces and the project schedules should allow for that.
In this particular case, I don't think there would any
problem with upgrading the bundled Java DB bits, but that
is a call to be made.
Dhiru, are you the right person?
Thanks,
Kedar
David Harrigan wrote:
> Hi Kedar,
>
> Thanks for the update. I'll certainly try that. However, if it works (and I
> suspect that it will work), shouldn't the emphasis be on getting this
> supported version of Derby/JavaDB into Glassfish v2 before the feature
> freeze happening shortly? From my own experiments with Derby 10.1.3.1
> and Derby 10.2.1.6 it appears that the upgrade is painless (provided that
> the db is recreated using the new version of Derby - all existing
> functionality
> works as before).
>
> I'm saying this because I'm really excited to be using Derby with Java and
> to have Glassfish support the offically released version for 9.1 would be
> quite simply awesome! :-)
>
> -=david=-
>
>
> Kedar Mhaswade wrote:
>
>> Hello David,
>>
>> I am not a 100 % sure, but your guess appears right.
>> The server runtime uses the javadb jars (actually it
>> should only use derby.jar and its locale-specific equivalents).
>> This is because runtime needs an embedded database for
>> ejb-timers. (See $domain-dir/lib/databases/ejb-timer).
>>
>> It looks to me that the Embedded Driver that application
>> server loads does not know how to load the database created
>> by a higher javadb version.
>>
>> Even if I suggested you to "override" the javadb jars that the
>> runtime uses by using classpath-prefix, the problem will remain,
>> because the ejb-timer database will be created with an older
>> javadb jars and if that database can not be loaded, server doesn't start.
>>
>> Can you try:
>> - back the current javadb software up.
>> - make <install-dir>/javadb point to the latest version.
>> - *create a new domain*, using asadmin create-domain command, enter
>> the master password as "changeit" upon prompted, call the domain say
>> "new".
>> - start the domain: "asadmin start-domain new"
>>
>> Note that the new domain creation process uses the latest javadb jars
>> to create the embedded ejb-timer database.
>>
>> Now deploy the application that has packaged database.
>> My guess is that it will work this time.
>>
>> Regards,
>> Kedar
>>
>> David Harrigan wrote:
>>
>>> Hi,
>>>
>>> I posted this on the Forums, but no feedback, and I've logged a bug. I
>>> think
>>> this is quite an important issue that affects the adoption of the latest
>>> stable released version of Derby with GF. It's also quite serious in the
>>> fact that 10.2.1.6 is the officially supported version from Sun as well!
>>> Here are the URLs (I've recently tested this with B25 and the same issue
>>> applies):
>>>
>>> http://forums.java.net/jive/thread.jspa?threadID=19077
>>> https://glassfish.dev.java.net/issues/show_bug.cgi?id=1305
>>>
>>> I've got a packaged database (jar) in my WEB-INF/lib dir that was created
>>> from the released 10.2.1.6 version of derby. I'm trying to open up the
>>> database using this supported protocol:
>>>
>>> jdbc:derby:classpath:searchdb.jar
>>>
>>> However, I'm getting an exception back:
>>>
>>> SQL Exception: Catalogs at version level 'null' cannot be upgraded to
>>> version level '10.1'.
>>>
>>> Now, that's the problem, this is what I know:
>>>
>>> Recreating and repackaging my database as 10.1.3.1 version works fine
>>> (i.e.,
>>> my app boots).
>>>
>>> Is this because 10.1.3.1 of Derby jars (derbyclient) is in the classpath?
>>> I
>>> notice it's in the javadb directory.
>>>
>>> -=david=-
>>>
>>>
>>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>
>>
>>
>>
>
>