On 1/24/07, James Watkin <[EMAIL PROTECTED]> wrote:
Craig, Thank you for your time, information, and openness. I'd also like to pass along a link to a video interview of Ed Burns that I watched today: http://w.on24.com/r.htm?e=25412&s=1&k=1C3610AF899E09A2EFD26F0FD6B7875E&partnerref=atssc_sitepost_01_16_07 In this interview, Ed Burns talked about JSF frameworks like Apache Shale and how the next version of the JSF spec will leverage ideas from them. Some specific features mentioned for the next (2.0?) JSF spec were conversation scope, additional core components, state management, and some sort of AJAX support. In a reference to Apache Shale, Ed Burns said, "...they (Apache Shale) have a remoting package that provides the ability to facilitate AJAX by invoking method bindings in the server but it turns out there are some security issues with that, but I think they'll be addressed." I don't know how old this interview is. Can you explain what he's referring to and whether or not it was addressed?
Yes, it was an old issue (the interview was recorded a while ago), and yes it has been addressed in the 1.0.4 release. The issue related to the way that the "dynamic" processor mapped a request URL to a method binding that could call any public method on a managed bean that has zero parameters. In other words, a URL like: http://localhost:8080/myapp/dynamic/foo/bar.faces (assumes you are using *.faces mapping for FacesServlet) would cause a method binding expression "#{foo.bar}" to be constructed, and therefore the "bar" method would be called. The challenge is that you might have public zero-args methods in your managed beans that are not designed to be executed directly from a client call like that, and gives clients an opportunity to disrupt your application. Today, the fix for this is a set of context init parameters that can be used to limit what URL patterns are allowed or disallowed for this processor (as well as the ones that serve static resources) to serve. It will return "not allowed" HTTP errors if you attempt to use a prohibited URL pattern. The gory details of configuring this are in the package summary Javadocs[1]. In the future, when we can move to an assumption of Java SE 5 as the baseline (or successfully demonstrate that retro-weaved JARs can run on 1.4systems), we'll be able to use annotations to explicitly identify the public methods that you want to make accessible to the dynamic processor. That's a lot more fine grained and easily understood than having to remember to update URL patterns in context init parameters. - Jim Craig Craig McClanahan wrote:
> On 1/23/07, James Watkin <[EMAIL PROTECTED]> wrote: >> >> I'm looking for a new web application framework. From attending various >> conferences and selected readings, it appears that a framework which >> supports JSF and AJAX is probably what we're looking for. >> >> Again, based solely on conferences and selected readings, the following >> frameworks appear to have merit: >> >> * Apache Shale or JBoss Seam for a high-end code-centric framework. >> http://shale.apache.org/ >> http://www.jboss.com/products/seam >> >> * ICEfaces for superior JSF/AJAX integration. >> http://www.devx.com/security/Article/33533 >> http://www.icesoft.com/products/icefaces.html >> >> http://theserversidecom.bitpipe.com/detail/RES/1163445089_619.html?src=wc_atssc_sitepost_11_14_06 >> >> >> * NetBeans Visual Web Pack (or Sun Java Studio Creator) for rapid >> development. >> http://www.netbeans.org/products/visualweb/ >> http://developers.sun.com/prodtech/javatools/jscreator/index.jsp >> >> * Spring Web Flow combined with JSF? >> http://opensource.atlassian.com/confluence/spring/display/WEBFLOW/Home > > > You might want to add one more category of things to look at ... JSF-based > libraries that enable the use of non-Ajax-aware JSF components in an Ajax > environment (partial page submit, partial page refresh). Two libraries at > java.net that do this kind of thing: > > * https://ajax4jsf.dev.java.net/ > > * https://jsf-extensions.dev.java.net/ > > I notice that JBoss Seam appears to have support for ICEfaces. Does >> Apache Shale plan to do the same? If not, why not, and does Apache Shale >> have some other plan to support AJAX, and what will be the benefit of >> that other approach? > > > You will see two "attitudes" in Shale towards this issue: > > * Shale does not contain any components itself ... it is designed to add > value > on the server side while working with *any* component library. Therefore, > in principle, it should work with any of the JSF-Ajax component libraries > that > you like. That being said, if there are compelling advantages to be > gained by > an explicit integration layer for particular libraries, we will certainly > look at that. > But, in the particular case of ICEFaces, there shouldn't be anything > required > other than just putting all the right libraries together. > > * For the particular use case of a client side application that wants to do > asynchronous callbacks *without* updating the JSF component state (perhaps > because the server side application is not based on JSF components), the > Shale Remoting library provides facilities for doing that sort of thing > directly. > > Since my only hands-on web development experience is with Struts, I'm >> looking for a discussion of these JSF/AJAX frameworks by those that have >> actual experience using them. >> >> If you're qualified, could you please share your experiences, assess >> these frameworks (or others I have omitted), and while you're at it, >> predict their futures? > > > As if you did not have enough to read :-), one other item to keep track of > is the "Web Beans" JSR (http://jcp.org/en/jsr/detail?id=299). This is an > attempt (just getting started) to standardize the relationships between the > JSF and EJB3/JPA component models, using Seam as a model of what might be > possible (plus contributions from other frameworks, of course). > > Thank you. >> >> - Jim > > > Craig > -- ______________________________ James Watkin ACIS Software Development UCLA Anderson School [EMAIL PROTECTED] Voice: 1-310-825-5030 Fax: 1-310-825-4835 ______________________________
