You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@felix.apache.org by Pavel Horal <pa...@orchitech.cz> on 2020/12/02 23:08:48 UTC
SCR duplicating service PIDs
Hello,
I came across a strange behavior regarding manually set service.pid for DS
components that is being duplicated by SCR upon configuration event.
When I define components with a manually set *service.pid *property I don't
expect SCR to actually duplicate the value when updating configuration.
The culprit is with the following line
https://github.com/apache/felix-dev/blob/master/scr/src/main/java/org/apache/felix/scr/impl/manager/ConfigurableComponentHolder.java#L483
. You can easily observe the following:
- There is a list of service PIDs that is being initialized to the PID
from component properties in the beginning of the method (line 464).
- List of PIDs is being extended with PID from the configuration
component (line 483), regardless whether the PID is already contained in
the list.
My question is whether this is really intended behavior or a potential bug.
I guess duplicate PIDs are only a real issue if component authors are
expecting that property to have just a single value... unfortunately that
is my case (I am migrating quite a large project from old Felix + SCR maven
plugin that was adding service.pid property by default).
*Wouldn't it be better if the ConfigurableComponentHolder only add unique
PIDs? Or would that break something?*
---
My sample component:
@Component(
name = "hello",
property = "service.pid=hello",
immediate = true)
public class HelloComponent {
public HelloComponent() {
System.out.println("Hello Felix Demo");
}
@Activate
void activate(Map<String, Object> properties) {
System.out.println("ACTIVATION PROPS: " + properties);
}
@Modified
void modified(Map<String, Object> properties) {
System.out.println("MODIFIED PROPS: " + properties);
}
}
After creating configuration I end up
Hello Felix Demo
ACTIVATION PROPS: {service.pid=hello, component.name=hello, component.id=0}
MODIFIED PROPS: {service.pid=[hello, hello], component.name=hello,
component.id=0}
Things get a bit stranger if I configure multiple PIDs, then SCR behaves
differently and simply replaces the array with a single value from the
configuration dictionary.
Pavel
Re: SCR duplicating service PIDs
Posted by Carsten Ziegeler <cz...@apache.org>.
Hi
that bug was fixed in the maven-scr-plugin:
https://issues.apache.org/jira/browse/FELIX-5304
Regards
Carsten
Am 03.12.2020 um 15:15 schrieb Pavel Horal:
> Hello,
>
> thank you for the clarification. I am actually in the process of migrating
> stuff (mainly reference / service filters) away from service.pid to
> component.name where applicable.
>
> I was confused by the fact that legacy SCR plugin did exactly what I was
> trying to achieve (createPid parameter) -
> https://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#component
> . In such environment one can always expect all services to have
> service.pid set (not just those with a configuration).
>
> Thank you for all the replies,
> Pavel
>
> On Thu, 3 Dec 2020 at 07:31, David Jencks <da...@gmail.com> wrote:
>
>>
>>
>>> On Dec 2, 2020, at 7:27 PM, Raymond Auge <ra...@liferay.com.INVALID>
>> wrote:
>>>
>>> On Wed, Dec 2, 2020 at 6:09 PM Pavel Horal <pa...@orchitech.cz>
>> wrote:
>>>
>>>> ---
>>>>
>>>> My sample component:
>>>>
>>>> @Component(
>>>> name = "hello",
>>>> property = "service.pid=hello",
>>>>
>>>
>>> This is not quite correct actually. I would have expected SCR to complain
>>> about this because service.pid should be one of the "managed" component
>>> properties. (i.e. never pass service.pid as a property)
>>>
>>> Since you have set _name_ property, what you want is simply:
>>>
>>>> @Component(
>>>> name = "hello",
>>>
>>> immediate = true)
>>>> public class HelloComponent { ... }
>>>>
>>>
>>> ... without setting _configurationPid_ property, 'service.pid' is implied
>>> from _name_.
>>>
>>> With that, you should notice that your component responds as you expect
>>> when a configuration with pid "hello" appears.
>>>
>>> HTH
>>>
>>> PS: _All components are configurable_ (even ones you never anticipated
>>> passing configuration to) because they always infer at least their
>>> component name as a service.pid (AFAIC this is one of the most
>> understated
>>> wonders of DS.)
>>
>> What if you’ve specified configuration policy IGNORE?
>>
>> Otherwise, I agree it’s a wonderful feature, although I always preferred
>> configuration policy REQUIRE.
>>
>> David Jencks
>>>
>>> --
>>> *Raymond Augé* (@rotty3000)
>>> Senior Software Architect *Liferay, Inc.* (@Liferay)
>>> OSGi Fellow
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
>> For additional commands, e-mail: users-help@felix.apache.org
>>
>>
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: SCR duplicating service PIDs
Posted by Pavel Horal <pa...@orchitech.cz>.
Hello,
thank you for the clarification. I am actually in the process of migrating
stuff (mainly reference / service filters) away from service.pid to
component.name where applicable.
I was confused by the fact that legacy SCR plugin did exactly what I was
trying to achieve (createPid parameter) -
https://felix.apache.org/documentation/subprojects/apache-felix-maven-scr-plugin/scr-annotations.html#component
. In such environment one can always expect all services to have
service.pid set (not just those with a configuration).
Thank you for all the replies,
Pavel
On Thu, 3 Dec 2020 at 07:31, David Jencks <da...@gmail.com> wrote:
>
>
> > On Dec 2, 2020, at 7:27 PM, Raymond Auge <ra...@liferay.com.INVALID>
> wrote:
> >
> > On Wed, Dec 2, 2020 at 6:09 PM Pavel Horal <pa...@orchitech.cz>
> wrote:
> >
> >> ---
> >>
> >> My sample component:
> >>
> >> @Component(
> >> name = "hello",
> >> property = "service.pid=hello",
> >>
> >
> > This is not quite correct actually. I would have expected SCR to complain
> > about this because service.pid should be one of the "managed" component
> > properties. (i.e. never pass service.pid as a property)
> >
> > Since you have set _name_ property, what you want is simply:
> >
> >> @Component(
> >> name = "hello",
> >
> > immediate = true)
> >> public class HelloComponent { ... }
> >>
> >
> > ... without setting _configurationPid_ property, 'service.pid' is implied
> > from _name_.
> >
> > With that, you should notice that your component responds as you expect
> > when a configuration with pid "hello" appears.
> >
> > HTH
> >
> > PS: _All components are configurable_ (even ones you never anticipated
> > passing configuration to) because they always infer at least their
> > component name as a service.pid (AFAIC this is one of the most
> understated
> > wonders of DS.)
>
> What if you’ve specified configuration policy IGNORE?
>
> Otherwise, I agree it’s a wonderful feature, although I always preferred
> configuration policy REQUIRE.
>
> David Jencks
> >
> > --
> > *Raymond Augé* (@rotty3000)
> > Senior Software Architect *Liferay, Inc.* (@Liferay)
> > OSGi Fellow
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
> For additional commands, e-mail: users-help@felix.apache.org
>
>
Re: SCR duplicating service PIDs
Posted by David Jencks <da...@gmail.com>.
> On Dec 2, 2020, at 7:27 PM, Raymond Auge <ra...@liferay.com.INVALID> wrote:
>
> On Wed, Dec 2, 2020 at 6:09 PM Pavel Horal <pa...@orchitech.cz> wrote:
>
>> ---
>>
>> My sample component:
>>
>> @Component(
>> name = "hello",
>> property = "service.pid=hello",
>>
>
> This is not quite correct actually. I would have expected SCR to complain
> about this because service.pid should be one of the "managed" component
> properties. (i.e. never pass service.pid as a property)
>
> Since you have set _name_ property, what you want is simply:
>
>> @Component(
>> name = "hello",
>
> immediate = true)
>> public class HelloComponent { ... }
>>
>
> ... without setting _configurationPid_ property, 'service.pid' is implied
> from _name_.
>
> With that, you should notice that your component responds as you expect
> when a configuration with pid "hello" appears.
>
> HTH
>
> PS: _All components are configurable_ (even ones you never anticipated
> passing configuration to) because they always infer at least their
> component name as a service.pid (AFAIC this is one of the most understated
> wonders of DS.)
What if you’ve specified configuration policy IGNORE?
Otherwise, I agree it’s a wonderful feature, although I always preferred configuration policy REQUIRE.
David Jencks
>
> --
> *Raymond Augé* (@rotty3000)
> Senior Software Architect *Liferay, Inc.* (@Liferay)
> OSGi Fellow
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: SCR duplicating service PIDs
Posted by Carsten Ziegeler <cz...@apache.org>.
In addition to what Ray wrote, service.pid is defined as a multi value
string property. If code is inspecting this property it must deal with
that.
Regards
Carsten
Am 03.12.2020 um 04:27 schrieb Raymond Auge:
> On Wed, Dec 2, 2020 at 6:09 PM Pavel Horal <pa...@orchitech.cz> wrote:
>
>> ---
>>
>> My sample component:
>>
>> @Component(
>> name = "hello",
>> property = "service.pid=hello",
>>
>
> This is not quite correct actually. I would have expected SCR to complain
> about this because service.pid should be one of the "managed" component
> properties. (i.e. never pass service.pid as a property)
>
> Since you have set _name_ property, what you want is simply:
>
>> @Component(
>> name = "hello",
>
> immediate = true)
>> public class HelloComponent { ... }
>>
>
> ... without setting _configurationPid_ property, 'service.pid' is implied
> from _name_.
>
> With that, you should notice that your component responds as you expect
> when a configuration with pid "hello" appears.
>
> HTH
>
> PS: _All components are configurable_ (even ones you never anticipated
> passing configuration to) because they always infer at least their
> component name as a service.pid (AFAIC this is one of the most understated
> wonders of DS.)
>
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@felix.apache.org
For additional commands, e-mail: users-help@felix.apache.org
Re: SCR duplicating service PIDs
Posted by Raymond Auge <ra...@liferay.com.INVALID>.
On Wed, Dec 2, 2020 at 6:09 PM Pavel Horal <pa...@orchitech.cz> wrote:
> ---
>
> My sample component:
>
> @Component(
> name = "hello",
> property = "service.pid=hello",
>
This is not quite correct actually. I would have expected SCR to complain
about this because service.pid should be one of the "managed" component
properties. (i.e. never pass service.pid as a property)
Since you have set _name_ property, what you want is simply:
> @Component(
> name = "hello",
immediate = true)
> public class HelloComponent { ... }
>
... without setting _configurationPid_ property, 'service.pid' is implied
from _name_.
With that, you should notice that your component responds as you expect
when a configuration with pid "hello" appears.
HTH
PS: _All components are configurable_ (even ones you never anticipated
passing configuration to) because they always infer at least their
component name as a service.pid (AFAIC this is one of the most understated
wonders of DS.)
--
*Raymond Augé* (@rotty3000)
Senior Software Architect *Liferay, Inc.* (@Liferay)
OSGi Fellow