Skip navigation

There is a lot of well-founded buzz around HTML5 but I assert that nearly all of it stems from how HTML5 enables the UI authoring experience to focus entirely on the browser, instead of on server-side processing that delivers content to the browser. For years, I've been making the case that building a web application is really building a distributed application, and therefore the art is finding the best allocation of processing tasks (UI, persistence, business logic, security, etc.) to processing nodes (smartphoe, tablet, laptop, desktop, browser, server, etc). The emergence of HTML5 as a viable deployment platform changes how we answer the question of "where does the User Interface processing task go?" My goal with this blog entry is to shed some light on what this means for JSF.

Where are we now and how did we get here?

Ever since the addition of the <form> element to HTML+ in 1993developers have been trying to force the pace of innovation delivered by browser vendors in order to deliver more and more compelling applications while lowering development/deployment/maintenance costs. Two factors have historically influenced this trend: ubiquity and capability. As soon as enough people had reasonably capable browsers, server side frameworks, such as JSF stepped in to give developers what they'd been wanting since 1993: "yeah, this browser stuff is nice, but what if I want to make my own darn tags? How can I do that?"

Graph of browser capability vs. browser ubiquity

Server side frameworks provide a browser-like authoring experience, but enable the use of components not present in the least-common-denominator browser. This is achieved through server side processing using JavaScript, images, and other browser primitives. In addition to this "capability extension" feature, server side frameworks also let developers keep a tighter hold on security, provide better I18N, and lower maintenance costs.

Now that HTML5 is reasonably ubiquitous, the need for the "capability extension" feature is not as pressing. For example the power of the HTML5 Canvas object, combined with the full expressiveness of JavaScript, lets you do a whole lot more directly on the browser. Even so, I think there is still a place for server side frameworks, not least for the cases of security and maintainence costs. I think the UI task today is really like finding the right value for this slider. Indeed most apps today need to address a huge variety of client device types, and the flexibility afforded by a server side framework is an asset in meeting that goal. For these and other reasons too deep for a quick blog post, I think the usefulness of server side UI frameworks has not yet reached its end.

How does JSF 2.2 fit in?

So where does that leave JSF 2.2? As you may know, HTML 5 is a huge specification and it addresses many different categories of content. We are still very early in the development of JSF 2.2 but I can state we plan to address elements in the following content categories.

Metadata

JSF applications already have large amounts of metadata available to them. We need to find the best way to allow that data to naturally express itself via the corresponding capability in HTML5.

Sectioningand Heading

Just as the lightweight ontology of section values in HTML5 was obtained by searching google for how people were using their div tags, the same idea can be applied to how people are using their facelet templates.

Form associated elements

Form based applications are the reason for must web applications and it is this category that most ofthe HTML5 related work in JSF 2.2 will happen. For example, HTML5 now has native slider and calendar controls, which only used to be implemented using server side processing and delivering JavaScript and images.

Current Status

We're still working on delivering a revision of the spec that ties up all the loose ends left over from JSF 2.1 such as<f:viewAction />, Cross Site Request Forgery protection, and File uploads. Once the Early Draft Release milestone has been reached, we can start to think more seriously about what to do with HTML5.

Technorati Tags: edburns

If you want to try out the absolute latest Mojarra 2.2-SNAPSHOT, you can run it on GlassFish 3.1 or GlassFish 3.1.1. To install it, grab the 2.2.0-SNAPSHOT version of Mojarra from this repository.

 <repository>   
   <id>jvnet-nexus-snapshots</id>   
   <name>jvnet-nexus-snapshots</name>   
   <url>https://maven.java.net/content/repositories/snapshots/</url> 
 </repository> 
 <dependency>   
   <groupId>org.glassfish</groupId>   
   <artifactId>javax.faces</artifactId>   
   <version>2.2.0-SNAPSHOT</version>   
   <scope>provided</scope> 
 </dependency> 


 

