Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 22151 invoked from network); 21 Jul 2010 14:32:50 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Jul 2010 14:32:50 -0000 Received: (qmail 80035 invoked by uid 500); 21 Jul 2010 14:32:50 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 79670 invoked by uid 500); 21 Jul 2010 14:32:48 -0000 Mailing-List: contact dev-help@myfaces.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "MyFaces Development" Delivered-To: mailing list dev@myfaces.apache.org Received: (qmail 79653 invoked by uid 99); 21 Jul 2010 14:32:48 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jul 2010 14:32:48 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of gerhard.petracek@gmail.com designates 209.85.213.181 as permitted sender) Received: from [209.85.213.181] (HELO mail-yx0-f181.google.com) (209.85.213.181) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 21 Jul 2010 14:32:41 +0000 Received: by yxm8 with SMTP id 8so2163549yxm.12 for ; Wed, 21 Jul 2010 07:31:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:content-type; bh=rBcoHOV7Ui2ICGcZra+uKrjiinKtYVzCgizptiXy1VQ=; b=sKrd1/Z+q42pjWKj7l9d6p8Zoo9zWJIlFBQyyWf9ulN47PlLSdm6a1fpR9EzFrktPL ydOA6Kch5NAskBFRUQzqRc8W09Dsdv/2nLIimpmonfgi22zz4y7MG3TV61euLLQGbEX8 8rvqSWHQT4QZC4hdpgmLd1ZEGh8TKEQg5sX/s= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; b=bvfVyIA8k02PjN8V2Brs4fpryfZ7L4ObpTI/8EKNnxUOP/js1os4mx1muUOeMedg6x aiPhdDRpNftdWUr8bmCRFQhv3+eOV5gxQiRNF8oLZWvyr4Rd5o9xKV2QodQLTPaKukpG Q81/xvzlDgu0+imhiE8QRBU0Pn9XFvulVQ4LY= Received: by 10.151.25.16 with SMTP id c16mr1963169ybj.349.1279722691798; Wed, 21 Jul 2010 07:31:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.231.152.194 with HTTP; Wed, 21 Jul 2010 07:24:25 -0700 (PDT) In-Reply-To: References: <588953.11195.qm@web27807.mail.ukl.yahoo.com> From: Gerhard Petracek Date: Wed, 21 Jul 2010 16:24:25 +0200 Message-ID: Subject: Re: provide a way to define the ordering of ELResolvers To: MyFaces Development Content-Type: multipart/alternative; boundary=000e0cd299f474a88e048be6a865 X-Virus-Checked: Checked by ClamAV on apache.org --000e0cd299f474a88e048be6a865 Content-Type: text/plain; charset=ISO-8859-1 as intermediate solution we could introduce an optional comparator (+ web.xml context-param). -> you can move external el-resolvers e.g. to the end of the list. advantages: - users don't have to call a method which is specific to myfaces-core. - if users switch between myfaces-core and mojarra, the only difference is the performance (if there is no side-effect due to a name clash). disadvantage: - we would introduce a feature which might get deprecated with jsf 2.1+ regards, gerhard http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces 2010/7/21 Jakob Korherr > Hi Mark, > > In the JSF 2.0 spec section 5.2.6, the implemented order is defined, thus > we cannot change this. > > If you want to overwrite it without changing MyFaces core you could create > your own ELResolverBuilder and set it in ApplicationImpl via > setResolverBuilderForFaces(). > > However IMO this is a task the EG has to address for JSF 2.1, because the > right order can bring a lot of performance improvements and should totally > be configurable. > > Regards, > Jakob > > 2010/7/21 Mark Struberg > >> Hi! >> >> >> Currently the ordering of ELResolvers is somehow hardcoded in >> ResolverBuilderForFaces and ResolverBuilderForJSP. >> All the additional ELResolvers get invoked before all MyFaces internal >> ones. >> >> This causes a lot traffic in pretty expensive ELResolvers like Spring or >> CDI >> ELResolvers. >> >> >> What I miss is a way to explicitely define the _exact_ ordering of >> EL_Resolvers. >> In my case I like to invoke the OpenWebBeans ELResolver only after all the >> 'cheaper' ones got fired, e.g. >> >> >> elResolver.add(new FlashELResolver()); >> elResolver.add(new ManagedBeanResolver()); >> elResolver.add(new ResourceResolver()); >> elResolver.add(new ResourceBundleELResolver()); >> elResolver.add(new ResourceBundleResolver()); >> elResolver.add(new MapELResolver()); >> elResolver.add(new ListELResolver()); >> elResolver.add(new ArrayELResolver()); >> elResolver.add(new BeanELResolver()); >> -> add OWB ELResolver here >> elResolver.add(new ScopedAttributeResolver()); >> >> This would speed up the performance on CDI based pages a lot ;) >> >> What is the best way to make this configurable? >> >> LieGrue, >> strub >> >> >> >> >> > > > -- > Jakob Korherr > > blog: http://www.jakobk.com > twitter: http://twitter.com/jakobkorherr > work: http://www.irian.at > --000e0cd299f474a88e048be6a865 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable as intermediate solution we could introduce an optional comparator (+ web.x= ml context-param).
-> you can move external el-resolvers=A0e.g.=A0to= the end of the list.

