Topic
8 replies Latest Post - ‏2013-10-30T11:27:38Z by javapapo
arjantijms
arjantijms
5 Posts
ACCEPTED ANSWER

Pinned topic Rather old MyFaces version in Liberty 8.5.5

‏2013-06-15T12:39:40Z |

I did some testing with WebSphere Liberty 8.5.5, and if I'm not mistaken it looks like it bundles MyFaces 2.0.3 or 2.0.4. The 2.0.3 implementation is from 13 December 2010 and contains quite a few bugs and performance issues.

Why does Liberty bundle such a rather old version?

Edit: I found this message saying it bundles 2.0.5: https://www.ibm.com/developerworks/community/forums/html/topic?id=2010a28b-37ef-44b6-aa3b-3a4f9f2095fa&ps=25

I couldn't however find the key "org.apache.myfaces.FLASH_SCOPE_DISABLED" in META-INF / myfaces-metadata.xml, which was introduced in MyFaces 2.0.5. At any length, 2.0.5 is from 5 April 2011 which is still rather old.

Why not bundle a relative recent version from the 2.1.x series and support JSF 2.1 at the API level instead of 2.0? Nearly all other app servers (JBoss, GlassFish, WebLogic, TomEE, etc do that as well).

 

  • Eric Covener
    Eric Covener
    16 Posts
    ACCEPTED ANSWER

    Re: Rather old MyFaces version in Liberty 8.5.5

    ‏2013-06-15T13:51:30Z  in response to arjantijms

    It's common to both profiles, and a wholesale rebase simply has not made the cut priority wise.     it's still serviced as normal, so If you're experiencing specific problems, you should submit a PMR.

    • arjantijms
      arjantijms
      5 Posts
      ACCEPTED ANSWER

      Re: Rather old MyFaces version in Liberty 8.5.5

      ‏2013-06-15T22:00:44Z  in response to Eric Covener

      Thanks for the reply. The problems are as mentioned the long list of bugs that was fixed between MyFaces 2.0.5 and the current version, as well as the major performance improvements that were done.

      To give some impression; for the "world wide wait" benchmark, rates MyFaces as the most expensive one to scale: See http://blog.websitesframeworks.com/2013/03/web-frameworks-benchmarks-192

      Specifically, MyFaces was much slower than Mojarra. However, in later releases this was the other way around. See http://blog.oio.de/2013/04/08/jsf-comparison-myfaces-vs-mojarra

      MyFaces has seen some major performance increases between those two benchmarks, for instance those done for 2.0.13 following this issue: https://issues.apache.org/jira/browse/MYFACES-3474

      Another very specific problem is that MyFaces 2.0.x misses the extremely important spec update that was done in the 2.1 MR, namely the addition of the ViewHandler#deriveLogicalViewId method: http://docs.oracle.com/javaee/6/api/javax/faces/application/ViewHandler.html#deriveLogicalViewId(javax.faces.context.FacesContext,%20java.lang.String) and the ViewDeclarationLanguage.viewExists method: http://docs.oracle.com/javaee/6/api/javax/faces/view/ViewDeclarationLanguage.html#viewExists%28javax.faces.context.FacesContext,%20java.lang.String%29

      Without that method very few Facelets resource resolvers work correctly as the contract in 2.0 was very unclear, see e.g. https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-809

      For instance, the FacesViews extensionless URL feature from OmniFaces doesn't work without it.

       

       

       

       

      • Eric Covener
        Eric Covener
        16 Posts
        ACCEPTED ANSWER

        Re: Rather old MyFaces version in Liberty 8.5.5

        ‏2013-06-16T22:45:48Z  in response to arjantijms

        There are a few myfaces/jsf upgrade enhancements request in the RFE tool. I suggest voting for them:

        https://www.ibm.com/developerworks/rfe/

        And I'd re-iterate that if there are specific bugs or acute performance improvements that are impacting you, you should request them via a PMR.  

    • arjantijms
      arjantijms
      5 Posts
      ACCEPTED ANSWER

      Re: Rather old MyFaces version in Liberty 8.5.5

      ‏2013-06-16T22:48:40Z  in response to Eric Covener

       it's still serviced as normal, so If you're experiencing specific problems, you should submit a PMR.

      I encountered more than a few specific problems, but they're all well known early MyFaces bugs, such as the fact that an h:link propagates the conversation ID (cid) parameter when a CDI conversation is active (it shouldn't do this), and a very nasty bug where injection of @ManagedProperty is done AFTER an @PostConstruct method is executed (it should happen BEFORE).

      Do you mean I should submit a PMR for every MyFaces bug, or just a general PMR asking MyFaces to be updated to a relatively recent version (e.g. not more than say 1 year old).

      Submitting a PMR for every MyFaces bug might not make a lot of sense, there are literally dozens of them and it would not make sense for IBM to fix all of these in MyFaces 2.0.5 since they have already been fixed in one of the 22 releases that came after 2.0.5.

      Please advise and sorry for the trouble.

      • Eric Covener
        Eric Covener
        16 Posts
        ACCEPTED ANSWER

        Re: Rather old MyFaces version in Liberty 8.5.5

        ‏2013-06-16T23:10:50Z  in response to arjantijms

        I'd suggest opening a PMR for each issue that impacts you that you're willing to provide trace and verify a fix on.  

        As someone who works on other Apache-based components and can be paged out at any time, from a change management perspective backporting individual fixes is much simpler than a wholesale re-base in the service stream.  

         

        (Please vote for the RFE's if you feel strongly about the importance of the wholesale update)

        • arjantijms
          arjantijms
          5 Posts
          ACCEPTED ANSWER

          Re: Rather old MyFaces version in Liberty 8.5.5

          ‏2013-07-01T09:24:38Z  in response to Eric Covener

          I'll vote for the wholesale update then, thanks for the pointers!

          After some investigation it appeared that I would have to create a few dozen of PMRs really. It's nearly every bug that was ever fixed by MyFaces that's troublesome.

          Thanks again! 

        • arjantijms
          arjantijms
          5 Posts
          ACCEPTED ANSWER

          Re: Rather old MyFaces version in Liberty 8.5.5

          ‏2013-09-18T17:05:25Z  in response to Eric Covener

          Btw, just liked to mention that over at OmniFaces we have again found a blocking issue with Liberty 8.5.5 that has been traced back to the old version of MyFaces that Liberty bundles.

          It took as some time to trace this, as there is no other server out there that uses a version of MyFaces that is so old. Even the first versions of TomEE (which also uses MyFaces) came with a more recent MyFaces.

          See https://code.google.com/p/omnifaces/issues/detail?id=183#c56 for details.

          I would again like to point out that for a modern, lightweight and developer focussed project like Liberty it's really off putting to bundle ancient dependencies that subsequently can't be upgraded manually either (this is surely something that developers don't like).

          If in anyway possible, please consider increasing the priority of this wholesale rebase. Even better would be btw to go for a simpler bundling and using the MyFaces SPI instead of modifying MyFaces, so updating becomes much simpler for both users to do themselves and for IBM as well (no more "rebasing", just update and test).