Once you download the javax.faces.jar, you must take some steps to install it in GlassFish 3.1 or 3.1.1.

  1. Remove jsf-api.jar and jsf-impl.jarfrom the modules directory.

  2. Put javax.faces.jar in the modulesdirectory.

  3. You must modify the default-web.xml file indomains/domain1/config and lib/templates. In each directory, remove any mention of jsf-api.jarand jsf-impl.jar from the default-web.xmlfile. In place of the two jars, add a reference tojavax.faces.jar.

Once Mojarra 2.2.0-SNAPSHOT has been installed in your GlassFish 3.1.1 or GlassFish 3.1 container, you can use the 2.2-SNAPSHOT verson of the javax.faces-war-archetype, which is just like the previous one except that it depends on the 2.2-SNAPSHOT version of the JSF API. You must always include the-DarchetypeRepository argument to mvn because SNAPSHOT artifacts are never pushed to maven central.

mvn archetype:generate -DarchetypeGroupId=javax.faces -DarchetypeArtifactId=javax.faces-war-archetype -DarchetypeVersion=2.2-SNAPSHOT -DarchetypeRepository=https://maven.java.net/content/repositories/snapshots/


 

This blog entry signifies the culmination of the effort of many individuals from many disciplines over the years. I would like to thank them all for finally allowing official Java jars to flow into Maven Central.

Technorati Tags: edburns

JCP/JavaEE Artifacts in Maven Central

As mentioned in the Editor’s Blog, java.net artifacts are finally available in Maven Central. This includes the official JCP/JavaEE artifacts, being published by the official steward of Java technology. This blog entry brings to your attention a few points about using these artifacts, as well as introducing a simple archetype that the Mojarra team uses to facilitate the creation of automated regression tests.

I am not at all in the position to comment on maven best practices, but one problem I’ve run into is the effect of bitrot on a maven build. This can sometimes result in a complicated assortment of repository entries leading to the lack of a clear understanding of how your dependencies are being satisfied. Now that the official JavaEE artifacts are all in maven central, you can omit the repository declaration entirely from your projects, relying on a mirror declaration in your settings.xml file, if necessary. If you are developing a Java EE 6 application, all of the compile time dependencies can be satisfied from a single artifact, in maven central.

  1. <dependencies>
  2.   <dependency>
  3.     <groupId>javax</groupId>
  4.     <artifactId>javaee-api</artifactId>
  5.     <version>6.0</version>
  6.     <scope>provided</scope>
  7.   </dependency>
  8. </dependencies>

It is important to note that this dependency was declared with <scope>provided</scope> This is the only way you can use this dependency because the jar has been stripped of all java code and contains only signatures. The actual implementation of JavaEE 6 comes, naturally, from your Java EE 6 compliant container.

If you would rather go à la carte, the individual artifacts for all of the JavaEE technologies are also available, as listed in these tables. The first table lists artifacts that conform to the naming scheme Oracle Architect, and JavaEE Titan, Bill Shannon. The scheme is documented at <http://wikis.sun.com/display/GlassFish/Maven+Versioning+Rules>.

Technology
groupId
artifactId
version
JSR-299 Contexts and Dependency Injection for JavaEE
javax.enterprise
javax.cdi-api
1.0
JSR 314 JavaServer Faces
javax.faces
javax.faces-api
2.1
JSR 330 Dependency Injection for Java
javax.inject
javax.inject
1
JSR 316 Java EE 6
javax
javaee-api
6.0
JSR 919 Java Mail
javax.mail
javax.mail-api
1.4.4
JSR 315 Java Servlet
javax.servlet
javax.servlet-api
3.0.1
JSR 245 Java Servlet
javax.servlet.jsp
javax.servlet.jsp-api
2.2.1

The remaining jars do not conform to the naming scheme, but are useful for compilation nonetheless.

