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