commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Heinicke (JIRA) <j...@apache.org>
Subject [jira] Commented: (TRANSACTION-9) [transaction] Add full file management capabilities to the FileResourceManager
Date Fri, 20 Jul 2007 00:41:06 GMT

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

Jörg Heinicke commented on TRANSACTION-9:
-----------------------------------------

Actually I'm not very keen to these lock methods at all, but if you think it's better to have
them I'm ok with it.

The only thing we should have in mind is to not invent a second JCP 170 aka JCR (Content Repository
for Java). Actually I wonder how the JCR implementations do transactional file system access.

Regarding the interface proposal:
1. setProperty() is probably supposed to return void.
2. Thinking about it a bit more I agree on read/writeStream(). Using those in bean style makes
not much sense.
3. writeStream() should probably have boolean parameter "append" again.
4. I still don't like the createFile/Directory() stuff. Sounds like creating sub resources,
so it should be at least createAsFile/Directory(). But having both makes not much sense. Isn't
it more a question of implementation, e.g. FileResource and DirectoryResource. Then create()
would be sufficient. Question: How to decide whether to create a directory or a file then?
Might be moved to ResourceManager then. What about getResource() with additional enum type
parameter? Or getDirectoryResource() and getFileResource()? Moving that difference to the
ResourceManager increases the usability IMHO. WDYT?
5. Just an idea: getChildren() matches listFiles() in File - the latter providing filter mechanism.
What about that? If we have Resource instead of File we would also have Resource(NameFilter)
- and could provide default adapter implementation for File(Name)Filter.

> [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: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message