I've been working on implementing the DTO stuff and its apparent that there's a larger problem than info format. The current Component interface exposed from the existing ScrService doesn't really make sense since it conflates the ComponentDescription and ComponentConfiguration levels. Furthermore it provides what I consider very inappropriate access to the ComponentInstance.
(While implementing DTO support and multiple pid support I've removed the "single component" that was always present in ConfigurableComponentHolder, apparently to make the Component interface work.) I think there are two more or less plausible choices: - completely drop the org.apache.felix.scr package (people can use the spec ServiceComponentRuntime service) (obviously this can't change the package version, which won't exist. What would it do the the bundle version?) - provide new partial implementations of the classes in that package based on the dtos. As far as I can see they are going to be very partial since I think Component is going to have to map to ComponentDescriptionDTO so there won't be any information at all about any instances. I suppose possibly I could mimic the current behavior by basing most of the Components on the ComponentConfigurationDTO but when there isn't one, basing the Component on the ComponentDescrioptionDTO instead. I really don't want to allow access to the Componentinstance however. If there is a really good argument for continuing to allow access to ComponentInstance then I think is should be via an extension of the spec ServiceCompomentRuntime, ComponentInstance getCompomentInstance( ComponentConfigurationDTO instance) Thoughts? Any other ideas? thanks david jencks On Apr 17, 2014, at 10:30 AM, Felix Meschberger <[email protected]> wrote: > Hi > > You are talking about the Shell/Gogo integrations ? > > Yes, I think it would make sense to morph them into matching what the > upcoming spec intents to do. > > Regards > Felix > > Am 16.04.2014 um 23:15 schrieb David Jencks <[email protected]>: > >> The upcoming ds spec has a more sensible data format for DS components built >> in, and I'd like to change the output of the SCR commands to match this new >> format, so we don't have to maintain two sets of data. The main change is >> that instead of each component being represented by an unconfigured instance >> or all the configured instances, there's a "definition" layer showing what >> the xml tells you and then an "instance" layer showing all the actual >> (configured) instances. >> >> I hope that this will also mean we don't have to have unconfigured instances >> around even when they aren't satisfied just to show the info from xml. >> >> Any objections to this in principle? >> >> thanks >> david jencks >> >
