Ok, I answer to you all on the several issues, in several upcoming comments
Summary of the patch (@Dan): currently derby supports only several storage system for the database file persistence. The aim of this patch is to add a new Storage system for derby, built upon the JNLP PersistenceService API, which is a sun provided persistence service meant to be used in java web start environments (web apps or web-deployed desktop apps, as the one I'm developing), and is meant to be sandbox friendly (no 'give me full access to your HD' popups as per using the standard file factory).
To get in depth, my implementation is currently made up of two implementation classes and an abstract class.
AbstractStorageFactory: abstract base class implementing StorageFactory interface. This is meant to be a base class for StorageFactory implementation classes, and it's a sort of 'cleaned up' and rewritten from scratch version of derby BaseStorageFactory class. It provides basic initialization logic for needed database/temp directories, and it also gives a standard temporary files implementation, using standard files.
JNLPStorageFactory: Java Web Start based StorageFactory implementation using JNLPStorageFile classes for file entities. All the persistence operations are delegated to JNLPStorageFile instances, which make use of the JNLP PersistenceService API provided by the Java Web Start framework, which is a sandbox friendly persistent storage available to JWS-enabled applications.
Persistence is based on a cookie-like mechanism which stores persistent entities associated with URLs. We build hierarchy upon this flat structure by using a implicit naming hierarchy.
Mapping is currently 1-1 (PersistenceEntity <---> Derby StorageFile) because I wanted to keep the implementation simple and straightforward, and this limits current applications of this factory till the sun PersistenceService implementation bug of maximum 255 persistence entries have been fixed (probably in next update, from the informations I have from Sun). This means the whole factory will fail horribly as soon as Derby asks for more than 255 storage entities.
The current implementation use JNLP Storage entities even for temporary files (to avoid using standard files, which will defy the whole purpose of this factory - making a sandbox friendly JWS enabled factory), but I plan to plug in a in-memory implementation for the temp files, in order to avoid spamming the persistence storage with temporary files (especially since the 255 max entities bug, presently).
JNLP Storage Entities have no hierarchy, so I had to code an implicit one into the name, using a special char (comma "," presently, as I thought it was the one least probable to be seen in URLs, but still valid).
A JNLP Storage entity therefore is associate with a given URL, which is usually something like "http://APP_CODEBASE/DIR1,DIR2,DIR3,FILE" (ex: "http://www.derby.com/jnlp/directory,subdirectory,file")
Currently, the implementation scan the whole persistent entities list to find the 'files' contained in a given directory, and parses all paths to find the entities that matches the needed path. This could be optimized by using data structures for indexing the entities, in order to avoid a full scan each time, but performance wise this should not be too much of a problem given the max 255 entities limit and the fact the PersistenceService is pretty efficient in retrieving the entities names. First make it work, then make it fast