Ed Burns's Blog: J2EE Archives

I'm pleased to announce the availability of the Public Review revisions of the next release of the JavaServer^TM Faces and Pages specifications. The Faces spec may be downloaded from <http://www.jcp.org/en/jsr/detail?id=252> and the Pages spec may be downloaded from <http://www.jcp.org/en/jsr/detail?id=245> We really want feedback! Please use our Forum to share your thoughts on the specs. Or you may send feedback to the comments alias for Faces or JSP (jsr-252-comments@jcp.org and jsr-245-comments@jcp.org respectively) .

In this entry, I link to a comprehensive high level outline of the changes to the spec since the 1.1 release of the Faces spec. I've decided include changes present in the December Early Draft Release as well as the current release for completeness. Keep in mind this is a high level outline, for details, I encourage you to read the relevant sections of the spec itself.

Before we get to the outline, here is a brief summary of the main changes:

Unified EL

The expression language used in Faces, which was inspired by the expression language used in JSTL and JSP, has been generalized and extracted into its own top level javax.el package. The EL is agnostic of the technology hosting it, such as JSP or Faces, and is intended to be generally useful in the same way one can use OGNL in a variety of applications. Faces now has deprecated its internal EL in favor of using the Unified EL.
New Tree Creation and Content Interweaving Model for Faces applications that use JSP

While it is perfectly acceptable to use Faces without using JSP, many people find their productivity increases when using these two technologies together. Unfortunately, as amply documented by Hans Bergsten in his article at onjava.com, there were some integration cases that didn't work as expected. By changing the specification of the implementation of the Faces ViewHandler for JSP, as well as changing the JSP custom tag base class used by all Faces component tags, these problems have all been resolved.
Integration with JSTL

Another long standing problem was in using JSTL's <c:forEach> tag to contain Faces input components. Because JSP has no notion of a postback, it was not possible to apply the values correctly to the nested input components on postback. By introducing some new concepts into the EL, it is now possible to fully use <c:forEach> with any kind of Faces component. This will require a new release of JSTL, which will also be present in J2EE 5, along with Faces and JSP.
Back Button issues and Multi Frame or Multi Window Faces Apps

Due to a deficiency in the State Management API using Faces in Multi Frame or Multi Window applications presented some problems. The browser back button also could cause application state to become confused. These problems have now been fixed.
Associating a message with a particular component in the page.

Previous revisions of the spec didn't allow for dynamically including the label of a component in an error message for that component. New spec features now allow for this to happen.

The golden question, of course, where's the implementation? It's all implemented, but the implementation of the Faces spec is only partially available, due to the unavailability of a public implementation of the JSP 2.1 spec. There are two reasons for this.

We heavily leverage the new, Unified EL, that is a separate spec document but, for convenience, is being delivered under the JSP 2.1 spec. So, while using the Unified EL does introduce a dependency on JSP 2.1, there is nothing stopping someone from implementing the EL spec outside of JSP.
In order to fix the Tree Creation and Content Interweaving problems (which are inherent to the old way of using Faces and JSP together, and therefore already implicitly dependent on JSP), as well as using <c:forEach> with Faces input components (and therefore implicitly dependent on JSTL), we had to make changes to the JSP spec, which are being delivered as part of JSP 2.1

The parts that are unavailable are those parts that a user would encounter only when using Faces and JSP together. The parts that are available are those parts that a user would encounter whether they use Faces with JSP or not. Features that are unavailable at this time are listed in gray, available features are listed in non-gray text. Available features are present in the latest release of the official Faces implementation on java.net which continues to run on J2EE 1.3 containers. Note that the content in section IV is mostly available.

Now, the outline of changes is available here.

TSSJS Mark Hapner Keynote

Posted by edburns on March 03, 2005 at 11:08 AM | Permalink | Comments (1)

I'm at The ServerSide Java Symposium, blogging live. I just attended Mark Hapner's keynote and here are my notes.


Mark started out listing some things that companies own, vs. what
communities own.  Companies own OS's, some protocols (AIM), but they
don't own the wire.  Communities own massively distributed services,
such as email, content, and also protocols.  Interestingly, he asserts
that Java is owned by the community.  The crowd grumbled a bit at this
assertion.  These two points of ownership were listed as a means to
support the assertion that developers want to own the whole stack:
protocol, framework, applications.

He introduces the concept of the services wire, stating that we must
never cede the services wire to a non-global protocol.

He spent some slides on defining what a services platform is, and
concluded that J2EE is getting closer to being that, but wasn't there
yet.  He used the analogy of the Unix Pipe as an easy way that programs
interoperate.  We need something similar for Web Services.

Service evolution is all about collaboration.  The essence of
collaboration is messaging, but messaging alone isn't enough.  You need
some message exchange patterns.  So, services will be built as
compositions of pipelines, a-la-Unix pipes.

The impl of MEP is XML.  (This places great importance on technologies
like fasst infoset).  Java is a great platform for XML.  Using XML here
allows each service node to use the technology appropriate to its need.
Of course, it also provides impl independence.  

Here Mark listed the core assertion of the talk, his vision for services:

  J2SE is the core
  JMX is the management piece
  JBI will be the collaboration piece
  J2EE will provide the services and the technologies

  This vision lead to Mark assert that the Java platform plays the main
  role in building out the web, and therefore will enable people to
  achieve their dream of community ownership of the entire stack.

Introducing Jayashri Visvanathan

Posted by edburns on August 30, 2004 at 01:22 PM | Permalink | Comments (1)

