On 8 September 2011 10:10, Rex Wang <[email protected]> wrote:
> 2011/9/8 Timothy Ward <[email protected]>
>
> >
> > 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: [email protected]
> > > 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: [email protected]
> > >
> > > 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 <[email protected]>
> > >
> > > > 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 <[email protected]> wrote:
> > > >
> > > > > 2011/9/6 Alasdair Nottingham <[email protected]>
> > > > >
> > > > > > On 1 September 2011 07:41, Valentin Mahrwald <
> > [email protected]
> > > > > > >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 <[email protected]> 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 <[email protected]>
> > > > > > > >>
> > > > > > > >>> 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 <[email protected]>
> 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
> > > > > > > > [email protected]
> > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > Alasdair Nottingham
> > > > > > [email protected]
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > Lei Wang (Rex)
> > > > > rwonly AT apache.org
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Alasdair Nottingham
> > > > [email protected]
> > > >
> > >
> > >
> > >
> > > --
> > > Lei Wang (Rex)
> > > rwonly AT apache.org
> >
> >
>
>
>
> --
> Lei Wang (Rex)
> rwonly AT apache.org
>
--
Alasdair Nottingham
[email protected]
