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

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

    Re: Rather old MyFaces version in Liberty 8.5.5

    ‏2013-06-15T13:51:30Z  

    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

    Re: Rather old MyFaces version in Liberty 8.5.5

    ‏2013-06-15T22:00:44Z  

    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.

    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

    Re: Rather old MyFaces version in Liberty 8.5.5

    ‏2013-06-16T22:45:48Z  

    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.

     

     

     

     

    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

    Re: Rather old MyFaces version in Liberty 8.5.5

    ‏2013-06-16T22:48:40Z  

    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.

     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

    Re: Rather old MyFaces version in Liberty 8.5.5

    ‏2013-06-16T23:10:50Z  

     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.

    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

    Re: Rather old MyFaces version in Liberty 8.5.5

    ‏2013-07-01T09:24:38Z  

    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)

    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

    Re: Rather old MyFaces version in Liberty 8.5.5

    ‏2013-09-18T17:05:25Z  

    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)

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

     

  • javapapo
    javapapo
    6 Posts

    Re: Rather old MyFaces version in Liberty 8.5.5

    ‏2013-10-30T11:27:38Z  

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

     

    It is at least unfortunate ...the whole thing MyFaces 2.0.5 + ibm specific ..please vote

    http://www.ibm.com/developerworks/rfe/execute?use_case=viewRfe&CR_ID=41002