JCP Watch: JSP 2.1, JDK 1.5, Web Services Metadata

Discussions

News: JCP Watch: JSP 2.1, JDK 1.5, Web Services Metadata

  1. There has been some activity in the JCP today. A new JSR for JSP 2.1 has been announced. The scope for JSP 2.1 is focused on aligning with JavaServer Faces, including enhancements to the expression language.

    Excerpt about JSP 2.1
    JavaServer Faces 1.0 (JSR-127) defines a standard framework for building User Interface components, and builds on top of JSP 1.2 technology. Because JSP 1.2 technology does not have an integrated expression language and because the JSP 2.0 EL does not meet all of the needs of JSF, a new expression language was developed for JSF 1.0. The JSF EG attempted to make the language as compatible with JSP 2.0 as possible but some differences were necessary. The JSF EG agreed that the JSF 1.0 EL will be phased out in the next release of the JSF specification in favor of the JSP 2.1 expression language. It is a goal, therefore, of JSP 2.1 to enhance the expression language to meet the needs of JSF technology. Many of these enhancements are likely to be useful in other contexts as well.

    Enhancements to be considered for the JSP 2.1 expression language include, but are not limited to, the following:

    • moving the expression language chapter into its own specification document, to be delivered under this JSR with consultation from the JavaServer Faces expert group
    • ability to redefine the behavior of the "." operator through a Property Resolver API
    • ability to plug in Variable Resolvers on a per-application and per-page basis
    • ability to plug in Property Resolvers on a per-application and per-page basis
    • ability to express references to bean methods using the expression language and invoking those methods via a Method Binding API
    • ability to express references to bean properties using the expression language and getting/setting those attributes via a Property Binding API
    • ability to defer expression evaluation until a time of a tag handler's choosing
    In addition to the primary focus area, the JSP 2.1 specification will synchronize with any changes in the corresponding J2EE, J2SE and Servlet API JSRs, and will consider addressing very small incremental fixes to the JSP 2.0 specification.
    Read more on JSR 245: JavaServerTM Pages 2.1

    JSR 181: Web Services Metadata for the Java Platform has published an Early Draft Review.

    Excerpt about Web Services Metadata
    This specification will define an annotated Java syntax for programming Web Services.

    The principal goal of the specification is to provide a simplified model for web services development that is easy to learn and quick to develop with. The specification will focus on enabling the commonly needed forms of web services required for achieving robust, maintainable, and highly interoperable integration.

    The Web Services Metadata for the JavaTM Platform will build on the JavaTM Language Metadata technology (JSR 175) to provide an easy to use syntax for describing web services at the source-code level for the J2EE platform.

    The specification is intended to provide a syntax that is amenable to manipulation by tools.

    The specification is intended to define a format that is easy to deploy. One attractive model is a submerged compilation model similar to JSP.

    The specification will build on the work of JSR-101 and JSR-109, and it will be designed to deploy on existing J2EE components. Metadata in the format should determine how J2EE features are deployed and provide access to the commonly needed web services technology standardized in the above JSRs while reducing the need to for application developers to learn and implement routine APIs.
    Read more about JSR 181: Web Services Metadata for the Java Platform

    Read more about JDK 1.5 (Tiger) having a second public draft

    Threaded Messages (17)

  2. Portlet support would be nice[ Go to top ]

    - ability to plug in Variable Resolvers on a per-application and per-page basis

    I guess that would give you the ability to plugin in a portlet resolver. It would be nice if JSR 168 objects were supported by the spec though.
  3. jsp syntax nightmare[ Go to top ]

    I wonder how many times they plan to change the JSP syntax.

    I recall jsp 1.0 with its scriptlets, then the TLD came, but, hey, they needed the JSTL. JSP 1.1... 1.2... EL language, Struts Taglibs, JSP 2.0, JSTL 1.1, Java Faces 1.0, JSP 2.1...

    Are they compatible ? The clear answer is No. Thousand of problems arise from this severe incompatiblity, especially using dynamic parameters in taglibs.

    Does this help... making presentation easier?
  4. Consider the alternative[ Go to top ]

    Well, consider what the other choices are: if the syntax is still flawed (an easy and common assertion to make) then NOT fixing it is worse than breaking the flawed versions, IMO.
  5. Consider the alternative[ Go to top ]

    I tottally agree with that.

    The problem is that this will be implemented by J2EE 1.5, while most application servers still don't support J2EE 1.4.

    So i won't consider Faces until it is consistent. take a look at this.


    JSF 1.2 - The revision of the JavaServer Faces specification that will synchronize with JSP 2.1. JSR not yet filed.

    So i will code an application that is inconsistent within itself.

    I want JSP 2.1 to be concise.
  6. JSP VS JSF[ Go to top ]

    I don't know why java community keeps disscussing this issue while sun should eleminate the whole JSp/Servlet thing nd work on providing JSF 2.0 with the next J2EE specs so that developing web application would not be an issue if th specification provided much richer componenets and ease of development why even toconsider using JSP....!
  7. J2EE Web Layer[ Go to top ]

    From what I can see of EJB 3.0 J2EE is heading in the right direction. Unfortunately it looks like the Web layer is still in a bit of a mess. The approach does appear to be iterating towards a solution. However it would be nice if Sun could take a step back, look at the situation and come up with a simple consistant direction which would be the way forward. A lot of the framworks which have sprung up in the past 3 years have been to fill a void in out of the box JSP/ Servlets/ Web development. As yet, I am not convinced that any of these ways (Struts, JSF, Velocity, WebWork) are going to be the way forward, and still be in use in 3 years time. This is a problem if you are trying to architect a maintainable solution for the future.
  8. Transitioning JSP versions[ Go to top ]

    When stable JSP 2.0 support came out in Tomcat, we switched. It took a day or two to convert the yucky-verbose JSTL format to JSP 2.0 EL. The learning curve for JSP 2.0 EL is much lower than JSTL <c:out> and all that stuff.

    I couldn't believe JSF had to reimplement an EL (and, although this is off-topic) how poorly implemented JSF 1.0 was. We made the terrible mistake of trying a project with JSF 1.0.

    Anyway, these proposed JSP 2.1 changes appeal greatly! I applaud those wanting to make JSP authoring easy and understandable.
  9. Transitioning JSP versions[ Go to top ]

    I couldn't believe JSF had to reimplement an EL (and, although this is off-topic) how poorly implemented JSF 1.0 was. We made the terrible mistake of trying a project with JSF 1.0.
    And JSP is being modified to support JSF!

    why not modifying JSP to support Velocity then?
  10. Transitioning JSP versions[ Go to top ]

    The learning curve for JSP 2.0 EL is much lower than JSTL <c:out> and all that stuff.
    Agreed with one caveat. <c:out> is still required as the working group could not agree on escaping rules for body ${epressions}. I would like them to reconsider that; also I would like to see simple method calls. What's so hard about ${x.y(z)} ? EL functions are such a pain in comparison.

    Matthias
  11. How about...[ Go to top ]

    If EJB 3.0 is 'replace entity beans with Hibernate' why can't JSP 2.1 be 'replace JSPs with Tapestry'? ;-)

    With backward compatibility, of course!

    Tom
  12. JSR 181 is J2EE's response to Longhorn's distributed SOA. Finally a JAX-RPC methodology that beats Axis! Also, possible future targeting of MDBs, SDOs, BPEL, perhaps via MDA. Simply add a modern discovery protocol like WS-Resource or WS-Discovery, and then JSR 181 competes directly with Jini. JSR 181 is more inclusive than Jini, since gSOAP C++ and Python web services can easily join the federation and use it.
  13. So Sun admits they pushed JSF 1.0 to market in an incomplete and inconsistent state by stating the EL in it will be abandoned in the next MINOR release in favour of an enhanced version of the EL currently in JSP 2.0.

    What they should of course have done is make the EL in JSF 1.0 consistent with that in JSP 2.0 so that JSP 2.1 and JSF 1.1 (or whatever) will share one EL without having to rewrite any code.

    As to the guy saying JSP and Servlets both should be abandoned, what have you been smoking?
    JSF and JSP are complementary technologies, not competing, just as are JSP and servlets.
    Your comment is exactly the same as people that stated Servlets should be abandoned when JSP 1.0 was announced. They were proven wrong in more ways than one...
  14. JSF and JSP are complementary technologies, not competing, just as are JSP and servlets.
    I don't think that Sun sees it that way. Why otherwise you would adapt JSP to accomodate JSF needs?

    JSP must have a straightforward, clear and reusable syntax for everyone to use. If JSF _extends_ it, its OK, but not replace it.

    This only brings lots and lots of uncompatible syntax. And of course, even if you don't use it, you have to learn it. And still worst is using different styles across a single application, when you find scriptlets, taglibs, EL, struts tags, all in the same spagetti JSP code.

    my 2 cents.
  15. So Sun admits they pushed JSF 1.0 to market in an incomplete and inconsistent state by stating the EL in it will be abandoned in the next MINOR release in favour of an enhanced version of the EL currently in JSP 2.0.What they should of course have done is make the EL in JSF 1.0 consistent with that in JSP 2.0 so that JSP 2.1 and JSF 1.1 (or whatever) will share one EL without having to rewrite any code.
    This is an incorrect statement. Basically, the JSP 2.0 EL didn't have all of the features they needed in JSF. The JSF EL is really well-done, extensible, and two-way (it can update objects as well as retrieve thier values). You can think of it as the next iteration of the JSP 2.0 EL. And, the syntax is pretty much the same (you just use "#" instead of "$"). So, JSP 2.1 is about giving pure JSP the same features, and separating out the EL into a separate document so that it can grow separately. It certainly won't break today's JSF apps.

    Kito D. Mann
    Author, JSF in Action
    http://www.jsfcentral.com -- JSF news, info, and FAQ
  16. Re: and things get more divided...[ Go to top ]

    Ok so maybe I am not understanding this. So when I upgrade to JSP 2.1 and the JSF Minor Release, I will not have to upgrade anything. If that's not correct, then I agree to the points made by the previous poster. Maybe JSF is not incomplete or inconsistent, but it's still a pain to update something without actually adding any functionality. Talk about high cost development.
  17. You can think of it as the next iteration of the JSP 2.0 EL. And, the syntax is pretty much the same (you just use "#" instead of "$"). So, JSP 2.1 is about giving pure JSP the same features, and separating out the EL into a separate document so that it can grow separately. It certainly won't break today's JSF apps.
    <sarcasm mode="on">
    Great! I can't wait till 2005 so i can use a # instead of a $ !
    </sarcasm>

    I really don't care if JSP breaks JSF. JSF is another spec. JSF shuoldn't mess with JSP.
  18. 1. From what I could see, the changes to JSP EL driven by JSF are changes that are very beneficial to other sophisticated template systems layered onto JSP. I don't really understand why people are complaining about this.

    2. My complaints about JSF 1.0 is that the reference implementation was fundamentally broken for JSTL iteration inside forms (these problems are known by the JSF developers). Unfortunately, this is a common need, and so JSF is not appropriate right now for many web sites. That doesn't mean the ideas behind JSF are bad.

    The changes to JSP EL will help everyone. So what if it was driven by JSF?