FYI, The blueprint itests in trunk can work now.. -Rex
2011/9/1 Rex Wang <[email protected]> > 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 <[email protected]> > >> 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] >> > > > > -- > Lei Wang (Rex) > rwonly AT apache.org > -- Lei Wang (Rex) rwonly AT apache.org
