Table of Contents

Skip to end of metadata
Go to start of metadata

Version 1.5.0 Releasedate: 2017 Sep. 5

Commit Info

The main focus of the 1.5.0 release is the enhancing of the interfaces Command and ChainCommand. The semantics wasn't clear at all. Especially the executeAsChain() methods returns a boolean and it is hard to understand in which situations true or false will be returned. 

The following issues are resolved:

SCF-15: Change the execute and executeAsChain Method to a Transition Enumeration

Problem regarding execute():

The execute(T parameterObject) method returns void. So actually you've to throw an exception if something goes wrong. Best practice is to implement the whole business logic into this method, for other purpose (chaining, process handling) as well. Regarding chaining you had to throw an "everything" is OK exception, which makes no sense.

New behavior:

There is a new method called executeCommand(T parameterObject). It returns an CommandTransition enumeration. The execute method should return:

  • SUCCESS, if everything was fine during execution.
  • FAILURE, if there was an error.

The old execute(T parameterObject) method is still there but marked as deprecated.

Problem regarding executeAsChain()

The executeAsChaint(T parameterObject) returns boolean. Thats not a good approach. A chain should be either aborted (if the whole work is done) or succeeded which mean the next command should overtake.

New behavior:

There ist a new method called executeCommandAsChain(T parameterObject) which returns an CommandTransition enumeration as well. This method should return:

  • SUCCESS, if the next chain should be overtake
  • DONE, otherwise, the chain should be stopped because work is done.

The old executeAsChain(T parameterObject) method is still there but marked as deprecated. It will be removed in the 2.0 version of the framework.

SCF-16: Make buildChain() protected

The method is public so you can call it. But it makes no sense because the different execute-methods calls buildChain() before the execution. So a better approach is to make it protected. For this the method was removed in the ChainBuilder interface. The interface is still there as a marker interface and will maybe removed in the 1.6.0 version.

Other solved issues:

SCF-2: Reorganisation of unit tests
SCF-5: Remove sonar issues
SCF-7: Remove non-javadoc issues in comments
SCF-8: Reorganize package structure in test (remove the commons package)
SCF-10/SCF-11/SCF-12/SCF-13/SCF-14: Providing a "learning by example" documentation for a better understanding
SCF-15: Provide a default Implementation for AbstractDefaultProcessCommand.executeAsChain()

 

 

Version 1.5.1 Releasedate: 2017 Sept. 22

 

commit 782e0182a0f49fcb0c2ac3f126beecce3c1c315a
Author: Manfred Wolff <wolff@manfred-wolff.de>
Date:   Fri Sep 22 08:15:14 2017 +0200

SCF-22: Introduce an AbstractDefaultCommand to avoid implementing legacy methods

Because the old legacy methods (execute() and executeAsChain()) are part of the framework til 1.7.0 you've to implement them. The AbstractDefaultCommand provided an default implementation of this method. So actually you should work with the defaults named:

  • AbstractDefaultCommand for simple execution.
  • AbstractDefaultChainCommand for the chain of responsibility approach
  • AbstractProcessCommand for the process behavior.

 

Version 2.0.0 planed 2017 Dec.

 

branch: develop

 

The current release candidate is on development branch. Planed release date is end of the year. Feel free to test the candidates.

Release CandidateDownload Link
2.0.0-RC1 

 

The following issues are resolved:

SCF-18 Remove the ChainBuilder interface in 1.6.0

After buildChain() was marked protected (SCD-16) the ChainBuilder interface was a pure marker interface. So it was removed in this version.

SCF-19: Provide a factory method for a GenericParameterObject

It is best practice to work with factory methods (never create objects with the new operator).

SCF-23: Change CommandTransition.SUCCESS TO NEXT

Actually we introduced new states for the transition object:

CommandTransion valuemeaning
SUCCESSReturn value of the executeCommand method. If everything worked fine this value should been returned.
FAILUREReturn value of the executeCommand method. If the command fails, this value should been returned.
NEXTReturn value of the executeCommandAsChain method. If the next command should overtake, this value should be returned.
DONEReturn value of the executeCommandAsChain method. If the work of the whole chain is done, this value should be returned

The AbstractDefaultChain command does a mapping of these commands in the default implementation.

If you use this default implementation you only have to implement the executeCommand method in chain commands as well.

All other issues of this release are documentation issues like the best practice documentation.

SCF-24: Remove deprecated methods: executeCommand and executeCommandAsChain

It was still confusing having two methods with almost same semantic but different behavior. For that we decided to delete all deprecations in 1.6.0.

SCF-31: Use standard jax parser to parse xml structure

The implementation of the XMLChainBuilder was bad. So we changed it to a standard approach using standard java sax parser. Actually we "ate our own dogfood" in this new implementation using commands to fulfill the job.

SCF-34 Migrate JUnit to JUnit 5

All tests are migrated to Junit5. Because of missing PIT support for Junit5 actually no PIT test runs.

 

  • No labels