On Thu, Feb 17, 2011 at 5:02 PM, Eugen Reiswich <[email protected]> wrote: >> 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!
As Chris points out... this is not something that DS can know, but YOU can know. Suppose all of the bundles that you have installed are in ACTIVE state, but some of your components are unsatisfied. DS does not know that you do not intend to install more how many more bundles you intend to install, but you do. You could simply write a bundle that starts all bundles and waits for them to reach ACTIVE state (a BundleListener or BundleTracker will help you with this part). Once all the bundles you know about are active, your system should be in its "ready" state, and if it is not then you can work out what went wrong. Likewise if any bundle fails to start then you will get a specific error about that bundle. Incidentally this is how the JUnit executor in Bndtools works... it starts all bundles, waits for them all to reach active state, then begins running any testcases it can find in the bundles. >> 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 > _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
