> >> Rely on service dependency management, not ordering. Code that relies on > >> ordering should be considered broken. > > Well, since bundles are started in a serial fashion (or not???), ignoring > > the sequence will force you to have some kind of support for late > > registration of services. I have built something like this with the help > > of the ServiceTrackerCustomizers, and it works. But it is still more > > complicated then simply creating a ServiceTracker, opening it, and > > retrieving the service. > > I understand your point there, and I think you are right from a > > theoretical perspective. But as I outlined further below, I think it > > really is not all black and white in that area. > > If you are responding to service events, then ordering is generally not > an issue. This is simplified even more if you use something like iPOJO, > DS, etc. since your component won't even be created until its > dependencies are satisfied, which then is basically the same as your > "creating a ServiceTracker, opening it, and retrieving the service" > approach. You can do the same manually with service listeners, but why > bother when these component frameworks will do it for you?
Why do I suddenly feel like I am missing out on something big here... Are you basically telling me I can do IOC style things out of the box by using DS (or iPOJO)? > > For example logging - which probably is a central service in every > > application. Would you really write code, that everytime it accesses the > > log service it first checks for the presence of the service by retrieving > > it from a ServiceTracker? Though, as far as I know this is the "right way > > to do it", I would still say it feels like I am "overdoing" it here. > > In my current application, I simply expect logging to be a "core" service, > > which is simply not allowed to disappear. Hence my strategy is simple: I > > get a reference to the service in the activator of my bundles, and then I > > reuse it everywhere in that bundle. > > No, I wouldn't do that for logging. I'd use iPOJO to declare the log > service as an optional dependency and have it inject me with the service > if it exist or a null object if it doesn't and I'd just ignore the > situation completely. OK, understood. But how do you manage the possible null pointer behind your log references? Is there some other trick one can pull off, to prevent permanent writing of tedious null checks? > > I think this also puts up the qestion of what the implacation of such a > > disappearing service would be from a business point of view. While the > > software could certainly work without logging (by work I mean, service the > > business case), it would still mean I am blindfolded when it comes to > > problems. So coming from that perspective I would say - once the logging > > is gone, the system is broken and should not commence working simply > > because I cannot tell anymore whether the system is out of control or not. > > For mandatory services, I'd just tell iPOJO it was a mandatory > dependency and it would tear things down for me in case of a failure. > Not much else you can do if a required service goes away. Point taken! Michael The information included in this e-mail and any files transmitted with it is strictly confidential and may be privileged or otherwise protected from disclosure. If you are not the intended recipient, please notify the sender immediately by e-mail and delete this e-mail as well as any attachment from your system. If you are not the intended recipient you are not authorized to use and/or copy this message and/or attachment and/or disclose the contents to any other person.
