OK, I understand that, but + comes with the language. Parsing what's
between {} shouldn't need an external library, IMHO.On 8 September 2011 14:49, Rex Wang <[email protected]> wrote: > In GERONIMO-5987 <https://issues.apache.org/jira/browse/GERONIMO-5987> > > We need ${ActiveMQ + PortOffset}. > > 2011/9/8 Jeremy Hughes <[email protected]> > >> On 8 September 2011 14:18, Rex Wang <[email protected]> wrote: >> > 2011/9/8 Timothy Ward <[email protected]> >> > >> >> >> >> Hi, >> >> >> >> comments in line >> >> >> >> > From: [email protected] >> >> > Date: Thu, 8 Sep 2011 17:10:54 +0800 >> >> > Subject: Re: [Release Discussion] ship maintenance releases of >> >> application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ? >> >> > To: [email protected] >> >> > >> >> > 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? >> >> > >> >> > >> >> > > 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. >> >> > >> >> >> >> Do in the absence of the jexl dependency what does <xxx value="${1+2}"> >> >> equal? >> >> >> >> What happens if I want to use a property placeholder keyed off the >> string >> >> value "1+2" when jexl is present? >> >> >> > We should NOT implicitly encourage user use such style as a key of value. >> I >> > don't think it makes any sense. In practice, I did not see any blueprint >> > config file use that. >> >> Why does anyone need jexl to add two numbers together? >> >> > >> > >> > -Rex >> > >> > >> >> >> >> >> >> > -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 >> >> >> >> >> > >> > >> > >> > -- >> > Lei Wang (Rex) >> > rwonly AT apache.org >> > >> > > > > -- > Lei Wang (Rex) > rwonly AT apache.org >
