Hi, Am 05.10.2012 um 23:38 schrieb Andrei Pozolotin:
> Felix: > > 1) will you accept comments on your sandbox? Yes, I will accept comments. > > 2) if so, where should I post it? You can post them here or create JIRA issues as you like. Regards Felix > > 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 >>>>>> >>>>>> >>>>>> >> >
