felix-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@adobe.com>
Subject Re: [DS] Feedback wanted on some ideas
Date Fri, 05 Oct 2012 19:24:25 GMT
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.


> 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_jencks@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
>>> thanks
>>> david jencks

View raw message