Hello Oliver,
Oliver Zeigermann <oliver.zeigermann <at> gmail.com> writes:
> The ResourceManager interface rather is some sort of relict from older times.
> No need to worry much about it except for backward compatibility.
This can be the hardest thing to worry about ;)
> 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.
No, hugeness is not something I really worry about. The risk of breaking
anything even by the simplest change is mostly not worth the gain. So I don't
care about size but number of concerns, what's a big difference ... ok, this is
nitpicking :)
Actually I would like to address some different requirements with my
FileResourceManager, which I can no longer fulfill by just extending the current
one. Reimplementing the current ResourceManager interface would be absolute
overkill as the transactional stuff is exactly the same. It's only the resource
handling I need in a different way.
My use case: We have some data input and output dirs for different let's call
them communication partners and a common repository dir:
ROOT -- cp1 -- upload
| \- download
|- cp2 -- upload
| \- download
|
\- repo
Up to now the data dirs and the repo dir had a common root to which I set the
store dir. But now data dirs and repo dir can be completely different. I could
set the store dir to "/" but I don't think that's really appropriate.
Furthermore the FileResourceManager does a recursive delete of directories so
that the data dir structure gets lost atm. With the current behaviour I would
need one FileResourceManager for every sub dir. This would be acceptable if they
had not such a huge overhead of lifecycle but would only be wrappers around file
system access. All instances would refer to one TransactionManager then. Another
possibility would be to allow the FileResourceManager to handle multiple store
dirs but I'd prefer the first approach.
Hope this explains it a bit ...
> Anyway, if you want to introduce something new, got ahead, but be
> aware of backward compatibility issues.
The question is in which extend. Even simply stripping the transactional concern
from ResourceManager interface into its own and letting the FileResourceManager
implement both interfaces, can lead to incompatibilities if the methods for
transactional concern are called on the ResourceManager interface and not on the
FileResourceManager instance.
> P.S.: I think it might be the time for a 1.2 release. What do you think?
See other thread ...
Jörg
> 2006/7/13, Joerg Heinicke <joerg.heinicke <at> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
