You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@aries.apache.org by Rex Wang <rw...@gmail.com> on 2011/08/30 08:17:16 UTC
[Release Discussion] ship maintenance releases of application-0.2.2 /
util-0.2.1 / blueprint-0.3.2 ?
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 apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
Hi Alasdair,
I just added 2 unit tests to the blueprint-core(At revision: 1163525).
BTW, if no one has the objection on the *
org.apache.aries.application/0.2.2-SNAPSHOT* and *
org.apache.aries.util/0.2.1-SNAPSHOT*. Could any one help release them
first?
thanks
-Rex
2011/8/30 Alasdair Nottingham <no...@apache.org>
> 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 <rw...@gmail.com> 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 apache.org
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Jeremy Hughes <hu...@apache.org>.
OK, I understand that, but + comes with the language. Parsing what's
between {} shouldn't need an external library, IMHO.
On 8 September 2011 14:49, Rex Wang <rw...@gmail.com> wrote:
> In GERONIMO-5987 <https://issues.apache.org/jira/browse/GERONIMO-5987>
>
> We need ${ActiveMQ + PortOffset}.
>
> 2011/9/8 Jeremy Hughes <hu...@apache.org>
>
>> On 8 September 2011 14:18, Rex Wang <rw...@gmail.com> wrote:
>> > 2011/9/8 Timothy Ward <ti...@apache.org>
>> >
>> >>
>> >> Hi,
>> >>
>> >> comments in line
>> >>
>> >> > From: rwonly@gmail.com
>> >> > Date: Thu, 8 Sep 2011 17:10:54 +0800
>> >> > Subject: Re: [Release Discussion] ship maintenance releases of
>> >> application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
>> >> > To: dev@aries.apache.org
>> >> >
>> >> > 2011/9/8 Timothy Ward <ti...@apache.org>
>> >> >
>> >> > >
>> >> > > Hi,
>> >> > >
>> >> > > I'm afraid I've not been paying as much attention as I should to
>> this
>> >> > > thread. Reading back over the issues. I would currently vote -1 on
>> this
>> >> > > release. I am not at all happy with the fact that users of this
>> support
>> >> will
>> >> > > see different, potentially erroneous, behaviour depending on the
>> >> presence or
>> >> > > absence of an optional dependency. Our previous statement has always
>> >> been
>> >> > > "If a blueprint bundle wants to use some non-standard function it
>> >> should
>> >> > > declare that using an additional namespace".
>> >> > >
>> >> > Do you mean the statement in spec 121.4:
>> >> > "The Blueprint XML resources in a bundle are the definitions. Each
>> >> > definition can include multiple
>> >> > namespaces. Implementations of the Blueprint core namespace must
>> strictly
>> >> > follow this specification,
>> >> > if they add additional behavior they must add additional namespaces
>> that
>> >> are
>> >> > actually used in
>> >> > the definitions to signal the deviation from this specification."?
>> >> >
>> >> > We are improving the blueprint-ext, which has been already an
>> additional
>> >> > namespace to blueprint core schema. Why must we add a new namespace to
>> >> > extend the ability of blueprint-ext?
>> >> >
>> >> >
>> >> > > In my view this new function should only be available if the
>> optional
>> >> > > dependency is satisfied, and blueprint bundles must enable this
>> >> function
>> >> > > using a custom namespace. Otherwise I see two problems.
>> >> > >
>> >> > >
>> >> > > I want this new support, but have no way to ensure it is present, as
>> a
>> >> > > result I am sometimes injected with "1+2" instead of "3". This leads
>> to
>> >> > > intermittent NumberFormatExceptions
>> >> > >
>> >> > I do not want this new support, but as the dependency is available I
>> am
>> >> > > injected with "3" instead of "1+2". This leads to inconsistent and
>> >> confusing
>> >> > > behaviour.
>> >> > >
>> >> > I am not sure I understand this..
>> >> > If you want 3, you need <xxx value="${1+2}">
>> >> > If you want 1+2, you should use <xxx value="1+2">
>> >> > Only the expression in ${..} will trigger the calculation, no matter
>> if
>> >> the
>> >> > dependency if available.
>> >> >
>> >>
>> >> Do in the absence of the jexl dependency what does <xxx value="${1+2}">
>> >> equal?
>> >>
>> >> What happens if I want to use a property placeholder keyed off the
>> string
>> >> value "1+2" when jexl is present?
>> >>
>> > We should NOT implicitly encourage user use such style as a key of value.
>> I
>> > don't think it makes any sense. In practice, I did not see any blueprint
>> > config file use that.
>>
>> Why does anyone need jexl to add two numbers together?
>>
>> >
>> >
>> > -Rex
>> >
>> >
>> >>
>> >>
>> >> > -Rex
>> >> >
>> >> >
>> >> > >
>> >> > >
>> >> > > Adding a namespace for this function elegantly solves both these
>> issues
>> >> in
>> >> > > a way that is consistent with other blueprint extensions, and I
>> think
>> >> is
>> >> > > essential before this function can be released.
>> >> > >
>> >> > > Regards,
>> >> > >
>> >> > > Tim
>> >> > >
>> >> > >
>> >> > > > From: rwonly@gmail.com
>> >> > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
>> >> > > > Subject: Re: [Release Discussion] ship maintenance releases of
>> >> > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
>> >> > > > To: dev@aries.apache.org
>> >> > > >
>> >> > > > I still think adding a new namespace only for such simple
>> calculation
>> >> is
>> >> > > too
>> >> > > > heavy and not consumalbe for users..
>> >> > > >
>> >> > > > Anyway, could anybody help with the release of *
>> >> > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
>> >> > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help
>> >> check
>> >> > > why
>> >> > > > I can not deploy artifacts to apache.snapshot? Maybe I can try
>> >> release
>> >> > > the 2
>> >> > > > components. Geronimo does not have much time targeting the
>> 3.0-beta
>> >> > > release.
>> >> > > >
>> >> > > > thanks,
>> >> > > >
>> >> > > > -Rex
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
>> >> > > >
>> >> > > > > If we release blueprint as is we will never be able to make the
>> >> change
>> >> > > as
>> >> > > > > we
>> >> > > > > would cause a major breaking change. I think we need to get this
>> >> right
>> >> > > > > before a release is done.
>> >> > > > >
>> >> > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
>> >> > > > >
>> >> > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
>> >> > > > > >
>> >> > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
>> >> > > vmahrwald@googlemail.com
>> >> > > > > > > >wrote:
>> >> > > > > > >
>> >> > > > > > > > Comments inline :)
>> >> > > > > > > >
>> >> > > > > > > > Kind regards,
>> >> > > > > > > >
>> >> > > > > > > > Valentin
>> >> > > > > > > >
>> >> > > > > > > > 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).
>> >> > > > > > > >
>> >> > > > > > > >
>> >> > > > > > > The blueprint specification says any non-standard extensions
>> to
>> >> > > > > blueprint
>> >> > > > > > > must be enabled via namespace handlers. I don't like the ext
>> of
>> >> cm
>> >> > > > > > > namespaces to require apache-jexl since it means more
>> >> dependencies
>> >> > > are
>> >> > > > > > > pulled in when they may never be used.
>> >> > > > > > >
>> >> > > > > > Hi Alasdair,
>> >> > > > > > Since the current code does not hard depend on the
>> commons-jexl,
>> >> and
>> >> > > I
>> >> > > > > > think
>> >> > > > > > the only difference from your desire is adding a new namespace
>> >> which
>> >> > > can
>> >> > > > > > delay the blueprint container initialization if the
>> commons-jexl
>> >> is
>> >> > > not
>> >> > > > > > present,
>> >> > > > > > I consider this as an improvement to the current solution. And
>> I
>> >> > > think it
>> >> > > > > > would be better to let user hold the option that if he would
>> use
>> >> the
>> >> > > new
>> >> > > > > > namespace, and if he don't use it, the ${a+b} can still work.
>> >> Hope
>> >> > > the
>> >> > > > > > current solution meets the criteria to start release..
>> >> > > > > >
>> >> > > > > > BTW, seems Aries community is not that active in last two
>> month.
>> >> Is
>> >> > > there
>> >> > > > > > still a release manager help the release works?
>> >> > > > > >
>> >> > > > > > -Rex
>> >> > > > > >
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > >
>> >> > > > > > > Looking at your options a) doesn't work because it isn't
>> using
>> >> > > > > namespace
>> >> > > > > > > handlers, b) sucks big time and would mean to meat the spec
>> we
>> >> > > would
>> >> > > > > > need
>> >> > > > > > > apache-jexl and the whole point is to allow the spec to be
>> >> > > implemented
>> >> > > > > > > without apache-jexl being required. So I think something
>> like
>> >> > > option c
>> >> > > > > > > should be gone for. For instance you could add an attribute
>> in
>> >> a
>> >> > > > > > > non-standard namespace that says to enable this capability.
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > > > Is any of that what you were thinking of?
>> >> > > > > > > >
>> >> > > > > > > > > Does that make any sense?
>> >> > > > > > > > >
>> >> > > > > > > > > Alasdair
>> >> > > > > > > > >
>> >> > > > > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com>
>> >> 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 <no...@apache.org>
>> >> > > > > > > > >>
>> >> > > > > > > > >>> 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 <rw...@gmail.com>
>> >> 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 apache.org
>> >> > > > > > > > >>>
>> >> > > > > > > > >>
>> >> > > > > > > > >>
>> >> > > > > > > > >>
>> >> > > > > > > > >> --
>> >> > > > > > > > >> Lei Wang (Rex)
>> >> > > > > > > > >> rwonly AT apache.org
>> >> > > > > > > > >>
>> >> > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > >
>> >> > > > > > > > > --
>> >> > > > > > > > > Alasdair Nottingham
>> >> > > > > > > > > not@apache.org
>> >> > > > > > > >
>> >> > > > > > > >
>> >> > > > > > >
>> >> > > > > > >
>> >> > > > > > > --
>> >> > > > > > > Alasdair Nottingham
>> >> > > > > > > not@apache.org
>> >> > > > > > >
>> >> > > > > >
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > --
>> >> > > > > > Lei Wang (Rex)
>> >> > > > > > rwonly AT apache.org
>> >> > > > > >
>> >> > > > >
>> >> > > > >
>> >> > > > >
>> >> > > > > --
>> >> > > > > Alasdair Nottingham
>> >> > > > > not@apache.org
>> >> > > > >
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > --
>> >> > > > Lei Wang (Rex)
>> >> > > > rwonly AT apache.org
>> >> > >
>> >> > >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > Lei Wang (Rex)
>> >> > rwonly AT apache.org
>> >>
>> >>
>> >
>> >
>> >
>> > --
>> > Lei Wang (Rex)
>> > rwonly AT apache.org
>> >
>>
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
In GERONIMO-5987 <https://issues.apache.org/jira/browse/GERONIMO-5987>
We need ${ActiveMQ + PortOffset}.
2011/9/8 Jeremy Hughes <hu...@apache.org>
> On 8 September 2011 14:18, Rex Wang <rw...@gmail.com> wrote:
> > 2011/9/8 Timothy Ward <ti...@apache.org>
> >
> >>
> >> Hi,
> >>
> >> comments in line
> >>
> >> > From: rwonly@gmail.com
> >> > Date: Thu, 8 Sep 2011 17:10:54 +0800
> >> > Subject: Re: [Release Discussion] ship maintenance releases of
> >> application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> >> > To: dev@aries.apache.org
> >> >
> >> > 2011/9/8 Timothy Ward <ti...@apache.org>
> >> >
> >> > >
> >> > > Hi,
> >> > >
> >> > > I'm afraid I've not been paying as much attention as I should to
> this
> >> > > thread. Reading back over the issues. I would currently vote -1 on
> this
> >> > > release. I am not at all happy with the fact that users of this
> support
> >> will
> >> > > see different, potentially erroneous, behaviour depending on the
> >> presence or
> >> > > absence of an optional dependency. Our previous statement has always
> >> been
> >> > > "If a blueprint bundle wants to use some non-standard function it
> >> should
> >> > > declare that using an additional namespace".
> >> > >
> >> > Do you mean the statement in spec 121.4:
> >> > "The Blueprint XML resources in a bundle are the definitions. Each
> >> > definition can include multiple
> >> > namespaces. Implementations of the Blueprint core namespace must
> strictly
> >> > follow this specification,
> >> > if they add additional behavior they must add additional namespaces
> that
> >> are
> >> > actually used in
> >> > the definitions to signal the deviation from this specification."?
> >> >
> >> > We are improving the blueprint-ext, which has been already an
> additional
> >> > namespace to blueprint core schema. Why must we add a new namespace to
> >> > extend the ability of blueprint-ext?
> >> >
> >> >
> >> > > In my view this new function should only be available if the
> optional
> >> > > dependency is satisfied, and blueprint bundles must enable this
> >> function
> >> > > using a custom namespace. Otherwise I see two problems.
> >> > >
> >> > >
> >> > > I want this new support, but have no way to ensure it is present, as
> a
> >> > > result I am sometimes injected with "1+2" instead of "3". This leads
> to
> >> > > intermittent NumberFormatExceptions
> >> > >
> >> > I do not want this new support, but as the dependency is available I
> am
> >> > > injected with "3" instead of "1+2". This leads to inconsistent and
> >> confusing
> >> > > behaviour.
> >> > >
> >> > I am not sure I understand this..
> >> > If you want 3, you need <xxx value="${1+2}">
> >> > If you want 1+2, you should use <xxx value="1+2">
> >> > Only the expression in ${..} will trigger the calculation, no matter
> if
> >> the
> >> > dependency if available.
> >> >
> >>
> >> Do in the absence of the jexl dependency what does <xxx value="${1+2}">
> >> equal?
> >>
> >> What happens if I want to use a property placeholder keyed off the
> string
> >> value "1+2" when jexl is present?
> >>
> > We should NOT implicitly encourage user use such style as a key of value.
> I
> > don't think it makes any sense. In practice, I did not see any blueprint
> > config file use that.
>
> Why does anyone need jexl to add two numbers together?
>
> >
> >
> > -Rex
> >
> >
> >>
> >>
> >> > -Rex
> >> >
> >> >
> >> > >
> >> > >
> >> > > Adding a namespace for this function elegantly solves both these
> issues
> >> in
> >> > > a way that is consistent with other blueprint extensions, and I
> think
> >> is
> >> > > essential before this function can be released.
> >> > >
> >> > > Regards,
> >> > >
> >> > > Tim
> >> > >
> >> > >
> >> > > > From: rwonly@gmail.com
> >> > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> >> > > > Subject: Re: [Release Discussion] ship maintenance releases of
> >> > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> >> > > > To: dev@aries.apache.org
> >> > > >
> >> > > > I still think adding a new namespace only for such simple
> calculation
> >> is
> >> > > too
> >> > > > heavy and not consumalbe for users..
> >> > > >
> >> > > > Anyway, could anybody help with the release of *
> >> > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> >> > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help
> >> check
> >> > > why
> >> > > > I can not deploy artifacts to apache.snapshot? Maybe I can try
> >> release
> >> > > the 2
> >> > > > components. Geronimo does not have much time targeting the
> 3.0-beta
> >> > > release.
> >> > > >
> >> > > > thanks,
> >> > > >
> >> > > > -Rex
> >> > > >
> >> > > >
> >> > > >
> >> > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> >> > > >
> >> > > > > If we release blueprint as is we will never be able to make the
> >> change
> >> > > as
> >> > > > > we
> >> > > > > would cause a major breaking change. I think we need to get this
> >> right
> >> > > > > before a release is done.
> >> > > > >
> >> > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
> >> > > > >
> >> > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> >> > > > > >
> >> > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> >> > > vmahrwald@googlemail.com
> >> > > > > > > >wrote:
> >> > > > > > >
> >> > > > > > > > Comments inline :)
> >> > > > > > > >
> >> > > > > > > > Kind regards,
> >> > > > > > > >
> >> > > > > > > > Valentin
> >> > > > > > > >
> >> > > > > > > > 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).
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > > The blueprint specification says any non-standard extensions
> to
> >> > > > > blueprint
> >> > > > > > > must be enabled via namespace handlers. I don't like the ext
> of
> >> cm
> >> > > > > > > namespaces to require apache-jexl since it means more
> >> dependencies
> >> > > are
> >> > > > > > > pulled in when they may never be used.
> >> > > > > > >
> >> > > > > > Hi Alasdair,
> >> > > > > > Since the current code does not hard depend on the
> commons-jexl,
> >> and
> >> > > I
> >> > > > > > think
> >> > > > > > the only difference from your desire is adding a new namespace
> >> which
> >> > > can
> >> > > > > > delay the blueprint container initialization if the
> commons-jexl
> >> is
> >> > > not
> >> > > > > > present,
> >> > > > > > I consider this as an improvement to the current solution. And
> I
> >> > > think it
> >> > > > > > would be better to let user hold the option that if he would
> use
> >> the
> >> > > new
> >> > > > > > namespace, and if he don't use it, the ${a+b} can still work.
> >> Hope
> >> > > the
> >> > > > > > current solution meets the criteria to start release..
> >> > > > > >
> >> > > > > > BTW, seems Aries community is not that active in last two
> month.
> >> Is
> >> > > there
> >> > > > > > still a release manager help the release works?
> >> > > > > >
> >> > > > > > -Rex
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > >
> >> > > > > > > Looking at your options a) doesn't work because it isn't
> using
> >> > > > > namespace
> >> > > > > > > handlers, b) sucks big time and would mean to meat the spec
> we
> >> > > would
> >> > > > > > need
> >> > > > > > > apache-jexl and the whole point is to allow the spec to be
> >> > > implemented
> >> > > > > > > without apache-jexl being required. So I think something
> like
> >> > > option c
> >> > > > > > > should be gone for. For instance you could add an attribute
> in
> >> a
> >> > > > > > > non-standard namespace that says to enable this capability.
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > > Is any of that what you were thinking of?
> >> > > > > > > >
> >> > > > > > > > > Does that make any sense?
> >> > > > > > > > >
> >> > > > > > > > > Alasdair
> >> > > > > > > > >
> >> > > > > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com>
> >> 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 <no...@apache.org>
> >> > > > > > > > >>
> >> > > > > > > > >>> 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 <rw...@gmail.com>
> >> 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 apache.org
> >> > > > > > > > >>>
> >> > > > > > > > >>
> >> > > > > > > > >>
> >> > > > > > > > >>
> >> > > > > > > > >> --
> >> > > > > > > > >> Lei Wang (Rex)
> >> > > > > > > > >> rwonly AT apache.org
> >> > > > > > > > >>
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > >
> >> > > > > > > > > --
> >> > > > > > > > > Alasdair Nottingham
> >> > > > > > > > > not@apache.org
> >> > > > > > > >
> >> > > > > > > >
> >> > > > > > >
> >> > > > > > >
> >> > > > > > > --
> >> > > > > > > Alasdair Nottingham
> >> > > > > > > not@apache.org
> >> > > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > >
> >> > > > > > --
> >> > > > > > Lei Wang (Rex)
> >> > > > > > rwonly AT apache.org
> >> > > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > --
> >> > > > > Alasdair Nottingham
> >> > > > > not@apache.org
> >> > > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Lei Wang (Rex)
> >> > > > rwonly AT apache.org
> >> > >
> >> > >
> >> >
> >> >
> >> >
> >> > --
> >> > Lei Wang (Rex)
> >> > rwonly AT apache.org
> >>
> >>
> >
> >
> >
> > --
> > Lei Wang (Rex)
> > rwonly AT apache.org
> >
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Jeremy Hughes <hu...@apache.org>.
On 8 September 2011 14:18, Rex Wang <rw...@gmail.com> wrote:
> 2011/9/8 Timothy Ward <ti...@apache.org>
>
>>
>> Hi,
>>
>> comments in line
>>
>> > From: rwonly@gmail.com
>> > Date: Thu, 8 Sep 2011 17:10:54 +0800
>> > Subject: Re: [Release Discussion] ship maintenance releases of
>> application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
>> > To: dev@aries.apache.org
>> >
>> > 2011/9/8 Timothy Ward <ti...@apache.org>
>> >
>> > >
>> > > Hi,
>> > >
>> > > I'm afraid I've not been paying as much attention as I should to this
>> > > thread. Reading back over the issues. I would currently vote -1 on this
>> > > release. I am not at all happy with the fact that users of this support
>> will
>> > > see different, potentially erroneous, behaviour depending on the
>> presence or
>> > > absence of an optional dependency. Our previous statement has always
>> been
>> > > "If a blueprint bundle wants to use some non-standard function it
>> should
>> > > declare that using an additional namespace".
>> > >
>> > Do you mean the statement in spec 121.4:
>> > "The Blueprint XML resources in a bundle are the definitions. Each
>> > definition can include multiple
>> > namespaces. Implementations of the Blueprint core namespace must strictly
>> > follow this specification,
>> > if they add additional behavior they must add additional namespaces that
>> are
>> > actually used in
>> > the definitions to signal the deviation from this specification."?
>> >
>> > We are improving the blueprint-ext, which has been already an additional
>> > namespace to blueprint core schema. Why must we add a new namespace to
>> > extend the ability of blueprint-ext?
>> >
>> >
>> > > In my view this new function should only be available if the optional
>> > > dependency is satisfied, and blueprint bundles must enable this
>> function
>> > > using a custom namespace. Otherwise I see two problems.
>> > >
>> > >
>> > > I want this new support, but have no way to ensure it is present, as a
>> > > result I am sometimes injected with "1+2" instead of "3". This leads to
>> > > intermittent NumberFormatExceptions
>> > >
>> > I do not want this new support, but as the dependency is available I am
>> > > injected with "3" instead of "1+2". This leads to inconsistent and
>> confusing
>> > > behaviour.
>> > >
>> > I am not sure I understand this..
>> > If you want 3, you need <xxx value="${1+2}">
>> > If you want 1+2, you should use <xxx value="1+2">
>> > Only the expression in ${..} will trigger the calculation, no matter if
>> the
>> > dependency if available.
>> >
>>
>> Do in the absence of the jexl dependency what does <xxx value="${1+2}">
>> equal?
>>
>> What happens if I want to use a property placeholder keyed off the string
>> value "1+2" when jexl is present?
>>
> We should NOT implicitly encourage user use such style as a key of value. I
> don't think it makes any sense. In practice, I did not see any blueprint
> config file use that.
Why does anyone need jexl to add two numbers together?
>
>
> -Rex
>
>
>>
>>
>> > -Rex
>> >
>> >
>> > >
>> > >
>> > > Adding a namespace for this function elegantly solves both these issues
>> in
>> > > a way that is consistent with other blueprint extensions, and I think
>> is
>> > > essential before this function can be released.
>> > >
>> > > Regards,
>> > >
>> > > Tim
>> > >
>> > >
>> > > > From: rwonly@gmail.com
>> > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
>> > > > Subject: Re: [Release Discussion] ship maintenance releases of
>> > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
>> > > > To: dev@aries.apache.org
>> > > >
>> > > > I still think adding a new namespace only for such simple calculation
>> is
>> > > too
>> > > > heavy and not consumalbe for users..
>> > > >
>> > > > Anyway, could anybody help with the release of *
>> > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
>> > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help
>> check
>> > > why
>> > > > I can not deploy artifacts to apache.snapshot? Maybe I can try
>> release
>> > > the 2
>> > > > components. Geronimo does not have much time targeting the 3.0-beta
>> > > release.
>> > > >
>> > > > thanks,
>> > > >
>> > > > -Rex
>> > > >
>> > > >
>> > > >
>> > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
>> > > >
>> > > > > If we release blueprint as is we will never be able to make the
>> change
>> > > as
>> > > > > we
>> > > > > would cause a major breaking change. I think we need to get this
>> right
>> > > > > before a release is done.
>> > > > >
>> > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
>> > > > >
>> > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
>> > > > > >
>> > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
>> > > vmahrwald@googlemail.com
>> > > > > > > >wrote:
>> > > > > > >
>> > > > > > > > Comments inline :)
>> > > > > > > >
>> > > > > > > > Kind regards,
>> > > > > > > >
>> > > > > > > > Valentin
>> > > > > > > >
>> > > > > > > > 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).
>> > > > > > > >
>> > > > > > > >
>> > > > > > > The blueprint specification says any non-standard extensions to
>> > > > > blueprint
>> > > > > > > must be enabled via namespace handlers. I don't like the ext of
>> cm
>> > > > > > > namespaces to require apache-jexl since it means more
>> dependencies
>> > > are
>> > > > > > > pulled in when they may never be used.
>> > > > > > >
>> > > > > > Hi Alasdair,
>> > > > > > Since the current code does not hard depend on the commons-jexl,
>> and
>> > > I
>> > > > > > think
>> > > > > > the only difference from your desire is adding a new namespace
>> which
>> > > can
>> > > > > > delay the blueprint container initialization if the commons-jexl
>> is
>> > > not
>> > > > > > present,
>> > > > > > I consider this as an improvement to the current solution. And I
>> > > think it
>> > > > > > would be better to let user hold the option that if he would use
>> the
>> > > new
>> > > > > > namespace, and if he don't use it, the ${a+b} can still work.
>> Hope
>> > > the
>> > > > > > current solution meets the criteria to start release..
>> > > > > >
>> > > > > > BTW, seems Aries community is not that active in last two month.
>> Is
>> > > there
>> > > > > > still a release manager help the release works?
>> > > > > >
>> > > > > > -Rex
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > >
>> > > > > > > Looking at your options a) doesn't work because it isn't using
>> > > > > namespace
>> > > > > > > handlers, b) sucks big time and would mean to meat the spec we
>> > > would
>> > > > > > need
>> > > > > > > apache-jexl and the whole point is to allow the spec to be
>> > > implemented
>> > > > > > > without apache-jexl being required. So I think something like
>> > > option c
>> > > > > > > should be gone for. For instance you could add an attribute in
>> a
>> > > > > > > non-standard namespace that says to enable this capability.
>> > > > > > >
>> > > > > > >
>> > > > > > > > Is any of that what you were thinking of?
>> > > > > > > >
>> > > > > > > > > Does that make any sense?
>> > > > > > > > >
>> > > > > > > > > Alasdair
>> > > > > > > > >
>> > > > > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com>
>> 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 <no...@apache.org>
>> > > > > > > > >>
>> > > > > > > > >>> 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 <rw...@gmail.com>
>> 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 apache.org
>> > > > > > > > >>>
>> > > > > > > > >>
>> > > > > > > > >>
>> > > > > > > > >>
>> > > > > > > > >> --
>> > > > > > > > >> Lei Wang (Rex)
>> > > > > > > > >> rwonly AT apache.org
>> > > > > > > > >>
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > --
>> > > > > > > > > Alasdair Nottingham
>> > > > > > > > > not@apache.org
>> > > > > > > >
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Alasdair Nottingham
>> > > > > > > not@apache.org
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Lei Wang (Rex)
>> > > > > > rwonly AT apache.org
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Alasdair Nottingham
>> > > > > not@apache.org
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Lei Wang (Rex)
>> > > > rwonly AT apache.org
>> > >
>> > >
>> >
>> >
>> >
>> > --
>> > Lei Wang (Rex)
>> > rwonly AT apache.org
>>
>>
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
2011/9/8 Timothy Ward <ti...@apache.org>
>
> Hi,
>
> comments in line
>
> > From: rwonly@gmail.com
> > Date: Thu, 8 Sep 2011 17:10:54 +0800
> > Subject: Re: [Release Discussion] ship maintenance releases of
> application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > To: dev@aries.apache.org
> >
> > 2011/9/8 Timothy Ward <ti...@apache.org>
> >
> > >
> > > Hi,
> > >
> > > I'm afraid I've not been paying as much attention as I should to this
> > > thread. Reading back over the issues. I would currently vote -1 on this
> > > release. I am not at all happy with the fact that users of this support
> will
> > > see different, potentially erroneous, behaviour depending on the
> presence or
> > > absence of an optional dependency. Our previous statement has always
> been
> > > "If a blueprint bundle wants to use some non-standard function it
> should
> > > declare that using an additional namespace".
> > >
> > Do you mean the statement in spec 121.4:
> > "The Blueprint XML resources in a bundle are the definitions. Each
> > definition can include multiple
> > namespaces. Implementations of the Blueprint core namespace must strictly
> > follow this specification,
> > if they add additional behavior they must add additional namespaces that
> are
> > actually used in
> > the definitions to signal the deviation from this specification."?
> >
> > We are improving the blueprint-ext, which has been already an additional
> > namespace to blueprint core schema. Why must we add a new namespace to
> > extend the ability of blueprint-ext?
> >
> >
> > > In my view this new function should only be available if the optional
> > > dependency is satisfied, and blueprint bundles must enable this
> function
> > > using a custom namespace. Otherwise I see two problems.
> > >
> > >
> > > I want this new support, but have no way to ensure it is present, as a
> > > result I am sometimes injected with "1+2" instead of "3". This leads to
> > > intermittent NumberFormatExceptions
> > >
> > I do not want this new support, but as the dependency is available I am
> > > injected with "3" instead of "1+2". This leads to inconsistent and
> confusing
> > > behaviour.
> > >
> > I am not sure I understand this..
> > If you want 3, you need <xxx value="${1+2}">
> > If you want 1+2, you should use <xxx value="1+2">
> > Only the expression in ${..} will trigger the calculation, no matter if
> the
> > dependency if available.
> >
>
> Do in the absence of the jexl dependency what does <xxx value="${1+2}">
> equal?
>
> What happens if I want to use a property placeholder keyed off the string
> value "1+2" when jexl is present?
>
We should NOT implicitly encourage user use such style as a key of value. I
don't think it makes any sense. In practice, I did not see any blueprint
config file use that.
-Rex
>
>
> > -Rex
> >
> >
> > >
> > >
> > > Adding a namespace for this function elegantly solves both these issues
> in
> > > a way that is consistent with other blueprint extensions, and I think
> is
> > > essential before this function can be released.
> > >
> > > Regards,
> > >
> > > Tim
> > >
> > >
> > > > From: rwonly@gmail.com
> > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > > Subject: Re: [Release Discussion] ship maintenance releases of
> > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > To: dev@aries.apache.org
> > > >
> > > > I still think adding a new namespace only for such simple calculation
> is
> > > too
> > > > heavy and not consumalbe for users..
> > > >
> > > > Anyway, could anybody help with the release of *
> > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help
> check
> > > why
> > > > I can not deploy artifacts to apache.snapshot? Maybe I can try
> release
> > > the 2
> > > > components. Geronimo does not have much time targeting the 3.0-beta
> > > release.
> > > >
> > > > thanks,
> > > >
> > > > -Rex
> > > >
> > > >
> > > >
> > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > > >
> > > > > If we release blueprint as is we will never be able to make the
> change
> > > as
> > > > > we
> > > > > would cause a major breaking change. I think we need to get this
> right
> > > > > before a release is done.
> > > > >
> > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
> > > > >
> > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > > >
> > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > > vmahrwald@googlemail.com
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Comments inline :)
> > > > > > > >
> > > > > > > > Kind regards,
> > > > > > > >
> > > > > > > > Valentin
> > > > > > > >
> > > > > > > > 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).
> > > > > > > >
> > > > > > > >
> > > > > > > The blueprint specification says any non-standard extensions to
> > > > > blueprint
> > > > > > > must be enabled via namespace handlers. I don't like the ext of
> cm
> > > > > > > namespaces to require apache-jexl since it means more
> dependencies
> > > are
> > > > > > > pulled in when they may never be used.
> > > > > > >
> > > > > > Hi Alasdair,
> > > > > > Since the current code does not hard depend on the commons-jexl,
> and
> > > I
> > > > > > think
> > > > > > the only difference from your desire is adding a new namespace
> which
> > > can
> > > > > > delay the blueprint container initialization if the commons-jexl
> is
> > > not
> > > > > > present,
> > > > > > I consider this as an improvement to the current solution. And I
> > > think it
> > > > > > would be better to let user hold the option that if he would use
> the
> > > new
> > > > > > namespace, and if he don't use it, the ${a+b} can still work.
> Hope
> > > the
> > > > > > current solution meets the criteria to start release..
> > > > > >
> > > > > > BTW, seems Aries community is not that active in last two month.
> Is
> > > there
> > > > > > still a release manager help the release works?
> > > > > >
> > > > > > -Rex
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Looking at your options a) doesn't work because it isn't using
> > > > > namespace
> > > > > > > handlers, b) sucks big time and would mean to meat the spec we
> > > would
> > > > > > need
> > > > > > > apache-jexl and the whole point is to allow the spec to be
> > > implemented
> > > > > > > without apache-jexl being required. So I think something like
> > > option c
> > > > > > > should be gone for. For instance you could add an attribute in
> a
> > > > > > > non-standard namespace that says to enable this capability.
> > > > > > >
> > > > > > >
> > > > > > > > Is any of that what you were thinking of?
> > > > > > > >
> > > > > > > > > Does that make any sense?
> > > > > > > > >
> > > > > > > > > Alasdair
> > > > > > > > >
> > > > > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com>
> 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 <no...@apache.org>
> > > > > > > > >>
> > > > > > > > >>> 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 <rw...@gmail.com>
> 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 apache.org
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> --
> > > > > > > > >> Lei Wang (Rex)
> > > > > > > > >> rwonly AT apache.org
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Alasdair Nottingham
> > > > > > > > > not@apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Alasdair Nottingham
> > > > > > > not@apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Lei Wang (Rex)
> > > > > > rwonly AT apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alasdair Nottingham
> > > > > not@apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Lei Wang (Rex)
> > > > rwonly AT apache.org
> > >
> > >
> >
> >
> >
> > --
> > Lei Wang (Rex)
> > rwonly AT apache.org
>
>
--
Lei Wang (Rex)
rwonly AT apache.org
RE: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Timothy Ward <ti...@apache.org>.
Hi,
comments in line
> From: rwonly@gmail.com
> Date: Thu, 8 Sep 2011 17:10:54 +0800
> Subject: Re: [Release Discussion] ship maintenance releases of application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> To: dev@aries.apache.org
>
> 2011/9/8 Timothy Ward <ti...@apache.org>
>
> >
> > Hi,
> >
> > I'm afraid I've not been paying as much attention as I should to this
> > thread. Reading back over the issues. I would currently vote -1 on this
> > release. I am not at all happy with the fact that users of this support will
> > see different, potentially erroneous, behaviour depending on the presence or
> > absence of an optional dependency. Our previous statement has always been
> > "If a blueprint bundle wants to use some non-standard function it should
> > declare that using an additional namespace".
> >
> Do you mean the statement in spec 121.4:
> "The Blueprint XML resources in a bundle are the definitions. Each
> definition can include multiple
> namespaces. Implementations of the Blueprint core namespace must strictly
> follow this specification,
> if they add additional behavior they must add additional namespaces that are
> actually used in
> the definitions to signal the deviation from this specification."?
>
> We are improving the blueprint-ext, which has been already an additional
> namespace to blueprint core schema. Why must we add a new namespace to
> extend the ability of blueprint-ext?
>
>
> > In my view this new function should only be available if the optional
> > dependency is satisfied, and blueprint bundles must enable this function
> > using a custom namespace. Otherwise I see two problems.
> >
> >
> > I want this new support, but have no way to ensure it is present, as a
> > result I am sometimes injected with "1+2" instead of "3". This leads to
> > intermittent NumberFormatExceptions
> >
> I do not want this new support, but as the dependency is available I am
> > injected with "3" instead of "1+2". This leads to inconsistent and confusing
> > behaviour.
> >
> I am not sure I understand this..
> If you want 3, you need <xxx value="${1+2}">
> If you want 1+2, you should use <xxx value="1+2">
> Only the expression in ${..} will trigger the calculation, no matter if the
> dependency if available.
>
Do in the absence of the jexl dependency what does <xxx value="${1+2}"> equal?
What happens if I want to use a property placeholder keyed off the string value "1+2" when jexl is present?
> -Rex
>
>
> >
> >
> > Adding a namespace for this function elegantly solves both these issues in
> > a way that is consistent with other blueprint extensions, and I think is
> > essential before this function can be released.
> >
> > Regards,
> >
> > Tim
> >
> >
> > > From: rwonly@gmail.com
> > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > Subject: Re: [Release Discussion] ship maintenance releases of
> > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > To: dev@aries.apache.org
> > >
> > > I still think adding a new namespace only for such simple calculation is
> > too
> > > heavy and not consumalbe for users..
> > >
> > > Anyway, could anybody help with the release of *
> > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help check
> > why
> > > I can not deploy artifacts to apache.snapshot? Maybe I can try release
> > the 2
> > > components. Geronimo does not have much time targeting the 3.0-beta
> > release.
> > >
> > > thanks,
> > >
> > > -Rex
> > >
> > >
> > >
> > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > >
> > > > If we release blueprint as is we will never be able to make the change
> > as
> > > > we
> > > > would cause a major breaking change. I think we need to get this right
> > > > before a release is done.
> > > >
> > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
> > > >
> > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > >
> > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > vmahrwald@googlemail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Comments inline :)
> > > > > > >
> > > > > > > Kind regards,
> > > > > > >
> > > > > > > Valentin
> > > > > > >
> > > > > > > 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).
> > > > > > >
> > > > > > >
> > > > > > The blueprint specification says any non-standard extensions to
> > > > blueprint
> > > > > > must be enabled via namespace handlers. I don't like the ext of cm
> > > > > > namespaces to require apache-jexl since it means more dependencies
> > are
> > > > > > pulled in when they may never be used.
> > > > > >
> > > > > Hi Alasdair,
> > > > > Since the current code does not hard depend on the commons-jexl, and
> > I
> > > > > think
> > > > > the only difference from your desire is adding a new namespace which
> > can
> > > > > delay the blueprint container initialization if the commons-jexl is
> > not
> > > > > present,
> > > > > I consider this as an improvement to the current solution. And I
> > think it
> > > > > would be better to let user hold the option that if he would use the
> > new
> > > > > namespace, and if he don't use it, the ${a+b} can still work. Hope
> > the
> > > > > current solution meets the criteria to start release..
> > > > >
> > > > > BTW, seems Aries community is not that active in last two month. Is
> > there
> > > > > still a release manager help the release works?
> > > > >
> > > > > -Rex
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > Looking at your options a) doesn't work because it isn't using
> > > > namespace
> > > > > > handlers, b) sucks big time and would mean to meat the spec we
> > would
> > > > > need
> > > > > > apache-jexl and the whole point is to allow the spec to be
> > implemented
> > > > > > without apache-jexl being required. So I think something like
> > option c
> > > > > > should be gone for. For instance you could add an attribute in a
> > > > > > non-standard namespace that says to enable this capability.
> > > > > >
> > > > > >
> > > > > > > Is any of that what you were thinking of?
> > > > > > >
> > > > > > > > Does that make any sense?
> > > > > > > >
> > > > > > > > Alasdair
> > > > > > > >
> > > > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com> 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 <no...@apache.org>
> > > > > > > >>
> > > > > > > >>> 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 <rw...@gmail.com> 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 apache.org
> > > > > > > >>>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> --
> > > > > > > >> Lei Wang (Rex)
> > > > > > > >> rwonly AT apache.org
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Alasdair Nottingham
> > > > > > > > not@apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Alasdair Nottingham
> > > > > > not@apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Lei Wang (Rex)
> > > > > rwonly AT apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alasdair Nottingham
> > > > not@apache.org
> > > >
> > >
> > >
> > >
> > > --
> > > Lei Wang (Rex)
> > > rwonly AT apache.org
> >
> >
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Jeremy Hughes <hu...@apache.org>.
Agreed.
I'd prefer a namespace that didn't imply the only implementation was
jexl based. Say using blueprint-eval or blueprint-expr instead of
blueprint-jexl.
Cheers,
Jeremy
On 8 September 2011 23:26, Alasdair Nottingham <no...@apache.org> wrote:
> Hi,
>
> So lets get real with an example to start illustrating my issues. We have a
> release already and the release is used by people, quite a few people. We
> don't know what they are doing. I have written a test. The test uses the
> sample blueprint bundle. It contains the following blueprint xml:
>
> <bean id="bar2" class="org.apache.aries.blueprint.sample.Bar">
>
> <property name="value" value="${a+b}"/>
>
> </bean>
>
> The setValue method takes a String. I have run these tests in two ways. The
> first with jexl and the second without. If jexl isn't installed I get:
>
> ${a+b}
>
> when jexl is installed I get:
>
> 0
>
> Irrespective of how useful this is to people who want the behaviour it is a
> huge problem for those people who do NOT want this behaviour. It is easy to
> say "well don't install jexl then", but consider this. I have written a
> blueprint bundle that expects to have ${a+b} injected. I deploy it in one
> runtime and it works the way I expect. Now I drop it into Geronimo and I get
> 0 instead. So I now need to go back and rewrite my bundle to work in
> geronimo and I have two different bundles for each environment. This is
> wrong.
>
> As said before I think we need this enabled via a namespace handler and an
> attribute. I would require the following to be added to the blueprint
> element:
>
> <blueprint jexl:enable="true" xmlns:jexl="
> http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0"/>
>
> any existing application will then behave consistently irrespective of what
> is installed in the surrounding framework. Even the one I just created. If
> the jexl bundle isn't installed then the jexl namespace handler is not
> installed so the blueprint bundle will not be processed until it is in the
> normal way. The code in question can remain where it is, but it would only
> be enabled if the jexl namespace is configured. Ideally we would be able to
> parameterise the value processing in a pluggable way, but as long as the
> externals are right we can refactor the internals at our leisure.
>
> We are creating a programming model for OSGi here and that means we need to
> get the modularity right. Currently it is not right, not only is the
> modularity wrong but this makes a breaking change to the way a blueprint.xml
> is processed in what is a bug release. Irrespective of how useful this is I
> do not think it is important enough to warrant a breaking change when we can
> make it work without breaking existing bundles.
>
> To address your question of "Do you think it is a good idea to support
> this?" I do think it is a good idea, if I didn't I would have -1ed the
> commit rather than engaged in an email discussion to get it right.
>
> Thanks
> Alasdair
>
> On 8 September 2011 14:35, Rex Wang <rw...@gmail.com> wrote:
>
>> 2011/9/8 Alasdair Nottingham <no...@apache.org>
>>
>> > On 8 September 2011 10:10, Rex Wang <rw...@gmail.com> wrote:
>> >
>> > > 2011/9/8 Timothy Ward <ti...@apache.org>
>> > >
>> > > >
>> > > > Hi,
>> > > >
>> > > > I'm afraid I've not been paying as much attention as I should to this
>> > > > thread. Reading back over the issues. I would currently vote -1 on
>> this
>> > > > release. I am not at all happy with the fact that users of this
>> support
>> > > will
>> > > > see different, potentially erroneous, behaviour depending on the
>> > presence
>> > > or
>> > > > absence of an optional dependency. Our previous statement has always
>> > been
>> > > > "If a blueprint bundle wants to use some non-standard function it
>> > should
>> > > > declare that using an additional namespace".
>> > > >
>> > > Do you mean the statement in spec 121.4:
>> > > "The Blueprint XML resources in a bundle are the definitions. Each
>> > > definition can include multiple
>> > > namespaces. Implementations of the Blueprint core namespace must
>> strictly
>> > > follow this specification,
>> > > if they add additional behavior they must add additional namespaces
>> that
>> > > are
>> > > actually used in
>> > > the definitions to signal the deviation from this specification."?
>> > >
>> > > We are improving the blueprint-ext, which has been already an
>> additional
>> > > namespace to blueprint core schema. Why must we add a new namespace to
>> > > extend the ability of blueprint-ext?
>> > >
>> > >
>> > Blueprint ext is a part of our core implementation. Adding it to
>> > blueprint-ext means that if you want to use ANY part of blueprint ext you
>> > MUST have apache-jexl even if you don't wan to use the ${a+b} syntax.
>> This
>> > is wrong.
>> >
>>
>> Hi Alasdair,
>> The itests passes without adding the commons-jexl bundle now.
>> If you don't have commons-jexl installed, the current code can work as
>> before. Unless you want to use ${a+b}, you need guarantee the commons-jexl
>> is present. Otherwise it will record this exception in logger. I know this
>> is not that convenient, but at least user can know what he need to do to
>> get
>> things right from the log..
>>
>> On the other hand, Java EE EL supports such style of calculation natively,
>> I
>> think we should support it in blueprint-ext directly to keep the consistent
>> of the current development experiences. In other words, if we don't use
>> commons-jexl to implement such ability, instead, we write codes by
>> ourselves
>> to do that. Do you think it is a good idea to support this? After all,
>> there
>> is no spec for blueprint-ext.
>>
>> thanks,
>> -Rex
>>
>>
>>
>>
>>
>>
>>
>> >
>> >
>> > >
>> > > > In my view this new function should only be available if the optional
>> > > > dependency is satisfied, and blueprint bundles must enable this
>> > function
>> > > > using a custom namespace. Otherwise I see two problems.
>> > > >
>> > > >
>> > > > I want this new support, but have no way to ensure it is present, as
>> a
>> > > > result I am sometimes injected with "1+2" instead of "3". This leads
>> to
>> > > > intermittent NumberFormatExceptions
>> > > >
>> > > I do not want this new support, but as the dependency is available I
>> am
>> > > > injected with "3" instead of "1+2". This leads to inconsistent and
>> > > confusing
>> > > > behaviour.
>> > > >
>> > > I am not sure I understand this..
>> > > If you want 3, you need <xxx value="${1+2}">
>> > > If you want 1+2, you should use <xxx value="1+2">
>> > > Only the expression in ${..} will trigger the calculation, no matter if
>> > the
>> > > dependency if available.
>> > >
>> > >
>> > I think tim is saying you want the string literal "${1+2}" not the string
>> > 1+2. With your change if I had ${1+2} I now get 3 rather than ${1+2}.
>> This
>> > is a change in behaviour and should be enabled using a new namespace. Of
>> > course you could just reversion the namespace from v1.x to v2 as a
>> breaking
>> > change, but we would need to support both versions of the schema.
>> >
>> > As with Tim I would currently -1 any release of blueprint 3.2 until this
>> is
>> > addressed.
>> >
>> > Alasdair
>> >
>> > -Rex
>> > >
>> > >
>> > > >
>> > > >
>> > > > Adding a namespace for this function elegantly solves both these
>> issues
>> > > in
>> > > > a way that is consistent with other blueprint extensions, and I think
>> > is
>> > > > essential before this function can be released.
>> > > >
>> > > > Regards,
>> > > >
>> > > > Tim
>> > > >
>> > > >
>> > > > > From: rwonly@gmail.com
>> > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
>> > > > > Subject: Re: [Release Discussion] ship maintenance releases of
>> > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
>> > > > > To: dev@aries.apache.org
>> > > > >
>> > > > > I still think adding a new namespace only for such simple
>> calculation
>> > > is
>> > > > too
>> > > > > heavy and not consumalbe for users..
>> > > > >
>> > > > > Anyway, could anybody help with the release of *
>> > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
>> > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help
>> > > check
>> > > > why
>> > > > > I can not deploy artifacts to apache.snapshot? Maybe I can try
>> > release
>> > > > the 2
>> > > > > components. Geronimo does not have much time targeting the 3.0-beta
>> > > > release.
>> > > > >
>> > > > > thanks,
>> > > > >
>> > > > > -Rex
>> > > > >
>> > > > >
>> > > > >
>> > > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
>> > > > >
>> > > > > > If we release blueprint as is we will never be able to make the
>> > > change
>> > > > as
>> > > > > > we
>> > > > > > would cause a major breaking change. I think we need to get this
>> > > right
>> > > > > > before a release is done.
>> > > > > >
>> > > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
>> > > > > >
>> > > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
>> > > > > > >
>> > > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
>> > > > vmahrwald@googlemail.com
>> > > > > > > > >wrote:
>> > > > > > > >
>> > > > > > > > > Comments inline :)
>> > > > > > > > >
>> > > > > > > > > Kind regards,
>> > > > > > > > >
>> > > > > > > > > Valentin
>> > > > > > > > >
>> > > > > > > > > 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).
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > The blueprint specification says any non-standard extensions
>> to
>> > > > > > blueprint
>> > > > > > > > must be enabled via namespace handlers. I don't like the ext
>> of
>> > > cm
>> > > > > > > > namespaces to require apache-jexl since it means more
>> > > dependencies
>> > > > are
>> > > > > > > > pulled in when they may never be used.
>> > > > > > > >
>> > > > > > > Hi Alasdair,
>> > > > > > > Since the current code does not hard depend on the
>> commons-jexl,
>> > > and
>> > > > I
>> > > > > > > think
>> > > > > > > the only difference from your desire is adding a new namespace
>> > > which
>> > > > can
>> > > > > > > delay the blueprint container initialization if the
>> commons-jexl
>> > is
>> > > > not
>> > > > > > > present,
>> > > > > > > I consider this as an improvement to the current solution. And
>> I
>> > > > think it
>> > > > > > > would be better to let user hold the option that if he would
>> use
>> > > the
>> > > > new
>> > > > > > > namespace, and if he don't use it, the ${a+b} can still work.
>> > Hope
>> > > > the
>> > > > > > > current solution meets the criteria to start release..
>> > > > > > >
>> > > > > > > BTW, seems Aries community is not that active in last two
>> month.
>> > Is
>> > > > there
>> > > > > > > still a release manager help the release works?
>> > > > > > >
>> > > > > > > -Rex
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > >
>> > > > > > > > Looking at your options a) doesn't work because it isn't
>> using
>> > > > > > namespace
>> > > > > > > > handlers, b) sucks big time and would mean to meat the spec
>> we
>> > > > would
>> > > > > > > need
>> > > > > > > > apache-jexl and the whole point is to allow the spec to be
>> > > > implemented
>> > > > > > > > without apache-jexl being required. So I think something
>> like
>> > > > option c
>> > > > > > > > should be gone for. For instance you could add an attribute
>> in
>> > a
>> > > > > > > > non-standard namespace that says to enable this capability.
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > > Is any of that what you were thinking of?
>> > > > > > > > >
>> > > > > > > > > > Does that make any sense?
>> > > > > > > > > >
>> > > > > > > > > > Alasdair
>> > > > > > > > > >
>> > > > > > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com>
>> > 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 <no...@apache.org>
>> > > > > > > > > >>
>> > > > > > > > > >>> 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 <rw...@gmail.com>
>> > > 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 apache.org
>> > > > > > > > > >>>
>> > > > > > > > > >>
>> > > > > > > > > >>
>> > > > > > > > > >>
>> > > > > > > > > >> --
>> > > > > > > > > >> Lei Wang (Rex)
>> > > > > > > > > >> rwonly AT apache.org
>> > > > > > > > > >>
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > --
>> > > > > > > > > > Alasdair Nottingham
>> > > > > > > > > > not@apache.org
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > > Alasdair Nottingham
>> > > > > > > > not@apache.org
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Lei Wang (Rex)
>> > > > > > > rwonly AT apache.org
>> > > > > > >
>> > > > > >
>> > > > > >
>> > > > > >
>> > > > > > --
>> > > > > > Alasdair Nottingham
>> > > > > > not@apache.org
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Lei Wang (Rex)
>> > > > > rwonly AT apache.org
>> > > >
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Lei Wang (Rex)
>> > > rwonly AT apache.org
>> > >
>> >
>> >
>> >
>> > --
>> > Alasdair Nottingham
>> > not@apache.org
>> >
>>
>>
>>
>> --
>> Lei Wang (Rex)
>> rwonly AT apache.org
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
Exactly. Thanks very much for the investigation and inputs!
BTW, If no objections, I volunteer to be the release manager of
application-0.2.2 and util-0.2.1
You will see the vote soon :-)
-Rex
2011/9/14 Alasdair Nottingham <no...@apache.org>
> Hi,
>
> The jexl module implements javax.el capability from Java EE. The syntax is
> much more expressive than just +. It is documented here:
> http://java.sun.com/products/jsp/syntax/2.0/syntaxref207.html
>
> Looking at the syntax if we enabled el evaluation by default we would need
> to ban a lot more than just a + from a property name. The one that worries
> me the most is having to ban the - character. Based on my past usage of
> properties files I think it is quite likely that people will use - in their
> property names. To me this suggests we should not do this by default even
> more.
>
> Alasdair
>
> On 14 September 2011 11:41, Guillaume Nodet <gn...@gmail.com> wrote:
>
> > On Wed, Sep 14, 2011 at 12:34, Alasdair Nottingham <no...@apache.org>
> wrote:
> >
> > > Hi,
> > >
> > > There are several aspects to why not, all of which make enabling it by
> > > default not really simple. The aspects are:
> > >
> > > 1. Our blueprint implementation has a small number of dependencies.
> > > People like this.
> > > 2. Someone using blueprint ext to do field injection should not be
> > > required to have jexl.
> > >
> >
> > Btw, can't we just do a very simple parsing without relying on jexl ?
> > If the only goal is to support a+b, relying on a 200 ko jar might be a
> bit
> > too much.
> > Or did I miss something and we also need to support more complex
> > expressions
> > and operators ?
> >
> >
> > > 3. Having the way something behaves change based on other bundles in
> > the
> > > framework is bad.
> > > 4. Breaking existing applications in a bug fix release is bad.
> > >
> > > The first requirement says jexl should be optional and not required by
> > > blueprint. The second says we should register ext irrespective of jexl.
> I
> > > think we all agree on these.
> > >
> > > The 3rd and 4th are probably the sticking points. My first concern is
> > that
> > > the behaviour of blueprint from a programming model perspective MUST be
> > > consistent irrespective of optional dependencies. So the current
> solution
> > > which changes based on the presence of absence of jexl is wrong. I
> think
> > we
> > > agree on this point.
> > >
> > > Where we differ is on point 4. In your view banning a+b as a property
> > name
> > > is acceptable, but to me it is not. We have shipped several releases of
> > > blueprint over the 2 years of aries where a+b is a supported property
> > name.
> > > In my opinion it is, in my view, perverse and wrong to turn around now
> > and
> > > say "no you can't do this". What if we had decided to use a different
> > > evaluation model, one which has a special meaning for the period
> > character.
> > >
> > > The fundamental issue for me is that we have more users of aries
> > blueprint
> > > than we know about and we can't know how people are using it. In my
> > > experience whenever I've said "that is a crazy idea no one would do
> that"
> > > it
> > > turns out that someone, somewhere has done exactly that. The property
> > name
> > > is supposed to be taken from the namespace of properties supported by
> > > ConfigAdmin which, as I understand it, allows a + character in the
> > property
> > > name. I think it would cause a surprise and confusion for us to
> > arbitrarily
> > > limit the namespace of property names.
> > >
> > > For these reasons I think the opt in approach is more appropriate.
> > >
> > > Alasdair
> > >
> > > On 14 September 2011 03:42, Rex Wang <rw...@gmail.com> wrote:
> > >
> > > > 2011/9/13 Alasdair Nottingham <no...@apache.org>
> > > >
> > > > > Hi,
> > > > >
> > > > > While I agree that it would be odd to use ${a+b} notation in the
> way
> > > you
> > > > > describe the fact it works today makes me really unhappy with
> > disabling
> > > > it
> > > > > as a result of this change. I don't think that JSTL and blueprint
> are
> > > > that
> > > > > analogous, so I don't think enabling this by default for everyone
> is
> > > the
> > > > > right way to do.
> > > >
> > > > Hi
> > > > I mean how EL is used in JSTL is similar with this suggestion.
> > > > I agree pluggable evaluator is good, especially for the situation
> > stated
> > > by
> > > > Guillaume. But for the ${a+b}, you are considering an existing
> support
> > > that
> > > > rarely people was using(even maybe no one used). So in practice, I
> did
> > > not
> > > > see any drawbacks to support this by default for everyone. I think
> > simple
> > > > is
> > > > beautiful, and there is no spec for blueprint-ext, why we can not
> > change
> > > > the
> > > > odd behavior support?
> > > >
> > > > -Rex
> > > >
> > > > We should respect the existing support and exploit good
> > > > > modularity to allow this to be plugged in as desired.
> > > > >
> > > > > Alasdair
> > > > >
> > > > > On 13 September 2011 09:32, Rex Wang <rw...@gmail.com> wrote:
> > > > >
> > > > > > Hi Alasdair,
> > > > > >
> > > > > > I am sorry for replying slow because I am on vacation.
> > > > > >
> > > > > > This looks much better than a new namespace to me. Thank you very
> > > much
> > > > > for
> > > > > > thinking a lot on this!
> > > > > > I can accept the new approach. But, IMHO, I think we should
> really
> > > > > "forbid"
> > > > > > user use following style in blueprint-ext :
> > > > > > (1) "a+b" as a key of value. eg: <property name="a+b" value="xxx"
> > />
> > > > > > (2) "${a+b}" as the injection value. eg: <property name="zzz"
> > > > > > value="${a+b}"
> > > > > > /> which expects the string ${a+b} to be injected to zzz.
> > > > > > I think the above two styles are not that useful and always bring
> a
> > > lot
> > > > > of
> > > > > > confusion while programming. And this is also not consistent with
> > the
> > > > > > existing development experiences in JSTL. So, my point of view is
> > not
> > > > > that
> > > > > > we must stick to jexl, I just hope we can support such evaluation
> > > > > natively.
> > > > > >
> > > > > > Anyway, if community decides, I respect.
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > -Rex
> > > > > >
> > > > > > 2011/9/9 Alasdair Nottingham <no...@apache.org>
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I have thought of a possible update we could do that would
> enable
> > > > this
> > > > > > > without a new namespace. I'll outline it here. Make a minor
> > update
> > > to
> > > > > the
> > > > > > > ext schema (making it 1.2.0) so we can do the following:
> > > > > > >
> > > > > > > <property-placeholder evaluator="jexl">
> > > > > > > <default-properties>
> > > > > > > <property name="name" value="value" />
> > > > > > > </default-properties>
> > > > > > > <location>file:///url</ext:location>
> > > > > > > </property-placeholder>
> > > > > > >
> > > > > > > The namespace handler then inserts a synthetic service
> dependency
> > > on
> > > > a
> > > > > > > service of type PropertyProcessor with the service property
> > > > > "type=jexl".
> > > > > > > This means the blueprint container would only be configured
> while
> > > the
> > > > > > > desired processor is available. Then we update the code where
> we
> > do
> > > > the
> > > > > > > processing to use the PropertyProcessor service instead of
> having
> > > it
> > > > > > > hardcoded.
> > > > > > >
> > > > > > > This solves my issues around correct modularity, your issues
> > around
> > > > > > > programming model simplicity, and it would also allow us to
> plug
> > > > other
> > > > > > > processors/evaluators such as groovy in the future very easily.
> > > > > > >
> > > > > > > Thoughts?
> > > > > > > Alasdair
> > > > > > >
> > > > > > > On 9 September 2011 10:39, Timothy Ward <
> timothyjward@apache.org
> > >
> > > > > wrote:
> > > > > > >
> > > > > > > >
> > > > > > > > Alasdair,
> > > > > > > >
> > > > > > > > Thanks for taking the time to write a test that answers my
> > > > question.
> > > > > I
> > > > > > > had
> > > > > > > > a suspicion that this sort of thing would happen. It needs to
> > be
> > > > > > possible
> > > > > > > > for the blueprint bundle to behave consistently whether JEXL
> is
> > > > > > installed
> > > > > > > or
> > > > > > > > not.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Tim
> > > > > > > >
> > > > > > > > > Date: Thu, 8 Sep 2011 23:26:18 +0100
> > > > > > > > > Subject: Re: [Release Discussion] ship maintenance releases
> > of
> > > > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > > > > From: not@apache.org
> > > > > > > > > To: dev@aries.apache.org
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > So lets get real with an example to start illustrating my
> > > issues.
> > > > > We
> > > > > > > have
> > > > > > > > a
> > > > > > > > > release already and the release is used by people, quite a
> > few
> > > > > > people.
> > > > > > > We
> > > > > > > > > don't know what they are doing. I have written a test. The
> > test
> > > > > uses
> > > > > > > the
> > > > > > > > > sample blueprint bundle. It contains the following
> blueprint
> > > xml:
> > > > > > > > >
> > > > > > > > > <bean id="bar2"
> > class="org.apache.aries.blueprint.sample.Bar">
> > > > > > > > >
> > > > > > > > > <property name="value" value="${a+b}"/>
> > > > > > > > >
> > > > > > > > > </bean>
> > > > > > > > >
> > > > > > > > > The setValue method takes a String. I have run these tests
> in
> > > two
> > > > > > ways.
> > > > > > > > The
> > > > > > > > > first with jexl and the second without. If jexl isn't
> > installed
> > > I
> > > > > > get:
> > > > > > > > >
> > > > > > > > > ${a+b}
> > > > > > > > >
> > > > > > > > > when jexl is installed I get:
> > > > > > > > >
> > > > > > > > > 0
> > > > > > > > >
> > > > > > > > > Irrespective of how useful this is to people who want the
> > > > behaviour
> > > > > > it
> > > > > > > is
> > > > > > > > a
> > > > > > > > > huge problem for those people who do NOT want this
> behaviour.
> > > It
> > > > is
> > > > > > > easy
> > > > > > > > to
> > > > > > > > > say "well don't install jexl then", but consider this. I
> have
> > > > > written
> > > > > > a
> > > > > > > > > blueprint bundle that expects to have ${a+b} injected. I
> > > deploy
> > > > it
> > > > > > in
> > > > > > > > one
> > > > > > > > > runtime and it works the way I expect. Now I drop it into
> > > > Geronimo
> > > > > > and
> > > > > > > I
> > > > > > > > get
> > > > > > > > > 0 instead. So I now need to go back and rewrite my bundle
> to
> > > work
> > > > > in
> > > > > > > > > geronimo and I have two different bundles for each
> > environment.
> > > > > This
> > > > > > is
> > > > > > > > > wrong.
> > > > > > > > >
> > > > > > > > > As said before I think we need this enabled via a namespace
> > > > handler
> > > > > > and
> > > > > > > > an
> > > > > > > > > attribute. I would require the following to be added to the
> > > > > blueprint
> > > > > > > > > element:
> > > > > > > > >
> > > > > > > > > <blueprint jexl:enable="true" xmlns:jexl="
> > > > > > > > >
> > http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0
> > > "/>
> > > > > > > > >
> > > > > > > > > any existing application will then behave consistently
> > > > irrespective
> > > > > > of
> > > > > > > > what
> > > > > > > > > is installed in the surrounding framework. Even the one I
> > just
> > > > > > created.
> > > > > > > > If
> > > > > > > > > the jexl bundle isn't installed then the jexl namespace
> > handler
> > > > is
> > > > > > not
> > > > > > > > > installed so the blueprint bundle will not be processed
> until
> > > it
> > > > is
> > > > > > in
> > > > > > > > the
> > > > > > > > > normal way. The code in question can remain where it is,
> but
> > it
> > > > > would
> > > > > > > > only
> > > > > > > > > be enabled if the jexl namespace is configured. Ideally we
> > > would
> > > > be
> > > > > > > able
> > > > > > > > to
> > > > > > > > > parameterise the value processing in a pluggable way, but
> as
> > > long
> > > > > as
> > > > > > > the
> > > > > > > > > externals are right we can refactor the internals at our
> > > leisure.
> > > > > > > > >
> > > > > > > > > We are creating a programming model for OSGi here and that
> > > means
> > > > we
> > > > > > > need
> > > > > > > > to
> > > > > > > > > get the modularity right. Currently it is not right, not
> only
> > > is
> > > > > the
> > > > > > > > > modularity wrong but this makes a breaking change to the
> way
> > a
> > > > > > > > blueprint.xml
> > > > > > > > > is processed in what is a bug release. Irrespective of how
> > > useful
> > > > > > this
> > > > > > > is
> > > > > > > > I
> > > > > > > > > do not think it is important enough to warrant a breaking
> > > change
> > > > > when
> > > > > > > we
> > > > > > > > can
> > > > > > > > > make it work without breaking existing bundles.
> > > > > > > > >
> > > > > > > > > To address your question of "Do you think it is a good idea
> > to
> > > > > > support
> > > > > > > > > this?" I do think it is a good idea, if I didn't I would
> have
> > > > -1ed
> > > > > > the
> > > > > > > > > commit rather than engaged in an email discussion to get it
> > > > right.
> > > > > > > > >
> > > > > > > > > Thanks
> > > > > > > > > Alasdair
> > > > > > > > >
> > > > > > > > > On 8 September 2011 14:35, Rex Wang <rw...@gmail.com>
> > wrote:
> > > > > > > > >
> > > > > > > > > > 2011/9/8 Alasdair Nottingham <no...@apache.org>
> > > > > > > > > >
> > > > > > > > > > > On 8 September 2011 10:10, Rex Wang <rw...@gmail.com>
> > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > 2011/9/8 Timothy Ward <ti...@apache.org>
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Hi,
> > > > > > > > > > > > >
> > > > > > > > > > > > > I'm afraid I've not been paying as much attention
> as
> > I
> > > > > should
> > > > > > > to
> > > > > > > > this
> > > > > > > > > > > > > thread. Reading back over the issues. I would
> > currently
> > > > > vote
> > > > > > -1
> > > > > > > > on
> > > > > > > > > > this
> > > > > > > > > > > > > release. I am not at all happy with the fact that
> > users
> > > > of
> > > > > > this
> > > > > > > > > > support
> > > > > > > > > > > > will
> > > > > > > > > > > > > see different, potentially erroneous, behaviour
> > > depending
> > > > > on
> > > > > > > the
> > > > > > > > > > > presence
> > > > > > > > > > > > or
> > > > > > > > > > > > > absence of an optional dependency. Our previous
> > > statement
> > > > > has
> > > > > > > > always
> > > > > > > > > > > been
> > > > > > > > > > > > > "If a blueprint bundle wants to use some
> non-standard
> > > > > > function
> > > > > > > it
> > > > > > > > > > > should
> > > > > > > > > > > > > declare that using an additional namespace".
> > > > > > > > > > > > >
> > > > > > > > > > > > Do you mean the statement in spec 121.4:
> > > > > > > > > > > > "The Blueprint XML resources in a bundle are the
> > > > definitions.
> > > > > > > Each
> > > > > > > > > > > > definition can include multiple
> > > > > > > > > > > > namespaces. Implementations of the Blueprint core
> > > namespace
> > > > > > must
> > > > > > > > > > strictly
> > > > > > > > > > > > follow this specification,
> > > > > > > > > > > > if they add additional behavior they must add
> > additional
> > > > > > > namespaces
> > > > > > > > > > that
> > > > > > > > > > > > are
> > > > > > > > > > > > actually used in
> > > > > > > > > > > > the definitions to signal the deviation from this
> > > > > > > specification."?
> > > > > > > > > > > >
> > > > > > > > > > > > We are improving the blueprint-ext, which has been
> > > already
> > > > an
> > > > > > > > > > additional
> > > > > > > > > > > > namespace to blueprint core schema. Why must we add a
> > new
> > > > > > > namespace
> > > > > > > > to
> > > > > > > > > > > > extend the ability of blueprint-ext?
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > Blueprint ext is a part of our core implementation.
> > Adding
> > > it
> > > > > to
> > > > > > > > > > > blueprint-ext means that if you want to use ANY part of
> > > > > blueprint
> > > > > > > ext
> > > > > > > > you
> > > > > > > > > > > MUST have apache-jexl even if you don't wan to use the
> > > ${a+b}
> > > > > > > syntax.
> > > > > > > > > > This
> > > > > > > > > > > is wrong.
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hi Alasdair,
> > > > > > > > > > The itests passes without adding the commons-jexl bundle
> > now.
> > > > > > > > > > If you don't have commons-jexl installed, the current
> code
> > > can
> > > > > work
> > > > > > > as
> > > > > > > > > > before. Unless you want to use ${a+b}, you need
> guarantee
> > > the
> > > > > > > > commons-jexl
> > > > > > > > > > is present. Otherwise it will record this exception in
> > > logger.
> > > > I
> > > > > > know
> > > > > > > > this
> > > > > > > > > > is not that convenient, but at least user can know what
> he
> > > need
> > > > > to
> > > > > > do
> > > > > > > > to
> > > > > > > > > > get
> > > > > > > > > > things right from the log..
> > > > > > > > > >
> > > > > > > > > > On the other hand, Java EE EL supports such style of
> > > > calculation
> > > > > > > > natively,
> > > > > > > > > > I
> > > > > > > > > > think we should support it in blueprint-ext directly to
> > keep
> > > > the
> > > > > > > > consistent
> > > > > > > > > > of the current development experiences. In other words,
> if
> > we
> > > > > don't
> > > > > > > use
> > > > > > > > > > commons-jexl to implement such ability, instead, we write
> > > codes
> > > > > by
> > > > > > > > > > ourselves
> > > > > > > > > > to do that. Do you think it is a good idea to support
> this?
> > > > After
> > > > > > > all,
> > > > > > > > > > there
> > > > > > > > > > is no spec for blueprint-ext.
> > > > > > > > > >
> > > > > > > > > > thanks,
> > > > > > > > > > -Rex
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > In my view this new function should only be
> available
> > > if
> > > > > the
> > > > > > > > optional
> > > > > > > > > > > > > dependency is satisfied, and blueprint bundles must
> > > > enable
> > > > > > this
> > > > > > > > > > > function
> > > > > > > > > > > > > using a custom namespace. Otherwise I see two
> > problems.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > I want this new support, but have no way to ensure
> it
> > > is
> > > > > > > present,
> > > > > > > > as
> > > > > > > > > > a
> > > > > > > > > > > > > result I am sometimes injected with "1+2" instead
> of
> > > "3".
> > > > > > This
> > > > > > > > leads
> > > > > > > > > > to
> > > > > > > > > > > > > intermittent NumberFormatExceptions
> > > > > > > > > > > > >
> > > > > > > > > > > > I do not want this new support, but as the
> dependency
> > is
> > > > > > > available
> > > > > > > > I
> > > > > > > > > > am
> > > > > > > > > > > > > injected with "3" instead of "1+2". This leads to
> > > > > > inconsistent
> > > > > > > > and
> > > > > > > > > > > > confusing
> > > > > > > > > > > > > behaviour.
> > > > > > > > > > > > >
> > > > > > > > > > > > I am not sure I understand this..
> > > > > > > > > > > > If you want 3, you need <xxx value="${1+2}">
> > > > > > > > > > > > If you want 1+2, you should use <xxx value="1+2">
> > > > > > > > > > > > Only the expression in ${..} will trigger the
> > > calculation,
> > > > no
> > > > > > > > matter if
> > > > > > > > > > > the
> > > > > > > > > > > > dependency if available.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > I think tim is saying you want the string literal
> > "${1+2}"
> > > > not
> > > > > > the
> > > > > > > > string
> > > > > > > > > > > 1+2. With your change if I had ${1+2} I now get 3
> rather
> > > than
> > > > > > > ${1+2}.
> > > > > > > > > > This
> > > > > > > > > > > is a change in behaviour and should be enabled using a
> > new
> > > > > > > namespace.
> > > > > > > > Of
> > > > > > > > > > > course you could just reversion the namespace from v1.x
> > to
> > > v2
> > > > > as
> > > > > > a
> > > > > > > > > > breaking
> > > > > > > > > > > change, but we would need to support both versions of
> the
> > > > > schema.
> > > > > > > > > > >
> > > > > > > > > > > As with Tim I would currently -1 any release of
> blueprint
> > > 3.2
> > > > > > until
> > > > > > > > this
> > > > > > > > > > is
> > > > > > > > > > > addressed.
> > > > > > > > > > >
> > > > > > > > > > > Alasdair
> > > > > > > > > > >
> > > > > > > > > > > -Rex
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Adding a namespace for this function elegantly
> solves
> > > > both
> > > > > > > these
> > > > > > > > > > issues
> > > > > > > > > > > > in
> > > > > > > > > > > > > a way that is consistent with other blueprint
> > > extensions,
> > > > > and
> > > > > > I
> > > > > > > > think
> > > > > > > > > > > is
> > > > > > > > > > > > > essential before this function can be released.
> > > > > > > > > > > > >
> > > > > > > > > > > > > Regards,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Tim
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > From: rwonly@gmail.com
> > > > > > > > > > > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > > > > > > > > > > > > Subject: Re: [Release Discussion] ship
> maintenance
> > > > > releases
> > > > > > > of
> > > > > > > > > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > > > > > > > > > To: dev@aries.apache.org
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > I still think adding a new namespace only for
> such
> > > > simple
> > > > > > > > > > calculation
> > > > > > > > > > > > is
> > > > > > > > > > > > > too
> > > > > > > > > > > > > > heavy and not consumalbe for users..
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Anyway, could anybody help with the release of *
> > > > > > > > > > > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > > > > > > > > > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or
> > > chould
> > > > > > anyone
> > > > > > > > help
> > > > > > > > > > > > check
> > > > > > > > > > > > > why
> > > > > > > > > > > > > > I can not deploy artifacts to apache.snapshot?
> > Maybe
> > > I
> > > > > can
> > > > > > > try
> > > > > > > > > > > release
> > > > > > > > > > > > > the 2
> > > > > > > > > > > > > > components. Geronimo does not have much time
> > > targeting
> > > > > the
> > > > > > > > 3.0-beta
> > > > > > > > > > > > > release.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > thanks,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -Rex
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > If we release blueprint as is we will never be
> > able
> > > > to
> > > > > > make
> > > > > > > > the
> > > > > > > > > > > > change
> > > > > > > > > > > > > as
> > > > > > > > > > > > > > > we
> > > > > > > > > > > > > > > would cause a major breaking change. I think we
> > > need
> > > > to
> > > > > > get
> > > > > > > > this
> > > > > > > > > > > > right
> > > > > > > > > > > > > > > before a release is done.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 6 September 2011 04:37, Rex Wang <
> > > > rwonly@gmail.com>
> > > > > > > > wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 2011/9/6 Alasdair Nottingham <not@apache.org
> >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On 1 September 2011 07:41, Valentin
> Mahrwald
> > <
> > > > > > > > > > > > > vmahrwald@googlemail.com
> > > > > > > > > > > > > > > > > >wrote:
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Comments inline :)
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Kind regards,
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Valentin
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > 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).
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > The blueprint specification says any
> > > non-standard
> > > > > > > > extensions
> > > > > > > > > > to
> > > > > > > > > > > > > > > blueprint
> > > > > > > > > > > > > > > > > must be enabled via namespace handlers. I
> > don't
> > > > > like
> > > > > > > the
> > > > > > > > ext
> > > > > > > > > > of
> > > > > > > > > > > > cm
> > > > > > > > > > > > > > > > > namespaces to require apache-jexl since it
> > > means
> > > > > more
> > > > > > > > > > > > dependencies
> > > > > > > > > > > > > are
> > > > > > > > > > > > > > > > > pulled in when they may never be used.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Hi Alasdair,
> > > > > > > > > > > > > > > > Since the current code does not hard depend
> on
> > > the
> > > > > > > > > > commons-jexl,
> > > > > > > > > > > > and
> > > > > > > > > > > > > I
> > > > > > > > > > > > > > > > think
> > > > > > > > > > > > > > > > the only difference from your desire is
> adding
> > a
> > > > new
> > > > > > > > namespace
> > > > > > > > > > > > which
> > > > > > > > > > > > > can
> > > > > > > > > > > > > > > > delay the blueprint container initialization
> if
> > > the
> > > > > > > > > > commons-jexl
> > > > > > > > > > > is
> > > > > > > > > > > > > not
> > > > > > > > > > > > > > > > present,
> > > > > > > > > > > > > > > > I consider this as an improvement to the
> > current
> > > > > > > solution.
> > > > > > > > And
> > > > > > > > > > I
> > > > > > > > > > > > > think it
> > > > > > > > > > > > > > > > would be better to let user hold the option
> > that
> > > if
> > > > > he
> > > > > > > > would
> > > > > > > > > > use
> > > > > > > > > > > > the
> > > > > > > > > > > > > new
> > > > > > > > > > > > > > > > namespace, and if he don't use it, the ${a+b}
> > can
> > > > > still
> > > > > > > > work.
> > > > > > > > > > > Hope
> > > > > > > > > > > > > the
> > > > > > > > > > > > > > > > current solution meets the criteria to start
> > > > > release..
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > BTW, seems Aries community is not that active
> > in
> > > > last
> > > > > > two
> > > > > > > > > > month.
> > > > > > > > > > > Is
> > > > > > > > > > > > > there
> > > > > > > > > > > > > > > > still a release manager help the release
> works?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > -Rex
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Looking at your options a) doesn't work
> > because
> > > > it
> > > > > > > isn't
> > > > > > > > > > using
> > > > > > > > > > > > > > > namespace
> > > > > > > > > > > > > > > > > handlers, b) sucks big time and would mean
> to
> > > > meat
> > > > > > the
> > > > > > > > spec
> > > > > > > > > > we
> > > > > > > > > > > > > would
> > > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > > apache-jexl and the whole point is to allow
> > the
> > > > > spec
> > > > > > to
> > > > > > > > be
> > > > > > > > > > > > > implemented
> > > > > > > > > > > > > > > > > without apache-jexl being required. So I
> > think
> > > > > > > something
> > > > > > > > > > like
> > > > > > > > > > > > > option c
> > > > > > > > > > > > > > > > > should be gone for. For instance you could
> > add
> > > an
> > > > > > > > attribute
> > > > > > > > > > in
> > > > > > > > > > > a
> > > > > > > > > > > > > > > > > non-standard namespace that says to enable
> > this
> > > > > > > > capability.
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Is any of that what you were thinking of?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Does that make any sense?
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > Alasdair
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > On 30 August 2011 07:36, Rex Wang <
> > > > > > > rwonly@gmail.com>
> > > > > > > > > > > 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 <
> > > > not@apache.org
> > > > > >
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >>> 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 <
> > > > > > > > rwonly@gmail.com>
> > > > > > > > > > > > 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 apache.org
> > > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >> --
> > > > > > > > > > > > > > > > > > >> Lei Wang (Rex)
> > > > > > > > > > > > > > > > > > >> rwonly AT apache.org
> > > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > > > > > > > rwonly AT apache.org
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > > > > > rwonly AT apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > > > rwonly AT apache.org
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > not@apache.org
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > rwonly AT apache.org
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Alasdair Nottingham
> > > > > > > > > not@apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Alasdair Nottingham
> > > > > > > not@apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Lei Wang (Rex)
> > > > > > rwonly AT apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alasdair Nottingham
> > > > > not@apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Lei Wang (Rex)
> > > > rwonly AT apache.org
> > > >
> > >
> > >
> > >
> > > --
> > > Alasdair Nottingham
> > > not@apache.org
> > >
> >
> >
> >
> > --
> > ------------------------
> > Guillaume Nodet
> > ------------------------
> > Blog: http://gnodet.blogspot.com/
> > ------------------------
> > Open Source SOA
> > http://fusesource.com
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
The jexl module implements javax.el capability from Java EE. The syntax is
much more expressive than just +. It is documented here:
http://java.sun.com/products/jsp/syntax/2.0/syntaxref207.html
Looking at the syntax if we enabled el evaluation by default we would need
to ban a lot more than just a + from a property name. The one that worries
me the most is having to ban the - character. Based on my past usage of
properties files I think it is quite likely that people will use - in their
property names. To me this suggests we should not do this by default even
more.
Alasdair
On 14 September 2011 11:41, Guillaume Nodet <gn...@gmail.com> wrote:
> On Wed, Sep 14, 2011 at 12:34, Alasdair Nottingham <no...@apache.org> wrote:
>
> > Hi,
> >
> > There are several aspects to why not, all of which make enabling it by
> > default not really simple. The aspects are:
> >
> > 1. Our blueprint implementation has a small number of dependencies.
> > People like this.
> > 2. Someone using blueprint ext to do field injection should not be
> > required to have jexl.
> >
>
> Btw, can't we just do a very simple parsing without relying on jexl ?
> If the only goal is to support a+b, relying on a 200 ko jar might be a bit
> too much.
> Or did I miss something and we also need to support more complex
> expressions
> and operators ?
>
>
> > 3. Having the way something behaves change based on other bundles in
> the
> > framework is bad.
> > 4. Breaking existing applications in a bug fix release is bad.
> >
> > The first requirement says jexl should be optional and not required by
> > blueprint. The second says we should register ext irrespective of jexl. I
> > think we all agree on these.
> >
> > The 3rd and 4th are probably the sticking points. My first concern is
> that
> > the behaviour of blueprint from a programming model perspective MUST be
> > consistent irrespective of optional dependencies. So the current solution
> > which changes based on the presence of absence of jexl is wrong. I think
> we
> > agree on this point.
> >
> > Where we differ is on point 4. In your view banning a+b as a property
> name
> > is acceptable, but to me it is not. We have shipped several releases of
> > blueprint over the 2 years of aries where a+b is a supported property
> name.
> > In my opinion it is, in my view, perverse and wrong to turn around now
> and
> > say "no you can't do this". What if we had decided to use a different
> > evaluation model, one which has a special meaning for the period
> character.
> >
> > The fundamental issue for me is that we have more users of aries
> blueprint
> > than we know about and we can't know how people are using it. In my
> > experience whenever I've said "that is a crazy idea no one would do that"
> > it
> > turns out that someone, somewhere has done exactly that. The property
> name
> > is supposed to be taken from the namespace of properties supported by
> > ConfigAdmin which, as I understand it, allows a + character in the
> property
> > name. I think it would cause a surprise and confusion for us to
> arbitrarily
> > limit the namespace of property names.
> >
> > For these reasons I think the opt in approach is more appropriate.
> >
> > Alasdair
> >
> > On 14 September 2011 03:42, Rex Wang <rw...@gmail.com> wrote:
> >
> > > 2011/9/13 Alasdair Nottingham <no...@apache.org>
> > >
> > > > Hi,
> > > >
> > > > While I agree that it would be odd to use ${a+b} notation in the way
> > you
> > > > describe the fact it works today makes me really unhappy with
> disabling
> > > it
> > > > as a result of this change. I don't think that JSTL and blueprint are
> > > that
> > > > analogous, so I don't think enabling this by default for everyone is
> > the
> > > > right way to do.
> > >
> > > Hi
> > > I mean how EL is used in JSTL is similar with this suggestion.
> > > I agree pluggable evaluator is good, especially for the situation
> stated
> > by
> > > Guillaume. But for the ${a+b}, you are considering an existing support
> > that
> > > rarely people was using(even maybe no one used). So in practice, I did
> > not
> > > see any drawbacks to support this by default for everyone. I think
> simple
> > > is
> > > beautiful, and there is no spec for blueprint-ext, why we can not
> change
> > > the
> > > odd behavior support?
> > >
> > > -Rex
> > >
> > > We should respect the existing support and exploit good
> > > > modularity to allow this to be plugged in as desired.
> > > >
> > > > Alasdair
> > > >
> > > > On 13 September 2011 09:32, Rex Wang <rw...@gmail.com> wrote:
> > > >
> > > > > Hi Alasdair,
> > > > >
> > > > > I am sorry for replying slow because I am on vacation.
> > > > >
> > > > > This looks much better than a new namespace to me. Thank you very
> > much
> > > > for
> > > > > thinking a lot on this!
> > > > > I can accept the new approach. But, IMHO, I think we should really
> > > > "forbid"
> > > > > user use following style in blueprint-ext :
> > > > > (1) "a+b" as a key of value. eg: <property name="a+b" value="xxx"
> />
> > > > > (2) "${a+b}" as the injection value. eg: <property name="zzz"
> > > > > value="${a+b}"
> > > > > /> which expects the string ${a+b} to be injected to zzz.
> > > > > I think the above two styles are not that useful and always bring a
> > lot
> > > > of
> > > > > confusion while programming. And this is also not consistent with
> the
> > > > > existing development experiences in JSTL. So, my point of view is
> not
> > > > that
> > > > > we must stick to jexl, I just hope we can support such evaluation
> > > > natively.
> > > > >
> > > > > Anyway, if community decides, I respect.
> > > > >
> > > > > thanks,
> > > > >
> > > > > -Rex
> > > > >
> > > > > 2011/9/9 Alasdair Nottingham <no...@apache.org>
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I have thought of a possible update we could do that would enable
> > > this
> > > > > > without a new namespace. I'll outline it here. Make a minor
> update
> > to
> > > > the
> > > > > > ext schema (making it 1.2.0) so we can do the following:
> > > > > >
> > > > > > <property-placeholder evaluator="jexl">
> > > > > > <default-properties>
> > > > > > <property name="name" value="value" />
> > > > > > </default-properties>
> > > > > > <location>file:///url</ext:location>
> > > > > > </property-placeholder>
> > > > > >
> > > > > > The namespace handler then inserts a synthetic service dependency
> > on
> > > a
> > > > > > service of type PropertyProcessor with the service property
> > > > "type=jexl".
> > > > > > This means the blueprint container would only be configured while
> > the
> > > > > > desired processor is available. Then we update the code where we
> do
> > > the
> > > > > > processing to use the PropertyProcessor service instead of having
> > it
> > > > > > hardcoded.
> > > > > >
> > > > > > This solves my issues around correct modularity, your issues
> around
> > > > > > programming model simplicity, and it would also allow us to plug
> > > other
> > > > > > processors/evaluators such as groovy in the future very easily.
> > > > > >
> > > > > > Thoughts?
> > > > > > Alasdair
> > > > > >
> > > > > > On 9 September 2011 10:39, Timothy Ward <timothyjward@apache.org
> >
> > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > Alasdair,
> > > > > > >
> > > > > > > Thanks for taking the time to write a test that answers my
> > > question.
> > > > I
> > > > > > had
> > > > > > > a suspicion that this sort of thing would happen. It needs to
> be
> > > > > possible
> > > > > > > for the blueprint bundle to behave consistently whether JEXL is
> > > > > installed
> > > > > > or
> > > > > > > not.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Tim
> > > > > > >
> > > > > > > > Date: Thu, 8 Sep 2011 23:26:18 +0100
> > > > > > > > Subject: Re: [Release Discussion] ship maintenance releases
> of
> > > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > > > From: not@apache.org
> > > > > > > > To: dev@aries.apache.org
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > So lets get real with an example to start illustrating my
> > issues.
> > > > We
> > > > > > have
> > > > > > > a
> > > > > > > > release already and the release is used by people, quite a
> few
> > > > > people.
> > > > > > We
> > > > > > > > don't know what they are doing. I have written a test. The
> test
> > > > uses
> > > > > > the
> > > > > > > > sample blueprint bundle. It contains the following blueprint
> > xml:
> > > > > > > >
> > > > > > > > <bean id="bar2"
> class="org.apache.aries.blueprint.sample.Bar">
> > > > > > > >
> > > > > > > > <property name="value" value="${a+b}"/>
> > > > > > > >
> > > > > > > > </bean>
> > > > > > > >
> > > > > > > > The setValue method takes a String. I have run these tests in
> > two
> > > > > ways.
> > > > > > > The
> > > > > > > > first with jexl and the second without. If jexl isn't
> installed
> > I
> > > > > get:
> > > > > > > >
> > > > > > > > ${a+b}
> > > > > > > >
> > > > > > > > when jexl is installed I get:
> > > > > > > >
> > > > > > > > 0
> > > > > > > >
> > > > > > > > Irrespective of how useful this is to people who want the
> > > behaviour
> > > > > it
> > > > > > is
> > > > > > > a
> > > > > > > > huge problem for those people who do NOT want this behaviour.
> > It
> > > is
> > > > > > easy
> > > > > > > to
> > > > > > > > say "well don't install jexl then", but consider this. I have
> > > > written
> > > > > a
> > > > > > > > blueprint bundle that expects to have ${a+b} injected. I
> > deploy
> > > it
> > > > > in
> > > > > > > one
> > > > > > > > runtime and it works the way I expect. Now I drop it into
> > > Geronimo
> > > > > and
> > > > > > I
> > > > > > > get
> > > > > > > > 0 instead. So I now need to go back and rewrite my bundle to
> > work
> > > > in
> > > > > > > > geronimo and I have two different bundles for each
> environment.
> > > > This
> > > > > is
> > > > > > > > wrong.
> > > > > > > >
> > > > > > > > As said before I think we need this enabled via a namespace
> > > handler
> > > > > and
> > > > > > > an
> > > > > > > > attribute. I would require the following to be added to the
> > > > blueprint
> > > > > > > > element:
> > > > > > > >
> > > > > > > > <blueprint jexl:enable="true" xmlns:jexl="
> > > > > > > >
> http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0
> > "/>
> > > > > > > >
> > > > > > > > any existing application will then behave consistently
> > > irrespective
> > > > > of
> > > > > > > what
> > > > > > > > is installed in the surrounding framework. Even the one I
> just
> > > > > created.
> > > > > > > If
> > > > > > > > the jexl bundle isn't installed then the jexl namespace
> handler
> > > is
> > > > > not
> > > > > > > > installed so the blueprint bundle will not be processed until
> > it
> > > is
> > > > > in
> > > > > > > the
> > > > > > > > normal way. The code in question can remain where it is, but
> it
> > > > would
> > > > > > > only
> > > > > > > > be enabled if the jexl namespace is configured. Ideally we
> > would
> > > be
> > > > > > able
> > > > > > > to
> > > > > > > > parameterise the value processing in a pluggable way, but as
> > long
> > > > as
> > > > > > the
> > > > > > > > externals are right we can refactor the internals at our
> > leisure.
> > > > > > > >
> > > > > > > > We are creating a programming model for OSGi here and that
> > means
> > > we
> > > > > > need
> > > > > > > to
> > > > > > > > get the modularity right. Currently it is not right, not only
> > is
> > > > the
> > > > > > > > modularity wrong but this makes a breaking change to the way
> a
> > > > > > > blueprint.xml
> > > > > > > > is processed in what is a bug release. Irrespective of how
> > useful
> > > > > this
> > > > > > is
> > > > > > > I
> > > > > > > > do not think it is important enough to warrant a breaking
> > change
> > > > when
> > > > > > we
> > > > > > > can
> > > > > > > > make it work without breaking existing bundles.
> > > > > > > >
> > > > > > > > To address your question of "Do you think it is a good idea
> to
> > > > > support
> > > > > > > > this?" I do think it is a good idea, if I didn't I would have
> > > -1ed
> > > > > the
> > > > > > > > commit rather than engaged in an email discussion to get it
> > > right.
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > > Alasdair
> > > > > > > >
> > > > > > > > On 8 September 2011 14:35, Rex Wang <rw...@gmail.com>
> wrote:
> > > > > > > >
> > > > > > > > > 2011/9/8 Alasdair Nottingham <no...@apache.org>
> > > > > > > > >
> > > > > > > > > > On 8 September 2011 10:10, Rex Wang <rw...@gmail.com>
> > > wrote:
> > > > > > > > > >
> > > > > > > > > > > 2011/9/8 Timothy Ward <ti...@apache.org>
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Hi,
> > > > > > > > > > > >
> > > > > > > > > > > > I'm afraid I've not been paying as much attention as
> I
> > > > should
> > > > > > to
> > > > > > > this
> > > > > > > > > > > > thread. Reading back over the issues. I would
> currently
> > > > vote
> > > > > -1
> > > > > > > on
> > > > > > > > > this
> > > > > > > > > > > > release. I am not at all happy with the fact that
> users
> > > of
> > > > > this
> > > > > > > > > support
> > > > > > > > > > > will
> > > > > > > > > > > > see different, potentially erroneous, behaviour
> > depending
> > > > on
> > > > > > the
> > > > > > > > > > presence
> > > > > > > > > > > or
> > > > > > > > > > > > absence of an optional dependency. Our previous
> > statement
> > > > has
> > > > > > > always
> > > > > > > > > > been
> > > > > > > > > > > > "If a blueprint bundle wants to use some non-standard
> > > > > function
> > > > > > it
> > > > > > > > > > should
> > > > > > > > > > > > declare that using an additional namespace".
> > > > > > > > > > > >
> > > > > > > > > > > Do you mean the statement in spec 121.4:
> > > > > > > > > > > "The Blueprint XML resources in a bundle are the
> > > definitions.
> > > > > > Each
> > > > > > > > > > > definition can include multiple
> > > > > > > > > > > namespaces. Implementations of the Blueprint core
> > namespace
> > > > > must
> > > > > > > > > strictly
> > > > > > > > > > > follow this specification,
> > > > > > > > > > > if they add additional behavior they must add
> additional
> > > > > > namespaces
> > > > > > > > > that
> > > > > > > > > > > are
> > > > > > > > > > > actually used in
> > > > > > > > > > > the definitions to signal the deviation from this
> > > > > > specification."?
> > > > > > > > > > >
> > > > > > > > > > > We are improving the blueprint-ext, which has been
> > already
> > > an
> > > > > > > > > additional
> > > > > > > > > > > namespace to blueprint core schema. Why must we add a
> new
> > > > > > namespace
> > > > > > > to
> > > > > > > > > > > extend the ability of blueprint-ext?
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > Blueprint ext is a part of our core implementation.
> Adding
> > it
> > > > to
> > > > > > > > > > blueprint-ext means that if you want to use ANY part of
> > > > blueprint
> > > > > > ext
> > > > > > > you
> > > > > > > > > > MUST have apache-jexl even if you don't wan to use the
> > ${a+b}
> > > > > > syntax.
> > > > > > > > > This
> > > > > > > > > > is wrong.
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi Alasdair,
> > > > > > > > > The itests passes without adding the commons-jexl bundle
> now.
> > > > > > > > > If you don't have commons-jexl installed, the current code
> > can
> > > > work
> > > > > > as
> > > > > > > > > before. Unless you want to use ${a+b}, you need guarantee
> > the
> > > > > > > commons-jexl
> > > > > > > > > is present. Otherwise it will record this exception in
> > logger.
> > > I
> > > > > know
> > > > > > > this
> > > > > > > > > is not that convenient, but at least user can know what he
> > need
> > > > to
> > > > > do
> > > > > > > to
> > > > > > > > > get
> > > > > > > > > things right from the log..
> > > > > > > > >
> > > > > > > > > On the other hand, Java EE EL supports such style of
> > > calculation
> > > > > > > natively,
> > > > > > > > > I
> > > > > > > > > think we should support it in blueprint-ext directly to
> keep
> > > the
> > > > > > > consistent
> > > > > > > > > of the current development experiences. In other words, if
> we
> > > > don't
> > > > > > use
> > > > > > > > > commons-jexl to implement such ability, instead, we write
> > codes
> > > > by
> > > > > > > > > ourselves
> > > > > > > > > to do that. Do you think it is a good idea to support this?
> > > After
> > > > > > all,
> > > > > > > > > there
> > > > > > > > > is no spec for blueprint-ext.
> > > > > > > > >
> > > > > > > > > thanks,
> > > > > > > > > -Rex
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > In my view this new function should only be available
> > if
> > > > the
> > > > > > > optional
> > > > > > > > > > > > dependency is satisfied, and blueprint bundles must
> > > enable
> > > > > this
> > > > > > > > > > function
> > > > > > > > > > > > using a custom namespace. Otherwise I see two
> problems.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > I want this new support, but have no way to ensure it
> > is
> > > > > > present,
> > > > > > > as
> > > > > > > > > a
> > > > > > > > > > > > result I am sometimes injected with "1+2" instead of
> > "3".
> > > > > This
> > > > > > > leads
> > > > > > > > > to
> > > > > > > > > > > > intermittent NumberFormatExceptions
> > > > > > > > > > > >
> > > > > > > > > > > I do not want this new support, but as the dependency
> is
> > > > > > available
> > > > > > > I
> > > > > > > > > am
> > > > > > > > > > > > injected with "3" instead of "1+2". This leads to
> > > > > inconsistent
> > > > > > > and
> > > > > > > > > > > confusing
> > > > > > > > > > > > behaviour.
> > > > > > > > > > > >
> > > > > > > > > > > I am not sure I understand this..
> > > > > > > > > > > If you want 3, you need <xxx value="${1+2}">
> > > > > > > > > > > If you want 1+2, you should use <xxx value="1+2">
> > > > > > > > > > > Only the expression in ${..} will trigger the
> > calculation,
> > > no
> > > > > > > matter if
> > > > > > > > > > the
> > > > > > > > > > > dependency if available.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > I think tim is saying you want the string literal
> "${1+2}"
> > > not
> > > > > the
> > > > > > > string
> > > > > > > > > > 1+2. With your change if I had ${1+2} I now get 3 rather
> > than
> > > > > > ${1+2}.
> > > > > > > > > This
> > > > > > > > > > is a change in behaviour and should be enabled using a
> new
> > > > > > namespace.
> > > > > > > Of
> > > > > > > > > > course you could just reversion the namespace from v1.x
> to
> > v2
> > > > as
> > > > > a
> > > > > > > > > breaking
> > > > > > > > > > change, but we would need to support both versions of the
> > > > schema.
> > > > > > > > > >
> > > > > > > > > > As with Tim I would currently -1 any release of blueprint
> > 3.2
> > > > > until
> > > > > > > this
> > > > > > > > > is
> > > > > > > > > > addressed.
> > > > > > > > > >
> > > > > > > > > > Alasdair
> > > > > > > > > >
> > > > > > > > > > -Rex
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Adding a namespace for this function elegantly solves
> > > both
> > > > > > these
> > > > > > > > > issues
> > > > > > > > > > > in
> > > > > > > > > > > > a way that is consistent with other blueprint
> > extensions,
> > > > and
> > > > > I
> > > > > > > think
> > > > > > > > > > is
> > > > > > > > > > > > essential before this function can be released.
> > > > > > > > > > > >
> > > > > > > > > > > > Regards,
> > > > > > > > > > > >
> > > > > > > > > > > > Tim
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > From: rwonly@gmail.com
> > > > > > > > > > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > > > > > > > > > > > Subject: Re: [Release Discussion] ship maintenance
> > > > releases
> > > > > > of
> > > > > > > > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > > > > > > > > To: dev@aries.apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > > I still think adding a new namespace only for such
> > > simple
> > > > > > > > > calculation
> > > > > > > > > > > is
> > > > > > > > > > > > too
> > > > > > > > > > > > > heavy and not consumalbe for users..
> > > > > > > > > > > > >
> > > > > > > > > > > > > Anyway, could anybody help with the release of *
> > > > > > > > > > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > > > > > > > > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or
> > chould
> > > > > anyone
> > > > > > > help
> > > > > > > > > > > check
> > > > > > > > > > > > why
> > > > > > > > > > > > > I can not deploy artifacts to apache.snapshot?
> Maybe
> > I
> > > > can
> > > > > > try
> > > > > > > > > > release
> > > > > > > > > > > > the 2
> > > > > > > > > > > > > components. Geronimo does not have much time
> > targeting
> > > > the
> > > > > > > 3.0-beta
> > > > > > > > > > > > release.
> > > > > > > > > > > > >
> > > > > > > > > > > > > thanks,
> > > > > > > > > > > > >
> > > > > > > > > > > > > -Rex
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > > > > > > > > > > > >
> > > > > > > > > > > > > > If we release blueprint as is we will never be
> able
> > > to
> > > > > make
> > > > > > > the
> > > > > > > > > > > change
> > > > > > > > > > > > as
> > > > > > > > > > > > > > we
> > > > > > > > > > > > > > would cause a major breaking change. I think we
> > need
> > > to
> > > > > get
> > > > > > > this
> > > > > > > > > > > right
> > > > > > > > > > > > > > before a release is done.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 6 September 2011 04:37, Rex Wang <
> > > rwonly@gmail.com>
> > > > > > > wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On 1 September 2011 07:41, Valentin Mahrwald
> <
> > > > > > > > > > > > vmahrwald@googlemail.com
> > > > > > > > > > > > > > > > >wrote:
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Comments inline :)
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Kind regards,
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Valentin
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > 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).
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > The blueprint specification says any
> > non-standard
> > > > > > > extensions
> > > > > > > > > to
> > > > > > > > > > > > > > blueprint
> > > > > > > > > > > > > > > > must be enabled via namespace handlers. I
> don't
> > > > like
> > > > > > the
> > > > > > > ext
> > > > > > > > > of
> > > > > > > > > > > cm
> > > > > > > > > > > > > > > > namespaces to require apache-jexl since it
> > means
> > > > more
> > > > > > > > > > > dependencies
> > > > > > > > > > > > are
> > > > > > > > > > > > > > > > pulled in when they may never be used.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Hi Alasdair,
> > > > > > > > > > > > > > > Since the current code does not hard depend on
> > the
> > > > > > > > > commons-jexl,
> > > > > > > > > > > and
> > > > > > > > > > > > I
> > > > > > > > > > > > > > > think
> > > > > > > > > > > > > > > the only difference from your desire is adding
> a
> > > new
> > > > > > > namespace
> > > > > > > > > > > which
> > > > > > > > > > > > can
> > > > > > > > > > > > > > > delay the blueprint container initialization if
> > the
> > > > > > > > > commons-jexl
> > > > > > > > > > is
> > > > > > > > > > > > not
> > > > > > > > > > > > > > > present,
> > > > > > > > > > > > > > > I consider this as an improvement to the
> current
> > > > > > solution.
> > > > > > > And
> > > > > > > > > I
> > > > > > > > > > > > think it
> > > > > > > > > > > > > > > would be better to let user hold the option
> that
> > if
> > > > he
> > > > > > > would
> > > > > > > > > use
> > > > > > > > > > > the
> > > > > > > > > > > > new
> > > > > > > > > > > > > > > namespace, and if he don't use it, the ${a+b}
> can
> > > > still
> > > > > > > work.
> > > > > > > > > > Hope
> > > > > > > > > > > > the
> > > > > > > > > > > > > > > current solution meets the criteria to start
> > > > release..
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > BTW, seems Aries community is not that active
> in
> > > last
> > > > > two
> > > > > > > > > month.
> > > > > > > > > > Is
> > > > > > > > > > > > there
> > > > > > > > > > > > > > > still a release manager help the release works?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > -Rex
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Looking at your options a) doesn't work
> because
> > > it
> > > > > > isn't
> > > > > > > > > using
> > > > > > > > > > > > > > namespace
> > > > > > > > > > > > > > > > handlers, b) sucks big time and would mean to
> > > meat
> > > > > the
> > > > > > > spec
> > > > > > > > > we
> > > > > > > > > > > > would
> > > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > > apache-jexl and the whole point is to allow
> the
> > > > spec
> > > > > to
> > > > > > > be
> > > > > > > > > > > > implemented
> > > > > > > > > > > > > > > > without apache-jexl being required. So I
> think
> > > > > > something
> > > > > > > > > like
> > > > > > > > > > > > option c
> > > > > > > > > > > > > > > > should be gone for. For instance you could
> add
> > an
> > > > > > > attribute
> > > > > > > > > in
> > > > > > > > > > a
> > > > > > > > > > > > > > > > non-standard namespace that says to enable
> this
> > > > > > > capability.
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Is any of that what you were thinking of?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Does that make any sense?
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > Alasdair
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > On 30 August 2011 07:36, Rex Wang <
> > > > > > rwonly@gmail.com>
> > > > > > > > > > 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 <
> > > not@apache.org
> > > > >
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >>> 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 <
> > > > > > > rwonly@gmail.com>
> > > > > > > > > > > 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 apache.org
> > > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >> --
> > > > > > > > > > > > > > > > > >> Lei Wang (Rex)
> > > > > > > > > > > > > > > > > >> rwonly AT apache.org
> > > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > > > > > > rwonly AT apache.org
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > > > > rwonly AT apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > > rwonly AT apache.org
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > not@apache.org
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Lei Wang (Rex)
> > > > > > > > > rwonly AT apache.org
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Alasdair Nottingham
> > > > > > > > not@apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Alasdair Nottingham
> > > > > > not@apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Lei Wang (Rex)
> > > > > rwonly AT apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alasdair Nottingham
> > > > not@apache.org
> > > >
> > >
> > >
> > >
> > > --
> > > Lei Wang (Rex)
> > > rwonly AT apache.org
> > >
> >
> >
> >
> > --
> > Alasdair Nottingham
> > not@apache.org
> >
>
>
>
> --
> ------------------------
> Guillaume Nodet
> ------------------------
> Blog: http://gnodet.blogspot.com/
> ------------------------
> Open Source SOA
> http://fusesource.com
>
--
Alasdair Nottingham
not@apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Guillaume Nodet <gn...@gmail.com>.
On Wed, Sep 14, 2011 at 12:34, Alasdair Nottingham <no...@apache.org> wrote:
> Hi,
>
> There are several aspects to why not, all of which make enabling it by
> default not really simple. The aspects are:
>
> 1. Our blueprint implementation has a small number of dependencies.
> People like this.
> 2. Someone using blueprint ext to do field injection should not be
> required to have jexl.
>
Btw, can't we just do a very simple parsing without relying on jexl ?
If the only goal is to support a+b, relying on a 200 ko jar might be a bit
too much.
Or did I miss something and we also need to support more complex expressions
and operators ?
> 3. Having the way something behaves change based on other bundles in the
> framework is bad.
> 4. Breaking existing applications in a bug fix release is bad.
>
> The first requirement says jexl should be optional and not required by
> blueprint. The second says we should register ext irrespective of jexl. I
> think we all agree on these.
>
> The 3rd and 4th are probably the sticking points. My first concern is that
> the behaviour of blueprint from a programming model perspective MUST be
> consistent irrespective of optional dependencies. So the current solution
> which changes based on the presence of absence of jexl is wrong. I think we
> agree on this point.
>
> Where we differ is on point 4. In your view banning a+b as a property name
> is acceptable, but to me it is not. We have shipped several releases of
> blueprint over the 2 years of aries where a+b is a supported property name.
> In my opinion it is, in my view, perverse and wrong to turn around now and
> say "no you can't do this". What if we had decided to use a different
> evaluation model, one which has a special meaning for the period character.
>
> The fundamental issue for me is that we have more users of aries blueprint
> than we know about and we can't know how people are using it. In my
> experience whenever I've said "that is a crazy idea no one would do that"
> it
> turns out that someone, somewhere has done exactly that. The property name
> is supposed to be taken from the namespace of properties supported by
> ConfigAdmin which, as I understand it, allows a + character in the property
> name. I think it would cause a surprise and confusion for us to arbitrarily
> limit the namespace of property names.
>
> For these reasons I think the opt in approach is more appropriate.
>
> Alasdair
>
> On 14 September 2011 03:42, Rex Wang <rw...@gmail.com> wrote:
>
> > 2011/9/13 Alasdair Nottingham <no...@apache.org>
> >
> > > Hi,
> > >
> > > While I agree that it would be odd to use ${a+b} notation in the way
> you
> > > describe the fact it works today makes me really unhappy with disabling
> > it
> > > as a result of this change. I don't think that JSTL and blueprint are
> > that
> > > analogous, so I don't think enabling this by default for everyone is
> the
> > > right way to do.
> >
> > Hi
> > I mean how EL is used in JSTL is similar with this suggestion.
> > I agree pluggable evaluator is good, especially for the situation stated
> by
> > Guillaume. But for the ${a+b}, you are considering an existing support
> that
> > rarely people was using(even maybe no one used). So in practice, I did
> not
> > see any drawbacks to support this by default for everyone. I think simple
> > is
> > beautiful, and there is no spec for blueprint-ext, why we can not change
> > the
> > odd behavior support?
> >
> > -Rex
> >
> > We should respect the existing support and exploit good
> > > modularity to allow this to be plugged in as desired.
> > >
> > > Alasdair
> > >
> > > On 13 September 2011 09:32, Rex Wang <rw...@gmail.com> wrote:
> > >
> > > > Hi Alasdair,
> > > >
> > > > I am sorry for replying slow because I am on vacation.
> > > >
> > > > This looks much better than a new namespace to me. Thank you very
> much
> > > for
> > > > thinking a lot on this!
> > > > I can accept the new approach. But, IMHO, I think we should really
> > > "forbid"
> > > > user use following style in blueprint-ext :
> > > > (1) "a+b" as a key of value. eg: <property name="a+b" value="xxx" />
> > > > (2) "${a+b}" as the injection value. eg: <property name="zzz"
> > > > value="${a+b}"
> > > > /> which expects the string ${a+b} to be injected to zzz.
> > > > I think the above two styles are not that useful and always bring a
> lot
> > > of
> > > > confusion while programming. And this is also not consistent with the
> > > > existing development experiences in JSTL. So, my point of view is not
> > > that
> > > > we must stick to jexl, I just hope we can support such evaluation
> > > natively.
> > > >
> > > > Anyway, if community decides, I respect.
> > > >
> > > > thanks,
> > > >
> > > > -Rex
> > > >
> > > > 2011/9/9 Alasdair Nottingham <no...@apache.org>
> > > >
> > > > > Hi,
> > > > >
> > > > > I have thought of a possible update we could do that would enable
> > this
> > > > > without a new namespace. I'll outline it here. Make a minor update
> to
> > > the
> > > > > ext schema (making it 1.2.0) so we can do the following:
> > > > >
> > > > > <property-placeholder evaluator="jexl">
> > > > > <default-properties>
> > > > > <property name="name" value="value" />
> > > > > </default-properties>
> > > > > <location>file:///url</ext:location>
> > > > > </property-placeholder>
> > > > >
> > > > > The namespace handler then inserts a synthetic service dependency
> on
> > a
> > > > > service of type PropertyProcessor with the service property
> > > "type=jexl".
> > > > > This means the blueprint container would only be configured while
> the
> > > > > desired processor is available. Then we update the code where we do
> > the
> > > > > processing to use the PropertyProcessor service instead of having
> it
> > > > > hardcoded.
> > > > >
> > > > > This solves my issues around correct modularity, your issues around
> > > > > programming model simplicity, and it would also allow us to plug
> > other
> > > > > processors/evaluators such as groovy in the future very easily.
> > > > >
> > > > > Thoughts?
> > > > > Alasdair
> > > > >
> > > > > On 9 September 2011 10:39, Timothy Ward <ti...@apache.org>
> > > wrote:
> > > > >
> > > > > >
> > > > > > Alasdair,
> > > > > >
> > > > > > Thanks for taking the time to write a test that answers my
> > question.
> > > I
> > > > > had
> > > > > > a suspicion that this sort of thing would happen. It needs to be
> > > > possible
> > > > > > for the blueprint bundle to behave consistently whether JEXL is
> > > > installed
> > > > > or
> > > > > > not.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Tim
> > > > > >
> > > > > > > Date: Thu, 8 Sep 2011 23:26:18 +0100
> > > > > > > Subject: Re: [Release Discussion] ship maintenance releases of
> > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > > From: not@apache.org
> > > > > > > To: dev@aries.apache.org
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > So lets get real with an example to start illustrating my
> issues.
> > > We
> > > > > have
> > > > > > a
> > > > > > > release already and the release is used by people, quite a few
> > > > people.
> > > > > We
> > > > > > > don't know what they are doing. I have written a test. The test
> > > uses
> > > > > the
> > > > > > > sample blueprint bundle. It contains the following blueprint
> xml:
> > > > > > >
> > > > > > > <bean id="bar2" class="org.apache.aries.blueprint.sample.Bar">
> > > > > > >
> > > > > > > <property name="value" value="${a+b}"/>
> > > > > > >
> > > > > > > </bean>
> > > > > > >
> > > > > > > The setValue method takes a String. I have run these tests in
> two
> > > > ways.
> > > > > > The
> > > > > > > first with jexl and the second without. If jexl isn't installed
> I
> > > > get:
> > > > > > >
> > > > > > > ${a+b}
> > > > > > >
> > > > > > > when jexl is installed I get:
> > > > > > >
> > > > > > > 0
> > > > > > >
> > > > > > > Irrespective of how useful this is to people who want the
> > behaviour
> > > > it
> > > > > is
> > > > > > a
> > > > > > > huge problem for those people who do NOT want this behaviour.
> It
> > is
> > > > > easy
> > > > > > to
> > > > > > > say "well don't install jexl then", but consider this. I have
> > > written
> > > > a
> > > > > > > blueprint bundle that expects to have ${a+b} injected. I
> deploy
> > it
> > > > in
> > > > > > one
> > > > > > > runtime and it works the way I expect. Now I drop it into
> > Geronimo
> > > > and
> > > > > I
> > > > > > get
> > > > > > > 0 instead. So I now need to go back and rewrite my bundle to
> work
> > > in
> > > > > > > geronimo and I have two different bundles for each environment.
> > > This
> > > > is
> > > > > > > wrong.
> > > > > > >
> > > > > > > As said before I think we need this enabled via a namespace
> > handler
> > > > and
> > > > > > an
> > > > > > > attribute. I would require the following to be added to the
> > > blueprint
> > > > > > > element:
> > > > > > >
> > > > > > > <blueprint jexl:enable="true" xmlns:jexl="
> > > > > > > http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0
> "/>
> > > > > > >
> > > > > > > any existing application will then behave consistently
> > irrespective
> > > > of
> > > > > > what
> > > > > > > is installed in the surrounding framework. Even the one I just
> > > > created.
> > > > > > If
> > > > > > > the jexl bundle isn't installed then the jexl namespace handler
> > is
> > > > not
> > > > > > > installed so the blueprint bundle will not be processed until
> it
> > is
> > > > in
> > > > > > the
> > > > > > > normal way. The code in question can remain where it is, but it
> > > would
> > > > > > only
> > > > > > > be enabled if the jexl namespace is configured. Ideally we
> would
> > be
> > > > > able
> > > > > > to
> > > > > > > parameterise the value processing in a pluggable way, but as
> long
> > > as
> > > > > the
> > > > > > > externals are right we can refactor the internals at our
> leisure.
> > > > > > >
> > > > > > > We are creating a programming model for OSGi here and that
> means
> > we
> > > > > need
> > > > > > to
> > > > > > > get the modularity right. Currently it is not right, not only
> is
> > > the
> > > > > > > modularity wrong but this makes a breaking change to the way a
> > > > > > blueprint.xml
> > > > > > > is processed in what is a bug release. Irrespective of how
> useful
> > > > this
> > > > > is
> > > > > > I
> > > > > > > do not think it is important enough to warrant a breaking
> change
> > > when
> > > > > we
> > > > > > can
> > > > > > > make it work without breaking existing bundles.
> > > > > > >
> > > > > > > To address your question of "Do you think it is a good idea to
> > > > support
> > > > > > > this?" I do think it is a good idea, if I didn't I would have
> > -1ed
> > > > the
> > > > > > > commit rather than engaged in an email discussion to get it
> > right.
> > > > > > >
> > > > > > > Thanks
> > > > > > > Alasdair
> > > > > > >
> > > > > > > On 8 September 2011 14:35, Rex Wang <rw...@gmail.com> wrote:
> > > > > > >
> > > > > > > > 2011/9/8 Alasdair Nottingham <no...@apache.org>
> > > > > > > >
> > > > > > > > > On 8 September 2011 10:10, Rex Wang <rw...@gmail.com>
> > wrote:
> > > > > > > > >
> > > > > > > > > > 2011/9/8 Timothy Ward <ti...@apache.org>
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Hi,
> > > > > > > > > > >
> > > > > > > > > > > I'm afraid I've not been paying as much attention as I
> > > should
> > > > > to
> > > > > > this
> > > > > > > > > > > thread. Reading back over the issues. I would currently
> > > vote
> > > > -1
> > > > > > on
> > > > > > > > this
> > > > > > > > > > > release. I am not at all happy with the fact that users
> > of
> > > > this
> > > > > > > > support
> > > > > > > > > > will
> > > > > > > > > > > see different, potentially erroneous, behaviour
> depending
> > > on
> > > > > the
> > > > > > > > > presence
> > > > > > > > > > or
> > > > > > > > > > > absence of an optional dependency. Our previous
> statement
> > > has
> > > > > > always
> > > > > > > > > been
> > > > > > > > > > > "If a blueprint bundle wants to use some non-standard
> > > > function
> > > > > it
> > > > > > > > > should
> > > > > > > > > > > declare that using an additional namespace".
> > > > > > > > > > >
> > > > > > > > > > Do you mean the statement in spec 121.4:
> > > > > > > > > > "The Blueprint XML resources in a bundle are the
> > definitions.
> > > > > Each
> > > > > > > > > > definition can include multiple
> > > > > > > > > > namespaces. Implementations of the Blueprint core
> namespace
> > > > must
> > > > > > > > strictly
> > > > > > > > > > follow this specification,
> > > > > > > > > > if they add additional behavior they must add additional
> > > > > namespaces
> > > > > > > > that
> > > > > > > > > > are
> > > > > > > > > > actually used in
> > > > > > > > > > the definitions to signal the deviation from this
> > > > > specification."?
> > > > > > > > > >
> > > > > > > > > > We are improving the blueprint-ext, which has been
> already
> > an
> > > > > > > > additional
> > > > > > > > > > namespace to blueprint core schema. Why must we add a new
> > > > > namespace
> > > > > > to
> > > > > > > > > > extend the ability of blueprint-ext?
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > Blueprint ext is a part of our core implementation. Adding
> it
> > > to
> > > > > > > > > blueprint-ext means that if you want to use ANY part of
> > > blueprint
> > > > > ext
> > > > > > you
> > > > > > > > > MUST have apache-jexl even if you don't wan to use the
> ${a+b}
> > > > > syntax.
> > > > > > > > This
> > > > > > > > > is wrong.
> > > > > > > > >
> > > > > > > >
> > > > > > > > Hi Alasdair,
> > > > > > > > The itests passes without adding the commons-jexl bundle now.
> > > > > > > > If you don't have commons-jexl installed, the current code
> can
> > > work
> > > > > as
> > > > > > > > before. Unless you want to use ${a+b}, you need guarantee
> the
> > > > > > commons-jexl
> > > > > > > > is present. Otherwise it will record this exception in
> logger.
> > I
> > > > know
> > > > > > this
> > > > > > > > is not that convenient, but at least user can know what he
> need
> > > to
> > > > do
> > > > > > to
> > > > > > > > get
> > > > > > > > things right from the log..
> > > > > > > >
> > > > > > > > On the other hand, Java EE EL supports such style of
> > calculation
> > > > > > natively,
> > > > > > > > I
> > > > > > > > think we should support it in blueprint-ext directly to keep
> > the
> > > > > > consistent
> > > > > > > > of the current development experiences. In other words, if we
> > > don't
> > > > > use
> > > > > > > > commons-jexl to implement such ability, instead, we write
> codes
> > > by
> > > > > > > > ourselves
> > > > > > > > to do that. Do you think it is a good idea to support this?
> > After
> > > > > all,
> > > > > > > > there
> > > > > > > > is no spec for blueprint-ext.
> > > > > > > >
> > > > > > > > thanks,
> > > > > > > > -Rex
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > In my view this new function should only be available
> if
> > > the
> > > > > > optional
> > > > > > > > > > > dependency is satisfied, and blueprint bundles must
> > enable
> > > > this
> > > > > > > > > function
> > > > > > > > > > > using a custom namespace. Otherwise I see two problems.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > I want this new support, but have no way to ensure it
> is
> > > > > present,
> > > > > > as
> > > > > > > > a
> > > > > > > > > > > result I am sometimes injected with "1+2" instead of
> "3".
> > > > This
> > > > > > leads
> > > > > > > > to
> > > > > > > > > > > intermittent NumberFormatExceptions
> > > > > > > > > > >
> > > > > > > > > > I do not want this new support, but as the dependency is
> > > > > available
> > > > > > I
> > > > > > > > am
> > > > > > > > > > > injected with "3" instead of "1+2". This leads to
> > > > inconsistent
> > > > > > and
> > > > > > > > > > confusing
> > > > > > > > > > > behaviour.
> > > > > > > > > > >
> > > > > > > > > > I am not sure I understand this..
> > > > > > > > > > If you want 3, you need <xxx value="${1+2}">
> > > > > > > > > > If you want 1+2, you should use <xxx value="1+2">
> > > > > > > > > > Only the expression in ${..} will trigger the
> calculation,
> > no
> > > > > > matter if
> > > > > > > > > the
> > > > > > > > > > dependency if available.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > I think tim is saying you want the string literal "${1+2}"
> > not
> > > > the
> > > > > > string
> > > > > > > > > 1+2. With your change if I had ${1+2} I now get 3 rather
> than
> > > > > ${1+2}.
> > > > > > > > This
> > > > > > > > > is a change in behaviour and should be enabled using a new
> > > > > namespace.
> > > > > > Of
> > > > > > > > > course you could just reversion the namespace from v1.x to
> v2
> > > as
> > > > a
> > > > > > > > breaking
> > > > > > > > > change, but we would need to support both versions of the
> > > schema.
> > > > > > > > >
> > > > > > > > > As with Tim I would currently -1 any release of blueprint
> 3.2
> > > > until
> > > > > > this
> > > > > > > > is
> > > > > > > > > addressed.
> > > > > > > > >
> > > > > > > > > Alasdair
> > > > > > > > >
> > > > > > > > > -Rex
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Adding a namespace for this function elegantly solves
> > both
> > > > > these
> > > > > > > > issues
> > > > > > > > > > in
> > > > > > > > > > > a way that is consistent with other blueprint
> extensions,
> > > and
> > > > I
> > > > > > think
> > > > > > > > > is
> > > > > > > > > > > essential before this function can be released.
> > > > > > > > > > >
> > > > > > > > > > > Regards,
> > > > > > > > > > >
> > > > > > > > > > > Tim
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > From: rwonly@gmail.com
> > > > > > > > > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > > > > > > > > > > Subject: Re: [Release Discussion] ship maintenance
> > > releases
> > > > > of
> > > > > > > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > > > > > > > To: dev@aries.apache.org
> > > > > > > > > > > >
> > > > > > > > > > > > I still think adding a new namespace only for such
> > simple
> > > > > > > > calculation
> > > > > > > > > > is
> > > > > > > > > > > too
> > > > > > > > > > > > heavy and not consumalbe for users..
> > > > > > > > > > > >
> > > > > > > > > > > > Anyway, could anybody help with the release of *
> > > > > > > > > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > > > > > > > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or
> chould
> > > > anyone
> > > > > > help
> > > > > > > > > > check
> > > > > > > > > > > why
> > > > > > > > > > > > I can not deploy artifacts to apache.snapshot? Maybe
> I
> > > can
> > > > > try
> > > > > > > > > release
> > > > > > > > > > > the 2
> > > > > > > > > > > > components. Geronimo does not have much time
> targeting
> > > the
> > > > > > 3.0-beta
> > > > > > > > > > > release.
> > > > > > > > > > > >
> > > > > > > > > > > > thanks,
> > > > > > > > > > > >
> > > > > > > > > > > > -Rex
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > > > > > > > > > > >
> > > > > > > > > > > > > If we release blueprint as is we will never be able
> > to
> > > > make
> > > > > > the
> > > > > > > > > > change
> > > > > > > > > > > as
> > > > > > > > > > > > > we
> > > > > > > > > > > > > would cause a major breaking change. I think we
> need
> > to
> > > > get
> > > > > > this
> > > > > > > > > > right
> > > > > > > > > > > > > before a release is done.
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 6 September 2011 04:37, Rex Wang <
> > rwonly@gmail.com>
> > > > > > wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > > > > > > > > > > vmahrwald@googlemail.com
> > > > > > > > > > > > > > > >wrote:
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Comments inline :)
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Kind regards,
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Valentin
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > 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).
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > The blueprint specification says any
> non-standard
> > > > > > extensions
> > > > > > > > to
> > > > > > > > > > > > > blueprint
> > > > > > > > > > > > > > > must be enabled via namespace handlers. I don't
> > > like
> > > > > the
> > > > > > ext
> > > > > > > > of
> > > > > > > > > > cm
> > > > > > > > > > > > > > > namespaces to require apache-jexl since it
> means
> > > more
> > > > > > > > > > dependencies
> > > > > > > > > > > are
> > > > > > > > > > > > > > > pulled in when they may never be used.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > Hi Alasdair,
> > > > > > > > > > > > > > Since the current code does not hard depend on
> the
> > > > > > > > commons-jexl,
> > > > > > > > > > and
> > > > > > > > > > > I
> > > > > > > > > > > > > > think
> > > > > > > > > > > > > > the only difference from your desire is adding a
> > new
> > > > > > namespace
> > > > > > > > > > which
> > > > > > > > > > > can
> > > > > > > > > > > > > > delay the blueprint container initialization if
> the
> > > > > > > > commons-jexl
> > > > > > > > > is
> > > > > > > > > > > not
> > > > > > > > > > > > > > present,
> > > > > > > > > > > > > > I consider this as an improvement to the current
> > > > > solution.
> > > > > > And
> > > > > > > > I
> > > > > > > > > > > think it
> > > > > > > > > > > > > > would be better to let user hold the option that
> if
> > > he
> > > > > > would
> > > > > > > > use
> > > > > > > > > > the
> > > > > > > > > > > new
> > > > > > > > > > > > > > namespace, and if he don't use it, the ${a+b} can
> > > still
> > > > > > work.
> > > > > > > > > Hope
> > > > > > > > > > > the
> > > > > > > > > > > > > > current solution meets the criteria to start
> > > release..
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > BTW, seems Aries community is not that active in
> > last
> > > > two
> > > > > > > > month.
> > > > > > > > > Is
> > > > > > > > > > > there
> > > > > > > > > > > > > > still a release manager help the release works?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > -Rex
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Looking at your options a) doesn't work because
> > it
> > > > > isn't
> > > > > > > > using
> > > > > > > > > > > > > namespace
> > > > > > > > > > > > > > > handlers, b) sucks big time and would mean to
> > meat
> > > > the
> > > > > > spec
> > > > > > > > we
> > > > > > > > > > > would
> > > > > > > > > > > > > > need
> > > > > > > > > > > > > > > apache-jexl and the whole point is to allow the
> > > spec
> > > > to
> > > > > > be
> > > > > > > > > > > implemented
> > > > > > > > > > > > > > > without apache-jexl being required. So I think
> > > > > something
> > > > > > > > like
> > > > > > > > > > > option c
> > > > > > > > > > > > > > > should be gone for. For instance you could add
> an
> > > > > > attribute
> > > > > > > > in
> > > > > > > > > a
> > > > > > > > > > > > > > > non-standard namespace that says to enable this
> > > > > > capability.
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Is any of that what you were thinking of?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Does that make any sense?
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > Alasdair
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > On 30 August 2011 07:36, Rex Wang <
> > > > > rwonly@gmail.com>
> > > > > > > > > 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 <
> > not@apache.org
> > > >
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >>> 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 <
> > > > > > rwonly@gmail.com>
> > > > > > > > > > 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 apache.org
> > > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >> --
> > > > > > > > > > > > > > > > >> Lei Wang (Rex)
> > > > > > > > > > > > > > > > >> rwonly AT apache.org
> > > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > > > > > rwonly AT apache.org
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > > > rwonly AT apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > rwonly AT apache.org
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Alasdair Nottingham
> > > > > > > > > not@apache.org
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Lei Wang (Rex)
> > > > > > > > rwonly AT apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Alasdair Nottingham
> > > > > > > not@apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alasdair Nottingham
> > > > > not@apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Lei Wang (Rex)
> > > > rwonly AT apache.org
> > > >
> > >
> > >
> > >
> > > --
> > > Alasdair Nottingham
> > > not@apache.org
> > >
> >
> >
> >
> > --
> > Lei Wang (Rex)
> > rwonly AT apache.org
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
There are several aspects to why not, all of which make enabling it by
default not really simple. The aspects are:
1. Our blueprint implementation has a small number of dependencies.
People like this.
2. Someone using blueprint ext to do field injection should not be
required to have jexl.
3. Having the way something behaves change based on other bundles in the
framework is bad.
4. Breaking existing applications in a bug fix release is bad.
The first requirement says jexl should be optional and not required by
blueprint. The second says we should register ext irrespective of jexl. I
think we all agree on these.
The 3rd and 4th are probably the sticking points. My first concern is that
the behaviour of blueprint from a programming model perspective MUST be
consistent irrespective of optional dependencies. So the current solution
which changes based on the presence of absence of jexl is wrong. I think we
agree on this point.
Where we differ is on point 4. In your view banning a+b as a property name
is acceptable, but to me it is not. We have shipped several releases of
blueprint over the 2 years of aries where a+b is a supported property name.
In my opinion it is, in my view, perverse and wrong to turn around now and
say "no you can't do this". What if we had decided to use a different
evaluation model, one which has a special meaning for the period character.
The fundamental issue for me is that we have more users of aries blueprint
than we know about and we can't know how people are using it. In my
experience whenever I've said "that is a crazy idea no one would do that" it
turns out that someone, somewhere has done exactly that. The property name
is supposed to be taken from the namespace of properties supported by
ConfigAdmin which, as I understand it, allows a + character in the property
name. I think it would cause a surprise and confusion for us to arbitrarily
limit the namespace of property names.
For these reasons I think the opt in approach is more appropriate.
Alasdair
On 14 September 2011 03:42, Rex Wang <rw...@gmail.com> wrote:
> 2011/9/13 Alasdair Nottingham <no...@apache.org>
>
> > Hi,
> >
> > While I agree that it would be odd to use ${a+b} notation in the way you
> > describe the fact it works today makes me really unhappy with disabling
> it
> > as a result of this change. I don't think that JSTL and blueprint are
> that
> > analogous, so I don't think enabling this by default for everyone is the
> > right way to do.
>
> Hi
> I mean how EL is used in JSTL is similar with this suggestion.
> I agree pluggable evaluator is good, especially for the situation stated by
> Guillaume. But for the ${a+b}, you are considering an existing support that
> rarely people was using(even maybe no one used). So in practice, I did not
> see any drawbacks to support this by default for everyone. I think simple
> is
> beautiful, and there is no spec for blueprint-ext, why we can not change
> the
> odd behavior support?
>
> -Rex
>
> We should respect the existing support and exploit good
> > modularity to allow this to be plugged in as desired.
> >
> > Alasdair
> >
> > On 13 September 2011 09:32, Rex Wang <rw...@gmail.com> wrote:
> >
> > > Hi Alasdair,
> > >
> > > I am sorry for replying slow because I am on vacation.
> > >
> > > This looks much better than a new namespace to me. Thank you very much
> > for
> > > thinking a lot on this!
> > > I can accept the new approach. But, IMHO, I think we should really
> > "forbid"
> > > user use following style in blueprint-ext :
> > > (1) "a+b" as a key of value. eg: <property name="a+b" value="xxx" />
> > > (2) "${a+b}" as the injection value. eg: <property name="zzz"
> > > value="${a+b}"
> > > /> which expects the string ${a+b} to be injected to zzz.
> > > I think the above two styles are not that useful and always bring a lot
> > of
> > > confusion while programming. And this is also not consistent with the
> > > existing development experiences in JSTL. So, my point of view is not
> > that
> > > we must stick to jexl, I just hope we can support such evaluation
> > natively.
> > >
> > > Anyway, if community decides, I respect.
> > >
> > > thanks,
> > >
> > > -Rex
> > >
> > > 2011/9/9 Alasdair Nottingham <no...@apache.org>
> > >
> > > > Hi,
> > > >
> > > > I have thought of a possible update we could do that would enable
> this
> > > > without a new namespace. I'll outline it here. Make a minor update to
> > the
> > > > ext schema (making it 1.2.0) so we can do the following:
> > > >
> > > > <property-placeholder evaluator="jexl">
> > > > <default-properties>
> > > > <property name="name" value="value" />
> > > > </default-properties>
> > > > <location>file:///url</ext:location>
> > > > </property-placeholder>
> > > >
> > > > The namespace handler then inserts a synthetic service dependency on
> a
> > > > service of type PropertyProcessor with the service property
> > "type=jexl".
> > > > This means the blueprint container would only be configured while the
> > > > desired processor is available. Then we update the code where we do
> the
> > > > processing to use the PropertyProcessor service instead of having it
> > > > hardcoded.
> > > >
> > > > This solves my issues around correct modularity, your issues around
> > > > programming model simplicity, and it would also allow us to plug
> other
> > > > processors/evaluators such as groovy in the future very easily.
> > > >
> > > > Thoughts?
> > > > Alasdair
> > > >
> > > > On 9 September 2011 10:39, Timothy Ward <ti...@apache.org>
> > wrote:
> > > >
> > > > >
> > > > > Alasdair,
> > > > >
> > > > > Thanks for taking the time to write a test that answers my
> question.
> > I
> > > > had
> > > > > a suspicion that this sort of thing would happen. It needs to be
> > > possible
> > > > > for the blueprint bundle to behave consistently whether JEXL is
> > > installed
> > > > or
> > > > > not.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Tim
> > > > >
> > > > > > Date: Thu, 8 Sep 2011 23:26:18 +0100
> > > > > > Subject: Re: [Release Discussion] ship maintenance releases of
> > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > From: not@apache.org
> > > > > > To: dev@aries.apache.org
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > So lets get real with an example to start illustrating my issues.
> > We
> > > > have
> > > > > a
> > > > > > release already and the release is used by people, quite a few
> > > people.
> > > > We
> > > > > > don't know what they are doing. I have written a test. The test
> > uses
> > > > the
> > > > > > sample blueprint bundle. It contains the following blueprint xml:
> > > > > >
> > > > > > <bean id="bar2" class="org.apache.aries.blueprint.sample.Bar">
> > > > > >
> > > > > > <property name="value" value="${a+b}"/>
> > > > > >
> > > > > > </bean>
> > > > > >
> > > > > > The setValue method takes a String. I have run these tests in two
> > > ways.
> > > > > The
> > > > > > first with jexl and the second without. If jexl isn't installed I
> > > get:
> > > > > >
> > > > > > ${a+b}
> > > > > >
> > > > > > when jexl is installed I get:
> > > > > >
> > > > > > 0
> > > > > >
> > > > > > Irrespective of how useful this is to people who want the
> behaviour
> > > it
> > > > is
> > > > > a
> > > > > > huge problem for those people who do NOT want this behaviour. It
> is
> > > > easy
> > > > > to
> > > > > > say "well don't install jexl then", but consider this. I have
> > written
> > > a
> > > > > > blueprint bundle that expects to have ${a+b} injected. I deploy
> it
> > > in
> > > > > one
> > > > > > runtime and it works the way I expect. Now I drop it into
> Geronimo
> > > and
> > > > I
> > > > > get
> > > > > > 0 instead. So I now need to go back and rewrite my bundle to work
> > in
> > > > > > geronimo and I have two different bundles for each environment.
> > This
> > > is
> > > > > > wrong.
> > > > > >
> > > > > > As said before I think we need this enabled via a namespace
> handler
> > > and
> > > > > an
> > > > > > attribute. I would require the following to be added to the
> > blueprint
> > > > > > element:
> > > > > >
> > > > > > <blueprint jexl:enable="true" xmlns:jexl="
> > > > > > http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0"/>
> > > > > >
> > > > > > any existing application will then behave consistently
> irrespective
> > > of
> > > > > what
> > > > > > is installed in the surrounding framework. Even the one I just
> > > created.
> > > > > If
> > > > > > the jexl bundle isn't installed then the jexl namespace handler
> is
> > > not
> > > > > > installed so the blueprint bundle will not be processed until it
> is
> > > in
> > > > > the
> > > > > > normal way. The code in question can remain where it is, but it
> > would
> > > > > only
> > > > > > be enabled if the jexl namespace is configured. Ideally we would
> be
> > > > able
> > > > > to
> > > > > > parameterise the value processing in a pluggable way, but as long
> > as
> > > > the
> > > > > > externals are right we can refactor the internals at our leisure.
> > > > > >
> > > > > > We are creating a programming model for OSGi here and that means
> we
> > > > need
> > > > > to
> > > > > > get the modularity right. Currently it is not right, not only is
> > the
> > > > > > modularity wrong but this makes a breaking change to the way a
> > > > > blueprint.xml
> > > > > > is processed in what is a bug release. Irrespective of how useful
> > > this
> > > > is
> > > > > I
> > > > > > do not think it is important enough to warrant a breaking change
> > when
> > > > we
> > > > > can
> > > > > > make it work without breaking existing bundles.
> > > > > >
> > > > > > To address your question of "Do you think it is a good idea to
> > > support
> > > > > > this?" I do think it is a good idea, if I didn't I would have
> -1ed
> > > the
> > > > > > commit rather than engaged in an email discussion to get it
> right.
> > > > > >
> > > > > > Thanks
> > > > > > Alasdair
> > > > > >
> > > > > > On 8 September 2011 14:35, Rex Wang <rw...@gmail.com> wrote:
> > > > > >
> > > > > > > 2011/9/8 Alasdair Nottingham <no...@apache.org>
> > > > > > >
> > > > > > > > On 8 September 2011 10:10, Rex Wang <rw...@gmail.com>
> wrote:
> > > > > > > >
> > > > > > > > > 2011/9/8 Timothy Ward <ti...@apache.org>
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Hi,
> > > > > > > > > >
> > > > > > > > > > I'm afraid I've not been paying as much attention as I
> > should
> > > > to
> > > > > this
> > > > > > > > > > thread. Reading back over the issues. I would currently
> > vote
> > > -1
> > > > > on
> > > > > > > this
> > > > > > > > > > release. I am not at all happy with the fact that users
> of
> > > this
> > > > > > > support
> > > > > > > > > will
> > > > > > > > > > see different, potentially erroneous, behaviour depending
> > on
> > > > the
> > > > > > > > presence
> > > > > > > > > or
> > > > > > > > > > absence of an optional dependency. Our previous statement
> > has
> > > > > always
> > > > > > > > been
> > > > > > > > > > "If a blueprint bundle wants to use some non-standard
> > > function
> > > > it
> > > > > > > > should
> > > > > > > > > > declare that using an additional namespace".
> > > > > > > > > >
> > > > > > > > > Do you mean the statement in spec 121.4:
> > > > > > > > > "The Blueprint XML resources in a bundle are the
> definitions.
> > > > Each
> > > > > > > > > definition can include multiple
> > > > > > > > > namespaces. Implementations of the Blueprint core namespace
> > > must
> > > > > > > strictly
> > > > > > > > > follow this specification,
> > > > > > > > > if they add additional behavior they must add additional
> > > > namespaces
> > > > > > > that
> > > > > > > > > are
> > > > > > > > > actually used in
> > > > > > > > > the definitions to signal the deviation from this
> > > > specification."?
> > > > > > > > >
> > > > > > > > > We are improving the blueprint-ext, which has been already
> an
> > > > > > > additional
> > > > > > > > > namespace to blueprint core schema. Why must we add a new
> > > > namespace
> > > > > to
> > > > > > > > > extend the ability of blueprint-ext?
> > > > > > > > >
> > > > > > > > >
> > > > > > > > Blueprint ext is a part of our core implementation. Adding it
> > to
> > > > > > > > blueprint-ext means that if you want to use ANY part of
> > blueprint
> > > > ext
> > > > > you
> > > > > > > > MUST have apache-jexl even if you don't wan to use the ${a+b}
> > > > syntax.
> > > > > > > This
> > > > > > > > is wrong.
> > > > > > > >
> > > > > > >
> > > > > > > Hi Alasdair,
> > > > > > > The itests passes without adding the commons-jexl bundle now.
> > > > > > > If you don't have commons-jexl installed, the current code can
> > work
> > > > as
> > > > > > > before. Unless you want to use ${a+b}, you need guarantee the
> > > > > commons-jexl
> > > > > > > is present. Otherwise it will record this exception in logger.
> I
> > > know
> > > > > this
> > > > > > > is not that convenient, but at least user can know what he need
> > to
> > > do
> > > > > to
> > > > > > > get
> > > > > > > things right from the log..
> > > > > > >
> > > > > > > On the other hand, Java EE EL supports such style of
> calculation
> > > > > natively,
> > > > > > > I
> > > > > > > think we should support it in blueprint-ext directly to keep
> the
> > > > > consistent
> > > > > > > of the current development experiences. In other words, if we
> > don't
> > > > use
> > > > > > > commons-jexl to implement such ability, instead, we write codes
> > by
> > > > > > > ourselves
> > > > > > > to do that. Do you think it is a good idea to support this?
> After
> > > > all,
> > > > > > > there
> > > > > > > is no spec for blueprint-ext.
> > > > > > >
> > > > > > > thanks,
> > > > > > > -Rex
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > > In my view this new function should only be available if
> > the
> > > > > optional
> > > > > > > > > > dependency is satisfied, and blueprint bundles must
> enable
> > > this
> > > > > > > > function
> > > > > > > > > > using a custom namespace. Otherwise I see two problems.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > I want this new support, but have no way to ensure it is
> > > > present,
> > > > > as
> > > > > > > a
> > > > > > > > > > result I am sometimes injected with "1+2" instead of "3".
> > > This
> > > > > leads
> > > > > > > to
> > > > > > > > > > intermittent NumberFormatExceptions
> > > > > > > > > >
> > > > > > > > > I do not want this new support, but as the dependency is
> > > > available
> > > > > I
> > > > > > > am
> > > > > > > > > > injected with "3" instead of "1+2". This leads to
> > > inconsistent
> > > > > and
> > > > > > > > > confusing
> > > > > > > > > > behaviour.
> > > > > > > > > >
> > > > > > > > > I am not sure I understand this..
> > > > > > > > > If you want 3, you need <xxx value="${1+2}">
> > > > > > > > > If you want 1+2, you should use <xxx value="1+2">
> > > > > > > > > Only the expression in ${..} will trigger the calculation,
> no
> > > > > matter if
> > > > > > > > the
> > > > > > > > > dependency if available.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > I think tim is saying you want the string literal "${1+2}"
> not
> > > the
> > > > > string
> > > > > > > > 1+2. With your change if I had ${1+2} I now get 3 rather than
> > > > ${1+2}.
> > > > > > > This
> > > > > > > > is a change in behaviour and should be enabled using a new
> > > > namespace.
> > > > > Of
> > > > > > > > course you could just reversion the namespace from v1.x to v2
> > as
> > > a
> > > > > > > breaking
> > > > > > > > change, but we would need to support both versions of the
> > schema.
> > > > > > > >
> > > > > > > > As with Tim I would currently -1 any release of blueprint 3.2
> > > until
> > > > > this
> > > > > > > is
> > > > > > > > addressed.
> > > > > > > >
> > > > > > > > Alasdair
> > > > > > > >
> > > > > > > > -Rex
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Adding a namespace for this function elegantly solves
> both
> > > > these
> > > > > > > issues
> > > > > > > > > in
> > > > > > > > > > a way that is consistent with other blueprint extensions,
> > and
> > > I
> > > > > think
> > > > > > > > is
> > > > > > > > > > essential before this function can be released.
> > > > > > > > > >
> > > > > > > > > > Regards,
> > > > > > > > > >
> > > > > > > > > > Tim
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > From: rwonly@gmail.com
> > > > > > > > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > > > > > > > > > Subject: Re: [Release Discussion] ship maintenance
> > releases
> > > > of
> > > > > > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > > > > > > To: dev@aries.apache.org
> > > > > > > > > > >
> > > > > > > > > > > I still think adding a new namespace only for such
> simple
> > > > > > > calculation
> > > > > > > > > is
> > > > > > > > > > too
> > > > > > > > > > > heavy and not consumalbe for users..
> > > > > > > > > > >
> > > > > > > > > > > Anyway, could anybody help with the release of *
> > > > > > > > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > > > > > > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould
> > > anyone
> > > > > help
> > > > > > > > > check
> > > > > > > > > > why
> > > > > > > > > > > I can not deploy artifacts to apache.snapshot? Maybe I
> > can
> > > > try
> > > > > > > > release
> > > > > > > > > > the 2
> > > > > > > > > > > components. Geronimo does not have much time targeting
> > the
> > > > > 3.0-beta
> > > > > > > > > > release.
> > > > > > > > > > >
> > > > > > > > > > > thanks,
> > > > > > > > > > >
> > > > > > > > > > > -Rex
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > > > > > > > > > >
> > > > > > > > > > > > If we release blueprint as is we will never be able
> to
> > > make
> > > > > the
> > > > > > > > > change
> > > > > > > > > > as
> > > > > > > > > > > > we
> > > > > > > > > > > > would cause a major breaking change. I think we need
> to
> > > get
> > > > > this
> > > > > > > > > right
> > > > > > > > > > > > before a release is done.
> > > > > > > > > > > >
> > > > > > > > > > > > On 6 September 2011 04:37, Rex Wang <
> rwonly@gmail.com>
> > > > > wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > > > > > > > > > >
> > > > > > > > > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > > > > > > > > > vmahrwald@googlemail.com
> > > > > > > > > > > > > > >wrote:
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Comments inline :)
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Kind regards,
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Valentin
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > 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).
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > The blueprint specification says any non-standard
> > > > > extensions
> > > > > > > to
> > > > > > > > > > > > blueprint
> > > > > > > > > > > > > > must be enabled via namespace handlers. I don't
> > like
> > > > the
> > > > > ext
> > > > > > > of
> > > > > > > > > cm
> > > > > > > > > > > > > > namespaces to require apache-jexl since it means
> > more
> > > > > > > > > dependencies
> > > > > > > > > > are
> > > > > > > > > > > > > > pulled in when they may never be used.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > Hi Alasdair,
> > > > > > > > > > > > > Since the current code does not hard depend on the
> > > > > > > commons-jexl,
> > > > > > > > > and
> > > > > > > > > > I
> > > > > > > > > > > > > think
> > > > > > > > > > > > > the only difference from your desire is adding a
> new
> > > > > namespace
> > > > > > > > > which
> > > > > > > > > > can
> > > > > > > > > > > > > delay the blueprint container initialization if the
> > > > > > > commons-jexl
> > > > > > > > is
> > > > > > > > > > not
> > > > > > > > > > > > > present,
> > > > > > > > > > > > > I consider this as an improvement to the current
> > > > solution.
> > > > > And
> > > > > > > I
> > > > > > > > > > think it
> > > > > > > > > > > > > would be better to let user hold the option that if
> > he
> > > > > would
> > > > > > > use
> > > > > > > > > the
> > > > > > > > > > new
> > > > > > > > > > > > > namespace, and if he don't use it, the ${a+b} can
> > still
> > > > > work.
> > > > > > > > Hope
> > > > > > > > > > the
> > > > > > > > > > > > > current solution meets the criteria to start
> > release..
> > > > > > > > > > > > >
> > > > > > > > > > > > > BTW, seems Aries community is not that active in
> last
> > > two
> > > > > > > month.
> > > > > > > > Is
> > > > > > > > > > there
> > > > > > > > > > > > > still a release manager help the release works?
> > > > > > > > > > > > >
> > > > > > > > > > > > > -Rex
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Looking at your options a) doesn't work because
> it
> > > > isn't
> > > > > > > using
> > > > > > > > > > > > namespace
> > > > > > > > > > > > > > handlers, b) sucks big time and would mean to
> meat
> > > the
> > > > > spec
> > > > > > > we
> > > > > > > > > > would
> > > > > > > > > > > > > need
> > > > > > > > > > > > > > apache-jexl and the whole point is to allow the
> > spec
> > > to
> > > > > be
> > > > > > > > > > implemented
> > > > > > > > > > > > > > without apache-jexl being required. So I think
> > > > something
> > > > > > > like
> > > > > > > > > > option c
> > > > > > > > > > > > > > should be gone for. For instance you could add an
> > > > > attribute
> > > > > > > in
> > > > > > > > a
> > > > > > > > > > > > > > non-standard namespace that says to enable this
> > > > > capability.
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Is any of that what you were thinking of?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Does that make any sense?
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > Alasdair
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > On 30 August 2011 07:36, Rex Wang <
> > > > rwonly@gmail.com>
> > > > > > > > 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 <
> not@apache.org
> > >
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >>> 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 <
> > > > > rwonly@gmail.com>
> > > > > > > > > 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 apache.org
> > > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >> --
> > > > > > > > > > > > > > > >> Lei Wang (Rex)
> > > > > > > > > > > > > > > >> rwonly AT apache.org
> > > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > > > > rwonly AT apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > not@apache.org
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > > rwonly AT apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Lei Wang (Rex)
> > > > > > > > > rwonly AT apache.org
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Alasdair Nottingham
> > > > > > > > not@apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Lei Wang (Rex)
> > > > > > > rwonly AT apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Alasdair Nottingham
> > > > > > not@apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alasdair Nottingham
> > > > not@apache.org
> > > >
> > >
> > >
> > >
> > > --
> > > Lei Wang (Rex)
> > > rwonly AT apache.org
> > >
> >
> >
> >
> > --
> > Alasdair Nottingham
> > not@apache.org
> >
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>
--
Alasdair Nottingham
not@apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
2011/9/13 Alasdair Nottingham <no...@apache.org>
> Hi,
>
> While I agree that it would be odd to use ${a+b} notation in the way you
> describe the fact it works today makes me really unhappy with disabling it
> as a result of this change. I don't think that JSTL and blueprint are that
> analogous, so I don't think enabling this by default for everyone is the
> right way to do.
Hi
I mean how EL is used in JSTL is similar with this suggestion.
I agree pluggable evaluator is good, especially for the situation stated by
Guillaume. But for the ${a+b}, you are considering an existing support that
rarely people was using(even maybe no one used). So in practice, I did not
see any drawbacks to support this by default for everyone. I think simple is
beautiful, and there is no spec for blueprint-ext, why we can not change the
odd behavior support?
-Rex
We should respect the existing support and exploit good
> modularity to allow this to be plugged in as desired.
>
> Alasdair
>
> On 13 September 2011 09:32, Rex Wang <rw...@gmail.com> wrote:
>
> > Hi Alasdair,
> >
> > I am sorry for replying slow because I am on vacation.
> >
> > This looks much better than a new namespace to me. Thank you very much
> for
> > thinking a lot on this!
> > I can accept the new approach. But, IMHO, I think we should really
> "forbid"
> > user use following style in blueprint-ext :
> > (1) "a+b" as a key of value. eg: <property name="a+b" value="xxx" />
> > (2) "${a+b}" as the injection value. eg: <property name="zzz"
> > value="${a+b}"
> > /> which expects the string ${a+b} to be injected to zzz.
> > I think the above two styles are not that useful and always bring a lot
> of
> > confusion while programming. And this is also not consistent with the
> > existing development experiences in JSTL. So, my point of view is not
> that
> > we must stick to jexl, I just hope we can support such evaluation
> natively.
> >
> > Anyway, if community decides, I respect.
> >
> > thanks,
> >
> > -Rex
> >
> > 2011/9/9 Alasdair Nottingham <no...@apache.org>
> >
> > > Hi,
> > >
> > > I have thought of a possible update we could do that would enable this
> > > without a new namespace. I'll outline it here. Make a minor update to
> the
> > > ext schema (making it 1.2.0) so we can do the following:
> > >
> > > <property-placeholder evaluator="jexl">
> > > <default-properties>
> > > <property name="name" value="value" />
> > > </default-properties>
> > > <location>file:///url</ext:location>
> > > </property-placeholder>
> > >
> > > The namespace handler then inserts a synthetic service dependency on a
> > > service of type PropertyProcessor with the service property
> "type=jexl".
> > > This means the blueprint container would only be configured while the
> > > desired processor is available. Then we update the code where we do the
> > > processing to use the PropertyProcessor service instead of having it
> > > hardcoded.
> > >
> > > This solves my issues around correct modularity, your issues around
> > > programming model simplicity, and it would also allow us to plug other
> > > processors/evaluators such as groovy in the future very easily.
> > >
> > > Thoughts?
> > > Alasdair
> > >
> > > On 9 September 2011 10:39, Timothy Ward <ti...@apache.org>
> wrote:
> > >
> > > >
> > > > Alasdair,
> > > >
> > > > Thanks for taking the time to write a test that answers my question.
> I
> > > had
> > > > a suspicion that this sort of thing would happen. It needs to be
> > possible
> > > > for the blueprint bundle to behave consistently whether JEXL is
> > installed
> > > or
> > > > not.
> > > >
> > > > Regards,
> > > >
> > > > Tim
> > > >
> > > > > Date: Thu, 8 Sep 2011 23:26:18 +0100
> > > > > Subject: Re: [Release Discussion] ship maintenance releases of
> > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > From: not@apache.org
> > > > > To: dev@aries.apache.org
> > > > >
> > > > > Hi,
> > > > >
> > > > > So lets get real with an example to start illustrating my issues.
> We
> > > have
> > > > a
> > > > > release already and the release is used by people, quite a few
> > people.
> > > We
> > > > > don't know what they are doing. I have written a test. The test
> uses
> > > the
> > > > > sample blueprint bundle. It contains the following blueprint xml:
> > > > >
> > > > > <bean id="bar2" class="org.apache.aries.blueprint.sample.Bar">
> > > > >
> > > > > <property name="value" value="${a+b}"/>
> > > > >
> > > > > </bean>
> > > > >
> > > > > The setValue method takes a String. I have run these tests in two
> > ways.
> > > > The
> > > > > first with jexl and the second without. If jexl isn't installed I
> > get:
> > > > >
> > > > > ${a+b}
> > > > >
> > > > > when jexl is installed I get:
> > > > >
> > > > > 0
> > > > >
> > > > > Irrespective of how useful this is to people who want the behaviour
> > it
> > > is
> > > > a
> > > > > huge problem for those people who do NOT want this behaviour. It is
> > > easy
> > > > to
> > > > > say "well don't install jexl then", but consider this. I have
> written
> > a
> > > > > blueprint bundle that expects to have ${a+b} injected. I deploy it
> > in
> > > > one
> > > > > runtime and it works the way I expect. Now I drop it into Geronimo
> > and
> > > I
> > > > get
> > > > > 0 instead. So I now need to go back and rewrite my bundle to work
> in
> > > > > geronimo and I have two different bundles for each environment.
> This
> > is
> > > > > wrong.
> > > > >
> > > > > As said before I think we need this enabled via a namespace handler
> > and
> > > > an
> > > > > attribute. I would require the following to be added to the
> blueprint
> > > > > element:
> > > > >
> > > > > <blueprint jexl:enable="true" xmlns:jexl="
> > > > > http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0"/>
> > > > >
> > > > > any existing application will then behave consistently irrespective
> > of
> > > > what
> > > > > is installed in the surrounding framework. Even the one I just
> > created.
> > > > If
> > > > > the jexl bundle isn't installed then the jexl namespace handler is
> > not
> > > > > installed so the blueprint bundle will not be processed until it is
> > in
> > > > the
> > > > > normal way. The code in question can remain where it is, but it
> would
> > > > only
> > > > > be enabled if the jexl namespace is configured. Ideally we would be
> > > able
> > > > to
> > > > > parameterise the value processing in a pluggable way, but as long
> as
> > > the
> > > > > externals are right we can refactor the internals at our leisure.
> > > > >
> > > > > We are creating a programming model for OSGi here and that means we
> > > need
> > > > to
> > > > > get the modularity right. Currently it is not right, not only is
> the
> > > > > modularity wrong but this makes a breaking change to the way a
> > > > blueprint.xml
> > > > > is processed in what is a bug release. Irrespective of how useful
> > this
> > > is
> > > > I
> > > > > do not think it is important enough to warrant a breaking change
> when
> > > we
> > > > can
> > > > > make it work without breaking existing bundles.
> > > > >
> > > > > To address your question of "Do you think it is a good idea to
> > support
> > > > > this?" I do think it is a good idea, if I didn't I would have -1ed
> > the
> > > > > commit rather than engaged in an email discussion to get it right.
> > > > >
> > > > > Thanks
> > > > > Alasdair
> > > > >
> > > > > On 8 September 2011 14:35, Rex Wang <rw...@gmail.com> wrote:
> > > > >
> > > > > > 2011/9/8 Alasdair Nottingham <no...@apache.org>
> > > > > >
> > > > > > > On 8 September 2011 10:10, Rex Wang <rw...@gmail.com> wrote:
> > > > > > >
> > > > > > > > 2011/9/8 Timothy Ward <ti...@apache.org>
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Hi,
> > > > > > > > >
> > > > > > > > > I'm afraid I've not been paying as much attention as I
> should
> > > to
> > > > this
> > > > > > > > > thread. Reading back over the issues. I would currently
> vote
> > -1
> > > > on
> > > > > > this
> > > > > > > > > release. I am not at all happy with the fact that users of
> > this
> > > > > > support
> > > > > > > > will
> > > > > > > > > see different, potentially erroneous, behaviour depending
> on
> > > the
> > > > > > > presence
> > > > > > > > or
> > > > > > > > > absence of an optional dependency. Our previous statement
> has
> > > > always
> > > > > > > been
> > > > > > > > > "If a blueprint bundle wants to use some non-standard
> > function
> > > it
> > > > > > > should
> > > > > > > > > declare that using an additional namespace".
> > > > > > > > >
> > > > > > > > Do you mean the statement in spec 121.4:
> > > > > > > > "The Blueprint XML resources in a bundle are the definitions.
> > > Each
> > > > > > > > definition can include multiple
> > > > > > > > namespaces. Implementations of the Blueprint core namespace
> > must
> > > > > > strictly
> > > > > > > > follow this specification,
> > > > > > > > if they add additional behavior they must add additional
> > > namespaces
> > > > > > that
> > > > > > > > are
> > > > > > > > actually used in
> > > > > > > > the definitions to signal the deviation from this
> > > specification."?
> > > > > > > >
> > > > > > > > We are improving the blueprint-ext, which has been already an
> > > > > > additional
> > > > > > > > namespace to blueprint core schema. Why must we add a new
> > > namespace
> > > > to
> > > > > > > > extend the ability of blueprint-ext?
> > > > > > > >
> > > > > > > >
> > > > > > > Blueprint ext is a part of our core implementation. Adding it
> to
> > > > > > > blueprint-ext means that if you want to use ANY part of
> blueprint
> > > ext
> > > > you
> > > > > > > MUST have apache-jexl even if you don't wan to use the ${a+b}
> > > syntax.
> > > > > > This
> > > > > > > is wrong.
> > > > > > >
> > > > > >
> > > > > > Hi Alasdair,
> > > > > > The itests passes without adding the commons-jexl bundle now.
> > > > > > If you don't have commons-jexl installed, the current code can
> work
> > > as
> > > > > > before. Unless you want to use ${a+b}, you need guarantee the
> > > > commons-jexl
> > > > > > is present. Otherwise it will record this exception in logger. I
> > know
> > > > this
> > > > > > is not that convenient, but at least user can know what he need
> to
> > do
> > > > to
> > > > > > get
> > > > > > things right from the log..
> > > > > >
> > > > > > On the other hand, Java EE EL supports such style of calculation
> > > > natively,
> > > > > > I
> > > > > > think we should support it in blueprint-ext directly to keep the
> > > > consistent
> > > > > > of the current development experiences. In other words, if we
> don't
> > > use
> > > > > > commons-jexl to implement such ability, instead, we write codes
> by
> > > > > > ourselves
> > > > > > to do that. Do you think it is a good idea to support this? After
> > > all,
> > > > > > there
> > > > > > is no spec for blueprint-ext.
> > > > > >
> > > > > > thanks,
> > > > > > -Rex
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > > In my view this new function should only be available if
> the
> > > > optional
> > > > > > > > > dependency is satisfied, and blueprint bundles must enable
> > this
> > > > > > > function
> > > > > > > > > using a custom namespace. Otherwise I see two problems.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > I want this new support, but have no way to ensure it is
> > > present,
> > > > as
> > > > > > a
> > > > > > > > > result I am sometimes injected with "1+2" instead of "3".
> > This
> > > > leads
> > > > > > to
> > > > > > > > > intermittent NumberFormatExceptions
> > > > > > > > >
> > > > > > > > I do not want this new support, but as the dependency is
> > > available
> > > > I
> > > > > > am
> > > > > > > > > injected with "3" instead of "1+2". This leads to
> > inconsistent
> > > > and
> > > > > > > > confusing
> > > > > > > > > behaviour.
> > > > > > > > >
> > > > > > > > I am not sure I understand this..
> > > > > > > > If you want 3, you need <xxx value="${1+2}">
> > > > > > > > If you want 1+2, you should use <xxx value="1+2">
> > > > > > > > Only the expression in ${..} will trigger the calculation, no
> > > > matter if
> > > > > > > the
> > > > > > > > dependency if available.
> > > > > > > >
> > > > > > > >
> > > > > > > I think tim is saying you want the string literal "${1+2}" not
> > the
> > > > string
> > > > > > > 1+2. With your change if I had ${1+2} I now get 3 rather than
> > > ${1+2}.
> > > > > > This
> > > > > > > is a change in behaviour and should be enabled using a new
> > > namespace.
> > > > Of
> > > > > > > course you could just reversion the namespace from v1.x to v2
> as
> > a
> > > > > > breaking
> > > > > > > change, but we would need to support both versions of the
> schema.
> > > > > > >
> > > > > > > As with Tim I would currently -1 any release of blueprint 3.2
> > until
> > > > this
> > > > > > is
> > > > > > > addressed.
> > > > > > >
> > > > > > > Alasdair
> > > > > > >
> > > > > > > -Rex
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > Adding a namespace for this function elegantly solves both
> > > these
> > > > > > issues
> > > > > > > > in
> > > > > > > > > a way that is consistent with other blueprint extensions,
> and
> > I
> > > > think
> > > > > > > is
> > > > > > > > > essential before this function can be released.
> > > > > > > > >
> > > > > > > > > Regards,
> > > > > > > > >
> > > > > > > > > Tim
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > From: rwonly@gmail.com
> > > > > > > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > > > > > > > > Subject: Re: [Release Discussion] ship maintenance
> releases
> > > of
> > > > > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > > > > > To: dev@aries.apache.org
> > > > > > > > > >
> > > > > > > > > > I still think adding a new namespace only for such simple
> > > > > > calculation
> > > > > > > > is
> > > > > > > > > too
> > > > > > > > > > heavy and not consumalbe for users..
> > > > > > > > > >
> > > > > > > > > > Anyway, could anybody help with the release of *
> > > > > > > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > > > > > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould
> > anyone
> > > > help
> > > > > > > > check
> > > > > > > > > why
> > > > > > > > > > I can not deploy artifacts to apache.snapshot? Maybe I
> can
> > > try
> > > > > > > release
> > > > > > > > > the 2
> > > > > > > > > > components. Geronimo does not have much time targeting
> the
> > > > 3.0-beta
> > > > > > > > > release.
> > > > > > > > > >
> > > > > > > > > > thanks,
> > > > > > > > > >
> > > > > > > > > > -Rex
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > > > > > > > > >
> > > > > > > > > > > If we release blueprint as is we will never be able to
> > make
> > > > the
> > > > > > > > change
> > > > > > > > > as
> > > > > > > > > > > we
> > > > > > > > > > > would cause a major breaking change. I think we need to
> > get
> > > > this
> > > > > > > > right
> > > > > > > > > > > before a release is done.
> > > > > > > > > > >
> > > > > > > > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com>
> > > > wrote:
> > > > > > > > > > >
> > > > > > > > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > > > > > > > > >
> > > > > > > > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > > > > > > > > vmahrwald@googlemail.com
> > > > > > > > > > > > > >wrote:
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Comments inline :)
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Kind regards,
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Valentin
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > 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).
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > The blueprint specification says any non-standard
> > > > extensions
> > > > > > to
> > > > > > > > > > > blueprint
> > > > > > > > > > > > > must be enabled via namespace handlers. I don't
> like
> > > the
> > > > ext
> > > > > > of
> > > > > > > > cm
> > > > > > > > > > > > > namespaces to require apache-jexl since it means
> more
> > > > > > > > dependencies
> > > > > > > > > are
> > > > > > > > > > > > > pulled in when they may never be used.
> > > > > > > > > > > > >
> > > > > > > > > > > > Hi Alasdair,
> > > > > > > > > > > > Since the current code does not hard depend on the
> > > > > > commons-jexl,
> > > > > > > > and
> > > > > > > > > I
> > > > > > > > > > > > think
> > > > > > > > > > > > the only difference from your desire is adding a new
> > > > namespace
> > > > > > > > which
> > > > > > > > > can
> > > > > > > > > > > > delay the blueprint container initialization if the
> > > > > > commons-jexl
> > > > > > > is
> > > > > > > > > not
> > > > > > > > > > > > present,
> > > > > > > > > > > > I consider this as an improvement to the current
> > > solution.
> > > > And
> > > > > > I
> > > > > > > > > think it
> > > > > > > > > > > > would be better to let user hold the option that if
> he
> > > > would
> > > > > > use
> > > > > > > > the
> > > > > > > > > new
> > > > > > > > > > > > namespace, and if he don't use it, the ${a+b} can
> still
> > > > work.
> > > > > > > Hope
> > > > > > > > > the
> > > > > > > > > > > > current solution meets the criteria to start
> release..
> > > > > > > > > > > >
> > > > > > > > > > > > BTW, seems Aries community is not that active in last
> > two
> > > > > > month.
> > > > > > > Is
> > > > > > > > > there
> > > > > > > > > > > > still a release manager help the release works?
> > > > > > > > > > > >
> > > > > > > > > > > > -Rex
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > Looking at your options a) doesn't work because it
> > > isn't
> > > > > > using
> > > > > > > > > > > namespace
> > > > > > > > > > > > > handlers, b) sucks big time and would mean to meat
> > the
> > > > spec
> > > > > > we
> > > > > > > > > would
> > > > > > > > > > > > need
> > > > > > > > > > > > > apache-jexl and the whole point is to allow the
> spec
> > to
> > > > be
> > > > > > > > > implemented
> > > > > > > > > > > > > without apache-jexl being required. So I think
> > > something
> > > > > > like
> > > > > > > > > option c
> > > > > > > > > > > > > should be gone for. For instance you could add an
> > > > attribute
> > > > > > in
> > > > > > > a
> > > > > > > > > > > > > non-standard namespace that says to enable this
> > > > capability.
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Is any of that what you were thinking of?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Does that make any sense?
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > Alasdair
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > On 30 August 2011 07:36, Rex Wang <
> > > rwonly@gmail.com>
> > > > > > > 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 <not@apache.org
> >
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >>> 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 <
> > > > rwonly@gmail.com>
> > > > > > > > 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 apache.org
> > > > > > > > > > > > > > >>>
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >> --
> > > > > > > > > > > > > > >> Lei Wang (Rex)
> > > > > > > > > > > > > > >> rwonly AT apache.org
> > > > > > > > > > > > > > >>
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > >
> > > > > > > > > > > > > > > --
> > > > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > > > rwonly AT apache.org
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > not@apache.org
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > rwonly AT apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Lei Wang (Rex)
> > > > > > > > rwonly AT apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Alasdair Nottingham
> > > > > > > not@apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Lei Wang (Rex)
> > > > > > rwonly AT apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alasdair Nottingham
> > > > > not@apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Alasdair Nottingham
> > > not@apache.org
> > >
> >
> >
> >
> > --
> > Lei Wang (Rex)
> > rwonly AT apache.org
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
While I agree that it would be odd to use ${a+b} notation in the way you
describe the fact it works today makes me really unhappy with disabling it
as a result of this change. I don't think that JSTL and blueprint are that
analogous, so I don't think enabling this by default for everyone is the
right way to do. We should respect the existing support and exploit good
modularity to allow this to be plugged in as desired.
Alasdair
On 13 September 2011 09:32, Rex Wang <rw...@gmail.com> wrote:
> Hi Alasdair,
>
> I am sorry for replying slow because I am on vacation.
>
> This looks much better than a new namespace to me. Thank you very much for
> thinking a lot on this!
> I can accept the new approach. But, IMHO, I think we should really "forbid"
> user use following style in blueprint-ext :
> (1) "a+b" as a key of value. eg: <property name="a+b" value="xxx" />
> (2) "${a+b}" as the injection value. eg: <property name="zzz"
> value="${a+b}"
> /> which expects the string ${a+b} to be injected to zzz.
> I think the above two styles are not that useful and always bring a lot of
> confusion while programming. And this is also not consistent with the
> existing development experiences in JSTL. So, my point of view is not that
> we must stick to jexl, I just hope we can support such evaluation natively.
>
> Anyway, if community decides, I respect.
>
> thanks,
>
> -Rex
>
> 2011/9/9 Alasdair Nottingham <no...@apache.org>
>
> > Hi,
> >
> > I have thought of a possible update we could do that would enable this
> > without a new namespace. I'll outline it here. Make a minor update to the
> > ext schema (making it 1.2.0) so we can do the following:
> >
> > <property-placeholder evaluator="jexl">
> > <default-properties>
> > <property name="name" value="value" />
> > </default-properties>
> > <location>file:///url</ext:location>
> > </property-placeholder>
> >
> > The namespace handler then inserts a synthetic service dependency on a
> > service of type PropertyProcessor with the service property "type=jexl".
> > This means the blueprint container would only be configured while the
> > desired processor is available. Then we update the code where we do the
> > processing to use the PropertyProcessor service instead of having it
> > hardcoded.
> >
> > This solves my issues around correct modularity, your issues around
> > programming model simplicity, and it would also allow us to plug other
> > processors/evaluators such as groovy in the future very easily.
> >
> > Thoughts?
> > Alasdair
> >
> > On 9 September 2011 10:39, Timothy Ward <ti...@apache.org> wrote:
> >
> > >
> > > Alasdair,
> > >
> > > Thanks for taking the time to write a test that answers my question. I
> > had
> > > a suspicion that this sort of thing would happen. It needs to be
> possible
> > > for the blueprint bundle to behave consistently whether JEXL is
> installed
> > or
> > > not.
> > >
> > > Regards,
> > >
> > > Tim
> > >
> > > > Date: Thu, 8 Sep 2011 23:26:18 +0100
> > > > Subject: Re: [Release Discussion] ship maintenance releases of
> > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > From: not@apache.org
> > > > To: dev@aries.apache.org
> > > >
> > > > Hi,
> > > >
> > > > So lets get real with an example to start illustrating my issues. We
> > have
> > > a
> > > > release already and the release is used by people, quite a few
> people.
> > We
> > > > don't know what they are doing. I have written a test. The test uses
> > the
> > > > sample blueprint bundle. It contains the following blueprint xml:
> > > >
> > > > <bean id="bar2" class="org.apache.aries.blueprint.sample.Bar">
> > > >
> > > > <property name="value" value="${a+b}"/>
> > > >
> > > > </bean>
> > > >
> > > > The setValue method takes a String. I have run these tests in two
> ways.
> > > The
> > > > first with jexl and the second without. If jexl isn't installed I
> get:
> > > >
> > > > ${a+b}
> > > >
> > > > when jexl is installed I get:
> > > >
> > > > 0
> > > >
> > > > Irrespective of how useful this is to people who want the behaviour
> it
> > is
> > > a
> > > > huge problem for those people who do NOT want this behaviour. It is
> > easy
> > > to
> > > > say "well don't install jexl then", but consider this. I have written
> a
> > > > blueprint bundle that expects to have ${a+b} injected. I deploy it
> in
> > > one
> > > > runtime and it works the way I expect. Now I drop it into Geronimo
> and
> > I
> > > get
> > > > 0 instead. So I now need to go back and rewrite my bundle to work in
> > > > geronimo and I have two different bundles for each environment. This
> is
> > > > wrong.
> > > >
> > > > As said before I think we need this enabled via a namespace handler
> and
> > > an
> > > > attribute. I would require the following to be added to the blueprint
> > > > element:
> > > >
> > > > <blueprint jexl:enable="true" xmlns:jexl="
> > > > http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0"/>
> > > >
> > > > any existing application will then behave consistently irrespective
> of
> > > what
> > > > is installed in the surrounding framework. Even the one I just
> created.
> > > If
> > > > the jexl bundle isn't installed then the jexl namespace handler is
> not
> > > > installed so the blueprint bundle will not be processed until it is
> in
> > > the
> > > > normal way. The code in question can remain where it is, but it would
> > > only
> > > > be enabled if the jexl namespace is configured. Ideally we would be
> > able
> > > to
> > > > parameterise the value processing in a pluggable way, but as long as
> > the
> > > > externals are right we can refactor the internals at our leisure.
> > > >
> > > > We are creating a programming model for OSGi here and that means we
> > need
> > > to
> > > > get the modularity right. Currently it is not right, not only is the
> > > > modularity wrong but this makes a breaking change to the way a
> > > blueprint.xml
> > > > is processed in what is a bug release. Irrespective of how useful
> this
> > is
> > > I
> > > > do not think it is important enough to warrant a breaking change when
> > we
> > > can
> > > > make it work without breaking existing bundles.
> > > >
> > > > To address your question of "Do you think it is a good idea to
> support
> > > > this?" I do think it is a good idea, if I didn't I would have -1ed
> the
> > > > commit rather than engaged in an email discussion to get it right.
> > > >
> > > > Thanks
> > > > Alasdair
> > > >
> > > > On 8 September 2011 14:35, Rex Wang <rw...@gmail.com> wrote:
> > > >
> > > > > 2011/9/8 Alasdair Nottingham <no...@apache.org>
> > > > >
> > > > > > On 8 September 2011 10:10, Rex Wang <rw...@gmail.com> wrote:
> > > > > >
> > > > > > > 2011/9/8 Timothy Ward <ti...@apache.org>
> > > > > > >
> > > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I'm afraid I've not been paying as much attention as I should
> > to
> > > this
> > > > > > > > thread. Reading back over the issues. I would currently vote
> -1
> > > on
> > > > > this
> > > > > > > > release. I am not at all happy with the fact that users of
> this
> > > > > support
> > > > > > > will
> > > > > > > > see different, potentially erroneous, behaviour depending on
> > the
> > > > > > presence
> > > > > > > or
> > > > > > > > absence of an optional dependency. Our previous statement has
> > > always
> > > > > > been
> > > > > > > > "If a blueprint bundle wants to use some non-standard
> function
> > it
> > > > > > should
> > > > > > > > declare that using an additional namespace".
> > > > > > > >
> > > > > > > Do you mean the statement in spec 121.4:
> > > > > > > "The Blueprint XML resources in a bundle are the definitions.
> > Each
> > > > > > > definition can include multiple
> > > > > > > namespaces. Implementations of the Blueprint core namespace
> must
> > > > > strictly
> > > > > > > follow this specification,
> > > > > > > if they add additional behavior they must add additional
> > namespaces
> > > > > that
> > > > > > > are
> > > > > > > actually used in
> > > > > > > the definitions to signal the deviation from this
> > specification."?
> > > > > > >
> > > > > > > We are improving the blueprint-ext, which has been already an
> > > > > additional
> > > > > > > namespace to blueprint core schema. Why must we add a new
> > namespace
> > > to
> > > > > > > extend the ability of blueprint-ext?
> > > > > > >
> > > > > > >
> > > > > > Blueprint ext is a part of our core implementation. Adding it to
> > > > > > blueprint-ext means that if you want to use ANY part of blueprint
> > ext
> > > you
> > > > > > MUST have apache-jexl even if you don't wan to use the ${a+b}
> > syntax.
> > > > > This
> > > > > > is wrong.
> > > > > >
> > > > >
> > > > > Hi Alasdair,
> > > > > The itests passes without adding the commons-jexl bundle now.
> > > > > If you don't have commons-jexl installed, the current code can work
> > as
> > > > > before. Unless you want to use ${a+b}, you need guarantee the
> > > commons-jexl
> > > > > is present. Otherwise it will record this exception in logger. I
> know
> > > this
> > > > > is not that convenient, but at least user can know what he need to
> do
> > > to
> > > > > get
> > > > > things right from the log..
> > > > >
> > > > > On the other hand, Java EE EL supports such style of calculation
> > > natively,
> > > > > I
> > > > > think we should support it in blueprint-ext directly to keep the
> > > consistent
> > > > > of the current development experiences. In other words, if we don't
> > use
> > > > > commons-jexl to implement such ability, instead, we write codes by
> > > > > ourselves
> > > > > to do that. Do you think it is a good idea to support this? After
> > all,
> > > > > there
> > > > > is no spec for blueprint-ext.
> > > > >
> > > > > thanks,
> > > > > -Rex
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > > In my view this new function should only be available if the
> > > optional
> > > > > > > > dependency is satisfied, and blueprint bundles must enable
> this
> > > > > > function
> > > > > > > > using a custom namespace. Otherwise I see two problems.
> > > > > > > >
> > > > > > > >
> > > > > > > > I want this new support, but have no way to ensure it is
> > present,
> > > as
> > > > > a
> > > > > > > > result I am sometimes injected with "1+2" instead of "3".
> This
> > > leads
> > > > > to
> > > > > > > > intermittent NumberFormatExceptions
> > > > > > > >
> > > > > > > I do not want this new support, but as the dependency is
> > available
> > > I
> > > > > am
> > > > > > > > injected with "3" instead of "1+2". This leads to
> inconsistent
> > > and
> > > > > > > confusing
> > > > > > > > behaviour.
> > > > > > > >
> > > > > > > I am not sure I understand this..
> > > > > > > If you want 3, you need <xxx value="${1+2}">
> > > > > > > If you want 1+2, you should use <xxx value="1+2">
> > > > > > > Only the expression in ${..} will trigger the calculation, no
> > > matter if
> > > > > > the
> > > > > > > dependency if available.
> > > > > > >
> > > > > > >
> > > > > > I think tim is saying you want the string literal "${1+2}" not
> the
> > > string
> > > > > > 1+2. With your change if I had ${1+2} I now get 3 rather than
> > ${1+2}.
> > > > > This
> > > > > > is a change in behaviour and should be enabled using a new
> > namespace.
> > > Of
> > > > > > course you could just reversion the namespace from v1.x to v2 as
> a
> > > > > breaking
> > > > > > change, but we would need to support both versions of the schema.
> > > > > >
> > > > > > As with Tim I would currently -1 any release of blueprint 3.2
> until
> > > this
> > > > > is
> > > > > > addressed.
> > > > > >
> > > > > > Alasdair
> > > > > >
> > > > > > -Rex
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > Adding a namespace for this function elegantly solves both
> > these
> > > > > issues
> > > > > > > in
> > > > > > > > a way that is consistent with other blueprint extensions, and
> I
> > > think
> > > > > > is
> > > > > > > > essential before this function can be released.
> > > > > > > >
> > > > > > > > Regards,
> > > > > > > >
> > > > > > > > Tim
> > > > > > > >
> > > > > > > >
> > > > > > > > > From: rwonly@gmail.com
> > > > > > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > > > > > > > Subject: Re: [Release Discussion] ship maintenance releases
> > of
> > > > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > > > > To: dev@aries.apache.org
> > > > > > > > >
> > > > > > > > > I still think adding a new namespace only for such simple
> > > > > calculation
> > > > > > > is
> > > > > > > > too
> > > > > > > > > heavy and not consumalbe for users..
> > > > > > > > >
> > > > > > > > > Anyway, could anybody help with the release of *
> > > > > > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > > > > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould
> anyone
> > > help
> > > > > > > check
> > > > > > > > why
> > > > > > > > > I can not deploy artifacts to apache.snapshot? Maybe I can
> > try
> > > > > > release
> > > > > > > > the 2
> > > > > > > > > components. Geronimo does not have much time targeting the
> > > 3.0-beta
> > > > > > > > release.
> > > > > > > > >
> > > > > > > > > thanks,
> > > > > > > > >
> > > > > > > > > -Rex
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > > > > > > > >
> > > > > > > > > > If we release blueprint as is we will never be able to
> make
> > > the
> > > > > > > change
> > > > > > > > as
> > > > > > > > > > we
> > > > > > > > > > would cause a major breaking change. I think we need to
> get
> > > this
> > > > > > > right
> > > > > > > > > > before a release is done.
> > > > > > > > > >
> > > > > > > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com>
> > > wrote:
> > > > > > > > > >
> > > > > > > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > > > > > > > >
> > > > > > > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > > > > > > > vmahrwald@googlemail.com
> > > > > > > > > > > > >wrote:
> > > > > > > > > > > >
> > > > > > > > > > > > > Comments inline :)
> > > > > > > > > > > > >
> > > > > > > > > > > > > Kind regards,
> > > > > > > > > > > > >
> > > > > > > > > > > > > Valentin
> > > > > > > > > > > > >
> > > > > > > > > > > > > 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).
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > The blueprint specification says any non-standard
> > > extensions
> > > > > to
> > > > > > > > > > blueprint
> > > > > > > > > > > > must be enabled via namespace handlers. I don't like
> > the
> > > ext
> > > > > of
> > > > > > > cm
> > > > > > > > > > > > namespaces to require apache-jexl since it means more
> > > > > > > dependencies
> > > > > > > > are
> > > > > > > > > > > > pulled in when they may never be used.
> > > > > > > > > > > >
> > > > > > > > > > > Hi Alasdair,
> > > > > > > > > > > Since the current code does not hard depend on the
> > > > > commons-jexl,
> > > > > > > and
> > > > > > > > I
> > > > > > > > > > > think
> > > > > > > > > > > the only difference from your desire is adding a new
> > > namespace
> > > > > > > which
> > > > > > > > can
> > > > > > > > > > > delay the blueprint container initialization if the
> > > > > commons-jexl
> > > > > > is
> > > > > > > > not
> > > > > > > > > > > present,
> > > > > > > > > > > I consider this as an improvement to the current
> > solution.
> > > And
> > > > > I
> > > > > > > > think it
> > > > > > > > > > > would be better to let user hold the option that if he
> > > would
> > > > > use
> > > > > > > the
> > > > > > > > new
> > > > > > > > > > > namespace, and if he don't use it, the ${a+b} can still
> > > work.
> > > > > > Hope
> > > > > > > > the
> > > > > > > > > > > current solution meets the criteria to start release..
> > > > > > > > > > >
> > > > > > > > > > > BTW, seems Aries community is not that active in last
> two
> > > > > month.
> > > > > > Is
> > > > > > > > there
> > > > > > > > > > > still a release manager help the release works?
> > > > > > > > > > >
> > > > > > > > > > > -Rex
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > Looking at your options a) doesn't work because it
> > isn't
> > > > > using
> > > > > > > > > > namespace
> > > > > > > > > > > > handlers, b) sucks big time and would mean to meat
> the
> > > spec
> > > > > we
> > > > > > > > would
> > > > > > > > > > > need
> > > > > > > > > > > > apache-jexl and the whole point is to allow the spec
> to
> > > be
> > > > > > > > implemented
> > > > > > > > > > > > without apache-jexl being required. So I think
> > something
> > > > > like
> > > > > > > > option c
> > > > > > > > > > > > should be gone for. For instance you could add an
> > > attribute
> > > > > in
> > > > > > a
> > > > > > > > > > > > non-standard namespace that says to enable this
> > > capability.
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > > Is any of that what you were thinking of?
> > > > > > > > > > > > >
> > > > > > > > > > > > > > Does that make any sense?
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > Alasdair
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > On 30 August 2011 07:36, Rex Wang <
> > rwonly@gmail.com>
> > > > > > 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 <no...@apache.org>
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >>> 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 <
> > > rwonly@gmail.com>
> > > > > > > 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 apache.org
> > > > > > > > > > > > > >>>
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >> --
> > > > > > > > > > > > > >> Lei Wang (Rex)
> > > > > > > > > > > > > >> rwonly AT apache.org
> > > > > > > > > > > > > >>
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > >
> > > > > > > > > > > > > > --
> > > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > not@apache.org
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > > rwonly AT apache.org
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > not@apache.org
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Lei Wang (Rex)
> > > > > > > > > rwonly AT apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Lei Wang (Rex)
> > > > > > > rwonly AT apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Alasdair Nottingham
> > > > > > not@apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Lei Wang (Rex)
> > > > > rwonly AT apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alasdair Nottingham
> > > > not@apache.org
> > >
> > >
> >
> >
> >
> > --
> > Alasdair Nottingham
> > not@apache.org
> >
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>
--
Alasdair Nottingham
not@apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
Hi Alasdair,
I am sorry for replying slow because I am on vacation.
This looks much better than a new namespace to me. Thank you very much for
thinking a lot on this!
I can accept the new approach. But, IMHO, I think we should really "forbid"
user use following style in blueprint-ext :
(1) "a+b" as a key of value. eg: <property name="a+b" value="xxx" />
(2) "${a+b}" as the injection value. eg: <property name="zzz" value="${a+b}"
/> which expects the string ${a+b} to be injected to zzz.
I think the above two styles are not that useful and always bring a lot of
confusion while programming. And this is also not consistent with the
existing development experiences in JSTL. So, my point of view is not that
we must stick to jexl, I just hope we can support such evaluation natively.
Anyway, if community decides, I respect.
thanks,
-Rex
2011/9/9 Alasdair Nottingham <no...@apache.org>
> Hi,
>
> I have thought of a possible update we could do that would enable this
> without a new namespace. I'll outline it here. Make a minor update to the
> ext schema (making it 1.2.0) so we can do the following:
>
> <property-placeholder evaluator="jexl">
> <default-properties>
> <property name="name" value="value" />
> </default-properties>
> <location>file:///url</ext:location>
> </property-placeholder>
>
> The namespace handler then inserts a synthetic service dependency on a
> service of type PropertyProcessor with the service property "type=jexl".
> This means the blueprint container would only be configured while the
> desired processor is available. Then we update the code where we do the
> processing to use the PropertyProcessor service instead of having it
> hardcoded.
>
> This solves my issues around correct modularity, your issues around
> programming model simplicity, and it would also allow us to plug other
> processors/evaluators such as groovy in the future very easily.
>
> Thoughts?
> Alasdair
>
> On 9 September 2011 10:39, Timothy Ward <ti...@apache.org> wrote:
>
> >
> > Alasdair,
> >
> > Thanks for taking the time to write a test that answers my question. I
> had
> > a suspicion that this sort of thing would happen. It needs to be possible
> > for the blueprint bundle to behave consistently whether JEXL is installed
> or
> > not.
> >
> > Regards,
> >
> > Tim
> >
> > > Date: Thu, 8 Sep 2011 23:26:18 +0100
> > > Subject: Re: [Release Discussion] ship maintenance releases of
> > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > From: not@apache.org
> > > To: dev@aries.apache.org
> > >
> > > Hi,
> > >
> > > So lets get real with an example to start illustrating my issues. We
> have
> > a
> > > release already and the release is used by people, quite a few people.
> We
> > > don't know what they are doing. I have written a test. The test uses
> the
> > > sample blueprint bundle. It contains the following blueprint xml:
> > >
> > > <bean id="bar2" class="org.apache.aries.blueprint.sample.Bar">
> > >
> > > <property name="value" value="${a+b}"/>
> > >
> > > </bean>
> > >
> > > The setValue method takes a String. I have run these tests in two ways.
> > The
> > > first with jexl and the second without. If jexl isn't installed I get:
> > >
> > > ${a+b}
> > >
> > > when jexl is installed I get:
> > >
> > > 0
> > >
> > > Irrespective of how useful this is to people who want the behaviour it
> is
> > a
> > > huge problem for those people who do NOT want this behaviour. It is
> easy
> > to
> > > say "well don't install jexl then", but consider this. I have written a
> > > blueprint bundle that expects to have ${a+b} injected. I deploy it in
> > one
> > > runtime and it works the way I expect. Now I drop it into Geronimo and
> I
> > get
> > > 0 instead. So I now need to go back and rewrite my bundle to work in
> > > geronimo and I have two different bundles for each environment. This is
> > > wrong.
> > >
> > > As said before I think we need this enabled via a namespace handler and
> > an
> > > attribute. I would require the following to be added to the blueprint
> > > element:
> > >
> > > <blueprint jexl:enable="true" xmlns:jexl="
> > > http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0"/>
> > >
> > > any existing application will then behave consistently irrespective of
> > what
> > > is installed in the surrounding framework. Even the one I just created.
> > If
> > > the jexl bundle isn't installed then the jexl namespace handler is not
> > > installed so the blueprint bundle will not be processed until it is in
> > the
> > > normal way. The code in question can remain where it is, but it would
> > only
> > > be enabled if the jexl namespace is configured. Ideally we would be
> able
> > to
> > > parameterise the value processing in a pluggable way, but as long as
> the
> > > externals are right we can refactor the internals at our leisure.
> > >
> > > We are creating a programming model for OSGi here and that means we
> need
> > to
> > > get the modularity right. Currently it is not right, not only is the
> > > modularity wrong but this makes a breaking change to the way a
> > blueprint.xml
> > > is processed in what is a bug release. Irrespective of how useful this
> is
> > I
> > > do not think it is important enough to warrant a breaking change when
> we
> > can
> > > make it work without breaking existing bundles.
> > >
> > > To address your question of "Do you think it is a good idea to support
> > > this?" I do think it is a good idea, if I didn't I would have -1ed the
> > > commit rather than engaged in an email discussion to get it right.
> > >
> > > Thanks
> > > Alasdair
> > >
> > > On 8 September 2011 14:35, Rex Wang <rw...@gmail.com> wrote:
> > >
> > > > 2011/9/8 Alasdair Nottingham <no...@apache.org>
> > > >
> > > > > On 8 September 2011 10:10, Rex Wang <rw...@gmail.com> wrote:
> > > > >
> > > > > > 2011/9/8 Timothy Ward <ti...@apache.org>
> > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'm afraid I've not been paying as much attention as I should
> to
> > this
> > > > > > > thread. Reading back over the issues. I would currently vote -1
> > on
> > > > this
> > > > > > > release. I am not at all happy with the fact that users of this
> > > > support
> > > > > > will
> > > > > > > see different, potentially erroneous, behaviour depending on
> the
> > > > > presence
> > > > > > or
> > > > > > > absence of an optional dependency. Our previous statement has
> > always
> > > > > been
> > > > > > > "If a blueprint bundle wants to use some non-standard function
> it
> > > > > should
> > > > > > > declare that using an additional namespace".
> > > > > > >
> > > > > > Do you mean the statement in spec 121.4:
> > > > > > "The Blueprint XML resources in a bundle are the definitions.
> Each
> > > > > > definition can include multiple
> > > > > > namespaces. Implementations of the Blueprint core namespace must
> > > > strictly
> > > > > > follow this specification,
> > > > > > if they add additional behavior they must add additional
> namespaces
> > > > that
> > > > > > are
> > > > > > actually used in
> > > > > > the definitions to signal the deviation from this
> specification."?
> > > > > >
> > > > > > We are improving the blueprint-ext, which has been already an
> > > > additional
> > > > > > namespace to blueprint core schema. Why must we add a new
> namespace
> > to
> > > > > > extend the ability of blueprint-ext?
> > > > > >
> > > > > >
> > > > > Blueprint ext is a part of our core implementation. Adding it to
> > > > > blueprint-ext means that if you want to use ANY part of blueprint
> ext
> > you
> > > > > MUST have apache-jexl even if you don't wan to use the ${a+b}
> syntax.
> > > > This
> > > > > is wrong.
> > > > >
> > > >
> > > > Hi Alasdair,
> > > > The itests passes without adding the commons-jexl bundle now.
> > > > If you don't have commons-jexl installed, the current code can work
> as
> > > > before. Unless you want to use ${a+b}, you need guarantee the
> > commons-jexl
> > > > is present. Otherwise it will record this exception in logger. I know
> > this
> > > > is not that convenient, but at least user can know what he need to do
> > to
> > > > get
> > > > things right from the log..
> > > >
> > > > On the other hand, Java EE EL supports such style of calculation
> > natively,
> > > > I
> > > > think we should support it in blueprint-ext directly to keep the
> > consistent
> > > > of the current development experiences. In other words, if we don't
> use
> > > > commons-jexl to implement such ability, instead, we write codes by
> > > > ourselves
> > > > to do that. Do you think it is a good idea to support this? After
> all,
> > > > there
> > > > is no spec for blueprint-ext.
> > > >
> > > > thanks,
> > > > -Rex
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > > In my view this new function should only be available if the
> > optional
> > > > > > > dependency is satisfied, and blueprint bundles must enable this
> > > > > function
> > > > > > > using a custom namespace. Otherwise I see two problems.
> > > > > > >
> > > > > > >
> > > > > > > I want this new support, but have no way to ensure it is
> present,
> > as
> > > > a
> > > > > > > result I am sometimes injected with "1+2" instead of "3". This
> > leads
> > > > to
> > > > > > > intermittent NumberFormatExceptions
> > > > > > >
> > > > > > I do not want this new support, but as the dependency is
> available
> > I
> > > > am
> > > > > > > injected with "3" instead of "1+2". This leads to inconsistent
> > and
> > > > > > confusing
> > > > > > > behaviour.
> > > > > > >
> > > > > > I am not sure I understand this..
> > > > > > If you want 3, you need <xxx value="${1+2}">
> > > > > > If you want 1+2, you should use <xxx value="1+2">
> > > > > > Only the expression in ${..} will trigger the calculation, no
> > matter if
> > > > > the
> > > > > > dependency if available.
> > > > > >
> > > > > >
> > > > > I think tim is saying you want the string literal "${1+2}" not the
> > string
> > > > > 1+2. With your change if I had ${1+2} I now get 3 rather than
> ${1+2}.
> > > > This
> > > > > is a change in behaviour and should be enabled using a new
> namespace.
> > Of
> > > > > course you could just reversion the namespace from v1.x to v2 as a
> > > > breaking
> > > > > change, but we would need to support both versions of the schema.
> > > > >
> > > > > As with Tim I would currently -1 any release of blueprint 3.2 until
> > this
> > > > is
> > > > > addressed.
> > > > >
> > > > > Alasdair
> > > > >
> > > > > -Rex
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Adding a namespace for this function elegantly solves both
> these
> > > > issues
> > > > > > in
> > > > > > > a way that is consistent with other blueprint extensions, and I
> > think
> > > > > is
> > > > > > > essential before this function can be released.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Tim
> > > > > > >
> > > > > > >
> > > > > > > > From: rwonly@gmail.com
> > > > > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > > > > > > Subject: Re: [Release Discussion] ship maintenance releases
> of
> > > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > > > To: dev@aries.apache.org
> > > > > > > >
> > > > > > > > I still think adding a new namespace only for such simple
> > > > calculation
> > > > > > is
> > > > > > > too
> > > > > > > > heavy and not consumalbe for users..
> > > > > > > >
> > > > > > > > Anyway, could anybody help with the release of *
> > > > > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > > > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone
> > help
> > > > > > check
> > > > > > > why
> > > > > > > > I can not deploy artifacts to apache.snapshot? Maybe I can
> try
> > > > > release
> > > > > > > the 2
> > > > > > > > components. Geronimo does not have much time targeting the
> > 3.0-beta
> > > > > > > release.
> > > > > > > >
> > > > > > > > thanks,
> > > > > > > >
> > > > > > > > -Rex
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > > > > > > >
> > > > > > > > > If we release blueprint as is we will never be able to make
> > the
> > > > > > change
> > > > > > > as
> > > > > > > > > we
> > > > > > > > > would cause a major breaking change. I think we need to get
> > this
> > > > > > right
> > > > > > > > > before a release is done.
> > > > > > > > >
> > > > > > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com>
> > wrote:
> > > > > > > > >
> > > > > > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > > > > > > >
> > > > > > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > > > > > > vmahrwald@googlemail.com
> > > > > > > > > > > >wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Comments inline :)
> > > > > > > > > > > >
> > > > > > > > > > > > Kind regards,
> > > > > > > > > > > >
> > > > > > > > > > > > Valentin
> > > > > > > > > > > >
> > > > > > > > > > > > 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).
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > The blueprint specification says any non-standard
> > extensions
> > > > to
> > > > > > > > > blueprint
> > > > > > > > > > > must be enabled via namespace handlers. I don't like
> the
> > ext
> > > > of
> > > > > > cm
> > > > > > > > > > > namespaces to require apache-jexl since it means more
> > > > > > dependencies
> > > > > > > are
> > > > > > > > > > > pulled in when they may never be used.
> > > > > > > > > > >
> > > > > > > > > > Hi Alasdair,
> > > > > > > > > > Since the current code does not hard depend on the
> > > > commons-jexl,
> > > > > > and
> > > > > > > I
> > > > > > > > > > think
> > > > > > > > > > the only difference from your desire is adding a new
> > namespace
> > > > > > which
> > > > > > > can
> > > > > > > > > > delay the blueprint container initialization if the
> > > > commons-jexl
> > > > > is
> > > > > > > not
> > > > > > > > > > present,
> > > > > > > > > > I consider this as an improvement to the current
> solution.
> > And
> > > > I
> > > > > > > think it
> > > > > > > > > > would be better to let user hold the option that if he
> > would
> > > > use
> > > > > > the
> > > > > > > new
> > > > > > > > > > namespace, and if he don't use it, the ${a+b} can still
> > work.
> > > > > Hope
> > > > > > > the
> > > > > > > > > > current solution meets the criteria to start release..
> > > > > > > > > >
> > > > > > > > > > BTW, seems Aries community is not that active in last two
> > > > month.
> > > > > Is
> > > > > > > there
> > > > > > > > > > still a release manager help the release works?
> > > > > > > > > >
> > > > > > > > > > -Rex
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Looking at your options a) doesn't work because it
> isn't
> > > > using
> > > > > > > > > namespace
> > > > > > > > > > > handlers, b) sucks big time and would mean to meat the
> > spec
> > > > we
> > > > > > > would
> > > > > > > > > > need
> > > > > > > > > > > apache-jexl and the whole point is to allow the spec to
> > be
> > > > > > > implemented
> > > > > > > > > > > without apache-jexl being required. So I think
> something
> > > > like
> > > > > > > option c
> > > > > > > > > > > should be gone for. For instance you could add an
> > attribute
> > > > in
> > > > > a
> > > > > > > > > > > non-standard namespace that says to enable this
> > capability.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Is any of that what you were thinking of?
> > > > > > > > > > > >
> > > > > > > > > > > > > Does that make any sense?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Alasdair
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 30 August 2011 07:36, Rex Wang <
> rwonly@gmail.com>
> > > > > 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 <no...@apache.org>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>> 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 <
> > rwonly@gmail.com>
> > > > > > 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 apache.org
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> --
> > > > > > > > > > > > >> Lei Wang (Rex)
> > > > > > > > > > > > >> rwonly AT apache.org
> > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > not@apache.org
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > rwonly AT apache.org
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Alasdair Nottingham
> > > > > > > > > not@apache.org
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Lei Wang (Rex)
> > > > > > > > rwonly AT apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Lei Wang (Rex)
> > > > > > rwonly AT apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alasdair Nottingham
> > > > > not@apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Lei Wang (Rex)
> > > > rwonly AT apache.org
> > > >
> > >
> > >
> > >
> > > --
> > > Alasdair Nottingham
> > > not@apache.org
> >
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Guillaume Nodet <gn...@gmail.com>.
That sounds much better to me.
I've had the same problem with encrypted passwords and i've created a
property placeholder.
It's quite easy to chain the placeholders, so it's slightly more
verbose, but a bit cleaner.
See ENC(${foo}) in he following example:
http://svn.apache.org/repos/asf/karaf/trunk/jaas/jasypt/src/test/resources/org/apache/karaf/jaas/jasypt/handler/test.xml
On Fri, Sep 9, 2011 at 12:36, Alasdair Nottingham <no...@apache.org> wrote:
> Hi,
>
> I have thought of a possible update we could do that would enable this
> without a new namespace. I'll outline it here. Make a minor update to the
> ext schema (making it 1.2.0) so we can do the following:
>
> <property-placeholder evaluator="jexl">
> <default-properties>
> <property name="name" value="value" />
> </default-properties>
> <location>file:///url</ext:location>
> </property-placeholder>
>
> The namespace handler then inserts a synthetic service dependency on a
> service of type PropertyProcessor with the service property "type=jexl".
> This means the blueprint container would only be configured while the
> desired processor is available. Then we update the code where we do the
> processing to use the PropertyProcessor service instead of having it
> hardcoded.
>
> This solves my issues around correct modularity, your issues around
> programming model simplicity, and it would also allow us to plug other
> processors/evaluators such as groovy in the future very easily.
>
> Thoughts?
> Alasdair
>
> On 9 September 2011 10:39, Timothy Ward <ti...@apache.org> wrote:
>
>>
>> Alasdair,
>>
>> Thanks for taking the time to write a test that answers my question. I had
>> a suspicion that this sort of thing would happen. It needs to be possible
>> for the blueprint bundle to behave consistently whether JEXL is installed or
>> not.
>>
>> Regards,
>>
>> Tim
>>
>> > Date: Thu, 8 Sep 2011 23:26:18 +0100
>> > Subject: Re: [Release Discussion] ship maintenance releases of
>> application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
>> > From: not@apache.org
>> > To: dev@aries.apache.org
>> >
>> > Hi,
>> >
>> > So lets get real with an example to start illustrating my issues. We have
>> a
>> > release already and the release is used by people, quite a few people. We
>> > don't know what they are doing. I have written a test. The test uses the
>> > sample blueprint bundle. It contains the following blueprint xml:
>> >
>> > <bean id="bar2" class="org.apache.aries.blueprint.sample.Bar">
>> >
>> > <property name="value" value="${a+b}"/>
>> >
>> > </bean>
>> >
>> > The setValue method takes a String. I have run these tests in two ways.
>> The
>> > first with jexl and the second without. If jexl isn't installed I get:
>> >
>> > ${a+b}
>> >
>> > when jexl is installed I get:
>> >
>> > 0
>> >
>> > Irrespective of how useful this is to people who want the behaviour it is
>> a
>> > huge problem for those people who do NOT want this behaviour. It is easy
>> to
>> > say "well don't install jexl then", but consider this. I have written a
>> > blueprint bundle that expects to have ${a+b} injected. I deploy it in
>> one
>> > runtime and it works the way I expect. Now I drop it into Geronimo and I
>> get
>> > 0 instead. So I now need to go back and rewrite my bundle to work in
>> > geronimo and I have two different bundles for each environment. This is
>> > wrong.
>> >
>> > As said before I think we need this enabled via a namespace handler and
>> an
>> > attribute. I would require the following to be added to the blueprint
>> > element:
>> >
>> > <blueprint jexl:enable="true" xmlns:jexl="
>> > http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0"/>
>> >
>> > any existing application will then behave consistently irrespective of
>> what
>> > is installed in the surrounding framework. Even the one I just created.
>> If
>> > the jexl bundle isn't installed then the jexl namespace handler is not
>> > installed so the blueprint bundle will not be processed until it is in
>> the
>> > normal way. The code in question can remain where it is, but it would
>> only
>> > be enabled if the jexl namespace is configured. Ideally we would be able
>> to
>> > parameterise the value processing in a pluggable way, but as long as the
>> > externals are right we can refactor the internals at our leisure.
>> >
>> > We are creating a programming model for OSGi here and that means we need
>> to
>> > get the modularity right. Currently it is not right, not only is the
>> > modularity wrong but this makes a breaking change to the way a
>> blueprint.xml
>> > is processed in what is a bug release. Irrespective of how useful this is
>> I
>> > do not think it is important enough to warrant a breaking change when we
>> can
>> > make it work without breaking existing bundles.
>> >
>> > To address your question of "Do you think it is a good idea to support
>> > this?" I do think it is a good idea, if I didn't I would have -1ed the
>> > commit rather than engaged in an email discussion to get it right.
>> >
>> > Thanks
>> > Alasdair
>> >
>> > On 8 September 2011 14:35, Rex Wang <rw...@gmail.com> wrote:
>> >
>> > > 2011/9/8 Alasdair Nottingham <no...@apache.org>
>> > >
>> > > > On 8 September 2011 10:10, Rex Wang <rw...@gmail.com> wrote:
>> > > >
>> > > > > 2011/9/8 Timothy Ward <ti...@apache.org>
>> > > > >
>> > > > > >
>> > > > > > Hi,
>> > > > > >
>> > > > > > I'm afraid I've not been paying as much attention as I should to
>> this
>> > > > > > thread. Reading back over the issues. I would currently vote -1
>> on
>> > > this
>> > > > > > release. I am not at all happy with the fact that users of this
>> > > support
>> > > > > will
>> > > > > > see different, potentially erroneous, behaviour depending on the
>> > > > presence
>> > > > > or
>> > > > > > absence of an optional dependency. Our previous statement has
>> always
>> > > > been
>> > > > > > "If a blueprint bundle wants to use some non-standard function it
>> > > > should
>> > > > > > declare that using an additional namespace".
>> > > > > >
>> > > > > Do you mean the statement in spec 121.4:
>> > > > > "The Blueprint XML resources in a bundle are the definitions. Each
>> > > > > definition can include multiple
>> > > > > namespaces. Implementations of the Blueprint core namespace must
>> > > strictly
>> > > > > follow this specification,
>> > > > > if they add additional behavior they must add additional namespaces
>> > > that
>> > > > > are
>> > > > > actually used in
>> > > > > the definitions to signal the deviation from this specification."?
>> > > > >
>> > > > > We are improving the blueprint-ext, which has been already an
>> > > additional
>> > > > > namespace to blueprint core schema. Why must we add a new namespace
>> to
>> > > > > extend the ability of blueprint-ext?
>> > > > >
>> > > > >
>> > > > Blueprint ext is a part of our core implementation. Adding it to
>> > > > blueprint-ext means that if you want to use ANY part of blueprint ext
>> you
>> > > > MUST have apache-jexl even if you don't wan to use the ${a+b} syntax.
>> > > This
>> > > > is wrong.
>> > > >
>> > >
>> > > Hi Alasdair,
>> > > The itests passes without adding the commons-jexl bundle now.
>> > > If you don't have commons-jexl installed, the current code can work as
>> > > before. Unless you want to use ${a+b}, you need guarantee the
>> commons-jexl
>> > > is present. Otherwise it will record this exception in logger. I know
>> this
>> > > is not that convenient, but at least user can know what he need to do
>> to
>> > > get
>> > > things right from the log..
>> > >
>> > > On the other hand, Java EE EL supports such style of calculation
>> natively,
>> > > I
>> > > think we should support it in blueprint-ext directly to keep the
>> consistent
>> > > of the current development experiences. In other words, if we don't use
>> > > commons-jexl to implement such ability, instead, we write codes by
>> > > ourselves
>> > > to do that. Do you think it is a good idea to support this? After all,
>> > > there
>> > > is no spec for blueprint-ext.
>> > >
>> > > thanks,
>> > > -Rex
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >
>> > > >
>> > > >
>> > > > >
>> > > > > > In my view this new function should only be available if the
>> optional
>> > > > > > dependency is satisfied, and blueprint bundles must enable this
>> > > > function
>> > > > > > using a custom namespace. Otherwise I see two problems.
>> > > > > >
>> > > > > >
>> > > > > > I want this new support, but have no way to ensure it is present,
>> as
>> > > a
>> > > > > > result I am sometimes injected with "1+2" instead of "3". This
>> leads
>> > > to
>> > > > > > intermittent NumberFormatExceptions
>> > > > > >
>> > > > > I do not want this new support, but as the dependency is available
>> I
>> > > am
>> > > > > > injected with "3" instead of "1+2". This leads to inconsistent
>> and
>> > > > > confusing
>> > > > > > behaviour.
>> > > > > >
>> > > > > I am not sure I understand this..
>> > > > > If you want 3, you need <xxx value="${1+2}">
>> > > > > If you want 1+2, you should use <xxx value="1+2">
>> > > > > Only the expression in ${..} will trigger the calculation, no
>> matter if
>> > > > the
>> > > > > dependency if available.
>> > > > >
>> > > > >
>> > > > I think tim is saying you want the string literal "${1+2}" not the
>> string
>> > > > 1+2. With your change if I had ${1+2} I now get 3 rather than ${1+2}.
>> > > This
>> > > > is a change in behaviour and should be enabled using a new namespace.
>> Of
>> > > > course you could just reversion the namespace from v1.x to v2 as a
>> > > breaking
>> > > > change, but we would need to support both versions of the schema.
>> > > >
>> > > > As with Tim I would currently -1 any release of blueprint 3.2 until
>> this
>> > > is
>> > > > addressed.
>> > > >
>> > > > Alasdair
>> > > >
>> > > > -Rex
>> > > > >
>> > > > >
>> > > > > >
>> > > > > >
>> > > > > > Adding a namespace for this function elegantly solves both these
>> > > issues
>> > > > > in
>> > > > > > a way that is consistent with other blueprint extensions, and I
>> think
>> > > > is
>> > > > > > essential before this function can be released.
>> > > > > >
>> > > > > > Regards,
>> > > > > >
>> > > > > > Tim
>> > > > > >
>> > > > > >
>> > > > > > > From: rwonly@gmail.com
>> > > > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
>> > > > > > > Subject: Re: [Release Discussion] ship maintenance releases of
>> > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
>> > > > > > > To: dev@aries.apache.org
>> > > > > > >
>> > > > > > > I still think adding a new namespace only for such simple
>> > > calculation
>> > > > > is
>> > > > > > too
>> > > > > > > heavy and not consumalbe for users..
>> > > > > > >
>> > > > > > > Anyway, could anybody help with the release of *
>> > > > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
>> > > > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone
>> help
>> > > > > check
>> > > > > > why
>> > > > > > > I can not deploy artifacts to apache.snapshot? Maybe I can try
>> > > > release
>> > > > > > the 2
>> > > > > > > components. Geronimo does not have much time targeting the
>> 3.0-beta
>> > > > > > release.
>> > > > > > >
>> > > > > > > thanks,
>> > > > > > >
>> > > > > > > -Rex
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
>> > > > > > >
>> > > > > > > > If we release blueprint as is we will never be able to make
>> the
>> > > > > change
>> > > > > > as
>> > > > > > > > we
>> > > > > > > > would cause a major breaking change. I think we need to get
>> this
>> > > > > right
>> > > > > > > > before a release is done.
>> > > > > > > >
>> > > > > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com>
>> wrote:
>> > > > > > > >
>> > > > > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
>> > > > > > > > >
>> > > > > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
>> > > > > > vmahrwald@googlemail.com
>> > > > > > > > > > >wrote:
>> > > > > > > > > >
>> > > > > > > > > > > Comments inline :)
>> > > > > > > > > > >
>> > > > > > > > > > > Kind regards,
>> > > > > > > > > > >
>> > > > > > > > > > > Valentin
>> > > > > > > > > > >
>> > > > > > > > > > > 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).
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > > The blueprint specification says any non-standard
>> extensions
>> > > to
>> > > > > > > > blueprint
>> > > > > > > > > > must be enabled via namespace handlers. I don't like the
>> ext
>> > > of
>> > > > > cm
>> > > > > > > > > > namespaces to require apache-jexl since it means more
>> > > > > dependencies
>> > > > > > are
>> > > > > > > > > > pulled in when they may never be used.
>> > > > > > > > > >
>> > > > > > > > > Hi Alasdair,
>> > > > > > > > > Since the current code does not hard depend on the
>> > > commons-jexl,
>> > > > > and
>> > > > > > I
>> > > > > > > > > think
>> > > > > > > > > the only difference from your desire is adding a new
>> namespace
>> > > > > which
>> > > > > > can
>> > > > > > > > > delay the blueprint container initialization if the
>> > > commons-jexl
>> > > > is
>> > > > > > not
>> > > > > > > > > present,
>> > > > > > > > > I consider this as an improvement to the current solution.
>> And
>> > > I
>> > > > > > think it
>> > > > > > > > > would be better to let user hold the option that if he
>> would
>> > > use
>> > > > > the
>> > > > > > new
>> > > > > > > > > namespace, and if he don't use it, the ${a+b} can still
>> work.
>> > > > Hope
>> > > > > > the
>> > > > > > > > > current solution meets the criteria to start release..
>> > > > > > > > >
>> > > > > > > > > BTW, seems Aries community is not that active in last two
>> > > month.
>> > > > Is
>> > > > > > there
>> > > > > > > > > still a release manager help the release works?
>> > > > > > > > >
>> > > > > > > > > -Rex
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > Looking at your options a) doesn't work because it isn't
>> > > using
>> > > > > > > > namespace
>> > > > > > > > > > handlers, b) sucks big time and would mean to meat the
>> spec
>> > > we
>> > > > > > would
>> > > > > > > > > need
>> > > > > > > > > > apache-jexl and the whole point is to allow the spec to
>> be
>> > > > > > implemented
>> > > > > > > > > > without apache-jexl being required. So I think something
>> > > like
>> > > > > > option c
>> > > > > > > > > > should be gone for. For instance you could add an
>> attribute
>> > > in
>> > > > a
>> > > > > > > > > > non-standard namespace that says to enable this
>> capability.
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > > Is any of that what you were thinking of?
>> > > > > > > > > > >
>> > > > > > > > > > > > Does that make any sense?
>> > > > > > > > > > > >
>> > > > > > > > > > > > Alasdair
>> > > > > > > > > > > >
>> > > > > > > > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com>
>> > > > 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 <no...@apache.org>
>> > > > > > > > > > > >>
>> > > > > > > > > > > >>> 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 <
>> rwonly@gmail.com>
>> > > > > 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 apache.org
>> > > > > > > > > > > >>>
>> > > > > > > > > > > >>
>> > > > > > > > > > > >>
>> > > > > > > > > > > >>
>> > > > > > > > > > > >> --
>> > > > > > > > > > > >> Lei Wang (Rex)
>> > > > > > > > > > > >> rwonly AT apache.org
>> > > > > > > > > > > >>
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > >
>> > > > > > > > > > > > --
>> > > > > > > > > > > > Alasdair Nottingham
>> > > > > > > > > > > > not@apache.org
>> > > > > > > > > > >
>> > > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > >
>> > > > > > > > > > --
>> > > > > > > > > > Alasdair Nottingham
>> > > > > > > > > > not@apache.org
>> > > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > >
>> > > > > > > > > --
>> > > > > > > > > Lei Wang (Rex)
>> > > > > > > > > rwonly AT apache.org
>> > > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > >
>> > > > > > > > --
>> > > > > > > > Alasdair Nottingham
>> > > > > > > > not@apache.org
>> > > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > > > > --
>> > > > > > > Lei Wang (Rex)
>> > > > > > > rwonly AT apache.org
>> > > > > >
>> > > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > > > --
>> > > > > Lei Wang (Rex)
>> > > > > rwonly AT apache.org
>> > > > >
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Alasdair Nottingham
>> > > > not@apache.org
>> > > >
>> > >
>> > >
>> > >
>> > > --
>> > > Lei Wang (Rex)
>> > > rwonly AT apache.org
>> > >
>> >
>> >
>> >
>> > --
>> > Alasdair Nottingham
>> > not@apache.org
>>
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
------------------------
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
Hi Alasdair,
I just tried implement your idea of extending the current blueprint-ext
schema approach, and upload a draft patch in
https://issues.apache.org/jira/browse/ARIES-727
I also list 3 questions in the comments of that jira. Seems the #2 question
is more troublesome.
Could you please help review?
regards,
-Rex
2011/9/9 Alasdair Nottingham <no...@apache.org>
> Hi,
>
> I have thought of a possible update we could do that would enable this
> without a new namespace. I'll outline it here. Make a minor update to the
> ext schema (making it 1.2.0) so we can do the following:
>
> <property-placeholder evaluator="jexl">
> <default-properties>
> <property name="name" value="value" />
> </default-properties>
> <location>file:///url</ext:location>
> </property-placeholder>
>
> The namespace handler then inserts a synthetic service dependency on a
> service of type PropertyProcessor with the service property "type=jexl".
> This means the blueprint container would only be configured while the
> desired processor is available. Then we update the code where we do the
> processing to use the PropertyProcessor service instead of having it
> hardcoded.
>
> This solves my issues around correct modularity, your issues around
> programming model simplicity, and it would also allow us to plug other
> processors/evaluators such as groovy in the future very easily.
>
> Thoughts?
> Alasdair
>
> On 9 September 2011 10:39, Timothy Ward <ti...@apache.org> wrote:
>
> >
> > Alasdair,
> >
> > Thanks for taking the time to write a test that answers my question. I
> had
> > a suspicion that this sort of thing would happen. It needs to be possible
> > for the blueprint bundle to behave consistently whether JEXL is installed
> or
> > not.
> >
> > Regards,
> >
> > Tim
> >
> > > Date: Thu, 8 Sep 2011 23:26:18 +0100
> > > Subject: Re: [Release Discussion] ship maintenance releases of
> > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > From: not@apache.org
> > > To: dev@aries.apache.org
> > >
> > > Hi,
> > >
> > > So lets get real with an example to start illustrating my issues. We
> have
> > a
> > > release already and the release is used by people, quite a few people.
> We
> > > don't know what they are doing. I have written a test. The test uses
> the
> > > sample blueprint bundle. It contains the following blueprint xml:
> > >
> > > <bean id="bar2" class="org.apache.aries.blueprint.sample.Bar">
> > >
> > > <property name="value" value="${a+b}"/>
> > >
> > > </bean>
> > >
> > > The setValue method takes a String. I have run these tests in two ways.
> > The
> > > first with jexl and the second without. If jexl isn't installed I get:
> > >
> > > ${a+b}
> > >
> > > when jexl is installed I get:
> > >
> > > 0
> > >
> > > Irrespective of how useful this is to people who want the behaviour it
> is
> > a
> > > huge problem for those people who do NOT want this behaviour. It is
> easy
> > to
> > > say "well don't install jexl then", but consider this. I have written a
> > > blueprint bundle that expects to have ${a+b} injected. I deploy it in
> > one
> > > runtime and it works the way I expect. Now I drop it into Geronimo and
> I
> > get
> > > 0 instead. So I now need to go back and rewrite my bundle to work in
> > > geronimo and I have two different bundles for each environment. This is
> > > wrong.
> > >
> > > As said before I think we need this enabled via a namespace handler and
> > an
> > > attribute. I would require the following to be added to the blueprint
> > > element:
> > >
> > > <blueprint jexl:enable="true" xmlns:jexl="
> > > http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0"/>
> > >
> > > any existing application will then behave consistently irrespective of
> > what
> > > is installed in the surrounding framework. Even the one I just created.
> > If
> > > the jexl bundle isn't installed then the jexl namespace handler is not
> > > installed so the blueprint bundle will not be processed until it is in
> > the
> > > normal way. The code in question can remain where it is, but it would
> > only
> > > be enabled if the jexl namespace is configured. Ideally we would be
> able
> > to
> > > parameterise the value processing in a pluggable way, but as long as
> the
> > > externals are right we can refactor the internals at our leisure.
> > >
> > > We are creating a programming model for OSGi here and that means we
> need
> > to
> > > get the modularity right. Currently it is not right, not only is the
> > > modularity wrong but this makes a breaking change to the way a
> > blueprint.xml
> > > is processed in what is a bug release. Irrespective of how useful this
> is
> > I
> > > do not think it is important enough to warrant a breaking change when
> we
> > can
> > > make it work without breaking existing bundles.
> > >
> > > To address your question of "Do you think it is a good idea to support
> > > this?" I do think it is a good idea, if I didn't I would have -1ed the
> > > commit rather than engaged in an email discussion to get it right.
> > >
> > > Thanks
> > > Alasdair
> > >
> > > On 8 September 2011 14:35, Rex Wang <rw...@gmail.com> wrote:
> > >
> > > > 2011/9/8 Alasdair Nottingham <no...@apache.org>
> > > >
> > > > > On 8 September 2011 10:10, Rex Wang <rw...@gmail.com> wrote:
> > > > >
> > > > > > 2011/9/8 Timothy Ward <ti...@apache.org>
> > > > > >
> > > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I'm afraid I've not been paying as much attention as I should
> to
> > this
> > > > > > > thread. Reading back over the issues. I would currently vote -1
> > on
> > > > this
> > > > > > > release. I am not at all happy with the fact that users of this
> > > > support
> > > > > > will
> > > > > > > see different, potentially erroneous, behaviour depending on
> the
> > > > > presence
> > > > > > or
> > > > > > > absence of an optional dependency. Our previous statement has
> > always
> > > > > been
> > > > > > > "If a blueprint bundle wants to use some non-standard function
> it
> > > > > should
> > > > > > > declare that using an additional namespace".
> > > > > > >
> > > > > > Do you mean the statement in spec 121.4:
> > > > > > "The Blueprint XML resources in a bundle are the definitions.
> Each
> > > > > > definition can include multiple
> > > > > > namespaces. Implementations of the Blueprint core namespace must
> > > > strictly
> > > > > > follow this specification,
> > > > > > if they add additional behavior they must add additional
> namespaces
> > > > that
> > > > > > are
> > > > > > actually used in
> > > > > > the definitions to signal the deviation from this
> specification."?
> > > > > >
> > > > > > We are improving the blueprint-ext, which has been already an
> > > > additional
> > > > > > namespace to blueprint core schema. Why must we add a new
> namespace
> > to
> > > > > > extend the ability of blueprint-ext?
> > > > > >
> > > > > >
> > > > > Blueprint ext is a part of our core implementation. Adding it to
> > > > > blueprint-ext means that if you want to use ANY part of blueprint
> ext
> > you
> > > > > MUST have apache-jexl even if you don't wan to use the ${a+b}
> syntax.
> > > > This
> > > > > is wrong.
> > > > >
> > > >
> > > > Hi Alasdair,
> > > > The itests passes without adding the commons-jexl bundle now.
> > > > If you don't have commons-jexl installed, the current code can work
> as
> > > > before. Unless you want to use ${a+b}, you need guarantee the
> > commons-jexl
> > > > is present. Otherwise it will record this exception in logger. I know
> > this
> > > > is not that convenient, but at least user can know what he need to do
> > to
> > > > get
> > > > things right from the log..
> > > >
> > > > On the other hand, Java EE EL supports such style of calculation
> > natively,
> > > > I
> > > > think we should support it in blueprint-ext directly to keep the
> > consistent
> > > > of the current development experiences. In other words, if we don't
> use
> > > > commons-jexl to implement such ability, instead, we write codes by
> > > > ourselves
> > > > to do that. Do you think it is a good idea to support this? After
> all,
> > > > there
> > > > is no spec for blueprint-ext.
> > > >
> > > > thanks,
> > > > -Rex
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > >
> > > > >
> > > > > >
> > > > > > > In my view this new function should only be available if the
> > optional
> > > > > > > dependency is satisfied, and blueprint bundles must enable this
> > > > > function
> > > > > > > using a custom namespace. Otherwise I see two problems.
> > > > > > >
> > > > > > >
> > > > > > > I want this new support, but have no way to ensure it is
> present,
> > as
> > > > a
> > > > > > > result I am sometimes injected with "1+2" instead of "3". This
> > leads
> > > > to
> > > > > > > intermittent NumberFormatExceptions
> > > > > > >
> > > > > > I do not want this new support, but as the dependency is
> available
> > I
> > > > am
> > > > > > > injected with "3" instead of "1+2". This leads to inconsistent
> > and
> > > > > > confusing
> > > > > > > behaviour.
> > > > > > >
> > > > > > I am not sure I understand this..
> > > > > > If you want 3, you need <xxx value="${1+2}">
> > > > > > If you want 1+2, you should use <xxx value="1+2">
> > > > > > Only the expression in ${..} will trigger the calculation, no
> > matter if
> > > > > the
> > > > > > dependency if available.
> > > > > >
> > > > > >
> > > > > I think tim is saying you want the string literal "${1+2}" not the
> > string
> > > > > 1+2. With your change if I had ${1+2} I now get 3 rather than
> ${1+2}.
> > > > This
> > > > > is a change in behaviour and should be enabled using a new
> namespace.
> > Of
> > > > > course you could just reversion the namespace from v1.x to v2 as a
> > > > breaking
> > > > > change, but we would need to support both versions of the schema.
> > > > >
> > > > > As with Tim I would currently -1 any release of blueprint 3.2 until
> > this
> > > > is
> > > > > addressed.
> > > > >
> > > > > Alasdair
> > > > >
> > > > > -Rex
> > > > > >
> > > > > >
> > > > > > >
> > > > > > >
> > > > > > > Adding a namespace for this function elegantly solves both
> these
> > > > issues
> > > > > > in
> > > > > > > a way that is consistent with other blueprint extensions, and I
> > think
> > > > > is
> > > > > > > essential before this function can be released.
> > > > > > >
> > > > > > > Regards,
> > > > > > >
> > > > > > > Tim
> > > > > > >
> > > > > > >
> > > > > > > > From: rwonly@gmail.com
> > > > > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > > > > > > Subject: Re: [Release Discussion] ship maintenance releases
> of
> > > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > > > To: dev@aries.apache.org
> > > > > > > >
> > > > > > > > I still think adding a new namespace only for such simple
> > > > calculation
> > > > > > is
> > > > > > > too
> > > > > > > > heavy and not consumalbe for users..
> > > > > > > >
> > > > > > > > Anyway, could anybody help with the release of *
> > > > > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > > > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone
> > help
> > > > > > check
> > > > > > > why
> > > > > > > > I can not deploy artifacts to apache.snapshot? Maybe I can
> try
> > > > > release
> > > > > > > the 2
> > > > > > > > components. Geronimo does not have much time targeting the
> > 3.0-beta
> > > > > > > release.
> > > > > > > >
> > > > > > > > thanks,
> > > > > > > >
> > > > > > > > -Rex
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > > > > > > >
> > > > > > > > > If we release blueprint as is we will never be able to make
> > the
> > > > > > change
> > > > > > > as
> > > > > > > > > we
> > > > > > > > > would cause a major breaking change. I think we need to get
> > this
> > > > > > right
> > > > > > > > > before a release is done.
> > > > > > > > >
> > > > > > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com>
> > wrote:
> > > > > > > > >
> > > > > > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > > > > > > >
> > > > > > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > > > > > > vmahrwald@googlemail.com
> > > > > > > > > > > >wrote:
> > > > > > > > > > >
> > > > > > > > > > > > Comments inline :)
> > > > > > > > > > > >
> > > > > > > > > > > > Kind regards,
> > > > > > > > > > > >
> > > > > > > > > > > > Valentin
> > > > > > > > > > > >
> > > > > > > > > > > > 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).
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > The blueprint specification says any non-standard
> > extensions
> > > > to
> > > > > > > > > blueprint
> > > > > > > > > > > must be enabled via namespace handlers. I don't like
> the
> > ext
> > > > of
> > > > > > cm
> > > > > > > > > > > namespaces to require apache-jexl since it means more
> > > > > > dependencies
> > > > > > > are
> > > > > > > > > > > pulled in when they may never be used.
> > > > > > > > > > >
> > > > > > > > > > Hi Alasdair,
> > > > > > > > > > Since the current code does not hard depend on the
> > > > commons-jexl,
> > > > > > and
> > > > > > > I
> > > > > > > > > > think
> > > > > > > > > > the only difference from your desire is adding a new
> > namespace
> > > > > > which
> > > > > > > can
> > > > > > > > > > delay the blueprint container initialization if the
> > > > commons-jexl
> > > > > is
> > > > > > > not
> > > > > > > > > > present,
> > > > > > > > > > I consider this as an improvement to the current
> solution.
> > And
> > > > I
> > > > > > > think it
> > > > > > > > > > would be better to let user hold the option that if he
> > would
> > > > use
> > > > > > the
> > > > > > > new
> > > > > > > > > > namespace, and if he don't use it, the ${a+b} can still
> > work.
> > > > > Hope
> > > > > > > the
> > > > > > > > > > current solution meets the criteria to start release..
> > > > > > > > > >
> > > > > > > > > > BTW, seems Aries community is not that active in last two
> > > > month.
> > > > > Is
> > > > > > > there
> > > > > > > > > > still a release manager help the release works?
> > > > > > > > > >
> > > > > > > > > > -Rex
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > Looking at your options a) doesn't work because it
> isn't
> > > > using
> > > > > > > > > namespace
> > > > > > > > > > > handlers, b) sucks big time and would mean to meat the
> > spec
> > > > we
> > > > > > > would
> > > > > > > > > > need
> > > > > > > > > > > apache-jexl and the whole point is to allow the spec to
> > be
> > > > > > > implemented
> > > > > > > > > > > without apache-jexl being required. So I think
> something
> > > > like
> > > > > > > option c
> > > > > > > > > > > should be gone for. For instance you could add an
> > attribute
> > > > in
> > > > > a
> > > > > > > > > > > non-standard namespace that says to enable this
> > capability.
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > > Is any of that what you were thinking of?
> > > > > > > > > > > >
> > > > > > > > > > > > > Does that make any sense?
> > > > > > > > > > > > >
> > > > > > > > > > > > > Alasdair
> > > > > > > > > > > > >
> > > > > > > > > > > > > On 30 August 2011 07:36, Rex Wang <
> rwonly@gmail.com>
> > > > > 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 <no...@apache.org>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>> 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 <
> > rwonly@gmail.com>
> > > > > > 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 apache.org
> > > > > > > > > > > > >>>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >>
> > > > > > > > > > > > >> --
> > > > > > > > > > > > >> Lei Wang (Rex)
> > > > > > > > > > > > >> rwonly AT apache.org
> > > > > > > > > > > > >>
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > >
> > > > > > > > > > > > > --
> > > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > > not@apache.org
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > not@apache.org
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Lei Wang (Rex)
> > > > > > > > > > rwonly AT apache.org
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Alasdair Nottingham
> > > > > > > > > not@apache.org
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Lei Wang (Rex)
> > > > > > > > rwonly AT apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Lei Wang (Rex)
> > > > > > rwonly AT apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alasdair Nottingham
> > > > > not@apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Lei Wang (Rex)
> > > > rwonly AT apache.org
> > > >
> > >
> > >
> > >
> > > --
> > > Alasdair Nottingham
> > > not@apache.org
> >
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
I have thought of a possible update we could do that would enable this
without a new namespace. I'll outline it here. Make a minor update to the
ext schema (making it 1.2.0) so we can do the following:
<property-placeholder evaluator="jexl">
<default-properties>
<property name="name" value="value" />
</default-properties>
<location>file:///url</ext:location>
</property-placeholder>
The namespace handler then inserts a synthetic service dependency on a
service of type PropertyProcessor with the service property "type=jexl".
This means the blueprint container would only be configured while the
desired processor is available. Then we update the code where we do the
processing to use the PropertyProcessor service instead of having it
hardcoded.
This solves my issues around correct modularity, your issues around
programming model simplicity, and it would also allow us to plug other
processors/evaluators such as groovy in the future very easily.
Thoughts?
Alasdair
On 9 September 2011 10:39, Timothy Ward <ti...@apache.org> wrote:
>
> Alasdair,
>
> Thanks for taking the time to write a test that answers my question. I had
> a suspicion that this sort of thing would happen. It needs to be possible
> for the blueprint bundle to behave consistently whether JEXL is installed or
> not.
>
> Regards,
>
> Tim
>
> > Date: Thu, 8 Sep 2011 23:26:18 +0100
> > Subject: Re: [Release Discussion] ship maintenance releases of
> application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > From: not@apache.org
> > To: dev@aries.apache.org
> >
> > Hi,
> >
> > So lets get real with an example to start illustrating my issues. We have
> a
> > release already and the release is used by people, quite a few people. We
> > don't know what they are doing. I have written a test. The test uses the
> > sample blueprint bundle. It contains the following blueprint xml:
> >
> > <bean id="bar2" class="org.apache.aries.blueprint.sample.Bar">
> >
> > <property name="value" value="${a+b}"/>
> >
> > </bean>
> >
> > The setValue method takes a String. I have run these tests in two ways.
> The
> > first with jexl and the second without. If jexl isn't installed I get:
> >
> > ${a+b}
> >
> > when jexl is installed I get:
> >
> > 0
> >
> > Irrespective of how useful this is to people who want the behaviour it is
> a
> > huge problem for those people who do NOT want this behaviour. It is easy
> to
> > say "well don't install jexl then", but consider this. I have written a
> > blueprint bundle that expects to have ${a+b} injected. I deploy it in
> one
> > runtime and it works the way I expect. Now I drop it into Geronimo and I
> get
> > 0 instead. So I now need to go back and rewrite my bundle to work in
> > geronimo and I have two different bundles for each environment. This is
> > wrong.
> >
> > As said before I think we need this enabled via a namespace handler and
> an
> > attribute. I would require the following to be added to the blueprint
> > element:
> >
> > <blueprint jexl:enable="true" xmlns:jexl="
> > http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0"/>
> >
> > any existing application will then behave consistently irrespective of
> what
> > is installed in the surrounding framework. Even the one I just created.
> If
> > the jexl bundle isn't installed then the jexl namespace handler is not
> > installed so the blueprint bundle will not be processed until it is in
> the
> > normal way. The code in question can remain where it is, but it would
> only
> > be enabled if the jexl namespace is configured. Ideally we would be able
> to
> > parameterise the value processing in a pluggable way, but as long as the
> > externals are right we can refactor the internals at our leisure.
> >
> > We are creating a programming model for OSGi here and that means we need
> to
> > get the modularity right. Currently it is not right, not only is the
> > modularity wrong but this makes a breaking change to the way a
> blueprint.xml
> > is processed in what is a bug release. Irrespective of how useful this is
> I
> > do not think it is important enough to warrant a breaking change when we
> can
> > make it work without breaking existing bundles.
> >
> > To address your question of "Do you think it is a good idea to support
> > this?" I do think it is a good idea, if I didn't I would have -1ed the
> > commit rather than engaged in an email discussion to get it right.
> >
> > Thanks
> > Alasdair
> >
> > On 8 September 2011 14:35, Rex Wang <rw...@gmail.com> wrote:
> >
> > > 2011/9/8 Alasdair Nottingham <no...@apache.org>
> > >
> > > > On 8 September 2011 10:10, Rex Wang <rw...@gmail.com> wrote:
> > > >
> > > > > 2011/9/8 Timothy Ward <ti...@apache.org>
> > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I'm afraid I've not been paying as much attention as I should to
> this
> > > > > > thread. Reading back over the issues. I would currently vote -1
> on
> > > this
> > > > > > release. I am not at all happy with the fact that users of this
> > > support
> > > > > will
> > > > > > see different, potentially erroneous, behaviour depending on the
> > > > presence
> > > > > or
> > > > > > absence of an optional dependency. Our previous statement has
> always
> > > > been
> > > > > > "If a blueprint bundle wants to use some non-standard function it
> > > > should
> > > > > > declare that using an additional namespace".
> > > > > >
> > > > > Do you mean the statement in spec 121.4:
> > > > > "The Blueprint XML resources in a bundle are the definitions. Each
> > > > > definition can include multiple
> > > > > namespaces. Implementations of the Blueprint core namespace must
> > > strictly
> > > > > follow this specification,
> > > > > if they add additional behavior they must add additional namespaces
> > > that
> > > > > are
> > > > > actually used in
> > > > > the definitions to signal the deviation from this specification."?
> > > > >
> > > > > We are improving the blueprint-ext, which has been already an
> > > additional
> > > > > namespace to blueprint core schema. Why must we add a new namespace
> to
> > > > > extend the ability of blueprint-ext?
> > > > >
> > > > >
> > > > Blueprint ext is a part of our core implementation. Adding it to
> > > > blueprint-ext means that if you want to use ANY part of blueprint ext
> you
> > > > MUST have apache-jexl even if you don't wan to use the ${a+b} syntax.
> > > This
> > > > is wrong.
> > > >
> > >
> > > Hi Alasdair,
> > > The itests passes without adding the commons-jexl bundle now.
> > > If you don't have commons-jexl installed, the current code can work as
> > > before. Unless you want to use ${a+b}, you need guarantee the
> commons-jexl
> > > is present. Otherwise it will record this exception in logger. I know
> this
> > > is not that convenient, but at least user can know what he need to do
> to
> > > get
> > > things right from the log..
> > >
> > > On the other hand, Java EE EL supports such style of calculation
> natively,
> > > I
> > > think we should support it in blueprint-ext directly to keep the
> consistent
> > > of the current development experiences. In other words, if we don't use
> > > commons-jexl to implement such ability, instead, we write codes by
> > > ourselves
> > > to do that. Do you think it is a good idea to support this? After all,
> > > there
> > > is no spec for blueprint-ext.
> > >
> > > thanks,
> > > -Rex
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > >
> > > >
> > > > >
> > > > > > In my view this new function should only be available if the
> optional
> > > > > > dependency is satisfied, and blueprint bundles must enable this
> > > > function
> > > > > > using a custom namespace. Otherwise I see two problems.
> > > > > >
> > > > > >
> > > > > > I want this new support, but have no way to ensure it is present,
> as
> > > a
> > > > > > result I am sometimes injected with "1+2" instead of "3". This
> leads
> > > to
> > > > > > intermittent NumberFormatExceptions
> > > > > >
> > > > > I do not want this new support, but as the dependency is available
> I
> > > am
> > > > > > injected with "3" instead of "1+2". This leads to inconsistent
> and
> > > > > confusing
> > > > > > behaviour.
> > > > > >
> > > > > I am not sure I understand this..
> > > > > If you want 3, you need <xxx value="${1+2}">
> > > > > If you want 1+2, you should use <xxx value="1+2">
> > > > > Only the expression in ${..} will trigger the calculation, no
> matter if
> > > > the
> > > > > dependency if available.
> > > > >
> > > > >
> > > > I think tim is saying you want the string literal "${1+2}" not the
> string
> > > > 1+2. With your change if I had ${1+2} I now get 3 rather than ${1+2}.
> > > This
> > > > is a change in behaviour and should be enabled using a new namespace.
> Of
> > > > course you could just reversion the namespace from v1.x to v2 as a
> > > breaking
> > > > change, but we would need to support both versions of the schema.
> > > >
> > > > As with Tim I would currently -1 any release of blueprint 3.2 until
> this
> > > is
> > > > addressed.
> > > >
> > > > Alasdair
> > > >
> > > > -Rex
> > > > >
> > > > >
> > > > > >
> > > > > >
> > > > > > Adding a namespace for this function elegantly solves both these
> > > issues
> > > > > in
> > > > > > a way that is consistent with other blueprint extensions, and I
> think
> > > > is
> > > > > > essential before this function can be released.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Tim
> > > > > >
> > > > > >
> > > > > > > From: rwonly@gmail.com
> > > > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > > > > > Subject: Re: [Release Discussion] ship maintenance releases of
> > > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > > To: dev@aries.apache.org
> > > > > > >
> > > > > > > I still think adding a new namespace only for such simple
> > > calculation
> > > > > is
> > > > > > too
> > > > > > > heavy and not consumalbe for users..
> > > > > > >
> > > > > > > Anyway, could anybody help with the release of *
> > > > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone
> help
> > > > > check
> > > > > > why
> > > > > > > I can not deploy artifacts to apache.snapshot? Maybe I can try
> > > > release
> > > > > > the 2
> > > > > > > components. Geronimo does not have much time targeting the
> 3.0-beta
> > > > > > release.
> > > > > > >
> > > > > > > thanks,
> > > > > > >
> > > > > > > -Rex
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > > > > > >
> > > > > > > > If we release blueprint as is we will never be able to make
> the
> > > > > change
> > > > > > as
> > > > > > > > we
> > > > > > > > would cause a major breaking change. I think we need to get
> this
> > > > > right
> > > > > > > > before a release is done.
> > > > > > > >
> > > > > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com>
> wrote:
> > > > > > > >
> > > > > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > > > > > >
> > > > > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > > > > > vmahrwald@googlemail.com
> > > > > > > > > > >wrote:
> > > > > > > > > >
> > > > > > > > > > > Comments inline :)
> > > > > > > > > > >
> > > > > > > > > > > Kind regards,
> > > > > > > > > > >
> > > > > > > > > > > Valentin
> > > > > > > > > > >
> > > > > > > > > > > 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).
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > The blueprint specification says any non-standard
> extensions
> > > to
> > > > > > > > blueprint
> > > > > > > > > > must be enabled via namespace handlers. I don't like the
> ext
> > > of
> > > > > cm
> > > > > > > > > > namespaces to require apache-jexl since it means more
> > > > > dependencies
> > > > > > are
> > > > > > > > > > pulled in when they may never be used.
> > > > > > > > > >
> > > > > > > > > Hi Alasdair,
> > > > > > > > > Since the current code does not hard depend on the
> > > commons-jexl,
> > > > > and
> > > > > > I
> > > > > > > > > think
> > > > > > > > > the only difference from your desire is adding a new
> namespace
> > > > > which
> > > > > > can
> > > > > > > > > delay the blueprint container initialization if the
> > > commons-jexl
> > > > is
> > > > > > not
> > > > > > > > > present,
> > > > > > > > > I consider this as an improvement to the current solution.
> And
> > > I
> > > > > > think it
> > > > > > > > > would be better to let user hold the option that if he
> would
> > > use
> > > > > the
> > > > > > new
> > > > > > > > > namespace, and if he don't use it, the ${a+b} can still
> work.
> > > > Hope
> > > > > > the
> > > > > > > > > current solution meets the criteria to start release..
> > > > > > > > >
> > > > > > > > > BTW, seems Aries community is not that active in last two
> > > month.
> > > > Is
> > > > > > there
> > > > > > > > > still a release manager help the release works?
> > > > > > > > >
> > > > > > > > > -Rex
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > Looking at your options a) doesn't work because it isn't
> > > using
> > > > > > > > namespace
> > > > > > > > > > handlers, b) sucks big time and would mean to meat the
> spec
> > > we
> > > > > > would
> > > > > > > > > need
> > > > > > > > > > apache-jexl and the whole point is to allow the spec to
> be
> > > > > > implemented
> > > > > > > > > > without apache-jexl being required. So I think something
> > > like
> > > > > > option c
> > > > > > > > > > should be gone for. For instance you could add an
> attribute
> > > in
> > > > a
> > > > > > > > > > non-standard namespace that says to enable this
> capability.
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > > Is any of that what you were thinking of?
> > > > > > > > > > >
> > > > > > > > > > > > Does that make any sense?
> > > > > > > > > > > >
> > > > > > > > > > > > Alasdair
> > > > > > > > > > > >
> > > > > > > > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com>
> > > > 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 <no...@apache.org>
> > > > > > > > > > > >>
> > > > > > > > > > > >>> 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 <
> rwonly@gmail.com>
> > > > > 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 apache.org
> > > > > > > > > > > >>>
> > > > > > > > > > > >>
> > > > > > > > > > > >>
> > > > > > > > > > > >>
> > > > > > > > > > > >> --
> > > > > > > > > > > >> Lei Wang (Rex)
> > > > > > > > > > > >> rwonly AT apache.org
> > > > > > > > > > > >>
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > >
> > > > > > > > > > > > --
> > > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > > not@apache.org
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > not@apache.org
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Lei Wang (Rex)
> > > > > > > > > rwonly AT apache.org
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Alasdair Nottingham
> > > > > > > > not@apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Lei Wang (Rex)
> > > > > > > rwonly AT apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Lei Wang (Rex)
> > > > > rwonly AT apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alasdair Nottingham
> > > > not@apache.org
> > > >
> > >
> > >
> > >
> > > --
> > > Lei Wang (Rex)
> > > rwonly AT apache.org
> > >
> >
> >
> >
> > --
> > Alasdair Nottingham
> > not@apache.org
>
>
--
Alasdair Nottingham
not@apache.org
RE: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Timothy Ward <ti...@apache.org>.
Alasdair,
Thanks for taking the time to write a test that answers my question. I had a suspicion that this sort of thing would happen. It needs to be possible for the blueprint bundle to behave consistently whether JEXL is installed or not.
Regards,
Tim
> Date: Thu, 8 Sep 2011 23:26:18 +0100
> Subject: Re: [Release Discussion] ship maintenance releases of application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> From: not@apache.org
> To: dev@aries.apache.org
>
> Hi,
>
> So lets get real with an example to start illustrating my issues. We have a
> release already and the release is used by people, quite a few people. We
> don't know what they are doing. I have written a test. The test uses the
> sample blueprint bundle. It contains the following blueprint xml:
>
> <bean id="bar2" class="org.apache.aries.blueprint.sample.Bar">
>
> <property name="value" value="${a+b}"/>
>
> </bean>
>
> The setValue method takes a String. I have run these tests in two ways. The
> first with jexl and the second without. If jexl isn't installed I get:
>
> ${a+b}
>
> when jexl is installed I get:
>
> 0
>
> Irrespective of how useful this is to people who want the behaviour it is a
> huge problem for those people who do NOT want this behaviour. It is easy to
> say "well don't install jexl then", but consider this. I have written a
> blueprint bundle that expects to have ${a+b} injected. I deploy it in one
> runtime and it works the way I expect. Now I drop it into Geronimo and I get
> 0 instead. So I now need to go back and rewrite my bundle to work in
> geronimo and I have two different bundles for each environment. This is
> wrong.
>
> As said before I think we need this enabled via a namespace handler and an
> attribute. I would require the following to be added to the blueprint
> element:
>
> <blueprint jexl:enable="true" xmlns:jexl="
> http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0"/>
>
> any existing application will then behave consistently irrespective of what
> is installed in the surrounding framework. Even the one I just created. If
> the jexl bundle isn't installed then the jexl namespace handler is not
> installed so the blueprint bundle will not be processed until it is in the
> normal way. The code in question can remain where it is, but it would only
> be enabled if the jexl namespace is configured. Ideally we would be able to
> parameterise the value processing in a pluggable way, but as long as the
> externals are right we can refactor the internals at our leisure.
>
> We are creating a programming model for OSGi here and that means we need to
> get the modularity right. Currently it is not right, not only is the
> modularity wrong but this makes a breaking change to the way a blueprint.xml
> is processed in what is a bug release. Irrespective of how useful this is I
> do not think it is important enough to warrant a breaking change when we can
> make it work without breaking existing bundles.
>
> To address your question of "Do you think it is a good idea to support
> this?" I do think it is a good idea, if I didn't I would have -1ed the
> commit rather than engaged in an email discussion to get it right.
>
> Thanks
> Alasdair
>
> On 8 September 2011 14:35, Rex Wang <rw...@gmail.com> wrote:
>
> > 2011/9/8 Alasdair Nottingham <no...@apache.org>
> >
> > > On 8 September 2011 10:10, Rex Wang <rw...@gmail.com> wrote:
> > >
> > > > 2011/9/8 Timothy Ward <ti...@apache.org>
> > > >
> > > > >
> > > > > Hi,
> > > > >
> > > > > I'm afraid I've not been paying as much attention as I should to this
> > > > > thread. Reading back over the issues. I would currently vote -1 on
> > this
> > > > > release. I am not at all happy with the fact that users of this
> > support
> > > > will
> > > > > see different, potentially erroneous, behaviour depending on the
> > > presence
> > > > or
> > > > > absence of an optional dependency. Our previous statement has always
> > > been
> > > > > "If a blueprint bundle wants to use some non-standard function it
> > > should
> > > > > declare that using an additional namespace".
> > > > >
> > > > Do you mean the statement in spec 121.4:
> > > > "The Blueprint XML resources in a bundle are the definitions. Each
> > > > definition can include multiple
> > > > namespaces. Implementations of the Blueprint core namespace must
> > strictly
> > > > follow this specification,
> > > > if they add additional behavior they must add additional namespaces
> > that
> > > > are
> > > > actually used in
> > > > the definitions to signal the deviation from this specification."?
> > > >
> > > > We are improving the blueprint-ext, which has been already an
> > additional
> > > > namespace to blueprint core schema. Why must we add a new namespace to
> > > > extend the ability of blueprint-ext?
> > > >
> > > >
> > > Blueprint ext is a part of our core implementation. Adding it to
> > > blueprint-ext means that if you want to use ANY part of blueprint ext you
> > > MUST have apache-jexl even if you don't wan to use the ${a+b} syntax.
> > This
> > > is wrong.
> > >
> >
> > Hi Alasdair,
> > The itests passes without adding the commons-jexl bundle now.
> > If you don't have commons-jexl installed, the current code can work as
> > before. Unless you want to use ${a+b}, you need guarantee the commons-jexl
> > is present. Otherwise it will record this exception in logger. I know this
> > is not that convenient, but at least user can know what he need to do to
> > get
> > things right from the log..
> >
> > On the other hand, Java EE EL supports such style of calculation natively,
> > I
> > think we should support it in blueprint-ext directly to keep the consistent
> > of the current development experiences. In other words, if we don't use
> > commons-jexl to implement such ability, instead, we write codes by
> > ourselves
> > to do that. Do you think it is a good idea to support this? After all,
> > there
> > is no spec for blueprint-ext.
> >
> > thanks,
> > -Rex
> >
> >
> >
> >
> >
> >
> >
> > >
> > >
> > > >
> > > > > In my view this new function should only be available if the optional
> > > > > dependency is satisfied, and blueprint bundles must enable this
> > > function
> > > > > using a custom namespace. Otherwise I see two problems.
> > > > >
> > > > >
> > > > > I want this new support, but have no way to ensure it is present, as
> > a
> > > > > result I am sometimes injected with "1+2" instead of "3". This leads
> > to
> > > > > intermittent NumberFormatExceptions
> > > > >
> > > > I do not want this new support, but as the dependency is available I
> > am
> > > > > injected with "3" instead of "1+2". This leads to inconsistent and
> > > > confusing
> > > > > behaviour.
> > > > >
> > > > I am not sure I understand this..
> > > > If you want 3, you need <xxx value="${1+2}">
> > > > If you want 1+2, you should use <xxx value="1+2">
> > > > Only the expression in ${..} will trigger the calculation, no matter if
> > > the
> > > > dependency if available.
> > > >
> > > >
> > > I think tim is saying you want the string literal "${1+2}" not the string
> > > 1+2. With your change if I had ${1+2} I now get 3 rather than ${1+2}.
> > This
> > > is a change in behaviour and should be enabled using a new namespace. Of
> > > course you could just reversion the namespace from v1.x to v2 as a
> > breaking
> > > change, but we would need to support both versions of the schema.
> > >
> > > As with Tim I would currently -1 any release of blueprint 3.2 until this
> > is
> > > addressed.
> > >
> > > Alasdair
> > >
> > > -Rex
> > > >
> > > >
> > > > >
> > > > >
> > > > > Adding a namespace for this function elegantly solves both these
> > issues
> > > > in
> > > > > a way that is consistent with other blueprint extensions, and I think
> > > is
> > > > > essential before this function can be released.
> > > > >
> > > > > Regards,
> > > > >
> > > > > Tim
> > > > >
> > > > >
> > > > > > From: rwonly@gmail.com
> > > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > > > > Subject: Re: [Release Discussion] ship maintenance releases of
> > > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > > To: dev@aries.apache.org
> > > > > >
> > > > > > I still think adding a new namespace only for such simple
> > calculation
> > > > is
> > > > > too
> > > > > > heavy and not consumalbe for users..
> > > > > >
> > > > > > Anyway, could anybody help with the release of *
> > > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help
> > > > check
> > > > > why
> > > > > > I can not deploy artifacts to apache.snapshot? Maybe I can try
> > > release
> > > > > the 2
> > > > > > components. Geronimo does not have much time targeting the 3.0-beta
> > > > > release.
> > > > > >
> > > > > > thanks,
> > > > > >
> > > > > > -Rex
> > > > > >
> > > > > >
> > > > > >
> > > > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > > > > >
> > > > > > > If we release blueprint as is we will never be able to make the
> > > > change
> > > > > as
> > > > > > > we
> > > > > > > would cause a major breaking change. I think we need to get this
> > > > right
> > > > > > > before a release is done.
> > > > > > >
> > > > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
> > > > > > >
> > > > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > > > > >
> > > > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > > > > vmahrwald@googlemail.com
> > > > > > > > > >wrote:
> > > > > > > > >
> > > > > > > > > > Comments inline :)
> > > > > > > > > >
> > > > > > > > > > Kind regards,
> > > > > > > > > >
> > > > > > > > > > Valentin
> > > > > > > > > >
> > > > > > > > > > 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).
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > The blueprint specification says any non-standard extensions
> > to
> > > > > > > blueprint
> > > > > > > > > must be enabled via namespace handlers. I don't like the ext
> > of
> > > > cm
> > > > > > > > > namespaces to require apache-jexl since it means more
> > > > dependencies
> > > > > are
> > > > > > > > > pulled in when they may never be used.
> > > > > > > > >
> > > > > > > > Hi Alasdair,
> > > > > > > > Since the current code does not hard depend on the
> > commons-jexl,
> > > > and
> > > > > I
> > > > > > > > think
> > > > > > > > the only difference from your desire is adding a new namespace
> > > > which
> > > > > can
> > > > > > > > delay the blueprint container initialization if the
> > commons-jexl
> > > is
> > > > > not
> > > > > > > > present,
> > > > > > > > I consider this as an improvement to the current solution. And
> > I
> > > > > think it
> > > > > > > > would be better to let user hold the option that if he would
> > use
> > > > the
> > > > > new
> > > > > > > > namespace, and if he don't use it, the ${a+b} can still work.
> > > Hope
> > > > > the
> > > > > > > > current solution meets the criteria to start release..
> > > > > > > >
> > > > > > > > BTW, seems Aries community is not that active in last two
> > month.
> > > Is
> > > > > there
> > > > > > > > still a release manager help the release works?
> > > > > > > >
> > > > > > > > -Rex
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > >
> > > > > > > > > Looking at your options a) doesn't work because it isn't
> > using
> > > > > > > namespace
> > > > > > > > > handlers, b) sucks big time and would mean to meat the spec
> > we
> > > > > would
> > > > > > > > need
> > > > > > > > > apache-jexl and the whole point is to allow the spec to be
> > > > > implemented
> > > > > > > > > without apache-jexl being required. So I think something
> > like
> > > > > option c
> > > > > > > > > should be gone for. For instance you could add an attribute
> > in
> > > a
> > > > > > > > > non-standard namespace that says to enable this capability.
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > > Is any of that what you were thinking of?
> > > > > > > > > >
> > > > > > > > > > > Does that make any sense?
> > > > > > > > > > >
> > > > > > > > > > > Alasdair
> > > > > > > > > > >
> > > > > > > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com>
> > > 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 <no...@apache.org>
> > > > > > > > > > >>
> > > > > > > > > > >>> 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 <rw...@gmail.com>
> > > > 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 apache.org
> > > > > > > > > > >>>
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >>
> > > > > > > > > > >> --
> > > > > > > > > > >> Lei Wang (Rex)
> > > > > > > > > > >> rwonly AT apache.org
> > > > > > > > > > >>
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > >
> > > > > > > > > > > --
> > > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > > not@apache.org
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Alasdair Nottingham
> > > > > > > > > not@apache.org
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Lei Wang (Rex)
> > > > > > > > rwonly AT apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Alasdair Nottingham
> > > > > > > not@apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Lei Wang (Rex)
> > > > > > rwonly AT apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Lei Wang (Rex)
> > > > rwonly AT apache.org
> > > >
> > >
> > >
> > >
> > > --
> > > Alasdair Nottingham
> > > not@apache.org
> > >
> >
> >
> >
> > --
> > Lei Wang (Rex)
> > rwonly AT apache.org
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Alasdair Nottingham <no...@apache.org>.
Hi,
So lets get real with an example to start illustrating my issues. We have a
release already and the release is used by people, quite a few people. We
don't know what they are doing. I have written a test. The test uses the
sample blueprint bundle. It contains the following blueprint xml:
<bean id="bar2" class="org.apache.aries.blueprint.sample.Bar">
<property name="value" value="${a+b}"/>
</bean>
The setValue method takes a String. I have run these tests in two ways. The
first with jexl and the second without. If jexl isn't installed I get:
${a+b}
when jexl is installed I get:
0
Irrespective of how useful this is to people who want the behaviour it is a
huge problem for those people who do NOT want this behaviour. It is easy to
say "well don't install jexl then", but consider this. I have written a
blueprint bundle that expects to have ${a+b} injected. I deploy it in one
runtime and it works the way I expect. Now I drop it into Geronimo and I get
0 instead. So I now need to go back and rewrite my bundle to work in
geronimo and I have two different bundles for each environment. This is
wrong.
As said before I think we need this enabled via a namespace handler and an
attribute. I would require the following to be added to the blueprint
element:
<blueprint jexl:enable="true" xmlns:jexl="
http://aries.apache.org/blueprint/xmlns/blueprint-jexl/v1.0.0"/>
any existing application will then behave consistently irrespective of what
is installed in the surrounding framework. Even the one I just created. If
the jexl bundle isn't installed then the jexl namespace handler is not
installed so the blueprint bundle will not be processed until it is in the
normal way. The code in question can remain where it is, but it would only
be enabled if the jexl namespace is configured. Ideally we would be able to
parameterise the value processing in a pluggable way, but as long as the
externals are right we can refactor the internals at our leisure.
We are creating a programming model for OSGi here and that means we need to
get the modularity right. Currently it is not right, not only is the
modularity wrong but this makes a breaking change to the way a blueprint.xml
is processed in what is a bug release. Irrespective of how useful this is I
do not think it is important enough to warrant a breaking change when we can
make it work without breaking existing bundles.
To address your question of "Do you think it is a good idea to support
this?" I do think it is a good idea, if I didn't I would have -1ed the
commit rather than engaged in an email discussion to get it right.
Thanks
Alasdair
On 8 September 2011 14:35, Rex Wang <rw...@gmail.com> wrote:
> 2011/9/8 Alasdair Nottingham <no...@apache.org>
>
> > On 8 September 2011 10:10, Rex Wang <rw...@gmail.com> wrote:
> >
> > > 2011/9/8 Timothy Ward <ti...@apache.org>
> > >
> > > >
> > > > Hi,
> > > >
> > > > I'm afraid I've not been paying as much attention as I should to this
> > > > thread. Reading back over the issues. I would currently vote -1 on
> this
> > > > release. I am not at all happy with the fact that users of this
> support
> > > will
> > > > see different, potentially erroneous, behaviour depending on the
> > presence
> > > or
> > > > absence of an optional dependency. Our previous statement has always
> > been
> > > > "If a blueprint bundle wants to use some non-standard function it
> > should
> > > > declare that using an additional namespace".
> > > >
> > > Do you mean the statement in spec 121.4:
> > > "The Blueprint XML resources in a bundle are the definitions. Each
> > > definition can include multiple
> > > namespaces. Implementations of the Blueprint core namespace must
> strictly
> > > follow this specification,
> > > if they add additional behavior they must add additional namespaces
> that
> > > are
> > > actually used in
> > > the definitions to signal the deviation from this specification."?
> > >
> > > We are improving the blueprint-ext, which has been already an
> additional
> > > namespace to blueprint core schema. Why must we add a new namespace to
> > > extend the ability of blueprint-ext?
> > >
> > >
> > Blueprint ext is a part of our core implementation. Adding it to
> > blueprint-ext means that if you want to use ANY part of blueprint ext you
> > MUST have apache-jexl even if you don't wan to use the ${a+b} syntax.
> This
> > is wrong.
> >
>
> Hi Alasdair,
> The itests passes without adding the commons-jexl bundle now.
> If you don't have commons-jexl installed, the current code can work as
> before. Unless you want to use ${a+b}, you need guarantee the commons-jexl
> is present. Otherwise it will record this exception in logger. I know this
> is not that convenient, but at least user can know what he need to do to
> get
> things right from the log..
>
> On the other hand, Java EE EL supports such style of calculation natively,
> I
> think we should support it in blueprint-ext directly to keep the consistent
> of the current development experiences. In other words, if we don't use
> commons-jexl to implement such ability, instead, we write codes by
> ourselves
> to do that. Do you think it is a good idea to support this? After all,
> there
> is no spec for blueprint-ext.
>
> thanks,
> -Rex
>
>
>
>
>
>
>
> >
> >
> > >
> > > > In my view this new function should only be available if the optional
> > > > dependency is satisfied, and blueprint bundles must enable this
> > function
> > > > using a custom namespace. Otherwise I see two problems.
> > > >
> > > >
> > > > I want this new support, but have no way to ensure it is present, as
> a
> > > > result I am sometimes injected with "1+2" instead of "3". This leads
> to
> > > > intermittent NumberFormatExceptions
> > > >
> > > I do not want this new support, but as the dependency is available I
> am
> > > > injected with "3" instead of "1+2". This leads to inconsistent and
> > > confusing
> > > > behaviour.
> > > >
> > > I am not sure I understand this..
> > > If you want 3, you need <xxx value="${1+2}">
> > > If you want 1+2, you should use <xxx value="1+2">
> > > Only the expression in ${..} will trigger the calculation, no matter if
> > the
> > > dependency if available.
> > >
> > >
> > I think tim is saying you want the string literal "${1+2}" not the string
> > 1+2. With your change if I had ${1+2} I now get 3 rather than ${1+2}.
> This
> > is a change in behaviour and should be enabled using a new namespace. Of
> > course you could just reversion the namespace from v1.x to v2 as a
> breaking
> > change, but we would need to support both versions of the schema.
> >
> > As with Tim I would currently -1 any release of blueprint 3.2 until this
> is
> > addressed.
> >
> > Alasdair
> >
> > -Rex
> > >
> > >
> > > >
> > > >
> > > > Adding a namespace for this function elegantly solves both these
> issues
> > > in
> > > > a way that is consistent with other blueprint extensions, and I think
> > is
> > > > essential before this function can be released.
> > > >
> > > > Regards,
> > > >
> > > > Tim
> > > >
> > > >
> > > > > From: rwonly@gmail.com
> > > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > > > Subject: Re: [Release Discussion] ship maintenance releases of
> > > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > > To: dev@aries.apache.org
> > > > >
> > > > > I still think adding a new namespace only for such simple
> calculation
> > > is
> > > > too
> > > > > heavy and not consumalbe for users..
> > > > >
> > > > > Anyway, could anybody help with the release of *
> > > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help
> > > check
> > > > why
> > > > > I can not deploy artifacts to apache.snapshot? Maybe I can try
> > release
> > > > the 2
> > > > > components. Geronimo does not have much time targeting the 3.0-beta
> > > > release.
> > > > >
> > > > > thanks,
> > > > >
> > > > > -Rex
> > > > >
> > > > >
> > > > >
> > > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > > > >
> > > > > > If we release blueprint as is we will never be able to make the
> > > change
> > > > as
> > > > > > we
> > > > > > would cause a major breaking change. I think we need to get this
> > > right
> > > > > > before a release is done.
> > > > > >
> > > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
> > > > > >
> > > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > > > >
> > > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > > > vmahrwald@googlemail.com
> > > > > > > > >wrote:
> > > > > > > >
> > > > > > > > > Comments inline :)
> > > > > > > > >
> > > > > > > > > Kind regards,
> > > > > > > > >
> > > > > > > > > Valentin
> > > > > > > > >
> > > > > > > > > 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).
> > > > > > > > >
> > > > > > > > >
> > > > > > > > The blueprint specification says any non-standard extensions
> to
> > > > > > blueprint
> > > > > > > > must be enabled via namespace handlers. I don't like the ext
> of
> > > cm
> > > > > > > > namespaces to require apache-jexl since it means more
> > > dependencies
> > > > are
> > > > > > > > pulled in when they may never be used.
> > > > > > > >
> > > > > > > Hi Alasdair,
> > > > > > > Since the current code does not hard depend on the
> commons-jexl,
> > > and
> > > > I
> > > > > > > think
> > > > > > > the only difference from your desire is adding a new namespace
> > > which
> > > > can
> > > > > > > delay the blueprint container initialization if the
> commons-jexl
> > is
> > > > not
> > > > > > > present,
> > > > > > > I consider this as an improvement to the current solution. And
> I
> > > > think it
> > > > > > > would be better to let user hold the option that if he would
> use
> > > the
> > > > new
> > > > > > > namespace, and if he don't use it, the ${a+b} can still work.
> > Hope
> > > > the
> > > > > > > current solution meets the criteria to start release..
> > > > > > >
> > > > > > > BTW, seems Aries community is not that active in last two
> month.
> > Is
> > > > there
> > > > > > > still a release manager help the release works?
> > > > > > >
> > > > > > > -Rex
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > >
> > > > > > > > Looking at your options a) doesn't work because it isn't
> using
> > > > > > namespace
> > > > > > > > handlers, b) sucks big time and would mean to meat the spec
> we
> > > > would
> > > > > > > need
> > > > > > > > apache-jexl and the whole point is to allow the spec to be
> > > > implemented
> > > > > > > > without apache-jexl being required. So I think something
> like
> > > > option c
> > > > > > > > should be gone for. For instance you could add an attribute
> in
> > a
> > > > > > > > non-standard namespace that says to enable this capability.
> > > > > > > >
> > > > > > > >
> > > > > > > > > Is any of that what you were thinking of?
> > > > > > > > >
> > > > > > > > > > Does that make any sense?
> > > > > > > > > >
> > > > > > > > > > Alasdair
> > > > > > > > > >
> > > > > > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com>
> > 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 <no...@apache.org>
> > > > > > > > > >>
> > > > > > > > > >>> 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 <rw...@gmail.com>
> > > 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 apache.org
> > > > > > > > > >>>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >>
> > > > > > > > > >> --
> > > > > > > > > >> Lei Wang (Rex)
> > > > > > > > > >> rwonly AT apache.org
> > > > > > > > > >>
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > Alasdair Nottingham
> > > > > > > > > > not@apache.org
> > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Alasdair Nottingham
> > > > > > > > not@apache.org
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Lei Wang (Rex)
> > > > > > > rwonly AT apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Alasdair Nottingham
> > > > > > not@apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Lei Wang (Rex)
> > > > > rwonly AT apache.org
> > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Lei Wang (Rex)
> > > rwonly AT apache.org
> > >
> >
> >
> >
> > --
> > Alasdair Nottingham
> > not@apache.org
> >
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>
--
Alasdair Nottingham
not@apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
2011/9/8 Alasdair Nottingham <no...@apache.org>
> On 8 September 2011 10:10, Rex Wang <rw...@gmail.com> wrote:
>
> > 2011/9/8 Timothy Ward <ti...@apache.org>
> >
> > >
> > > Hi,
> > >
> > > I'm afraid I've not been paying as much attention as I should to this
> > > thread. Reading back over the issues. I would currently vote -1 on this
> > > release. I am not at all happy with the fact that users of this support
> > will
> > > see different, potentially erroneous, behaviour depending on the
> presence
> > or
> > > absence of an optional dependency. Our previous statement has always
> been
> > > "If a blueprint bundle wants to use some non-standard function it
> should
> > > declare that using an additional namespace".
> > >
> > Do you mean the statement in spec 121.4:
> > "The Blueprint XML resources in a bundle are the definitions. Each
> > definition can include multiple
> > namespaces. Implementations of the Blueprint core namespace must strictly
> > follow this specification,
> > if they add additional behavior they must add additional namespaces that
> > are
> > actually used in
> > the definitions to signal the deviation from this specification."?
> >
> > We are improving the blueprint-ext, which has been already an additional
> > namespace to blueprint core schema. Why must we add a new namespace to
> > extend the ability of blueprint-ext?
> >
> >
> Blueprint ext is a part of our core implementation. Adding it to
> blueprint-ext means that if you want to use ANY part of blueprint ext you
> MUST have apache-jexl even if you don't wan to use the ${a+b} syntax. This
> is wrong.
>
Hi Alasdair,
The itests passes without adding the commons-jexl bundle now.
If you don't have commons-jexl installed, the current code can work as
before. Unless you want to use ${a+b}, you need guarantee the commons-jexl
is present. Otherwise it will record this exception in logger. I know this
is not that convenient, but at least user can know what he need to do to get
things right from the log..
On the other hand, Java EE EL supports such style of calculation natively, I
think we should support it in blueprint-ext directly to keep the consistent
of the current development experiences. In other words, if we don't use
commons-jexl to implement such ability, instead, we write codes by ourselves
to do that. Do you think it is a good idea to support this? After all, there
is no spec for blueprint-ext.
thanks,
-Rex
>
>
> >
> > > In my view this new function should only be available if the optional
> > > dependency is satisfied, and blueprint bundles must enable this
> function
> > > using a custom namespace. Otherwise I see two problems.
> > >
> > >
> > > I want this new support, but have no way to ensure it is present, as a
> > > result I am sometimes injected with "1+2" instead of "3". This leads to
> > > intermittent NumberFormatExceptions
> > >
> > I do not want this new support, but as the dependency is available I am
> > > injected with "3" instead of "1+2". This leads to inconsistent and
> > confusing
> > > behaviour.
> > >
> > I am not sure I understand this..
> > If you want 3, you need <xxx value="${1+2}">
> > If you want 1+2, you should use <xxx value="1+2">
> > Only the expression in ${..} will trigger the calculation, no matter if
> the
> > dependency if available.
> >
> >
> I think tim is saying you want the string literal "${1+2}" not the string
> 1+2. With your change if I had ${1+2} I now get 3 rather than ${1+2}. This
> is a change in behaviour and should be enabled using a new namespace. Of
> course you could just reversion the namespace from v1.x to v2 as a breaking
> change, but we would need to support both versions of the schema.
>
> As with Tim I would currently -1 any release of blueprint 3.2 until this is
> addressed.
>
> Alasdair
>
> -Rex
> >
> >
> > >
> > >
> > > Adding a namespace for this function elegantly solves both these issues
> > in
> > > a way that is consistent with other blueprint extensions, and I think
> is
> > > essential before this function can be released.
> > >
> > > Regards,
> > >
> > > Tim
> > >
> > >
> > > > From: rwonly@gmail.com
> > > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > > Subject: Re: [Release Discussion] ship maintenance releases of
> > > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > > To: dev@aries.apache.org
> > > >
> > > > I still think adding a new namespace only for such simple calculation
> > is
> > > too
> > > > heavy and not consumalbe for users..
> > > >
> > > > Anyway, could anybody help with the release of *
> > > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help
> > check
> > > why
> > > > I can not deploy artifacts to apache.snapshot? Maybe I can try
> release
> > > the 2
> > > > components. Geronimo does not have much time targeting the 3.0-beta
> > > release.
> > > >
> > > > thanks,
> > > >
> > > > -Rex
> > > >
> > > >
> > > >
> > > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > > >
> > > > > If we release blueprint as is we will never be able to make the
> > change
> > > as
> > > > > we
> > > > > would cause a major breaking change. I think we need to get this
> > right
> > > > > before a release is done.
> > > > >
> > > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
> > > > >
> > > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > > >
> > > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > > vmahrwald@googlemail.com
> > > > > > > >wrote:
> > > > > > >
> > > > > > > > Comments inline :)
> > > > > > > >
> > > > > > > > Kind regards,
> > > > > > > >
> > > > > > > > Valentin
> > > > > > > >
> > > > > > > > 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).
> > > > > > > >
> > > > > > > >
> > > > > > > The blueprint specification says any non-standard extensions to
> > > > > blueprint
> > > > > > > must be enabled via namespace handlers. I don't like the ext of
> > cm
> > > > > > > namespaces to require apache-jexl since it means more
> > dependencies
> > > are
> > > > > > > pulled in when they may never be used.
> > > > > > >
> > > > > > Hi Alasdair,
> > > > > > Since the current code does not hard depend on the commons-jexl,
> > and
> > > I
> > > > > > think
> > > > > > the only difference from your desire is adding a new namespace
> > which
> > > can
> > > > > > delay the blueprint container initialization if the commons-jexl
> is
> > > not
> > > > > > present,
> > > > > > I consider this as an improvement to the current solution. And I
> > > think it
> > > > > > would be better to let user hold the option that if he would use
> > the
> > > new
> > > > > > namespace, and if he don't use it, the ${a+b} can still work.
> Hope
> > > the
> > > > > > current solution meets the criteria to start release..
> > > > > >
> > > > > > BTW, seems Aries community is not that active in last two month.
> Is
> > > there
> > > > > > still a release manager help the release works?
> > > > > >
> > > > > > -Rex
> > > > > >
> > > > > >
> > > > > >
> > > > > > >
> > > > > > > Looking at your options a) doesn't work because it isn't using
> > > > > namespace
> > > > > > > handlers, b) sucks big time and would mean to meat the spec we
> > > would
> > > > > > need
> > > > > > > apache-jexl and the whole point is to allow the spec to be
> > > implemented
> > > > > > > without apache-jexl being required. So I think something like
> > > option c
> > > > > > > should be gone for. For instance you could add an attribute in
> a
> > > > > > > non-standard namespace that says to enable this capability.
> > > > > > >
> > > > > > >
> > > > > > > > Is any of that what you were thinking of?
> > > > > > > >
> > > > > > > > > Does that make any sense?
> > > > > > > > >
> > > > > > > > > Alasdair
> > > > > > > > >
> > > > > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com>
> 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 <no...@apache.org>
> > > > > > > > >>
> > > > > > > > >>> 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 <rw...@gmail.com>
> > 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 apache.org
> > > > > > > > >>>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >>
> > > > > > > > >> --
> > > > > > > > >> Lei Wang (Rex)
> > > > > > > > >> rwonly AT apache.org
> > > > > > > > >>
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > Alasdair Nottingham
> > > > > > > > > not@apache.org
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Alasdair Nottingham
> > > > > > > not@apache.org
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Lei Wang (Rex)
> > > > > > rwonly AT apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alasdair Nottingham
> > > > > not@apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Lei Wang (Rex)
> > > > rwonly AT apache.org
> > >
> > >
> >
> >
> >
> > --
> > Lei Wang (Rex)
> > rwonly AT apache.org
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Alasdair Nottingham <no...@apache.org>.
On 8 September 2011 10:10, Rex Wang <rw...@gmail.com> wrote:
> 2011/9/8 Timothy Ward <ti...@apache.org>
>
> >
> > Hi,
> >
> > I'm afraid I've not been paying as much attention as I should to this
> > thread. Reading back over the issues. I would currently vote -1 on this
> > release. I am not at all happy with the fact that users of this support
> will
> > see different, potentially erroneous, behaviour depending on the presence
> or
> > absence of an optional dependency. Our previous statement has always been
> > "If a blueprint bundle wants to use some non-standard function it should
> > declare that using an additional namespace".
> >
> Do you mean the statement in spec 121.4:
> "The Blueprint XML resources in a bundle are the definitions. Each
> definition can include multiple
> namespaces. Implementations of the Blueprint core namespace must strictly
> follow this specification,
> if they add additional behavior they must add additional namespaces that
> are
> actually used in
> the definitions to signal the deviation from this specification."?
>
> We are improving the blueprint-ext, which has been already an additional
> namespace to blueprint core schema. Why must we add a new namespace to
> extend the ability of blueprint-ext?
>
>
Blueprint ext is a part of our core implementation. Adding it to
blueprint-ext means that if you want to use ANY part of blueprint ext you
MUST have apache-jexl even if you don't wan to use the ${a+b} syntax. This
is wrong.
>
> > In my view this new function should only be available if the optional
> > dependency is satisfied, and blueprint bundles must enable this function
> > using a custom namespace. Otherwise I see two problems.
> >
> >
> > I want this new support, but have no way to ensure it is present, as a
> > result I am sometimes injected with "1+2" instead of "3". This leads to
> > intermittent NumberFormatExceptions
> >
> I do not want this new support, but as the dependency is available I am
> > injected with "3" instead of "1+2". This leads to inconsistent and
> confusing
> > behaviour.
> >
> I am not sure I understand this..
> If you want 3, you need <xxx value="${1+2}">
> If you want 1+2, you should use <xxx value="1+2">
> Only the expression in ${..} will trigger the calculation, no matter if the
> dependency if available.
>
>
I think tim is saying you want the string literal "${1+2}" not the string
1+2. With your change if I had ${1+2} I now get 3 rather than ${1+2}. This
is a change in behaviour and should be enabled using a new namespace. Of
course you could just reversion the namespace from v1.x to v2 as a breaking
change, but we would need to support both versions of the schema.
As with Tim I would currently -1 any release of blueprint 3.2 until this is
addressed.
Alasdair
-Rex
>
>
> >
> >
> > Adding a namespace for this function elegantly solves both these issues
> in
> > a way that is consistent with other blueprint extensions, and I think is
> > essential before this function can be released.
> >
> > Regards,
> >
> > Tim
> >
> >
> > > From: rwonly@gmail.com
> > > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > > Subject: Re: [Release Discussion] ship maintenance releases of
> > application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > > To: dev@aries.apache.org
> > >
> > > I still think adding a new namespace only for such simple calculation
> is
> > too
> > > heavy and not consumalbe for users..
> > >
> > > Anyway, could anybody help with the release of *
> > > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help
> check
> > why
> > > I can not deploy artifacts to apache.snapshot? Maybe I can try release
> > the 2
> > > components. Geronimo does not have much time targeting the 3.0-beta
> > release.
> > >
> > > thanks,
> > >
> > > -Rex
> > >
> > >
> > >
> > > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> > >
> > > > If we release blueprint as is we will never be able to make the
> change
> > as
> > > > we
> > > > would cause a major breaking change. I think we need to get this
> right
> > > > before a release is done.
> > > >
> > > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
> > > >
> > > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > > >
> > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > vmahrwald@googlemail.com
> > > > > > >wrote:
> > > > > >
> > > > > > > Comments inline :)
> > > > > > >
> > > > > > > Kind regards,
> > > > > > >
> > > > > > > Valentin
> > > > > > >
> > > > > > > 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).
> > > > > > >
> > > > > > >
> > > > > > The blueprint specification says any non-standard extensions to
> > > > blueprint
> > > > > > must be enabled via namespace handlers. I don't like the ext of
> cm
> > > > > > namespaces to require apache-jexl since it means more
> dependencies
> > are
> > > > > > pulled in when they may never be used.
> > > > > >
> > > > > Hi Alasdair,
> > > > > Since the current code does not hard depend on the commons-jexl,
> and
> > I
> > > > > think
> > > > > the only difference from your desire is adding a new namespace
> which
> > can
> > > > > delay the blueprint container initialization if the commons-jexl is
> > not
> > > > > present,
> > > > > I consider this as an improvement to the current solution. And I
> > think it
> > > > > would be better to let user hold the option that if he would use
> the
> > new
> > > > > namespace, and if he don't use it, the ${a+b} can still work. Hope
> > the
> > > > > current solution meets the criteria to start release..
> > > > >
> > > > > BTW, seems Aries community is not that active in last two month. Is
> > there
> > > > > still a release manager help the release works?
> > > > >
> > > > > -Rex
> > > > >
> > > > >
> > > > >
> > > > > >
> > > > > > Looking at your options a) doesn't work because it isn't using
> > > > namespace
> > > > > > handlers, b) sucks big time and would mean to meat the spec we
> > would
> > > > > need
> > > > > > apache-jexl and the whole point is to allow the spec to be
> > implemented
> > > > > > without apache-jexl being required. So I think something like
> > option c
> > > > > > should be gone for. For instance you could add an attribute in a
> > > > > > non-standard namespace that says to enable this capability.
> > > > > >
> > > > > >
> > > > > > > Is any of that what you were thinking of?
> > > > > > >
> > > > > > > > Does that make any sense?
> > > > > > > >
> > > > > > > > Alasdair
> > > > > > > >
> > > > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com> 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 <no...@apache.org>
> > > > > > > >>
> > > > > > > >>> 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 <rw...@gmail.com>
> 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 apache.org
> > > > > > > >>>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >>
> > > > > > > >> --
> > > > > > > >> Lei Wang (Rex)
> > > > > > > >> rwonly AT apache.org
> > > > > > > >>
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > --
> > > > > > > > Alasdair Nottingham
> > > > > > > > not@apache.org
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Alasdair Nottingham
> > > > > > not@apache.org
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Lei Wang (Rex)
> > > > > rwonly AT apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alasdair Nottingham
> > > > not@apache.org
> > > >
> > >
> > >
> > >
> > > --
> > > Lei Wang (Rex)
> > > rwonly AT apache.org
> >
> >
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>
--
Alasdair Nottingham
not@apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
2011/9/8 Timothy Ward <ti...@apache.org>
>
> Hi,
>
> I'm afraid I've not been paying as much attention as I should to this
> thread. Reading back over the issues. I would currently vote -1 on this
> release. I am not at all happy with the fact that users of this support will
> see different, potentially erroneous, behaviour depending on the presence or
> absence of an optional dependency. Our previous statement has always been
> "If a blueprint bundle wants to use some non-standard function it should
> declare that using an additional namespace".
>
Do you mean the statement in spec 121.4:
"The Blueprint XML resources in a bundle are the definitions. Each
definition can include multiple
namespaces. Implementations of the Blueprint core namespace must strictly
follow this specification,
if they add additional behavior they must add additional namespaces that are
actually used in
the definitions to signal the deviation from this specification."?
We are improving the blueprint-ext, which has been already an additional
namespace to blueprint core schema. Why must we add a new namespace to
extend the ability of blueprint-ext?
> In my view this new function should only be available if the optional
> dependency is satisfied, and blueprint bundles must enable this function
> using a custom namespace. Otherwise I see two problems.
>
>
> I want this new support, but have no way to ensure it is present, as a
> result I am sometimes injected with "1+2" instead of "3". This leads to
> intermittent NumberFormatExceptions
>
I do not want this new support, but as the dependency is available I am
> injected with "3" instead of "1+2". This leads to inconsistent and confusing
> behaviour.
>
I am not sure I understand this..
If you want 3, you need <xxx value="${1+2}">
If you want 1+2, you should use <xxx value="1+2">
Only the expression in ${..} will trigger the calculation, no matter if the
dependency if available.
-Rex
>
>
> Adding a namespace for this function elegantly solves both these issues in
> a way that is consistent with other blueprint extensions, and I think is
> essential before this function can be released.
>
> Regards,
>
> Tim
>
>
> > From: rwonly@gmail.com
> > Date: Thu, 8 Sep 2011 11:58:22 +0800
> > Subject: Re: [Release Discussion] ship maintenance releases of
> application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> > To: dev@aries.apache.org
> >
> > I still think adding a new namespace only for such simple calculation is
> too
> > heavy and not consumalbe for users..
> >
> > Anyway, could anybody help with the release of *
> > org.apache.aries.application/0.2.2-SNAPSHOT* *and
> > org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help check
> why
> > I can not deploy artifacts to apache.snapshot? Maybe I can try release
> the 2
> > components. Geronimo does not have much time targeting the 3.0-beta
> release.
> >
> > thanks,
> >
> > -Rex
> >
> >
> >
> > 2011/9/7 Alasdair Nottingham <no...@apache.org>
> >
> > > If we release blueprint as is we will never be able to make the change
> as
> > > we
> > > would cause a major breaking change. I think we need to get this right
> > > before a release is done.
> > >
> > > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
> > >
> > > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > > >
> > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> vmahrwald@googlemail.com
> > > > > >wrote:
> > > > >
> > > > > > Comments inline :)
> > > > > >
> > > > > > Kind regards,
> > > > > >
> > > > > > Valentin
> > > > > >
> > > > > > 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).
> > > > > >
> > > > > >
> > > > > The blueprint specification says any non-standard extensions to
> > > blueprint
> > > > > must be enabled via namespace handlers. I don't like the ext of cm
> > > > > namespaces to require apache-jexl since it means more dependencies
> are
> > > > > pulled in when they may never be used.
> > > > >
> > > > Hi Alasdair,
> > > > Since the current code does not hard depend on the commons-jexl, and
> I
> > > > think
> > > > the only difference from your desire is adding a new namespace which
> can
> > > > delay the blueprint container initialization if the commons-jexl is
> not
> > > > present,
> > > > I consider this as an improvement to the current solution. And I
> think it
> > > > would be better to let user hold the option that if he would use the
> new
> > > > namespace, and if he don't use it, the ${a+b} can still work. Hope
> the
> > > > current solution meets the criteria to start release..
> > > >
> > > > BTW, seems Aries community is not that active in last two month. Is
> there
> > > > still a release manager help the release works?
> > > >
> > > > -Rex
> > > >
> > > >
> > > >
> > > > >
> > > > > Looking at your options a) doesn't work because it isn't using
> > > namespace
> > > > > handlers, b) sucks big time and would mean to meat the spec we
> would
> > > > need
> > > > > apache-jexl and the whole point is to allow the spec to be
> implemented
> > > > > without apache-jexl being required. So I think something like
> option c
> > > > > should be gone for. For instance you could add an attribute in a
> > > > > non-standard namespace that says to enable this capability.
> > > > >
> > > > >
> > > > > > Is any of that what you were thinking of?
> > > > > >
> > > > > > > Does that make any sense?
> > > > > > >
> > > > > > > Alasdair
> > > > > > >
> > > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com> 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 <no...@apache.org>
> > > > > > >>
> > > > > > >>> 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 <rw...@gmail.com> 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 apache.org
> > > > > > >>>
> > > > > > >>
> > > > > > >>
> > > > > > >>
> > > > > > >> --
> > > > > > >> Lei Wang (Rex)
> > > > > > >> rwonly AT apache.org
> > > > > > >>
> > > > > > >
> > > > > > >
> > > > > > >
> > > > > > > --
> > > > > > > Alasdair Nottingham
> > > > > > > not@apache.org
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alasdair Nottingham
> > > > > not@apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Lei Wang (Rex)
> > > > rwonly AT apache.org
> > > >
> > >
> > >
> > >
> > > --
> > > Alasdair Nottingham
> > > not@apache.org
> > >
> >
> >
> >
> > --
> > Lei Wang (Rex)
> > rwonly AT apache.org
>
>
--
Lei Wang (Rex)
rwonly AT apache.org
RE: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Timothy Ward <ti...@apache.org>.
Hi,
I'm afraid I've not been paying as much attention as I should to this thread. Reading back over the issues. I would currently vote -1 on this release. I am not at all happy with the fact that users of this support will see different, potentially erroneous, behaviour depending on the presence or absence of an optional dependency. Our previous statement has always been "If a blueprint bundle wants to use some non-standard function it should declare that using an additional namespace".
In my view this new function should only be available if the optional dependency is satisfied, and blueprint bundles must enable this function using a custom namespace. Otherwise I see two problems.
I want this new support, but have no way to ensure it is present, as a result I am sometimes injected with "1+2" instead of "3". This leads to intermittent NumberFormatExceptions
I do not want this new support, but as the dependency is available I am injected with "3" instead of "1+2". This leads to inconsistent and confusing behaviour.
Adding a namespace for this function elegantly solves both these issues in a way that is consistent with other blueprint extensions, and I think is essential before this function can be released.
Regards,
Tim
> From: rwonly@gmail.com
> Date: Thu, 8 Sep 2011 11:58:22 +0800
> Subject: Re: [Release Discussion] ship maintenance releases of application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
> To: dev@aries.apache.org
>
> I still think adding a new namespace only for such simple calculation is too
> heavy and not consumalbe for users..
>
> Anyway, could anybody help with the release of *
> org.apache.aries.application/0.2.2-SNAPSHOT* *and
> org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help check why
> I can not deploy artifacts to apache.snapshot? Maybe I can try release the 2
> components. Geronimo does not have much time targeting the 3.0-beta release.
>
> thanks,
>
> -Rex
>
>
>
> 2011/9/7 Alasdair Nottingham <no...@apache.org>
>
> > If we release blueprint as is we will never be able to make the change as
> > we
> > would cause a major breaking change. I think we need to get this right
> > before a release is done.
> >
> > On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
> >
> > > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> > >
> > > > On 1 September 2011 07:41, Valentin Mahrwald <vmahrwald@googlemail.com
> > > > >wrote:
> > > >
> > > > > Comments inline :)
> > > > >
> > > > > Kind regards,
> > > > >
> > > > > Valentin
> > > > >
> > > > > 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).
> > > > >
> > > > >
> > > > The blueprint specification says any non-standard extensions to
> > blueprint
> > > > must be enabled via namespace handlers. I don't like the ext of cm
> > > > namespaces to require apache-jexl since it means more dependencies are
> > > > pulled in when they may never be used.
> > > >
> > > Hi Alasdair,
> > > Since the current code does not hard depend on the commons-jexl, and I
> > > think
> > > the only difference from your desire is adding a new namespace which can
> > > delay the blueprint container initialization if the commons-jexl is not
> > > present,
> > > I consider this as an improvement to the current solution. And I think it
> > > would be better to let user hold the option that if he would use the new
> > > namespace, and if he don't use it, the ${a+b} can still work. Hope the
> > > current solution meets the criteria to start release..
> > >
> > > BTW, seems Aries community is not that active in last two month. Is there
> > > still a release manager help the release works?
> > >
> > > -Rex
> > >
> > >
> > >
> > > >
> > > > Looking at your options a) doesn't work because it isn't using
> > namespace
> > > > handlers, b) sucks big time and would mean to meat the spec we would
> > > need
> > > > apache-jexl and the whole point is to allow the spec to be implemented
> > > > without apache-jexl being required. So I think something like option c
> > > > should be gone for. For instance you could add an attribute in a
> > > > non-standard namespace that says to enable this capability.
> > > >
> > > >
> > > > > Is any of that what you were thinking of?
> > > > >
> > > > > > Does that make any sense?
> > > > > >
> > > > > > Alasdair
> > > > > >
> > > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com> 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 <no...@apache.org>
> > > > > >>
> > > > > >>> 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 <rw...@gmail.com> 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 apache.org
> > > > > >>>
> > > > > >>
> > > > > >>
> > > > > >>
> > > > > >> --
> > > > > >> Lei Wang (Rex)
> > > > > >> rwonly AT apache.org
> > > > > >>
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Alasdair Nottingham
> > > > > > not@apache.org
> > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > Alasdair Nottingham
> > > > not@apache.org
> > > >
> > >
> > >
> > >
> > > --
> > > Lei Wang (Rex)
> > > rwonly AT apache.org
> > >
> >
> >
> >
> > --
> > Alasdair Nottingham
> > not@apache.org
> >
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
I still think adding a new namespace only for such simple calculation is too
heavy and not consumalbe for users..
Anyway, could anybody help with the release of *
org.apache.aries.application/0.2.2-SNAPSHOT* *and
org.apache.aries.util/0.2.1-SNAPSHOT* first? or chould anyone help check why
I can not deploy artifacts to apache.snapshot? Maybe I can try release the 2
components. Geronimo does not have much time targeting the 3.0-beta release.
thanks,
-Rex
2011/9/7 Alasdair Nottingham <no...@apache.org>
> If we release blueprint as is we will never be able to make the change as
> we
> would cause a major breaking change. I think we need to get this right
> before a release is done.
>
> On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
>
> > 2011/9/6 Alasdair Nottingham <no...@apache.org>
> >
> > > On 1 September 2011 07:41, Valentin Mahrwald <vmahrwald@googlemail.com
> > > >wrote:
> > >
> > > > Comments inline :)
> > > >
> > > > Kind regards,
> > > >
> > > > Valentin
> > > >
> > > > 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).
> > > >
> > > >
> > > The blueprint specification says any non-standard extensions to
> blueprint
> > > must be enabled via namespace handlers. I don't like the ext of cm
> > > namespaces to require apache-jexl since it means more dependencies are
> > > pulled in when they may never be used.
> > >
> > Hi Alasdair,
> > Since the current code does not hard depend on the commons-jexl, and I
> > think
> > the only difference from your desire is adding a new namespace which can
> > delay the blueprint container initialization if the commons-jexl is not
> > present,
> > I consider this as an improvement to the current solution. And I think it
> > would be better to let user hold the option that if he would use the new
> > namespace, and if he don't use it, the ${a+b} can still work. Hope the
> > current solution meets the criteria to start release..
> >
> > BTW, seems Aries community is not that active in last two month. Is there
> > still a release manager help the release works?
> >
> > -Rex
> >
> >
> >
> > >
> > > Looking at your options a) doesn't work because it isn't using
> namespace
> > > handlers, b) sucks big time and would mean to meat the spec we would
> > need
> > > apache-jexl and the whole point is to allow the spec to be implemented
> > > without apache-jexl being required. So I think something like option c
> > > should be gone for. For instance you could add an attribute in a
> > > non-standard namespace that says to enable this capability.
> > >
> > >
> > > > Is any of that what you were thinking of?
> > > >
> > > > > Does that make any sense?
> > > > >
> > > > > Alasdair
> > > > >
> > > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com> 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 <no...@apache.org>
> > > > >>
> > > > >>> 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 <rw...@gmail.com> 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 apache.org
> > > > >>>
> > > > >>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Lei Wang (Rex)
> > > > >> rwonly AT apache.org
> > > > >>
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Alasdair Nottingham
> > > > > not@apache.org
> > > >
> > > >
> > >
> > >
> > > --
> > > Alasdair Nottingham
> > > not@apache.org
> > >
> >
> >
> >
> > --
> > Lei Wang (Rex)
> > rwonly AT apache.org
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Alasdair Nottingham <no...@apache.org>.
If we release blueprint as is we will never be able to make the change as we
would cause a major breaking change. I think we need to get this right
before a release is done.
On 6 September 2011 04:37, Rex Wang <rw...@gmail.com> wrote:
> 2011/9/6 Alasdair Nottingham <no...@apache.org>
>
> > On 1 September 2011 07:41, Valentin Mahrwald <vmahrwald@googlemail.com
> > >wrote:
> >
> > > Comments inline :)
> > >
> > > Kind regards,
> > >
> > > Valentin
> > >
> > > 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).
> > >
> > >
> > The blueprint specification says any non-standard extensions to blueprint
> > must be enabled via namespace handlers. I don't like the ext of cm
> > namespaces to require apache-jexl since it means more dependencies are
> > pulled in when they may never be used.
> >
> Hi Alasdair,
> Since the current code does not hard depend on the commons-jexl, and I
> think
> the only difference from your desire is adding a new namespace which can
> delay the blueprint container initialization if the commons-jexl is not
> present,
> I consider this as an improvement to the current solution. And I think it
> would be better to let user hold the option that if he would use the new
> namespace, and if he don't use it, the ${a+b} can still work. Hope the
> current solution meets the criteria to start release..
>
> BTW, seems Aries community is not that active in last two month. Is there
> still a release manager help the release works?
>
> -Rex
>
>
>
> >
> > Looking at your options a) doesn't work because it isn't using namespace
> > handlers, b) sucks big time and would mean to meat the spec we would
> need
> > apache-jexl and the whole point is to allow the spec to be implemented
> > without apache-jexl being required. So I think something like option c
> > should be gone for. For instance you could add an attribute in a
> > non-standard namespace that says to enable this capability.
> >
> >
> > > Is any of that what you were thinking of?
> > >
> > > > Does that make any sense?
> > > >
> > > > Alasdair
> > > >
> > > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com> 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 <no...@apache.org>
> > > >>
> > > >>> 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 <rw...@gmail.com> 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 apache.org
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Lei Wang (Rex)
> > > >> rwonly AT apache.org
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Alasdair Nottingham
> > > > not@apache.org
> > >
> > >
> >
> >
> > --
> > Alasdair Nottingham
> > not@apache.org
> >
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>
--
Alasdair Nottingham
not@apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
2011/9/6 Alasdair Nottingham <no...@apache.org>
> On 1 September 2011 07:41, Valentin Mahrwald <vmahrwald@googlemail.com
> >wrote:
>
> > Comments inline :)
> >
> > Kind regards,
> >
> > Valentin
> >
> > 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).
> >
> >
> The blueprint specification says any non-standard extensions to blueprint
> must be enabled via namespace handlers. I don't like the ext of cm
> namespaces to require apache-jexl since it means more dependencies are
> pulled in when they may never be used.
>
Hi Alasdair,
Since the current code does not hard depend on the commons-jexl, and I think
the only difference from your desire is adding a new namespace which can
delay the blueprint container initialization if the commons-jexl is not
present,
I consider this as an improvement to the current solution. And I think it
would be better to let user hold the option that if he would use the new
namespace, and if he don't use it, the ${a+b} can still work. Hope the
current solution meets the criteria to start release..
BTW, seems Aries community is not that active in last two month. Is there
still a release manager help the release works?
-Rex
>
> Looking at your options a) doesn't work because it isn't using namespace
> handlers, b) sucks big time and would mean to meat the spec we would need
> apache-jexl and the whole point is to allow the spec to be implemented
> without apache-jexl being required. So I think something like option c
> should be gone for. For instance you could add an attribute in a
> non-standard namespace that says to enable this capability.
>
>
> > Is any of that what you were thinking of?
> >
> > > Does that make any sense?
> > >
> > > Alasdair
> > >
> > > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com> 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 <no...@apache.org>
> > >>
> > >>> 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 <rw...@gmail.com> 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 apache.org
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Lei Wang (Rex)
> > >> rwonly AT apache.org
> > >>
> > >
> > >
> > >
> > > --
> > > Alasdair Nottingham
> > > not@apache.org
> >
> >
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Alasdair Nottingham <no...@apache.org>.
On 1 September 2011 07:41, Valentin Mahrwald <vm...@googlemail.com>wrote:
> Comments inline :)
>
> Kind regards,
>
> Valentin
>
> 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).
>
>
The blueprint specification says any non-standard extensions to blueprint
must be enabled via namespace handlers. I don't like the ext of cm
namespaces to require apache-jexl since it means more dependencies are
pulled in when they may never be used.
Looking at your options a) doesn't work because it isn't using namespace
handlers, b) sucks big time and would mean to meat the spec we would need
apache-jexl and the whole point is to allow the spec to be implemented
without apache-jexl being required. So I think something like option c
should be gone for. For instance you could add an attribute in a
non-standard namespace that says to enable this capability.
> Is any of that what you were thinking of?
>
> > Does that make any sense?
> >
> > Alasdair
> >
> > On 30 August 2011 07:36, Rex Wang <rw...@gmail.com> 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 <no...@apache.org>
> >>
> >>> 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 <rw...@gmail.com> 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 apache.org
> >>>
> >>
> >>
> >>
> >> --
> >> Lei Wang (Rex)
> >> rwonly AT apache.org
> >>
> >
> >
> >
> > --
> > Alasdair Nottingham
> > not@apache.org
>
>
--
Alasdair Nottingham
not@apache.org
Re: [Release Discussion] ship maintenance releases of application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Valentin Mahrwald <vm...@googlemail.com>.
Comments inline :)
Kind regards,
Valentin
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 <rw...@gmail.com> 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 <no...@apache.org>
>>
>>> 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 <rw...@gmail.com> 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 apache.org
>>>
>>
>>
>>
>> --
>> Lei Wang (Rex)
>> rwonly AT apache.org
>>
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
FYI, The blueprint itests in trunk can work now..
-Rex
2011/9/1 Rex Wang <rw...@gmail.com>
> At revision: 1163899, I make the commons-jexl an optional dependency.
> At revision: 1163921, I ported the rev 1162308-1163899 from 0.3 branch to
> trunk. However, the itests in trunk is really buggy... I did not get a time
> to make it work...
>
> Let's take a look at the new changes in branch 0.3, all the itests can pass
> without installing the commons-jexl bundle. So, currently,
> (1) If user is using blueprint-ext namespace and not using the new syntax
> "${a+b}", and he did not install the commons-jexl bundle, the new code can
> still work.
> This means the new code does not break the current programming model.
>
> (2) If user is using blueprint-ext namespace and also using the new syntax
> "${a+b}", but he "forgot" to install the commons-jexl bundle, the blueprint
> container won't be initialized correctly, and an error will be logged, says:
>
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------
> org.apache.aries.blueprint.ext.PropertyPlaceholder - Could not evaluate
> expression: key.b+0
> org.apache.aries.blueprint.ext.PropertyPlaceholder - Exception:
> java.lang.ClassNotFoundException: org.apache.commons.jexl2.JexlEngine
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:489)
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405)
> at
> org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393)
> at
> org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105)
> at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
> .....
> Caused by: java.lang.NumberFormatException: For input string: "${key.b+0}"
> at
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
> at java.lang.Integer.parseInt(Integer.java:449)
> at java.lang.Integer.valueOf(Integer.java:554)
> at
> org.apache.aries.blueprint.container.AggregateConverter.convertFromString(AggregateConverter.java:269)
> at
> org.apache.aries.blueprint.container.AggregateConverter.convert(AggregateConverter.java:162)
> at
> org.apache.aries.blueprint.container.BlueprintRepository.convert(BlueprintRepository.java:373)
> at
> org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.convert(ReflectionUtils.java:323)
> at
> org.apache.aries.blueprint.utils.ReflectionUtils$MethodPropertyDescriptor.internalSet(ReflectionUtils.java:476)
> at
> org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.set(ReflectionUtils.java:307)
> at
> org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:805)
> ... 26 more
>
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
> I think it would be better to add such syntax to blueprint-ext(and also
> blueprint-cm) directly, instead of adding a new namespace to handle such
> calculation. This ability is really useful and should be used as simple as
> is. Now, the current solution does not break the current use cases and
> programming model, so do you still consider it as a blocker to release?
>
>
> thanks,
>
> -Rex
>
>
> 2011/9/1 Alasdair Nottingham <no...@apache.org>
>
>> 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.
>>
>> Does that make any sense?
>>
>> Alasdair
>>
>> On 30 August 2011 07:36, Rex Wang <rw...@gmail.com> 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 <no...@apache.org>
>> >
>> > > 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 <rw...@gmail.com> 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 apache.org
>> > >
>> >
>> >
>> >
>> > --
>> > Lei Wang (Rex)
>> > rwonly AT apache.org
>> >
>>
>>
>>
>> --
>> Alasdair Nottingham
>> not@apache.org
>>
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
At revision: 1163899, I make the commons-jexl an optional dependency.
At revision: 1163921, I ported the rev 1162308-1163899 from 0.3 branch to
trunk. However, the itests in trunk is really buggy... I did not get a time
to make it work...
Let's take a look at the new changes in branch 0.3, all the itests can pass
without installing the commons-jexl bundle. So, currently,
(1) If user is using blueprint-ext namespace and not using the new syntax
"${a+b}", and he did not install the commons-jexl bundle, the new code can
still work.
This means the new code does not break the current programming model.
(2) If user is using blueprint-ext namespace and also using the new syntax
"${a+b}", but he "forgot" to install the commons-jexl bundle, the blueprint
container won't be initialized correctly, and an error will be logged, says:
---------------------------------------------------------------------------------------------------------------------------------------------------
org.apache.aries.blueprint.ext.PropertyPlaceholder - Could not evaluate
expression: key.b+0
org.apache.aries.blueprint.ext.PropertyPlaceholder - Exception:
java.lang.ClassNotFoundException: org.apache.commons.jexl2.JexlEngine
at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:489)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405)
at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393)
at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105)
at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
.....
Caused by: java.lang.NumberFormatException: For input string: "${key.b+0}"
at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
at java.lang.Integer.parseInt(Integer.java:449)
at java.lang.Integer.valueOf(Integer.java:554)
at
org.apache.aries.blueprint.container.AggregateConverter.convertFromString(AggregateConverter.java:269)
at
org.apache.aries.blueprint.container.AggregateConverter.convert(AggregateConverter.java:162)
at
org.apache.aries.blueprint.container.BlueprintRepository.convert(BlueprintRepository.java:373)
at
org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.convert(ReflectionUtils.java:323)
at
org.apache.aries.blueprint.utils.ReflectionUtils$MethodPropertyDescriptor.internalSet(ReflectionUtils.java:476)
at
org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.set(ReflectionUtils.java:307)
at
org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:805)
... 26 more
---------------------------------------------------------------------------------------------------------------------------------------------------
I think it would be better to add such syntax to blueprint-ext(and also
blueprint-cm) directly, instead of adding a new namespace to handle such
calculation. This ability is really useful and should be used as simple as
is. Now, the current solution does not break the current use cases and
programming model, so do you still consider it as a blocker to release?
thanks,
-Rex
2011/9/1 Alasdair Nottingham <no...@apache.org>
> 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.
>
> Does that make any sense?
>
> Alasdair
>
> On 30 August 2011 07:36, Rex Wang <rw...@gmail.com> 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 <no...@apache.org>
> >
> > > 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 <rw...@gmail.com> 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 apache.org
> > >
> >
> >
> >
> > --
> > Lei Wang (Rex)
> > rwonly AT apache.org
> >
>
>
>
> --
> Alasdair Nottingham
> not@apache.org
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Alasdair Nottingham <no...@apache.org>.
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.
Does that make any sense?
Alasdair
On 30 August 2011 07:36, Rex Wang <rw...@gmail.com> 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 <no...@apache.org>
>
> > 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 <rw...@gmail.com> 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 apache.org
> >
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>
--
Alasdair Nottingham
not@apache.org
Re: [Release Discussion] ship maintenance releases of
application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Rex Wang <rw...@gmail.com>.
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 <no...@apache.org>
> 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 <rw...@gmail.com> 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 apache.org
>
--
Lei Wang (Rex)
rwonly AT apache.org
Re: [Release Discussion] ship maintenance releases of application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Posted by Alasdair Nottingham <no...@apache.org>.
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 <rw...@gmail.com> 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 apache.org