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
