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]
