Hi Andrei, Am 05.10.2012 um 20:54 schrieb Andrei Pozolotin:
> Felix: great. can you please share link - what do you mean by "upcoming > spec "? Andrei. There is nothing public yet except the requirements available from OSGi Bug 147 [1] (where you commented already) The rest is work in progress in the OSGi Aliance which I cannot share yet. But the API will be based on what's in my sandbox at [2] (though there will be some changes). The "upcoming spec" is the spec enhancements we do to implement RFP-151 from Bug 147. Regards Felix [1] https://www.osgi.org/bugzilla/show_bug.cgi?id=147 [2] http://svn.apache.org/repos/asf/felix/sandbox/fmeschbe/dsadmin/ > > -------- Original Message -------- > Subject: Re: [DS] Feedback wanted on some ideas > From: Felix Meschberger <fmesc...@adobe.com> > To: dev@felix.apache.org <dev@felix.apache.org> > Date: Fri 05 Oct 2012 01:48:41 PM CDT >> 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 >>>> >>>> >>>> >> >
