On 3/17/11 10:30, Michael Hess wrote:
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?
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.
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.
-> richard
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
