Job, JobParameters are not serializable?

[robert.kasanicky]

In the 1.1 trunk JobParameters are serializable and JobInstance does not have reference to Job, only jobName. So there shouldn't be any more serialization headaches in 1.1 release.

[lucasward]

I'm still not sure that you need the job to be serializable for your use case. The JobExecution and JobParameters makes sense to me, since they're generated at runtime. (To answer your other question, yes both of them are Serializable, at least in the current trunk) However, if you wanted to launch in a jvm, why not just give send the job name over, along with the JobParameters, and let the other jvm create the application context? It has to anyway since it's already going to need to get/create a datasource, etc.

[wordywordy]

Lucasward, I got your meaning and I think it is easy to send jobName and jobParameters and get our job done easily.

Why we want that is we aim at keep the contract of launcher unchanged:
1. JobExecution jobExecution = launcher.run(job, jobParameters);

We can of course write something like:
2. JobExecution jobExecution = launcherByJobName.run(jobName, jobParameters);

But it changed the contract. Anyway, I think it is not a big deal but I still want to consult Spring Batch authors on our design thoughts. If you prefer the approach 2 to 1, we can surely proceed like that.

[lucasward]

I can understand not wanting to change the contract, but in this case, I think I would. It's much preferable to leave the creation of the Job in the JVM where it will actually be run. I'm not sure how you could do it otherwise. Since a Job has steps, who have readers and writers, it would be pretty much impossible to stamp the entire thing as serializable. For example, if your writer was a DAO that took a DataSource, your DataSource would have to be serialized as well (which is of course a bad thing)

[stephenbute]

I can understand not wanting to change the contract, but in this case, I think I would. It's much preferable to leave the creation of the Job in the JVM where it will actually be run. I'm not sure how you could do it otherwise. Since a Job has steps, who have readers and writers, it would be pretty much impossible to stamp the entire thing as serializable. For example, if your writer was a DAO that took a DataSource, your DataSource would have to be serialized as well (which is of course a bad thing)

Will Spring Batch consider make another interface for this ?
Like JobRunner.run(String jobName , String[] parameters)