Home

News: Tapestry 4.1.2 / OGNL 2.7 Released

  1. Tapestry 4.1.2 / OGNL 2.7 Released (23 messages)

    I am both happy and proud to announce the release of Tapestry 4.1.2 and OGNL 2.7. The official change list can be found both here (Tapestry) and here (OGNL). There has been such an immense amount of work put in to both of these releases that it doesn’t do them justice to just link to a simple jira change list: * Performance - The biggest reason for the delay in this release of Tapestry has been in waiting for the new OGNL bytecode compiler enhancements to stabilize. None of this would have been possible without the kind support / dedication of resources by Patrick Lightbody of OpenSymphony/WebWork/Struts2/Selenium/others I don’t know about. Thanks Patrick! The actual performance boost when using this new OGNL version for existing Tapestry 4 users will be like night and day. The numbers are roughly available in the previous post on the subject - but you are looking at something around 6 times faster than the old interpreted mode was capable of doing. * Memory consumption / More Performance - The ever consuming obsession that has become YourKit has done almost as much for performance and memory consumption that the OGNL bytecode enhancements have. Development mode issues with running out of jvm memory have been eliminated completely - as well as a number of unneccessary memory consumers in various internal portions of the framework. Page/component instances are now pooled by a much more robust / configurable pool implementation that finally allows idle pages / components to be discarded from the pool - thus reclaiming valuable heap space in production applications at non peak times. As for the performance improvements, well - let me just say that if you have used YourKit before then you’ll know what “the only hot spots left are in the servlet container itself” means. It’s damn fast, ok? :) * Testing - A common complaint in the past is that the framework hasn’t really been very giving in sharing how it tests components/pages internally. Obviously people like to test things these days so it makes sense to help with that. We’ve refactored things/moved code around some and now have a new tapestry-test library that you can use to help test your Tapestry applications here: http://tapestry.apache.org/tapestry4.1/tapestry-test/index.html . * Asset caching - What we feel constitutes one of the higher quality image/javascript/resource caching systems available for standard out of the box servlet apps - (even rivaling some servlet containers in many instances) - is also now available. The details of why/how that came about can be read about here. These enhacements do all kinds of nice things for your assets for you automatically - such as gzipping javascript and css resources as well as handling Etag header fields and similar logic - all while appropriately handling all of the various inevitable browser version quirks that constitute the bain of every web developers existence.. * Google rounded corners / drop shadow image services - Since we know many of you will only be lured by shiny baubles (myself included) - we have added a little something extra to entice you with via the very robust image generation services. The drop shadow work is due completely to the previous efforts and subtle pointers in the right direction from Romain Guy. * Documentation - We know people haven’t been very happy about this aspect of things in the past. A number of big changes have slowly been happening in this area - the biggest being a great new series of tutorials covering almost all of the common issues you’ll run across in Tapestry 4 development by Alexander Kolesnikov. They can be found here. Many updates/additions/improvements have been made to the overall documentation effort of Tapestry 4 as well whenever we have found any obvious holes. What’s even better than documentation though? Not needing it to begin with. While we have spent a great deal of time updating and adding to the documentation we have also spent a lot of time improving the framework in general and eliminating any obvious quirks that might have previously lead people to wanting more documentation to begin with. We think you’ll find that a lot more of your typical every day tasks will really “just work” as expected. * Dojo and Prototype/Scriptaculous integration - The bundled version of Dojo provided by Tapestry has been upgraded to the latest 0.4.3 version. (ok, the latest is technically 0.9 but first things first..) This has allowed us to not only get all of the great bug fixes / improvements made by the team but also to take advantage of the new layered build system developed by James Burke of AOL. The layered build system has increased the speed of the overall page load time of any given page substantially and we are very happy/thankful for his awesome work in this area. This version also features integration of the latest versions of Prototype/Script.aculo.us libraries and the requisite component that uses them which has been named “Suggest“. * Ajax / JSON Support - Second only to the performance improvements has been the amount of work put in to refining and improving the Tapestry AJAX/JSON support. Client side profiling / performance improvements have overall also been substantially improved. New documentation has been added covering various key areas of this portion of the API as well as some new naturaldocs generated apidocs for our client side javascript library. I don’t feel bad in saying that Tapestry 4.1.2 probably represents one of the most robust java web framework libraries available for AJAX applications in the open source java world today. We’ve been doing this for a really long time now and kind of have this area covered. Show me something that does as much as Tapestry does while also being flexible / debuggable enough to allow you to easily branch off and do things your own way and I’ll concede defeat. Until then….it’s well worth checking out if you haven’t tried this particular side of Tapestry yet. Message was edited by: joeo@enigmastation.com

    Threaded Messages (23)

  2. Kudos to you and the whole Tapestry team, this is a great release. Thanks Jesse.
  3. ognl.org?[ Go to top ]

    Is the OGNL.org site going to be updated with the 2.7 download, or is that site no longer maintained? Congrats to all the folks involved!
  4. Re: ognl.org?[ Go to top ]

    Hi, nice release. where can I find ognl 2.7 for download? regards, Ricardo
  5. where to get ognl...[ Go to top ]

    Sorry about the status of actual download links and such for ognl. Patrick sent me an email with information related to the opensymphony.com side of ognl which I plan on taking a stab at this weekend to see what I can do about some enhanced documentation for the new compiler interface classes. In the meantime....You can download the new version from http://mirrors.ibiblio.org/pub/mirrors/maven2/ognl/ognl/2.7/ - but besides a few bug fixes and annoyances being changed you won't get the new compiler functionality with a drop in replacement. That logic has new special method calls you must make explicitly. (such as Ognl.compileExpression() )
  6. Re: where to get ognl...[ Go to top ]

    you won't get the new compiler functionality with a drop in replacement. That logic has new special method calls you must make explicitly. (such as Ognl.compileExpression() )
    Your comment seems to indicate that one would need to invoke Ognl.compileExpression() now all over the place and not sure how this will be done from an HTML page. I assume there is clear documentation on how to compile all my current OGNL expressions in HTML pages in one easy swoop preferrably with one or two calls to configure or invoke Ognl.compileExpression().
  7. Re: where to get ognl...[ Go to top ]

    you won't get the new compiler functionality with a drop in replacement. That logic has new special method calls you must make explicitly. (such as Ognl.compileExpression() )


    Your comment seems to indicate that one would need to invoke Ognl.compileExpression() now all over the place and not sure how this will be done from an HTML page.

    I assume there is clear documentation on how to compile all my current OGNL expressions in HTML pages in one easy swoop preferrably with one or two calls to configure or invoke Ognl.compileExpression().
    Come on, take a breather, use some common sense. There's a big difference between coding to the OGNL API and using OGNL expressions inside Tapestry pages; of COURSE the Tapestry code is compiling the expressions, I hardly think Jesse would put months of effort into something that wouldn't actually get used!
  8. Re: where to get ognl...[ Go to top ]

    Come on, take a breather, use some common sense. Of COURSE the Tapestry code is compiling the expressions, I hardly think Jesse would put months of effort into something that wouldn't actually get used!
    ouch..take it easy.. My assumptions were inline until I read Jesse's quote: "you won't get the new compiler functionality with a drop in replacement. That logic has new special method calls you must make explicitly. (such as Ognl.compileExpression() )".
  9. Re: where to get ognl...[ Go to top ]

    I'm not sure what you mean. Obviously HTML doesn't have support for OGNL expressions so I'm assuming you are using a framework of some kind. In Tapestry the point where OGNL expressions are evaluated is centralized as one simple service. So...It's only one place in Tapestry. Wherever you do it is up to you.
    you won't get the new compiler functionality with a drop in replacement. That logic has new special method calls you must make explicitly. (such as Ognl.compileExpression() )


    Your comment seems to indicate that one would need to invoke Ognl.compileExpression() now all over the place and not sure how this will be done from an HTML page.

    I assume there is clear documentation on how to compile all my current OGNL expressions in HTML pages in one easy swoop preferrably with one or two calls to configure or invoke Ognl.compileExpression().
  10. Re: Tapestry 4.1.2 / OGNL 2.7 Released[ Go to top ]

    Well this is welcome news although frustrated by the uncertainty caused by the emergence of Tapestry 5 which may be a tough migration from 4. We are already looking as a move to JSF we had weathered the storm caused by the change from tapestry 3 to 4, now to suggest that, again backwards compatibility is compromised is to ask for trouble. Tapestry is fun but if Howard and gang were to accelerate work on the next version of JSF and provide a united front just maybe it will save java web development from the distraction that is rails :-) Congratulations on the fixes and changes on version 4 but still in dilemma as to whether wait for Tapestry 5 or move on.
  11. Re: Tapestry 4.1.2 / OGNL 2.7 Released[ Go to top ]

    I think everyone that is having the T4/T5 question should find the following interesting reading: http://jroller.com/page/WarnerOnstine?entry=tapestry_future_adoption_redux
  12. My congratulations! Great job, guys.
  13. Great Framework[ Go to top ]

    Congratulations to the whole Tapestry team for making such a great framework, Keep the good work guys.
  14. Jesse, Great release notice, that's a ton of stuff going on in 4.1. I'm thrilled that there's so much going on in the Tapestry world, both all the T4 development, and all the outside libraries and applications (such as Tacos and Trails) that I literally can't keep up with it all!
  15. Greate news.[ Go to top ]

    Great job guys.
  16. thanks[ Go to top ]

    Thanks for all the encouraging words everyone. ~All~ of the Tapestry developers/community worked very hard on this release so it's gratifying(relieving) seeing some of it come to an end finally.
  17. where can i get the OGNL 2.7?[ Go to top ]

    the ognl.org does not provide the download link for this version. so does anybody know where can i download it? Thanks!
  18. performance for concurrent case![ Go to top ]

    public static Class[] getParameterTypes(Method m) { synchronized (_methodParameterTypesCache) { Class[] result; if ((result = (Class[]) _methodParameterTypesCache.get(m)) == null) { _methodParameterTypesCache.put(m, result = m.getParameterTypes()); } return result; } } There are so many method synchronized the cache object like above code; it's not good for the concurrent invocations. And I have done a test for this and find out that OGNL is the performance bottleneck when multiple thread invocation case. So any idea or solution for improving the performance in concurrent case? Thanks!
  19. OGNL performance in concurrent case![ Go to top ]

    And i found out that most the caches or pools are only used to read (only), that means the return value will not be changed or modified and the removed from the cache; so can we do like this: Object o = getFromCache(key); if(o == null) { synchronized(cache) { if((o=getFromCache(key)) == null) { o = getRealObject(); putObjectIntoCache(key, o); } } } return o;
  20. I think all of that is interesting but mostly irrelevant in the new bytecode compiled version. It literally takes your OGNL expression and converts it into the native equivalent of what you would do to get the same expression by manual java code. ie: "property.value[4]" gets turned in to: "getProperty().getValue(4)" There is no bottleneck in anything related OGNL when you use compiled expressions.
    And i found out that most the caches or pools are only used to read (only), that means the return value will not be changed or modified and the removed from the cache; so can we do like this:

    Object o = getFromCache(key);
    if(o == null)
    {
    synchronized(cache)
    {
    if((o=getFromCache(key)) == null)
    {
    o = getRealObject();
    putObjectIntoCache(key, o);
    }
    }
    }

    return o;
  21. I did not get your point for this "There is no bottleneck in anything related OGNL when you use compiled expressions." And I did not find out any thing about the concurrrent case from your comments. If the OGNL has the code for synchronized block, then it should result the signal competed issues, right? so we always try to reduse the synchronized code in one system. Can you give more comments on this? Thanks!
    I think all of that is interesting but mostly irrelevant in the new bytecode compiled version.

    It literally takes your OGNL expression and converts it into the native equivalent of what you would do to get the same expression by manual java code.

    ie:

    "property.value[4]"

    gets turned in to:

    "getProperty().getValue(4)"

    There is no bottleneck in anything related OGNL when you use compiled expressions.

    And i found out that most the caches or pools are only used to read (only), that means the return value will not be changed or modified and the removed from the cache; so can we do like this:

    Object o = getFromCache(key);
    if(o == null)
    {
    synchronized(cache)
    {
    if((o=getFromCache(key)) == null)
    {
    o = getRealObject();
    putObjectIntoCache(key, o);
    }
    }
    }

    return o;
  22. It's in my reply. Read it again. sheeesh.....
    I did not get your point for this "There is no bottleneck in anything related OGNL when you use compiled expressions."
  23. What you are missing is that, in most cases, the OGNL expression is converted into a kind of "shim" that performs the equivalent operation in bytecode, as if a hand-tooled class had been written. Inside the shim, it's pure method invocatations, no synchronization, no reflection, etc. The shim will eventually be optimized by hotspot, just like any other Java code. Once the shim exists, the other paths through OGNL code become irrelevant, they are no longer executed. This is a technique used in a number of open source projects, though not even Tapestry 5 does it as aggressively as what Jesse has accomplished here.
  24. Congratulations, great job.