A quick look at the future of Oddjob from a development perspective. What bits of the API might change?
A new 'destroyed' state is almost inevitable fairly soon. I can't think of another way for a trigger listener to detect network failure.
Should state be an enumeration or should it be a class hierarchy? Might we want to define flavours of complete at some stage? The possibility of having a transaction spanning several jobs might require this.
I still wonder if 'complete' and 'not complete' are the right terms for the states we've got.
The Arooa framework is pretty good. The LEAVE_PROXY flag should be replaced with a ValueType DynaClass for maps, lists and variables.
The setContext method should be changed as it's too much like a
bean method which is confusing - acceptContext(ArooaContext)
maybe?
The property replacement stategy needs a rethink as it's a bit ugly.
Should Structural, Stateful, and Iconic be replaced with a more generic notification framework like JMX with filtering? Would the upheval be worth it?
Plugging in your own classloader must become possible.
Passing properties down from on job to another as args is a pain. Maybe introduce the idea of 'exporting' a bean to a nested oddjob. You could then 'export' global variables.
Throttling support should be added to parallel
and forEach.
Sometimes job detail can be hidden from a top level view. But it would nice to zoom into the internals of a job. For this to work it will have to become possible to spawn a JMX server to handle the detail.
Spawning JMX servers has other applications as well - such as servicing clients which want to execute adhoc jobs on a server - dangerous from a security point of view though.
The ability plug in a Scheule Handler should be added.
At some point security at the JMX level will be added. I can't imagine this will cause any upheaval in the API though.
Oddjob Designer needs alot of work. The API will almost certainly change.