Discussions

News: What should be in the Java EE 6 Web Profile?

  1. What should be in the Java EE 6 Web Profile? (17 messages)

    In response to Roberto Chinnici's blog entry discussing the options before the Java EE 6 Expert Group regarding the Web Profile, Chris Adamson has put up a poll on java.net to gauge the public's opinions. While the results are nowhere near scientific -- and even less binding -- it is an interesting exercise, so head over and vote. More importantly, if you have an opinion, find someone on the EG and let your voice be heard! [Editor's note: at the time of posting, there're only fifty-one votes. Let's all chime in and see what comes out.]
  2. Web Profile?[ Go to top ]

    Maybe someone could chime in and explain what a web profile is... I saw the original poll, but couldn't find an explanation. Any help?
  3. Re: Web Profile?[ Go to top ]

    Maybe someone could chime in and explain what a web profile is... I saw the original poll, but couldn't find an explanation. Any help?
    The posting has a link to the TSS entry explaining Roberto Chinicci's blog post in some detail. A web profile is basically a subset of the specification, so the "web profile" is a collection of APIs focused solely on web apps. This means that Tomcat or Jetty could be considered valid Java EE containers - under the "web profile" instead of the "full profile."
  4. Re: Web Profile?[ Go to top ]

    Current poll update. http://today.java.net/pub/pq/198 If I'm reading this correctly, 53% don't want either profiles in any shape or form, or JSF or WebBeans in that profile if one was defined.
  5. Good to see that so far, the "I'm not interested" answer is getting a good number of votes. (24% so far) I would have thought that the Web Profiles JSR would be better if it defined how a profile could be stored, but didn't actually specify what it was. It would be interesting to hear the Apache Geronimo crowd chime in at this point. Their maven-like repository seems (from my Geronimo-newb point of view) like a mechanism for storing profiles -- where you don't have to bundle every single .jar with your web app, but can rely on Geronimo to store multiple versions of jars. I'm happy to vote for anything which leads to the demise of JSF and Struts.
  6. I honestly doubt voting will get us rid of JSF or Struts ;-) But seriously - is there really the need for profiles at all? As it is right now the defacto standard is to use Tomcat plus insert libraries of choice if you don't need EJB's and the like, else you go for a full blown stack like JBoss, Glassfish or Geronimo. Even if the difference between profiles may be up to 100 MB of disc space - space and bandwidth to download is cheap nowadays. The only point I really see is startup time (ok, how often do we have to start an app server in production?) and - thats the real valid point to me - resource consumption for libraries not really needed. From the profiles Roberto listed in his blog my guess is that people will either use A (Servlet 3.0, JSP 2.2, JSR-45, EL 1.2, JSTL 1.2, JSR-250) or the full stack - which is just what we use today ... Standardization is a good thing, lets hope this one wont make things more complicated than they need to be. Markus Plesser [fleXive] core developer http://www.flexive.org -- UCS - unique computing solutions gmbh http://www.ucs.at
  7. I'm happy to vote for anything which leads to the demise of JSF and Struts.
    So what's the beef with JSF? And regardless of what happens with this profile, it won't affect JSF's inclusion in the EE spec, and in no way affects Struts, as it's not even part of the JCP.
  8. I'm happy to vote for anything which leads to the demise of JSF and Struts.

    So what's the beef with JSF? And regardless of what happens with this profile, it won't affect JSF's inclusion in the EE spec, and in no way affects Struts, as it's not even part of the JCP.
    Spring Webflow (SWF) for my 2c is better than JSF and Struts. Other people will have their favourites too. - SWF has a rich navigation instead of a naive navigation model. I know JSF is integrated with SWF, but SWF + sitemesh + jQuery seems to do the job nicely without JSF. - SWF supports the Post-Redirect-Get pattern out of the box, i.e. not forward-based. - View technology isn't baked in to SWF, logical view names are used. - There is the notion of a conversation in SWF, and additional useful scopes, incl. request, flow, conversation, session, flash (survives redirect) - Each flow is *easily* unit testable, i.e. the logic of handling events and transitioning to new states. I see web profiles as misguided, and would prefer to: 1. Use a geronimo-like mechanism to allow profiles to be stored. 2. Let natural selection determine what the most popular 'profile' is. If JSF, etc, can survive on their merits without being forced down our throats then so be it.
  9. JSF needs a lot of work in itself, but if you add in Facelets along with Seam (the navigation, scoping and dependency bijection) then you have a really great framework (but with a steep, steep learning curve). JSF 2.0 looks to be absorbing some of these features from facelets and seam.
  10. Spring Webflow (SWF) for my 2c is better than JSF and Struts. Other people will have their favourites too.
    Fair enough. You like another framework better. That's fine, I guess, though I obviously disagree with your conclusion. :) To be pedantic, though, whether you realize it or not, you ARE using Java EE, since you are writing a Java web app. That being so, are you currently being forced to use JSF (it has been included since Java EE 5)? How about JMS? EJB 3? JPA? Just because it's in the spec, it doesn't mean you have to use it. What the spec *does* offer, though, is a standard framework (for web, messaging, persistence, etc) that developers are free to use, should they choose to do so. To apply your logic consistently, I think, we should jettison the EE spec altogether, as we shouldn't "force" those technologies on anyone, but we can't stop there. Java SE has to go to, as we shouldn't force reflection on people who don't want that. Apparently, we can't truly have choice if we're provided with an option built-in, so all that garbage has to go, right? You're certainly free to choose the stack you like best, but I fail to see how your vehemence has any solid ground at all. Joe Kauzlarich is right in his post above: Many of your complaints are currently solved by Facelets and Seam, both of which are either being worked into the 2.0 spec, or standardized in another spec which will integerate with JSF 2, which is the version the EE 6 spec will callously and cruelly force down the throat of every Java developer on the planet. :)
  11. That being so, are you currently being forced to use JSF (it has been included since Java EE 5)? How about JMS? EJB 3? JPA?
    To clarify, This server side post is about the Web Profile -- not services, messaging, or persistence. My argument probably boils down to suggesting that Web Profiles be dropped, and a generic profile system used instead, whereby if various specs, like JSF, have merit they will survive, otherwise they will die out. Most "good looking" websites in my experience seem to be the result of training up a good web designer in how to use Eclipse and JSP pages. 1. Designer creates concept for web app look and feel. 2. Developer builds skeleton page + navigation, then commits pages. 3. Designer does a CVS/SVN update, starts up Tomcat or whatever, and modifies pages/CSS 4. Designer creates JSP 2.0 tags as required 5. Designer uses Sitemesh decorators as required I've trained designers up to do this. If they're a HTML designer and not just a photoshop designer then its not a stretch to get a designer working on the live app. I can't see how JSF fits into this picture.
  12. value of JSF[ Go to top ]


    I can't see how JSF fits into this picture.
    JSF allows the developer to abstract completely from low-level http request parameters. The JSF UIComponents are self-contained and encapsulate all decoding logic (actually for most JSF components the renderer classes contain the decoding logic). With traditional action-based frameworks (Struts, Spring MVC etc.), the level of abstraction is much lower. Consequently as developer you have to deal with low-level details such as getting check box submissions right (cf. [Ladd et al, Expert Spring MVC, Apress 2006, page 230]. No need to spend your energy on this when using JSF/Seam. Think of complicated components and it becomes clear that the JSF approach (components fully encapsulate encoding and decoding) is the right approach for serverside web applications. Validation in action-based frameworks is inferior too, compared with JSF. While there are add-on libraries such as Valang or Jakarta Commons Validator, they are inferior to JSF in combination with Seam. Spring Web flow is great. It is more powerful than Seam's conversation concept the implementation of which still has several design flaws (which hopefully will get fixed in Seam 3.0). I like Web flow's concept of input/output mappers to transfer state from a flow to its nested child flow and back again when the child flow ends. In Seam this is currently more difficult. Nevertheless, Seam in combination with JSF is at present probably the most powerful framework for serverside web applications although it requires some efforts to learn the framework (but don't you have to do this anyway when using a framework?).
  13. To clarify, This server side post is about the Web Profile -- not services, messaging, or persistence.
    Right, but your complaint seems to be predicated on the idea that if JSF is in the profile, you will somehow be forced to use it, so I just took your argument and applied to other technologies that are also in the spec, though not necessarily in this profile. Either way, though, I think your complaint falls flat. :)
    My argument probably boils down to suggesting that Web Profiles be dropped
    You may be on to something there, as I'm not sure I'm sold on the idea of profiles, though you go furhter below than I would.
    and a generic profile system used instead, whereby if various specs, like JSF, have merit they will survive, otherwise they will die out.
    As has been noted, whether or not JSF (or JavaMail or...) is in the profile neither affects its inclusion in the specification itself (as the profile isn't a spec) nor does it force anyone to use it. Profiles aside, if several years pass, and the EE 12 expert group sees that no one is using JSF, it could very well be removed. I hate to keep beating this drum, but: just because it's their, it doesn't mean you have to use it. When I was still using Spring, I didn't use AOP because it was there. I cherry-picked what I wanted and moved on. I certainly didn't rant in public about the evil plans of Interface21 to force me to use AOP. :)
    how to use Eclipse and JSP pages.
    You're still using JSP? Now if you want to talk about a technology that should be dragged out behind the woodshed and put down, JSP is the one. JSF 2 will still support it, but all the cool new stuff won't be available to JSP users. And there was much rejoicing.
    I've trained designers up to do this. If they're a HTML designer and not just a photoshop designer then its not a stretch to get a designer working on the live app. I can't see how JSF fits into this picture.
    And I don't see how it doesn't. 1. Designer creates concept for web app look and feel. 2. Developer builds skeleton page + navigation, then commits pages. 3. Designer does a CVS/SVN update, starts up Tomcat or whatever, and modifies pages/CSS 4. Designer creates JSF 1.2/2.0 tags as required 5. Designer and developer use JSFTemplating/Facelets functionality as required. 6. Developer writes managed beans and application code as required. All very similar, and all very usable, just with different technologies. Big Lots, Quicken, and...some Swiss bank are a few large companies off the top of my head that like it. Out of curiosity, when was the last time you used JSF? Have you used JSFTemplating or Facelets? Have you looked at Seam? Have you been tracking JSF 2's progress? JSFTemplating, Facelets, and Seam, for example, seem to me to solve many if not all of the complaints you've addressed so far, and JSF 2 will either incorporate that functionality, or integrate with other standards that are.
  14. Right, but your complaint seems to be predicated on the idea that if JSF is in the profile
    Yes. Leave WebBeans and JSF out. I'm playing around with extjs at the moment too, to see how it best hooks into app services. With SWF and extjs, and others, there are several candidates for the view layer. I don't buy the argument that JSF is the only technology that can bind/process/render complex UI components. On top of that, most users seem to be morons, and so I want rich navigation and simple pages, not every page chock full of complex components. Maybe 5% of the pages in an app need to be Web 2.0, and so I'll tend to use extra jQuery stuff there.
    Out of curiosity, when was the last time you used JSF?
    About 2 minutes ago.
    You're still using JSP
    From my experience, JSP seems to be something that lets designers get on with making sites look pretty. If I change from JSP, I don't want to lose SWF flows/navigation, additional scopes, and Post-Redirect-Get.
    and JSF 2 will either incorporate that functionality
    Maybe I'll check it out, *if* its not forward based, and *if* it provides rich navigation and additional scopes as per SWF, if/when its released like you say.
  15. I don't buy the argument that JSF is the only technology that can bind/process/render complex UI components.
    I'm not aware of anyone making that argument. What the spec is offering (and this profile might -- and I think should -- include is a "default" choice. If you don't like it, as you apparently don't, you're always free to use something else. All it costs is two jars in the lib directory. :)
    On top of that, most users seem to be morons, and so I want rich navigation and simple pages, not every page chock full of complex components. Maybe 5% of the pages in an app need to be Web 2.0, and so I'll tend to use extra jQuery stuff there.
    Again, there's not reason that can't be done with JSF. In fact, I do that, though I use YUI. :)
    Out of curiosity, when was the last time you used JSF?


    About 2 minutes ago.
    Fair enough. I've talked to some people who rail against JSF and haven't used it since 1.0 or 1.1. :)
    From my experience, JSP seems to be something that lets designers get on with making sites look pretty.

    If I change from JSP, I don't want to lose SWF flows/navigation, additional scopes, and Post-Redirect-Get.
    But you won't. In fact, I would think that, say, Facelets would be MORE designer friendly, as it's just xhtml. Dreamweaver, for example, has an add-on that integrates better with Facelets, giving it some understanding, I guess of what h:dataTable is, for example (note: I don't use WYSIWYG designers, so I'm pretty uninformed on their current state). SWF should work just fine with Facelets or JSFTemplating, as the NavigationHandler is independent of the ViewHandler.
    Maybe I'll check it out, *if* its not forward based, and *if* it provides rich navigation and additional scopes as per SWF, if/when its released like you say.
    Forward-based? Not sure what you mean by that, exactly, but, just in case, have you looked at the tag in the default nav handler? Is that kind of what you're talking about? The additional scopes will probably come via Web Beans.
  16. I guess its clear by now we disagree and we're just chewing up valuable Internet bandwidth. JSF for me tries just to solve a problem that doesn't exist. I didn't ask for it, and I don't want it. I'll keep monitoring it of course, like all the other technologies we're all monitoring. I hope you found some of my feedback useful. Regards,
  17. Rip out JSF again[ Go to top ]

    I would love to see a light web profile with all the good stuff (EL/Tags/JSP/Servlets/Filters/etc) but leaving the framework option up to the developers, in other words leaving JSF and Web Beans out of the picture. However, as I see it there are two strong reasons for the EG to choose to include atleast JSF in the web profile, namely: a) The tool support is *huge* for JSF, this cannot be ignored. b) The way JSF is hooked into existing containers will probably make it rather interesting to cut out again. Whichever way this goes, I'm looking forward to see many new standardized web containers on the market!
  18. Re: Rip out JSF again[ Go to top ]

    The way JSF is hooked into existing containers will probably make it rather interesting to cut out again.
    How is JSF hooked into containers? In GlassFish, it's in the javaee.jar (and maybe one more. I've updated my installation so it's a bit different), but in Tomcat, for example, JSF is two jars either in your WAR or the server lib directory. No special hooks or config needed.