Hi MK >> The obvious optimalization would be move the BeanELResolver to top. But MK >> you cannot: EL spec 2.2 javax.el.BeanELResolver: "If the property is not MK >> found or is not readable, a PropertyNotFoundException is thrown." So MK >> UEL spec. mandates that BeanELResolver must be last one which resolves MK >> not-null base and a property on that base.
MK >> Do you know the reason for that? Do you have any ideas how to move MK >> BeanELResolver to top and avoid thousands of "empty" geValue MK >> invocations? If BeanELResolver is on top, other resolvers like MapELResolver will fail. I don't think that could be possible. Maybe we need to think about a solution for override EL resolvers chain, maybe through a SPI interface. regards, Leonardo Uribe 2011/3/29 Martin Koci <[email protected]>: > Hi, > > the only solution which comes to my mind is update MYFACES-3075 to > support transforming (replacing one resover with another) and with some > sort of supplier support (when user wants provide own list of EL > reolvers). That will allow complete maninulation of el resolvers chain: > custom chain,sort,filter and transform. > > Then we can provide a lenient BeanELResolver implementation with > behaviour: if base does not have the property returns null and allows > next resolver to take charge of getValue. > > WDYT? > > Kočičák > > Martin Koci píše v Po 28. 03. 2011 v 20:50 +0200: >> Hi, >> >> I'm optimizing render response on a large view (takes over 3 secs to >> render) and below you can see results of unsorted and unfiltered >> ELResolvers chain. The most important info is that BeanELResolver >> resolves property over 40000x from 64000 invocations. The second place >> belongs to ImplicitObjectResolver with over 20000 resolved properties. >> The reason why BeanElResolver is so successful is because majority of >> expressions looks like >> {requestScope.pojoObject.propertyOne.propertyTwo}. >> >> >> The obvious optimalization would be move the BeanELResolver to top. But >> you cannot: EL spec 2.2 javax.el.BeanELResolver: "If the property is not >> found or is not readable, a PropertyNotFoundException is thrown." So >> UEL spec. mandates that BeanELResolver must be last one which resolves >> not-null base and a property on that base. >> >> Do you know the reason for that? Do you have any ideas how to move >> BeanELResolver to top and avoid thousands of "empty" geValue >> invocations? >> >> Thanks, >> >> Kočičák >> >> >> Results: >> ImplicitObjectResolver: >> getValue invocations: 64452 getValue hits: 21018 >> >> org.apache.myfaces.el.unified.resolver.CompositeComponentELResolver: >> getValue invocations: 64336 getValue hits: 30 >> >> org.richfaces.skin.SkinPropertiesELResolver >> getValue invocations: 64306 getValue hits: 0 >> >> org.richfaces.resource.ResourceParameterELResolver >> getValue invocations: 64306 getValue hits: 0 >> >> org.jboss.weld.environment.servlet.jsf.WeldApplication >> $LazyBeanManagerIntegrationELResolver >> getValue invocations: 64306 getValue hits: 975 >> >> org.apache.myfaces.el.unified.resolver.ManagedBeanResolver >> getValue invocations: 63331 getValue hits: 0 >> >> org.apache.myfaces.el.unified.resolver.ResourceResolver >> getValue invocations: 63331 getValue hits: 64 >> >> javax.el.ResourceBundleELResolver >> getValue invocations: 63267 getValue hits: 3 >> >> org.apache.myfaces.el.unified.resolver.ResourceBundleResolver >> getValue invocations: 63264 getValue hits: 3 >> >> javax.el.MapELResolver: >> getValue invocations: 63261 getValue hits: 1069 >> >> javax.el.ListELResolver: >> getValue invocations: 62192 getValue hits: 0 >> >> javax.el.ArrayELResolver: >> getValue invocations: 62192 getValue hits: 0 >> >> javax.el.BeanELResolver: >> getValue invocations: 62192 getValue hits: 40563 >> >> org.apache.myfaces.el.unified.resolver.ScopedAttributeResolver >> getValue invocations: 21629 getValue hits: 582 >> >> > > >
