Okay, sounds good. I'll create an issue for his and fix the config files in the projects :)
Matthijs -----Original Message----- From: Bram de Kruijff [mailto:[email protected]] Sent: donderdag 24 mei 2012 16:16 To: [email protected] Subject: Re: [Amdatu-developers] Autoconf processor and metatype OCDs On Thu, May 24, 2012 at 3:50 PM, Marcel Offermans <[email protected]> wrote: > 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. I just meant that this spec defined situation means that as the one writing configuration files, I can never assume that MetaType service will be around. Thus, I must always define local OCDs (as we agree) upon below. Given this situation, the fact that the spec says it may optionally be there does not provide me with anything, so it just as well could have been left out. At least taht is how I understand it now :S >> 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. ack 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
