2011/9/13 Alasdair Nottingham n...@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 rwo...@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 n...@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
locationfile:///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 timothyjw...@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: n...@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
