|
64 | 64 | * } |
65 | 65 | * </pre> |
66 | 66 | * |
67 | | - * The user should provide a {@link DataSource} as a bean in the context, or else |
68 | | - * implement {@link BatchConfigurer} in the configuration class itself, e.g. |
| 67 | + * You should provide a {@link DataSource} as a bean in the context or else implement {@link BatchConfigurer} in |
| 68 | + * the configuration class itself -- for example: |
69 | 69 | * |
70 | 70 | * <pre class="code"> |
71 | 71 | * @Configuration |
|
87 | 87 | * } |
88 | 88 | * </pre> |
89 | 89 | * |
90 | | - * If multiple {@link javax.sql.DataSource}s are defined in the context, the primary |
91 | | - * autowire candidate will be used, otherwise an exception will be thrown. |
| 90 | + * If multiple {@link javax.sql.DataSource} instances are defined in the context, the primary autowire candidate |
| 91 | + * is used. Otherwise, an exception is thrown. |
92 | 92 | * |
93 | | - * Note that only one of your configuration classes needs to have the |
94 | | - * <code>@EnableBatchProcessing</code> annotation. Once you have an |
95 | | - * <code>@EnableBatchProcessing</code> class in your configuration you will have an |
96 | | - * instance of {@link StepScope} and {@link org.springframework.batch.core.scope.JobScope} |
97 | | - * so your beans inside steps can have <code>@Scope("step")</code> and |
98 | | - * <code>@Scope("job")</code> respectively. You will also be able to |
99 | | - * <code>@Autowired</code> some useful stuff into your context: |
| 93 | + * Note that only one of your configuration classes needs to have the <code>@EnableBatchProcessing</code> |
| 94 | + * annotation. Once you have an <code>@EnableBatchProcessing</code> class in your configuration, you have an |
| 95 | + * instance of {@link StepScope} and {@link org.springframework.batch.core.scope.JobScope}, so your beans inside steps |
| 96 | + * can have <code>@Scope("step")</code> and <code>@Scope("job")</code> respectively. You can also |
| 97 | + * use <code>@Autowired</code> to insert some useful stuff into your context: |
100 | 98 | * |
101 | 99 | * <ul> |
102 | | - * <li>a {@link JobRepository} (bean name "jobRepository" of type |
103 | | - * {@link org.springframework.batch.core.repository.support.SimpleJobRepository})</li> |
104 | | - * <li>a {@link JobLauncher} (bean name "jobLauncher" of type |
105 | | - * {@link org.springframework.batch.core.launch.support.SimpleJobLauncher})</li> |
106 | | - * <li>a {@link JobRegistry} (bean name "jobRegistry" of type |
107 | | - * {@link org.springframework.batch.core.configuration.support.MapJobRegistry})</li> |
108 | | - * <li>a {@link org.springframework.batch.core.explore.JobExplorer} (bean name |
109 | | - * "jobExplorer" of type |
110 | | - * {@link org.springframework.batch.core.explore.support.SimpleJobExplorer})</li> |
111 | | - * <li>a {@link JobBuilderFactory} (bean name "jobBuilders") as a convenience to prevent |
112 | | - * you from having to inject the job repository into every job, as in the examples |
113 | | - * above</li> |
114 | | - * <li>a {@link StepBuilderFactory} (bean name "stepBuilders") as a convenience to prevent |
115 | | - * you from having to inject the job repository and transaction manager into every |
116 | | - * step</li> |
| 100 | + * <li>a {@link JobRepository} (bean name "jobRepository" of type {@link org.springframework.batch.core.repository.support.SimpleJobRepository})</li> |
| 101 | + * <li>a {@link JobLauncher} (bean name "jobLauncher" of type {@link org.springframework.batch.core.launch.support.SimpleJobLauncher})</li> |
| 102 | + * <li>a {@link JobRegistry} (bean name "jobRegistry" of type {@link org.springframework.batch.core.configuration.support.MapJobRegistry})</li> |
| 103 | + * <li>a {@link org.springframework.batch.core.explore.JobExplorer} (bean name "jobExplorer" of type {@link org.springframework.batch.core.explore.support.SimpleJobExplorer})</li> |
| 104 | + * <li>a {@link JobBuilderFactory} (bean name "jobBuilders") as a convenience to prevent you from having to inject the |
| 105 | + * job repository into every job, as in the earlier examples</li> |
| 106 | + * <li>a {@link StepBuilderFactory} (bean name "stepBuilders") as a convenience to prevent you from having to inject the |
| 107 | + * job repository and transaction manager into every step</li> |
117 | 108 | * </ul> |
118 | 109 | * |
119 | | - * The transaction manager provided by this annotation will be of type |
120 | | - * {@link org.springframework.jdbc.datasource.DataSourceTransactionManager} configured |
121 | | - * with the {@link javax.sql.DataSource} provided within the context. |
| 110 | + * The transaction manager provided by this annotation is of type {@link org.springframework.jdbc.datasource.DataSourceTransactionManager} |
| 111 | + * and is configured with the {@link javax.sql.DataSource} provided within the context. |
122 | 112 | * |
123 | | - * In order to use a custom transaction manager, a custom {@link BatchConfigurer} should |
124 | | - * be provided. For example: |
| 113 | + * To use a custom transaction manager, you should provide a custom {@link BatchConfigurer} -- for example: |
125 | 114 | * |
126 | 115 | * <pre class="code"> |
127 | 116 | * @Configuration |
|
143 | 132 | * } |
144 | 133 | * </pre> |
145 | 134 | * |
146 | | - * If the configuration is specified as <code>modular=true</code> then the context will |
147 | | - * also contain an {@link AutomaticJobRegistrar}. The job registrar is useful for |
148 | | - * modularizing your configuration if there are multiple jobs. It works by creating |
149 | | - * separate child application contexts containing job configurations and registering those |
150 | | - * jobs. The jobs can then create steps and other dependent components without needing to |
151 | | - * worry about bean definition name clashes. Beans of type |
152 | | - * {@link ApplicationContextFactory} will be registered automatically with the job |
| 135 | + * If the configuration is specified as <code>modular=true</code>, the context also contains an |
| 136 | + * {@link AutomaticJobRegistrar}. The job registrar is useful for modularizing your configuration if there are multiple |
| 137 | + * jobs. It works by creating separate child application contexts to contain job configurations and register those |
| 138 | + * jobs. The jobs can then create steps and other dependent components without needing to worry about bean definition |
| 139 | + * name clashes. Beans of type {@link ApplicationContextFactory} are automatically registered with the job |
153 | 140 | * registrar. Example: |
154 | 141 | * |
155 | 142 | * <pre class="code"> |
|
172 | 159 | * } |
173 | 160 | * </pre> |
174 | 161 | * |
175 | | - * Note that a modular parent context in general should <em>not</em> itself contain |
176 | | - * @Bean definitions for job, especially if a {@link BatchConfigurer} is provided, |
177 | | - * because cyclic configuration dependencies are otherwise likely to develop. |
| 162 | + * Note that a modular parent context, in general, should <em>not</em> itself contain @Bean definitions for job, |
| 163 | + * especially if a {@link BatchConfigurer} is provided, because cyclic configuration dependencies are likely |
| 164 | + * to develop. |
178 | 165 | * |
179 | 166 | * <p> |
180 | | - * For reference, the first example above can be compared to the following Spring XML |
181 | | - * configuration: |
| 167 | + * For reference, compare the first example shown earlier to the following Spring XML configuration: |
182 | 168 | * |
183 | 169 | * <pre class="code"> |
184 | 170 | * {@code |
|
208 | 194 | public @interface EnableBatchProcessing { |
209 | 195 |
|
210 | 196 | /** |
211 | | - * Indicate whether the configuration is going to be modularized into multiple |
212 | | - * application contexts. If true then you should not create any @Bean Job |
213 | | - * definitions in this context, but rather supply them in separate (child) contexts |
214 | | - * through an {@link ApplicationContextFactory}. |
215 | | - * @return boolean indicating whether the configuration is going to be modularized |
216 | | - * into multiple application contexts. Defaults to false. |
| 197 | + * Indicate whether the configuration is going to be modularized into multiple application contexts. If true, |
| 198 | + * you should not create any @Bean Job definitions in this context but, rather, supply them in separate (child) |
| 199 | + * contexts through an {@link ApplicationContextFactory}. |
| 200 | + * |
| 201 | + * @return boolean indicating whether the configuration is going to be |
| 202 | + * modularized into multiple application contexts. Defaults to {@code false}. |
217 | 203 | */ |
218 | 204 | boolean modular() default false; |
219 | 205 |
|
|
0 commit comments