commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Oliver Zeigermann" <oliver.zeigerm...@gmail.com>
Subject Re: [transaction] splitting ResourceManager interface
Date Thu, 13 Jul 2006 18:06:39 GMT
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 <joerg.heinicke@gmx.de>:
> 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: commons-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: commons-dev-help@jakarta.apache.org
>
>

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