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
