db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Myrna van Lunteren" <m.v.lunte...@gmail.com>
Subject Re: [jira] Updated: (DERBY-2469) Java Web Start JNLP PersistenceService API storage support
Date Tue, 12 Jun 2007 22:38:03 GMT
On 6/12/07, Mike Matrigali (JIRA) <jira@apache.org> wrote:
>     [ https://issues.apache.org/jira/browse/DERBY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
> Mike Matrigali updated DERBY-2469:
> ----------------------------------
> I am concerned about making this part of the release that is coming up.  I haven't been
able to apply the patch, but as far as I can tell there is no test to verify it works at all.
 Also not clear what needs to be done to use it.
> I do wish Derby had a better mechanism for delivering experimental code to users who
would rather not apply patches and build for themselves.  Until this module is tested it seems
like it should not be part of a delivered derby jar.
> Derby has been built to allow for just these kinds of extensions, it would be nice if
we could somehow improve the release mechanism to allow for this, but whether myrna wants
to do that is up to her.  I would like it if these extensions could be added to a separate
jar, maybe derby_experimental.jar to make it very clear that it is not currently supported.
  I havent seen much write up for this feature so I don't know if it might affect backward
compatibility, or somehow affect files in existing databases if called on them.  We may want
to log warnings to errror logs about experimental, may want to mark dbs as beta, ....
> I think it would also be nice if there was an area of the trunk where things like
> this could get checked in so that multiple people could work on stuff like this but
> where it was easy for a release manager could pick and choose whether it
> should be included in an actual release.   In this case it might also serve to
> make sure that the interfaces are right for this module such that one need
> not bundle the new module with the default implementation.
> > Java Web Start JNLP PersistenceService API storage support
> > ----------------------------------------------------------
> >
> >                 Key: DERBY-2469
> >                 URL: https://issues.apache.org/jira/browse/DERBY-2469
> >             Project: Derby
> >          Issue Type: New Feature
> >          Components: Store
> >    Affects Versions:
> >         Environment: Java Web Start
> >            Reporter: Luigi Lauro
> >            Assignee: David Van Couvering
> >            Priority: Minor
> >         Attachments: svn-diff-20070329, svn-diff-20070606, svn-diff-20070612
> >
> >
> > I would love to have Derby write/read to the storage area provided by the JNLP PersistenceService
> > Since Derby is now bundled with the Java6 JDK as JavaDB, I think this  integration
would go a long way towards making derby more developer- friendly in Java Web Start environments,
where using the sandbox tools Sun provides us it the right way to go, instead of working 
around it and force the user to give the app the authorization to write on the hard drive
> > I'm investigating the effort needed to provide an implementation of the WritableStorageFactory
interface around the PersistenceService API, and if that's doable in a few days work, I will
start working on it and submit a patch for testing/approval ASAP.
> > Feel free to volounteer and provide pointers/hints/whatever, it's really appreciate,
especially since I currently know nothing of derby internals.
> --
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.

Ok, thanks Mike for your input.
My very first comment on this - which appears to have gotten snowed
under - was exactly concern as to what this would be doing to

As I didn't hear from anyone else except two clear proponents, I felt
inclined to see how far David and Luigi could get this code.

As I'm cutting the 10.3 candidate release on Friday, I do not see this
being anywhere ready for inclusion as 'product'; Luigi indicated
there's not been much testing, unless I misunderstood that, it
requires jdk1.5., whereas our normal build process should work with

If it can be arranged somehow to accept it without going into
derby.jar I have no objection to it being in the branch.
So, that leaves some options.
1.  don't check it in unless it's acceptably working and testing
2.  check it in, but don't build it
3.  check it in, but build it to a separate jar file.
4. ...

I'd prefer 2 or 3, and I do not want to hold up the release for it...


View raw message