Re: [core] Backwards compatibility (e.g. MYFACES-2543)
Yes.- this is a BUG it needs to support more than just 2.0 (Dan/Ed commented on the open list) -Matthias On Thu, Feb 11, 2010 at 2:35 PM, Matthias Wessendorf mat...@apache.org wrote: nope, but the web.xml setting for Trinidad's alternate view handler; it is complaining about the facelets embedded faces-config -Matthias On Thu, Feb 11, 2010 at 2:22 PM, Jakob Korherr jakob.korh...@gmail.com wrote: have you installed the com.sun.facelets.FaceletViewHandler in faces-config? and which error did you get? 2010/2/11 Matthias Wessendorf mat...@apache.org @ javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER I tried (Glassfish v3) to deploy a JSF 1.2 application (with Facelets 1.1.14) and that javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER parameter == true; I get an error there as well :-) -Matthias On Wed, Feb 10, 2010 at 11:08 AM, Jakob Korherr jakob.korh...@gmail.com wrote: 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 -- 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:
Re: [core] Backwards compatibility (e.g. MYFACES-2543)
@ javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER I tried (Glassfish v3) to deploy a JSF 1.2 application (with Facelets 1.1.14) and that javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER parameter == true; I get an error there as well :-) -Matthias On Wed, Feb 10, 2010 at 11:08 AM, Jakob Korherr jakob.korh...@gmail.com wrote: 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 -- 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)
have you installed the com.sun.facelets.FaceletViewHandler in faces-config? and which error did you get? 2010/2/11 Matthias Wessendorf mat...@apache.org @ javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER I tried (Glassfish v3) to deploy a JSF 1.2 application (with Facelets 1.1.14) and that javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER parameter == true; I get an error there as well :-) -Matthias On Wed, Feb 10, 2010 at 11:08 AM, Jakob Korherr jakob.korh...@gmail.com wrote: 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 -- 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)
nope, but the web.xml setting for Trinidad's alternate view handler; it is complaining about the facelets embedded faces-config -Matthias On Thu, Feb 11, 2010 at 2:22 PM, Jakob Korherr jakob.korh...@gmail.com wrote: have you installed the com.sun.facelets.FaceletViewHandler in faces-config? and which error did you get? 2010/2/11 Matthias Wessendorf mat...@apache.org @ javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER I tried (Glassfish v3) to deploy a JSF 1.2 application (with Facelets 1.1.14) and that javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER parameter == true; I get an error there as well :-) -Matthias On Wed, Feb 10, 2010 at 11:08 AM, Jakob Korherr jakob.korh...@gmail.com wrote: 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 -- 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: [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
[core] Backwards compatibility (e.g. MYFACES-2543)
Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -Matthias -- 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)
On my opinion you have to differentiate between 1.x taglibs and 2.0 taglibs in some way, because MyFaces cannot know if this taglib will or won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you simply have to add version=2.0 to your taglib and it will function properly. This is also specified in the spec (although completely hidden in the appendix): take a look at the xsd type definition of facelet-taglib-versionType. It says This type contains the recognized versions of facelet-taglib supported. and 2.0 is the only allowed value for this attribute. Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -Matthias -- 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)
Hi I agree with Jakob. Just a small comment, doing some black box tests between myfaces and ri I notice long time ago that ri cannot read faces-config.xml without have version 2.0 in that file. It seems they fix that but a side effect is what we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is doing right and really ri is mixing the two config files by some unknown reason. regards, Leonardo Uribe 2010/2/9 Jakob Korherr jakob.korh...@gmail.com On my opinion you have to differentiate between 1.x taglibs and 2.0 taglibs in some way, because MyFaces cannot know if this taglib will or won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you simply have to add version=2.0 to your taglib and it will function properly. This is also specified in the spec (although completely hidden in the appendix): take a look at the xsd type definition of facelet-taglib-versionType. It says This type contains the recognized versions of facelet-taglib supported. and 2.0 is the only allowed value for this attribute. Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -Matthias -- 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)
maybe I am conservative, but I doubt that it is a bug, to allow old facelets-based tag JARs. You are saying it is, right ? On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I agree with Jakob. Just a small comment, doing some black box tests between myfaces and ri I notice long time ago that ri cannot read faces-config.xml without have version 2.0 in that file. It seems they fix that but a side effect is what we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is doing right and really ri is mixing the two config files by some unknown reason. regards, Leonardo Uribe 2010/2/9 Jakob Korherr jakob.korh...@gmail.com On my opinion you have to differentiate between 1.x taglibs and 2.0 taglibs in some way, because MyFaces cannot know if this taglib will or won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you simply have to add version=2.0 to your taglib and it will function properly. This is also specified in the spec (although completely hidden in the appendix): take a look at the xsd type definition of facelet-taglib-versionType. It says This type contains the recognized versions of facelet-taglib supported. and 2.0 is the only allowed value for this attribute. Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -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: [core] Backwards compatibility (e.g. MYFACES-2543)
... on the other hand, the EG says, that JSF2.0 RT can be used to deploy a JSF1.2 based application. Since Facelets was just some random proprietary framework, ignoring the old Facelets DTD is I think correct; Still it is IMO a bit lame. -Matthias On Tue, Feb 9, 2010 at 7:20 PM, Matthias Wessendorf mat...@apache.org wrote: maybe I am conservative, but I doubt that it is a bug, to allow old facelets-based tag JARs. You are saying it is, right ? On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I agree with Jakob. Just a small comment, doing some black box tests between myfaces and ri I notice long time ago that ri cannot read faces-config.xml without have version 2.0 in that file. It seems they fix that but a side effect is what we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is doing right and really ri is mixing the two config files by some unknown reason. regards, Leonardo Uribe 2010/2/9 Jakob Korherr jakob.korh...@gmail.com On my opinion you have to differentiate between 1.x taglibs and 2.0 taglibs in some way, because MyFaces cannot know if this taglib will or won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you simply have to add version=2.0 to your taglib and it will function properly. This is also specified in the spec (although completely hidden in the appendix): take a look at the xsd type definition of facelet-taglib-versionType. It says This type contains the recognized versions of facelet-taglib supported. and 2.0 is the only allowed value for this attribute. Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -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: [core] Backwards compatibility (e.g. MYFACES-2543)
Can it be made into a configuration option? On Tue, Feb 9, 2010 at 1:25 PM, Matthias Wessendorf mat...@apache.org wrote: ... on the other hand, the EG says, that JSF2.0 RT can be used to deploy a JSF1.2 based application. Since Facelets was just some random proprietary framework, ignoring the old Facelets DTD is I think correct; Still it is IMO a bit lame. -Matthias On Tue, Feb 9, 2010 at 7:20 PM, Matthias Wessendorf mat...@apache.org wrote: maybe I am conservative, but I doubt that it is a bug, to allow old facelets-based tag JARs. You are saying it is, right ? On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I agree with Jakob. Just a small comment, doing some black box tests between myfaces and ri I notice long time ago that ri cannot read faces-config.xml without have version 2.0 in that file. It seems they fix that but a side effect is what we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is doing right and really ri is mixing the two config files by some unknown reason. regards, Leonardo Uribe 2010/2/9 Jakob Korherr jakob.korh...@gmail.com On my opinion you have to differentiate between 1.x taglibs and 2.0 taglibs in some way, because MyFaces cannot know if this taglib will or won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you simply have to add version=2.0 to your taglib and it will function properly. This is also specified in the spec (although completely hidden in the appendix): take a look at the xsd type definition of facelet-taglib-versionType. It says This type contains the recognized versions of facelet-taglib supported. and 2.0 is the only allowed value for this attribute. Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -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: [core] Backwards compatibility (e.g. MYFACES-2543)
It is a bug to allow old facelets taglibs which are not marked with version=2.0 with the built-in facelets implementation. 2010/2/9 Matthias Wessendorf mat...@apache.org maybe I am conservative, but I doubt that it is a bug, to allow old facelets-based tag JARs. You are saying it is, right ? On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I agree with Jakob. Just a small comment, doing some black box tests between myfaces and ri I notice long time ago that ri cannot read faces-config.xml without have version 2.0 in that file. It seems they fix that but a side effect is what we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is doing right and really ri is mixing the two config files by some unknown reason. regards, Leonardo Uribe 2010/2/9 Jakob Korherr jakob.korh...@gmail.com On my opinion you have to differentiate between 1.x taglibs and 2.0 taglibs in some way, because MyFaces cannot know if this taglib will or won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you simply have to add version=2.0 to your taglib and it will function properly. This is also specified in the spec (although completely hidden in the appendix): take a look at the xsd type definition of facelet-taglib-versionType. It says This type contains the recognized versions of facelet-taglib supported. and 2.0 is the only allowed value for this attribute. Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -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: [core] Backwards compatibility (e.g. MYFACES-2543)
Never mind. I see in the jira issue that it's possible to drop in the old facelets implementation. That seems like the right approach to me. On Tue, Feb 9, 2010 at 1:27 PM, Mike Kienenberger mkien...@gmail.com wrote: Can it be made into a configuration option? On Tue, Feb 9, 2010 at 1:25 PM, Matthias Wessendorf mat...@apache.org wrote: ... on the other hand, the EG says, that JSF2.0 RT can be used to deploy a JSF1.2 based application. Since Facelets was just some random proprietary framework, ignoring the old Facelets DTD is I think correct; Still it is IMO a bit lame. -Matthias On Tue, Feb 9, 2010 at 7:20 PM, Matthias Wessendorf mat...@apache.org wrote: maybe I am conservative, but I doubt that it is a bug, to allow old facelets-based tag JARs. You are saying it is, right ? On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I agree with Jakob. Just a small comment, doing some black box tests between myfaces and ri I notice long time ago that ri cannot read faces-config.xml without have version 2.0 in that file. It seems they fix that but a side effect is what we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is doing right and really ri is mixing the two config files by some unknown reason. regards, Leonardo Uribe 2010/2/9 Jakob Korherr jakob.korh...@gmail.com On my opinion you have to differentiate between 1.x taglibs and 2.0 taglibs in some way, because MyFaces cannot know if this taglib will or won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you simply have to add version=2.0 to your taglib and it will function properly. This is also specified in the spec (although completely hidden in the appendix): take a look at the xsd type definition of facelet-taglib-versionType. It says This type contains the recognized versions of facelet-taglib supported. and 2.0 is the only allowed value for this attribute. Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -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: [core] Backwards compatibility (e.g. MYFACES-2543)
On Tue, Feb 9, 2010 at 7:23 PM, Jakob Korherr jakob.korh...@gmail.com wrote: It is a bug to allow old facelets taglibs which are not marked with version=2.0 with the built-in facelets implementation. do you mind filing one against them :-) I wonder what they have to say for that... -Matthias 2010/2/9 Matthias Wessendorf mat...@apache.org maybe I am conservative, but I doubt that it is a bug, to allow old facelets-based tag JARs. You are saying it is, right ? On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I agree with Jakob. Just a small comment, doing some black box tests between myfaces and ri I notice long time ago that ri cannot read faces-config.xml without have version 2.0 in that file. It seems they fix that but a side effect is what we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is doing right and really ri is mixing the two config files by some unknown reason. regards, Leonardo Uribe 2010/2/9 Jakob Korherr jakob.korh...@gmail.com On my opinion you have to differentiate between 1.x taglibs and 2.0 taglibs in some way, because MyFaces cannot know if this taglib will or won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you simply have to add version=2.0 to your taglib and it will function properly. This is also specified in the spec (although completely hidden in the appendix): take a look at the xsd type definition of facelet-taglib-versionType. It says This type contains the recognized versions of facelet-taglib supported. and 2.0 is the only allowed value for this attribute. Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -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: [core] Backwards compatibility (e.g. MYFACES-2543)
...and, of course, when you extend old Facelets classes, this is NOT supported. However the JSF spec has provided a backdoor: == javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER for that you need to ship old Facelets. -Matthias On Tue, Feb 9, 2010 at 7:25 PM, Matthias Wessendorf mat...@apache.org wrote: ... on the other hand, the EG says, that JSF2.0 RT can be used to deploy a JSF1.2 based application. Since Facelets was just some random proprietary framework, ignoring the old Facelets DTD is I think correct; Still it is IMO a bit lame. -Matthias On Tue, Feb 9, 2010 at 7:20 PM, Matthias Wessendorf mat...@apache.org wrote: maybe I am conservative, but I doubt that it is a bug, to allow old facelets-based tag JARs. You are saying it is, right ? On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I agree with Jakob. Just a small comment, doing some black box tests between myfaces and ri I notice long time ago that ri cannot read faces-config.xml without have version 2.0 in that file. It seems they fix that but a side effect is what we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is doing right and really ri is mixing the two config files by some unknown reason. regards, Leonardo Uribe 2010/2/9 Jakob Korherr jakob.korh...@gmail.com On my opinion you have to differentiate between 1.x taglibs and 2.0 taglibs in some way, because MyFaces cannot know if this taglib will or won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you simply have to add version=2.0 to your taglib and it will function properly. This is also specified in the spec (although completely hidden in the appendix): take a look at the xsd type definition of facelet-taglib-versionType. It says This type contains the recognized versions of facelet-taglib supported. and 2.0 is the only allowed value for this attribute. Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -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 -- 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)
On Tue, Feb 9, 2010 at 7:31 PM, Mike Kienenberger mkien...@gmail.com wrote: Never mind. I see in the jira issue that it's possible to drop in the old facelets implementation. That seems like the right approach to me. 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 use ;-) Oh, crappy MyFaces doesn't work etc :) All the FUD! :) On Tue, Feb 9, 2010 at 1:27 PM, Mike Kienenberger mkien...@gmail.com wrote: Can it be made into a configuration option? On Tue, Feb 9, 2010 at 1:25 PM, Matthias Wessendorf mat...@apache.org wrote: ... on the other hand, the EG says, that JSF2.0 RT can be used to deploy a JSF1.2 based application. Since Facelets was just some random proprietary framework, ignoring the old Facelets DTD is I think correct; Still it is IMO a bit lame. -Matthias On Tue, Feb 9, 2010 at 7:20 PM, Matthias Wessendorf mat...@apache.org wrote: maybe I am conservative, but I doubt that it is a bug, to allow old facelets-based tag JARs. You are saying it is, right ? On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I agree with Jakob. Just a small comment, doing some black box tests between myfaces and ri I notice long time ago that ri cannot read faces-config.xml without have version 2.0 in that file. It seems they fix that but a side effect is what we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is doing right and really ri is mixing the two config files by some unknown reason. regards, Leonardo Uribe 2010/2/9 Jakob Korherr jakob.korh...@gmail.com On my opinion you have to differentiate between 1.x taglibs and 2.0 taglibs in some way, because MyFaces cannot know if this taglib will or won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you simply have to add version=2.0 to your taglib and it will function properly. This is also specified in the spec (although completely hidden in the appendix): take a look at the xsd type definition of facelet-taglib-versionType. It says This type contains the recognized versions of facelet-taglib supported. and 2.0 is the only allowed value for this attribute. Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -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 -- 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)
we could make a special log entry instead of just ignoring old facelets libraries. ...and you do not have to set the config parameter if the com.sun.facelets.FaceletViewHandler is installed in the faces-config. MyFaces does this automatically! 2010/2/9 Matthias Wessendorf mat...@apache.org On Tue, Feb 9, 2010 at 7:31 PM, Mike Kienenberger mkien...@gmail.com wrote: Never mind. I see in the jira issue that it's possible to drop in the old facelets implementation. That seems like the right approach to me. 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 use ;-) Oh, crappy MyFaces doesn't work etc :) All the FUD! :) On Tue, Feb 9, 2010 at 1:27 PM, Mike Kienenberger mkien...@gmail.com wrote: Can it be made into a configuration option? On Tue, Feb 9, 2010 at 1:25 PM, Matthias Wessendorf mat...@apache.org wrote: ... on the other hand, the EG says, that JSF2.0 RT can be used to deploy a JSF1.2 based application. Since Facelets was just some random proprietary framework, ignoring the old Facelets DTD is I think correct; Still it is IMO a bit lame. -Matthias On Tue, Feb 9, 2010 at 7:20 PM, Matthias Wessendorf mat...@apache.org wrote: maybe I am conservative, but I doubt that it is a bug, to allow old facelets-based tag JARs. You are saying it is, right ? On Tue, Feb 9, 2010 at 7:04 PM, Leonardo Uribe lu4...@gmail.com wrote: Hi I agree with Jakob. Just a small comment, doing some black box tests between myfaces and ri I notice long time ago that ri cannot read faces-config.xml without have version 2.0 in that file. It seems they fix that but a side effect is what we are seeing right now (facelets taglibs 1.1.x read). I think myfaces is doing right and really ri is mixing the two config files by some unknown reason. regards, Leonardo Uribe 2010/2/9 Jakob Korherr jakob.korh...@gmail.com On my opinion you have to differentiate between 1.x taglibs and 2.0 taglibs in some way, because MyFaces cannot know if this taglib will or won't run. If you can ensure that your 1.x-taglib runs with facelets 2.0 you simply have to add version=2.0 to your taglib and it will function properly. This is also specified in the spec (although completely hidden in the appendix): take a look at the xsd type definition of facelet-taglib-versionType. It says This type contains the recognized versions of facelet-taglib supported. and 2.0 is the only allowed value for this attribute. Regards, Jakob 2010/2/9 Matthias Wessendorf mat...@apache.org Deplyoing very simple JARs, like: https://issues.apache.org/jira/secure/attachment/12435313/MyFaces_Test.jar should work, out of the box. Doesn't the spec explicitly talk about this for backward compatibility? Sure, when you extend the old Facelets classes, you have to have it deployed as well (and there is some parameter to disable Facelets2) -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 -- 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)
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. 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'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 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 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
