felix-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Hess <MH...@orga-systems.com>
Subject Re: About the startlevel
Date Thu, 17 Mar 2011 16:57:43 GMT
> >> 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.
Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message