Thanks for the inputs to add a new service.
i have done the same thing but my service is not initialised it is
throwing an initialisation exception.
as u said in the init method without parameters i just wrote
setinit(true).
nothing is done as iam not initialising anything.
so i gave only setinit(true);
what could be the problem?
thanks and regards
rama
"Henning P. Schmiedehausen" wrote:
>
> ramadevi <[EMAIL PROTECTED]> writes:
>
> >Hi,
> >Is it possible to create a new service apart from the services provided
> >by the turbine.
>
> Yes, sure. Simply extend TurbineBaseService. You must then add your
> service to the TurbineResources.properties like this:
>
> services.<xxx>.classname = <full class name of your service>
>
> and you're set.
>
> If you look at the examples of the simple services like
> db/TurbinePoolBrokerService or servlet/TurbineServletService you'll
> get on speed pretty fast.
>
> In a Nutshell:
>
> - You must not try to provide a C'tor with parameters, best is not to
> provide any C'tor at all, because nothing should be done at
> construction time (You'll get the default c'tor which is fine for us).
>
> - Your Service will be instantiated exactly once. So it must be threadsafe,
> must not use class global variables for session-dependend information.
>
> - You should provide an init() method which is called when Turbine starts
> up and should initialized your service dependent code. There is lots
> of confusion of how this init() method should look like, I personally
> prefer the parameterless variant:
>
> public void init() throws InitializationException
> {
> }
>
> You must call setInit(true) if your service initializes correctly. Else
> no user of your service can find it. Right after this, your service might
> be queried and used by other sessions, so you should not call setInit()
> prematurely.
>
> - You might provide a shutdown() method which is called when Turbine shuts
> down. You can clean up your internal data in this method. You should call
> setInit(false) as the last thing in shutdown().
>
> - It is good style, that if you build the FooService, to provide:
>
> <yourpackage>.FooService.java with an Interface definition of your
> Service which extends o.a.t.services.Service
> It should contain a constant SERVICE_NAME
> with the Turbine visible name of your service.
>
> <yourpackage>.TurbineFooService.java which extends the TurbineBaseService,
> implements FooService and provides
> the actual code
>
> <yourpackage>.TurbineFoo.java which contains static facade methods for
> your service along the following lines:
>
> public abstract class TurbineFoo
> {
> protected static FooService getService()
> {
> return (FooService) TurbineServices
> .getInstance().getService(FooService.SERVICE_NAME);
> }
>
> [...]
>
> public static void fooMethod1()
> {
> getService().fooMethod1();
> }
>
> public static int fooMethod2(int bar)
> {
> return getService().fooMethod2(bar);
> }
>
> [...]
> }
>
> to give users of your service the ability to simply write
>
> TurbineFoo.fooMethod1();
>
> in their code and not to care which actual Implementation of FooService
> is running.
>
> init() and shutdown() applies to Turbine 2.1/2.2 This might change
> with the lifecycle interfaces in a later release.
>
> Regards
> Henning
>
> --
> Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
> INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [EMAIL PROTECTED]
>
> Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [EMAIL PROTECTED]
> D-91054 Buckenhof Fax.: 09131 / 50654-20
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
