As of DS 1.1, the component name is only unique per bundle. So I'm not sure how this would work, wouldn't you need to include the bundle in the method signature?
david jencks On Oct 3, 2012, at 10:39 AM, Andrei Pozolotin wrote: > 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 <david_jen...@yahoo.com> > To: dev@felix.apache.org > 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 >> >> >> >
