Does this behavior mean that an EBA can't package a namespace handler that one of its other bundles uses? Is this prohibited or even a bad idea for other reasons?
thanks david jencks On Sep 27, 2010, at 11:39 AM, Alasdair Nottingham wrote: > No, it is so the resolver can resolve dangling service references, installing > the bundles would be bad because it would violate the contract of the Aries > application installer which allows you to resolve without installing the > application. Also when we are installing in an isolated way we need to know > the resolution prior to installation, so we would need to install, uninstall > then reinstall. > > Your namespace handler must cope, what is the problem? > > Alasdair > > On 27 Sep 2010, at 19:34, Joe Bohn <[email protected]> wrote: > >> >> Can you be more specific on the need for the EBA installer to parse the >> blueprint xml? Is it to validate that services exported by the EBA are >> actually defined in some bundle? >> >> If that is the case, then would it be possible to install the bundle(s) >> first and validate exported services against those registered by the various >> bundles? >> >> Joe >> >> >> On 9/27/10 2:16 PM, Alasdair Nottingham wrote: >>> Hi, >>> >>> I think the simple answer is probably yes. I think it is called once to >>> know how to resolve the application, and the second time because we have >>> installed the framework. >>> >>> Alasdair >>> >>> On 27 Sep 2010, at 19:02, Joe Bohn<[email protected]> wrote: >>> >>>> >>>> When processing an application (EBA) we parse all of the blueprint.xml >>>> (including custom namespaces) as part of the application processing for >>>> all bundles within the EBA. The net result is that we do all of this >>>> parsing twice because we also must parse and processes the information in >>>> the BlueprintContainer. >>>> >>>> Why is it necessary to parse the blueprint.xml during EBA installation in >>>> the application module? >>>> >>>> I stumbled on this because I was making some modifications to a custom >>>> namespace handler and noticed that it was being invoked twice for the same >>>> elements. It seems that this is not desirable. Should all namespace >>>> handlers be coded in such a way that they can be invoked multiple times >>>> for the exact same elements? >>>> >>>> -- >>>> Joe >>>
