On 3/17/11 12:57, 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?
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)?
I am not sure what you mean by "out of the box"...but
DS/iPOJO/Dependency Manager/etc. all support an IoC approach to OSGi
programming...the exact details of each is different, but they all
interoperate via services and the service registry.
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?
In iPOJO, for example, you can have it inject your components with a
"null object" if an optional service is not available. The "null object"
is just a dummy implementation that does nothing. You can also specify
your own custom dummy object that does whatever you want.
-> richard
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.
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
