Hi Balázs

There is a very simple reason that targeted pids point at bundles. The bundle 
is the unit of deployment and management in OSGi.

Now, to discuss the reasoning behind this. It’s important to understand that 
there are a lot of different job roles involved in creating and running a 
production system. Years ago these job roles were actually done by different 
people, so this was easy to understand, however now the industry has 
consolidated a lot of these roles. A software developer is typically now also 
now involved in design and  testing, and the devops movement is pushing them 
into deployment and management as well.

You are quite correct that Require-Bundle is a bad thing, but that is because 
bundles are a bad way to express dependencies, not because bundles themselves 
are a bad thing! Require-Bundle is therefore something to avoid when 
developing, but it is something that’s pretty important when deploying (the 
Bndtools resolver run requirements are typically bundle requirements).

At runtime a “management agent” (e.g. file install, the Paremus Service Fabric, 
a developer at her keyboard) is responsible for deployment and operational 
management. This means that they have to install and configure things. The 
entire OSGi specification is built around the concept of a bundle being the 
thing that you deploy. You can’t install a DS component, or a package, just a 
bundle.

Therefore, given that the deployer is always working with bundles, it makes 
sense to target configurations at bundles. In the situation where you have 
multiple versions of a given component/Managed Service Factory in the framework 
then those will come from different bundles. The deployer knows which bundles 
are installed, and which bundles the configurations they’re creating are 
intended for.

In summary, the reason that the targeted pid feels “wrong” to you is that 
you’re used to working at an extremely low level in the system. Configuration 
management is actually a much higher level task, and one that needs to be 
optimised for operational management in a large system over the longer term.

I hope this helps,

Regards,

Tim

> On 21 Nov 2016, at 22:58, Balázs Zsoldos <balazs.zsol...@everit.biz> wrote:
> 
> Hi,
> 
> I have another thought based on the configadmin spec. if you have still some 
> energy to read my mails :)
> 
> In 104.3.2 Targeted Pids
> 
> The target PID scopes the applicability of the PID to a limited set of target 
> bundles.
> The syntax of a target pid is: target-pid ::= PID ( '|' symbolic-name ( '|' 
> version ( '|' location )? )? )? 
> 
> My question is: Why do we target the bundle?
> 
> Using Require-Bundle at bundle wirings is "deprecated" and there is a reason 
> for that.
> 
> Before reading the following, please note: I am not proposing to change the 
> syntax of PIDs in an incompatible way. I am writing these examples simply to 
> have a similarity with the current spec.
> 
> Why do not we target with OSGi filters?
> 
> An example to target a bundle:
> 
> MYPID|(bundle.symbolicName=myBundle)
> 
> Well, targeting bundles are not that interesting. I would never use that. But 
> targeting components or managed services that have multiple versions in the 
> OSGi container can be much more interesting. The selected Managed Service 
> would be based on its service properties.
> 
> If one uses ConfigurationListener instead of ManagedService to implement a 
> component framework, he/she can decide what the OSGi filter should be matched 
> against.
> 
> An example to be sure that the compatible version of the component will pick 
> up the configuration :
> 
> MYPID|(&(version>=2.1)!(version>=3))
> 
> Kind regards,
> Balázs
> 
> _______________________________________________
> OSGi Developer Mail List
> osgi-dev@mail.osgi.org
> https://mail.osgi.org/mailman/listinfo/osgi-dev

_______________________________________________
OSGi Developer Mail List
osgi-dev@mail.osgi.org
https://mail.osgi.org/mailman/listinfo/osgi-dev

Reply via email to