Announcement Announcement Module
Collapse
No announcement yet.
Removing of Step Scope? Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • #16
    If I understood you I might think about even adding a dispose() hook, even to the Job interface. What do you mean about the delegate? How can an AOP solution have access to more information than the JobFactory?

    Comment


    • #17
      What I meant was that the Job can be,for example, a SimpleJob. So its public interface has additional methods (e.g. setListeners). If you wrap it in a delegating Job, you won't be able to access these methods externally. Using AOP (with proxyTargetClass="true") you can access all methods.

      Comment


      • #18
        OK I get it. I'm not sure I would want to treat the SimpleJob as a public API, except for configuration, so I would call that an abuse of proxyTargetClass=true. But that's a personal opinion - if it works for you, knock yourself out.

        Comment


        • #19
          As I said before, I don't like the proxy solution very much.
          I would prefer to get a job holder object back from the factory. This object holds both the instantiated Job instance and a reference to the context (or a dispose method).
          That object can then be passed around to the other interfaces (e.g. JobLauncher). That means that the other interfaces would have to be aware of JobHolder instead of Job, and they can call dispose after execute is finished.

          But this is only my opinion...

          Comment


          • #20
            Not sure if this is exactly related, but...

            What if each JobExecution held an instance of ExecutionAttributes that was automatically persisted just like StepExecution's attributes? That way, stateful job-level attributes can be created by the user using a job or step listener by accessing the job execution, and will be restored if a new execution of the same job instance is created. This would allow inter-step communication, maintain the philosophy of our current paradigm of reinstating state from the database, and remove any need for a "JobContext" (i.e. a non-"won't fix" solution for half of http://jira.springframework.org/browse/BATCH-361 -- the other half [resource disposal] is already addressed by JobListener).

            Comment


            • #21
              It's not really related to the stateful/stateless discussion we were having, but that needn't stop us continuing (this thread http://forum.springframework.org/showthread.php?t=51174 might have been closer, except for the misunderstanding about the nature of a step).

              ExecutionAttributes in the JobExecution is a good idea - it was one of the approaches we were considering. When we designed the ExecutionContext framework we sort of anticipated that that might end up being stored at the job level as well.

              This feature won't make it into 1.0 now, but there will be workarounds (e.g. copying attributes between steps in a step listener).

              Comment

              Working...
              X