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
. 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:

        name = "hello",
        property = "service.pid=hello",
        immediate = true)
public class HelloComponent {

    public HelloComponent() {
        System.out.println("Hello Felix Demo");

    void activate(Map<String, Object> properties) {
        System.out.println("ACTIVATION PROPS: " + properties);

    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,

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.


Reply via email to