[Remoterengine-devel] service mechanism

[Romain Francois]

Hi,

I've commited a "simple" service mechanism in the RemoteREngine code so 
that we can implement variations of some bahaviours. For example reading 
a line from the console involves the ConsoleReadLine interface, which is 
a service and the default implementation of this service is given by the 
DefaultConsoleReadLine class.

Here are the steps to take advantage of this
- create a service interface : Service is just a marker interface, so 
there is no more to do than declare that your interface extends Service
- create an implementation of the service, as usual you create a class 
that implements the service interface you described above
- You need to annotate the class with the "ServiceImplementation" annotation

Under the carpet, this happens, at compile time, the 
ServiceImplementation annotations are processed, which creates a file 
called services.xml that is deployed in the jar. Currently it looks like 
this :


<?xml version="1.0"?>
<services>
   <!-- this is an autogenerated file, do not change -->

   <service
      class="org.rosuda.REngine.remote.common.console.ConsoleReadLine"
      name="default"
 
implementation="org.rosuda.REngine.remote.common.console.DefaultConsoleReadLine" 
/>

</services>


The xml file is then parsed to feed the ServiceManager class, which you 
can then use to create instances of your services, with the getInstance 
method :

public static <T extends Service> T getInstance( Class<T> serviceClass, 
String name) throws ServiceException

(at the moment the ConsoleThread class uses it:

reader = ServiceManager.getInstance(ConsoleReadLine.class, "default") ;

I'm hoping that with a mechanism like this, we can keep the code light 
but provide hooks for extended functionality. For example, I plan to use 
jline for implementing the "ConsoleReadLine" interface to get features 
such as completion and history in the console, but I would like to have 
this as a separate pluggable component.

One other potential use is for logging, we would create an interface 
that declares the logging behaviour and provide a default implementation 
using only regular java classes, and maybe an additional component 
outside using Log4J or something.

One thing I have not done yet though is a strategy for loading 
additional jars , ... I guess I'll cross that bridge when I work on the 
jline stuff

Romain

-- 
Romain Francois
Professional R Enthusiast
+33(0) 6 28 91 30 30
http://romainfrancois.blog.free.fr
|- http://tr.im/w33B : Completion for java objects
|- http://tr.im/vzip : Code Snippet : List of CRAN packages
`- http://tr.im/vsK1 : R parser package on CRAN