[Peter Kriens]>> Of course you're right that there is an issue with when you consider >> the application to have "started", whether successfully or >> unsuccessfully. DS does not consider a component with unsatisfied references to be any kind of error, because the services that would make it a satisfied component may be coming along very soon... so, when should an error be thrown?
[Eugen Reiswich]> That's exactly the question I was not able to answer! Basically only the system designer can know whether the non-availability of a particular component is a "normal" or an "error" case. A component might be used in devices with and without a touch screen, or there could be a requirement to continue to provide limited service if the network connection goes down ... the case "if any component fails, the whole system fails" is the exception rather than the rule. [Peter Kriens]>> That said, I did have a similar problem last year with framework >> startup. I decided I wanted a READY service that would be registered by the framework when the framework was ready with the starting of all the bundles. This got efficiently shut down in the CPEG though but during the discussion we came to an interesting idea for DS. [Eugene]> > Ok, I can life with this solution even though it feels like a workaround. > As I understand I will need to deploy the ReadyService twice: server-side > and client-side in a distributed environment with server-side OSGi, right? If the server can only handle client requests when all its components are active then I suppose you need some kind of mechanism to prevent the client from making requests before the server is ready; or else you respond to the requests with "service unavailable, please try later". This would depend very much on the nature of the client application and the protocols being used. [Peter]>> The idea was to add a new filter to a DS component that controlled the enabled status of the component. As long as that filter was not satisfied, the component was disabled. Obviously, you could set this filter in the XML (or bnd annotations [plug!]) or in Configuration Admin. I think this would address many of your needs. After gaining some practical experience with DS I find that (1) it's pretty neat, (2) sometimes I wish for just a little more "control" or "interactivity". Your enabling filter sounds like a good idea, some standardised introspection mechanism could also help. Then again there are probably existing features that I haven't yet understood how to use effectively ... Best regards Chris _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
