I wouldn't be surprised if the doc does need improving, but this has always been possible because the blueprint container exposes a parsing service.
If you save the resolved application and use that on second startup then the second parse won't happen, so the performance hit is limited to the first use, I don't see this as a huge issue. Alasdair On 27 Sep 2010, at 20:00, Joe Bohn <[email protected]> wrote: > > It's not a question of the namespace handler being able to cope. I think I > can certainly accommodate multiple passes. > > I was just considering the larger implications. I'm a little concerned about > the performance of parsing everything twice - but I suppose that isn't a huge > problem (at least until we decide we need to parse a few more times for a few > more reasons). > > I think we do need to clearly communicate and document the requirements this > change places on namespace handlers in general. Prior to this the assumption > was that namespace handlers were being invoked when parsing the blueprint xml > by the the blueprint container (after the bundles were started). It also > wasn't necessary to handle multiple invocations because the bundle would only > be parsed once. With this change the namespace handler is being invoked in > a different context (before the bundle is started) and multiple times. > > Joe > > > On 9/27/10 2:39 PM, 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 >>>> >> > > > -- > Joe
