Hi Note that this behavior implies that all applications that are using JSP and are upgraded to JSF 2.0 needs to add javax.faces.DISABLE_FACELET_JSF_VIEWHANDLER to work correctly, otherwise if the parser reads a "bad" facelet taglib file it could throw ClassXXXExceptions. I would like to prevent that.
And the code on ViewDeclarationLanguageFactoryImpl does not take into consideration the trinidad + facelets ViewHandler config style (check for class to know if facelets is on is a bad idea). In few words, we have to solve MYFACES-2564 too. regards, Leonardo Uribe The code reverted on MYFACES-2564 needs to be applied too, but care must be taken into account 2010/2/25 Matthias Wessendorf <[email protected]> > 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. > <=== > > Also note the *java* in "java code". > > -Matthias > > > On Thu, Feb 25, 2010 at 1:56 PM, Leonardo Uribe <[email protected]> wrote: > > Hi > > > > The problem is the spec is not explicit about that. I think the way it > this > > written those paragraph are as if it was a "guideline" and that's is the > > problem because this should be explicit. > > > > The behavior proposed (throw ClassNotFoundException or ClassCastException > > and kick all users to use facelets 1.1.x) is valid, so it is ok to commit > > it. > > > > regards, > > > > Leonardo Uribe > > > > 2010/2/25 Jakob Korherr <[email protected]> > >> > >> Hi, > >> > >> But the users DO want to run the "old" facelets taglibs and, as > discussed > >> before, 95% of the "old" taglibs don't rely on com.sun.facelets classes, > >> they just define tags via xhtml files. > >> > >> If they get a ClassCastException the just have to use the old > >> facelets-1.1.x. This is excatly what the spec says! > >> > >> Regards, > >> Jakob > >> > >> 2010/2/25 Leonardo Uribe <[email protected]> > >>> > >>> Hi > >>> > >>> If we read every facelet 1.1.x tag lib xml file, it is possible to get > >>> ClassNotFoundException. The problem with this behavior is that it does > not > >>> give the chance to users to fix it without change the original jar > file. > >>> > >>> regards, > >>> > >>> Leonardo Uribe > >>> > >>> 2010/2/25 Jakob Korherr <[email protected]> > >>>> > >>>> Hi Leo, > >>>> > >>>> It is a really easy fix - I just removed the version check in > >>>> TagLibraryConfig to make "old" libraries work. If the EG changes the > spec in > >>>> this field we can apply this later. In the meantime, I think we > clearly > >>>> should support "old" facelets taglibs. > >>>> > >>>> Regards, > >>>> Jakob > >>>> > >>>> 2010/2/25 Leonardo Uribe <[email protected]> > >>>>> > >>>>> Hi > >>>>> > >>>>> Before commit it I would like to have the description about how this > >>>>> should work and ask or notify the EG about this behavior (so if they > decide > >>>>> something different we have a chance to do it right). Since ri is > doing > >>>>> something in this field, I think we can commit a solution for that. > >>>>> > >>>>> regards, > >>>>> > >>>>> Leonardo Uribe > >>>>> > >>>>> 2010/2/25 Jakob Korherr <[email protected]> > >>>>>> > >>>>>> I'll do it! I also have a working version running locally at the > >>>>>> moment, I just have to test it a little more. Then I'll commit it ;) > >>>>>> > >>>>>> Regards, > >>>>>> Jakob > >>>>>> > >>>>>> 2010/2/25 Matthias Wessendorf <[email protected]> > >>>>>>> > >>>>>>> Yeah, I understand that. > >>>>>>> > >>>>>>> Any interest in helping with the fix ? :) > >>>>>>> > >>>>>>> -Matthias > >>>>>>> > >>>>>>> On Thu, Feb 25, 2010 at 8:47 AM, Ganesh <[email protected]> wrote: > >>>>>>> > Also this blocks me from testing the beta with DojoFaces which > >>>>>>> > might reveal > >>>>>>> > other issues ... > >>>>>>> > > >>>>>>> > Best regards, > >>>>>>> > Ganesh > >>>>>>> > > >>>>>>> > Matthias Wessendorf schrieb: > >>>>>>> >> > >>>>>>> >> Again... > >>>>>>> >> > >>>>>>> >> MYFACES-2543 > >>>>>>> >> > >>>>>>> >> *snip* > >>>>>>> >> 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. > >>>>>>> >> *snip* > >>>>>>> >> > >>>>>>> >> So, this is actually blocking a reasonable use-case. Please keep > >>>>>>> >> the > >>>>>>> >> bug open ;-) > >>>>>>> >> > >>>>>>> >> -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 >
