Agreed. I'd prefer a namespace that didn't imply the only implementation was jexl based. Say using blueprint-eval or blueprint-expr instead of blueprint-jexl.
Cheers, Jeremy On 8 September 2011 23:26, Alasdair Nottingham <[email protected]> wrote: > 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] >
