refactor code out of ExecuteJobThread in Command

[camunda]

What do you think about refactoring all the not Thread related code out of the ExecutoeJobThread in a own Command, which does the job.

The command can be called by the ExecuteJobThread. But the COmmand can also be used in other environments or maybe ad hoc if you need.

What do you think?

[tom.baeyens]

managing threads on the other side of a session facade is not a good thing.

if you look at the job executor as a component, you could think of commands like start-new-thread and stop-thread or set-nbr-of-thread. but still the threads would be managed by the component, not the actual command.

hmmm... this reasoning is not really (thread?)-safe :-)

probably it depends on what you want to do. but i don't see yet a use case in which you want to manage the job executor. i would think it is always a deployment kind of thing.

another aspect is that you can also turn it around. you could just use the JobExecutorThread in the command in stead of the other way round.

just thinking out loud here. i didn't really see yet where you want to take it.

[camunda]

another aspect is that you can also turn it around. you could just use the JobExecutorThread in the command in stead of the other way round.

Actually, I tried this. But it is not easy to leave out the Threading in the current implementation.

Maybe a solution would also be, to push some code for the Job-Execution in another class (or the ScheduleSession maybe?), so the JobEexecutorThread gets much easier and I can build a Command using the same code.