Spring Integration - Revision history

Carfey: /* Spring Boot */

2016-02-15T21:43:57Z

Spring Boot

← Older revision		Revision as of 21:43, 15 February 2016
Line 31:		Line 31:
	== Spring Boot ==		== Spring Boot ==

	See the [https://github.com/ajit-kulkarni/obsidian-demo Spring Boot sample project] showing how to start and stop the Obsidian scheduler automatically, courtesy or Ajit Kulkarni.		See the [https://github.com/ajit-kulkarni/obsidian-demo Spring Boot sample project] showing how to start and stop the Obsidian scheduler automatically, courtesy of Ajit Kulkarni.

	== Best Practices ==		== Best Practices ==

Carfey at 21:43, 15 February 2016

2016-02-15T21:43:44Z

← Older revision		Revision as of 21:43, 15 February 2016
Line 28:		Line 28:

	Grails services can be used with the standard Spring Integration as outlined above, but they must have the appropriate <code>@Component</code> annotation, or a subtype of that annotation.		Grails services can be used with the standard Spring Integration as outlined above, but they must have the appropriate <code>@Component</code> annotation, or a subtype of that annotation.

			== Spring Boot ==

			See the [https://github.com/ajit-kulkarni/obsidian-demo Spring Boot sample project] showing how to start and stop the Obsidian scheduler automatically, courtesy or Ajit Kulkarni.

	== Best Practices ==		== Best Practices ==

Carfey: /* Grails */

2015-10-21T21:48:35Z

Grails

← Older revision		Revision as of 21:48, 21 October 2015
Line 27:		Line 27:
	== Grails ==		== Grails ==

	Grails services ~~will~~ with standard Spring Integration as outlined above, but they must have the appropriate <code>@Component</code> annotation, or a subtype of that annotation.		Grails services can be used with the standard Spring Integration as outlined above, but they must have the appropriate <code>@Component</code> annotation, or a subtype of that annotation.

	== Best Practices ==		== Best Practices ==

Carfey at 21:47, 21 October 2015

2015-10-21T21:47:51Z

← Older revision		Revision as of 21:47, 21 October 2015
Line 24:		Line 24:

	As of '''Obsidian 2.2.1''', implementations of <code>SchedulableJob</code> found in your [http://docs.spring.io/spring/docs/2.5.6/api/org/springframework/context/ApplicationContext.html ApplicationContext] will automatically be available in the [[Admin_Jobs#Adding_.26_Editing_Jobs\|Job Admin]] screen thus avoiding needing to configure distinct [[Implementing_Jobs#Classpath_Scanning\|Classpath Scanning]]. If you're using at least Spring 3.0, your [[Implementing_Jobs#Annotation-Based_Jobs\|annotated]] jobs will also be found in the Spring <code>ApplicationContext</code>.		As of '''Obsidian 2.2.1''', implementations of <code>SchedulableJob</code> found in your [http://docs.spring.io/spring/docs/2.5.6/api/org/springframework/context/ApplicationContext.html ApplicationContext] will automatically be available in the [[Admin_Jobs#Adding_.26_Editing_Jobs\|Job Admin]] screen thus avoiding needing to configure distinct [[Implementing_Jobs#Classpath_Scanning\|Classpath Scanning]]. If you're using at least Spring 3.0, your [[Implementing_Jobs#Annotation-Based_Jobs\|annotated]] jobs will also be found in the Spring <code>ApplicationContext</code>.

			== Grails ==

			Grails services will with standard Spring Integration as outlined above, but they must have the appropriate <code>@Component</code> annotation, or a subtype of that annotation.

	== Best Practices ==		== Best Practices ==

Carfey: /* Dependency Injection via Spring */

2015-10-21T21:18:11Z

Dependency Injection via Spring

← Older revision		Revision as of 21:18, 21 October 2015
Line 11:		Line 11:
	Regardless of the method you use to configure your Spring components, Obsidian will load them directly from the container which means the actual singleton or prototype object obtained from Spring is executed by Obsidian. This makes creating jobs which use configured services very easy and convenient.		Regardless of the method you use to configure your Spring components, Obsidian will load them directly from the container which means the actual singleton or prototype object obtained from Spring is executed by Obsidian. This makes creating jobs which use configured services very easy and convenient.

	Spring will need to be configured and started in all Obsidian runtimes ~~- both scheduler nodes and any Web~~ Admin UI ~~deployments~~. Each environment will require the job classes to be wired in Spring, scheduler nodes to permit retrieval from the context for execution, admin deployments to allow retrieval from the context for configuration validation.		Spring will need to be configured and started in all Obsidian scheduler runtimes, but not standalone Admin UI web apps. Each environment will require the job classes to be wired in Spring, scheduler nodes to permit retrieval from the context for execution, admin deployments to allow retrieval from the context for configuration validation.

	To allow Obsidian to locate your application's Spring context, you will need to ensure Obsidian's [http://docs.spring.io/spring/docs/2.5.6/api/org/springframework/context/ApplicationContextAware.html ApplicationContextAware] implementation is configured by Spring. If you are using Spring's classpath scanning, you can use the following approach to add an additional package to your configuration:		To allow Obsidian to locate your application's Spring context, you will need to ensure Obsidian's [http://docs.spring.io/spring/docs/2.5.6/api/org/springframework/context/ApplicationContextAware.html ApplicationContextAware] implementation is configured by Spring. If you are using Spring's classpath scanning, you can use the following approach to add an additional package to your configuration:

Carfey: /* Best Practices */

2015-10-21T21:02:55Z

Best Practices

← Older revision		Revision as of 21:02, 21 October 2015
Line 33:		Line 33:
	* In many cases, the majority of job logic can be left in your existing Spring components.		* In many cases, the majority of job logic can be left in your existing Spring components.
	* Use Obsidian to configure parameters and store results, but leave application-level configuration in Spring.		* Use Obsidian to configure parameters and store results, but leave application-level configuration in Spring.
			* Make sure every job you want to be loaded from the Spring context has a <code>@Component</code> annotation, or a subtype of that annotation.

	== Sample Jobs ==		== Sample Jobs ==

Carfey: /* Dependency Injection via Spring */

2015-10-21T21:02:07Z

Dependency Injection via Spring

← Older revision		Revision as of 21:02, 21 October 2015
Line 7:		Line 7:
	Obsidian uses the <code>@Component</code> and any Spring or custom extensions of those annotations (such as <code>@Service</code> and <code>@Repository</code>) as a basis for knowing which job implementations should be retrieved from the Spring context. It is important to note that if a job class does not have one of these annotations, '''Obsidian will not use the container version''', and will instantiate the job directly.		Obsidian uses the <code>@Component</code> and any Spring or custom extensions of those annotations (such as <code>@Service</code> and <code>@Repository</code>) as a basis for knowing which job implementations should be retrieved from the Spring context. It is important to note that if a job class does not have one of these annotations, '''Obsidian will not use the container version''', and will instantiate the job directly.

	Job classes which can be loaded from Spring can be either <code>SchedulableJob</code> implementations or [[Implementing_Jobs#Annotation-Based_Jobs\|annotated]] jobs. Even if you are not using Spring annotations to wire your classes, you will need to add the <code>@Component</code> annotation (or a subtype) to your job classes to serve as a [http://en.wikipedia.org/wiki/Marker_interface_pattern ~~Marker~~] to Obsidian. See [[Implementing_Jobs\|Implementing Jobs]] for details on how to write and configure executable jobs.		Job classes which can be loaded from Spring can be either <code>SchedulableJob</code> implementations or [[Implementing_Jobs#Annotation-Based_Jobs\|annotated]] jobs. Even if you are not using Spring annotations to wire your classes, you will need to add the <code>@Component</code> annotation (or a subtype) to your job classes to serve as a [http://en.wikipedia.org/wiki/Marker_interface_pattern marker] to Obsidian. See [[Implementing_Jobs\|Implementing Jobs]] for details on how to write and configure executable jobs.

	Regardless of the method you use to configure your Spring components, Obsidian will load them directly from the container which means the actual singleton or prototype object obtained from Spring is executed by Obsidian. This makes creating jobs which use configured services very easy and convenient.		Regardless of the method you use to configure your Spring components, Obsidian will load them directly from the container which means the actual singleton or prototype object obtained from Spring is executed by Obsidian. This makes creating jobs which use configured services very easy and convenient.

Carfey: /* Dependency Injection via Spring */

2015-10-21T21:01:13Z

Dependency Injection via Spring

← Older revision		Revision as of 21:01, 21 October 2015
Line 7:		Line 7:
	Obsidian uses the <code>@Component</code> and any Spring or custom extensions of those annotations (such as <code>@Service</code> and <code>@Repository</code>) as a basis for knowing which job implementations should be retrieved from the Spring context. It is important to note that if a job class does not have one of these annotations, '''Obsidian will not use the container version''', and will instantiate the job directly.		Obsidian uses the <code>@Component</code> and any Spring or custom extensions of those annotations (such as <code>@Service</code> and <code>@Repository</code>) as a basis for knowing which job implementations should be retrieved from the Spring context. It is important to note that if a job class does not have one of these annotations, '''Obsidian will not use the container version''', and will instantiate the job directly.

	Job classes which can be loaded from Spring can be either <code>SchedulableJob</code> implementations or [[Implementing_Jobs#Annotation-Based_Jobs\|annotated]] jobs. Even if you are not using Spring annotations to wire your classes, you will need to add the annotation to your job classes to serve as a [http://en.wikipedia.org/wiki/Marker_interface_pattern Marker] to Obsidian. See [[Implementing_Jobs\|Implementing Jobs]] for details on how to write and configure executable jobs.		Job classes which can be loaded from Spring can be either <code>SchedulableJob</code> implementations or [[Implementing_Jobs#Annotation-Based_Jobs\|annotated]] jobs. Even if you are not using Spring annotations to wire your classes, you will need to add the <code>@Component</code> annotation (or a subtype) to your job classes to serve as a [http://en.wikipedia.org/wiki/Marker_interface_pattern Marker] to Obsidian. See [[Implementing_Jobs\|Implementing Jobs]] for details on how to write and configure executable jobs.

	Regardless of the method you use to configure your Spring components, Obsidian will load them directly from the container which means the actual singleton or prototype object obtained from Spring is executed by Obsidian. This makes creating jobs which use configured services very easy and convenient.		Regardless of the method you use to configure your Spring components, Obsidian will load them directly from the container which means the actual singleton or prototype object obtained from Spring is executed by Obsidian. This makes creating jobs which use configured services very easy and convenient.

Carfey: /* Dependency Injection via Spring */

2015-10-21T20:59:21Z

Dependency Injection via Spring

← Older revision		Revision as of 20:59, 21 October 2015
Line 5:		Line 5:
	As of Obsidian 2.2.0, Obsidian has greatly improved the integration with your Spring dependency injection container, and now supports loading job implementations from the Spring context. Obsidian does not include any Spring libraries and will defer to the version and libraries you include with your application. It supports versions of Spring from 2.5 onward.		As of Obsidian 2.2.0, Obsidian has greatly improved the integration with your Spring dependency injection container, and now supports loading job implementations from the Spring context. Obsidian does not include any Spring libraries and will defer to the version and libraries you include with your application. It supports versions of Spring from 2.5 onward.

	Obsidian uses the <code>@Component</code> and any Spring or custom extensions of those annotations (such as <code>@Service</code> and <code>@Repository</code>) as a basis for knowing which job implementations should be retrieved from the Spring context.		Obsidian uses the <code>@Component</code> and any Spring or custom extensions of those annotations (such as <code>@Service</code> and <code>@Repository</code>) as a basis for knowing which job implementations should be retrieved from the Spring context. It is important to note that if a job class does not have one of these annotations, '''Obsidian will not use the container version''', and will instantiate the job directly.

	It is important to note that if a job class does not have one of these annotations, Obsidian will ~~never~~ use the container version, and will instantiate the job directly.

	Job classes which can be loaded from Spring can be either <code>SchedulableJob</code> implementations or [[Implementing_Jobs#Annotation-Based_Jobs\|annotated]] jobs. Even if you are not using Spring annotations to wire your classes, you will need to add the annotation to your job classes to serve as a [http://en.wikipedia.org/wiki/Marker_interface_pattern Marker] to Obsidian. See [[Implementing_Jobs\|Implementing Jobs]] for details on how to write and configure executable jobs.		Job classes which can be loaded from Spring can be either <code>SchedulableJob</code> implementations or [[Implementing_Jobs#Annotation-Based_Jobs\|annotated]] jobs. Even if you are not using Spring annotations to wire your classes, you will need to add the annotation to your job classes to serve as a [http://en.wikipedia.org/wiki/Marker_interface_pattern Marker] to Obsidian. See [[Implementing_Jobs\|Implementing Jobs]] for details on how to write and configure executable jobs.

Carfey: /* Dependency Injection via Spring */

2015-10-21T20:57:17Z

Dependency Injection via Spring

← Older revision		Revision as of 20:57, 21 October 2015
Line 6:		Line 6:

	Obsidian uses the <code>@Component</code> and any Spring or custom extensions of those annotations (such as <code>@Service</code> and <code>@Repository</code>) as a basis for knowing which job implementations should be retrieved from the Spring context.		Obsidian uses the <code>@Component</code> and any Spring or custom extensions of those annotations (such as <code>@Service</code> and <code>@Repository</code>) as a basis for knowing which job implementations should be retrieved from the Spring context.

			It is important to note that if a job class does not have one of these annotations, Obsidian will never use the container version, and will instantiate the job directly.

	Job classes which can be loaded from Spring can be either <code>SchedulableJob</code> implementations or [[Implementing_Jobs#Annotation-Based_Jobs\|annotated]] jobs. Even if you are not using Spring annotations to wire your classes, you will need to add the annotation to your job classes to serve as a [http://en.wikipedia.org/wiki/Marker_interface_pattern Marker] to Obsidian. See [[Implementing_Jobs\|Implementing Jobs]] for details on how to write and configure executable jobs.		Job classes which can be loaded from Spring can be either <code>SchedulableJob</code> implementations or [[Implementing_Jobs#Annotation-Based_Jobs\|annotated]] jobs. Even if you are not using Spring annotations to wire your classes, you will need to add the annotation to your job classes to serve as a [http://en.wikipedia.org/wiki/Marker_interface_pattern Marker] to Obsidian. See [[Implementing_Jobs\|Implementing Jobs]] for details on how to write and configure executable jobs.