Return-Path: Delivered-To: apmail-myfaces-dev-archive@www.apache.org Received: (qmail 18258 invoked from network); 8 Dec 2010 21:08:42 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 8 Dec 2010 21:08:42 -0000 Received: (qmail 82279 invoked by uid 500); 8 Dec 2010 21:08:42 -0000 Delivered-To: apmail-myfaces-dev-archive@myfaces.apache.org Received: (qmail 82243 invoked by uid 500); 8 Dec 2010 21:08:42 -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 82236 invoked by uid 99); 8 Dec 2010 21:08:42 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Dec 2010 21:08:42 +0000 X-ASF-Spam-Status: No, hits=3.7 required=10.0 tests=FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of lu4242@gmail.com designates 74.125.82.43 as permitted sender) Received: from [74.125.82.43] (HELO mail-ww0-f43.google.com) (74.125.82.43) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 08 Dec 2010 21:08:33 +0000 Received: by wwi17 with SMTP id 17so1579331wwi.0 for ; Wed, 08 Dec 2010 13:08:13 -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:cc:content-type; bh=WGGE6vhFmk/pElAvRbe8rfisi8JUXZkrz9auSASw8Nw=; b=KuF0UvrQOI5kWaQ5lC46f4hSVjXo4ykRuBPD1g1eYPEyTybE5uWkW6uDVvVudAwu// pJgJYpDBW1SIfuIPQ0NgfNU3GziP5xt9NVmXI3sHwOY0fKrj1JC5JkrLmc3KjI3YH9zm yw35oCgLY0vydV0+KH4heMhJTeOMMlTAHhM5E= 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 :cc:content-type; b=G+zTLTHVfPgXwRdWqkr8QJwFk13lOb2w8mHObZhz6dNBhrAIW+10nW3YGXZ3FznkW3 X30tJMBBUBYsnGDFtBagYGF1RoxIFmAdjFiv4lVN/XOLQNHWtr1NDweiqge3yQy/qpGC ggOn4fiKAIXMEM1U0wQnkkxslbsIDokpayVfQ= MIME-Version: 1.0 Received: by 10.227.132.208 with SMTP id c16mr9755299wbt.25.1291842493104; Wed, 08 Dec 2010 13:08:13 -0800 (PST) Received: by 10.216.137.3 with HTTP; Wed, 8 Dec 2010 13:08:12 -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: Wed, 8 Dec 2010 16:08:12 -0500 Message-ID: Subject: Re: ordering tck failures in geronimo From: Leonardo Uribe To: MyFaces Development Cc: dev@geronimo.apache.org, Jakob Korherr Content-Type: multipart/alternative; boundary=0016e649ceace844c50496ec840d X-Virus-Checked: Checked by ClamAV on apache.org --0016e649ceace844c50496ec840d Content-Type: text/plain; charset=ISO-8859-1 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 --0016e649ceace844c50496ec840d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi

I agree with Jakob about faces-config merging and ordering algori= thm 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 algor= itm it is not being 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 public abstract Fac= esConfig 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);

Th= e first option has the advantage that it fill the initial requeriment witho= ut add more complexity to the problem. The second one seems to be more stru= ctured and opens the possibility to do other things like how override MyFac= es parsing for faces-config.xml files like it is being discussed. If the co= ntainer parse faces-config.xml files, with the previous methods it is possi= ble 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,

L= eonardo Uribe




--0016e649ceace844c50496ec840d--