Technology
groupId
artifactId
version
JSR 925 JavaBeans Activation Framework
javax.activation
activation
1.1.1
JSR 250 Standard JavaEE Annotations
javax.annotation
jsr250-api
1.0
JSR 107 JCache
javax.cache
cache-api
0.2
JSR 188 Delivery Context
javax.ccpp
ccpp
1.0
(pre JCP JSR) Java Communications API
javax.comm
comm
3.0-u1
JSR 220 Enterprise Java Beans
javax.ejb
ejb-api
3.0
JSR 341 Expression Language
javax.el
el-api
2.2
JSR 52 JSP Standard Tag Library
javax.servlet
jstl
1.2
JSR 97 JavaHelp
javax.help
javahelp
2.0.05
JSR 208 Java Besiness Integration
javax.jbi
jbi
1.0
JSR 283 Java Content Repository API
javax.jcr
jcr
2.0
JSR 243 Java Data Objects 2
javax.jdo
jdo2-api
2.2
JSR 914 Java Messaging Service
javax.jms
jms-api
1.1-rev-1
JSR 181 Web Services Metadata for Java
javax.jws
jsr181-api
1.0-MR1
JSR 77 Java Management API
javax.management.j2ee
management-api
1.1-rev-1
JSR 317 Java Persistence
javax.persistence
persistence-api
1.0.2
JSR 286 Java Portlet
javax.portlet
portlet-api
2.0
JSR 322 Java EE Connector
javax.resource
connector-api
1.6-alpha-1
JSR 32: JAIN SIP API Specification
javax.sdp
nist-sdp
1.0
JSR 115 Java Authorization Contract for Containers API
javax.security
security-api
1.1-rev-1
JSR 240 JAIN SLEE
javax.slee
jainslee-api
1.1
JSR 907 Java Transaction API
javax.transaction
transaction-api
1.1-rev-1
JSR 303 Bean Validation
javax.validation
validation-api
1.0.0.GA
JSR 311 Java API for RESTful Web Services
javax.ws.rs
jsr311-api
1.1.1
JSR 222 Java Architecture for XML Binding
javax.xml.bind
jaxb-api
2.2.4
JSR 105 XML Digital Signature APIs
javax.xml.crypto
jsr105-api
1.0.1
JSR 206 Java API for XML Processing
javax.xml.parsers
jaxp-api
1.4.2
JSR 93 Java API for XML Registries
javax.xml
jaxr-api
1.0_04
JSR 101 XML RPC
javax.xml
jaxrpc-api
1.1
XML Web Services
javax.xml
jaxws-api
2.0EA3
JSR 173 Streaming API for XML
javax.xml.stream
stax-api
1.0-2
JSR 67 XML Messaging
javax.xml.soap
saaj-api
1.3.4
JSR 196 Java Authentication Service
Provider Interface for Containers
javax.xml
webservices-api
2.1-b16
JSR 224 XML-Based Web Services
javax.xml.ws
jaxws-api
2.2.6

If you want to use JSF 2.1, which was released after JavaEE 6, it is necessary to explicitly place a compile time dependency on that artifact before the javaee-api 6.0 dependency.

  1. <dependencies>
  2.   <dependency>
  3.     <groupId>javax.faces</groupId>
  4.     <artifactId>javax.faces-api</artifactId>
  5.     <version>2.1</version>
  6.     <scope>provided</scope>
  7.   </dependency>
  8.   <dependency>
  9.     <groupId>javax</groupId>
  10.     <artifactId>javaee-api</artifactId>
  11.     <version>6.0</version>
  12.     <scope>provided</scope>
  13.   </dependency>
  14. </dependencies>

Oracle GlassFish Server 3.1.1 <http://glassfish.org/> contains an implementation of JSF 2.1.

Archetypes That Use The Artifacts

Because we now have these artifacts in maven central, it is possible for us to finally add archetypes that use them. This first archetype creates a simple war project that depends on JSF 2.1 and JavaEE 6.

 mvn archetype:generate -DarchetypeGroupId=javax.faces -DarchetypeArtifactId=javax.faces-war-archetype -DarchetypeVersion=2.1 

A subsequent post will document the use of another artifact, for the very latest JSF version, 2.2-SNAPSHOT.

This blog entry signifies the culmination of the effort of many individuals from many disciplines over the ears. I would like to thank them all for finally allowing official Java jars to flow into Maven Central.

Technorati Tags: edburns

Filter Blog

By date: