Re: [REVOTE] Ext-Scripting Alpha1
+1 On Tue, Feb 9, 2010 at 11:46 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +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/2/9 Werner Punz werner.p...@gmail.com Hello, as some may remember I had to pull the vote of ext-scripting Alpha 1 due to a missing parent pom in the projects main pom. Nevertheless I have done all the changes and used the opportunity for some pre alpha code cleanup. I would like to restart the vote, to get the Alpha finally out. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Please integrate patch from TRINIDAD-1397
Hi, last year in the beginning of autumn we added a patch for a serious and annoying skinning bug. see: https://issues.apache.org/jira/browse/TRINIDAD-1397 Would you please be so kind and integrate this patch? Thanks in advance! Best regards Elmar
Re: [core] Backwards compatibility (e.g. MYFACES-2543)
IMHO the spec is very clear about this and the stuff in the appendix is a spec bug. From the spec (10.1.2): A decision was made early in this process to strive for backwards compatibility between the latest popular version of Facelets and Facelets in JSF 2.0. The sole determinant to backwards compatibility lies in the answer to the question, “is there any Java code in the application, or in libraries used by the application, that extends from or depends on any class in package com.sun.facelets and/or its sub-packages?” ■ If the answer to this question is “yes”, Facelets in JSF 2.0 is not backwards compatibile with Facelets and such an application must continue to bundle the Facelets jar file along with the application, continue to set the Facelets configuration parameters, and also set the javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER context-param to true. Please see Section 11.1.3 “Application Configuration Parameters” for details on this option. Any code that extends or depends on any class in package com.sun.facelets and/or its sub-packages must be modified to depend on the appropriate classes in package javax.faces.webapp.vdl and/or its subpackages. ■ If the answer to this question is “no”, Facelets in JSF 2.0 is backwards compatible with pre-JSF 2.0 Facelets and such an application must not continue to bundle the Facelets jar file along with the application, and must not continue to set the Facelets configuration parameters. Thankfully, most applications that use Facelets fall into the latter category, or, if they fall in the former, their dependence will easily be migrated to the new public classes. Best regards, Ganesh Matthias Wessendorf schrieb: On Wed, Feb 10, 2010 at 6:26 AM, Ganesh gan...@j4fry.org wrote: Many Facelets taglibs don't use Facelets tag handlers, but simply wrap some xhtml templates. Nothing will stop these libraries to work with MyFaces if we allow old version taglibs. If we insist on refusing them people will simply switch to Mojarra to get their application to run. I know; that's what I meant with my comment before The argument of a xsd:restriction in the spec will help little. Just taking old Facelets is *not* a solution, because the rest of the application may want to use the new features. Please try filing this as a bug to Mojarra as Matthias proposed - if they fix it, MyFaces may insist on version=2.0, but if they don't I think we shouldn't either. I agree I've carried the question whether a JSF 2.0 compatible implementation is required to refuse old version facelets taglibs into the EG - let's see, what they have to say technically, I think now we are correct. @Jakob: Did you create such a bug against the RI ? (that they allow old Facelets) maybe another on not being (too) clear in the spec about it... -Matthias on this ... Best regards, Ganesh I see both ways; I think I don't like the fact that the RI has this bug :) So, end of the story is, almost everybody will blame this to us ;-) Oh, crappy MyFaces doesn't work etc :) All the FUD! :)
Re: [core] Backwards compatibility (e.g. MYFACES-2543)
On Wed, Feb 10, 2010 at 10:44 AM, Ganesh gan...@j4fry.org wrote: IMHO the spec is very clear about this and the stuff in the appendix is a spec bug. From the spec (10.1.2): A decision was made early in this process to strive for backwards compatibility between the latest popular version of Facelets and Facelets in JSF 2.0. The sole determinant to backwards compatibility lies in the answer to the question, “is there any Java code in the application, or in libraries used by the application, that extends from or depends on any class in package com.sun.facelets and/or its sub-packages?” ■ If the answer to this question is “yes”, Facelets in JSF 2.0 is not backwards compatibile with Facelets and such an application must continue to bundle the Facelets jar file along with the application, continue to set the Facelets configuration parameters, and also set the javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER context-param to true. Please see Section 11.1.3 “Application Configuration Parameters” for details on this option. Any code that extends or depends on any class in package com.sun.facelets and/or its sub-packages must be modified to depend on the appropriate classes in package javax.faces.webapp.vdl and/or its subpackages. yes (see previous email(s)) ■ If the answer to this question is “no”, Facelets in JSF 2.0 is backwards compatible with pre-JSF 2.0 Facelets and such an application must not continue to bundle the Facelets jar file along with the application, and must not continue to set the Facelets configuration parameters. Thankfully, most applications that use Facelets fall into the latter category, or, if they fall in the former, their dependence will easily be migrated to the new public classes. ok. please; file a bug on that appendix thing. thjx -m Best regards, Ganesh Matthias Wessendorf schrieb: On Wed, Feb 10, 2010 at 6:26 AM, Ganesh gan...@j4fry.org wrote: Many Facelets taglibs don't use Facelets tag handlers, but simply wrap some xhtml templates. Nothing will stop these libraries to work with MyFaces if we allow old version taglibs. If we insist on refusing them people will simply switch to Mojarra to get their application to run. I know; that's what I meant with my comment before The argument of a xsd:restriction in the spec will help little. Just taking old Facelets is *not* a solution, because the rest of the application may want to use the new features. Please try filing this as a bug to Mojarra as Matthias proposed - if they fix it, MyFaces may insist on version=2.0, but if they don't I think we shouldn't either. I agree I've carried the question whether a JSF 2.0 compatible implementation is required to refuse old version facelets taglibs into the EG - let's see, what they have to say technically, I think now we are correct. @Jakob: Did you create such a bug against the RI ? (that they allow old Facelets) maybe another on not being (too) clear in the spec about it... -Matthias on this ... Best regards, Ganesh I see both ways; I think I don't like the fact that the RI has this bug :) So, end of the story is, almost everybody will blame this to us ;-) Oh, crappy MyFaces doesn't work etc :) All the FUD! :) -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [core] Backwards compatibility (e.g. MYFACES-2543)
No I have not filed any bugs. Feel free to file them ;) Regards, Jakob 2010/2/10 Matthias Wessendorf mat...@apache.org On Wed, Feb 10, 2010 at 10:44 AM, Ganesh gan...@j4fry.org wrote: IMHO the spec is very clear about this and the stuff in the appendix is a spec bug. From the spec (10.1.2): A decision was made early in this process to strive for backwards compatibility between the latest popular version of Facelets and Facelets in JSF 2.0. The sole determinant to backwards compatibility lies in the answer to the question, “is there any Java code in the application, or in libraries used by the application, that extends from or depends on any class in package com.sun.facelets and/or its sub-packages?” ■ If the answer to this question is “yes”, Facelets in JSF 2.0 is not backwards compatibile with Facelets and such an application must continue to bundle the Facelets jar file along with the application, continue to set the Facelets configuration parameters, and also set the javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER context-param to true. Please see Section 11.1.3 “Application Configuration Parameters” for details on this option. Any code that extends or depends on any class in package com.sun.facelets and/or its sub-packages must be modified to depend on the appropriate classes in package javax.faces.webapp.vdl and/or its subpackages. yes (see previous email(s)) ■ If the answer to this question is “no”, Facelets in JSF 2.0 is backwards compatible with pre-JSF 2.0 Facelets and such an application must not continue to bundle the Facelets jar file along with the application, and must not continue to set the Facelets configuration parameters. Thankfully, most applications that use Facelets fall into the latter category, or, if they fall in the former, their dependence will easily be migrated to the new public classes. ok. please; file a bug on that appendix thing. thjx -m Best regards, Ganesh Matthias Wessendorf schrieb: On Wed, Feb 10, 2010 at 6:26 AM, Ganesh gan...@j4fry.org wrote: Many Facelets taglibs don't use Facelets tag handlers, but simply wrap some xhtml templates. Nothing will stop these libraries to work with MyFaces if we allow old version taglibs. If we insist on refusing them people will simply switch to Mojarra to get their application to run. I know; that's what I meant with my comment before The argument of a xsd:restriction in the spec will help little. Just taking old Facelets is *not* a solution, because the rest of the application may want to use the new features. Please try filing this as a bug to Mojarra as Matthias proposed - if they fix it, MyFaces may insist on version=2.0, but if they don't I think we shouldn't either. I agree I've carried the question whether a JSF 2.0 compatible implementation is required to refuse old version facelets taglibs into the EG - let's see, what they have to say technically, I think now we are correct. @Jakob: Did you create such a bug against the RI ? (that they allow old Facelets) maybe another on not being (too) clear in the spec about it... -Matthias on this ... Best regards, Ganesh I see both ways; I think I don't like the fact that the RI has this bug :) So, end of the story is, almost everybody will blame this to us ;-) Oh, crappy MyFaces doesn't work etc :) All the FUD! :) -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [REVOTE] Ext-Scripting Alpha1
+1 Regards, Jakob 2010/2/10 Matthias Wessendorf mat...@apache.org +1 On Tue, Feb 9, 2010 at 11:46 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +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/2/9 Werner Punz werner.p...@gmail.com Hello, as some may remember I had to pull the vote of ext-scripting Alpha 1 due to a missing parent pom in the projects main pom. Nevertheless I have done all the changes and used the opportunity for some pre alpha code cleanup. I would like to restart the vote, to get the Alpha finally out. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2528) BeanValidator validation groups are overwritten with PSS
[
https://issues.apache.org/jira/browse/MYFACES-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12831939#action_12831939
]
Michael Kurz commented on MYFACES-2528:
---
Filed issue 1543 on Mojarra for this:
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1543
I think Ed is already aware of the overall problem as he commented on issue
1500 (disabled attribute):
https://javaserverfaces.dev.java.net/issues/show_bug.cgi?id=1500
BeanValidator validation groups are overwritten with PSS
Key: MYFACES-2528
URL: https://issues.apache.org/jira/browse/MYFACES-2528
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta
Reporter: Michael Kurz
Attachments: MYFACES-2528.patch
Setting the validation groups of a bean validator like f:validateBean
validationGroups=#{bean.groups}/ is not always working correctly with PSS.
Property bean.groups returns null or the class name of a validation group in
my example based on the value of a boolean checkbox:
h:selectBooleanCheckbox value=#{bean.prop1}
valueChangeListener=#{bean.prop1Changed}
immediate=true onclick=this.form.submit()/
h:inputText value=#{bean.prop2} rendered=#{bean.prop1}
f:validateBean validationGroups=#{bean.groups}/
/h:inputText
If I check the boolean checkbox the form is submitted and rendered again with
the additional input field. The problem now is that the validation groups are
set correctly on building the view during the second traversal of the
lifecycle before restoring the state. But on restoring the validator this
value is overwritten with the old value from the state and my validation
group is gone again.
As the BeanValidator is a PartialStateHolder this can be avoided by only
saving and restoring the state if the initial state was not marked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Fwd: [1539-ProjectStageSystemProperty] PROPOSAL
FYI -- Forwarded message -- From: Ed Burns ed.bu...@sun.com Date: Mon, Feb 8, 2010 at 5:55 PM Subject: [1539-ProjectStageSystemProperty] PROPOSAL To: d...@javaserverfaces.dev.java.net PROPOSAL This will *not* go in the spec, but I propose that existing JSF implementation coordinate and implement the following behavior. We introduce a System Property faces.PROJECT_STAGE Rationale for using this name: the context-param for this property is javax.faces.PROJECT_STAGE. I chose not to use the javax. prefix because doing so would be in poor taste. The javax. prefix is intended for things in the specification proper. The valid values of this property are exactly as specified in section 11.1.3. If the System Property is not one of the valid values, the other sources for a value for this property are consulted. The implementation will interpret this property as an override for all other ways of setting the Application.getProjectStage() property. In addition to the preceding proposal, the implementation will print out a very prominent log message such as: *** WARNING: JavaServer Faces is running in DEVELOPMENT mode. *** *** ^^^ *** *** Do NOT deploy to your live server(s) without changing this. *** *** See Application#getProjectStage() for more information. *** Matthias Wessendorf, can you ensure that MyFaces implements it this way? Ed -- | ed.bu...@sun.com | office: 408 884 9519 OR x31640 | homepage: | http://ridingthecrest.com/ - To unsubscribe, e-mail: dev-unsubscr...@javaserverfaces.dev.java.net For additional commands, e-mail: dev-h...@javaserverfaces.dev.java.net -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2528) BeanValidator validation groups are overwritten with PSS
[
https://issues.apache.org/jira/browse/MYFACES-2528?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12831941#action_12831941
]
Jakob Korherr commented on MYFACES-2528:
Thanks Michael. I am very curious about their solution!
BeanValidator validation groups are overwritten with PSS
Key: MYFACES-2528
URL: https://issues.apache.org/jira/browse/MYFACES-2528
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta
Reporter: Michael Kurz
Attachments: MYFACES-2528.patch
Setting the validation groups of a bean validator like f:validateBean
validationGroups=#{bean.groups}/ is not always working correctly with PSS.
Property bean.groups returns null or the class name of a validation group in
my example based on the value of a boolean checkbox:
h:selectBooleanCheckbox value=#{bean.prop1}
valueChangeListener=#{bean.prop1Changed}
immediate=true onclick=this.form.submit()/
h:inputText value=#{bean.prop2} rendered=#{bean.prop1}
f:validateBean validationGroups=#{bean.groups}/
/h:inputText
If I check the boolean checkbox the form is submitted and rendered again with
the additional input field. The problem now is that the validation groups are
set correctly on building the view during the second traversal of the
lifecycle before restoring the state. But on restoring the validator this
value is overwritten with the old value from the state and my validation
group is gone again.
As the BeanValidator is a PartialStateHolder this can be avoided by only
saving and restoring the state if the initial state was not marked.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2544) UIViewRoot skips uncorrectly encodeBegin
[
https://issues.apache.org/jira/browse/MYFACES-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jakob Korherr updated MYFACES-2544:
---
Resolution: Fixed
Fix Version/s: 2.0.0-beta-2
Assignee: Jakob Korherr
Status: Resolved (was: Patch Available)
This is very interesting. Until now the if part in encodeBegin was never
executed, because facesContext.getRenderResponse() is always true at this
point. So maybe there are some unwanted side effects from the patch. Because of
that I added a FIXME in the code.
Martin, maybe you could check if this is a problem with the spec. I noticed
that the if path is not that different from the else path. The only difference
is that a PreRenderComponentEvent is published and I don't know if this is ok.
Thanks!
UIViewRoot skips uncorrectly encodeBegin
Key: MYFACES-2544
URL: https://issues.apache.org/jira/browse/MYFACES-2544
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
Fix For: 2.0.0-beta-2
Attachments: MYFACES-2544.patch
javax.faces.component.UIViewRoot.encodeBegin(FacesContext) contains:
if (!skipPhase) {
super.encodeBegin(context);
}
but skipPhase = context.getRenderResponse() || context.getResponseComplete()
- it
makes sense for all phases except render response phase itself. That condition
probably should be:
if (!context.getResponseComplete()) {
super.encodeBegin(context);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2536) converterId and validatorId should not be required
[ https://issues.apache.org/jira/browse/MYFACES-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12831947#action_12831947 ] Jakob Korherr commented on MYFACES-2536: Martin, can you ensure that the code which works with validatorId or converterId checks if they are null? We don't want ugly NullPointerExceptions. Please check that and then I'll commit the patch. converterId and validatorId should not be required -- Key: MYFACES-2536 URL: https://issues.apache.org/jira/browse/MYFACES-2536 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: myfaces core trunk Reporter: Martin Koci Priority: Trivial Attachments: MYFACES-2536.patch With JSF 2.0 attributes converterId resp. validatorId (tags f:converter resp. f:validator) aren't required. See: https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/facelets/f/converter.html https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/facelets/f/validator.html -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (MYFACES-2545) ProjectStage can be set via System Property and ProjectStage!=Production should create a log entry
ProjectStage can be set via System Property and ProjectStage!=Production should create a log entry -- Key: MYFACES-2545 URL: https://issues.apache.org/jira/browse/MYFACES-2545 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Jakob Korherr Assignee: Jakob Korherr Copied from the mail from Ed Burns: PROPOSAL This will *not* go in the spec, but I propose that existing JSF implementation coordinate and implement the following behavior. We introduce a System Property faces.PROJECT_STAGE Rationale for using this name: the context-param for this property is javax.faces.PROJECT_STAGE. I chose not to use the javax. prefix because doing so would be in poor taste. The javax. prefix is intended for things in the specification proper. The valid values of this property are exactly as specified in section 11.1.3. If the System Property is not one of the valid values, the other sources for a value for this property are consulted. The implementation will interpret this property as an override for all other ways of setting the Application.getProjectStage() property. In addition to the preceding proposal, the implementation will print out a very prominent log message such as: *** WARNING: JavaServer Faces is running in DEVELOPMENT mode.*** *** ^^^ *** *** Do NOT deploy to your live server(s) without changing this. *** *** See Application#getProjectStage() for more information. *** -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
AW: Fwd: [1539-ProjectStageSystemProperty] PROPOSAL
txs also fixed in CODI [1] LieGrue, strub [1] http://github.com/struberg/myfaces-ext-cdi/ --- Matthias Wessendorf mat...@apache.org schrieb am Mi, 10.2.2010: Von: Matthias Wessendorf mat...@apache.org Betreff: Fwd: [1539-ProjectStageSystemProperty] PROPOSAL An: MyFaces Development dev@myfaces.apache.org Datum: Mittwoch, 10. Februar 2010, 11:59 FYI -- Forwarded message -- From: Ed Burns ed.bu...@sun.com Date: Mon, Feb 8, 2010 at 5:55 PM Subject: [1539-ProjectStageSystemProperty] PROPOSAL To: d...@javaserverfaces.dev.java.net PROPOSAL This will *not* go in the spec, but I propose that existing JSF implementation coordinate and implement the following behavior. We introduce a System Property faces.PROJECT_STAGE Rationale for using this name: the context-param for this property is javax.faces.PROJECT_STAGE. I chose not to use the javax. prefix because doing so would be in poor taste. The javax. prefix is intended for things in the specification proper. The valid values of this property are exactly as specified in section 11.1.3. If the System Property is not one of the valid values, the other sources for a value for this property are consulted. The implementation will interpret this property as an override for all other ways of setting the Application.getProjectStage() property. In addition to the preceding proposal, the implementation will print out a very prominent log message such as: *** WARNING: JavaServer Faces is running in DEVELOPMENT mode. *** *** ^^^ *** *** Do NOT deploy to your live server(s) without changing this. *** *** See Application#getProjectStage() for more information. *** Matthias Wessendorf, can you ensure that MyFaces implements it this way? Ed -- | ed.bu...@sun.com | office: 408 884 9519 OR x31640 | homepage: | http://ridingthecrest.com/ - To unsubscribe, e-mail: dev-unsubscr...@javaserverfaces.dev.java.net For additional commands, e-mail: dev-h...@javaserverfaces.dev.java.net -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com
[jira] Commented: (MYFACES-2544) UIViewRoot skips uncorrectly encodeBegin
[
https://issues.apache.org/jira/browse/MYFACES-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12831966#action_12831966
]
Martin Koci commented on MYFACES-2544:
--
This is probably bug in spec.
https://javaserverfaces.dev.java.net/nonav/docs/2.0/javadocs/javax/faces/component/UIViewRoot.html
says: Upon return from the listener, call FacesContext.getResponseComplete()
and FacesContext.getRenderResponse(). If either return true set the internal
state flag to true. ... Execute any processing for this phase if the internal
state flag was not set. But this nonsence for render response phase, because
FacesContext.renderResponse() = Signal the JavaServer faces implementation
that, as soon as the current phase of the request processing lifecycle has been
completed, control should be passed to the emRender Response/em phase,
bypassing any phases that have not been executed yet.
Delivering PreRenderComponentEvent is ok, because spec says:
encodeBegin() must publish a PreRenderComponentEvent or
PreRenderComponentEvent indicates that the source component is about to be
rendered. UIViewRoot is UIComponent too and there is no reason to act
differently (although PreRenderViewEvent and PreRenderComponentEvent attached
to UIViewRoot have same meaning).
UIViewRoot skips uncorrectly encodeBegin
Key: MYFACES-2544
URL: https://issues.apache.org/jira/browse/MYFACES-2544
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
Fix For: 2.0.0-beta-2
Attachments: MYFACES-2544.patch
javax.faces.component.UIViewRoot.encodeBegin(FacesContext) contains:
if (!skipPhase) {
super.encodeBegin(context);
}
but skipPhase = context.getRenderResponse() || context.getResponseComplete()
- it
makes sense for all phases except render response phase itself. That condition
probably should be:
if (!context.getResponseComplete()) {
super.encodeBegin(context);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2492) Update and create Mock classes in myfaces-test20
[ https://issues.apache.org/jira/browse/MYFACES-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12831968#action_12831968 ] Jakob Korherr commented on MYFACES-2492: So, I finally made it through your patch and I ran all related tests for the test module (I also ran all myfaces api, impl and shared tests with your new mock classes locally). There were just some few things I had to change/add: - the document root in MockResourceTestCase had to be changed in order to run the test successfully - the license information was missing in testfile.js - You used your own _messages instance variable in MockFacesContext20 for the getMessageList() methods, but you forgot that the messages Map is internally used in MockFacesContext for some more methods (I noticed that because some tests failed when I tried to build myfaces-api). So I made the messages instance variable in MockFacesContext protected, removed your addMessage method and changed the getMessageList() methods accordingly. Update and create Mock classes in myfaces-test20 Key: MYFACES-2492 URL: https://issues.apache.org/jira/browse/MYFACES-2492 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Reporter: Ingo Hofmann Attachments: extended_mock_classes1.patch Update existing Mock classes in myfaces-test20 (MyFaces test framework) to JSF 2.0 API and write Mock classes for new 2.0 classes from core project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2492) Update and create Mock classes in myfaces-test20
[ https://issues.apache.org/jira/browse/MYFACES-2492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-2492. Resolution: Fixed Assignee: Jakob Korherr Update and create Mock classes in myfaces-test20 Key: MYFACES-2492 URL: https://issues.apache.org/jira/browse/MYFACES-2492 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Reporter: Ingo Hofmann Assignee: Jakob Korherr Attachments: extended_mock_classes1.patch Update existing Mock classes in myfaces-test20 (MyFaces test framework) to JSF 2.0 API and write Mock classes for new 2.0 classes from core project. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [REVOTE] Ext-Scripting Alpha1
+1 Regards, Jan-Kees 2010/2/10 Jakob Korherr jakob.korh...@gmail.com: +1 Regards, Jakob 2010/2/10 Matthias Wessendorf mat...@apache.org +1 On Tue, Feb 9, 2010 at 11:46 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +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/2/9 Werner Punz werner.p...@gmail.com Hello, as some may remember I had to pull the vote of ext-scripting Alpha 1 due to a missing parent pom in the projects main pom. Nevertheless I have done all the changes and used the opportunity for some pre alpha code cleanup. I would like to restart the vote, to get the Alpha finally out. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: Fwd: [1539-ProjectStageSystemProperty] PROPOSAL
cool! On Wed, Feb 10, 2010 at 1:15 PM, Mark Struberg strub...@yahoo.de wrote: txs also fixed in CODI [1] LieGrue, strub [1] http://github.com/struberg/myfaces-ext-cdi/ --- Matthias Wessendorf mat...@apache.org schrieb am Mi, 10.2.2010: Von: Matthias Wessendorf mat...@apache.org Betreff: Fwd: [1539-ProjectStageSystemProperty] PROPOSAL An: MyFaces Development dev@myfaces.apache.org Datum: Mittwoch, 10. Februar 2010, 11:59 FYI -- Forwarded message -- From: Ed Burns ed.bu...@sun.com Date: Mon, Feb 8, 2010 at 5:55 PM Subject: [1539-ProjectStageSystemProperty] PROPOSAL To: d...@javaserverfaces.dev.java.net PROPOSAL This will *not* go in the spec, but I propose that existing JSF implementation coordinate and implement the following behavior. We introduce a System Property faces.PROJECT_STAGE Rationale for using this name: the context-param for this property is javax.faces.PROJECT_STAGE. I chose not to use the javax. prefix because doing so would be in poor taste. The javax. prefix is intended for things in the specification proper. The valid values of this property are exactly as specified in section 11.1.3. If the System Property is not one of the valid values, the other sources for a value for this property are consulted. The implementation will interpret this property as an override for all other ways of setting the Application.getProjectStage() property. In addition to the preceding proposal, the implementation will print out a very prominent log message such as: *** WARNING: JavaServer Faces is running in DEVELOPMENT mode. *** *** ^^^ *** *** Do NOT deploy to your live server(s) without changing this. *** *** See Application#getProjectStage() for more information. *** Matthias Wessendorf, can you ensure that MyFaces implements it this way? Ed -- | ed.bu...@sun.com | office: 408 884 9519 OR x31640 | homepage: | http://ridingthecrest.com/ - To unsubscribe, e-mail: dev-unsubscr...@javaserverfaces.dev.java.net For additional commands, e-mail: dev-h...@javaserverfaces.dev.java.net -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf __ Do You Yahoo!? Sie sind Spam leid? Yahoo! Mail verfügt über einen herausragenden Schutz gegen Massenmails. http://mail.yahoo.com -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (MYFACES-2536) converterId and validatorId should not be required
[
https://issues.apache.org/jira/browse/MYFACES-2536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12831994#action_12831994
]
Martin Koci commented on MYFACES-2536:
--
Yes, ugly exceptions happen with f:converter binding=#{aNonExistentBean} /:
1) myfaces: NPE in ConvertDelegateHandler
2) mojarra: javax.faces.view.facelets.TagException: /test.xhtml f:converter
Default behavior invoked of requiring a converter-id passed in the constructor,
must override ConvertHandler(ConverterConfig)
Is seems that this odd behaviour comes from old facelts codebase. I try to find
out how those converterId/binding attributes should cooperate.
converterId and validatorId should not be required
--
Key: MYFACES-2536
URL: https://issues.apache.org/jira/browse/MYFACES-2536
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces core trunk
Reporter: Martin Koci
Priority: Trivial
Attachments: MYFACES-2536.patch
With JSF 2.0 attributes converterId resp. validatorId (tags f:converter resp.
f:validator) aren't required. See:
https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/facelets/f/converter.html
https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/facelets/f/validator.html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[core] converterId/validatorId and binding
Hi,
there is probably a unclarity regarding cooperation of
converterId/validatorId and binding attributes from f:converter and
f:validator facelets tags.
https://javaserverfaces.dev.java.net/nonav/docs/2.0/pdldocs/facelets/f/converter.html
says that converterId is not required, same for validatorId.
I didn't find what should happen if user does not specify converterId
and binding leads to null object. Simple test page
h:inputText value=#{testBean.value}
f:converter binding=#{aNonExistentBean} /
/h:inputText
confirms that this is mystery for mojarra developers too - it throws
javax.faces.view.facelets.TagException: /test.xhtml @10,54 f:converter
Default behavior invoked of requiring a converter-id passed in the
constructor, must override ConvertHandler(ConverterConfig)
Specification does not speak about facelets tag directly but 9.4.5
f:converter (for JSP) contains this text:
The createConverter() method must:
If binding is non-null, call binding.getValue() to obtain a reference to
the Converter instance. If there is no exception thrown, and
binding.getValue() returned a non-null object that implements
javax.faces.convert.Converter, register it by calling setConverter(). If
there was an exception thrown, rethrow the exception as a JspException.
Use the converterId attribute if the converter instance could not be
created from the binding attribute. If the converterId attribute is set,
call the createConverter() method of the Application instance for this
application, passing converter id specified by their converterId
attribute. If the binding attribute was also set, store the converter
instance by calling binding.setValue(). Register the converter instance
by calling setConverter(). If there was an exception thrown, rethrow the
exception as a JspException.
Please notice the sentence If the converterId attribute is set. I
suggest to follow this behavior in ConvertDelegateHandler and log a
warning or add a FacesMessage in develelopment mode if user uses
f:converter tag without converterId and with null binding (same for
f:validator).
Regards,
Martin Kočí
Related issue: https://issues.apache.org/jira/browse/MYFACES-2536
[Trinidad] Version 2.x becoming trunk ?
Hey, as the most work recently goes into the JSF2 version for Trinidad, I'd like to make that trunk. The current trunk (1.2.x) will become a branch; Sure releases for that (and fixes) are coming in. Of course :-) IMO this makes sense; Not only Trinidad has the current focus on jsf2, so does MyFaces Core as well -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[Trinidad2] new branch...
Hello, there is a new branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/matzewTrinidad2002/ yes... it will be renamed ... / relocated; soon (see my other email) Also, I am about to generate a new (alpha/beta) release for the 2.0.x offerings (will contain changes BEFORE this new branch has been created) -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Resolved: (MYFACES-2545) ProjectStage can be set via System Property and ProjectStage!=Production should create a log entry
[ https://issues.apache.org/jira/browse/MYFACES-2545?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jakob Korherr resolved MYFACES-2545. Resolution: Fixed Fix Version/s: 2.0.0-beta-2 ProjectStage can be set via System Property and ProjectStage!=Production should create a log entry -- Key: MYFACES-2545 URL: https://issues.apache.org/jira/browse/MYFACES-2545 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.0-beta-2 Reporter: Jakob Korherr Assignee: Jakob Korherr Fix For: 2.0.0-beta-2 Copied from the mail from Ed Burns: PROPOSAL This will *not* go in the spec, but I propose that existing JSF implementation coordinate and implement the following behavior. We introduce a System Property faces.PROJECT_STAGE Rationale for using this name: the context-param for this property is javax.faces.PROJECT_STAGE. I chose not to use the javax. prefix because doing so would be in poor taste. The javax. prefix is intended for things in the specification proper. The valid values of this property are exactly as specified in section 11.1.3. If the System Property is not one of the valid values, the other sources for a value for this property are consulted. The implementation will interpret this property as an override for all other ways of setting the Application.getProjectStage() property. In addition to the preceding proposal, the implementation will print out a very prominent log message such as: *** WARNING: JavaServer Faces is running in DEVELOPMENT mode.*** *** ^^^ *** *** Do NOT deploy to your live server(s) without changing this. *** *** See Application#getProjectStage() for more information. *** -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1107) tr:table - scrolling of content
[ https://issues.apache.org/jira/browse/TRINIDAD-1107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832068#action_12832068 ] Cedric Durmont commented on TRINIDAD-1107: -- Well, I'm glad you asked ! I made it work on tr:treeTable, the javascript code needed a bit of tweaking. There is still a problem with column widths if the treetable is larger than the screen, but I think it's an acceptable limitation ATM. I'm readying a new version of the patch, I'll publish it tomorrow. Regards, Cedric Durmont tr:table - scrolling of content --- Key: TRINIDAD-1107 URL: https://issues.apache.org/jira/browse/TRINIDAD-1107 Project: MyFaces Trinidad Issue Type: Improvement Components: Components Reporter: Gerhard Petracek Attachments: patch.txt, scrolltable-patch2_1.txt if a table is too long and it comes to page scrollbars, you cannot see the header all the time (e.g. after scrolling to the bottom of the table). so we need a scrollbar for the table body. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [REVOTE] Ext-Scripting Alpha1
+1 build integration was successful Alex 2010/2/10 Jan-Kees van Andel jankeesvanan...@gmail.com +1 Regards, Jan-Kees 2010/2/10 Jakob Korherr jakob.korh...@gmail.com: +1 Regards, Jakob 2010/2/10 Matthias Wessendorf mat...@apache.org +1 On Tue, Feb 9, 2010 at 11:46 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +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/2/9 Werner Punz werner.p...@gmail.com Hello, as some may remember I had to pull the vote of ext-scripting Alpha 1 due to a missing parent pom in the projects main pom. Nevertheless I have done all the changes and used the opportunity for some pre alpha code cleanup. I would like to restart the vote, to get the Alpha finally out. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Mit freundlichen Grüßen / Kind regards Alexander Bell J4Fry OpenSource Community Internet: http://www.j4fry.org E-Mail: alexander.b...@j4fry.org Webprofil: http://www.j4fry.org/alexanderbell.shtml
Re: [REVOTE] Ext-Scripting Alpha1
+1 On Wed, Feb 10, 2010 at 9:23 AM, Alexander Bell alexander.b...@j4fry.orgwrote: +1 build integration was successful Alex 2010/2/10 Jan-Kees van Andel jankeesvanan...@gmail.com +1 Regards, Jan-Kees 2010/2/10 Jakob Korherr jakob.korh...@gmail.com: +1 Regards, Jakob 2010/2/10 Matthias Wessendorf mat...@apache.org +1 On Tue, Feb 9, 2010 at 11:46 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +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/2/9 Werner Punz werner.p...@gmail.com Hello, as some may remember I had to pull the vote of ext-scripting Alpha 1 due to a missing parent pom in the projects main pom. Nevertheless I have done all the changes and used the opportunity for some pre alpha code cleanup. I would like to restart the vote, to get the Alpha finally out. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Mit freundlichen Grüßen / Kind regards Alexander Bell J4Fry OpenSource Community Internet: http://www.j4fry.org E-Mail: alexander.b...@j4fry.org Webprofil: http://www.j4fry.org/alexanderbell.shtml -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
[jira] Created: (TRINIDAD-1719) ajax xml response is not valid in some cases
ajax xml response is not valid in some cases
Key: TRINIDAD-1719
URL: https://issues.apache.org/jira/browse/TRINIDAD-1719
Project: MyFaces Trinidad
Issue Type: Bug
Affects Versions: 1.2.13-core
Reporter: Xavier Brénuchon
Hello,
There is a probleme with ajax calls in trinidad 1.2.13 (not with 1.2.9).
For exemple : I want use a table with a sortable colomun. When I click on the
column header, there is an ajax call.
But the xml response is not valid and the page made a repost.
The xml response is not valid because in my page (not in the table), I have,
for exemple, a 'h:outputText' with accented character as value.
Indeed, this 'h:outputText' has written its value in the ajax xml output. (not
in a 'fragment', not in a CDATA section).
There is 2 problems :
First, this 'h:outputText' should not write to output, because it is not
affected by the partial render (this 'h:outputText' is not in the table). (This
first problem was present in trinidad 1.2.9)
Second, even if this accented value is written is the output stream and not in
a cdata section, accented characters must be compatible with xml (#x hexa; for
exemple) (This problem is new in trinidad 1.2.13)
I looked at source code and I found where are bugs.
First the h:outputText is not ignored because a method must be uncommented :
PPRResponseWriter.java, ligne 219 :
/* Needed in JSF 1.2
@Override
public void writeText(Object text,
UIComponent component,
String propertyName) throws IOException
{
if (_isInsideTarget() (text != null))
super.writeText(text, component, propertyName);
}
*/
This method must be uncomment, because for h:outputText, there is no test
_isInsideTarget.
Second, In DispatchResponseConf.java, ligne 75, the content type is searched in
RequestStateMap (a new class from 1.2.13) :
return (String)
RequestStateMap.getInstance(context.getExternalContext()).get(__CONTENT_TYPE_KEY);
The problem is that the content type is not inserted in RequestStateMap, but
always by the old way (1.2.9) ie request.setAttribut.
So trinidad don't finds content type (here :'text/xml') and uses the default
HtmlResponseWriter and not XhtmlResponseWriter (see CoreRenderKit.java line 592)
So we must correct both where the content type is written :
DispatchRenderResponse.java, ligne 45 :
_request.setAttribute(DispatchResponseConfiguratorImpl.__CONTENT_TYPE_KEY,
ct.getContentType());
and DispatchServletResponse.java, ligne 49 :
_request.setAttribute(DispatchResponseConfiguratorImpl.__CONTENT_TYPE_KEY,
ct.getContentType());
Replace these two line with :
RequestStateMap.getInstance(_request).put(__CONTENT_TYPE_KEY,
ct.getContentType());
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[Trinidad 2] Permission to change the API of CoreRenderer by adding a new final override and a new sub-class hook method for client behavior decoding (TRINIDAD-1715)
I need to add the ClientBehavior decoding logic to Trinidad as I
forgot to do it earlier
(https://issues.apache.org/jira/browse/TRINIDAD-1715). I would like to
put the logic in the renderer, not in UIXComponentBase as it makes
much more sense to have it there. I need to make sure the method is
called so that people don't subclass the method and forget to call the
parent method. I would like to make the following additions to
CoreRenderer:
@Override
public final void decode(
FacesContext facesContext,
UIComponent component)
{
FacesBean facesBean = getFacesBean(component);
String clientId = null;
if (facesBean != null)
{
clientId = decodeBehaviors(facesContext, component, facesBean);
}
decode(facesContext, component, facesBean, clientId);
}
/**
* Hook for sub-classes to perform their own decode logic
* @param facesContext the faces context
* @param component the component to decode
* @param facesBean the faces bean for the component
* @param clientId the client ID if it has been retrieved already
* during decoding, otherwise it will be null. Passed in for performance
* reasons, so that if it has already been retrieved it will not need to be
* retrieved again
*/
protected void decode(
FacesContext facesContext,
UIComponent component,
FacesBeanfacesBean,
String clientId)
{
// No-op
}
Even though this seems the right thing to do, I know that any
renderers that sub-class CoreRenderer or XhtmlRenderer will need to be
updated. I will obviously convert the Trinidad renderers. Do you all
concur that this is the right thing to do, an also if you are okay
with the API of the new contract?
Thank you,
Andrew
Re: [Trinidad2] new branch...
Hi Matthias, What is the new branch for? Are you saying that will be trunk? Why not just make the 2.0.x branch trunk? Thanks, Gab Matthias Wessendorf wrote: Hello, there is a new branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/matzewTrinidad2002/ yes... it will be renamed ... / relocated; soon (see my other email) Also, I am about to generate a new (alpha/beta) release for the 2.0.x offerings (will contain changes BEFORE this new branch has been created) -Matthias
Re: [Trinidad] Version 2.x becoming trunk ?
+1, I know there will be push back, but I would like to see MyFaces move forward and ensure that the latest technologies is treated as a first-class citizen instead of the other way around. It would also lessen the work for those of us developers so that bugs can still go to both but enhancements can be only put into 2.0 unless specifically desired for earlier branches. On Wed, Feb 10, 2010 at 8:56 AM, Matthias Wessendorf mat...@apache.org wrote: Hey, as the most work recently goes into the JSF2 version for Trinidad, I'd like to make that trunk. The current trunk (1.2.x) will become a branch; Sure releases for that (and fixes) are coming in. Of course :-) IMO this makes sense; Not only Trinidad has the current focus on jsf2, so does MyFaces Core as well -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] Permission to change the API of CoreRenderer by adding a new final override and a new sub-class hook method for client behavior decoding (TRINIDAD-1715)
I would prefer that code fail in an obvious way--doesn't compile or link
rather than have things not quite work right. So, if the choice is
between CoreRenderer subclasses that overrode decode need to realize
that they need change to call super and CoreRenderer subclasses fail to
compile or link because decode is now final and they then read the new
javadoc for decode that tells them to override the protected version,
I'll go with the more obvious failure.
+1
-- Blake Sullivan
Andrew Robinson said the following On 2/10/2010 9:39 AM PT:
I need to add the ClientBehavior decoding logic to Trinidad as I
forgot to do it earlier
(https://issues.apache.org/jira/browse/TRINIDAD-1715). I would like to
put the logic in the renderer, not in UIXComponentBase as it makes
much more sense to have it there. I need to make sure the method is
called so that people don't subclass the method and forget to call the
parent method. I would like to make the following additions to
CoreRenderer:
@Override
public final void decode(
FacesContext facesContext,
UIComponent component)
{
FacesBean facesBean = getFacesBean(component);
String clientId = null;
if (facesBean != null)
{
clientId = decodeBehaviors(facesContext, component, facesBean);
}
decode(facesContext, component, facesBean, clientId);
}
/**
* Hook for sub-classes to perform their own decode logic
* @param facesContext the faces context
* @param component the component to decode
* @param facesBean the faces bean for the component
* @param clientId the client ID if it has been retrieved already
* during decoding, otherwise it will be null. Passed in for performance
* reasons, so that if it has already been retrieved it will not need to be
* retrieved again
*/
protected void decode(
FacesContext facesContext,
UIComponent component,
FacesBeanfacesBean,
String clientId)
{
// No-op
}
Even though this seems the right thing to do, I know that any
renderers that sub-class CoreRenderer or XhtmlRenderer will need to be
updated. I will obviously convert the Trinidad renderers. Do you all
concur that this is the right thing to do, an also if you are okay
with the API of the new contract?
Thank you,
Andrew
Re: [Trinidad2] new branch...
On Wed, Feb 10, 2010 at 6:39 PM, Gabrielle Crawford gabrielle.crawf...@oracle.com wrote: Hi Matthias, What is the new branch for? contains stuff that has been fixed on trunk. Are you saying that will be trunk? maybe soon; see the other email Why not just make the 2.0.x branch trunk? see other email; I want to give a heads-up instead of swapping out trunk... -Matthias PS: this will be renamed... (after that is done, another email is around ehre) Thanks, Gab Matthias Wessendorf wrote: Hello, there is a new branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/matzewTrinidad2002/ yes... it will be renamed ... / relocated; soon (see my other email) Also, I am about to generate a new (alpha/beta) release for the 2.0.x offerings (will contain changes BEFORE this new branch has been created) -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Reopened: (MYFACES-2544) UIViewRoot skips uncorrectly encodeBegin
[
https://issues.apache.org/jira/browse/MYFACES-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Leonardo Uribe reopened MYFACES-2544:
-
I'll revert the previous patch. The use case you have to consider is when there
is an error on a beforePhase listener. If there is,
context.getResponseComplete() could return true, inclusive on render response
phase. Long time ago, I review MYFACES-2374 and It is known ri does not do
this, and this one cause an error on a compatibility test, but in this case the
previous behavior is the expected one (the javadoc says so and this one comes
from jsf 1.2).
Please note maybe there is a misundersanding about what
FacesContext.renderResponse() and FacesContext.getRenderResponse() do. The
meaning of this constant is allow jsf to skip phases when an error occur. For
example, if a validator throws a RuntimeException, ProcessUpdates and
InvokeApplication phases should not be executed, so they will be skipped and
RenderResponse phase should occur. Why UIViewRoot.encodeBegin skip render the
view? because in jsf 1.2 this is considered an error and encodeBegin should not
happen, instead, the error page is published.
Now, PreRenderViewEvent could be used to change the view to be rendered. Just
take a look at org.apache.myfaces.lifecycle.RenderResponseExecutor. Its meaning
and behavior are different to PreRenderComponentEvent. Maybe the real bug is
UIViewRoot does not call
context.getApplication().publishEvent(context, PreRenderComponentEvent.class,
UIComponent.class, this);
before call encodeBegin(), like UIComponentBase.encodeBegin() does. Maybe this
one was ignored, because usually UIViewRoot does not render anything.
Note to solve this issue we have also to check if the new behavior introduced
with ExceptionHandler api is compatible with the original jsf 1.2 algorithm.
Jakob, could you take a look at this one again from this point of view?
UIViewRoot skips uncorrectly encodeBegin
Key: MYFACES-2544
URL: https://issues.apache.org/jira/browse/MYFACES-2544
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
Fix For: 2.0.0-beta-2
Attachments: MYFACES-2544.patch
javax.faces.component.UIViewRoot.encodeBegin(FacesContext) contains:
if (!skipPhase) {
super.encodeBegin(context);
}
but skipPhase = context.getRenderResponse() || context.getResponseComplete()
- it
makes sense for all phases except render response phase itself. That condition
probably should be:
if (!context.getResponseComplete()) {
super.encodeBegin(context);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[Trinidad] version 2.0 branches,...... Please read :-)
Hello the OLD trindiad2 branch has been reloacted, to: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/OLD_trinidad-2.0.x/ the NEW branch (which contains the latest greatest work from trunk) is now named 2.0.x: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/trinidad-2.0.x/ If you have questions, let me know! -Matthias On Wed, Feb 10, 2010 at 6:54 PM, Matthias Wessendorf mat...@apache.org wrote: On Wed, Feb 10, 2010 at 6:39 PM, Gabrielle Crawford gabrielle.crawf...@oracle.com wrote: Hi Matthias, What is the new branch for? contains stuff that has been fixed on trunk. Are you saying that will be trunk? maybe soon; see the other email Why not just make the 2.0.x branch trunk? see other email; I want to give a heads-up instead of swapping out trunk... -Matthias PS: this will be renamed... (after that is done, another email is around ehre) Thanks, Gab Matthias Wessendorf wrote: Hello, there is a new branch: https://svn.apache.org/repos/asf/myfaces/trinidad/branches/matzewTrinidad2002/ yes... it will be renamed ... / relocated; soon (see my other email) Also, I am about to generate a new (alpha/beta) release for the 2.0.x offerings (will contain changes BEFORE this new branch has been created) -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] Version 2.x becoming trunk ?
+1 Matthias Wessendorf wrote: Hey, as the most work recently goes into the JSF2 version for Trinidad, I'd like to make that trunk. The current trunk (1.2.x) will become a branch; Sure releases for that (and fixes) are coming in. Of course :-) IMO this makes sense; Not only Trinidad has the current focus on jsf2, so does MyFaces Core as well -Matthias
Re: [Trinidad] Version 2.x becoming trunk ?
+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/2/10 Matthias Wessendorf mat...@apache.org Hey, as the most work recently goes into the JSF2 version for Trinidad, I'd like to make that trunk. The current trunk (1.2.x) will become a branch; Sure releases for that (and fixes) are coming in. Of course :-) IMO this makes sense; Not only Trinidad has the current focus on jsf2, so does MyFaces Core as well -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [core] UIComponentBase.getId() can return null
We need to fol,low up with the JSF spec because: 1) The RI does not implement the behavior you would expect from the JavaDoc because calling getClientId() on a component with a null id causes the id of the component to be set as a side-effect. The expected result would be that the id of the component would not be set in this case 2) The behavior implied by the Javadoc (and the one I believe that MyFaces does and Trinidad tried to implement) is not useful. I see no reason why it is preferable that the clientId of a not agree with the component's id just so that the component's id can sometimes be null. The only advantage of supporting a null id is lower memory usage for dynamically created components. The other insidious side-effect of getId() being allowed to return null is that this caused problems with the JSF RI not having stable clientIds. This led the RI to impement clientId caching. The RI's implementation of clientId caching: 1) Requires special behavior on components that want to work with components that inherit from the RI's UIComponentBase 2) The RI doesn't correctly clear its caches in cases when it should (the id of a NamingContainer changes, thus affecting the clientIds of its descendants or a component is moved between NamingContainers, affecting both its and its descendants clientIds) So, for JSF 2.1 we should also address clientId caching and at the very least have real apis for clearing the caches and have the spec actually define the required behavior. -- Blake Sullivan Matthias Wessendorf said the following On 2/9/2010 12:54 AM PT: Hi, Blake committed an interesting patch to Trinidad: http://bit.ly/dtghOs I see that MyFaces can actually return NULL on getId(), however the MyFaces implementation goes ahead and creates the ID if getClientId(facesCtx) is called AND! the getId() returns null. So, why not directly ensuring that getId() can't return null ? Checking the JavaDoc of getClientId(FacesCtx), I see that MyFaces is doing what is required. But does that really make sense? -Matthias
Re: [Trinidad] Version 2.x becoming trunk ?
+1 regards, Leonardo Uribe 2010/2/10 Gerhard Petracek gerhard.petra...@gmail.com +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/2/10 Matthias Wessendorf mat...@apache.org Hey, as the most work recently goes into the JSF2 version for Trinidad, I'd like to make that trunk. The current trunk (1.2.x) will become a branch; Sure releases for that (and fixes) are coming in. Of course :-) IMO this makes sense; Not only Trinidad has the current focus on jsf2, so does MyFaces Core as well -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad] Version 2.x becoming trunk ?
+1 Thanks Pavitra On 2/10/2010 7:56 AM, Matthias Wessendorf wrote: Hey, as the most work recently goes into the JSF2 version for Trinidad, I'd like to make that trunk. The current trunk (1.2.x) will become a branch; Sure releases for that (and fixes) are coming in. Of course :-) IMO this makes sense; Not only Trinidad has the current focus on jsf2, so does MyFaces Core as well -Matthias
MyFaces in OSGi
Hi all,
I'm trying to make latest MyFaces core run in OSGi environment (in
Geronimo 3.0) and I'm running into a few problems. I'm hoping to get
your input on some of these problems. Here's our setup: we deploy
myfaces-api and myfaces-impl as separate bundles and we also have a
separate bundle that is the application (effectively a war file) that
uses jsf. When running the application, Geronimo sets the context
class loader to the application classloader which delegates the calls
to the application bundle.
Now, most of the problems we are running into are due to use of the
context class loader in myfaces code to lookup resources within the
META-INF directory.
For example, IncludeHandler.java looks up
META-INF/rsc/myfaces-dev-error-include.xhtml resource or
FacesConfigurator.java looks up META-INF/standard-faces-config.xml
resource via CCL. This works great in a regular Java environment but
breaks in OSGi. One easy solution for this would be to first ask the
CCL for the resource and if none is found ask the surrounding class
class loader for that resource (assuming the resource we are looking
for lives in the same jar as the class loading it), i.e.:
URL foo = getContextClassLoader().getResource(META-INF/foo);
if (foo == null) {
foo = getClass().getClassLoader().getResource(META-INF/foo);
}
There are other more advanced work-arounds (e.g. ContextFinder in
Equinox) but I'm wondering what people think about updating the
MyFaces code to use this simple solution. Just to be clear, this only
needs to be done for a few known resources that live within the impl
or api jars and not for all resource lookups.
The ErrorPageWriter.java also looks up some resources via CCL and can
fall back to looking for META-INF/rsc/myfaces-dev-error.xml and
META-INF/rsc/myfaces-dev-debug.xml. But these resources live in the
api module for some reason. I'm not sure why but I'm hoping they can
be moved to the impl module. That way the simple solution mentioned
above would still work.
My final problem is with
AnnotationConfigurator.getMyfacesImplJarFile(). Besides the problem
with META-INF lookup using CCL and even if that method successfully
looked up that resource, it won't be able to get a JarFile out it.
Because the url returned from resource lookup in OSGi environment
can't be considered as a url to a jar file. So I think we will need a
way to override that piece of code from Geronimo somehow. Maybe even
making the getMyfacesImplJarFile() method protected would work for us
(we can return a fake JarFile that deletes calls to a bundle object).
Thanks,
Jarek
SVN issue ?
Hello, I can't commit to /myfaces/trinidad/*** SVN folder... anything going on? I don't see much here: http://monitoring.apache.org/status/ -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (TRINIDAD-1679) Tag doc to list relationship between tags
[ https://issues.apache.org/jira/browse/TRINIDAD-1679?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832178#action_12832178 ] Maria Kaval commented on TRINIDAD-1679: --- The patch was applied to 1.2.11.1 but I need it applied to 1.2.11 (which is under the tags folder, not branches folder): http://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-1.2.11 Thanks. Tag doc to list relationship between tags - Key: TRINIDAD-1679 URL: https://issues.apache.org/jira/browse/TRINIDAD-1679 Project: MyFaces Trinidad Issue Type: Improvement Components: Documentation Affects Versions: 1.2.11-plugins Reporter: Maria Kaval Priority: Minor Fix For: 1.2.12-plugins Attachments: JIRA1679patch_for_1_2_11.patch, patchJIRA1679.patch, patchJIRA1679_2.patch The tag doc should list relationships between tags. For example, if a given facet of a component can only take a component of type X, that should be listed on the tag doc page, and a link to the tag doc for component X provided.This JIRA will supported parsing out the existing fmd:allowed-child-components and fmd:required-ancestor-contracts (from the namespace http://java.sun.com/xml/ns/javaee/faces/design-time-metadata) from the component XML files and converting that into relevant tag names, then adding that information into the generated tag doc pages. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: SVN issue ?
getting: svn: Commit failed (details follow): svn: The specified baseline is not the latest baseline, so it may not be checked out. I even combine svn up and svn ci == svn up svn ci -Matthias On Wed, Feb 10, 2010 at 9:28 PM, Matthias Wessendorf mat...@apache.org wrote: Hello, I can't commit to /myfaces/trinidad/*** SVN folder... anything going on? I don't see much here: http://monitoring.apache.org/status/ -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
[jira] Commented: (TRINIDAD-1677) Tag Documentation to list default value for attributes
[ https://issues.apache.org/jira/browse/TRINIDAD-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832179#action_12832179 ] Maria Kaval commented on TRINIDAD-1677: --- The patch was applied to 1.2.11.1 but I need it applied to 1.2.11 (which is under the tags folder, not branches folder): http://svn.apache.org/repos/asf/myfaces/trinidad-maven/tags/maven-plugin-parent-1.2.11 Thanks. Tag Documentation to list default value for attributes -- Key: TRINIDAD-1677 URL: https://issues.apache.org/jira/browse/TRINIDAD-1677 Project: MyFaces Trinidad Issue Type: Improvement Components: Documentation Affects Versions: 1.2.11-plugins Reporter: Maria Kaval Assignee: Jeanne Waldman Priority: Minor Fix For: 1.2.12-plugins Attachments: JIRA1677_trunk.patch, JIRA1677_trunk2.patch, JIRA1677patch_for_1_2_11.patch Original Estimate: 24h Remaining Estimate: 24h The tag documentation today does not list the default value for a given attribute of a component. Listing the default value for an attribute will help clarify how a component works for application developers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1677) Tag Documentation to list default value for attributes
[ https://issues.apache.org/jira/browse/TRINIDAD-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832184#action_12832184 ] Matthias Weßendorf commented on TRINIDAD-1677: -- that has been released. We generally don't patch TAGs as these are final. Are you on 1.2.11 ? that means you are on an officially released version; options are taking one of the existing branches or trunk; Tag Documentation to list default value for attributes -- Key: TRINIDAD-1677 URL: https://issues.apache.org/jira/browse/TRINIDAD-1677 Project: MyFaces Trinidad Issue Type: Improvement Components: Documentation Affects Versions: 1.2.11-plugins Reporter: Maria Kaval Assignee: Jeanne Waldman Priority: Minor Fix For: 1.2.12-plugins Attachments: JIRA1677_trunk.patch, JIRA1677_trunk2.patch, JIRA1677patch_for_1_2_11.patch Original Estimate: 24h Remaining Estimate: 24h The tag documentation today does not list the default value for a given attribute of a component. Listing the default value for an attribute will help clarify how a component works for application developers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2544) UIViewRoot skips uncorrectly encodeBegin
[
https://issues.apache.org/jira/browse/MYFACES-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832185#action_12832185
]
Martin Koci commented on MYFACES-2544:
--
when there is an error on a beforePhase listener. If there is,
context.getResponseComplete() could return true, inclusive on render response
phase.
How is context.getResponseComplete() related to error handling? I don't get the
point about error in beforePhase - if there is a error in phaseListener it is
logged and/or published with exceptionHandler: 6.2.2 Backwards Compatible
ExceptionHandler and 12.3 PhaseListener
Please note maybe there is a misundersanding about what
FacesContext.renderResponse() and FacesContext.getRenderResponse() do. The
meaning of this constant is allow jsf to skip phases when an error occur.
For example, if a validator throws a RuntimeException,
ProcessUpdates and InvokeApplication phases should not be executed, so they
will be skipped and RenderResponse phase should occur.
Yes, but why exclude from executing exactly one method at particular class? Why
UIViewRoot.encodeEnd is not exluded? UIViewRoot.encodeBegin represents the
beginning of render response phase as component. It is legal for a listener
(action or valueChange) to call context FacesContext.renderResponse() but it
does not mean that there was a error - listener can simple be smart enough to
know that no other phases except for render response are needed.
Why UIViewRoot.encodeBegin skip render the view? because in jsf 1.2
this is considered an error and encodeBegin should not happen,
instead, the error page is published.
I don't think FacesContext.getRenderResponse() true = a runtime exception is
a valid expectation - skipping to render response phase is a possible response
to runtime exception, but it does not imply that render response phase is
executing as response to error.
Here is example what should work:
MyUIView extends UIViewRoot {
encodeBegin() {
super.encodeBegin()
// super notifies phase listeners, puts component to EL and publish
PreRenderComponentEvent
// rendering specific stuff here
}
}
This was not working with mojarra and isn't working with myfaces. But clearly
it can be fixed with adding
context.getApplication().publishEvent(PreRenderComponentEvent.class) and it
will work together with algorithm requested by spec.
UIViewRoot skips uncorrectly encodeBegin
Key: MYFACES-2544
URL: https://issues.apache.org/jira/browse/MYFACES-2544
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
Fix For: 2.0.0-beta-2
Attachments: MYFACES-2544.patch
javax.faces.component.UIViewRoot.encodeBegin(FacesContext) contains:
if (!skipPhase) {
super.encodeBegin(context);
}
but skipPhase = context.getRenderResponse() || context.getResponseComplete()
- it
makes sense for all phases except render response phase itself. That condition
probably should be:
if (!context.getResponseComplete()) {
super.encodeBegin(context);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: SVN issue ?
ok... svn: Commit failed (details follow): svn: Commit blocked by start-commit hook (exit code 1) with output: Write access is currently disabled. The ASF SVN repository is currently undergoing maintenance. On Wed, Feb 10, 2010 at 9:31 PM, Matthias Wessendorf mat...@apache.org wrote: getting: svn: Commit failed (details follow): svn: The specified baseline is not the latest baseline, so it may not be checked out. I even combine svn up and svn ci == svn up svn ci -Matthias On Wed, Feb 10, 2010 at 9:28 PM, Matthias Wessendorf mat...@apache.org wrote: Hello, I can't commit to /myfaces/trinidad/*** SVN folder... anything going on? I don't see much here: http://monitoring.apache.org/status/ -Matthias -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
RE: [jira] Commented: (TRINIDAD-1677) Tag Documentation to list default value for attributes
Thanks for the clarification. Yes, we are currently picking up Trinidad-maven 1.2.11 for our RCF trunk. One option would be to do a new release of the plugins now that JIRA 1677 and JIRA 1679 have been checked in. Is there a plan to make a Trinidad 1.2.12 release of the plugins? Maria -Original Message- From: Matthias Weßendorf (JIRA) [mailto:d...@myfaces.apache.org] Sent: Wednesday, February 10, 2010 12:39 PM To: Maria Kaval Subject: [jira] Commented: (TRINIDAD-1677) Tag Documentation to list default value for attributes [ https://issues.apache.org/jira/browse/TRINIDAD-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832184#action_12832184 ] Matthias Weßendorf commented on TRINIDAD-1677: -- that has been released. We generally don't patch TAGs as these are final. Are you on 1.2.11 ? that means you are on an officially released version; options are taking one of the existing branches or trunk; Tag Documentation to list default value for attributes -- Key: TRINIDAD-1677 URL: https://issues.apache.org/jira/browse/TRINIDAD-1677 Project: MyFaces Trinidad Issue Type: Improvement Components: Documentation Affects Versions: 1.2.11-plugins Reporter: Maria Kaval Assignee: Jeanne Waldman Priority: Minor Fix For: 1.2.12-plugins Attachments: JIRA1677_trunk.patch, JIRA1677_trunk2.patch, JIRA1677patch_for_1_2_11.patch Original Estimate: 24h Remaining Estimate: 24h The tag documentation today does not list the default value for a given attribute of a component. Listing the default value for an attribute will help clarify how a component works for application developers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [jira] Commented: (TRINIDAD-1677) Tag Documentation to list default value for attributes
On Wed, Feb 10, 2010 at 9:45 PM, Maria Kaval maria.ka...@oracle.com wrote: Thanks for the clarification. Yes, we are currently picking up Trinidad-maven 1.2.11 for our RCF trunk. One option would be to do a new release of the plugins now that JIRA 1677 and JIRA 1679 have been checked in. Is there a plan to make a Trinidad 1.2.12 release of the plugins? Matthias: I want to run Trinidad 2 maven plugins release 2morrow; doing that for trunk is fine as well; Almost all automated ;-) -Matthias Maria -Original Message- From: Matthias Weßendorf (JIRA) [mailto:d...@myfaces.apache.org] Sent: Wednesday, February 10, 2010 12:39 PM To: Maria Kaval Subject: [jira] Commented: (TRINIDAD-1677) Tag Documentation to list default value for attributes [ https://issues.apache.org/jira/browse/TRINIDAD-1677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832184#action_12832184 ] Matthias Weßendorf commented on TRINIDAD-1677: -- that has been released. We generally don't patch TAGs as these are final. Are you on 1.2.11 ? that means you are on an officially released version; options are taking one of the existing branches or trunk; Tag Documentation to list default value for attributes -- Key: TRINIDAD-1677 URL: https://issues.apache.org/jira/browse/TRINIDAD-1677 Project: MyFaces Trinidad Issue Type: Improvement Components: Documentation Affects Versions: 1.2.11-plugins Reporter: Maria Kaval Assignee: Jeanne Waldman Priority: Minor Fix For: 1.2.12-plugins Attachments: JIRA1677_trunk.patch, JIRA1677_trunk2.patch, JIRA1677patch_for_1_2_11.patch Original Estimate: 24h Remaining Estimate: 24h The tag documentation today does not list the default value for a given attribute of a component. Listing the default value for an attribute will help clarify how a component works for application developers. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf
Re: [Trinidad 2] Permission to change the API of CoreRenderer by adding a new final override and a new sub-class hook method for client behavior decoding (TRINIDAD-1715)
I am wondering if this may not be a great idea as it may break people
since CoreRenderer is API and not IMPL. Any ideas on how I can do this
in a way to ensure that the client behaviors are decoded but not break
the API?
-Andrew
On Wed, Feb 10, 2010 at 10:39 AM, Andrew Robinson
andrew.rw.robin...@gmail.com wrote:
I need to add the ClientBehavior decoding logic to Trinidad as I
forgot to do it earlier
(https://issues.apache.org/jira/browse/TRINIDAD-1715). I would like to
put the logic in the renderer, not in UIXComponentBase as it makes
much more sense to have it there. I need to make sure the method is
called so that people don't subclass the method and forget to call the
parent method. I would like to make the following additions to
CoreRenderer:
�...@override
public final void decode(
FacesContext facesContext,
UIComponent component)
{
FacesBean facesBean = getFacesBean(component);
String clientId = null;
if (facesBean != null)
{
clientId = decodeBehaviors(facesContext, component, facesBean);
}
decode(facesContext, component, facesBean, clientId);
}
/**
* Hook for sub-classes to perform their own decode logic
* @param facesContext the faces context
* @param component the component to decode
* @param facesBean the faces bean for the component
* @param clientId the client ID if it has been retrieved already
* during decoding, otherwise it will be null. Passed in for performance
* reasons, so that if it has already been retrieved it will not need to be
* retrieved again
*/
protected void decode(
FacesContext facesContext,
UIComponent component,
FacesBean facesBean,
String clientId)
{
// No-op
}
Even though this seems the right thing to do, I know that any
renderers that sub-class CoreRenderer or XhtmlRenderer will need to be
updated. I will obviously convert the Trinidad renderers. Do you all
concur that this is the right thing to do, an also if you are okay
with the API of the new contract?
Thank you,
Andrew
[jira] Created: (MYFACES-2546) Conversion rules for obtaing renderable String from the value property of SelectItem
Conversion rules for obtaing renderable String from the value property of
SelectItem
--
Key: MYFACES-2546
URL: https://issues.apache.org/jira/browse/MYFACES-2546
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces trunk
Reporter: Martin Koci
Priority: Minor
h:selectOneMenu
f:selectItems value=#{model.selectItemsWithNonStringValue} /
/h:selectOneMenu
if SelectItem.getValue() returns other type than String and there is no
converter for that type, myfaces throw exception:
java.lang.IllegalArgumentException: Value is no String
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getConvertedStringValue(RendererUtils.java:633)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getConvertedStringValue(RendererUtils.java:652)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.renderSelectOptions(HtmlRendererUtils.java:538)
RI does not throw a exception but with quietness outputs toString() as option
value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2544) UIViewRoot skips uncorrectly encodeBegin
[
https://issues.apache.org/jira/browse/MYFACES-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832211#action_12832211
]
Leonardo Uribe commented on MYFACES-2544:
-
How is context.getResponseComplete() related to error handling?
Look org.apache.myfaces.renderkit.ErrorPageWriter. This one is called after log
a page.
Yes, but why exclude from executing exactly one method at particular class?
Why UIViewRoot.encodeEnd is not exluded?
This should not happen and it is a bug. This means the code that call the
listener inside encodeBegin() should be called overriding
UIViewRoot.encodeAll(). Note this is not notice because the typical use case
fall into previous phases.
I don't think FacesContext.getRenderResponse() true = a runtime exception is
a valid expectation
True. My intention here is analize a possible use case that makes fail the
previous patch, not say this is the rule.
I committed an incomplete alternate patch. It is better to check:
context.getResponseComplete() || (context.getRenderResponse()
!PhaseId.RENDER_RESPONSE.equals(phaseId))
and move the algorithm that check for the listener to encodeAll. This fix
should be done in jsf 1.2 too. I'll commit the full solution soon.
UIViewRoot skips uncorrectly encodeBegin
Key: MYFACES-2544
URL: https://issues.apache.org/jira/browse/MYFACES-2544
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
Fix For: 2.0.0-beta-2
Attachments: MYFACES-2544-2.patch, MYFACES-2544.patch
javax.faces.component.UIViewRoot.encodeBegin(FacesContext) contains:
if (!skipPhase) {
super.encodeBegin(context);
}
but skipPhase = context.getRenderResponse() || context.getResponseComplete()
- it
makes sense for all phases except render response phase itself. That condition
probably should be:
if (!context.getResponseComplete()) {
super.encodeBegin(context);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2540) Facelets server state saving does not work
[ https://issues.apache.org/jira/browse/MYFACES-2540?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832218#action_12832218 ] Leonardo Uribe commented on MYFACES-2540: - I attached a patch with a modification about where it should be called stateMgr.saveView(context). This form is preferred because it is only called when it is necessary. The other way call it even in cases where we have pages that does not write the state token. Facelets server state saving does not work -- Key: MYFACES-2540 URL: https://issues.apache.org/jira/browse/MYFACES-2540 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta-2 Environment: myfaces core trunk Reporter: Martin Koci Attachments: MYFACES-2540-2.patch, MYFACES-2540.patch Facelets server state saving does not work: StateManager.saveView in not called during ViewDeclarationLanguage.renderView in case of server state saving. Please see attached patch for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2537) FacesConfigurator.sortRelativeOrderingList() algorithm is broken trying to resolve some examples
[ https://issues.apache.org/jira/browse/MYFACES-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832219#action_12832219 ] Leonardo Uribe commented on MYFACES-2537: - This is another different problem. We should handle it in other issue if possible. FacesConfigurator.sortRelativeOrderingList() algorithm is broken trying to resolve some examples Key: MYFACES-2537 URL: https://issues.apache.org/jira/browse/MYFACES-2537 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Leonardo Uribe Assignee: Leonardo Uribe Attachments: MYFACES-2537-FacesConfigurator.patch Curtiss Howard put this comment on dev list FacesConfigurator.sortRelativeOrderingList() is failing on a rather simple case: A after B B before C C before A The expected faces-config ordering is B-C-A, but instead sortRelativeOrderingList() is detecting a circularity. The algorithm proposed fails because it is not able to process the nodes in the correct order (the algorithm assign a weight equal to all nodes, so it fails when try to order them in a psedo postorder form). It is faster and better try another algorithm. The current one works in all tests done at this moment but this case makes it fail without any possible workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2544) UIViewRoot skips uncorrectly encodeBegin
[
https://issues.apache.org/jira/browse/MYFACES-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832224#action_12832224
]
Leonardo Uribe commented on MYFACES-2544:
-
The latest patch (MYFACES-2544-3.patch) is the final form of the proposed
solution. If no objections I'll commit it soon
UIViewRoot skips uncorrectly encodeBegin
Key: MYFACES-2544
URL: https://issues.apache.org/jira/browse/MYFACES-2544
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
Fix For: 2.0.0-beta-2
Attachments: MYFACES-2544-2.patch, MYFACES-2544-3.patch,
MYFACES-2544.patch
javax.faces.component.UIViewRoot.encodeBegin(FacesContext) contains:
if (!skipPhase) {
super.encodeBegin(context);
}
but skipPhase = context.getRenderResponse() || context.getResponseComplete()
- it
makes sense for all phases except render response phase itself. That condition
probably should be:
if (!context.getResponseComplete()) {
super.encodeBegin(context);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2544) UIViewRoot skips uncorrectly encodeBegin
[
https://issues.apache.org/jira/browse/MYFACES-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832226#action_12832226
]
Leonardo Uribe commented on MYFACES-2544:
-
Reading the spec javadoc, it is enforced listeners should be called from
encodeBegin() and encodeEnd(). We have to use an alternate way to produce the
same results.
UIViewRoot skips uncorrectly encodeBegin
Key: MYFACES-2544
URL: https://issues.apache.org/jira/browse/MYFACES-2544
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
Fix For: 2.0.0-beta-2
Attachments: MYFACES-2544-2.patch, MYFACES-2544-3.patch,
MYFACES-2544.patch
javax.faces.component.UIViewRoot.encodeBegin(FacesContext) contains:
if (!skipPhase) {
super.encodeBegin(context);
}
but skipPhase = context.getRenderResponse() || context.getResponseComplete()
- it
makes sense for all phases except render response phase itself. That condition
probably should be:
if (!context.getResponseComplete()) {
super.encodeBegin(context);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (MYFACES-2546) Conversion rules for obtaing renderable String from the value property of SelectItem
[
https://issues.apache.org/jira/browse/MYFACES-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Koci updated MYFACES-2546:
-
Status: Patch Available (was: Open)
Conversion rules for obtaing renderable String from the value property of
SelectItem
--
Key: MYFACES-2546
URL: https://issues.apache.org/jira/browse/MYFACES-2546
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces trunk
Reporter: Martin Koci
Priority: Minor
Attachments: MYFACES-2546.patch
h:selectOneMenu
f:selectItems value=#{model.selectItemsWithNonStringValue} /
/h:selectOneMenu
if SelectItem.getValue() returns other type than String and there is no
converter for that type, myfaces throw exception:
java.lang.IllegalArgumentException: Value is no String
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getConvertedStringValue(RendererUtils.java:633)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getConvertedStringValue(RendererUtils.java:652)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.renderSelectOptions(HtmlRendererUtils.java:538)
RI does not throw a exception but with quietness outputs toString() as
option value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2546) Conversion rules for obtaing renderable String from the value property of SelectItem
[
https://issues.apache.org/jira/browse/MYFACES-2546?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832227#action_12832227
]
Martin Koci commented on MYFACES-2546:
--
Trinidad also renders item.value.toString() - see
org.apache.myfaces.trinidadinternal.renderkit.core.xhtml.SimpleSelectOneChoiceRenderer.encodeSelectItems()
for example.
Conversion rules for obtaing renderable String from the value property of
SelectItem
--
Key: MYFACES-2546
URL: https://issues.apache.org/jira/browse/MYFACES-2546
Project: MyFaces Core
Issue Type: Improvement
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces trunk
Reporter: Martin Koci
Priority: Minor
Attachments: MYFACES-2546.patch
h:selectOneMenu
f:selectItems value=#{model.selectItemsWithNonStringValue} /
/h:selectOneMenu
if SelectItem.getValue() returns other type than String and there is no
converter for that type, myfaces throw exception:
java.lang.IllegalArgumentException: Value is no String
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getConvertedStringValue(RendererUtils.java:633)
at
org.apache.myfaces.shared_impl.renderkit.RendererUtils.getConvertedStringValue(RendererUtils.java:652)
at
org.apache.myfaces.shared_impl.renderkit.html.HtmlRendererUtils.renderSelectOptions(HtmlRendererUtils.java:538)
RI does not throw a exception but with quietness outputs toString() as
option value.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2544) UIViewRoot skips uncorrectly encodeBegin
[
https://issues.apache.org/jira/browse/MYFACES-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832238#action_12832238
]
Leonardo Uribe commented on MYFACES-2544:
-
The latest patch (MYFACES-2544-4.patch) uses encodeBegin() and encodeEnd(), but
before execute encodeChildren() or encodeEnd() it check for
getResponseComplete(). If no objections, I'll commit this code soon.
UIViewRoot skips uncorrectly encodeBegin
Key: MYFACES-2544
URL: https://issues.apache.org/jira/browse/MYFACES-2544
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.0-beta-2
Environment: myfaces trunk
Reporter: Martin Koci
Assignee: Jakob Korherr
Fix For: 2.0.0-beta-2
Attachments: MYFACES-2544-2.patch, MYFACES-2544-3.patch,
MYFACES-2544-4.patch, MYFACES-2544.patch
javax.faces.component.UIViewRoot.encodeBegin(FacesContext) contains:
if (!skipPhase) {
super.encodeBegin(context);
}
but skipPhase = context.getRenderResponse() || context.getResponseComplete()
- it
makes sense for all phases except render response phase itself. That condition
probably should be:
if (!context.getResponseComplete()) {
super.encodeBegin(context);
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (TRINIDAD-1718) input/select components are not rendered well with the new Casablanca skin
[ https://issues.apache.org/jira/browse/TRINIDAD-1718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Catalin Kormos resolved TRINIDAD-1718. -- Resolution: Fixed Fix Version/s: 1.2.14-core input/select components are not rendered well with the new Casablanca skin -- Key: TRINIDAD-1718 URL: https://issues.apache.org/jira/browse/TRINIDAD-1718 Project: MyFaces Trinidad Issue Type: Bug Components: Skinning Affects Versions: 1.2.14-core Reporter: Mathias Walter Assignee: Catalin Kormos Fix For: 1.2.14-core Attachments: casablanca_TreeTable_actionsFacet.png Trinidad input/select components are not rendered well if they are placed in the actions facet of a table/treeTable. See screenshot. The first input is a h:inputText, 2nd is tr:inputText and 3rd is tr:inputText with simple=true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces in OSGi
Hi Jarek,
It would be great if you could file your problems as issues in the jira.
Then I will take a look at them!
Thanks,
Jakob
2010/2/10 Jarek Gawor jga...@gmail.com
Hi all,
I'm trying to make latest MyFaces core run in OSGi environment (in
Geronimo 3.0) and I'm running into a few problems. I'm hoping to get
your input on some of these problems. Here's our setup: we deploy
myfaces-api and myfaces-impl as separate bundles and we also have a
separate bundle that is the application (effectively a war file) that
uses jsf. When running the application, Geronimo sets the context
class loader to the application classloader which delegates the calls
to the application bundle.
Now, most of the problems we are running into are due to use of the
context class loader in myfaces code to lookup resources within the
META-INF directory.
For example, IncludeHandler.java looks up
META-INF/rsc/myfaces-dev-error-include.xhtml resource or
FacesConfigurator.java looks up META-INF/standard-faces-config.xml
resource via CCL. This works great in a regular Java environment but
breaks in OSGi. One easy solution for this would be to first ask the
CCL for the resource and if none is found ask the surrounding class
class loader for that resource (assuming the resource we are looking
for lives in the same jar as the class loading it), i.e.:
URL foo = getContextClassLoader().getResource(META-INF/foo);
if (foo == null) {
foo = getClass().getClassLoader().getResource(META-INF/foo);
}
There are other more advanced work-arounds (e.g. ContextFinder in
Equinox) but I'm wondering what people think about updating the
MyFaces code to use this simple solution. Just to be clear, this only
needs to be done for a few known resources that live within the impl
or api jars and not for all resource lookups.
The ErrorPageWriter.java also looks up some resources via CCL and can
fall back to looking for META-INF/rsc/myfaces-dev-error.xml and
META-INF/rsc/myfaces-dev-debug.xml. But these resources live in the
api module for some reason. I'm not sure why but I'm hoping they can
be moved to the impl module. That way the simple solution mentioned
above would still work.
My final problem is with
AnnotationConfigurator.getMyfacesImplJarFile(). Besides the problem
with META-INF lookup using CCL and even if that method successfully
looked up that resource, it won't be able to get a JarFile out it.
Because the url returned from resource lookup in OSGi environment
can't be considered as a url to a jar file. So I think we will need a
way to override that piece of code from Geronimo somehow. Maybe even
making the getMyfacesImplJarFile() method protected would work for us
(we can return a fake JarFile that deletes calls to a bundle object).
Thanks,
Jarek
[jira] Created: (MYFACES-2547) FacesConfigurator absolute does not handle files with no name correctly
FacesConfigurator absolute does not handle files with no name correctly --- Key: MYFACES-2547 URL: https://issues.apache.org/jira/browse/MYFACES-2547 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Leonardo Uribe Assignee: Leonardo Uribe Reported in MYFACES-2537 by Martin Koci: Current implementation does not solve this situation: 2) JSF 2.0 library named cz_markoc_faces 1) JSF 1.2 library (without name - it is the OpenWebBeans JSF integration) My library is feeded 2x and OWB never - but I think this is caused with badly written if-condition, please see MYFACES-2537-FacesConfigurator.patch for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (MYFACES-2537) FacesConfigurator.sortRelativeOrderingList() algorithm is broken trying to resolve some examples
[ https://issues.apache.org/jira/browse/MYFACES-2537?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2537. - Resolution: Fixed Fix Version/s: 2.0.0-beta-2 Opened MYFACES-2547, so we can close this one FacesConfigurator.sortRelativeOrderingList() algorithm is broken trying to resolve some examples Key: MYFACES-2537 URL: https://issues.apache.org/jira/browse/MYFACES-2537 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 Attachments: MYFACES-2537-FacesConfigurator.patch Curtiss Howard put this comment on dev list FacesConfigurator.sortRelativeOrderingList() is failing on a rather simple case: A after B B before C C before A The expected faces-config ordering is B-C-A, but instead sortRelativeOrderingList() is detecting a circularity. The algorithm proposed fails because it is not able to process the nodes in the correct order (the algorithm assign a weight equal to all nodes, so it fails when try to order them in a psedo postorder form). It is faster and better try another algorithm. The current one works in all tests done at this moment but this case makes it fail without any possible workaround. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: MyFaces in OSGi
hi,
maybe bernhard can help as well.
he brought up [1] the topic some months ago.
regards,
gerhard
[1] http://www.mail-archive.com/dev@myfaces.apache.org/msg39068.html
http://www.irian.at
Your JSF powerhouse -
JSF Consulting, Development and
Courses in English and German
Professional Support for Apache MyFaces
2010/2/10 Jakob Korherr jakob.korh...@gmail.com
Hi Jarek,
It would be great if you could file your problems as issues in the jira.
Then I will take a look at them!
Thanks,
Jakob
2010/2/10 Jarek Gawor jga...@gmail.com
Hi all,
I'm trying to make latest MyFaces core run in OSGi environment (in
Geronimo 3.0) and I'm running into a few problems. I'm hoping to get
your input on some of these problems. Here's our setup: we deploy
myfaces-api and myfaces-impl as separate bundles and we also have a
separate bundle that is the application (effectively a war file) that
uses jsf. When running the application, Geronimo sets the context
class loader to the application classloader which delegates the calls
to the application bundle.
Now, most of the problems we are running into are due to use of the
context class loader in myfaces code to lookup resources within the
META-INF directory.
For example, IncludeHandler.java looks up
META-INF/rsc/myfaces-dev-error-include.xhtml resource or
FacesConfigurator.java looks up META-INF/standard-faces-config.xml
resource via CCL. This works great in a regular Java environment but
breaks in OSGi. One easy solution for this would be to first ask the
CCL for the resource and if none is found ask the surrounding class
class loader for that resource (assuming the resource we are looking
for lives in the same jar as the class loading it), i.e.:
URL foo = getContextClassLoader().getResource(META-INF/foo);
if (foo == null) {
foo = getClass().getClassLoader().getResource(META-INF/foo);
}
There are other more advanced work-arounds (e.g. ContextFinder in
Equinox) but I'm wondering what people think about updating the
MyFaces code to use this simple solution. Just to be clear, this only
needs to be done for a few known resources that live within the impl
or api jars and not for all resource lookups.
The ErrorPageWriter.java also looks up some resources via CCL and can
fall back to looking for META-INF/rsc/myfaces-dev-error.xml and
META-INF/rsc/myfaces-dev-debug.xml. But these resources live in the
api module for some reason. I'm not sure why but I'm hoping they can
be moved to the impl module. That way the simple solution mentioned
above would still work.
My final problem is with
AnnotationConfigurator.getMyfacesImplJarFile(). Besides the problem
with META-INF lookup using CCL and even if that method successfully
looked up that resource, it won't be able to get a JarFile out it.
Because the url returned from resource lookup in OSGi environment
can't be considered as a url to a jar file. So I think we will need a
way to override that piece of code from Geronimo somehow. Maybe even
making the getMyfacesImplJarFile() method protected would work for us
(we can return a fake JarFile that deletes calls to a bundle object).
Thanks,
Jarek
[jira] Resolved: (MYFACES-2547) FacesConfigurator absolute ordering does not handle files with no name correctly
[ https://issues.apache.org/jira/browse/MYFACES-2547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-2547. - Resolution: Fixed Fix Version/s: 2.0.0-beta-2 Thanks to Martin Koci for provide this patch. I also solve one small bug (remove a ;) in the algorithm too and add a junit test for absolute ordering. FacesConfigurator absolute ordering does not handle files with no name correctly Key: MYFACES-2547 URL: https://issues.apache.org/jira/browse/MYFACES-2547 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.0-beta-2 Reported in MYFACES-2537 by Martin Koci: Current implementation does not solve this situation: 2) JSF 2.0 library named cz_markoc_faces 1) JSF 1.2 library (without name - it is the OpenWebBeans JSF integration) My library is feeded 2x and OWB never - but I think this is caused with badly written if-condition, please see MYFACES-2537-FacesConfigurator.patch for details. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-2543) Facelets Taglib jars are not recognized
[ https://issues.apache.org/jira/browse/MYFACES-2543?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12832298#action_12832298 ] Leonardo Uribe commented on MYFACES-2543: - This issue is invalid. The day we change the package from com.sun.facelets to org.apache.myfaces.view.facelets we make impossible to do that. I believe the spec is clear (see section 10.1.2). The fact is facelets tag handlers from 1.1.x requires classes on package com.sun.facelets, and myfaces doesn't have them. I ignore if we can run old facelets jars with myfaces 2.0.x. The point is this will not be solved because it has unwanted side effects, and unfortunately we can't solve them. Facelets Taglib jars are not recognized --- Key: MYFACES-2543 URL: https://issues.apache.org/jira/browse/MYFACES-2543 Project: MyFaces Core Issue Type: Bug Components: JSR-314 Affects Versions: 2.0.0-beta Environment: Facelets Reporter: Ganesh Jung Attachments: MyFaces_Test.jar Facelets taglibs defined according to the spec 10.3.2 are not recognized. This page uses a test taglib (see attachment): !DOCTYPE html PUBLIC -//W3C//DTD XHTML 1.0 Transitional//EN http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd; html xmlns=http://www.w3.org/1999/xhtml; xmlns:f=http://java.sun.com/jsf/core; xmlns:h=http://java.sun.com/jsf/html; xmlns:ui=http://java.sun.com/jsf/facelets; xmlns:test=http://j4fry.org/test; body test:button / /body /html but test:button is not resolved... -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [REVOTE] Ext-Scripting Alpha1
Hi +1 I have seen there is no site configuration for this project. Do you have any plans about do this later (if you need some help with that I can do it, so you can focus on the code)? regards, Leonardo Uribe 2010/2/10 Grant Smith work.gr...@gmail.com +1 On Wed, Feb 10, 2010 at 9:23 AM, Alexander Bell alexander.b...@j4fry.orgwrote: +1 build integration was successful Alex 2010/2/10 Jan-Kees van Andel jankeesvanan...@gmail.com +1 Regards, Jan-Kees 2010/2/10 Jakob Korherr jakob.korh...@gmail.com: +1 Regards, Jakob 2010/2/10 Matthias Wessendorf mat...@apache.org +1 On Tue, Feb 9, 2010 at 11:46 PM, Gerhard Petracek gerhard.petra...@gmail.com wrote: +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/2/9 Werner Punz werner.p...@gmail.com Hello, as some may remember I had to pull the vote of ext-scripting Alpha 1 due to a missing parent pom in the projects main pom. Nevertheless I have done all the changes and used the opportunity for some pre alpha code cleanup. I would like to restart the vote, to get the Alpha finally out. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Mit freundlichen Grüßen / Kind regards Alexander Bell J4Fry OpenSource Community Internet: http://www.j4fry.org E-Mail: alexander.b...@j4fry.org Webprofil: http://www.j4fry.org/alexanderbell.shtml -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
[jira] Created: (MYFACES-2548) META-INF resource lookup in OSGi environment
META-INF resource lookup in OSGi environment
Key: MYFACES-2548
URL: https://issues.apache.org/jira/browse/MYFACES-2548
Project: MyFaces Core
Issue Type: Improvement
Components: General
Affects Versions: 2.0.0-beta-2
Reporter: Jarek Gawor
MyFaces uses context class loader to lookup META-INF resources. This works fine
in a regular Java environment but breaks in OSGi. One easy solution for this
would be to first ask the CCL for the resource and if none is found ask the
surrounding class class loader for that resource (assuming the resource we are
looking for lives in the same jar as the class loading it), i.e.:
URL foo = getContextClassLoader().getResource(META-INF/foo);
if (foo == null) {
foo = getClass().getClassLoader().getResource(META-INF/foo);
}
There are a few places in MyFaces code that would need to be updated to use
this fallback approach. For example in IncludeHandler.java and
ErrorPageWriter.java.
I also noticed that for some reason the myfaces-dev-debug.xml and
myfaces-dev-error.xml live in the api module. They seem to be only used the
impl module so they shouldn't really be needed in the api module.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [REVOTE] Ext-Scripting Alpha1
That is planned post alpha 1 :-) I just want to get an alpha snapshot out so that people who are interested have the confidence to try it out. (In my opinion the code is more or less beta) Werner Leonardo Uribe schrieb: Hi +1 I have seen there is no site configuration for this project. Do you have any plans about do this later (if you need some help with that I can do it, so you can focus on the code)? regards, Leonardo Uribe 2010/2/10 Grant Smith work.gr...@gmail.com mailto:work.gr...@gmail.com +1 On Wed, Feb 10, 2010 at 9:23 AM, Alexander Bell alexander.b...@j4fry.org mailto:alexander.b...@j4fry.org wrote: +1 build integration was successful Alex 2010/2/10 Jan-Kees van Andel jankeesvanan...@gmail.com mailto:jankeesvanan...@gmail.com +1 Regards, Jan-Kees 2010/2/10 Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com: +1 Regards, Jakob 2010/2/10 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org +1 On Tue, Feb 9, 2010 at 11:46 PM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: +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/2/9 Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com Hello, as some may remember I had to pull the vote of ext-scripting Alpha 1 due to a missing parent pom in the projects main pom. Nevertheless I have done all the changes and used the opportunity for some pre alpha code cleanup. I would like to restart the vote, to get the Alpha finally out. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Mit freundlichen Grüßen / Kind regards Alexander Bell J4Fry OpenSource Community Internet: http://www.j4fry.org E-Mail: alexander.b...@j4fry.org mailto:alexander.b...@j4fry.org Webprofil: http://www.j4fry.org/alexanderbell.shtml -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
Re: [REVOTE] Ext-Scripting Alpha1
Ah I forgot, for the site, I want to do it the ext-eval way, just a single page which then links to the Wiki for now. I added extensive but yet unfinished documentation there. Post 1.0 when the Wiki has been enough proofread and better structure I will do a snapshot to roll a site and the documentation in a better way. But for now that is my plan regarding the site. Werner Leonardo Uribe schrieb: Hi +1 I have seen there is no site configuration for this project. Do you have any plans about do this later (if you need some help with that I can do it, so you can focus on the code)? regards, Leonardo Uribe 2010/2/10 Grant Smith work.gr...@gmail.com mailto:work.gr...@gmail.com +1 On Wed, Feb 10, 2010 at 9:23 AM, Alexander Bell alexander.b...@j4fry.org mailto:alexander.b...@j4fry.org wrote: +1 build integration was successful Alex 2010/2/10 Jan-Kees van Andel jankeesvanan...@gmail.com mailto:jankeesvanan...@gmail.com +1 Regards, Jan-Kees 2010/2/10 Jakob Korherr jakob.korh...@gmail.com mailto:jakob.korh...@gmail.com: +1 Regards, Jakob 2010/2/10 Matthias Wessendorf mat...@apache.org mailto:mat...@apache.org +1 On Tue, Feb 9, 2010 at 11:46 PM, Gerhard Petracek gerhard.petra...@gmail.com mailto:gerhard.petra...@gmail.com wrote: +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/2/9 Werner Punz werner.p...@gmail.com mailto:werner.p...@gmail.com Hello, as some may remember I had to pull the vote of ext-scripting Alpha 1 due to a missing parent pom in the projects main pom. Nevertheless I have done all the changes and used the opportunity for some pre alpha code cleanup. I would like to restart the vote, to get the Alpha finally out. Werner -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf -- Mit freundlichen Grüßen / Kind regards Alexander Bell J4Fry OpenSource Community Internet: http://www.j4fry.org E-Mail: alexander.b...@j4fry.org mailto:alexander.b...@j4fry.org Webprofil: http://www.j4fry.org/alexanderbell.shtml -- Grant Smith - V.P. Information Technology Marathon Computer Systems, LLC.
Re: MyFaces in OSGi
Ok, sure. For now I created MYFACES-2548 with a proposed patch. I
might open one more bug for the
AnnotationConfigurator.getMyfacesImplJarFile() issue once I do little
more testing.
Jarek
On Wed, Feb 10, 2010 at 5:51 PM, Jakob Korherr jakob.korh...@gmail.com wrote:
Hi Jarek,
It would be great if you could file your problems as issues in the jira.
Then I will take a look at them!
Thanks,
Jakob
2010/2/10 Jarek Gawor jga...@gmail.com
Hi all,
I'm trying to make latest MyFaces core run in OSGi environment (in
Geronimo 3.0) and I'm running into a few problems. I'm hoping to get
your input on some of these problems. Here's our setup: we deploy
myfaces-api and myfaces-impl as separate bundles and we also have a
separate bundle that is the application (effectively a war file) that
uses jsf. When running the application, Geronimo sets the context
class loader to the application classloader which delegates the calls
to the application bundle.
Now, most of the problems we are running into are due to use of the
context class loader in myfaces code to lookup resources within the
META-INF directory.
For example, IncludeHandler.java looks up
META-INF/rsc/myfaces-dev-error-include.xhtml resource or
FacesConfigurator.java looks up META-INF/standard-faces-config.xml
resource via CCL. This works great in a regular Java environment but
breaks in OSGi. One easy solution for this would be to first ask the
CCL for the resource and if none is found ask the surrounding class
class loader for that resource (assuming the resource we are looking
for lives in the same jar as the class loading it), i.e.:
URL foo = getContextClassLoader().getResource(META-INF/foo);
if (foo == null) {
foo = getClass().getClassLoader().getResource(META-INF/foo);
}
There are other more advanced work-arounds (e.g. ContextFinder in
Equinox) but I'm wondering what people think about updating the
MyFaces code to use this simple solution. Just to be clear, this only
needs to be done for a few known resources that live within the impl
or api jars and not for all resource lookups.
The ErrorPageWriter.java also looks up some resources via CCL and can
fall back to looking for META-INF/rsc/myfaces-dev-error.xml and
META-INF/rsc/myfaces-dev-debug.xml. But these resources live in the
api module for some reason. I'm not sure why but I'm hoping they can
be moved to the impl module. That way the simple solution mentioned
above would still work.
My final problem is with
AnnotationConfigurator.getMyfacesImplJarFile(). Besides the problem
with META-INF lookup using CCL and even if that method successfully
looked up that resource, it won't be able to get a JarFile out it.
Because the url returned from resource lookup in OSGi environment
can't be considered as a url to a jar file. So I think we will need a
way to override that piece of code from Geronimo somehow. Maybe even
making the getMyfacesImplJarFile() method protected would work for us
(we can return a fake JarFile that deletes calls to a bundle object).
Thanks,
Jarek
