I'd +1 that. But.. I dunno if I count.
Matt
On 11/10/06, kedar <Kedar.Mhaswade_at_sun.com> wrote:
> 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
> >>
> >>
> >>
> >>
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>