db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Van Couvering (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-2469) Java Web Start JNLP PersistenceService API storage support
Date Wed, 13 Jun 2007 00:27:26 GMT

    [ 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).  

David

> 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: 10.2.2.0
>         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
API.
> 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
IMHO.
> 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.


Mime
View raw message