Hello!
Sorry for being late, but I have had an appointment day with one of our
customers.
public abstract class Backup implements IOOperation {
protected Backup(final FuPolicy policy) {
And two implementations:
public class NoBackup extends Backup {
public class SimpleBackup extends Backup
What do you think, if the commands do not chain the next command, but if
they create a Undo-Command which will be put on a stack and - in case of
an exception can be processed to rollback all commands.
I havent though about it in every detail, but if it is possible it is
easier to handle - and
Mario Ivankovits wrote:
In pseudo code:
UndoStack tx = new UndoStack();
try
{
Backup(tx, ...)
Copy(tx, ...)
Move(tx, ...)
}
catch (Exception)
{
tx.rollback(); - process undo-stack
}
This looks ok. I still prefer each command to handle it's own cleanup
(try/catch/finally in part existing for
Hello!
I'm curious what you find out about Commons Transactions. When I
looked it over, it seemd to me designed with primitives for us to use
to make our own transactions. I missed any ready-to-use code for this
purpose. I wonder how much overlap there is with java.util.concurrent
in the
Mario Ivankovits wrote:
JDK5: Dont forget, our target is jdk1.3 (even if I use 1.5 since it is
out) You cant imagine how fast the first user shouted after I used (by
mistake) a jdk 1.4 method.
JDK 1.3!? I had no earthly idea.
-
B. K. Oxley (binkley) wrote:
I'm curious what you find out about Commons Transactions. When I
looked it over, it seemd to me designed with primitives for us to use
to make our own transactions. I missed any ready-to-use code for this
purpose.
After 2 hours of copy/paste their
Continuing the command pattern, I rejiggered the Save command to use a
Backup command rather than hard-coding the backup policy:
public class Save implements IOOperation {
private final Backup backup;
private final InputStream newContents;
private final FuFile original;
public
Mario Ivankovits wrote:
Where do you think to implement this FileOperation interface? I miss
the source fileobject -a s I said, I dont want to implement the
interface in the FileObject and thus thought about something like
this:
DefaultFileOperations.get().copy(FileObject src, FileObject
Hello!
void save(final OutputStream newContents, final FileObject dest) throws
FileSystemException;
void saveAndOverwrite(final OutputStream newContents, final FileObject
dest) throws FileSystemException;
How strong is your preference?
Doesnt lead such a design to have tons of saveAnd methods.
I looked over the problem again and think I'd prefer a command object
approach:
public interface OperationE extends Exception {
void execute() throws E;
}
And:
public interface IOOperation extends OperationIOException { }
(Excess abstraction, I know. I had a hard time resisting the coolness
How is this for an interface for file operations?
public interface FileOperation {
void save(final InputStream newContents)
throws FileSystemException;
void saveAndBackup(final InputStream newContents)
throws FileSystemException;
void copyTo(final FileName
Hello!
How is this for an interface for file operations?
Where do you think to implement this FileOperation interface?
I miss the source fileobject -a s I said, I dont want to implement the
interface in the FileObject and thus thought about something like this:
Hi Brian!
Sorry for the long delay. I was in an delivery period and therefore out
of time.
After the next week I should have more time again.
I am not sure we should implement a poor-man's transaction if we could
have more ([transaction] ) for free.
Hmmm, I would like to have a depper look on
For inclusion in the VFS I propose a higher-level API which wraps the
lower-level FileObject operations for ease of use in applications.
In particular, I would like to capture these principles:
* Do-or-die semantics.
* Transactional semantics.
* Completed operations.
* Instance methods.
* Easy
Damn good work!
I think we should introduce a FileUtils class, I dont want to bloat the
FileObject with utility functions.
About transactionality :- care should be taken to not reimplement
something like [transaction], they already implemented such a beast
using java.io.File. Maybe we can
Mario Ivankovits wrote:
About transactionality :- care should be taken to not reimplement
something like [transaction], they already implemented such a beast
using java.io.File. Maybe we can adopt it.
I'll have to look at it, but it looked like overkill for what I had in mind.
I've been toying
16 matches
Mail list logo
