On 2010-11-15 12.59, Niclas Hedhman wrote:
Maybe called "interface Availability" instead, since AvailableService
sounds like other services are Unavailable ;-)

Much better! It was "Available" at first, but that clashed with the annotation. I'll change it.

There is also a service qualifier @Available that can be used for DI.
Example:
@Service @Optional @Available MyService service;
will only inject a service if it's currently available, otherwise null.

And this happens once? What if one has

@Service @Available ServiceReference<MyService>  ref;

??
I assume the ref will not be null, even if the service is not available.

Checks happen on injection for single references (i.e. ref will indeed be null if there is no available service), and if you have an Iterable it happens on each iterator() call: @Service @Available Iterable<ServiceReference<MyService>> availableMyServices;

A follow-up should possibly be that ServiceProvider (importedService)
can make services available/un-available after the initial start-up,

If you call ServiceReference.isAvailable() and the backing service is imported, then it will ask the ServiceImporter. So that is already there.

and finally I still would like to see a listener/notification of that
be exposed somehow (maybe on the ServiceReference).

There is no events going on, and I'm not sure it would be possible either. In many cases it is only when a question is specifically asked that it can be answered, e.g. "is a REST resource available? Well do GET and try!".

Further, I assume that a NotAvailableException is also defined, as
from you call isAvailable() until you make the call to the service, it
may no longer be available...

Yes, I actually renamed ServiceException to ServiceUnavailableException. isAvailable() is only an indicator, and when the service is actually used, directly after or an hour later or whatever, it might be down. That's business as usual. This will only help minimize errors, not eliminate them.

I was initially considering replacing isActive with isAvailable, but
currently they are both there. Does it make sense to have isActive() in an
API, or is that maybe more SPI'ish functionality as it relates to the
underlying service rather than usage?

I can't see the difference. Either I would view "not Active" as a sub
case of "not Available", or there is a domain specific meaning to it,
in which case it belong in the the domain code. But I am not having a
strongly formed opinion at the moment.

If you have a service hosted in Qi4j it can be "not active" but "available" (i.e. you can start it up), and it can also be "active" but "not available", so they are different. I'm just having a hard time seeing application/domain code bothering with it. For SPI-type code it definitely is interesting, i.e. "if service is active, passivate and activate it to restart it".

/Rickard

_______________________________________________
qi4j-dev mailing list
[email protected]
http://lists.ops4j.org/mailman/listinfo/qi4j-dev

Reply via email to