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 <david.a.jen...@gmail.com> wrote:
On Dec 2, 2020, at 7:27 PM, Raymond Auge <raymond.a...@liferay.com.INVALID>
wrote:
On Wed, Dec 2, 2020 at 6:09 PM Pavel Horal <pavel.ho...@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-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
--
--
Carsten Ziegeler
Adobe Research Switzerland
cziege...@apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@felix.apache.org
For additional commands, e-mail: users-h...@felix.apache.org
