On Thu, May 24, 2012 at 2:24 PM, Marcel Offermans <[email protected]> wrote: > On May 24, 2012, at 13:56 PM, Matthijs Hendriks wrote: > > The autoconf resource processor checks (i a config file needs processing) > for metatype files of the bundles in the deployment package for the OCD in > the config file. > > > According to the spec (115.3.4) it should first check for OCD elements in > the resource itself. If not present in the resource, it should consult the > MetaType service. However, it is perfectly valid for the MetaType service to > not be present, so the resource processor cannot rely on it. > > It does this before all bundles are installed. > > > See figure 114.8, bundles are always installed or updated before any of the > customizers start processing resources, so this statement is not true. > > In some situations this is the best order, but if you simultaneously > provision a config file and the bundle containing the metatype with the OCD, > an exception is throws, since it can’t find the OCD in the deployment > package (yet). Detaching and attaching the config file ‘fixes’ the problem, > but oviously this is not very practical. > > > Neither is relying on the bundle containing the metatype, since we > established above that the MetaType service itself is optional. > > A local workaround for this is to include the OCD in the config file, so > that it can actually find the OCD. > > > I would not say that is a workaround, but the way to do it.
Agreed, it seems the way to do it. You just can't trust the metatype service to be there. Not just because it may not be part of the deployment, but also because if it is it's bundle may not be active because the DeploymentAdmin stopped it. The "optional" dependency of the AutoconfProcessor on Metatype is void. To me it does feel like a workaround.. around the spec. Clearly the idea of metatype is that the provider bundle can specify its configuration model and let the Metatype service "provide unified access". I don't think having to copy & paste the OCD's around was part of the plan. A partial solution might be to internalize the MetaType service document retrieval from bundles into the AutoConf processor (it is trivial). However, that still would not cover MetaTypeProvider (never actually see someone use it) services so it would not cover the spec. > However, another solution might be, to have the autoconf check not only in > the bundles in the deployment package, but also in the deployment queue (or > what is it called?). > > I don't think that makes sense, given the information above. > True, the bundles should have been installed. Maybe you did not have a MetaType service of it was not registered. So conclusions... 1) We ship config files by default with local OCD definitions (to avoid the issues discussed above) 2) We still supply /META-INF/metatype.xml where relevant (to provides a reference for developers and support tools like webconsole) Does that seem like a acceptable model for now? Grz, Bram > Greetings, Marcel > > > _______________________________________________ > Amdatu-developers mailing list > [email protected] > http://lists.amdatu.org/mailman/listinfo/amdatu-developers > _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
