Now all root elements have a version, and if the realm has versioning
enabled, then actions through the ElementMap lead to new versions being
created. There are also methods to revert/undo changes to an object.
Some tests are still failing, this will be fixed later
Now instead of instantiating StrolchAgent and calling the method
setup(), instantiate StrolchBootstrapper and call one of the setup
methods which is appropriate to your use-case.
New feature is to use a StrolchBootstrap.xml to configure the
environment, root, config and data paths. Each can be defined by
environment and overridden, etc.
You can now add policies to Resources, Orders and Activities:
<Policies>
<Policy Type="PlanningPolicy" Value="key:SimplePlanningPolicy" />
<Policy Type="ExecutionPolicy"
Value="java:li.strolch.policy.execution.TestSimulatedExecutionPolicy" />
<Policy Type="ConfirmationPolicy" Value="key:NoConfirmation" />
</Policies>
And now there is a PolicyHandler to get the Policy:
<Component>
<name>PolicyHandler</name>
<api>li.strolch.policy.PolicyHandler</api>
<impl>li.strolch.policy.DefaultPolicyHandler</impl>
<Properties>
<readPolicyFile>true</readPolicyFile>
<policyConfigFile>StrolchPolicies.xml</policyConfigFile>
</Properties>
</Component>
Which has its own configuration file:
<?xml version="1.0" encoding="UTF-8"?>
<StrolchPolicies>
<PolicyType Type="PlanningPolicy"
Api="li.strolch.policytest.TestPlanningPolicy">
<Policy Key="SimplePlanningPolicy"
Class="li.strolch.policytest.TestSimplePlanningPolicy" />
</PolicyType>
<PolicyType Type="ConfirmationPolicy"
Api="li.strolch.policytest.TestConfirmationPolicy">
<Policy Key="NoConfirmation"
Class="li.strolch.policytest.TestNoConfirmationPolicy" />
</PolicyType>
</StrolchPolicies>
Some tests are still broken at this state - will fix them in the next
commit
- So sadly just auto closing a TX using try-resource from Java7 is a bad idea.
- Doing that leads to problems when an exception is thrown, then the close is called (duh) but this leads to commit being called.
- Since the Java language does not offer a decent way to detect if the close is being called in the context of an exception i was forced to add a tx.commitOnClose() and tx.rollbackOnClose().
- The default is that when a TX is opened, then the close strategy is rollback; the API user must call tx.commitOnClose() before the TX is closed by the braces, or as late as possible, to make sure that if an exception is thrown the transaction is rolled back, and not committed.
- The API was also extended with a tx.fail(msg):StrolchTransactionException so that if the implementor detects an unrecoverable error, one can write: throw tx.fail(“my reason”);
This was sadly an unavoidable late 1.0.0 change
Conflicts:
li.strolch.agent/src/main/java/li/strolch/persistence/api/AbstractTransaction.java
Robert von Burg