Hi, Am 03.10.2012 um 19:39 schrieb Andrei Pozolotin:
> 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. No. This would open security doors/holes. And as David indicates: The ScrService as well as the upcoming spec will allow for administrative enablement and disablement accross bundle boundaries (and the spec will include security considerations). Regards Felix > > -------- 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 >> >> >> >
