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 17:09:54 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)?
> 
> 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.

OK, I think I have some "homework" todo. Seems like there are solutions to 
some of the problems we are fighting.

> >>> 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.

Yummy, this sounds good. Need to check it (especially because I have iPOJO 
in here already for something...)

Thank you so much for your input!

Michael

> -> 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: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
> 


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