Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 61959 invoked from network); 9 Dec 2010 02:28:30 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 9 Dec 2010 02:28:30 -0000 Received: (qmail 52191 invoked by uid 500); 9 Dec 2010 02:28:30 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 52151 invoked by uid 500); 9 Dec 2010 02:28:30 -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 52144 invoked by uid 99); 9 Dec 2010 02:28:30 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Dec 2010 02:28:30 +0000 X-ASF-Spam-Status: No, hits=1.5 required=10.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of xhhsld@gmail.com designates 209.85.216.53 as permitted sender) Received: from [209.85.216.53] (HELO mail-qw0-f53.google.com) (209.85.216.53) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 09 Dec 2010 02:28:21 +0000 Received: by qwe5 with SMTP id 5so2054268qwe.12 for ; Wed, 08 Dec 2010 18:28:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type; bh=234ck4XalHOlWcTaEYp5YsE3a8QTQjMxucR25Aw7nHw=; b=tq90cBqIteu/QZ5FFt2pzG4ohhpl76vqQlvhkxI+gzwEnSAVHu/WZSu4XBzAOhsqs/ +9yhubJU2fY1RLhvuY5JEjpCrtOHOZgG3turkk3aqzPUhzpakjEkTvSX1fFjkpttAkws wjsF61dWlDWfqhio6FWYxoQcQRhH6FXBfFP60= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; b=mboa1hGdoxLKt2eMlIPFlglygzk3EZl4PHRluxfoD56U0Sw1greIvLkSgMvuup6n2q efOMaov1vdn1TpUAkLtu079AFQ0dpB5sTxWnsNEhJ+aSrCPzbYjhoMfQAafyzMh2RFH6 wy2rf+uCOjWXXCWOHSOTNN3v2X/l/vReDW3WQ= MIME-Version: 1.0 Received: by 10.224.20.74 with SMTP id e10mr1832400qab.362.1291861680752; Wed, 08 Dec 2010 18:28:00 -0800 (PST) Received: by 10.224.28.212 with HTTP; Wed, 8 Dec 2010 18:28:00 -0800 (PST) In-Reply-To: References: <0E901BAB-10FB-4263-ACBE-6247F61F41AF@yahoo.com> <2B5C75DA-830D-4343-8DC9-F9DDE57A1AAA@yahoo.com> <9E004281-2991-406F-82A1-D3497681E366@yahoo.com> Date: Thu, 9 Dec 2010 10:28:00 +0800 Message-ID: Subject: Re: ordering tck failures in geronimo From: Ivan To: dev@geronimo.apache.org, dev@myfaces.apache.org Content-Type: multipart/alternative; boundary=000e0ce04a3a9488dd0496f0fc72 X-Virus-Checked: Checked by ClamAV on apache.org --000e0ce04a3a9488dd0496f0fc72 Content-Type: text/plain; charset=ISO-8859-1 my 2 cents, it seems for me less urgly ... a. For the FacesConfigurationProvider , it is better to have only one method getFacesConfigData() b. Create another abstract class AbstractFacesConfigurationProvider which extends FacesConfigurationProvider, and define those proctected methods of get***, also place those sorting/merging codes there. c. In the DefaultFacesConfigurationProvider, it only implements those get*** methods. thanks. 2010/12/9 Leonardo Uribe > Hi > > I agree with Jakob about faces-config merging and ordering algorithm should > not be exposed by MyFaces. Why is it not enough?. At this point it is not > clear the reasons. Note in this moment ordering and sorting algoritm it is > not being exposed by FacesConfigurationProvider interface. > > Other different thing is FacesConfigurationProvider.getFacesConfigData(). > The intention of this method is provide a way to get a Serializable object > that represents all config information required to initialize MyFaces and > allow container to store it temporally somewere. In this way it is possible > to deploy and undeploy an application more quickly, because if "nothing > changes"(no added dependencies, no update from faces-config.xml files or > classes) this information is always the same. > > On MYFACES-2945 and previous discussions it was proposed two different > options: > > 1. Add getFacesConfigData() > 2. Add a set of methods to retrieve FacesConfig objects instead. > > > public abstract FacesConfig getStandardFacesConfig(ExternalContext > ectx); > public abstract FacesConfig > getMetaInfServicesFacesConfig(ExternalContext ectx); > public abstract FacesConfig getAnnotationsFacesConfig(ExternalContext > ectx, boolean metadataComplete); > public abstract List > getClassloaderFacesConfig(ExternalContext ectx); > public abstract List > getContextSpecifiedFacesConfig(ExternalContext ectx); > public abstract FacesConfig getWebAppFacesConfig(ExternalContext ectx); > > > The first option has the advantage that it fill the initial requeriment > without add more complexity to the problem. The second one seems to be more > structured and opens the possibility to do other things like how override > MyFaces parsing for faces-config.xml files like it is being discussed. If > the container parse faces-config.xml files, with the previous methods it is > possible to prevent parse the same files twice. > > My first intention, as is shown on MYFACES-2945 was that > FacesConfigurationProvider does not included getFacesConfigData(), because > it is possible to fill the initial objective with these methods, but finally > it was agreed the first option looks better, right? > > Now I see that on MYFACES-2998 that fact is questioned: > > JK>> Unfortunately it also provides a method that should combine all these > data: getFacesConfigData(). > JK>> This method is here due to refactorings, but IMHO this is the last > place where it should be put, > JK>> because it gets "its own implementation" via its Factory and then > calls all of the above methods on > JK>> it. I know this was introduced to support wrapping the default impl, > but it really is very, very ugly. > > In few words, why does it looks ugly? or with other words, what can we do > to make it cleaner? remove it? or just provide another SPI interface and put > that method there? In practice, getFacesConfigData() merges all FacesConfig > information, and "on the way" it does order applicationFacesConfig files > (the ones obtained from getClassloaderFacesConfig() and > getContextSpecifiedFacesConfig() ) . To do that it requires to call all six > methods from FacesConfigurationProvider, there is no other way, so I don't > see why do that is considered ugly. > > At this moment we have the following courses of action: > > 1. Remove FacesConfigurationResource interface partially, because it is > still too inmature and let it for myfaces core 2.0.4. > 2. Create another SPI interface for getFacesConfigData() (please suggest a > name for it, maybe FacesConfigurationMergerProvider?) and remove this method > form FacesConfigurationResource. Apply the patch on MYFACES-2998 seems to be > in this direction, but forget the reason why it is wanted to expose > getFacesConfigData() to the container. > 3. Apply something like MYFACES-2998 patch, and refactor this one later in > myfaces core 2.0.4 > > Suggestions are welcome. > > regards, > > Leonardo Uribe > > > > > -- Ivan --000e0ce04a3a9488dd0496f0fc72 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable my 2 cents, it seems for me less urgly ...
a. For the FacesConfiguration= Provider , it is better to have only one method getFacesConfigData()
b. = Create another abstract class AbstractFacesConfigurationProvider which exte= nds FacesConfigurationProvider, and define those proctected methods of get*= **, also place those sorting/merging codes there.
c. In the DefaultFacesConfigurationProvider, it only implements those get**= * methods.
thanks.

