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 >
