Hi Andrei, Am 05.10.2012 um 21:19 schrieb Andrei Pozolotin:
> David: > > in case you are open for more revolutionary ideas: > can we have "DS/SCR annotation service", please? :-) We have annotations. But those are build-time annotations for a good reason: We don't want to eagerly read/load classes just to find annotations. Rather the annotations are converted into the traditional descriptors which provide for great support of lazy loading. So, I don't really see a benefit in runtime annotations. Regards Felix > > just steal from Aries: > > http://aries.apache.org/modules/blueprintannotation.html > > """ > Blueprint annotation is being prototyped in Apache Aries in trunk/blueprint. > The blueprint annotation service is an optional service to the blueprint core > and should not affect the blueprint core if annotation supported is not > required. If the blueprint annotation service is available, the bundle > contains > no blueprint definition XML and the bundle contains the manifest header > Bundle-Blueprint-Annotation with the value set to true, the blueprint > annotation service will attempt to scan the bundle for blueprint annotations, > such as @Blueprint, @Bean, @Service, @Reference, @ReferenceList, etc. The > blueprint annotation api is available in > trunk/blueprint/blueprint-annotation-api module, while the blueprint > implementation is available in trunk/blueprint/blueprint-annotatiom-impl > module. A blueprint annotated sample is also provided in > trunk/blueprint/blueprint-sample-annotation. > """ > > thank you. > > Andrei. > > -------- Original Message -------- > Subject: Re: [DS] Feedback wanted on some ideas > From: David Jencks <david_jen...@yahoo.com> > To: dev@felix.apache.org > Date: Fri 05 Oct 2012 12:26:40 PM CDT >> Any comments on these ideas? Should I take silence as agreement :-) ? >> >> thanks >> david jencks >> >> On Oct 3, 2012, at 10:28 AM, David Jencks wrote: >> >>> 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 >>> >>> >> >
