A simple way would be to create a service with dependencies on all your 10 services. When this service will be registered, you'll know your application is ready. But I agree this is a real problem and there is a need for something here.
On Thu, Feb 17, 2011 at 09:50, Eugen Reiswich <[email protected]> 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 > -- Cheers, Guillaume Nodet ------------------------ Blog: http://gnodet.blogspot.com/ ------------------------ Open Source SOA http://fusesource.com _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
