You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Santiago Basulto (JIRA)" <ji...@apache.org> on 2010/09/06 18:48:33 UTC
[jira] Created: (CHAIN-51) New Features for the project.
New Features for the project.
-----------------------------
Key: CHAIN-51
URL: https://issues.apache.org/jira/browse/CHAIN-51
Project: Commons Chain
Issue Type: New Feature
Reporter: Santiago Basulto
I'm proposing a change to the project. Did not know how to do it, so asked in the mailing list and told me to make the proposal here.
I'll comment a little about my changes. It needs a lot of refactoring and documenting, but i'd like to comment the main idea behind it, so you can give your opinion. I have faced some problems with names. I did not want to rename commons.chain classes, as a matter of respect, so some names can seem weird, it can change.
First of all, i needed more "control" over my commands. I like to have everything logged, and several commands were used in GUI apps, so i needed more User interaction. Then, i decide to provide the main Interface (Command) some other methods, just to can track what is it doing. I made a new interface called Action (i use the other name given to this pattern). I extend it from Command, just becouse i didn't want to change everything, and can keep using my old Commands.
This new Interface, Action, has two new methods:
void registerHandler(ActionHandler c);
boolean removeHandler(ActionHandler c); //true if the handler was present, false otherwise
The main idea behind this was to have a Handler object that can track the "moves and states" of the Action (or Command) class. It's something similar to the Observer Pattern. An action "can" (optionally, if doesn't want to register a handler, it's a simple Command) register a Handler, and comunicate things about itself. So, i have an Interface called ActionHandler. It has three methods:
void start(Action a);
void done(Action a);
void fail(Action a,Exception e);
Then, for example, the action "can" invoke start method from its handler, to comunicate it that has started executing. It's really simple, but helped me big time.
Something great about the Action Interface, is that it only sais that you can register a handler, not the number of handlers. So, a Class implementing Action can register a number of handlers (file logger handler, GUI tool for comunicating the user, console logger, etc) and inform about the progress to all of them. If it's not needed to comunicate, this class can just execute silently.
So, this is the main change, but with this little change i needed to do something with the chain. So i just made the Chain interface extend the Action interface. Of course, can be another class, something like ActionChain that implements the Action Interface, and let Chain untouched.
I've attached a simpler version of my source code. With just the basic classes and a package for test it. I've developed some other classes, for example, Action implementations that register several ActionHandlers. I'm currently working on a "BlockingQueueChain", it's a chain that can execute all its Commands (or Actions) in parallel. Obviusly, there are not so many cases when this Chain can be used. If someone is interested i will can send the source code.
Ok, i think that's all. Hope you can tell me if this is a good idea, or not. Or simply, whether i should start a new "branch" of the project to no interfere with Commons Chain.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CHAIN-51) New Features for the project.
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHAIN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12909828#action_12909828 ]
Phil Steitz commented on CHAIN-51:
----------------------------------
I volunteer to help get patches applied. I may be a little slow and am of course happy to let others join in; but I am willing to help with this.
> New Features for the project.
> -----------------------------
>
> Key: CHAIN-51
> URL: https://issues.apache.org/jira/browse/CHAIN-51
> Project: Commons Chain
> Issue Type: New Feature
> Reporter: Santiago Basulto
> Attachments: actions-src.rar, CHAIN-51-Alternative-Listener-proposal.patch
>
> Original Estimate: 240h
> Remaining Estimate: 240h
>
> I'm proposing a change to the project. Did not know how to do it, so asked in the mailing list and told me to make the proposal here.
> I'll comment a little about my changes. It needs a lot of refactoring and documenting, but i'd like to comment the main idea behind it, so you can give your opinion. I have faced some problems with names. I did not want to rename commons.chain classes, as a matter of respect, so some names can seem weird, it can change.
> First of all, i needed more "control" over my commands. I like to have everything logged, and several commands were used in GUI apps, so i needed more User interaction. Then, i decide to provide the main Interface (Command) some other methods, just to can track what is it doing. I made a new interface called Action (i use the other name given to this pattern). I extend it from Command, just becouse i didn't want to change everything, and can keep using my old Commands.
> This new Interface, Action, has two new methods:
> void registerHandler(ActionHandler c);
> boolean removeHandler(ActionHandler c); //true if the handler was present, false otherwise
> The main idea behind this was to have a Handler object that can track the "moves and states" of the Action (or Command) class. It's something similar to the Observer Pattern. An action "can" (optionally, if doesn't want to register a handler, it's a simple Command) register a Handler, and comunicate things about itself. So, i have an Interface called ActionHandler. It has three methods:
>
> void start(Action a);
> void done(Action a);
> void fail(Action a,Exception e);
> Then, for example, the action "can" invoke start method from its handler, to comunicate it that has started executing. It's really simple, but helped me big time.
> Something great about the Action Interface, is that it only sais that you can register a handler, not the number of handlers. So, a Class implementing Action can register a number of handlers (file logger handler, GUI tool for comunicating the user, console logger, etc) and inform about the progress to all of them. If it's not needed to comunicate, this class can just execute silently.
> So, this is the main change, but with this little change i needed to do something with the chain. So i just made the Chain interface extend the Action interface. Of course, can be another class, something like ActionChain that implements the Action Interface, and let Chain untouched.
> I've attached a simpler version of my source code. With just the basic classes and a package for test it. I've developed some other classes, for example, Action implementations that register several ActionHandlers. I'm currently working on a "BlockingQueueChain", it's a chain that can execute all its Commands (or Actions) in parallel. Obviusly, there are not so many cases when this Chain can be used. If someone is interested i will can send the source code.
> Ok, i think that's all. Hope you can tell me if this is a good idea, or not. Or simply, whether i should start a new "branch" of the project to no interfere with Commons Chain.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CHAIN-51) New Features for the project.
Posted by "Santiago Basulto (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHAIN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12909896#action_12909896 ]
Santiago Basulto commented on CHAIN-51:
---------------------------------------
First of all. Thank you for helping with this. After that, i would like to say sorry for all my ignorance.
Niall: Thanks very much for your interest. I'll make some comments to what you posted before.
About the Patch, name changing, ASF license and test, i'm already working on this. But i'm new on this stuff, so it will take some time. I add that package names becouse didn't want to people get confused with the actual Chain (commited) code. About the tests, i'm reading about JUnit (never used it before!).
JDK: OK! perfectly reasonable! and good observation by the way.
Handlers (PaneHandler and StreamHandler): I just added those two becouse wanted to show what i was thinking. May be deleted.
Java Listeners: Sincerely, i'd like to keep things as simple as it can be. Obviously, if it can fit standars, that is great! So, if you think it's better to keep in mind the Java Listeners, we can change it. The main idea of the new feature was to change it a little bit to address the "control" needs, so the way it's done can change. (What do you think Phil????)
About the rest of your comment: Didn't understand entirely!!!!! Do you have a GMail account so we can discuss it through chat? In my profile is published my email.
Phil:
Thanks, Thanks, Thanks for your support. Invaluable!
> New Features for the project.
> -----------------------------
>
> Key: CHAIN-51
> URL: https://issues.apache.org/jira/browse/CHAIN-51
> Project: Commons Chain
> Issue Type: New Feature
> Reporter: Santiago Basulto
> Attachments: actions-src.rar, CHAIN-51-Alternative-Listener-proposal.patch
>
> Original Estimate: 240h
> Remaining Estimate: 240h
>
> I'm proposing a change to the project. Did not know how to do it, so asked in the mailing list and told me to make the proposal here.
> I'll comment a little about my changes. It needs a lot of refactoring and documenting, but i'd like to comment the main idea behind it, so you can give your opinion. I have faced some problems with names. I did not want to rename commons.chain classes, as a matter of respect, so some names can seem weird, it can change.
> First of all, i needed more "control" over my commands. I like to have everything logged, and several commands were used in GUI apps, so i needed more User interaction. Then, i decide to provide the main Interface (Command) some other methods, just to can track what is it doing. I made a new interface called Action (i use the other name given to this pattern). I extend it from Command, just becouse i didn't want to change everything, and can keep using my old Commands.
> This new Interface, Action, has two new methods:
> void registerHandler(ActionHandler c);
> boolean removeHandler(ActionHandler c); //true if the handler was present, false otherwise
> The main idea behind this was to have a Handler object that can track the "moves and states" of the Action (or Command) class. It's something similar to the Observer Pattern. An action "can" (optionally, if doesn't want to register a handler, it's a simple Command) register a Handler, and comunicate things about itself. So, i have an Interface called ActionHandler. It has three methods:
>
> void start(Action a);
> void done(Action a);
> void fail(Action a,Exception e);
> Then, for example, the action "can" invoke start method from its handler, to comunicate it that has started executing. It's really simple, but helped me big time.
> Something great about the Action Interface, is that it only sais that you can register a handler, not the number of handlers. So, a Class implementing Action can register a number of handlers (file logger handler, GUI tool for comunicating the user, console logger, etc) and inform about the progress to all of them. If it's not needed to comunicate, this class can just execute silently.
> So, this is the main change, but with this little change i needed to do something with the chain. So i just made the Chain interface extend the Action interface. Of course, can be another class, something like ActionChain that implements the Action Interface, and let Chain untouched.
> I've attached a simpler version of my source code. With just the basic classes and a package for test it. I've developed some other classes, for example, Action implementations that register several ActionHandlers. I'm currently working on a "BlockingQueueChain", it's a chain that can execute all its Commands (or Actions) in parallel. Obviusly, there are not so many cases when this Chain can be used. If someone is interested i will can send the source code.
> Ok, i think that's all. Hope you can tell me if this is a good idea, or not. Or simply, whether i should start a new "branch" of the project to no interfere with Commons Chain.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CHAIN-51) New Features for the project.
Posted by "Santiago Basulto (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHAIN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Santiago Basulto updated CHAIN-51:
----------------------------------
Attachment: actions-src.rar
This is the source code for the new ideas exposed.
> New Features for the project.
> -----------------------------
>
> Key: CHAIN-51
> URL: https://issues.apache.org/jira/browse/CHAIN-51
> Project: Commons Chain
> Issue Type: New Feature
> Reporter: Santiago Basulto
> Attachments: actions-src.rar
>
> Original Estimate: 240h
> Remaining Estimate: 240h
>
> I'm proposing a change to the project. Did not know how to do it, so asked in the mailing list and told me to make the proposal here.
> I'll comment a little about my changes. It needs a lot of refactoring and documenting, but i'd like to comment the main idea behind it, so you can give your opinion. I have faced some problems with names. I did not want to rename commons.chain classes, as a matter of respect, so some names can seem weird, it can change.
> First of all, i needed more "control" over my commands. I like to have everything logged, and several commands were used in GUI apps, so i needed more User interaction. Then, i decide to provide the main Interface (Command) some other methods, just to can track what is it doing. I made a new interface called Action (i use the other name given to this pattern). I extend it from Command, just becouse i didn't want to change everything, and can keep using my old Commands.
> This new Interface, Action, has two new methods:
> void registerHandler(ActionHandler c);
> boolean removeHandler(ActionHandler c); //true if the handler was present, false otherwise
> The main idea behind this was to have a Handler object that can track the "moves and states" of the Action (or Command) class. It's something similar to the Observer Pattern. An action "can" (optionally, if doesn't want to register a handler, it's a simple Command) register a Handler, and comunicate things about itself. So, i have an Interface called ActionHandler. It has three methods:
>
> void start(Action a);
> void done(Action a);
> void fail(Action a,Exception e);
> Then, for example, the action "can" invoke start method from its handler, to comunicate it that has started executing. It's really simple, but helped me big time.
> Something great about the Action Interface, is that it only sais that you can register a handler, not the number of handlers. So, a Class implementing Action can register a number of handlers (file logger handler, GUI tool for comunicating the user, console logger, etc) and inform about the progress to all of them. If it's not needed to comunicate, this class can just execute silently.
> So, this is the main change, but with this little change i needed to do something with the chain. So i just made the Chain interface extend the Action interface. Of course, can be another class, something like ActionChain that implements the Action Interface, and let Chain untouched.
> I've attached a simpler version of my source code. With just the basic classes and a package for test it. I've developed some other classes, for example, Action implementations that register several ActionHandlers. I'm currently working on a "BlockingQueueChain", it's a chain that can execute all its Commands (or Actions) in parallel. Obviusly, there are not so many cases when this Chain can be used. If someone is interested i will can send the source code.
> Ok, i think that's all. Hope you can tell me if this is a good idea, or not. Or simply, whether i should start a new "branch" of the project to no interfere with Commons Chain.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CHAIN-51) New Features for the project.
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHAIN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12907065#action_12907065 ]
Phil Steitz commented on CHAIN-51:
----------------------------------
This looks like an interesting enhancement to Commons Chain. The setup looks reasonable. We can talk about the names and even the structure, but for now I would like to start playing with the setup as you have described it. So that we can all work with your proposed extension, we need to take what you have proposed in the rar attachment above and turn it into a patch against the trunk version of chain. Don't hesitate to ask on commons-dev if you need help getting the Commons Chain build to work or creating a patch including your proposed enhancements. (See http://commons.apache.org/patches.html for general info). A couple of quick comments:
1. As you point out, we want existing chains to work the same as they do now.
2. Chain is currently very easy to learn and use, another feature we want to keep. Good documentation and minimal complexity in the new APIs (looks pretty good as you have it, but think carefully about this) are what is needed here.
3. Make sure everything builds and is tested as part of the main chain build
4. Make sure to include ASF license headers with each new file
If you don't mind, it would also be a good thing to submit a contributor license agreement (http://www.apache.org/licenses/icla.txt - scan and email to the address in the form).
Welcome to Commons!
> New Features for the project.
> -----------------------------
>
> Key: CHAIN-51
> URL: https://issues.apache.org/jira/browse/CHAIN-51
> Project: Commons Chain
> Issue Type: New Feature
> Reporter: Santiago Basulto
> Attachments: actions-src.rar
>
> Original Estimate: 240h
> Remaining Estimate: 240h
>
> I'm proposing a change to the project. Did not know how to do it, so asked in the mailing list and told me to make the proposal here.
> I'll comment a little about my changes. It needs a lot of refactoring and documenting, but i'd like to comment the main idea behind it, so you can give your opinion. I have faced some problems with names. I did not want to rename commons.chain classes, as a matter of respect, so some names can seem weird, it can change.
> First of all, i needed more "control" over my commands. I like to have everything logged, and several commands were used in GUI apps, so i needed more User interaction. Then, i decide to provide the main Interface (Command) some other methods, just to can track what is it doing. I made a new interface called Action (i use the other name given to this pattern). I extend it from Command, just becouse i didn't want to change everything, and can keep using my old Commands.
> This new Interface, Action, has two new methods:
> void registerHandler(ActionHandler c);
> boolean removeHandler(ActionHandler c); //true if the handler was present, false otherwise
> The main idea behind this was to have a Handler object that can track the "moves and states" of the Action (or Command) class. It's something similar to the Observer Pattern. An action "can" (optionally, if doesn't want to register a handler, it's a simple Command) register a Handler, and comunicate things about itself. So, i have an Interface called ActionHandler. It has three methods:
>
> void start(Action a);
> void done(Action a);
> void fail(Action a,Exception e);
> Then, for example, the action "can" invoke start method from its handler, to comunicate it that has started executing. It's really simple, but helped me big time.
> Something great about the Action Interface, is that it only sais that you can register a handler, not the number of handlers. So, a Class implementing Action can register a number of handlers (file logger handler, GUI tool for comunicating the user, console logger, etc) and inform about the progress to all of them. If it's not needed to comunicate, this class can just execute silently.
> So, this is the main change, but with this little change i needed to do something with the chain. So i just made the Chain interface extend the Action interface. Of course, can be another class, something like ActionChain that implements the Action Interface, and let Chain untouched.
> I've attached a simpler version of my source code. With just the basic classes and a package for test it. I've developed some other classes, for example, Action implementations that register several ActionHandlers. I'm currently working on a "BlockingQueueChain", it's a chain that can execute all its Commands (or Actions) in parallel. Obviusly, there are not so many cases when this Chain can be used. If someone is interested i will can send the source code.
> Ok, i think that's all. Hope you can tell me if this is a good idea, or not. Or simply, whether i should start a new "branch" of the project to no interfere with Commons Chain.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CHAIN-51) New Features for the project.
Posted by "Niall Pemberton (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHAIN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Niall Pemberton updated CHAIN-51:
---------------------------------
Attachment: CHAIN-51-Alternative-Listener-proposal.patch
I have some comments about your suggestions - but before that Commons Chain is pretty dormant - I did the last bugfix release back in May 2008, but Chain hasn't had any real development since at least 2006. It would probably be a good idea to try to find a committer willing to commit your work, before putting any more effort on this - otherwise you may be wasting your time. Having said that, here are my comments.
There is some general work needed to your contribution before it would be ready to commit. If you fixed them and re-submitted, then it would reduce the work needed to be done by a committer and probably increase the chances that it would be accepted:
* Create a patch (rather than rar file) - see http://commons.apache.org/patches.html
* Change the package names from your "ar.com.santiagobasulto" to "org.apache.commons.chain"
* Add the ASF license headers to your source files: http://www.apache.org/legal/src-headers.html
* The tests are currently mixed in with the rest of the source code - move them to follow the commons chain directory structure (tests are in "src/test/java") and make them JUnit tests like the rest of Chain's tests
In its current form your contribution requires a minimum of JDK 1.6 and Commons Chain is currently supporting a minimum of JDK 1.3. Changing the minimum JDK version is probably not going to be an issue - but the only thing in your work that requires JDK 1.6 rather than JDK 1.5 is the use of @Override markers for implementations of interfaces (which JDK 1.5 doesn't allow). I think JDK 1.5 would be a good minimum version and removing @Override for interface implementations would not be a great loss.
I have some comments about the implementation in general - apologies, they are probably disorganized and some may contradict others(!) - but here goes:
* I would drop the PaneHandler and StreamHandler implementations - I think those implementations are too specific for a Commons component and don't add enough value to be included
* I don't like the way the new Action interface extends the existing Command interface - which then requires a new ActionChain interface to provide the Chain equivalent. IMO it would be better to have this as a completely separate interface that any Command or Chain could implement. To make that workable requires adding a "get" method for the handler/listeners
* I think it would be better to use the java's "listener" concept
* rename Action to CommandHandler and
* rename ActionHandler to CommandListener and extend the EventListener marker interface
* Create a CommandEvent object that extends EventObject and is used as a parameter to the listener methods
* Remove the "fail" method from the listener and add "Exception" as a property of CommandEvent. The "done" method then gets called whether the execution is successful or throws an exception.
* We could then modify the existing ChainBase to implement CommandHandler and call listeners for itself and for the Commands it executes. This way anything using ChainBase would get this automatically built in
{code}
public interface CommandHandler {
void addListener(CommandListener c);
boolean removeListener(CommandListener c);
Iterable<CommandListener> getListeners();
}
{code}
{code}
public interface CommandListener extends EventListener {
void start(CommandEvent event);
void finish(CommandEvent event);
}
{code}
{code}
public class CommandEvent extends EventObject {
private final Context context;
private final Exception exception;
public CommandEvent(Command command, Context context, Exception exception) {
super(command);
this.context = context;
this.exception = exception;
}
public Context getContext() {
return context;
}
public Exception getException() {
return exception;
}
}
{code}
> New Features for the project.
> -----------------------------
>
> Key: CHAIN-51
> URL: https://issues.apache.org/jira/browse/CHAIN-51
> Project: Commons Chain
> Issue Type: New Feature
> Reporter: Santiago Basulto
> Attachments: actions-src.rar, CHAIN-51-Alternative-Listener-proposal.patch
>
> Original Estimate: 240h
> Remaining Estimate: 240h
>
> I'm proposing a change to the project. Did not know how to do it, so asked in the mailing list and told me to make the proposal here.
> I'll comment a little about my changes. It needs a lot of refactoring and documenting, but i'd like to comment the main idea behind it, so you can give your opinion. I have faced some problems with names. I did not want to rename commons.chain classes, as a matter of respect, so some names can seem weird, it can change.
> First of all, i needed more "control" over my commands. I like to have everything logged, and several commands were used in GUI apps, so i needed more User interaction. Then, i decide to provide the main Interface (Command) some other methods, just to can track what is it doing. I made a new interface called Action (i use the other name given to this pattern). I extend it from Command, just becouse i didn't want to change everything, and can keep using my old Commands.
> This new Interface, Action, has two new methods:
> void registerHandler(ActionHandler c);
> boolean removeHandler(ActionHandler c); //true if the handler was present, false otherwise
> The main idea behind this was to have a Handler object that can track the "moves and states" of the Action (or Command) class. It's something similar to the Observer Pattern. An action "can" (optionally, if doesn't want to register a handler, it's a simple Command) register a Handler, and comunicate things about itself. So, i have an Interface called ActionHandler. It has three methods:
>
> void start(Action a);
> void done(Action a);
> void fail(Action a,Exception e);
> Then, for example, the action "can" invoke start method from its handler, to comunicate it that has started executing. It's really simple, but helped me big time.
> Something great about the Action Interface, is that it only sais that you can register a handler, not the number of handlers. So, a Class implementing Action can register a number of handlers (file logger handler, GUI tool for comunicating the user, console logger, etc) and inform about the progress to all of them. If it's not needed to comunicate, this class can just execute silently.
> So, this is the main change, but with this little change i needed to do something with the chain. So i just made the Chain interface extend the Action interface. Of course, can be another class, something like ActionChain that implements the Action Interface, and let Chain untouched.
> I've attached a simpler version of my source code. With just the basic classes and a package for test it. I've developed some other classes, for example, Action implementations that register several ActionHandlers. I'm currently working on a "BlockingQueueChain", it's a chain that can execute all its Commands (or Actions) in parallel. Obviusly, there are not so many cases when this Chain can be used. If someone is interested i will can send the source code.
> Ok, i think that's all. Hope you can tell me if this is a good idea, or not. Or simply, whether i should start a new "branch" of the project to no interfere with Commons Chain.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CHAIN-51) New Features for the project.
Posted by "Phil Steitz (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CHAIN-51?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12917270#action_12917270 ]
Phil Steitz commented on CHAIN-51:
----------------------------------
Sorry it has taken me a while to get back to this. I concur with Niall's suggestions. Santiago - does Niall's patch provide a workable framework for you?
> New Features for the project.
> -----------------------------
>
> Key: CHAIN-51
> URL: https://issues.apache.org/jira/browse/CHAIN-51
> Project: Commons Chain
> Issue Type: New Feature
> Reporter: Santiago Basulto
> Attachments: actions-src.rar, CHAIN-51-Alternative-Listener-proposal.patch
>
> Original Estimate: 240h
> Remaining Estimate: 240h
>
> I'm proposing a change to the project. Did not know how to do it, so asked in the mailing list and told me to make the proposal here.
> I'll comment a little about my changes. It needs a lot of refactoring and documenting, but i'd like to comment the main idea behind it, so you can give your opinion. I have faced some problems with names. I did not want to rename commons.chain classes, as a matter of respect, so some names can seem weird, it can change.
> First of all, i needed more "control" over my commands. I like to have everything logged, and several commands were used in GUI apps, so i needed more User interaction. Then, i decide to provide the main Interface (Command) some other methods, just to can track what is it doing. I made a new interface called Action (i use the other name given to this pattern). I extend it from Command, just becouse i didn't want to change everything, and can keep using my old Commands.
> This new Interface, Action, has two new methods:
> void registerHandler(ActionHandler c);
> boolean removeHandler(ActionHandler c); //true if the handler was present, false otherwise
> The main idea behind this was to have a Handler object that can track the "moves and states" of the Action (or Command) class. It's something similar to the Observer Pattern. An action "can" (optionally, if doesn't want to register a handler, it's a simple Command) register a Handler, and comunicate things about itself. So, i have an Interface called ActionHandler. It has three methods:
>
> void start(Action a);
> void done(Action a);
> void fail(Action a,Exception e);
> Then, for example, the action "can" invoke start method from its handler, to comunicate it that has started executing. It's really simple, but helped me big time.
> Something great about the Action Interface, is that it only sais that you can register a handler, not the number of handlers. So, a Class implementing Action can register a number of handlers (file logger handler, GUI tool for comunicating the user, console logger, etc) and inform about the progress to all of them. If it's not needed to comunicate, this class can just execute silently.
> So, this is the main change, but with this little change i needed to do something with the chain. So i just made the Chain interface extend the Action interface. Of course, can be another class, something like ActionChain that implements the Action Interface, and let Chain untouched.
> I've attached a simpler version of my source code. With just the basic classes and a package for test it. I've developed some other classes, for example, Action implementations that register several ActionHandlers. I'm currently working on a "BlockingQueueChain", it's a chain that can execute all its Commands (or Actions) in parallel. Obviusly, there are not so many cases when this Chain can be used. If someone is interested i will can send the source code.
> Ok, i think that's all. Hope you can tell me if this is a good idea, or not. Or simply, whether i should start a new "branch" of the project to no interfere with Commons Chain.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.