How services work - Revision history

Matt: Reverted edits by Amesycyxa (Talk); changed back to last version by Jochen

2010-11-26T19:43:48Z

Reverted edits by Amesycyxa (Talk); changed back to last version by Jochen

Amesycyxa at 03:40, 18 November 2010

2010-11-18T03:40:05Z

Jochen at 22:00, 3 June 2008

2008-06-03T22:00:49Z

Jochen: /* Why services */

2008-06-03T21:48:52Z

‎Why services

Jochen: New page: ==Why services== The first version of Designer (and also the rest of Rifidi) was littered with a lot of Singletons.
As everybody knows by now: * Singletons are bad. * They are hard t...

2008-06-03T21:48:26Z

New page: ==Why services== The first version of Designer (and also the rest of Rifidi) was littered with a lot of Singletons. As everybody knows by now: * Singletons are bad. * They are hard t...

New page

==Why services==
The first version of Designer (and also the rest of Rifidi) was littered with a lot of Singletons. 
As everybody knows by now:
* Singletons are bad.
* They are hard to test.
* Impossible (almost) to mock
So I replaced them with a little service registry where you register a concrete class with an interface this class implements. 
Once again I had to discover that somebody else had already had that idea some time ago. 
OSGi is an SOA (bright me, reading about OSGi all the time without actually realizing what it means). 
So I am using now the OSGi ServiceRegistry to deal with services. 
You, as an aspiring rifidi developer, won't need to worry about that. 
To make it easier to use the services I wrote a ServiceLocater that does all the work for you. 
The only thing to remember is to use the @Inject annotation and do the following call. 
ServiceRegister.getInstance().service(this)

@@ Line 1: / Line 1: @@
->==Why services==
+==Why services==
-The first version of Designer (and also the rest of Rifidi) was littered with a lot of Singletons.&lt;br/&gt;
+The first version of Designer (and also the rest of Rifidi) was littered with a lot of Singletons.<br/>
 As everybody knows by now:
 * Singletons are bad.
 * They are hard to test.
 * Impossible (almost) to mock
-So I replaced them with a little service registry where you register a concrete class with an interface this class implements.&lt;br/&gt;
+So I replaced them with a little service registry where you register a concrete class with an interface this class implements.<br/>
-Once again I had to discover that somebody else had already had that idea some time ago.&lt;br/&gt;
+Once again I had to discover that somebody else had already had that idea some time ago.<br/>
-OSGi is an SOA (bright me, reading about OSGi all the time without actually realizing what it means).&lt;br/&gt;
+OSGi is an SOA (bright me, reading about OSGi all the time without actually realizing what it means).<br/>
-So I am using now the OSGi ServiceRegistry to deal with services.&lt;br/&gt;
+So I am using now the OSGi ServiceRegistry to deal with services.<br/>
-You, as an aspiring rifidi developer, won't need to worry about that.&lt;br/&gt;
+You, as an aspiring rifidi developer, won't need to worry about that.<br/>
-To make it easier to use the services I wrote a ServiceLocater that does all the work for you.&lt;br/&gt;
+To make it easier to use the services I wrote a ServiceLocater that does all the work for you.<br/>
-The only thing to remember is to use the @Inject annotation and do the following call in the constructor.&lt;br/&gt;
+The only thing to remember is to use the @Inject annotation and do the following call in the constructor.<br/>
   ServiceRegister.getInstance().service(this)
 ==@Inject==
 This annotation is a marker for the ServiceLocator in the ServiceRegistry. It annotates a setter method that takes the desired service interface as it's only parameter.<br/>

@@ Line 1: / Line 1: @@
-==Why services==
+>==Why services==
-The first version of Designer (and also the rest of Rifidi) was littered with a lot of Singletons.<br/>
+The first version of Designer (and also the rest of Rifidi) was littered with a lot of Singletons.&lt;br/&gt;
 As everybody knows by now:
 * Singletons are bad.
 * They are hard to test.
 * Impossible (almost) to mock
-So I replaced them with a little service registry where you register a concrete class with an interface this class implements.<br/>
+So I replaced them with a little service registry where you register a concrete class with an interface this class implements.&lt;br/&gt;
-Once again I had to discover that somebody else had already had that idea some time ago.<br/>
+Once again I had to discover that somebody else had already had that idea some time ago.&lt;br/&gt;
-OSGi is an SOA (bright me, reading about OSGi all the time without actually realizing what it means).<br/>
+OSGi is an SOA (bright me, reading about OSGi all the time without actually realizing what it means).&lt;br/&gt;
-So I am using now the OSGi ServiceRegistry to deal with services.<br/>
+So I am using now the OSGi ServiceRegistry to deal with services.&lt;br/&gt;
-You, as an aspiring rifidi developer, won't need to worry about that.<br/>
+You, as an aspiring rifidi developer, won't need to worry about that.&lt;br/&gt;
-To make it easier to use the services I wrote a ServiceLocater that does all the work for you.<br/>
+To make it easier to use the services I wrote a ServiceLocater that does all the work for you.&lt;br/&gt;
-The only thing to remember is to use the @Inject annotation and do the following call in the constructor.<br/>
+The only thing to remember is to use the @Inject annotation and do the following call in the constructor.&lt;br/&gt;
   ServiceRegister.getInstance().service(this)
 ==@Inject==
 This annotation is a marker for the ServiceLocator in the ServiceRegistry. It annotates a setter method that takes the desired service interface as it's only parameter.<br/>

← Older revision		Revision as of 22:00, 3 June 2008
Line 13:		Line 13:
	The only thing to remember is to use the @Inject annotation and do the following call in the constructor.<br/>		The only thing to remember is to use the @Inject annotation and do the following call in the constructor.<br/>
	ServiceRegister.getInstance().service(this)		ServiceRegister.getInstance().service(this)
		+	==@Inject==
		+	This annotation is a marker for the ServiceLocator in the ServiceRegistry. It annotates a setter method that takes the desired service interface as it's only parameter.<br/>
		+	@Inject
		+	public void setEventsService(EventsService eventsService) {
		+	this.eventsService = eventsService;
		+	}
		+	After the call to service(this) in the constructor the locator will check the class for the annotation and try to resolve it.<br/>
		+	If the service is not available atb the time of the call it will be resolved as soon as the service becomes available.<br/>
		+	NOTE: All OSGi services are supported, als declarative services. The only problem is that due to the way they get initialized they are unsutable for a GUI application.