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] Commented: (DERBY-2469) Java Web Start JNLP PersistenceService API storage support
Date Wed, 13 Jun 2007 04:36:34 GMT
On 6/12/07, David Van Couvering (JIRA) <jira@apache.org> wrote:
>    [ https://issues.apache.org/jira/browse/DERBY-2469?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12504061
> David Van Couvering commented on DERBY-2469:
> --------------------------------------------
> I agree it needs to get tested, and I'm working on that (and I've asked MIchelle to help)
> But yes I believe it should be considered experimental. I like the idea of putting it
into a separate jar file.
> How about the following approach:
> - Create a new top-level subdirectory called 'experimental'
> - Create a package org.apache.derby.jnlp and put the new classes there (fixing them as
necessary so they do not require package-private access to the default implementation)
> - build-jars creates a new jar file, derby-experimental.jar, that contains all the classes
in the experimental subdirectory
> The way I *think*  you use it (I haven't been able to verify this actually works yet)
is that you add a new subsubProtocol in modules.properties called 'jnlp' (derby.storage.subsubProtocol.jnlp6=org.apache.derby.jnlp.JNLPStorageFactory)
and then use the URL "jdbc:derby:jnlp:mydb;create=true" (or something to that effect).   You
would add this to modules.properties so it is only enabled for Java 5 or higher.
> The intended use is that when you create a Java Web Start application, you use this storage
engine, and this makes it so the JWS application doesn't have to ask the user to grant permission
to use the local file system.
> Woudl this be acceptable for checkin?
> I also want to get it tested, and will work on that, but I would think that if it doesn't
break the build and doesn't go into the standard derby.jar, it should be check-inable without
tests.  This is similar to the way we treat our demo directory, it seems to me.  We want to
be able to check in stuff like this without having to go through a big gauntlet.  We almost
Luigi on this one, and we still don't have the in-memory storage and JMX support checked in
(both of which could I am pretty sure could be put in the experimental jar).

+1 I like that approach.
By the way, I hope I'm not sounding like a weathervane...It's exciting
to see new contributions by new (or existing) contributors, but on the
other hand, at this late stage I'm a little apprehensive about putting
in a big chunk of new code.
Thx David for looking into getting this in.


View raw message