On Mon, Nov 15, 2010 at 9:01 PM, Rickard Öberg <[email protected]> wrote:
>> @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), The ref is null, not a reference pointing to a null? I think this is semantics that we might not have gotten right. > and if you have an Iterable it > happens on each iterator() call: > @Service @Available Iterable<ServiceReference<MyService>> > availableMyServices; Ok, sounds reasonable. > >> 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. Ok, good. >> 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!". Well, when I worked on a GUI client many years ago with Jini backing the available services on the network, it was much better to softly disable features that became unavailable if a service disappeared, than waiting for the user to execute the command and toss an error in her face. We also had a simple indicator for "availability" based on how many of the expected services were actually available, as a quick reference. >> 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. Ok, good. > 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". Ok, so the isActive() is actually "hasBeenActivated()" which communicates the meaning better. Yes, I agree it barely makes sense in API, but I am ok to keep it in ServiceReference. One far fetched use-case I can imagine is that for a really slow starting service, one might avoid calling it if it has not been activated, to avoid the delay that it would incur... but OTOH how often does one have such a choice? Cheers -- Niclas Hedhman, Software Developer http://www.qi4j.org - New Energy for Java I live here; http://tinyurl.com/2qq9er I work here; http://tinyurl.com/2ymelc I relax here; http://tinyurl.com/2cgsug _______________________________________________ qi4j-dev mailing list [email protected] http://lists.ops4j.org/mailman/listinfo/qi4j-dev
