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]
