We are using iPOJO so I'll take a look at doing this.
Thanks for that link. That's a treasure trove of documentation.
On 8/7/2014 2:33 AM, Benjamin Debeerst wrote:
If you're not constrained to the component framework, you might want to
consider iPOJO. This allows you to control the service lifecycle via a simple
boolean field, annotated with @ServiceController [1]. In particular if you have
some properties attached to that service you don't have to worry to pass them
to OSGi every time you're registering the service. You can also have one
component publish multiple services and control the service lifecycles
altogether or independently.
Regards,
Benjamin
[1]
http://felix.apache.org/documentation/subprojects/apache-felix-ipojo/apache-felix-ipojo-userguide/instance-vs-service-controller.html
-----Original Message-----
From: Neil Bartlett [mailto:njbartl...@gmail.com]
Sent: Mittwoch, 6. August 2014 16:12
To: users@felix.apache.org; Dean Schulze
Subject: Re: Can I restart one Service from another Service?
To register a service: BundleContext.registerService()
The returned object from that method is a ServiceRegistration. When you want to
unregister, call ServiceRegistration.unregister().
Regards,
Neil
On 6 August 2014 at 14:49:40, Dean Schulze (dean.w.schu...@gmail.com) wrote:
The remote process sends a heartbeat over the socket periodically. If the
heartbeat is missing we need to re-establish the socket by waiting for the
remote process to come back up and connect.
I could register a proxy service when there is a connection and unregister it
when the connection is lost. Can you give me a pointer to how to dynamically
register / unregister a service?
On 8/5/2014 6:43 PM, David Jencks wrote:
I'm afraid Neil's proposal puts the exact same problem in another component. He
is correct that you should NOT call any of the lifecycle methods that DS calls.
On the other hand the original request isn't very well formed.
What is your goal here? Do you want a service "proxying" the remote process to
be registered only when there is a connection to the remote process? How do you determine
whether or not the remote process is available and when its availability changes?
I don't understand your problem yet, but you might consider having the activate
method start a thread that manages the connection to the remote process, and
registers a service when is establishes the connection and unregisters the
service when the connection fails or ends. The deactivate method can stop this
thread.
thanks
david jencks
On Aug 5, 2014, at 4:48 PM, Neil Bartlett <njbartl...@gmail.com> wrote:
No you should not call activate/deactivate yourself, these are intended to be
called by the framework.
Instead, represent the remote process as a service, then bind the service into
your DS component using a mandatory reference.
On 6 August 2014 at 00:10:15, Dean Schulze (dean.w.schu...@gmail.com) wrote:
I have a Service Component that communicates with a remote process
via a socket. The activate methods waits for the remote process to
come up and then establishes communication. If that remote process
goes down I need to go through the same process that the activate
method uses to establish communication.
I haven't been able to find any information on restarting a Service
Component. Can I programatically restart a Service Component, or
would it be better to call deactivate() and activate() on the same Service
Component?
Thanks.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
