Although there was an OSGI F2F and a big mail outage, I haven't seen any response to this. Please speak up soon or I will go ahead and remove the package with the old felix specific admin api.
(locally, I have all the tests except those for factory components rewritten to use the new ServiceComponentRuntime api + DTOs). thanks david jencks On May 5, 2014, at 12:14 AM, David Jencks <[email protected]> wrote: > 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 >>> >> >
