tag:blogger.com,1999:blog-427258967255390991.post5508839199115674692..comments2024-03-01T16:24:46.081+08:00Comments on The Tech Faucet: JavaServer Faces (JSF2) and JAX-RS don't play well togetherCraig Ringerhttp://www.blogger.com/profile/02343803844223399065noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-427258967255390991.post-56209296974029077882011-07-21T09:23:56.969+08:002011-07-21T09:23:56.969+08:00First: please accept my apology for my choice of w...First: please accept my apology for my choice of wording re the spec. I wrote this when I was <i>extremely</i> frustrated while learning JSF2 in an EE6 environment and tripping over a fair few bugs in the process, so I wasn't being as diplomatic as I could be. It was rude and I apologize.<br /><br />I do stand by my opinion that the JSF2 spec is significantly less readable than most of the other specs referenced under the EE 6 umbrella, and is much less useful for the "end developer" who is trying to work with the specified technology. I realize that its primary purpose is to be a precise and detailed specification, not a how-to document, and that the most important target audience are those creating implementations of the spec. Nonetheless, many of the other EE specs serve as a useful reference for when other resources are insufficient. The JPA 2.0 and CDI specs are two examples of specifications that're extremely useful as references and quite readable.<br /><br />I have tried, and do use, a couple of books on EE 6. That said, when I was getting started with EE 6 there was very little out there and much of that wasn't available in Australia. In any case, most of the books on the market focus on particular technologies within EE 6 and often don't spend much time on how they can be used together to satisfy needs that one alone does not.<br /><br />As for the issue of abstraction: I agree, you ideally shouldn't need to get access to the HttpServletRequest, and that when you do need to mess with it a servlet filter is usually the right place to do it. Ideally. In practice, sometimes a high level abstraction is the right answer for 95% of what you're doing, but when you need to get the other 5% done you run into trouble and have to step outside the abstraction. <br /><br />In this case the issue had more to do with my ignorance and less to do with the abstraction. I should've just written a servlet filter that exposed the information I needed.<br /><br />In this case, I needed access to a context parameter from the EE environment. In retrospect I should've used a JNDI environment parameter instead. What I landed up doing in this case was using the preferences API and a setup web page to store the app installation info required instead of getting it from the container.<br /><br />As for the users list: Having stuck my foot firmly in my mouth, I think I'll have to do just that.<br /><br />Thanks again for reviewing my comments. I realize I've been far from diplomatic in places and that I show my ignorance in more than a few of those places. Perhaps that in its self will be informative, because it's a window into the learning process and experience for someone approaching EE 6 cold, and may help show some of the areas that're harder to grasp than someone already familiar with them would expect.Craig Ringerhttps://www.blogger.com/profile/02343803844223399065noreply@blogger.comtag:blogger.com,1999:blog-427258967255390991.post-75173121662200072732011-07-20T04:48:45.628+08:002011-07-20T04:48:45.628+08:00CR> First, the JSF2 documentation (and writing ...CR> First, the JSF2 documentation (and writing of the JSF2 spec) is<br />CR> horrific. One often lands up stumbling through Google-land trying to<br />CR> find out details that should be obvious and easy to find in the spec<br />CR> or other documentation.<br /><br />Have you looked at any of the books on the topic? As the editor of the<br />spec, I apologize for not meeting your desired quality requirements. I<br />must point out that the spec is written to specify the implementation,<br />not how to use it. <br /><br />CR> Second, the JSF2 spec was clearly concocted with no thought of or<br />CR> co-operation with the JAX-RS spec, and it shows.<br /><br />You are correct here. Since the first release of the spec in 2004, we<br />have not excerted any effort to simplify the use of these two<br />technologies together. I am happy to report that we are working toward<br />this during the run of JAX-RS 2.0 and JSF 2.2.<br /><br />CR> if your method needs access to the HttpServletRequest<br /><br />...I assert that the method is not operating at a level of abstraction<br />which JSF is designed to facilitate. In JSF, all access to the request<br />is encapsulated within UI components. It is the components that<br />interface with the HttpServletRequest. Your code interacts with the<br />components, not the name/value pairs of HTTP directly. Now, I<br />understand there are many times when you really just want the darn<br />name/value pair, but in that case, JAX-RS is a better fit.<br /><br />That said, there is more we can do to make these technologies work well<br />together. For example, Facelets is a very useful page templating<br />technology in its own right, even using only the ,<br />, and tags. I hope that we can make it possible<br />to use these tags from JAX-RS generated UIs.<br /><br />There are other ideas in this vein as well.<br /><br />I would welcome your input on the<br />users@javaserverfaces-spec-public.java.net mailing list. Perhaps you<br />can help us improve the quality of the spec document.<br /><br />Sincerely,<br /><br />Ed Burns<br />JSF spec editoredburnshttps://www.blogger.com/profile/14048196581438285965noreply@blogger.com