great ideas; one more for your consideration
http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent(java.lang.String)
<http://www.osgi.org/javadoc/r4v41/org/osgi/service/component/ComponentContext.html#enableComponent%28java.lang.String%29>
"""
public void *enableComponent*(java.lang.String name)
Enables the specified component name. The specified component name
must be in the same bundle as this component.
"""
instead, I suggest to permit traversal of bundle boundaries, so
enable/disable target can be anywhere.
-------- Original Message --------
Subject: [DS] Feedback wanted on some ideas
From: David Jencks <[email protected]>
To: [email protected]
Date: Wed 03 Oct 2012 12:28:49 PM CDT
> 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 state.
>
>
> thanks
> david jencks
>
>
>
