You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@felix.apache.org by David Jencks <da...@yahoo.com> on 2014/04/17 08:15:59 UTC
[DS] Changing the format of the info from commands?
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
Re: [DS] Changing the format of the info from commands? AND REMOVING OLD ADMIN API
Posted by David Jencks <da...@yahoo.com>.
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 <da...@yahoo.com> 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 <fm...@adobe.com> 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 <da...@yahoo.com>:
>>
>>> 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
>>>
>>
>
Re: [DS] Changing the format of the info from commands?
Posted by David Jencks <da...@yahoo.com>.
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 <fm...@adobe.com> 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 <da...@yahoo.com>:
>
>> 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
>>
>
Re: [DS] Changing the format of the info from commands?
Posted by Felix Meschberger <fm...@adobe.com>.
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 <da...@yahoo.com>:
> 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
>