After leading the JavaServer Faces implementation team through our 1.0 release I deciced to spend more time on developing the specification itself, and have handed the leadership over to the ever-so-capable Jayashri Visvanathan. Jayashri was a key contributor to the project during 1.0, and has lead the team through the 1.1 and subsequent releases. I'm devoting this blog to giving the community a chance to get to know Jayashri better, and to give her a chance to share her vision for the future of the JavaServer Faces project.

Ed Burns: How do you think the Java Enterprise community will benefit from having javaserverfaces as an open development project?

Jayashri Visvanathan: Thanks for the introduction as well as for your vote of confidence. Following are some of the important benefits of open development.

One of the major concerns of the community has been that they have no knowledge of what features/bugs would be addressed in the next release. With open development, they have access to issues list for the current release as well as for the future releases.
They get to file issues and track any updates to that issue. If they are subscribed to the dev@javaserverfaces.dev.java.net alias, they can follow discussions about various issues including any code changes.
They are able to get access to the bug fixes/features on a day to day basis. Currently we don't have nightly builds set up but it will be available shortly.
They have access to latest source code. Once the JDL license for JSF is available, they will be able to modify and redistribute the binaries.

To summarize, they get to fully participate in the development of JSF, as an observer, code contributor or as a committer.

EB: What are your priorities for the project over the next 6 months?

JV: Here's an unprioritized short list of some things I'd like to do

Make nightly builds available.
Set up cruise control so that it can viewed externally. For those who are not aware, cruise control defines a build cycle determines if a build is necessary, if so builds, runs tests, creates a log file, and sends notifications. Right now, this is running on a Sun system and we would like to make it available to everyone.
Start accepting external contributions. To make this happen we are looking at how to make it as easy as possible for external committers to run the test suites.
Continue to focus on improving the performance of the RI in order to make it production quality.
Build a community of developers who are committed to increasing the quality of Sun's JavaServer Faces implementation.

EB: How do you feel about competing with other JavaServer Faces implementations? Where do you see your implementation excelling?

JV:JSF RI tracks the spec very closely serving as a proof of concept for the JSF specification. In addition, thanks to Ryan Lubke, our TCK Engineer, the tests are being run on a continous basis to catch any spec violations early and often. Our goal is to make the RI production quality and highly scalable.

EB: How do you plan to address feature requests and bug reports?

JV: Bugs will be evaluated within a week. If the bug is critical enough or is show stopper, we would make every effort to address it immediately. I would like to take this opportunity to encourage everyone to file issues for all bugs and any feature requests they have. To help us to quickly fix the bug, be sure to include as much information with your report as possible such as a test case, your platform, version numbers and steps to reproduce the problem.

EB: What can you tell us about your process for accepting contributors to the project?

JV: We are currently accepting code contributions/patches from the community. Detailed guidelines for submitting patches is in FAQ. In order for your patch to be accepted quickly, please attach a test case. JSF team follows test first development & code review process strictly, so if a patch doesn't have a test case, we would have to create/update an existing test for it which would delay the acceptance of your patch. Contributors who give frequent and valuable contributions can become a committer if they desire. Again,the FAQ details the JSF code development process.

EB: What do you see as some of the challenges this project may face?

JV: Our challenge would be make the RI highly scalable and of production quality in addition to keeping up with the latest spec revisions. With help from the community, its a definite possibility.

EB: How will you judge the success of the project?

JV: Based on community's feedback and their participation. JSF community has always been very vocal about pointing good and bad things about the specification as well as the RI and I hope they continue to do that and thats key to success of this project.

With that, I would like to thank you once again for introducing me and I look to forward to working with the Java Enterprise community.

Let's learn about ourfaces

Posted by edburns on August 18, 2004 at 07:59 AM | Permalink | Comments (5)

The ourfaces project is intended to be a casual, yet very useful repository of JavaServer Faces components. I say casual because we want have a low barrier to entry for adding new components to the repository. The project leader, Matthias Unverzagt, has made it very easy to get started as a contributor, in four simple steps. Of course, if it's easy to be a contributor, it's even easier to be a user.

If you look at http://www.jsfcentral.com/ you'll see there are at least ten different entries for JavaServer Faces component libraries, and most of them are not dollar cost free, nor are they free software. I feel it is important to have a high quality, open source, dollar cost free component library for Faces, and the OurFaces project intends to be just that.

Let's take a look at how the project is structured. We've made the project easy to access by building the component catalog in an easy-to-deploy WAR file during the standard build process. This enables you to explore the runtime performance of the components. The source tree is broken down as follows.

ourfaces/

  licenses/ 

    Any licenses that apply to this project go here

  src/

    <component>/

      Where <component> is one of the components in the catalog.
      Currently, we have calendar, code, tree, and table.

        catalog/

          Any artifacts relating to displaying this component in the
          catalog.  These are user-level artifacts, not core component
          artifacts.

            java/

              Java code for displaying the component in the catalog

            web/

               Any non-java code artifacts for displaying the component
               in the catalog.  This includes skinability, sample HTML,
               CSS, XML config files, etc.

        owner.xml

          The XML file that declares the owner of this component.  The
          owner is responsible for everything in this component,
          including its display in the catalog.  

        taglibrary/

          The java code that makes up the UIComponent subclass,
          (optional) Renderer, and UIComponentTag subclass.


    code/

      Any supporting code relating to the display of the catalog

    platform/

      Any supporting code used by the components.

This framework allows the component library to accept contributions from arbitrary parties, while allowing each party to own their components in the repository. As you can see, we currently only have three components, so we're eager to accept more contributors. We hope that becoming a member of the java-enterprise community will give us more visibility.

Please feel free to read and post on the discussion forum!

Powered by
Movable Type 3.01D

java.net RSS Feeds