So, in the general case, it is not possible to deploy resources for which bundles are needed that get provisioned in my own deployment package. This seems to be a reentrant problem: what if my resource processor needs a service, which in turn needs some configuration, while I provision ConfigAdmin in my own deployment package? That gives us a potential chain of dependent resource processors, with all the problems that brings. Wild idea: how about creating a new class of Resource, and 'after-the-fact' resource: we keep the in-process Resources as they are now, and only deliver the after-the-fact resources to their respective resource processors once the processor's dependencies are resolved, and it comes up?
In this specific case, would you propose building a resource processor that just 'accepts' the resources, and drops them into the ConfigAdmin when that comes up? Angelo On Mar 7, 2011, at 10:02 AM, Peter Kriens wrote: > I think you need a special resource processor for this case. It seems very > bad practice to use a bundle before it is properly configured. > > Kind regards, > > Peter Kriens > > > > > On 3 mrt 2011, at 10:49, Angelo van der Sijpt wrote: > >> Hi List, >> >> The Auto Configuration Specification (compendium, section 115) shows a >> resource processor for use in Deployment Admin, which allows deploying >> configurations into Configuration Admin. >> The basic workflow of Deployment Admin is roughly like this, >> - install all bundles, but don't start them, >> - start all resource processors (marked with 'DeploymentPackage-Customizer' >> in their manifest), >> - feed all resources to the resource processors, >> - start the rest of the bundles. >> >> If I now have both a Config Admin, an AutoConf processor, and some >> configurations in my deployment package, the Config Admin would only be >> started once all resources have been processed, but this would mean the >> AutoConf processor cannot find the Config Admin to put the configurations >> on. So, this cannot work. >> >> Is this an oversight in the spec, or is there a technical reason to disallow >> this? >> >> In a more general sense, I can see other situations in which I would have >> resources, their related processor, and the 'receiving bundle' for the >> resources in a single deployment package. Is this something we want to >> support, or should the receiving bundle just also pack the resource >> processor? >> >> Thanks, >> >> Angelo >> _______________________________________________ >> OSGi Developer Mail List >> [email protected] >> https://mail.osgi.org/mailman/listinfo/osgi-dev > > > _______________________________________________ > OSGi Developer Mail List > [email protected] > https://mail.osgi.org/mailman/listinfo/osgi-dev _______________________________________________ OSGi Developer Mail List [email protected] https://mail.osgi.org/mailman/listinfo/osgi-dev
