The problem you're describing here is one that a lot of people that start developing applications built out of services run into. A log service is a nice example, but the problem is more generic.
Basically, the issue is, you have components in your application that want to log things, but these components have a different life cycle than that of the log service they depend on. When modelling this dependency, you have a few options: a) Make it a required dependency, which means that no component depending on the log service will become active before the log service is present. That sounds great, it solves your problem, but it does mean that all these components will go down again if you stop or just briefly update the log service, which might not be what you want. b) Make it an optional dependency, which means that your components will become active, and might or might not actually log events. They will when the log service is up, but if it's not, you will loose log events. The upside is that your components stay up if the log service is down or being updated. There are some options to customize this behaviour. You can create a client side proxy that will capture all log events and send them to the log service when it becomes available again. You can also create a second log service with a low service ranking, which can act as a "backup" service, capturing log events and sending them to a log service with higher ranking when it becomes available (this could be seen as a server side proxy, leveraging the OSGi service registry). Finally, you have the option of using a "temporal dependency" (that's the term the Felix Dependency Manager uses for it). A temporal dependency is a required dependency that sticks around even if the actual dependency disappears for a short amount of time. Any component invoking a method on that service dependency whilst it's temporarily not available will block with a configurable timeout. If, within that time, the service dependency appears again, the call will unblock. If not, it times out and you get an exception (something you should always expect when invoking a service anyway). This last option might not be the best solution for logging, but I'm mentioning it for completeness. Which solution you choose depends on your exact requirements. Each one has trade-offs and without more context it's hard to decide. I hope this gives you an idea of the possible solutions though. Greetings, Marcel On May 16, 2010, at 10:52 , yashas wrote: > > I have apache file install agent to install and start my bundles on a felix > container. The file install agent installs and starts the bundles in no > determinate order as all the bundles have the same bundlelevel of 1 > (startlevel of the framework is also 1). My concern is specific to the SLF4J > bundle, the logback bundle and my custom bundle 'A' which has the logging > statements. The issue is that I am intermittently seeing the logging > statements of bundle A getting logged into log file which i believe is due > to logback bundle being started before SLF4J bundle sporadically. But when I > change the bundle level of logback to 2 (startlevel of framework to 2) then > i do consistently see the logs of bundle A in log file. This behavior makes > me believe that the SLF4J bundle always needs to be started before the > logback bundle but at the same time i do realize that start level should NOT > be used as a way to control service startup order. This is considered a > programming error in OSGi as service start orders are not guaranteed and > services may come and go at will. Please help me out with the right approach > to take. Thanks in advance. > -- > View this message in context: > http://old.nabble.com/bundle-start-up-order-related-issue-tp28573308p28573308.html > Sent from the Apache Felix - Users mailing list archive at Nabble.com. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
