aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Valentin Mahrwald <>
Subject Re: [Release Discussion] ship maintenance releases of application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Date Thu, 01 Sep 2011 06:41:59 GMT
Comments inline :)

Kind regards,


On 31 Aug 2011, at 20:02, Alasdair Nottingham wrote:

> I'm sorry for being slow I'm on holiday with limited access to email.
> The goal (I thought) was to ensure that the support for ${a+b} would be
> optional. When we make it optional we have two problems:
>   1. How do we make it optional (usually gate any call with a
>    Class.forName check to ensures we can load a class.
>   2. How do we fail when the support isn't there and someone is using it.
> The first problem is trivial to fix, the latter is harder to define. It
> isn't until you build the bean that you find the ${a+b} doesn't work and
> with lazy activation that could take a while. I would suggest that if we
> have ${a+b} in use, and the apache-jexl bundle is not present, then the bean
> creation would most likely fail (or you would get the wrong behaviour). This
> is obviously not desirable.
> An alternative would be to make use of the default behaviour of blueprint
> for namespace extensions. By using a separate namespace to indicate the
> desire to use this behaviour blueprint will delay initialisation of a
> bundle's blueprint container until the namespace is available. The result
> would be if apache-jexl is not present the namespace handler would not be
> registered and the blueprint container would not be configured. In addition
> you can now register the namesake when apache-jexl becomes available
> allowing it to be brought up later.

I think that this definitely the right way to go. In practical terms though it might be quite
a bit tricky to implement. 
In particular I am wondering how to link the usage of the extended property replacement syntax
to a namespace reference. I can think of 
the following ways to do this:

a) Have two  different property placeholder brackets like ${...} for the non-arithmetic one
and $[...] for the one doing arithmetic. The second
one is defined via a tag from the new namespace.
b) Support property placeholders only if we can support the whole shebang (which is kind of
step back?)
c) Have a kind of unrelated namespace import which we check for when we decide whether to
do arithmetic (that could be quite non-obvious to the user).

Is any of that what you were thinking of?

> Does that make any sense?
> Alasdair
> On 30 August 2011 07:36, Rex Wang <> wrote:
>> Sorry, I will add the corresponding tests. But I am not quite understanding
>> your suggestion in Aries-727 of  "use a different namespace to the ext
>> one".  The current implement add the ability to blueprint-ext and also
>> blueprint-cm, because the CmPropertyPlaceholder is the subclass of the
>> PropertyPlaceholder. Could a different namespace handle this?
>> After the change is final, will definitely port it to the trunk.
>> thanks,
>> -Rex
>> 2011/8/30 Alasdair Nottingham <>
>>> Hi,
>>> I'm not happy with the current fix for ARIES-727. There are no tests and
>> as
>>> I commented on the bug the dependency on jexl is not optional when it
>> should
>>> be. It also doesn't exist in trunk which is dangerous. This affects the
>>> programming model so it needs to be right.
>>> Alasdair Nottingham
>>> On 29 Aug 2011, at 23:17, Rex Wang <> wrote:
>>>> Hi Devs,
>>>> Geronimo 3.0-beta has passed the Java EE 6 full profile tck, and  is
>>> going
>>>> to release soon. But some dependencies are from Aries project, so we
>> are
>>>> requesting your supports to release the following 3 components with the
>>>> important fixes to our users. Could anybody please help?
>>>> *1. **org.apache.aries.application/0.2.2-SNAPSHOT*
>>>> ARIES-521: handles zip files without directory entries
>>>> ARIES-635: Move the resource bundle to the right directory
>>>> ARIES-638: Logging improvements for AriesApplicationManagerImpl
>>>> ARIES-667: OBRAriesResolver can return bundle information for bundles
>>> with
>>>> higher version than expected
>>>> ARIES-689: Application OBR resolution fails for optional imports
>>>> ARIES-734: Back port improvements made to resolution error messages in
>>> OBR
>>>> application resolver
>>>> *2. org.apache.aries.util/0.2.1-SNAPSHOT*
>>>> ARIES-667: OBRAriesResolver can return bundle information for bundles
>>> with
>>>> higher version than expected
>>>> *3. org.apache.aries.blueprint/0.3.2-SNAPSHOT*
>>>> ARIES-727 support syntax : ${a+b} in blueprint-ext
>>>> regards,
>>>> --
>>>> Lei Wang (Rex)
>>>> rwonly AT
>> --
>> Lei Wang (Rex)
>> rwonly AT
> -- 
> Alasdair Nottingham

View raw message