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 20:12:35 GMT
1) I don't know how the blueprint code handles this situation when the
parsing service is being used, as opposed to setting up a blueprint. A
test case is a good way in my view to work this out. It would also
help us to scope what, if any, limitation exists.
2) If namespace handlers were standardized then I believe it would
increase the likely hood of people wanting to include namespace
handlers and include them in applications. It is therefore relevant
because it affects, in my mind at least, the priority of worrying
about this "limitation".


On 27 September 2010 20:52, David Jencks <> wrote:
> Not sure how a test case will clarify the situation. You are saying the eba scan of blueprint
plans should not install any bundles in the eba.  My scenario is that a namespace handler
impl is in one of the eba bundles and it adds all the services exported by the blueprint plan.
 How can you discover these without loading the namespace handler from one of the eba bundles,
which you've said shouldn't happen? I don't see standardization of namespace handlers are
relevant, this seems like an important requirement for the interaction of EBA and blueprint
that ought to be ironed out in the future specs.
> david jencks
> On Sep 27, 2010, at 12:28 PM, Alasdair Nottingham wrote:
>> I think we need a test case, it is possible it won't work as it can't find the namespace
handler to parse the code, also if it adds services or references we may not add them to the
resolve process, so bad things could happen. I don't think applications will do this right
now since namespace handlers are not standardised.
>> Alasdair
>> On 27 Sep 2010, at 20:06, Lin Sun <> wrote:
>>> I think that should be possible.  We just need to make sure the name
>>> space handler registered in the isolated environment are detectable by
>>> the namespace handler registry thus can be properly registered.
>>> Lin
>>> On Mon, Sep 27, 2010 at 2:55 PM, David Jencks <>
>>>> 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 <> 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<>  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