On May 24, 2012, at 15:01 PM, Bram de Kruijff wrote: > 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.
I agree. I'm not quite sure what you mean with the last sentence? The spec and our implementation both have MetaType as an optional dependency. > 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. Maybe. Maybe they felt that *requiring* MetaType to be around would have been too strong a dependency. After all, in all other uses, it is optional as well. I do have the feeling they never intended humans to hand-write these configuration files. If you have an editor and it generates these files, copying the OCDs to make them more self-contained is not that bad (in my opinion). > 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. Interesting idea, but I don't think we should do that for the exact reason you state (it does 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) Yes. > 2) We still supply /META-INF/metatype.xml where relevant (to provides > a reference for developers and support tools like webconsole) Yes. > Does that seem like a acceptable model for now? I completely agree. Greetings, Marcel _______________________________________________ Amdatu-developers mailing list [email protected] http://lists.amdatu.org/mailman/listinfo/amdatu-developers
