Can you clarify a bit more accurately what is going wrong? Do some of the components not start at all, or are some not being bound into your application component?
If the former then make sure you enable the OSGi LogService. DS will send errors to the log service if any service fails to start, e.g. due to an exception in the constructor or activate method. If the latter, perhaps you are using optional-static references? If so there is a "gotcha" with these: DS will not "rebind" your component when the service becomes available. 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? However as a user, you see this as your application simply not starting, which certainly is an error. Depending on the DS implementation you may be able to introspect the state of the components, including the ones that are unsatisfied, and report this as a kind of startup progress. Felix DS has a handy introspection API for doing this, I hope that Equinox has this too but I'm not sure. Regards, Neil On Thu, Feb 17, 2011 at 8:50 AM, 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 > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
