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