> 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?
That's exactly the question I was not able to answer! > 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. 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? Eugen Am 17.02.2011 um 14:43 schrieb Peter Kriens: > First, if you run into problems because certain mandatory services are not > running you've clearly not handled your dependencies explicitly ... Except > for situations where you need more than 1 of a specific service type, you can > always correctly create a dependency graph for each component. It sounds like > you have optional dependencies. > > 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. > > 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. > > This idea is on my too long list of things to do for CPEG :-( > > In the mean time, it is not very hard to create a component that provides the > READY service based on a configuration admin record (just add the filters in > the configuration record). The component waits until all the filters are > satisfied and then registers the READY. The filters could look for service > properties but you could also provide specific properties about the > environment: time of day, startlevel, bundles, etc. > > Kind regards, > > Peter Kriens > > > > On 17 feb 2011, at 09:50, Eugen Reiswich wrote: > >> Hi folks, >> >> The start up of an application is exactly where I get in trouble with OSGi. >> Although using DS, my application sometimes starts with say only 8 of 10 >> available services due to misconfiguration. In this case I would rather >> throw a RuntimeException, NPE ore something comparable to point at the place >> where the misconfiguration happened. To be more precisely, what I need is a >> possibility to recognize that all 10 of 10 services are started. In this >> case I would like to print something out like "application started >> successfully, all 10 of 10 services are available". If less than 10 services >> are available throw an exception and give developers a hint that the >> application started inconsistently. But in OSGi there is no point in time >> where I can ensure that my application is in a consistent state and ensure >> that all services are started, right? >> >> Eugen >> >> >> Am 16.02.2011 um 18:53 schrieb Neil Bartlett: >> >>> Hi Eugen, >>> >>> This is a very interesting question, thanks for asking it! >>> >>> I appreciate that dynamics are not a big feature of enterprise >>> applications, but there is one time when ALL applications are dynamic, >>> and that is during startup (also, less importantly, during shutdown). >>> This is what I find most useful about OSGi Services: bundles can be >>> started in any order and they can find each other and wire themselves >>> up without requiring a fragile start ordering or a central "God" >>> component to do the wiring. >>> >>> If you are using Declarative Services (DS) you do not necessarily have >>> to handle dynamics and concurrency. The default policy for a service >>> reference is "static": this means that your component instance will be >>> destroyed and recreated if the target of the reference ever changes. >>> This hugely simplifies the programming model because you don't need to >>> worry about concurrency at all. It can be inefficient if things are >>> changing frequently but in an environment where dynamic >>> installation/uninstallation is rare then it can be the best policy. >>> >>> Spring DM/Blueprint has some similar features for "damping" dynamics; >>> I will let somebody else describe them because I am not an expert. >>> >>> With regard to ensuring all mandatory dependencies are satisfied, it's >>> very simple... just start ALL of your bundles! DS has a very helpful >>> feature called "delayed services" in which the implementation of the >>> service is not created until the service is actually needed by a >>> client. This means that it is essentially free to start a DS-based >>> bundle. You just have to be sure NOT to include a BundleActivator... >>> you don't need activators anyway if you are using DS. >>> >>> Regards, >>> Neil >>> >>> On Wed, Feb 16, 2011 at 5:34 PM, Eugen Reiswich >>> <[email protected]> wrote: >>>> Hi folks, >>>> >>>> we had today a conversation regarding OSGi with DS for business >>>> applications. The main point of the discussion was: how can I get rid of >>>> OSGi dynamics in applications where I do not need dynamics. For example: >>>> in an application for a savings bank I will NOT start to use hot plugging >>>> to add new bundles or remove existing bundles, start and stop services >>>> while customers are transferring money from one account to another. The >>>> point is that in OSGi applications I have to deal with dynamic behavior of >>>> services and bundles although I explicitly do not want to have this >>>> behavior. Declarative services in fact simplify the service orchestration >>>> and concurrency but they still have a dynamic character. >>>> >>>> Moving from a world currently dominated by Spring to an OSGi world the >>>> question arise: how can I ensure in an OSGi application that all >>>> required/mandatory services are satisfied at start up? In applications >>>> with more than a few services the OSGi console is not an appropriate way >>>> for this task. >>>> >>>> To give you an example: we are developing a server-side OSGi application >>>> which provides several domain related services: CustomerService, >>>> AccountService etc. When we start our server we do not know whether all >>>> service relations are satisfied and thus all mandatory services are >>>> started. Any ideas/best practices would be appreciated. >>>> >>>> Regards, >>>> Eugen >>>> _______________________________________________ >>>> OSGi Developer Mail List >>>> [email protected] >>>> https://mail.osgi.org/mailman/listinfo/osgi-dev >>>> >>> >>> _______________________________________________ >>> OSGi Developer Mail List >>> [email protected] >>> https://mail.osgi.org/mailman/listinfo/osgi-dev >> >> >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
