felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <david_jen...@yahoo.com>
Subject [DS] Feedback wanted on some ideas
Date Wed, 03 Oct 2012 17:28:49 GMT
I've had several ideas about DS enhancements, some of which I've implemented, and would like
some feedback about how desirable they are before committing or proceeding with them.

1.  (FELIX-3692)  If you manually enable/disable components some of the work gets done asynchronously.
 I propose an api for finding out whether this work is done or waiting for it, something like

   boolean tasksCompleted();

   void waitForTasksCompleted();

on ScrService.   (suggestions for better names welcome :-)  One use would be in our tests
to replace the delay() call.

2.  (FELIX-3557) There are several circumstances in which, as the spec warns, you can't establish
a circular dependency between components.  In some of these cases, the order in which the
components are activated determines whether all the references are established.  This is hard
to understand from a users point of view :-).  Sometimes it's possible to detect these situations
and establish the reference asynchronously.  The patch attached to the issue does this but
needs a little more work to only try with services from DS components.

For these two, I'm wondering if they would be useful enough to propose for the DS 1.3 spec.

3. (re-proposal)  I'd like to propose moving the implementation to java 5 again with generics
etc.  The last time I suggested this there was a lot of pushback on the grounds that there
are a lot of people using DS on limited platforms.  However, none of these alleged :-) people
is using trunk, because for several months the classes pulled from the concurrent library
were wrong and trunk just didn't run on pre-java-5 vms.  Are the compendium 4.3 spec classes
we pull in even compatible with pre-java-5 vms?

4.  (radical idea I haven't tried yet)  I'm becoming increasingly convinced that the state
objects in AbstractComponentManager mostly cause confusion and make the code more complicated
and less reliable.  The spec really only describes two states, enabled and disabled.  The
variations on enabled -- whether the component has all its dependencies satisfied, whether
the service is registered, whether there are any implementation objects created -- all seem
somewhat orthogonal and depend very much on the environment  and don't seem to relate well
to a single "dimension" of state.  I'm considering trying to refactor the code that responds
to outside actions (activate/deactivate and dependencies appearing/disappearing) to be more
"straight-through" with checks on the specific aspects of state that they need.  Possibly
we would want to put the "dynamic state" such as dependencies + instances in a single state
object, but this is a different approach to the current state objects which have no internal

david jencks

View raw message