2010/12/9 Leonardo = Uribe <lu4242@gmai= l.com>
Hi

I agree= with Jakob about faces-config merging and ordering algorithm should not be= exposed by MyFaces. Why is it not enough?. At this point it is not clear t= he reasons. Note in this moment ordering and sorting algoritm it is not bei= ng exposed by FacesConfigurationProvider interface.

Other different thing is=20 FacesConfigurationProvider.getFacesConfigData(). The intention of this meth= od is provide a way to get a Serializable object that represents all config= information required to initialize MyFaces and allow container to store it= temporally somewere. In this way it is possible to deploy and undeploy an = application more quickly, because if "nothing changes"(no added d= ependencies, no update from faces-config.xml files or classes) this informa= tion is always the same.

On MYFACES-2945 and previous discussions it was proposed two different = options:

1. Add getFacesConfigData()
2. Add a set of methods to= retrieve FacesConfig objects instead.


=A0=A0=A0 p= ublic abstract FacesConfig getStandardFacesConfig(ExternalContext=20 ectx);
=A0=A0=A0 public abstract FacesConfig=20 getMetaInfServicesFacesConfig(ExternalContext ectx);
=A0=A0=A0 public=20 abstract FacesConfig getAnnotationsFacesConfig(ExternalContext ectx,=20 boolean metadataComplete);
=A0=A0=A0 public abstract=20 List<FacesConfig> getClassloaderFacesConfig(ExternalContext ectx);=A0=A0=A0 public abstract List<FacesConfig>=20 getContextSpecifiedFacesConfig(ExternalContext ectx);
=A0=A0=A0 public= =20 abstract FacesConfig getWebAppFacesConfig(ExternalContext ectx);

The first option has the advantage that it fill the initial requeriment= without add more complexity to the problem. The second one seems to be mor= e structured and opens the possibility to do other things like how override= MyFaces parsing for faces-config.xml files like it is being discussed. If = the container parse faces-config.xml files, with the previous methods it is= possible to prevent parse the same files twice.

My first intention, as is shown on MYFACES-2945 was that FacesConfigura= tionProvider does not included getFacesConfigData(), because it is possible= to fill the initial objective with these methods, but finally it was agree= d the first option looks better, right?

Now I see that on MYFACES-2998 that fact is questioned:

JK>&g= t; Unfortunately it also provides a method that should combine all these=20 data: getFacesConfigData().
JK>> This method is here due to refac= torings, but IMHO this is the last place where it should be put,
JK>> because= it gets=20 "its own implementation" via its Factory and then calls all of th= e above methods on
JK>> it. I know this was introduced to support wrappi= ng the=20 default impl, but it really is very, very ugly.

In few words, why does it looks ugly? or with other words, what can= we do to make it cleaner? remove it? or just provide another SPI interface= and put that method there? In practice, getFacesConfigData() merges all Fa= cesConfig information, and "on the way" it does order application= FacesConfig files (the ones obtained from getClassloaderFacesConfig() and= =20 getContextSpecifiedFacesConfig() ) . To do that it requires to call all six= methods from FacesConfigurationProvider, there is no other way, so I don&#= 39;t see why do that is considered ugly.

At this moment we have the = following courses of action:

1. Remove FacesConfigurationResource interface partially, because it is= still too inmature and let it for myfaces core 2.0.4.
2. Create another= SPI interface for getFacesConfigData() (please suggest a name for it, mayb= e FacesConfigurationMergerProvider?) and remove this method form FacesConfi= gurationResource. Apply the patch on MYFACES-2998 seems to be in this direc= tion, but forget the reason why it is wanted to expose getFacesConfigData()= to the container.
3. Apply something like MYFACES-2998 patch, and refactor this one later in = myfaces core 2.0.4

Suggestions are welcome.

regards,

Leonardo Uribe







--
Ivan
--000e0ce04a3a9488dd0496f0fc72--