I haven't got to the point where I agree or disagree (although I fear I will disagree) on whether it will be possible to do this, but since you say it would be possible to do "update" instead of "install/uninstall" (assuming you are referring to the Bundle.update() method) it wouldn't reduce the parse. An update does a stop/start of a bundle which would cause the blueprint container implementation to reparse the blueprint.xml files.
I also think the cost of making the code do 1 parse is probably higher than the cost of doing it twice (in the rare cases you need to do it twice). I know I sound vague, but that is because I'm still vague in my thinking and want to do more thinking before going into more detail. Alasdair On 27 September 2010 20:32, Lin Sun <[email protected]> wrote: > Hi > > Sorry I misread your note... now it is clear :) > > I agree it is best to parse blueprint xmls for application policy at > the application install time. I had just thought of the possibility > to avoid the 2 times of parsing by establishing the application first, > then do an update of the application as needed when the blueprint xmls > are parsed by the blueprint container. (With the latest hooks or > subsystem, it should be possible to do the update instead of uninstall > + reinstall.). However, I think it is cleaner to do it at > application layer which has the knowledge of bundles in the > application, even tho it means we need to parse blueprint xmls twice > (at least when app first installed). > > Lin > On Mon, Sep 27, 2010 at 3:09 PM, Alasdair Nottingham <[email protected]> wrote: >> Hi, >> >> I meant what I said, to follow Joe's suggestion we would do the steps I >> described. >> >> I don't see how subsystems helps, nor do the resolver hooks. >> >> Alasdair >> >> On 27 Sep 2010, at 19:59, Lin Sun <[email protected]> wrote: >> >>> I assume you meant >>> >>> so we would NOT need to install, uninstall then reinstall. >>> >>> I wonder if it is possible to do an update of the isolated composite >>> after we detect the need to modify the composite policies such as >>> import-service or import-package, etc, maybe not with the current >>> solution provided by the framework we use, but perhaps with the latest >>> subsystem impl in the future? >>> >>> Thanks >>> >>> Lin >>> >>> On Mon, Sep 27, 2010 at 2:39 PM, Alasdair Nottingham <[email protected]> >>> 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 >>>>>> >>>> >> > -- Alasdair Nottingham [email protected]
