[ 
https://issues.apache.org/jira/browse/TRANSACTION-9?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12513925
 ] 

Oliver Zeigermann commented on TRANSACTION-9:
---------------------------------------------

I do agree concerning properties and Resource vs. ResourceManager. This is my 
new proposal

public interface Resource {
    String getPath();
    boolean isDirectory();
    boolean isFile();

    Collection<Resource> getChildren() throws IOException, LockException;
    Resource getParent() throws IOException, LockException;

    InputStream readStream() throws IOException, LockException;
    OutputStream writeStream() throws IOException, LockException;

    boolean delete() throws IOException, LockException;
    boolean move(String destinationpath) throws IOException, LockException;
    boolean copy(String destinationpath) throws IOException, LockException;
    boolean exists();
    void createDirectory() throws IOException, LockException;
    void createFile() throws IOException, LockException;

    // plus more general properties
   // among them could be length, lastmodfied, etc.
    Object getProperty(String name);
    Object setProperty(String name, Object newValue);

    // plus locking methods
    void readLock();
    void writeLock();
    boolean tryReadLock();
    boolean tryWriteLock();
}

public interface FileResourceManager {
   Resource getResource(String path) throws IOException, LockException;
   void addResourceListener(ResourceListener listener);
   void removeResourceListener(ResourceListener listener);
 } 

However, I do not agree to use bean style here, as this is no bean. This is an 
interface. It should not have bean style getters/setters.

Concerning try*Lock(): These methods are fail fast version of the lock*() ones 
which can be used to check whether you *could* acqurie a lock or not. They make 
sense if you just want to know.



> [transaction] Add full file management capabilities to the FileResourceManager
> ------------------------------------------------------------------------------
>
>                 Key: TRANSACTION-9
>                 URL: https://issues.apache.org/jira/browse/TRANSACTION-9
>             Project: Commons Transaction
>          Issue Type: Improvement
>         Environment: Operating System: All
> Platform: All
>            Reporter: Peter Fassev
>            Assignee: Oliver Zeigermann
>            Priority: Minor
>             Fix For: 2.0
>
>         Attachments: filemanager.zip
>
>
> Hi,
> As stated in the doc the FileResourceManager is:
> "A resource manager for streamable objects stored in a file system"
> I agree, that this is a resource manager, but it could be easily extended, to 
> support a full file management system. It will be very helpful to have 
> additional methods like renameResource(), getResourceSize(), 
> getResourceTime(), 
> setResourceTime() etc. This are common file operations, which should be 
> managed 
> by the FileResourceManager.
> Further it will be very helpful to have (real) support for resource 
> collections 
> (folders). It will be necessary to distinguish between single resources 
> (files) 
> and collections (folders). 
> Together, this features will enable a transactional access to any file based 
> resources - for instance a document repository.
> Are there plans for such extensions and if not, will they actually fit in the 
> goals of the transaction library?
> If not, please open the underlying structure, like the inner class 
> TransactionContext, in order to add extensions the file management. For 
> instance, it will be good to have a separate factory method, which creates 
> the 
> context.
> If you are interested in this proposal, I am ready to contribute to this 
> project. I consider myself as an experienced java developer and I will be 
> glad 
> to help you. 
> Best regards
> Peter Fassev

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to