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