MyFaces Core
  1. MyFaces Core
  2. MYFACES-2543

Facelets Taglib jars are not recognized

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 2.0.0-beta
    • Fix Version/s: 2.0.0-beta-3
    • Component/s: JSR-314
    • Labels:
      None
    • Environment:
      Facelets

      Description

      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...

      1. MyFaces_Test.jar
        1.0 kB
        Ganesh Jung

        Issue Links

          Activity

          Hide
          Ganesh Jung added a comment -

          By putting this jar on to your classpath you can test the example page.

          Show
          Ganesh Jung added a comment - By putting this jar on to your classpath you can test the example page.
          Hide
          Jakob Korherr added a comment -

          Your facelets taglib has to have the version attribute set to 2.0 to be recognized!!!

          Show
          Jakob Korherr added a comment - Your facelets taglib has to have the version attribute set to 2.0 to be recognized!!!
          Hide
          Matthias Weßendorf added a comment -

          which is IMO not nice;
          As stated on a different bug, MyFaces2 should be more lenient...

          Show
          Matthias Weßendorf added a comment - which is IMO not nice; As stated on a different bug, MyFaces2 should be more lenient...
          Hide
          Jakob Korherr added a comment -

          I don't know if this is OK with the spec. Mojarra does that too. On my opinion you have to differentiate between facelets 1.x and facelets 2 in some sort of way an this version attribute does exactly that. Furthermore if you want to use a facelets 1.x taglib you can use the (old) facelets 1.x. implementation. This will work.

          Show
          Jakob Korherr added a comment - I don't know if this is OK with the spec. Mojarra does that too. On my opinion you have to differentiate between facelets 1.x and facelets 2 in some sort of way an this version attribute does exactly that. Furthermore if you want to use a facelets 1.x taglib you can use the (old) facelets 1.x. implementation. This will work.
          Hide
          Leonardo Uribe added a comment -

          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.

          Show
          Leonardo Uribe added a comment - 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.
          Hide
          Leonardo Uribe added a comment -

          This issue is closed as won't fix, because no advance can be done from this point. To solve it we have to change the package convention to com.sun.facelets, and that is a bad idea. Note a workaround could be done to allow previous jsf 1.2 libs to work with jsf 2.0 as described on jsf 2.0 spec chapter 10

          Show
          Leonardo Uribe added a comment - This issue is closed as won't fix, because no advance can be done from this point. To solve it we have to change the package convention to com.sun.facelets, and that is a bad idea. Note a workaround could be done to allow previous jsf 1.2 libs to work with jsf 2.0 as described on jsf 2.0 spec chapter 10
          Hide
          Ganesh Jung added a comment -

          reasons for reopning this where discussed on the dev list:

          +1 on that
          Go ahead and re-open it

          Sent from my iPod.

          On 12.02.2010, at 06:36, Ganesh <ganesh@j4fry.org> wrote:

          > Leo, can you please read this again? I thought we agreed on this being a MyFaces bug. IMHO te spec is clear and I don't agree on closing the issue.
          >
          > 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.
          > Can we please reopen the issue and fix it?
          >
          > Best regards,
          > Ganesh

          Show
          Ganesh Jung added a comment - reasons for reopning this where discussed on the dev list: +1 on that Go ahead and re-open it Sent from my iPod. On 12.02.2010, at 06:36, Ganesh <ganesh@j4fry.org> wrote: > Leo, can you please read this again? I thought we agreed on this being a MyFaces bug. IMHO te spec is clear and I don't agree on closing the issue. > > 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. > Can we please reopen the issue and fix it? > > Best regards, > Ganesh
          Hide
          Leonardo Uribe added a comment -

          Ok, I'll do comments for each part:

          > 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?"

          In other words, it says below are the criteria to define whether an application is compatible with facelets for jsf 2.0. Suppose you have an application/jsf component library working with facelets 1.1.x, so if you want to know if it is compatible or not with facelets for jsf 2.0 you have to ask this question first.

          > ■ 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.

          In other words it says if you have classes that uses com.sun.facelets package (read use as you have classes depending from), your application/jsf component library IS NOT compatible with facelets for jsf 2.0, but you can use the old facelets jars and register the old facelets view handler to keep using them as is. The other alternative is modify all clasess that uses com.sun.facelets and/or its sub-packages to the appropiate javax.faces.webapp.vdl counterpart. If you do that your application / jsf component library will work for jsf 2.0. The param is used to tell jsf please use the jsp view handler (JspViewHandlerImpl in myfaces case), because the other one introduced in jsf 2.0 (ViewHandlerImpl) could cause conflicts.

          Note that the only reason why an application / jsf component library could have a facelet taglib xml file is to reference classes that extends com.su.facelets package.

          > ■ 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.

          If this is true, your application/ jsf component library already works for facelets in JSF 2.0. You can use it directly without make changes, but again that means there is no facelet taglib xml files.

          > 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.

          True

          My answer is no, we can't reopen this one, but I'll let it open to hear if someone in jsr-314-open list has something to say about it

          Show
          Leonardo Uribe added a comment - Ok, I'll do comments for each part: > 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?" In other words, it says below are the criteria to define whether an application is compatible with facelets for jsf 2.0. Suppose you have an application/jsf component library working with facelets 1.1.x, so if you want to know if it is compatible or not with facelets for jsf 2.0 you have to ask this question first. > ■ 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. In other words it says if you have classes that uses com.sun.facelets package (read use as you have classes depending from), your application/jsf component library IS NOT compatible with facelets for jsf 2.0, but you can use the old facelets jars and register the old facelets view handler to keep using them as is. The other alternative is modify all clasess that uses com.sun.facelets and/or its sub-packages to the appropiate javax.faces.webapp.vdl counterpart. If you do that your application / jsf component library will work for jsf 2.0. The param is used to tell jsf please use the jsp view handler (JspViewHandlerImpl in myfaces case), because the other one introduced in jsf 2.0 (ViewHandlerImpl) could cause conflicts. Note that the only reason why an application / jsf component library could have a facelet taglib xml file is to reference classes that extends com.su.facelets package. > ■ 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. If this is true, your application/ jsf component library already works for facelets in JSF 2.0. You can use it directly without make changes, but again that means there is no facelet taglib xml files. > 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. True My answer is no, we can't reopen this one, but I'll let it open to hear if someone in jsr-314-open list has something to say about it
          Hide
          Jakob Korherr added a comment -

          I agree with Leonardo.

          Show
          Jakob Korherr added a comment - I agree with Leonardo.
          Hide
          Ganesh Jung added a comment -

          Did you take into account jars with a taglib.xml that are based only on xhtml templates? I bet 95% of all Facelets taglibs do this. An application can be using
          the jar that I uploaded with this issue. Did you check it? It doesn't extend any com.sun.facelets stuff. In fact, it doesn't use any Java classes at all... DojoFaces also is this kind of jar. It has an old style taglib.xml and it consists solely of xhtml templates. According to the spec it must work with a JSF 2.0 conform implemetation, but with MyFaces 2.0 beta 2 not even the taglib.xml will be accepted...

          Show
          Ganesh Jung added a comment - Did you take into account jars with a taglib.xml that are based only on xhtml templates? I bet 95% of all Facelets taglibs do this. An application can be using the jar that I uploaded with this issue. Did you check it? It doesn't extend any com.sun.facelets stuff. In fact, it doesn't use any Java classes at all... DojoFaces also is this kind of jar. It has an old style taglib.xml and it consists solely of xhtml templates. According to the spec it must work with a JSF 2.0 conform implemetation, but with MyFaces 2.0 beta 2 not even the taglib.xml will be accepted...
          Hide
          Matthias Weßendorf added a comment -

          Leo/Jakob:

          check the JAR before you comment...
          There is NO java class at all; just some taglib and XHTML

          this has to work..... Why?

          Here:
          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?"

          ==> NO (right?)

          From the spec:
          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.

          ==> should work. But it does not... why? Myfaces2 wants to see 2.0 gramma settings on taglib (which is wrong)
          The XSD restriction on the SPEC appendix is a bug.

          I am re-opening this ticket, for the given reasons.

          Show
          Matthias Weßendorf added a comment - Leo/Jakob: check the JAR before you comment... There is NO java class at all; just some taglib and XHTML this has to work..... Why? Here: 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?" ==> NO (right?) From the spec: 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. ==> should work. But it does not... why? Myfaces2 wants to see 2.0 gramma settings on taglib (which is wrong) The XSD restriction on the SPEC appendix is a bug. I am re-opening this ticket, for the given reasons.
          Hide
          Leonardo Uribe added a comment -

          That's another completely different use case. Ganesh, could you describe in more detailed and complete way what's your proposal about what a jsf implementation should do (not your particular use case, instead what jsf should do when it founds a facelets taglib file) and submit it to jsr-314-open list. It is not clear this specific use case from your comments. Probe of that is your last comment make clear your point of view.

          Note if that is true, the spec should say something about that. Also, RI behavior should be make clear first, because there are doubts about whether read facelets taglibs 1.1.x is a bug or not (I'm supposing right now it is a bug, but I don't know RI internals).

          Show
          Leonardo Uribe added a comment - That's another completely different use case. Ganesh, could you describe in more detailed and complete way what's your proposal about what a jsf implementation should do (not your particular use case, instead what jsf should do when it founds a facelets taglib file) and submit it to jsr-314-open list. It is not clear this specific use case from your comments. Probe of that is your last comment make clear your point of view. Note if that is true, the spec should say something about that. Also, RI behavior should be make clear first, because there are doubts about whether read facelets taglibs 1.1.x is a bug or not (I'm supposing right now it is a bug, but I don't know RI internals).
          Show
          Ganesh Jung added a comment - So, here's the spec issue: https://javaserverfaces-spec-public.dev.java.net/issues/show_bug.cgi?id=744
          Hide
          Matthias Weßendorf added a comment -

          Leo,

          the use-case it to be backwards compatible.
          I mean it should just work, if there are NO java dependencies
          on "old" facelets... Otherwise it would be extra pain for
          users.

          IMO: JSF did things not 100% correct in the past and people complained about it.
          If it would not support this scenario folks have good reasons to blame jsf again.

          Does that make sense?

          Show
          Matthias Weßendorf added a comment - Leo, the use-case it to be backwards compatible. I mean it should just work, if there are NO java dependencies on "old" facelets... Otherwise it would be extra pain for users. IMO: JSF did things not 100% correct in the past and people complained about it. If it would not support this scenario folks have good reasons to blame jsf again. Does that make sense?
          Hide
          Matthias Weßendorf added a comment -

          Removing fix Version, as there is no fix yet......

          Show
          Matthias Weßendorf added a comment - Removing fix Version, as there is no fix yet......
          Hide
          Leonardo Uribe added a comment -

          Thinking about it, maybe we should read facelets 1.1.x taglibs twice, the first one could be used to check if we can load it (no class references or java tag handlers) and the second time if the previous filter pass load it.

          In this way, if the user still wants to run it, the user could provide its own corrected taglib xml file to make the library run without make changes on its jars.

          Show
          Leonardo Uribe added a comment - Thinking about it, maybe we should read facelets 1.1.x taglibs twice, the first one could be used to check if we can load it (no class references or java tag handlers) and the second time if the previous filter pass load it. In this way, if the user still wants to run it, the user could provide its own corrected taglib xml file to make the library run without make changes on its jars.
          Hide
          Ganesh Jung added a comment -

          Now that the spec issue is solved here's my suggestion to treat this issue: MyFaces shouldn't make any distinction between http://java.sun.com/dtd/facelet-taglib_1_0.dtd taglibs and http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd taglibs.

          Trying to craft an algorithm that distinguishes between "good taglibs" and "bad taglibs" will unerringly fail in some cornercases. A jar may contain some com.sun.facelets classes or some java taghandlers, but the defined tags never use them. Or maybe the developer knows how to call the tags so that the legacy code doesn't run.

          Nobody will blame MyFaces for ClassNotFoundExceptions when stumbling onto a com.sun.facelets reference, but MyFaces will be blamed if fully functional taglibs don't run because of some heuristic jar scanning that MyFaces does at startup.

          Show
          Ganesh Jung added a comment - Now that the spec issue is solved here's my suggestion to treat this issue: MyFaces shouldn't make any distinction between http://java.sun.com/dtd/facelet-taglib_1_0.dtd taglibs and http://java.sun.com/xml/ns/javaee/web-facelettaglibrary_2_0.xsd taglibs. Trying to craft an algorithm that distinguishes between "good taglibs" and "bad taglibs" will unerringly fail in some cornercases. A jar may contain some com.sun.facelets classes or some java taghandlers, but the defined tags never use them. Or maybe the developer knows how to call the tags so that the legacy code doesn't run. Nobody will blame MyFaces for ClassNotFoundExceptions when stumbling onto a com.sun.facelets reference, but MyFaces will be blamed if fully functional taglibs don't run because of some heuristic jar scanning that MyFaces does at startup.
          Hide
          Jakob Korherr added a comment -

          OK that's a good solution, Ganesh. I think we should do this!

          Show
          Jakob Korherr added a comment - OK that's a good solution, Ganesh. I think we should do this!
          Hide
          Jakob Korherr added a comment -

          I committed a solution for this (I just removed the version check). However the EG is currently working on how to solve this scenario in the right way, so I'll leave the JIRA issue open.

          Show
          Jakob Korherr added a comment - I committed a solution for this (I just removed the version check). However the EG is currently working on how to solve this scenario in the right way, so I'll leave the JIRA issue open.
          Hide
          Jakob Korherr added a comment -

          Resolved: See the discussion on the dev-mailing list ([Facelets] deploying "old" Facelets templates with MyFaces 2) for details.

          Show
          Jakob Korherr added a comment - Resolved: See the discussion on the dev-mailing list ( [Facelets] deploying "old" Facelets templates with MyFaces 2) for details.

            People

            • Assignee:
              Jakob Korherr
              Reporter:
              Ganesh Jung
            • Votes:
              0 Vote for this issue
              Watchers:
              1 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development