Re: [osgi-dev] OSGi dynamics
Hi, Am Donnerstag, den 17.02.2011, 11:59 + schrieb Neil Bartlett: 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. Yes, recent releases of Equinox DS implement the same API. Regards Felix ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] OSGi dynamics
[Peter Kriens] 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? [Eugen Reiswich] That's exactly the question I was not able to answer! Basically only the system designer can know whether the non-availability of a particular component is a normal or an error case. A component might be used in devices with and without a touch screen, or there could be a requirement to continue to provide limited service if the network connection goes down ... the case if any component fails, the whole system fails is the exception rather than the rule. [Peter Kriens] 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. [Eugene] 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? If the server can only handle client requests when all its components are active then I suppose you need some kind of mechanism to prevent the client from making requests before the server is ready; or else you respond to the requests with service unavailable, please try later. This would depend very much on the nature of the client application and the protocols being used. [Peter] 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. After gaining some practical experience with DS I find that (1) it's pretty neat, (2) sometimes I wish for just a little more control or interactivity. Your enabling filter sounds like a good idea, some standardised introspection mechanism could also help. Then again there are probably existing features that I haven't yet understood how to use effectively ... Best regards Chris ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] OSGi dynamics
On Thu, Feb 17, 2011 at 5:02 PM, Eugen Reiswich ereisw...@googlemail.com 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
Re: [osgi-dev] OSGi dynamics
On 19 Feb 2011, at 11:25 , Neil Bartlett wrote: 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. In some real-world systems I've seen, even that is not enough, as some of the dynamics happen even after all bundles have gone into their active state. The spec states that a BundleActivator.start() method should return in a timely manner, so if it needs to do a lot of work, it should probably start a background thread. If any of that work leads to, for example, more services being registered, even waiting for all bundles to reach the active state will not be enough. In short this confirms the statement that only you, as the designer of the system, will be able to come up with a good algorithm that defines when your system is up and running. Greetings, Marcel ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] OSGi dynamics
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 ereisw...@googlemail.com 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 osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
Re: [osgi-dev] OSGi dynamics
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 ereisw...@googlemail.com 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 ereisw...@googlemail.com 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 osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev -- Cheers, Guillaume Nodet Blog: http://gnodet.blogspot.com/ Open
Re: [osgi-dev] OSGi dynamics
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 ereisw...@googlemail.com 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 ereisw...@googlemail.com 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
Re: [osgi-dev] OSGi dynamics
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
Re: [osgi-dev] OSGi dynamics
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 ereisw...@googlemail.com 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 osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev ___ OSGi Developer Mail List osgi-dev@mail.osgi.org https://mail.osgi.org/mailman/listinfo/osgi-dev
