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 <[email protected]> wrote: > On Wed, Sep 14, 2011 at 12:34, Alasdair Nottingham <[email protected]> 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 <[email protected]> wrote: > > > > > 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 > > > > > > > > > > > -- > > Alasdair Nottingham > > [email protected] > > > > > > -- > ------------------------ > Guillaume Nodet > ------------------------ > Blog: http://gnodet.blogspot.com/ > ------------------------ > Open Source SOA > http://fusesource.com > -- Alasdair Nottingham [email protected]
