aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alasdair Nottingham <>
Subject Re: parsing blueprint elements on EBA install
Date Mon, 27 Sep 2010 19:51:50 GMT
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


On 27 September 2010 20:32, Lin Sun <> 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 <> 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 <> 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 <> 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 <> 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
>>>>>> Alasdair
>>>>>> On 27 Sep 2010, at 19:02, Joe Bohn<>  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

View raw message