great. I will study your sandbox.
-------- 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 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 <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
>>>>>
>>>>>
>>>>>
>
