Felix: 1) will you accept comments on your sandbox?
2) if so, where should I post it? Andrei -------- Original Message -------- Subject: Re: [DS] Feedback wanted on some ideas From: Felix Meschberger <[email protected]> To: [email protected] <[email protected]> Date: Fri 05 Oct 2012 02:01:23 PM CDT > 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 <[email protected]> >> To: [email protected] <[email protected]> >> 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 <[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 >>>>> >>>>> >>>>> >
