Hi, Jörg!
That certainly is post 1.2, right? Maybe even some work for a 2.0
version? More details inline.
2006/7/14, Joerg Heinicke <[EMAIL PROTECTED]>:
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.
Hmmm. Why do you need FileResourceManagers in the fist place? Just to
synchronize file access? Not quite sure here...
Anyway, TransactionManager wouldn't be such a good name for a new
class as it has a predefinied meaning in the J2EE world I guess.
> 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.
One way would be to leave the ResourceManager interface untouched and
introduce your two new interfaces. FileResourceManager would implement
all three interfaces.
Another idea would be to make it all better in 2.0 and do not care too
much for backward compatibility. One idea might be to even use Java 5
locking. Maybe this is stuff for another thread, though...
Oliver
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
