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