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. 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]
