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