advantages:
= =A0- users don't have to call a method which is specific to myfaces-cor= e.
=A0- if users switch between myfaces-core and mojarra, the only difference = is the performance (if there is no side-effect due to a name clash).

disadvantage:
=A0- we would introduce a= feature which might get deprecated with jsf 2.1+

regards,
gerhard

http://www.irian.at

Your JSF powerhouse -
J= SF Consulting, Development and
Courses in English and German

Prof= essional Support for Apache MyFaces


2010/7/21 Jakob Korherr <jakob.korherr@gmail.com>
Hi Mark,

In the JSF 2.0 spec section 5.2.6, the implemented order is= defined, thus we cannot change this.

If you want to overwrite it wi= thout changing MyFaces core you could create your own ELResolverBuilder and= set it in ApplicationImpl via setResolverBuilderForFaces().

However IMO this is a task the EG has to address for JSF 2.1, because t= he right order can bring a lot of performance improvements and should total= ly be configurable.

Regards,
Jakob

2010/7/21 Mark Struberg <struberg@yahoo.de>
Hi!


Currently the ordering of ELResolvers is somehow hardcoded in
ResolverBuilderForFaces and ResolverBuilderForJSP.
All the additional ELResolvers get invoked before all MyFaces internal ones= .

This causes a lot traffic in pretty expensive ELResolvers like Spring or CD= I
ELResolvers.


What I miss is a way to explicitely define the _exact_ ordering of EL_Resol= vers.
In my case I like to invoke the OpenWebBeans ELResolver only after all the<= br> 'cheaper' ones got fired, e.g.


=A0 =A0 =A0 =A0elResolver.add(new FlashELResolver());
=A0 =A0 =A0 =A0elResolver.add(new ManagedBeanResolver());
=A0 =A0 =A0 =A0elResolver.add(new ResourceResolver());
=A0 =A0 =A0 =A0elResolver.add(new ResourceBundleELResolver());
=A0 =A0 =A0 =A0elResolver.add(new ResourceBundleResolver());
=A0 =A0 =A0 =A0elResolver.add(new MapELResolver());
=A0 =A0 =A0 =A0elResolver.add(new ListELResolver());
=A0 =A0 =A0 =A0elResolver.add(new ArrayELResolver());
=A0 =A0 =A0 =A0elResolver.add(new BeanELResolver());
-> add OWB ELResolver here
=A0 =A0 =A0 =A0elResolver.add(new ScopedAttributeResolver());

This would speed up the performance on CDI based pages a lot ;)

What is the best way to make this configurable?

LieGrue,
strub







--

--000e0cd299f474a88e048be6a865--