Re: [VOTE] release for myfaces commons 1.0.1
+1 Everything looks fine! Regards, Jakob 2010/12/9 Leonardo Uribe lu4...@gmail.com: +1 2010/12/8 Leonardo Uribe lu4...@gmail.com Hi, I was running the needed tasks to get the 1.0.1 release of Apache MyFaces Commons out. MyFaces Commons project aims to provide non-renderkit-specific utilites that can be used with any MyFaces JSF framework. Myfaces Commons provide artifacts compatible with JSF 1.1, 1.2 and 2.0. For more info about this artifacts take a loot at the site on ([4]). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.commons v1.0.1 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [5]. Please take a look at the 1.0.1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-007/org/apache/myfaces/commons/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfacescommons101binsrc [4] http://myfaces.apache.org/commons [5] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310846styleName=Htmlversion=12315967 -- Jakob Korherr blog: http://www.jakobk.com twitter: http://twitter.com/jakobkorherr work: http://www.irian.at
Re: ordering tck failures in geronimo
Hi, I called it ugly, because of its implementation code in DefaultFacesConfigurationProvider: The method is already inside of a FacesConfigurationProvider, but it does this: FacesConfigurationProvider provider = FacesConfigurationProviderFactory. getFacesConfigurationProviderFactory(_externalContext). getFacesConfigurationProvider(_externalContext); ...and then calls all the other methods of FacesConfigurationProvider on this provider instance. As I said, I know this is this way, because FacesConfigurationProvider can be wrapped, but IMHO it is really ugly. The method used on MYFACES-2998 was a first approach to solve this problem in a better way. However, I really like those two of your suggestions: 1) Leo #2: Create another SPI interface for getFacesConfigData() (please suggest a name for it, maybe FacesConfigurationMergerProvider?) and remove this method form FacesConfigurationProvider. 2) Ivan: In a few words: let getFacesConfigData() on FacesConfigurationProvider, but provide an AbstractFacesConfigurationProvider which implements the merging and sorting to let custom SPI impls take advantage of it. At first, I really liked Ivan's proposal, but after thinking more about it, it is not consistent with what we have right now (we do not provide any other Abstract-SPI impl) and we would have the huge merging and sorting code all in the SPI(-api) package, but IMO it should really go into o.a.m.config. Thus I think that a new FacesConfigurationMergerProvider-SPI as Leo proposed is the best choice here. Note that for this SPI it is good practice to use other SPI impls. I will provide a patch for it soon and then we can discuss it further! Regards, Jakob 2010/12/9 Ivan xhh...@gmail.com: 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 lu4...@gmail.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 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 ListFacesConfig getClassloaderFacesConfig(ExternalContext ectx); public abstract ListFacesConfig 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
[jira] Commented: (MYFACES-2945) Make a way to get the FacesConfig from a provider
[ https://issues.apache.org/jira/browse/MYFACES-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969694#action_12969694 ] Jakob Korherr commented on MYFACES-2945: Just for reference: related discussion on the mailing-list: http://www.mail-archive.com/dev@myfaces.apache.org/msg50248.html Make a way to get the FacesConfig from a provider - Key: MYFACES-2945 URL: https://issues.apache.org/jira/browse/MYFACES-2945 Project: MyFaces Core Issue Type: Improvement Components: SPI Affects Versions: 2.0.2 Reporter: Ivan Assignee: Leonardo Uribe Fix For: 2.0.3-SNAPSHOT Attachments: MYFACES-2945-2.patch, MYFACES-2945-3.patch Currently, MyFaces startup listener will parse the all the faces configuration files and sort them on each startup time, and it will be better to do it once in the deployment time, and get those data structure instances from a provider. One possible way is to make those FacesConfig class serializable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2945) Make a way to get the FacesConfig from a provider
[
https://issues.apache.org/jira/browse/MYFACES-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969699#action_12969699
]
Jakob Korherr commented on MYFACES-2945:
With the patch MYFACES-2945-FacesConfigurationMerger.patch the following is
possible for Geronimo:
public class GeronimoFacesConfigurationMerger extends FacesConfigurationMerger
{
private FacesConfigurationMerger myfacesProvider;
public GeronimoFacesConfigurationMerger(FacesConfigurationMerger
myfacesProvider)
{
this.myfacesProvider = myfacesProvider;
}
@Override
public FacesConfigData getFacesConfigData(FacesConfigurationProvider
facesConfigProvider, ExternalContext ectx)
{
FacesConfigData facesConfigData = getCachedData(ectx);
if (facesConfigData == null)
{
// merge the data using MyFaces' FacesConfigurationMerger impl
facesConfigData =
myfacesProvider.getFacesConfigData(facesConfigProvider, ectx);
// cache it
cacheFacesConfigData(facesConfigData, ectx);
}
return facesConfigData;
}
private FacesConfigData getCachedData(ExternalContext ectx)
{
// TODO get cached FacesConfigData instance
return null;
}
private void cacheFacesConfigData(FacesConfigData facesConfigData,
ExternalContext ectx)
{
// TODO cache data
}
}
If no objections, I will commit this patch soon!
Make a way to get the FacesConfig from a provider
-
Key: MYFACES-2945
URL: https://issues.apache.org/jira/browse/MYFACES-2945
Project: MyFaces Core
Issue Type: Improvement
Components: SPI
Affects Versions: 2.0.2
Reporter: Ivan
Assignee: Leonardo Uribe
Fix For: 2.0.3-SNAPSHOT
Attachments: MYFACES-2945-2.patch, MYFACES-2945-3.patch,
MYFACES-2945-FacesConfigurationMerger.patch
Currently, MyFaces startup listener will parse the all the faces
configuration files and sort them on each startup time, and it will be better
to do it once in the deployment time, and get those data structure instances
from a provider. One possible way is to make those FacesConfig class
serializable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: ordering tck failures in geronimo
Hi guys, I just uploaded a patch for a FacesConfigurationMerger SPI: MYFACES-2945-FacesConfigurationMerger.patch Furthermore I added a quick code sample as comment on the MYFACES-2945 issue about how Geronimo can use this new SPI. Please take a look at the patch and if there are no objections, I will commit it soon! Regards, Jakob 2010/12/9 Jakob Korherr jakob.korh...@gmail.com: Hi, I called it ugly, because of its implementation code in DefaultFacesConfigurationProvider: The method is already inside of a FacesConfigurationProvider, but it does this: FacesConfigurationProvider provider = FacesConfigurationProviderFactory. getFacesConfigurationProviderFactory(_externalContext). getFacesConfigurationProvider(_externalContext); ...and then calls all the other methods of FacesConfigurationProvider on this provider instance. As I said, I know this is this way, because FacesConfigurationProvider can be wrapped, but IMHO it is really ugly. The method used on MYFACES-2998 was a first approach to solve this problem in a better way. However, I really like those two of your suggestions: 1) Leo #2: Create another SPI interface for getFacesConfigData() (please suggest a name for it, maybe FacesConfigurationMergerProvider?) and remove this method form FacesConfigurationProvider. 2) Ivan: In a few words: let getFacesConfigData() on FacesConfigurationProvider, but provide an AbstractFacesConfigurationProvider which implements the merging and sorting to let custom SPI impls take advantage of it. At first, I really liked Ivan's proposal, but after thinking more about it, it is not consistent with what we have right now (we do not provide any other Abstract-SPI impl) and we would have the huge merging and sorting code all in the SPI(-api) package, but IMO it should really go into o.a.m.config. Thus I think that a new FacesConfigurationMergerProvider-SPI as Leo proposed is the best choice here. Note that for this SPI it is good practice to use other SPI impls. I will provide a patch for it soon and then we can discuss it further! Regards, Jakob 2010/12/9 Ivan xhh...@gmail.com: 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 lu4...@gmail.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 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 ListFacesConfig getClassloaderFacesConfig(ExternalContext ectx); public abstract ListFacesConfig 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:
[jira] Created: (MYFACES-2999) Using XML Comment in HTML Panel Grid
Using XML Comment in HTML Panel Grid Key: MYFACES-2999 URL: https://issues.apache.org/jira/browse/MYFACES-2999 Project: MyFaces Core Issue Type: Bug Components: JSR-252 Affects Versions: 2.0.2 Reporter: Gurkan Erdogdu When using !-- Some comment -- in a panelGrid tag, panelGrid is not rendered correctly. For example, h:panelGrid columns=2 !-- Some comment -- h:outputText ./ h:outputText / /h:panelGrid Above code has not rendered correctly! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [VOTE] Release of Extensions CDI (CODI) 0.9.1
+1 Am 06.12.10 19:35, schrieb Mark Struberg: did some test runs with our app and it looks very good. Artifacts and source-release looks fine too. +1 LieGrue, strub --- On Mon, 12/6/10, Matthias Wessendorfmat...@apache.org wrote: From: Matthias Wessendorfmat...@apache.org Subject: Re: [VOTE] Release of Extensions CDI (CODI) 0.9.1 To: MyFaces Developmentdev@myfaces.apache.org Date: Monday, December 6, 2010, 6:21 PM +1 On Mon, Dec 6, 2010 at 3:58 AM, Gerhard Petracekgpetra...@apache.org wrote: Hi, We were running the needed tasks to get the 2nd release of Apache MyFaces Extensions CDI (aka MyFaces CODI) out. The artifacts are deployed to Nexus [1] (and [2]). The release contains the following modules: - CODI Core - CODI JSF Module (for 1.2 and 2.0) - CODI JPA Module - CODI BV Module - CODI I18N-Message Module - CODI Scripting Module - CODI Trinidad Support Module - CODI Distribution Modules Please take a look at the 0.9.1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [3]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Gerhard [1] https://repository.apache.org/content/repositories/orgapachemyfaces-050/ [2] https://repository.apache.org/content/repositories/orgapachemyfaces-050/org/apache/myfaces/extensions/cdi/myfaces-extcdi-parent/0.9.1/myfaces-extcdi-parent-0.9.1-source-release.zip [3] http://www.apache.org/foundation/voting.html#ReleaseVotes -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [VOTE] release for myfaces commons 1.0.1
+1 Am 09.12.10 02:46, schrieb Leonardo Uribe: Hi, I was running the needed tasks to get the 1.0.1 release of Apache MyFaces Commons out. MyFaces Commons project aims to provide non-renderkit-specific utilites that can be used with any MyFaces JSF framework. Myfaces Commons provide artifacts compatible with JSF 1.1, 1.2 and 2.0. For more info about this artifacts take a loot at the site on ([4]). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.commons v1.0.1 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [5]. Please take a look at the 1.0.1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-007/org/apache/myfaces/commons/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfacescommons101binsrc [4] http://myfaces.apache.org/commons [5] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310846styleName=Htmlversion=12315967 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310846styleName=Htmlversion=12315967
[jira] Created: (TRINIDAD-1976) UIXEditableValue lacks calls to pushComponentToEL(context, this);
UIXEditableValue lacks calls to pushComponentToEL(context, this);
-
Key: TRINIDAD-1976
URL: https://issues.apache.org/jira/browse/TRINIDAD-1976
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0.3-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Priority: Critical
UIXEditableValue never calls pushComponentToEL(context, this); during
validation (and possibly other lifecycle methods). As a result #{component} is
wrong during validation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] release for myfaces commons 1.0.1
+1 sent from my Android phone On Dec 9, 2010 8:15 PM, Werner Punz werner.p...@gmail.com wrote: +1 Am 09.12.10 02:46, schrieb Leonardo Uribe: Hi, I was running the needed tasks to get the 1.0.1 release of Apache MyFaces Commons out. MyFaces Commons project aims to provide non-renderkit-specific utilites that can be used with any MyFaces JSF framework. Myfaces Commons provide artifacts compatible with JSF 1.1, 1.2 and 2.0. For more info about this artifacts take a loot at the site on ([4]). Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.commons v1.0.1 [1] The artifacts were deployed on nexus repo [1] and to my private Apache account [3] for binary and source packages. The release notes could be found at [5]. Please take a look at the 1.0.1 artifacts and vote! Please note: This vote is majority approval with a minimum of three +1 votes (see [2]). [ ] +1 for community members who have reviewed the bits [ ] +0 [ ] -1 for fatal flaws that should cause these bits not to be released, and why.. Thanks, Leonardo Uribe [1] https://repository.apache.org/content/repositories/orgapachemyfaces-007/org/apache/myfaces/commons/ [2] http://www.apache.org/foundation/voting.html#ReleaseVotes [3] http://people.apache.org/~lu4242/myfacescommons101binsrc [4] http://myfaces.apache.org/commons [5] https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310846styleName=Htmlversion=12315967 https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310846styleName=Htmlversion=12315967
[jira] Commented: (TRINIDAD-1976) UIXEditableValue lacks calls to pushComponentToEL(context, this);
[
https://issues.apache.org/jira/browse/TRINIDAD-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969911#action_12969911
]
Andrew Robinson commented on TRINIDAD-1976:
---
Example that is broken:
tr:inputText value=#{bean.map[component.clientId]} /
UIXEditableValue lacks calls to pushComponentToEL(context, this);
-
Key: TRINIDAD-1976
URL: https://issues.apache.org/jira/browse/TRINIDAD-1976
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0.3-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Priority: Critical
UIXEditableValue never calls pushComponentToEL(context, this); during
validation (and possibly other lifecycle methods). As a result #{component}
is wrong during validation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1976) UIXEditableValue lacks calls to pushComponentToEL(context, this);
[
https://issues.apache.org/jira/browse/TRINIDAD-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969910#action_12969910
]
Andrew Robinson commented on TRINIDAD-1976:
---
Note that the same issue exists in Mojarra UIInput:
http://java.net/jira/browse/JAVASERVERFACES-1890
UIXEditableValue lacks calls to pushComponentToEL(context, this);
-
Key: TRINIDAD-1976
URL: https://issues.apache.org/jira/browse/TRINIDAD-1976
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0.3-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Priority: Critical
UIXEditableValue never calls pushComponentToEL(context, this); during
validation (and possibly other lifecycle methods). As a result #{component}
is wrong during validation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2945) Make a way to get the FacesConfig from a provider
[ https://issues.apache.org/jira/browse/MYFACES-2945?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12969918#action_12969918 ] Leonardo Uribe commented on MYFACES-2945: - I think it is not necessary to pass FacesConfigurationProvider as param for getFacesConfigData, because in theory we don't do anything with it before pass it and wrappers will not do anything with it later. I think it looks good to load it using FacesConfigurationProviderFactory.getFacesConfigurationProvider(ExternalContext). Make a way to get the FacesConfig from a provider - Key: MYFACES-2945 URL: https://issues.apache.org/jira/browse/MYFACES-2945 Project: MyFaces Core Issue Type: Improvement Components: SPI Affects Versions: 2.0.2 Reporter: Ivan Assignee: Leonardo Uribe Fix For: 2.0.3-SNAPSHOT Attachments: MYFACES-2945-2.patch, MYFACES-2945-3.patch, MYFACES-2945-FacesConfigurationMerger.patch Currently, MyFaces startup listener will parse the all the faces configuration files and sort them on each startup time, and it will be better to do it once in the deployment time, and get those data structure instances from a provider. One possible way is to make those FacesConfig class serializable. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ordering tck failures in geronimo
Hi I think it is not necessary to pass FacesConfigurationProvider as param for getFacesConfigData, because in theory we don't do anything with it before pass it and wrappers will not do anything with it later. I think it looks good to load it using FacesConfigurationProviderFactory.getFacesConfigurationProvider(ExternalContext). The other parts of the patch looks good. regards, Leonardo Uribe 2010/12/9 Jakob Korherr jakob.korh...@gmail.com Hi guys, I just uploaded a patch for a FacesConfigurationMerger SPI: MYFACES-2945-FacesConfigurationMerger.patch Furthermore I added a quick code sample as comment on the MYFACES-2945 issue about how Geronimo can use this new SPI. Please take a look at the patch and if there are no objections, I will commit it soon! Regards, Jakob 2010/12/9 Jakob Korherr jakob.korh...@gmail.com: Hi, I called it ugly, because of its implementation code in DefaultFacesConfigurationProvider: The method is already inside of a FacesConfigurationProvider, but it does this: FacesConfigurationProvider provider = FacesConfigurationProviderFactory. getFacesConfigurationProviderFactory(_externalContext). getFacesConfigurationProvider(_externalContext); ...and then calls all the other methods of FacesConfigurationProvider on this provider instance. As I said, I know this is this way, because FacesConfigurationProvider can be wrapped, but IMHO it is really ugly. The method used on MYFACES-2998 was a first approach to solve this problem in a better way. However, I really like those two of your suggestions: 1) Leo #2: Create another SPI interface for getFacesConfigData() (please suggest a name for it, maybe FacesConfigurationMergerProvider?) and remove this method form FacesConfigurationProvider. 2) Ivan: In a few words: let getFacesConfigData() on FacesConfigurationProvider, but provide an AbstractFacesConfigurationProvider which implements the merging and sorting to let custom SPI impls take advantage of it. At first, I really liked Ivan's proposal, but after thinking more about it, it is not consistent with what we have right now (we do not provide any other Abstract-SPI impl) and we would have the huge merging and sorting code all in the SPI(-api) package, but IMO it should really go into o.a.m.config. Thus I think that a new FacesConfigurationMergerProvider-SPI as Leo proposed is the best choice here. Note that for this SPI it is good practice to use other SPI impls. I will provide a patch for it soon and then we can discuss it further! Regards, Jakob 2010/12/9 Ivan xhh...@gmail.com: 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 lu4...@gmail.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 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 ListFacesConfig getClassloaderFacesConfig(ExternalContext ectx); public abstract ListFacesConfig 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
Result (was: Re: [VOTE] Release of Extensions CDI (CODI) 0.9.1)
thank you for voting! 6 binding +1 votes (pmc): - Matthias Wessendorf - Jakob Korherr - Leonardo Uribe - Grant Smith - Werner Punz - Gerhard Petracek 3 non-binding +1 votes: - Mark Struberg - Rudy De Busscher - Michael Kurz no -1 votes regards, gerhard -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Resolved: (TRINIDAD-1976) UIXEditableValue lacks calls to pushComponentToEL(context, this);
[
https://issues.apache.org/jira/browse/TRINIDAD-1976?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-1976.
---
Resolution: Fixed
Fix Version/s: 2.0.0.3-core
Changed the code to ensure that the component is available to EL during
decoding, validation, and updating when performing the input value processing
UIXEditableValue lacks calls to pushComponentToEL(context, this);
-
Key: TRINIDAD-1976
URL: https://issues.apache.org/jira/browse/TRINIDAD-1976
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 2.0.0.3-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Priority: Critical
Fix For: 2.0.0.3-core
UIXEditableValue never calls pushComponentToEL(context, this); during
validation (and possibly other lifecycle methods). As a result #{component}
is wrong during validation.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
