aries-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rex Wang <rwo...@gmail.com>
Subject Re: [Release Discussion] ship maintenance releases of application-0.2.2 / util-0.2.1 / blueprint-0.3.2 ?
Date Thu, 01 Sep 2011 07:33:32 GMT
At revision: 1163899, I make the commons-jexl an optional dependency.
At revision: 1163921, I ported the rev 1162308-1163899 from 0.3 branch to
trunk. However, the itests in trunk is really buggy... I did not get a time
to make it work...

Let's take a look at the new changes in branch 0.3, all the itests can pass
without installing the commons-jexl bundle. So, currently,
(1) If user is using blueprint-ext namespace and not using the new syntax
"${a+b}", and he did not install the commons-jexl bundle, the new code can
still work.
This means the new code does not break the current programming model.

(2) If user is using blueprint-ext namespace and also using the new syntax
"${a+b}", but he "forgot" to install the commons-jexl bundle, the blueprint
container won't be initialized correctly, and an error will be logged, says:

---------------------------------------------------------------------------------------------------------------------------------------------------
org.apache.aries.blueprint.ext.PropertyPlaceholder - Could not evaluate
expression: key.b+0
org.apache.aries.blueprint.ext.PropertyPlaceholder - Exception:
java.lang.ClassNotFoundException: org.apache.commons.jexl2.JexlEngine
    at
org.eclipse.osgi.internal.loader.BundleLoader.findClassInternal(BundleLoader.java:489)
    at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:405)
    at
org.eclipse.osgi.internal.loader.BundleLoader.findClass(BundleLoader.java:393)
    at
org.eclipse.osgi.internal.baseadaptor.DefaultClassLoader.loadClass(DefaultClassLoader.java:105)
    at java.lang.ClassLoader.loadClass(ClassLoader.java:248)
    .....
Caused by: java.lang.NumberFormatException: For input string: "${key.b+0}"
    at
java.lang.NumberFormatException.forInputString(NumberFormatException.java:48)
    at java.lang.Integer.parseInt(Integer.java:449)
    at java.lang.Integer.valueOf(Integer.java:554)
    at
org.apache.aries.blueprint.container.AggregateConverter.convertFromString(AggregateConverter.java:269)
    at
org.apache.aries.blueprint.container.AggregateConverter.convert(AggregateConverter.java:162)
    at
org.apache.aries.blueprint.container.BlueprintRepository.convert(BlueprintRepository.java:373)
    at
org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.convert(ReflectionUtils.java:323)
    at
org.apache.aries.blueprint.utils.ReflectionUtils$MethodPropertyDescriptor.internalSet(ReflectionUtils.java:476)
    at
org.apache.aries.blueprint.utils.ReflectionUtils$PropertyDescriptor.set(ReflectionUtils.java:307)
    at
org.apache.aries.blueprint.container.BeanRecipe.setProperty(BeanRecipe.java:805)
    ... 26 more
---------------------------------------------------------------------------------------------------------------------------------------------------

I think it would be better to add such syntax to blueprint-ext(and also
blueprint-cm) directly, instead of adding a new namespace to handle such
calculation. This ability is really useful and should be used as simple as
is. Now, the current solution does not break the current use cases and
programming model, so do you still consider it as a blocker to release?


thanks,

-Rex

2011/9/1 Alasdair Nottingham <not@apache.org>

> 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 <rwonly@gmail.com> 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 <not@apache.org>
> >
> > > 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 <rwonly@gmail.com> 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
> not@apache.org
>



-- 
Lei Wang (Rex)
rwonly AT apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message