I would argue that in that case only the client's initializer is not used. A situation that the client is more likely to notice and thus may find the required configuration. It would not impact the product's stability, however, only the client's additional feature.
Regards Julian On Wed, Nov 9, 2016 at 10:46 AM, Carsten Ziegeler <[email protected]> wrote: > Julian Sedding wrote >> I'm in favour of using ids/names to configure a list of required >> plugins. That seems more robust. >> >> Imagine a client application deploying its own RepositoryInitializer >> without adjusting the required number of services. That could easily >> lead to one of the "product" RepositoryInitializers to be skipped. >> Even worse, depending on the startup order (and without proper >> service.ranking) the active RepositoryInitializers could vary between >> restarts. >> > Well, I can argue if the same client does so without adjusting the list > of required names then the initializer might not be used either. The > variation is less than with configuring the number, but the > problem/danger is the same. > > Carsten > >> Regards >> Julian >> >> >> On Wed, Nov 9, 2016 at 10:33 AM, Carsten Ziegeler <[email protected]> >> wrote: >>> Julian Sedding wrote >>>> Wouldn't it make sense in these "we have 0..N *mandatory* plugins, how >>>> to wait on them problem" situations to explicitly configure all >>>> required dependencies on the consuming service, e.g. by PID. This >>>> would make it robust and allow for correct ordering. Of course the >>>> additional configuration constitutes an overhead, but I think if the >>>> dependencies are mandatory, this information needs to live somewhere. >>>> >>> Right, there are two options: >>> - you configure the number of services you expect, usually you know how >>> many you deploy >>> - you reference the required services by some other means. PID does not >>> work as not every service has a PID. So we would need to come up with >>> another property identifying the service, like "name", "id" etc. >>> >>> I see other people very often use the first approach being totally happy >>> with it. But whatever we pick, I'm fine with it as long as we pick >>> something. The current way simply does not work >>> >>> Carsten >>> >>> -- >>> Carsten Ziegeler >>> Adobe Research Switzerland >>> [email protected] >>> >> > > > > > -- > Carsten Ziegeler > Adobe Research Switzerland > [email protected] >
