Hi, Jörg! My first implementation of FileResourceManager really implemented two interfaces that were close to what you propose. The idea was to have impementations other than to the file system. The ResourceManager interface rather is some sort of relict from older times. No need to worry much about it except for backward compatibility.
Why change things in the first place? Just because the FileResourceManager is huge? That is not a bad thing all by itself. Some classed simply get big. Compare it to the String class. It is twice as big. Anyway, if you want to introduce something new, got ahead, but be aware of backward compatibility issues. Oliver P.S.: I think it might be the time for a 1.2 release. What do you think? 2006/7/13, Joerg Heinicke <[EMAIL PROTECTED]>:
Hello, the more I work with the FileResourceManager the more I'm convinced that the ResourceManager interface should be splitted into two interfaces: one for handling the locking and transactional stuff (proposal: TransactionManager) and one for actually handling the resources (as is: ResourceManager). One the one hand the only implementation, the FileResourceManager, simply does too much, i.e. too many concerns are handled in it. On the other hand I extend my local version of the FileResourceManager with more and more methods to emulate a file system access (methods from java.io.File actually). In theory I would need to add these methods to ResourceManager interface to be able to work with interfaces, but it would get bigger and bigger. Instead I wonder if a generic ResourceManager interface (in my new sense as described above) is appropriate at all. Probably it would be more appropriate to rename it to FileResourceManager or introduce FileResourceManager interface extending ResourceManager. The splitting of the current ResourceManager interface would allow to reuse the transaction/locking capability with different ResourceManagers (in my new sense). The splitting should be quite easy IMHO. The concerns are quite good separated in the FileResourceManager. WDYT? Regards, Jörg --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]