2011/9/13 Alasdair Nottingham <[email protected]>
> 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 <[email protected]> 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 <[email protected]>
> >
> > > 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 <[email protected]>
> 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: [email protected]
> > > > > To: [email protected]
> > > > >
> > > > > 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 <[email protected]> wrote:
> > > > >
> > > > > > 2011/9/8 Alasdair Nottingham <[email protected]>
> > > > > >
> > > > > > > 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.
> > > > > > >
> > > > > >
> > > > > > 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: [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]
> > > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > --
> > > > > > 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
