In GERONIMO-5987 <https://issues.apache.org/jira/browse/GERONIMO-5987>
We need ${ActiveMQ + PortOffset}.
2011/9/8 Jeremy Hughes <[email protected]>
> On 8 September 2011 14:18, Rex Wang <[email protected]> wrote:
> > 2011/9/8 Timothy Ward <[email protected]>
> >
> >>
> >> Hi,
> >>
> >> comments in line
> >>
> >> > From: [email protected]
> >> > 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: [email protected]
> >> >
> >> > 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?
> >> >
> >> >
> >> > > 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: [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
> >>
> >>
> >
> >
> >
> > --
> > Lei Wang (Rex)
> > rwonly AT apache.org
> >
>
--
Lei Wang (Rex)
rwonly AT apache.org
