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 > >
