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