Arun Gupta, Miles to go ...

Java EE 7 Launch Webcast: Jun 12th, Register Now

2013-05-19T15:10:12+00:00

The Java EE 7 Platform JSR was approved a few days ago and is ready to be released ...ta da!

Want to learn the latest and the greatest improvements in the platform from the best ?

Mark the date for webinars in two different time zones:

Jun 12, 2013, 9am PT
Jun 12, 2013, 9pm PT

Register now!

What will you see in this online event ?

Business Keynote (Hasan Rizvi and Cameron Purdy)
Technical Keynote (Linda DeMichiel)
Breakout Sessions on different JSRs by specification leads
Live Chat
Lots of Demos
Community, Partner, and Customer video testimonials

Feel free to use any of the following images to promote the launch webcast on your blog, website, social media, or elsewhere. You can also copy/paste the code fragment shown next to them:

Don't forget to register!

Get ready to drink from the fire hose, no throttle!

Suggestions for Java EE and Cloud Track at JavaOne 2013: CFP ends Apr 23

2013-04-17T22:54:56+00:00

JavaOne Call for Papers has been extended and now will close on April 23. There are eight tracks to submit your talks:

Client and Embedded Development with JavaFX
Core Java Platform
Edge Computing with Java in Embedded, Smart Card, and IoT applications
Emerging Languages and the Java Virtual Machine
Securing Java
Java Development Tools and Techniques
Java EE Web Profile and Platform Technologies
Java Web Services and the Cloud

A complete description of each track is provided here. Five different kind of sessions can be submitted for each track:

Conference Session: A 60-minute session presented by Oracle, customers, partners, developers, and/or user group members
Panel: A 60-minute session presented in a panel format by multiple speakers consisting of Oracle, customers, partners, developers, and/or user group members
Tutorials: A 2 hour speaker led session where the presenter literally show attendees a live "How to" tutorial, and attendees can ask questions to the presenter during this. It doesn't require the attendee to have any equipment whatsoever. Ideally, the attendee should be listening and taking notes.
Birds of a Feather (BOFs): A 60-minute session that allows a closer interaction with the speakers and attendees focusing on a particular aspect of technology.
Hands-on Lab (HOL): A two-hour hands-on, interactive lab session

We've seen a good response to paper submission so far and really thankful for that!

You've a few more days to submit your talks. As a track co-lead for Java EE and Cloud tracks, here are some talks that I'd like to see there:

Anything related to WebSocket, JSON, Concurrency, Batch, HTML5, Persistence, Dependency Injection, Transactions ?
Do you have a creative use of Java EE technologies in your applications ?
Are you an extreme believer in Java EE and use most of the components for creating world-class applications ?
Are you using multiple application servers in your deployment environment ?
Do you have any experience of migrating from earlier versions of J2EE to Java EE ? Tutorials here would be nice.
Do you want to show value of standards-based application development over proprietary frameworks ?
Are you building support for Java EE 7 in your applications already ?
Performance, monitoring, testing, development, deployment strategies ?
Any other enterprise Java technologies from the ecosystem ?
Real case studies on how Java EE helped you deliver on time, within budget, and stay competitive

And now some suggestions for the Cloud track:

How are your Java services powering web and cloud ?
Anything related to REST/SOAP Web services and design patterns ?
How is Service Oriented Architecture (SOA) helping you realize the benefits ?
Do you have an interesting deployment topology across your private and public cloud ?
Do you have a case study showing why a particular deployment scenario works ?
Are you exposing services at IaaS, PaaS, and SaaS layers and share guidelines on them ?
How are you simplifying DevOps ?
How are you using BigData in development and deployment ?
Anything related to NoSQL ? Using a mix of NoSQL and RDBMS ?

Keep the job of Content Review Committe interesting, demanding, and challenging. Submit as many sessions as you can before April 23rd 11:50pm PT.

Read the content review process and tips for submission from 2 years ago to improve your chances of getting a paper selected.

Submit now!

WebSocket Client and Server Endpoint: Annotated and Programmatic (TOTD #212)

2013-04-04T19:35:00+00:00

JSR 356 defines Java API for WebSocket 1.0. It defines a standard-based programming model for creating WebSocket client and server endpoint. Both kind of endpoints can be created programmatically or using annotations. This Tip Of The Day (TOTD) provide short snippets of how to write a WebSocket client and server endpoint programmatically or using annotations.

The complete source code in this sample can be downloaded from here.

Lets start with annotation-based server endpoint.

@ServerEndpoint("/websocket")

public class MyEndpoint {

@OnMessage

public String echoText(String name) {

return name;

}

}

@ServerEndpoint marks the POJO as a WebSocket server endpoint. URI of the deployed endpoint is as value attribute of the annotation. echoText method is invoked whenever a message with text payload is received by this endpoint. Payload of the message is mapped to the parameter name. A synchronous response is returned to the client using the return value.

Programmatic server endpoint can be defined as:

public class MyEndpoint extends Endpoint {

@Override

  public void onOpen(final Session session,
EndpointConfig ec) {

    session.addMessageHandler(new
MessageHandler.Whole<String>() {

@Override

      public void
onMessage(String text) {

try {

         
session.getBasicRemote().sendText(text);

        } catch
(IOException ex) {

         
Logger.getLogger(MyEndpoint.class.getName()).log(Level.SEVERE,
null, ex);

}

});

}

A programmatic server endpoint is defined by extending Endpoint abstract class. onOpen method is overridden to be notified of when a new conversation has started. Session captures the other end of the conversation. EndpointConfig identifies the configuration object used to configure this endpoint. Multiple MessageHandlers are registered to handle text, binary, and pong messages. The first parameter of onOpen captures the other end of the conversation. A synchronous response to the client is sent by calling getBasicRemote().sendText(...) method.

Programmatic server endpoint needs to be configured using ServerApplicationConfig.

public class MyApplicationConfig implements
ServerApplicationConfig {

@Override

  public Set<ServerEndpointConfig>
getEndpointConfigs(Set<Class<? extends Endpoint>> set)
{

    return new
HashSet<ServerEndpointConfig>() {

{

       
add(ServerEndpointConfig.Builder

           
.create(MyEndpoint.class, "/websocket")

           
.build());

}

};

}

@Override

  public Set<Class<?>>
getAnnotatedEndpointClasses(Set<Class<?>> set) {

return Collections.emptySet();

}

}

WebSocket runtime scans the WAR file with all implementations of ServerApplicationConfig and registers the endpoint returned from getEndpointConfigs and getAnnotatedEndpointClasses. The URI of the server endpoint is published using ServerEndpointConfig.Builder.

Now lets take a look at annotated client endpoint.

@ClientEndpoint

public class MyClient {

@OnOpen

public void onOpen(Session session) {

try {

String name = "Duke";

     
System.out.println("Sending message to endpoint: " + name);

     
session.getBasicRemote().sendText(name);

} catch (IOException ex) {

     
Logger.getLogger(MyClient.class.getName()).log(Level.SEVERE, null,
ex);

}

}

@ClientEndpoint marks the POJO as a WebSocket client endpoint. onOpen method is invoked whenever a new WebSocket connection is opened and is identified by @OnOpen annotation. Session captures the other end of the conversation. A synchronous message is sent to the server using session.getBasicRemote.sendText() method.

This client can connect to the endpoint as:

WebSocketContainer container =
ContainerProvider.getWebSocketContainer();

String uri = "ws://localhost:8080" +
request.getContextPath() + "/websocket";

container.connectToServer(MyClient.class,
URI.create(uri));

And finally programmatic client endpoint.

public class MyClient extends Endpoint {

@Override

  public void onOpen(final Session session,
EndpointConfig ec) {

    session.addMessageHandler(new
MessageHandler.Whole<String>() {

@Override

      public void
onMessage(String text) {

       
System.out.println("Received response in client from endpoint: " +
text);

}

});

try {

String name = "Duke";

     
System.out.println("Sending message from client -> endpoint: "
+ name);

     
session.getBasicRemote().sendText(name);

} catch (IOException ex) {

     
Logger.getLogger(MyClient.class.getName()).log(Level.SEVERE, null,
ex);

}

}

The first parameter of onOpen captures the other end of the conversation. EndpointConfig identifies the configuration object used to configure this endpoint. Multiple MessageHandlers are registered to handle text, binary, and pong messages. onMessage method is called whenever a message is received from the endpoint. A synchronous request to the server is sent by calling getBasicRemote().sendText(...) method.

This client can connect to the endpoint as:

WebSocketContainer container =
ContainerProvider.getWebSocketContainer();

String uri = "ws://localhost:8080" +
request.getContextPath() + "/websocket";

container.connectToServer(MyClient.class,

               
null,

               
URI.create(uri));

Now go download your GlassFish b82, samples source code, and run them.

Introducing Kids to Java Programming Using Minecraft

2013-03-22T17:29:04+00:00

Minecraft is a wildly popular game among elementary and middle schoolers. The game allows players to build constructions of textured cubes in a 3D world.

My son has been playing the game for about a year, lets say addicted to it. Last Fall he told me that the game is corrupted because the JAR file snapshot has messed up the configuration. And that right away rang a bell in me as a Java Evangelist at Oracle.

I learned from him that the game is written in Java, has a trial version that runs as an applet in the browser, and downloaded as a JAR file for desktop. The game is modular where the players travel through a world and chunks are loaded and unloaded to keep the memory footprint small. Something unique about the game is the ability to modify the game from what it was originally designed for. In Minecraft language, this is called as a "mod" - short for modifications. For example, a mod can add new characters to the game, change look-and-feel of the play field, or make it easy to build new structures.

The game has a server and a client component. This allows the game to be played in a single player mode where a player connects to a server using a client and plays the game. Alternatively multiple players, using different clients across platforms, can connect to a server and play with each other collaboratively. Its very common to have a server run with multiple mods. There are almost an infinite number of mods someone could do to make Minecraft a more amusing game to play. There is no official API to create these mods but there are several third-party vendors that provide that capability; Bukkit is one such API. The ability to write mods and alter the game play gives players more control over the game and gets them more excited.

My son expressed his desire to write a mod and so we started exploring further. Then onwards, he started teaching me Minecraft vocabulary and I taught him the Java programming concepts. Our discussions in the car, on the dinner table, during the breakfast preparation, and elsewhere changed to reflect that as well. He already played with Scratch and Greenfoot last Summer and that was extremely helpful during this learning curve. We set up a goal to build a mod during Christmas break. After understanding the basic concepts and building a few mods, we decided to share the knowledge with a broader set of Minecrafters. And that's where the concept of doing a Minecraft Workshop was born.

My son came up with a list of his minecraft buddies and we announced a date for the workshop. Everybody invited for the workshop confirmed their presence right away. I found out that both the invited kids and their parents were equally excited. One friend could not attend because of a prior commitment and was extremely disappointed. On the day of the workshop, some kids were eager to come even before the formal start of the workshop.

The workshop was attended by 10 kids with age ranging from 10-14 years. Most of the kids had no programming experience, let alone Java. However there was high Minecraft experience in the group with some kids playing for about 2 years and up to 2 hours every day. When given the topic of Minecraft, the small group would talk excitedly about different aspects of the game, constantly using hundreds of game-specific terms and phrases as if speaking a different language. My goal was to leverage their passion and introduce them to Java programming.

The challenge for me was to introduce programming to these kids using analogies from the daily life. Using a car, features, capabilities, types, and car dealers and correlating with class, properties, methods, instances, and packages seem to work. Fruits and different methods of peeling, eating, and planting was used to introduce the concept of Interface in Java. I asked, “What can you do with a watermelon?” the first answer was obvious, “you can eat it.” The second one was a little less so, “You can chuck in a trash can.” The response was greeted with scattered laughter. I used that to explain the concept of Exceptions in Java.

Short anecdotes and side-conversations kept the livelihood of the group going throughout the five hour programming session. There are almost an infinite number of mods someone could do to make Minecraft a more amusing game to play. But all these mods hold the same basic framework that we set up for any future work on making game-specific mods. By the end of the session, we had worked out an entire framework for making a mod. A Maven archetype to create a template Bukkit plugin allowed the attendees to avoid writing boilerplate code. A lower bar to get started and simplicity was the key for this audience. The mod built in the workshop added a new server-side command and printed a trivial message.

Although the goal of the workshop was to get an introduction on programming and make a Minecraft mod, I believe the attendees learned much more than that. I think the informal set up helped them discover that programming can be fun and useful to add to gaming experience. Programming is a vast field and we barely scratched the surface. But most importantly, the attendees had a good time and learned their first lesson of Java programming to start off an interest in it.

"Fun", "Easy", "Quick", "Awesome", "Short", and "Intuitive" described attendees' one word summary of building and running their first Hello World application using NetBeans.

All the instructions followed in the workshop, including a lot more pictures, are available at java4kids.java.net/minecraft-workshop.

For me, it was quite a humbling and learning experience. I've delivered multiple workshops all around the world but mostly to professional developers. I realized how the instructions need to be completely spelled out in order for the attendees of this age to make progress. Something as simple as "Hit Enter after entering the command", yes, that is required. Anyway I plan this to be the first of many more workshops aimed to introduce the world of Java programming to school students.

One of the lessons learned during the workshop was to simplify the installation experience. All the kids had JDK and NetBeans set up already, pretty straight forward. However I wonder why Maven insists on JAVA_HOME variable instead of figuring it out. I need to investigate how to seamlessly install JDK, NetBeans, and Maven in a platform independent way. This will allow to focus more on building the actual mod rather than the multi-step installations.

This workshop was not possible without mentoring support from Allen Dutra and other parents. A huge shout out to my family who helped validate and calibrate my strategy for the audience. My nephews feedback from the lab is incorporated into this blog. Thanks to Oracle for sponsoring the snacks!

Thank you @notch for using Java to build the game! You've provided a great platform for young kids to learn Java and truly enabled Make The Future Java ...

Chunked Step using Batch Applications in Java EE 7: Getting Started with GlassFish 4 (TOTD #211)

2013-03-06T09:00:00+00:00

TOTD #192 explained the key concepts of JSR 352. This Tip Of The Day provides a working example of a how to write a simple chunk step using JSR 352 Reference Implementation integrated in GlassFish 4.

The source code for this sample application can be downloaded from here and works on GlassFish 4 b78.

As explained in TOTD #192, JSR 352 defines item-oriented processing using chunk step and task-oriented processing using batchlet step. A chunk consists of a reader that reads one item at a time, a processor that processes one item at a time, and a writer that aggregates 'chunk' number of items and then writes them out.

Here is an implementation of reader:

@Named

public class MyItemReader extends
AbstractItemReader<MyInputRecord> {

    private final StringTokenizer
tokens;

public MyItemReader() {

        tokens = new
StringTokenizer("1,2,3,4,5,6,7,8,9,10", ",");

}

@Override

public MyInputRecord readItem() {

        if
(tokens.hasMoreTokens()) {

           
return new MyInputRecord(Integer.valueOf(tokens.nextToken()));

}

return null;

}

}

Reader uses type information to specify the type of record that it is working on, MyInputRecord in this case. The readItem method returns null to indicate the end of items that can be read. In this case, a StringTokenizer is used to read the items but you can use an InputStream here if you like.

Here is an implementation of processor:

@Named

public class MyItemProcessor implements
ItemProcessor<MyInputRecord,MyOutputRecord> {

@Override

    public MyOutputRecord
processItem(MyInputRecord t) {

       
System.out.println("processItem: " + t);

        return
(t.getId() % 2 == 0) ? null : new MyOutputRecord(t.getId() * 2);

}

}

Processor uses type information to specify the type of input and output records its working on, MyInputRecord is the input record and MyOutputRecord is the output record in this case. The processItem method reads the input record and accepts only odd-numbered records. This is where your business logic would be implemented.

And here is an implementation of writer:

@Named

public class MyItemWriter extends
AbstractItemWriter<MyOutputRecord> {



    @Override

    public void
writeItems(List<MyOutputRecord> list) {

       
System.out.println("writeItems: " + list);

    }

}

Writer uses type information as well to specify the type of output record, MyOutputRecord in this case. All these elements are tied together using "Job XML" as shown:

<job id="myJob" xmlns="http://batch.jsr352/jsl">

<step id="myStep" >

        <chunk
item-count="3">

           
<reader ref="myItemReader"></reader>

           
<processor ref="myItemProcessor"></processor>

           
<writer ref="myItemWriter"></writer>

       
</chunk>

</step>

</job>

Eventually, the references myItemReader, myItemProcessor, and myItemWriter will be resolved using CDI. But for now, the references can be explicitly resolved using "batch.xml" as shown:

<batch-artifacts xmlns="http://jcp.org.batch/jsl">

    <ref id="myItemReader"
class="org.glassfish.chunk.simple.MyItemReader"/>

    <ref id="myItemProcessor"
class="org.glassfish.chunk.simple.MyItemProcessor"/>

    <ref id="myItemWriter"
class="org.glassfish.chunk.simple.MyItemWriter"/>

</batch-artifacts>

Once again, downloaded the source code from here and get it running on GlassFish 4 b78.

Post feedback on public@jbatch.java.net or users@glassfish.java.net.

Consuming and Producing JSON using JAX-RS Entity Providers and JSR 353 Streaming API (TOTD# 210)

2013-03-04T08:15:00+00:00

TOTD #193 explained how JAX-RS Entity Providers can be used to provide mapping between on-the-wire representations and their associated Java types. This blog shows how you can use Java API for JSON Processing (JSR 353), already integrated in GlassFish 4 promoted builds, to produce and consume JSON payload using Entity Providers.

The source code in this blog can be downloaded here and runs on GlassFish b76.

Lets say your domain object is defined as:

public class MyObject {



  private String name;

  private int age;



  //. . .

}

And your resource endpoint is defined as:

@Path("endpoint")

public class MyResource {

  @POST

  @Consumes(MediaType.APPLICATION_JSON)

  public MyObject echoObject(MyObject mo) {

    return mo;

  }

}

This is just echoing the domain object but I suspect your domain logic would be more complex than that ;-)

Using JAX-RS Client API, this endpoint can be invoked as:

WebTarget target = client.target(".../endpoint");

MyObject mo = target

              
.request()

              
.post(

                
Entity.entity(new MyObject("Duke", 18),
MediaType.APPLICATION_JSON),

                
MyObject.class);

System.out.println("Received response: " + mo.getName() + ", " +
mo.getAge() + "<br><br>");

The MessageBodyWriter.writeTo method, that writes MyObject to the underlying OutputStream, uses Streaming API from JSR 353 and looks like:

@Override

public void writeTo(MyObject t, 

                   



Class<?> type,

                   



 Type type1,

                   



 Annotation[] antns,

                   



 MediaType mt,

                   



 MultivaluedMap<String, Object> mm,

                   



 OutputStream out)

           
throws IOException, WebApplicationException {

  JsonGeneratorFactory factory =
Json.createGeneratorFactory();

  JsonGenerator gen = factory.createGenerator(out);

  gen.writeStartObject()

     .write("name", t.getName())

     .write("age", t.getAge())

     .writeEnd();

  gen.flush();

}

Similarly MessageBodyReader.readFrom method, that reads MyObject from the underlying InputStream, uses Streaming API from JSR 353 and looks like:

@Override

public MyObject readFrom(Class<MyObject> type,

                        




Type type1,

                        




 Annotation[] antns,

                        




 MediaType mt,

                        




MultivaluedMap<String, String> mm,

                        




 InputStream in)

               




throws IOException, WebApplicationException {

  MyObject mo = new MyObject();

  JsonParser parser = Json.createParser(in);

  while (parser.hasNext()) {

    switch (parser.next()) {

      case KEY_NAME:

        String key =
parser.getString();

        parser.next();

        switch (key) {

          case "name":

           
mo.setName(parser.getString());

            break;

          case "age":

           
mo.setAge(parser.getIntValue());

            break;

          default:

            break;

        }

        break;

      default:

        break;

    }

  }

  return mo;

}

The code is pretty straight forward and refer to Java API for JSON Processing javadocs if you need help in understanding the code.

Download the source code and enjoy!

Updating to latest WebSocket API - Starting with GlassFish b78 (TOTD #209)

2013-02-28T15:50:44+00:00

Java API for WebSocket (JSR 356) has recently gone through a major refactoring. The changes are integrated in Tyrus b12 and now available in GlassFish b78. This Tip Of The Day (TOTD) shows the change log for WebSocket endpoint in Collaborative Whiteboard Sample (explained in TOTD #189) between GlassFish b76 and b78.

First of all, everything stays in javax.websocket.* and javax.websocket.server.* package.

There are name changes in annotations, APIs, class renames, and some behavior change as well. Pavel's blog provides a comprehensive list of changes and the annotation changes are listed here as well:

Name before b78	Name after b78
`@WebSocketEndpoint`	`@ServerEndpoint`
`@WebSocketClient`	`@ClientEndpoint`
`@WebSocketMessage`	`@OnMessage`
`@WebSocketPathParam`	`@PathParam`
`@WebSocketOpen`	`@OnOpen`
`@WebSocketClose`	`@OnClose`
`@WebSocketError`	`@OnError`

Here is the change log for updating Whiteboard.java:

--- <html>Whiteboard.java (<b>849f919</b>)</html>
+++ <html><b>Current File</b></html>
@@ -45,50 +45,48 @@
 import java.util.HashSet;
 import java.util.Set;
 import javax.websocket.EncodeException;
+import javax.websocket.OnClose;
+import javax.websocket.OnMessage;
+import javax.websocket.OnOpen;
 import javax.websocket.Session;
-import javax.websocket.WebSocketClose;
-import javax.websocket.WebSocketMessage;
-import javax.websocket.WebSocketOpen;
-import javax.websocket.server.WebSocketEndpoint;
+import javax.websocket.server.ServerEndpoint;
 
 /**
 * @author Arun Gupta
 */
-@WebSocketEndpoint(value = "/websocket",
+@ServerEndpoint(value = "/websocket",
 encoders = {FigureEncoder.class},
 decoders = {FigureDecoder.class})
 public class Whiteboard {
 
 private static Set<Session> peers = Collections.synchronizedSet(new HashSet<Session>());
 
- @WebSocketOpen
+ @OnOpen
 public void onOpen(Session peer) {
 peers.add(peer);
 }
 
- @WebSocketClose
+ @OnClose
 public void onClose(Session peer) {
 peers.remove(peer);
 }
 
- @WebSocketMessage
+ @OnMessage
 public void boradcastFigure(Figure figure, Session session) throws IOException, EncodeException {
 System.out.println("boradcastFigure: " + figure);
 for (Session peer : peers) {
 if (!peer.equals(session)) {
- peer.getRemote().sendObject(figure);
+ peer.getBasicRemote().sendObject(figure);
 }
 }
 }
 
- @WebSocketMessage
+ @OnMessage
 public void broadcastSnapshot(ByteBuffer data, Session session) throws IOException {
 System.out.println("broadcastBinary: " + data);
 for (Session peer : peers) {
 if (!peer.equals(session)) {
- peer.getRemote().sendBytes(data);
+ peer.getBasicRemote().sendBinary(data);
 }
 }
 }

The updated source code for the sample is available here and runs on GlassFish b78.

Hopefully this gives you a good idea on how to migrate your WebSocket applications from the older to the newer API. The changes are still evolving and the specification (PDF) and javadocs (ZIP) are the definitive source for the latest information. The complete set of latest spec downloads are available here.

As always, send the spec feedback to users@websocket-spec.java.net and implementation feedback to users@tyrus.java.net.

Transparency and Community Participation in Java EE 7

2013-02-27T10:00:00+00:00

Ever since the launch of Java EE 7 and its component JSRs, Oracle has been very committed to a high level of transparency for all of the JSRs under the Java EE 7 umbrella. We're so excited that increased transparency has resulted in more useful feedback that has improved the Java EE platform. Let me tell you what we've done, how it's helped, and how you can get involved too.

One of the requirements for JCP 2.8 is:

When voting to approve a JSR's transition to the next stage, EC members are expected to take into consideration the extent to which the Spec Lead is meeting the transparency requirements.

Now that many of these JSRs have gone through the Public Review Ballot and others are in progress, it is useful to review how they have contributed to the transparency process.

First of all, all Java EE 7 Expert Groups are operating using the transparency rules defined JCP 2.8. The transparency rule requires:

Public can read the names on the Expert Group
Expert Group business is regularly reported on a publicly readable alias
Mechanism for allow public to provide feedback
Spec lead respond to the posts on the alias
Schedule of JSR is publicly available, current, and updated regularly
Open source process for the development of RI and/or TCK
Publicly readable and/or writable issue-tracker
Publicly accessible document archive

Happy to report that all the JSRs in Java EE 7 have followed the guidelines mentioned above. Providing a specific example using JSR 342:

JSR 342 has all the Expert Group member names publicly listed
All technical discussions on the Expert Group are reported on jsr342-experts@javaee-spec.java.net alias and archived
Anybody outside the Expert Group can subscribe to the alias at users@javaee-spec.java.net and provide feedback
Spec leads regularly read and respond on the alias
Schedule of JSR is publicly reported at javaee-spec.java.net
GlassFish is the Reference Implementation and is completely built in open source. The promoted builds have been available for several months, the schedule is completely transparent, maven coordinates are published, and NetBeans tooling is available for some time. All this allows developers to play with the bleeding edge Java EE 7 technologies as they are integrated in GlassFish. Public forum allows the users to communicate specifically about the RI.
Publicly readable/writable issue tracker
Publicly accessible document archive

The transparency checklist by each JSR is explained in the table below.

Many of our spec leads have gone beyond this in their outreach to the community with blogs, talks, chats, and more. The Java EE 7 Expert Group recently concluded a public survey seeking community input to define key areas in the platform such as which specifications should be included in the Web Profile, should CDI be enabled by default, expanded use of @Stereotype, and expansions of Interceptors to all Java EE components. Over 1100 respondents voted, make their voices heard, and help decide the direction of the platform.

The table below provides:

Public website for each specification in Java EE 7. All of our JSRs that are part of the Java EE 7 Platform are being run in the open, using java.net projects. These JSRs, and links to their respective projects are listed on the home page of the Java EE 7 Platform JSR and in the table below. Each page has publicly viewable Expert Group mailing lists as Users observer lists. The Users lists receive copies of all expert group emails, as well as providing users the ability to post feedback and engage in discussions with each other and with expert group members. All lists have publicly viewable archives on the java.net project sites.

Similarly, all projects have publicly accessible download areas, and JIRA issue trackers where bugs and suggestions for new features can be posted, and which also serve as another means of discussion with EG members. The schedules and interim drafts of the specification were posted on the main project page and publicly visible Downloads area.
Transparency Checklist columns shows the status of different JSRs meeting the transparency requirements of JCP 2.8.
Community Participation represents the increase in community participation above and beyond the core Expert Group for each Specification. As you can see the participation from the community outside the Expert Group is pretty significant and has worked really well.
To encourage further community participation, different Java EE 7 Expert Groups defined specific areas to provide feedback using Adopt-a-JSR. We saw tremendous success with the effort with several JUGs joining the effort. The last column lists different JUGs that have adopted a particular JSR. In several cases, JUGs have adopted multiple JSRs.

Specification / JSR	Transparency Checklist								Community Participation	Adopt-a-JSR
Specification / JSR	A	B	C	D	E	F	G	H	Community Participation	Adopt-a-JSR
Concurrency (JSR 236)	✓	✓	✓	✓	✓	✓	✓	✓	~250%
JPA (JSR 338)	✓	✓	✓	✓	✓	✓	✓	✓	~250%	Chennai JUG Hyderabad JUG
JAX-RS (JSR 339)	✓	✓	✓	✓	✓	✓	✓	✓	~350%	CE JUG Indonesia JUG LJC Madrid JUG Morocco JUG Peru JUG SouJava
Servlet (JSR 340)	✓	✓	✓	✓	✓	✓	✓	✓	~350%
EL (JSR 341)	✓	✓	✓	✓	✓	✓	✓	✓	~125%
Java EE 7 (JSR 342)	✓	✓	✓	✓	✓	✓	✓	✓	~600%	LJC
JMS (JSR 343)	✓	✓	✓	✓	✓	✓	✓	✓	~500%	FASO JUG Indonesia JUG LJC Peru JUG
JSF 2.2 (JSR 344)	✓	✓	✓	✓	✓	✓	✓	✓	~200%	CE JUG Chennai JUG Cologne JUG Hyderabad JUG SouJava
EJB (JSR 345)	✓	✓	✓	✓	✓	✓	✓	✓	~300%	SouJava Campinas JUG
CDI (JSR 346)	✓	✓	✓	✓	✓	✓	✓	✓	Only public forum	Chennai JUG Hyderabad JUG Indonesia JUG LJC
Bean Validation (JSR 349)	✓	✓	✓	✓	✓	✓	✓	✓	Only public forum	SouJava
Batch (JSR 352)	✓	✓	✓	✓	✓	✓	✓	✓	~750%	Chennai JUG LJC, SouJava
JSON (JSR 353)	✓	✓	✓	✓	✓	✓	✓	✓	~650%	CE JUG Congo JUG LJC Mbale JUG Morocco JUG Peru JUG SouJava Toronto JUG
WebSocket (JSR 356)	✓	✓	✓	✓	✓	✓	✓	✓	~400%	BeJUG LJC Chennai JUG Morocco JUG CEJUG NY SIG

The map below shows geographical coordinates for different JUGs participating in the Adopt-a-JSR effort for Java EE 7:

View Java EE 7 Adopt-a-JSR Maps in a larger map

Specific contributions from Adopt-a-JSR effort:

London Java Community (LJC) organized a WebSocket and JSON Hack Day. The event was sold out within 2 hours and had 17 people on the waiting list. The event started with a presentation on explaining the APIs in Java API for WebSocket (JSR 353) and Java API for JSON Processing (JSR 353). The attendees designed a Market Ticker application. All the presentation material and source code was shared publicly. LJC also created projects (cdiex-palindrom-jsf and cdiex-datastore) to test CDI 1.1 specification.
Chennai JUG is building a multi-player game that can be played across the Internet. The application uses Java API for WebSocket 1.0 (JSR 356), Java API for JSON Processing 1.0 (JSR 353), Java Persistence API 2.1 (JSR 338), JavaServer Faces 2.2 (JSR 344) and Batch Applications for Java Platform (JSR 352) and/or Enterprise JavaBeans 3.2 (JSR 345) and so provide a holistic experience of building a Java EE 7 application. The energetic JUG meets regularly using G+ hangouts and in the neighborhood coffee shops to coordinate. And then they go hacking the application on github. There are 5 developers that are regularly contributing to the application and the JUG plans to incorporate several other technologies as part of an ongoing effort.
Morocco JUG will be presenting on Java EE 7, WebSocket, and JSON at Java Developer Conference, Cairo, Egypt.
Cologne JUG had a meetup on about JSF 2.2 and another one on CDI 1.1 (video).
BeJUG has adopted JSR 356 have planned a hackathon on Mar 6th. They plan to build a cross-browser Tic-Tac-Toe application using JSR 356. One of the JUG members is on its way to become a committer in Tyrus - the Reference Implementation for JSR 356.
Ceara JUG has planned a set of presentations on Mar 9 by on JAX-RS 2.0 (JSR 339), Java API for JSON Processing (JSR 353), JavaServer Faces 2.2 (JSR 344), and Java API for WebSocket (JSR 356).
San Francisco JUG organized a Java EE 7 and WebSocket session and planning a session on JAX-RS 2.0.
SouJava is contributing by adding new features from JSF 2.2 to Scrum Toys.

Several other JUGs are doing an outstanding work and contributing towards making Java EE 7 as the best release ever. All these efforts truly indicate that Java EE 7 is getting grass roots participation from the global community. This truly allows early feedback on the specification and implementation from the end user and developers who will eventually use these APIs. Overall this leads to a higher quality deliverables and will hopefully eventually lead to a faster adoption as well.

Even though many of the JSRs have gone through Public Review Ballot and others are in progress, its never too late to contribute. So how do you contribute ? Just follow this three step process:

Join a JUG: If you do not participate in your local Java User Group, then find your local JUG and participate. There are several already active JUGs around the world. If one does not exist in your neighborhood, now is your time to shine as a leader and start one.
Participate in Adopt-a-JSR: Encourage JUG members to participate in the global Adopt-a-JSR effort. Several JUGs are already participating and contributing very effectively.
Share the joy: Pick any of the Java EE 7 JSRs that are particularly interesting, download GlassFish 4 promoted builds, read javadocs, build a sample application, provide feedback to the Expert Group, and share the joy!

Adopt-a-JSR for Java EE 7: Getting Started provide more details on how your JUGs can contribute effectively.

Java EE 7 JSRs are truly operating in a fully transparent manner and took community participation to a new level. We are always ready for feedback!

WebSocket Java Client API in GlassFish 4 (TOTD #208)

2013-02-26T14:46:16+00:00

The WebSocket API by W3C defines an API that enables Web pages to use the WebSocket protocol for two-way communication with a remote host. Java API for WebSocket (JSR 356) has added an ability to invoke a WebSocket endpoint from a Java application. This Tip Of The Day (TOTD) will explain how you can use that API for invoking a WebSocket endpoint.

JSR 356 introduces a class-level annotation @WebSocketClient that converts a POJO into a WebSocket client. The usual lifecycle annotations such as @WebSocketOpen, @WebSocketClose, @WebSocketError, and @WebSocketMessage can be specified on methods.

@WebSocketClient
public class MyClientEndpoint {
 @WebSocketOpen
 public void onOpen(Session session) {
 System.out.println("Connected to endpoint: " + session.getRemote());
 try {
 String name = "Duke";
 System.out.println("Sending message to endpoint: " + name);
 session.getRemote().sendString(name);
 } catch (IOException ex) {
 Logger.getLogger(MyClientEndpoint.class.getName()).log(Level.SEVERE, null, ex);
 }
 }
 
 @WebSocketMessage
 public void processMessage(String message) {
 System.out.println("Received message in client: " + message);
 Client.messageLatch.countDown();
 }
}

This code sends a message to the connected WebSocket endpoint from the onOpen method and prints the message when it comes back. This endpoint is bootstrapped using a separate class:


public class Client {

 final static CountDownLatch messageLatch = new CountDownLatch(1);
 
 public static void main(String[] args) {
 try {
 WebSocketContainer container = ContainerProvider.getWebSocketContainer();
 String uri = "ws://echo.websocket.org:80/";
 System.out.println("Connecting to " + uri);
 container.connectToServer(MyClientEndpoint.class, URI.create(uri));
 messageLatch.await(100, TimeUnit.SECONDS); 
 } catch (DeploymentException | InterruptedException ex) {
 Logger.getLogger(Client.class.getName()).log(Level.SEVERE, null, ex);
 }
 }
}

Note that a CountDownLatch is used to ensure that there is enough time for the client to connect to the endpoint. The latch counts down in MyClientEndpoint.processMessage once the echo message is received from the endpoint.

The source code can be downloaded here, connects to a remote WebSocket endpoint, and displays the output on the console.

The Maven dependency for now are specified as:

<dependencies>
 <dependency>
 <groupId>org.glassfish.tyrus</groupId>
 <artifactId>tyrus-client</artifactId>
 <version>1.0-SNAPSHOT</version>
 </dependency>
 <dependency>
 <groupId>org.glassfish.tyrus</groupId>
 <artifactId>tyrus-container-grizzly</artifactId>
 <version>1.0-SNAPSHOT</version>
 </dependency> 
</dependencies>

Hopefully these could be specified as javax dependencies only!

The latest specification draft and javadocs can be downloaded here. Share your feedback at users@websocket-spec.java.net (for the specification) or users@tyrus.java.net (for the implenentation).

Chat Sever using WebSocket in GlassFish 4 (TOTD #207)

2013-02-25T19:44:12+00:00

A canonical example of using WebSocket is a chat server. This Tip Of The Day (TOTD) will share the code for building exactly that!

The complete code in this TOTD can be downloaded here and runs on GlassFish 4 b77.

Here is the code for the Chat Server built as a WebSocket endpoint:

@WebSocketEndpoint("/websocket")
public class ChatEndpoint {
 private static final Set<Session> peers = Collections.synchronizedSet(new HashSet<Session>());
 
 @WebSocketOpen
 public void onOpen(Session peer) {
 peers.add(peer);
 }
 
 @WebSocketClose
 public void onClose(Session peer) {
 peers.remove(peer);
 }
 
 @WebSocketMessage
 public void message(String message, Session client) throws IOException, EncodeException {
 for (Session peer : peers) {
 peer.getRemote().sendObject(message);
 }
 }
}

In this code:

Lifecycle callbacks manage the coordinates of the connecting clients
message method receives all the messages sent by the client and then transmits to all the connected clients.

Simple, isn't it ?

You can use a trivial JavaScript to exchange messages between two browsers. A chat session between two Chrome and Firefox is shown below:

Download the source code and run it in GlassFish 4 b77.

JsonParser and JsonReader - Streaming and Object Readers in Java API for JSON Processing (TOTD #206)

2013-02-20T07:00:00+00:00

JsonReader reads a JSON object or array from an input source. This provides DOM access to the JSON structure.

JsonParser provides forward, ready-only access to JSON data in a streaming way. The parser can be created from InputStream and Reader. A sample code looks like:

JsonParser jsonParser = Json.createParser(new
StringReader(YOUR_STRING_HERE));

Here is a table with code fragments for parsing some common JSON using Object Model and events generated from Streaming API:

JSON	Object Model API	Events from Streaming API
`{ }`	`JsonReader jsonReader = new JsonReader(new StringReader("{}")); JsonObject json = jsonReader.readObject();`	`{START_OBJECT }END_OBJECT`
`{` `"apple":"red",` `"banana":"yellow"}`	`jsonReader = new JsonReader(new StringReader(...)); json = jsonReader.readObject();`	`{START_OBJECT` `"apple"KEY_NAME:"red"VALUE_STRING,` `"banana"KEY_NAME:"yellow"VALUE_STRING}`
`[` `{ "apple":"red" },` `{ "banana":"yellow" }]`	`jsonReader = new JsonReader(new StringReader(...)); JsonArray jsonArr = jsonReader.readArray();`	`[START_ARRAY` `{START_OBJECT "apple"KEY_NAME:"red"VALUE_STRING }END_OBJECT,` `{START_OBJECT "banana"KEY_NAME:"yellow"VALUE_STRING }END_OBJECT]END_ARRAY`
`{` `"title":"The Matrix",` `"year":1999,` `"cast":[` `"Keanu Reaves",` `"Laurence Fishburne",` `"Carrie-Anne Moss"` `]}`	`jsonReader = new JsonReader(new StringReader(...)); json = jsonReader.readObject();`	`{START_OBJECT` `"title"KEY_NAME:"The Matrix"VALUE_STRING,` `"year"KEY_NAME:1999VALUE_NUMBER,` `"cast"KEY_NAME:[START_ARRAY` `"Keanu Reaves"VALUE_STRING,` `"Laurence Fishburne"VALUE_STRING,` `"Carrie-Anne Moss"VALUE_STRING` `]END_ARRAY}END_OBJECT`

The source code for this sample can be downloaded here, try it with GlassFish 4 b76 or later.

Note, GlassFish b76 has Public Review version of the APIs. But the APIs have evolved since then and an integration is planned in the next few days. So if you are using an older build, the sample code may not work. I'll update the sample code once the bits are integrated.

Here are some more links for you to read further:

JsonGenerator and JsonObjectBuilder - Streaming and Object API in Java API for JSON Processing (TOTD #205)

2013-02-18T19:15:53+00:00

Java API for JSON Processing (JSR 353) cleared Public Review unanimously and is on its way to to standardization. There is still Proposed Final Draft and the final vote to come. As per the Java EE 7 schedule, the specification will be final on 4/15/2013. The implementation is already integrated in GlassFish 4 builds.

The API provides an Object Model (like DOM for XML) and Streaming API (like StAX for XML) to parse and generate JSON structure. Here is a table that provide code fragments for generating some common JSON:

JSON	Object Model API	Streaming API
`{ }`	`JsonObject jsonObject = new JsonObjectBuilder().build();new JsonWriter(System.out) .writeObject(jsonObject);`	`JsonGeneratorFactory factory = Json.createGeneratorFactory();JsonGenerator gen = factory.createGenerator(System.out);gen.writeStartObject().writeEnd();`
`{` `"apple":"red",` `"banana":"yellow"}`	`new JsonObjectBuilder()` `.add("apple", "red")` `.add("banana", "yellow").build();`	`gen.writeStartObject()` `.write("apple", "red")` `.write("banana", "yellow")` `.writeEnd();`
`[` `{ "apple":"red" },` `{ "banana":"yellow" }]`	`JsonArray jsonArray = new JsonArrayBuilder()` `.add(new JsonObjectBuilder() .add("apple","red"))` `.add(new JsonObjectBuilder() .add("banana","yellow"))` `.build();`	`gen.writeStartArray()` `.writeStartObject()` `.write("apple", "red")` `.writeEnd()` `.writeStartObject()` `.write("banana", "yellow")` `.writeEnd().writeEnd();`
`{` `"title":"The Matrix",` `"year":1999,` `"cast":[` `"Keanu Reaves",` `"Laurence Fishburne",` `"Carrie-Anne Moss"` `]}`	`new` `new JsonObjectBuilder()` `.add("title", "The Matrix")` `.add("year", 1999)` `.add("cast", new JsonArrayBuilder()` `.add("Keanu Reaves")` `.add("Laurence Fishburne")` `.add("Carrie-Anne Moss")).build();`	`gen.writeStartObject()` `.write("title", "The Matrix")` `.write("year", 1999)` `.writeStartArray("cast")` `.write("Keanu Reaves")` `.write("Laurence Fishburne")` `.write("Carrie-Anne Moss")` `.writeEnd()` `.writeEnd();`

The source code for this sample can be downloaded here, try it with GlassFish 4 b76 or later.

Here are some more links for you to read further:

@WebSocketClient in GlassFish 4 (TOTD #204)

2013-02-13T23:12:29+00:00

Tyrus is the Reference Implementation for Java API for WebSocket (JSR 356) and is already integrated in GlassFish 4. The implementation is rapidly evolving and and adding support for different features already defined in the latest version of the specification.

The latest integration in GlassFish added support for creating Java-based WebSocket clients.

Any POJO can be made a WebSocket client by adding @WebSocketClient. A inbound message is received in a method annotated with @WebSocketMessage. Any method can be designated as lifecycle method by specifying @WebSocketOpen, @WebSocketClose, @WebSocketError. Here is a simple sample:

@WebSocketClient
public class MyClient {
 @WebSocketOpen
 public void onOpen(Session session) {
 System.out.println("Connected to endpoint: " + session.getRemote());
 try {
 session.getRemote().sendString("Duke");
 } catch (IOException ex) {
 Logger.getLogger(MyClient.class.getName()).log(Level.SEVERE, null, ex);
 }
 }
 
 @WebSocketMessage
 public void processMessage(String message, Session session) {
 System.out.println(getClass().getName() + ": " + message);
 }
}

In this code, a message is sent to the connected WebSocket endpoint whenever the connection is initiated. An inbound message (coming from the server) is processed using processMessage method.

The endpoint code is pretty trivial:

@WebSocketEndpoint(value="/websocket", configuration=DefaultServerConfiguration.class)
public class MyEndpoint {
 
 @WebSocketMessage
 public String sayHello(String name) {
 System.out.println(getClass().getName() + ": " + name);
 return "Hello " + name;
 }
 
}

The endpoint has a single method that receives the payload, appends a string and returns back as the response. Even though server is returning the response right away, the client views this as two separate messages, one outbound and the other one inbound. So any message-exchange-pattern such as request/response need to be specifically built using the application code. The configuration attribute, in this case, is optional and will be fixed in a subsequent release of Tyrus.

The client can bootstrap using Java SE or Java EE components as:

WebSocketContainer container = ContainerProvider.getWebSocketContainer();
String uri = "ws://localhost:8080" + request.getContextPath() + "/websocket";
container.connectToServer(MyClient.class, URI.create(uri));

The complete source code used in this Tip Of The Day (TOTD) is available here. It will run on the latest checked out version of GlassFish workspace, not a promoted build yet (bleeding edge eh ;-)

Please provide feedback on users@tyrus.java.net.

How are you going to use Java-based WebSocket client in your applications ?

Here are other Java EE 7 entries published on this blog so far:

Create ManagedExecutorService, ManagedScheduledExecutorService, ManagedThreadFactory, ContextService in GlassFish 4 build 74 (TOTD #203)
Resource Library Contracts in JSF 2.2 (TOTD #202)
Java EE 7 Maven Archetype - Available in NetBeans (TOTD #201)
Java EE 7 and NetBeans IDE - Early Support Available (TOTD #199)
JSF 2.2 FacesFlow - @FlowScoped, #{flowScope}, @FlowDefinition (TOTD #198)
Java EE 7 Maven Application (TOTD #197)
Default Data Source in Java EE 7: Lesser XML and More Defaults (TOTD #196)
JPA 2.1 Implementation - EclipseLink M6 integrated in GlassFish 4 (TOTD #195)
JAX-RS Client API and GlassFish 4 - Logging HTTP Messages (TOTD #194)
JAX-RS Custom Entity Providers (TOTD #193)
Batch Applications in Java EE 7 (TOTD #192)
Simple JMS 2.0 Sample (TOTD #191)
What's New in Servlet 3.1 ?
Concurrency Utilities for Java EE (JSR 236)
Collaborative Whiteboard using WebSocket in GlassFish 4 (TOTD #189)
Non-blocking I/O using Servlet 3.1 (TOTD #188)
What's New in EJB 3.2 ?
JPA 2.1 Schema Generation (TOTD #187)
WebSocket Applications using Java (JSR 356)
Jersey 2 in GlassFish 4 (TOTD #182)
WebSocket and Java EE 7 (TOTD #181)
Java API for JSON Processing (JSR 353)
JMS 2.0 Early Draft (JSR 343)

Create ManagedExecutorService, ManagedScheduledExecutorService, ManagedThreadFactory, ContextService in GlassFish 4 build 74 (TOTD #203)

2013-02-11T14:37:32+00:00

Latest GlassFish 4 promoted build (74 at this time) has the first cut of Concurrency Utilities for Java EE (JSR 236) implementation integrated. An earlier blog provided an overview of the specification, lets see what can be actually done with this build.

This build introduce new commands to create ManagedExecutorService, ManagedScheduledExecutorService, ManagedThreadFactory, and ContextService.

A simple command execution as:

asadmin create-managed-executor-service concurrent/myExecutor
Managed executor service concurrent/myExecutor created successfully.
Command create-managed-executor-service executed successfully.

creates the configuration for a default ManagedExecutorService. Adding --help shows more details about the command:

create-managed-executor-service
    [--enabled=true]
    [--contextinfo=contextinfo]
    [--threadpriority=5]
    [--longrunningtasks=false]
    [--hungafterseconds=hungafterseconds]
    [--corepoolsize=0]
    [--maximumpoolsize=2147483647]
    [--keepaliveseconds=60]
    [--threadlifetimeseconds=0]
    [--taskqueuecapacity=2147483647]
    [--description=description]
    [--property=property]
    [--target=target]
    jndi_name

The created executor can then be injected into a Java EE component (say Servlet) as:

@Resource(name = "concurrent/myExecutor")
ManagedExecutorService executor;

or looked up using JNDI as:

InitialContext ctx = new InitialContext();
ManagedExecutorService executor = (ManagedExecutorService) ctx.lookup("concurrent/myExecutor");

A task can be defined as:

public class MyRunnableTask implements Runnable {

 private int id;

 public MyRunnableTask(int id) {
 this.id = id;
 }

 @Override
 public void run() {
 try {
 System.out.format("%d (runnable): starting", id);
 System.out.format("%d (runnable): sleeping 2 seconds", id);
 Thread.sleep(2000);
 System.out.format("%d (runnable): complete", id);
 } catch (InterruptedException ex) {
 Logger.getLogger(TestResourceServlet.class.getName()).log(Level.SEVERE, null, ex);
 }
 }
}

Task can be submitted as:

Future<?> f = executor.submit(new MyRunnableTask(1));

executor.execute(new MyRunnableTask(2));

A task may also be defined as:

public class MyCallableTask implements Callable<Product> {

 private int id;
 
 public MyCallableTask(int id) {
 this.id = id;
 }
 
 @Override
 public Product call() {
 try {
 System.out.format("%d (callable): starting", id);
 System.out.format("%d (callable): sleeping 2 seconds", id);
 Thread.sleep(2000);
 System.out.format("%d (callable): complete", id);
 } catch (InterruptedException ex) {
 Logger.getLogger(TestResourceServlet.class.getName()).log(Level.SEVERE, null, ex);
 }
 return new Product(id);
 }
}

where Product is a domain-specific class. In this case, the task is submited for execution as:

Future<Product> f2 = executor.submit(new MyCallableTask(3));

A ManagedScheduledExecutorService can be created as:

asadmin create-managed-scheduled-executor-service concurrent/myScheduledExecutor
Managed scheduled executor service concurrent/myScheduledExecutor created successfully.
Command create-managed-scheduled-executor-service executed successfully.

A ManagedThreadFactory can be created as:

asadmin create-managed-thread-factory concurrent/myThreadFactory
Managed thread factory concurrent/myThreadFactory created successfully.
Command create-managed-thread-factory executed successfully.

A ContextService can be created as:

asadmin create-context-service concurrent/myContextService
Context service concurrent/myContextService created successfully.
Command create-context-service executed successfully.

Note, this is the first integration and some of the options may not work. But you can definitely start playing around with basic stuff now.

The complete source code used in this Tip Of The Day (TOTD) is available here and will run on GlassFish 4 b74.

Resource Library Contracts in JSF2.2 (TOTD #202)

2013-02-08T09:33:45+00:00

JavaServer Faces 2 introduced Facelets as the default View Declaration Language. Facelets allows to create templates using XHTML and CSS that can be then used to provide a consistent look-and-feel across different pages of an application. JSF 2.2 defines Resource Library Contracts that allow facelet templates to be applied to an entire application in a reusable and interchangeable manner.

This Tip Of The Day (TOTD) will explain how you can leverage them in your web application.

The complete source code for this sample can be downloaded here. This will run on GlassFish build 72 + latest JSF 2.2.0 SNAPSHOT copied over "glassfish3/glassfish/modules/javax.faces.jar" file.

Consider the following WAR file:

index.xhtml
user/index.xhtml
contracts/blue/layout.css
contracts/blue/template.xhtml
contracts/red
contracts/red/layout.css
contracts/red/template.xhtml
WEB-INF/faces-config.xml

The application also has two pages - "index.xhtml" and "user/index.xhtml". All contracts reside in the "contracts" directory of the WAR. All templates and resources for a contract are in their own directory. For example, the structure above has two defined contracts "blue" and "red". Each contract has a "template.xhtml" and a CSS. Each template is called as "declared template". The "template.xhtml" has <ui:insert> tags called as "declared insertion points". CSS and other resources bundled in the directory are "declared resources". The "declared template", "declared insertion points", and "declared resources" together make the definition of the resource library contract. A template client needs to know the value of all three in order to use the contract.

In our case, templates have similar "ui:insert" sections and template clients will accordingly have "ui:define" sections. The difference will primarily be in the CSS. "index.xhtml" will refer to the template as:

<ui:composition template="/template.xhtml">
 <ui:define name="content">
 . . .
 </ui:define>
</ui:composition>

The usage of the contracts is defined in "faces-config.xml" as:

<application>
 <resource-library-contracts>
 <contract-mapping>
 <url-pattern>/user/*</url-pattern>
 <contracts>blue</contracts>
 </contract-mapping>
 <contract-mapping>
 <url-pattern>*</url-pattern>
 <contracts>red</contracts>
 </contract-mapping>
 </resource-library-contracts>
</application>

A contract is applied based upon the URL pattern invoked. Based upon the configuration specified here, "red" contract will be applied to "faces/index.xhtml" and "red" contract will be applied to "faces/user/index.xhtml".

The template of the page can be changed dynamically as well. For example consider "index.xhtml" is updated as:

<f:view contracts="#{contractsBean.contract}">
 <ui:composition template="/template.xhtml">

 <ui:define name="content">
 <a href="#{facesContext.externalContext.requestContextPath}/faces/user/index.xhtml">Go to</a> other contract
 <p/>
 Look at WEB-INF/faces-config.xml for contract configuration.
 <p/><p/>
 Choose a template:<br/>
 <h:form>
 <h:selectOneRadio value="#{contractsBean.contract}" layout="pageDirection" required="true">
 <f:selectItem itemValue="red" itemLabel="red"/>
 <f:selectItem itemValue="blue" itemLabel="blue"/>
 </h:selectOneRadio>
 <h:commandButton value="Apply" action="index" />
 </h:form>
 </ui:define>

 </ui:composition>
</f:view>

The "ui:composition" is included in "f:view". An additional "contracts" attribute can bind to an EL. The value of this EL is populated from the radio button in the newly added form. Now you can choose a radio button, click on the "Apply" button and the new template will be applied to the page. The bean is very trivial:

@Named
@SessionScoped
public class ContractsBean implements Serializable {
 
 String contract = "red";

 public String getContract() {
 return contract;
 }

 public void setContract(String contract) {
 this.contract = contract;
 }
}

This is a very powerful feature. Imagine providing different look-and-feel for your website and letting the user choose them, fun eh ?

Contracts may be packaged as a JAR file. Such a JAR file maybe bundled in "WEB-INF/lib" directory. Read section 2.7 for more details about the packaging requirement and a marker file that identifies the JAR to contain a contract.

In the specification ...

Section 10.1.3 provide background on the feature.
Section 2.7 provide formal definition of the feature.
Section 11.4.2.1 defines how the contracts are identified during application startup.

Create templates as JAR files and reuse them across different applications, enjoy!

Jfokus 2013 Trip Report - A Magnificent Spectacle

2013-02-07T09:44:18+00:00

This was my third consecutive year (2012, 2011) at Jfokus and the organizing committee, and Mattias Karlsson in particular, continue to amaze me every year! As one of my colleague mentioned, it truly has become a "magnificent spectacle".

With the conference sold out 2 weeks before the official start, 1550 attendees from 20+ countries were delighted by a barrage of international speakers. This was the biggest Jfokus ever and the bar has always gone higher from the previous years.

The conference kickstarted with a guided tour of Old Town Stockholm and was a good way to get familiar with history of the city.

The conference had hands-on lab on the first day and technical sessions, BoFs, HackerGarten, NightHacking, Swedish massage by Mejsla and other activities on day 2 and 3. Even though the conference had several tracks but the best track is always the "hallway track" which gives you the unique opportunity to engage with other attendees of the conference.

Markus and I delivered a lab on "Developing JAX-RS Web Applications Utilizing Server-sent Events and WebSockets". Geertjan also showed up at the lab and helped out with general NetBeans questions. The lab guide is available and the complete source code can be downloaded here. Note, the lab works on GlassFish 4.0 build 57 for now because of the pending bugs in SSE implementation in Jersey.

The last 45 minutes of the lab had a different section covering some other Java EE 7 technologies. The lab guide is available at bit.ly/javaee7-hol (PDF) and the starting code is available at bit.ly/javaee7-hol-code (ZIP). For now, this particular lab covers:

This lab is a work in progress and a more comprehensive feature set will be integrated and shared at future conferences (yes, several are already planned!). Let me know if you'll be interested in reviewing the contents and providing feedback.

Here are some pics from the lab session:

The conference also had its first #GeekRun. 7 of us ran in sub-zero temperature in the dark around the island and it was a great experience!

Here is the running route:

The evening concluded with an outstanding speakers' dinner at F12. The hospitality of the restaurant, warmth of the Jfokus events team, and company of some of the finest geeks in the world made the evening memorable. Some pics from the dinner ...

I delivered a session on The Java EE 7 Platform: Productivity++ and Embracing HTML5. There were about 100+ attendees for the 9am session. It gave a quick overview of the features coming in Java EE 7:

Java API for WebSocket
Java API for JSON Processing
Concurrency Utilities for Java EE
Batch Applications for Java Platform
JAX-RS 2.0
JMS 2

And several other technologies which are getting an update. The complete slides are available:

The session also showed a quick demo of the latest NetBeans build supporting Java EE 7.

In How to participate in the future of Java, I talkd about how several JUGs are contributing to Adopt-a-JSR efforts around Java EE 7. There are 19 JUGs from around the world that are participating in this effort. What is your JUG waiting for ? Join the momentum now!

Here are some more pictures from the conference:

The conference collected feedback for each talk using green, red, and yellow cards, a concept first found in Oredev. As explained in the opening keynote, the rule is getting green cards is good, yelllow card means so so and red card means the speaker is not coming back to the conference. Here are the cards that I received after my talk on Java EE 7:

I've heard the rumor that Nordic conferences don't like to repeat speakers for more than 2-3 years in a row. This was my third year but hey, the cards are all green. I'm keeping my fingers crossed for next year ;-)

Anyway, congratulations once again Mattias and team for a job very well done!

And the complete photo album:

Java EE 7 Maven Archetype - Available in NetBeans (TOTD #201)

2013-02-02T05:40:25+00:00

Want to create a Java EE 7 application using Maven ?

mvn -DarchetypeGroupId=org.codehaus.mojo.archetypes -DarchetypeArtifactId=webapp-javaee7 -DarchetypeVersion=0.1-SNAPSHOT -DarchetypeRepository=https://nexus.codehaus.org/content/repositories/snapshots/ -DgroupId=org.glassfish -DartifactId=javaee7-sample -Dversion=1.0-SNAPSHOT -Dpackage=org.glassfish.javaee7-sample -Darchetype.interactive=false --batch-mode --update-snapshots archetype:generate
[INFO] Scanning for projects...
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml
Downloaded: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml (11 KB at 42.6 KB/sec)
Downloaded: http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml (22 KB at 65.6 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/maven-metadata.xml
Downloaded: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/maven-metadata.xml (701 B at 4.3 KB/sec)
[INFO]
[INFO] ------------------------------------------------------------------------
[INFO] Building Maven Stub Project (No POM) 1
[INFO] ------------------------------------------------------------------------
Downloading: http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml
Downloaded: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-metadata.xml (11 KB at 64.9 KB/sec)
Downloaded: http://repo1.maven.org/maven2/org/codehaus/mojo/maven-metadata.xml (22 KB at 77.8 KB/sec)
Downloading: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/maven-metadata.xml
Downloaded: http://repo1.maven.org/maven2/org/apache/maven/plugins/maven-archetype-plugin/maven-metadata.xml (701 B at 3.1 KB/sec)
[INFO]
[INFO] >>> maven-archetype-plugin:2.2:generate (default-cli) @ standalone-pom >>>
[INFO]
[INFO] <<< maven-archetype-plugin:2.2:generate (default-cli) @ standalone-pom <<<
[INFO]
[INFO] --- maven-archetype-plugin:2.2:generate (default-cli) @ standalone-pom ---
[INFO] Generating project in Batch mode
[INFO] Archetype defined by properties
Downloading: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/archetypes/webapp-javaee7/0.1-SNAPSHOT/maven-metadata.xml
Downloaded: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/archetypes/webapp-javaee7/0.1-SNAPSHOT/maven-metadata.xml (786 B at 0.5 KB/sec)
Downloading: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/archetypes/webapp-javaee7/0.1-SNAPSHOT/maven-metadata.xml
Downloaded: https://nexus.codehaus.org/content/repositories/snapshots/org/codehaus/mojo/archetypes/webapp-javaee7/0.1-SNAPSHOT/maven-metadata.xml (786 B at 2.0 KB/sec)
[INFO] ----------------------------------------------------------------------------
[INFO] Using following parameters for creating project from Archetype: webapp-javaee7:0.1-SNAPSHOT
[INFO] ----------------------------------------------------------------------------
[INFO] Parameter: groupId, Value: org.glassfish
[INFO] Parameter: artifactId, Value: javaee7-sample
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: package, Value: org.glassfish.javaee7-sample
[INFO] Parameter: packageInPathFormat, Value: org/glassfish/javaee7-sample
[INFO] Parameter: package, Value: org.glassfish.javaee7-sample
[INFO] Parameter: version, Value: 1.0-SNAPSHOT
[INFO] Parameter: groupId, Value: org.glassfish
[INFO] Parameter: artifactId, Value: javaee7-sample
[INFO] project created from Archetype in dir: /Users/arungup/code/workspaces/tmp/javaee7-sample
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 4.703s
[INFO] Finished at: Sat Feb 02 07:31:54 EET 2013
[INFO] Final Memory: 11M/125M
[INFO] ------------------------------------------------------------------------

That's it!

NetBeans Development Builds allows to create a Maven-based Java EE 7 web application now. wiki.netbeans.org/JavaEE7 provide a complete list of planned features. TOTD #199 provide some more details on the features currently working. Of course, this application will get deployed to GlassFish 4.

GlassFish 4 Latest Builds, Zip, API, and Javadocs (TOTD #200)

2013-01-30T12:00:00+00:00

Do you want a handy link to the latest GlassFish builds, zip bundles, Java EE 7 API jar or javadocs ?

Now they are available at download.java.net/glassfish/4.0/promoted!

The pattern is: download.java.net/glassfish/4.0/promoted/latest-*.

So download.java.net/glassfish/4.0/promoted/latest-glassfish.zip gives you the latest GlassFish zip bundle. Similarly download.java.net/glassfish/4.0/promoted/latest-javaee-api-javadoc.jar gives you the latest Java EE 7 javadocs and download.java.net/glassfish/4.0/promoted/latest-web-unix.sh gives you the latest Unix installer for Java EE 7 Web profile. These are all in turn link to the latest promoted build.

The complete set of promoted builds are available as usual at download.java.net/glassfish/4.0/promoted. And the nightly builds at download.java.net/glassfish/4.0/nightly.

What is your favorite location to download GlassFish builds ?

Java EE 7 and NetBeans IDE - Early Support Available (TOTD #199)

2013-01-29T18:38:31+00:00

NetBeans IDE provides the best out-of-the-box experience for Java EE development, deployment, and debugging. Early builds of NetBeans have already started providing support for Java EE 7 features such as

Registering GlassFish 4
Creating Java EE 7 application
Wizard for JAX-RS 2 Filters/Interceptors
Initial support for Faces Flow
Loading templates from a resource library
Non-persistent EJB timers in Web profile
Wizard for WebSocket endpoints

wiki.netbeans.org/JavaEE7 provide a complete list of features slated for the release and the builds can be downloaded from bertram2.netbeans.org:8080/job/web-main-javaee7. Here are some snapshots of the work completed so far.

Creating a Java EE 7 Web application and using GlassFish 4 server

Creating a WebSocket endpoint

Wizard for creating WebSocket endpoint

The generated code looks like:

@WebSocketEndpoint("/endpoint")
public class NewWSEndpoint {

 @WebSocketMessage
 public String onMessage(String message) {
 return null;
 }
 
}

Creating a JAX-RS 2 Filter

Wizard for creating a JAX-RS 2 Filter

By default it is a server-side filter but can be made client-side filter too.

Wizard for creating a JAX-RS 2 Interceptor

Creating a RESTful Java Client using JAX-RS 2 Client APIs

Wizard for creating a JAX-RS 2 Client

This is a very early work-in-progress so any feedback is welcome.

Download GlassFish 4.0 promoted build, register it with NetBeans IDE and take it for a test drive!

JSF 2.2 Faces Flow - @FlowScoped, #{flowScope}, @FlowDefinition (TOTD #198)

2013-01-28T23:03:16+00:00

JavaServer Faces 2.2 is more evolutionary than it is revolutionary. This is by design as JSF 2.0 added a whole bunch of new features as part of the Java EE 6 platform. The Preface 1 from the JSF 2.2 Public Review specification provides a list of changes between JSF 2.1 and 2.2. There are several changes coming in JSF 2.2 but the big ticket items are:

Faces Flow
Resource Library Contract
HTML5 Friendly Markup

This Tip Of The Day (TOTD) will explain Faces Flow. Section 7.5 and 11.4.3 in the specification introduce the feature.

Faces Flow provides an encapsulation of related views/pages with an application defined entry and exit points. For example, a check out cart can consist of cart page, credit card details page, shipping address page, and confirmation page. All these pages, along with required resources and beans, can be packaged together as a module which can then be reused in other applications.

Each flow has a well-defined entry and exit point that have been assigned some application specific meaning by the developer. Usually the objects in a faces flow are designed to allow the user to accomplish a task that requires input over a number of different views. In our case, the navigation between pages for selecting items, entering shipping address, credit card details, and confirmation page would make a flow. All the pages and objects that deal with the checking out process can be composed as modules. An application thus become a collection of flows instead of just views.

It takes the best part of other flow-based technologies such as ADF Task Flow, Spring Web Flow, and Apace MyFaces CODI and standardizes in JSF 2.2.

What is the need ?

Imagine a multi-page shopping cart with one page for selecting the items, a second page for shipping options, a third page for entering credit card details, and a fourth page for final confirmation. Managed Beans can be used to capture the data, session scope variables pass information between pages, button clicks can be used to invoke the business logic in backing EJBs, and (conditional) navigation rules can be defined to go from one page to another. There are a few issues with this approach:

This flow of sequence will typically be part of a bigger application. However an application, typically with several pages, is one large flow and everything is visible with no logical partitioning.
The flow of pages or views cannot be encapsulated as a logical unit and thus cannot be reused, e.g. incorporated into another bigger flow easily.
The lowest logical granularity is a page. The only way to invoke application logic is to tie it to a UI component activated by the user in a page. Business logic cannot be invoked without any user initiated action.
Same flow cannot be opened in multiple windows because session scoped variables are used to pass information between pages. CDI defines @ConversationScoped but that is only part of the solution.
There is no scope defined that can span multiple pages but less than a session.

Faces Flow provide a solution to the issues mentioned above.

What's new in JSF 2.2 for flows ?

The flow of application is no longer restricted to flow between pages but instead defined as flow between "nodes". There are five different types of nodes:

View: Any JSF page in the application
Method Call: Invoke application logic from flow graph via an EL
Switch: Navigation decisions in the flow graph based on boolean EL
Flow Call: Call another flow with parameters and receive return values
Flow Return: Return to the calling flow

The nodes define the entry and exit points of a flow.

Two new annotations are introduced:

@FlowScoped is a CDI scope that defines the scope of bean in the specified flow. This enables automatic activation/passivation of the bean when the scope is entered/exited.
@FlowDefinition is a class level annotation that allows the flow definition to be defined using the fluent FlowBuilder API.

A new EL object, #{flowScope}, for flow local storage is also introduced. This maps to facesContext.getApplication().getFlowHandler().getCurrentFlowScope().

How are flows packaged ?

Flows can be packaged in JAR files or in directories.

JAR packaging requires flows to be explicitly declared in META-INF/faces-config.xml in the JAR file. Flow nodes are packaged in META-INF/flows/<flowname> where <flowname> is a JAR directory entry whose name is identical to that of a flow id in the corresponding faces-config.xml. @FlowScoped and @FlowDefinition beans must be packaged in the JAR file and accompanied by META-INF/beans.xml.

A sample JAR file looks like:

META-INF/faces-config.xml
META-INF/flows/flow1/entry.xhtml
META-INF/flows/flow1/next.xhtml
META-INF/flows/flow1/end.xhtml
META-INF/flows/flow2/start.xhtml
META-INF/flows/flow2/next.xhtml
META-INF/flows/flow2/end.xhtml
META-INF/beans.xml
org/glassfish/sample/MyFlow1Bean.class
org/glassfish/sample/MyFlow2Bean.class
org/glassfish/sample/MyFlowDefintion.class

Flows packaged in directories use convention-over-configuration. The conventions are:

Every View Declaration Language file in that directory is a view node of that flow.
The start node of the flow is the view whose name is the same as the name of the flow.
Navigation among any of the views in the directory is considered to be within the flow.
Navigation to a view outside of that directory is considered to be an exit of the flow.
Optional <flowname>-flow.xml that represents the flow definition. The rules in this file overrides the conventions described above.

A sample directory looks like:

flow1/flow1.xhtml
flow1/flow1a.xhtml
flow1/flow1b.xhtml
flow2/flow2-flow.xml
flow2/flow2.xhtml
flow2/flow2a.xhtml
flow2/flow2b.xhtml
WEB-INF/...

Show me the code!

Lets try a sample now!

The source code for the two samples explained below can be downloaded here. A complete explanation of the sample including the code walk-through is shown in the video:

This will run on GlassFish 4.0 b72. For now, you'll need to replace glassfish/modules/javax.faces.jar with javax.faces-2.2.0-SNAPSHOT.jar and replacing glassfish/modules/javax.el.jar with javax-el-3.0-b03.jar. This JARs will soon be integrated in the GlassFish build. Ah, the joys of bleeding edge development!

Java EE 7 Maven Application (TOTD #197)

2013-01-26T14:39:39+00:00

Did you know that Java EE 7 APIs are now published in maven ?

The complete set of coordinates are described here. So how do you build a simple Java EE 7 maven application ?

Generate the ususal Java EE 6 maven application as:

mvn -DarchetypeGroupId=org.codehaus.mojo.archetypes -DarchetypeArtifactId=webapp-javaee6 -DarchetypeVersion=1.5 -DarchetypeRepository=http://repo.maven.apache.org/maven2 -DgroupId=org.glassfish -DartifactId=hello-javaee7 -Dversion=1.0-SNAPSHOT -Dpackage=org.glassfish.hellojavaee7 -Darchetype.interactive=false --batch-mode archetype:generate

In the generated pom.xml, replace

<dependencies>
 <dependency>
 <groupId>javax</groupId>
 <artifactId>javaee-web-api</artifactId>
 <version>6.0</version>
 <scope>provided</scope>
 </dependency>
</dependencies>

with

<repositories>
 <repository> 
 <id>Java EE 7</id> 
 <url>https://maven.java.net/content/groups/promoted/</url> 
 </repository> 
</repositories>

<dependencies>
 <dependency> 
 <groupId>javax</groupId> 
 <artifactId>javaee-api</artifactId> 
 <version>7.0-b72</version> 
 </dependency> 
</dependencies>

Notice, there is a new <version> of dependency for each GlassFish 4 promoted build. This may be simplified in the coming builds.

The <artifactId> can be changed to javaee-web-api if your application requires Java EE 7 Web Profile API only.

And now all Java EE 7 APIs so far integrated in GlassFish are available in your application.

You can also include specific API JAR files explicitly in your project directly. The latest APIs are available in the format:

Java EE 7 Full Platform: http://download.java.net/glassfish/4.0/promoted/javaee-api-7.0-b72.jar
Java EE 7 Web Profile: http://download.java.net/glassfish/4.0/promoted/javaee-web-api-7.0-b72.jar
Corresponding javadocs: http://download.java.net/glassfish/4.0/promoted/javaee-web-api-7.0-b72-javadoc.jar

In general, you can replace "b72" in the URL with the latest promoted build number to get the latest artifacts. A simplified URL for the latest set of these artifacts is in the works!

What next ? Maven archetype and support in NetBeans coming soon!

Default DataSource in Java EE 7: Lesser XML and More Defaults (TOTD #196)

2013-01-23T07:30:00+00:00

Section E.5.5.20 in the Java EE 7 Platform specification defines a new Default Data Source that must be provided by a Java EE 7-compliant runtime. This pre-configured data source can be used by application for accessing the associated database. It is accessible to the application under the JNDI name:

java:comp/DefaultDataSource

This can be accessed in the application as:

@Resource(name="myDataSource", lookup="java:comp/DefaultDataSource")
DataSource myDS;

If the binding is not specified, the mapping of the reference will default to this default data source. So the above fragment is equivalent to:

@Resource(name="myDataSource")
DataSource myDS;

Section 8.2.1.5 in the JPA 2.1 specification says

If neither jta-data-source and non-jta-data-source elements are specified, the deployer must specify a JTA data source at deployment or a JTA data source must be provided by the container, and a JTA EntityManagerFactory will be created to correspond to it.

Per.book
This means a Java EE 7 application can have the following persistence.xml:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
 <persistence-unit name="myPU" transaction-type="JTA">
 <jta-data-source>java:comp/DefaultDataSource</jta-data-source>
 </persistence-unit>
</persistence>

This is semantically equivalent to:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
 <persistence-unit name="movieplex7PU" transaction-type="JTA"/>
</persistence>

Notice, no jta-data-source.

In both cases, the default data source will be provisioned and available to the application. In GlassFish 4, this is bound to the JDBC resource jdbc/__default.

And this can be verified by giving the command:

./bin/asadmin list-jdbc-resources
jdbc/sample
jdbc/__TimerPool
jdbc/__default
Command list-jdbc-resources executed successfully.

Lesser XML and more defaults makes Java EE 7 more lightweight and user friendly!

Download GlassFish 4.0 promoted build and try it today!

JPA 2.1 Implementation - EclipseLink M6 integrated in GlassFish 4 (TOTD #195)

2013-01-18T22:46:29+00:00

As TOTD #187 explained, one of the new features in JPA 2.1 is Schema Generation. It refers to generation of database artifacts like tables, indexes, and constraints in a database schema. Read TOTD #187 for more details. This Tip Of The Day (TOTD) will explain how to use this feature in GlassFish 4.

JPA 2.1 is implemented in EclipseLink and the status shows that a decent progress is made. EclipseLink Milestone builds shows the dates when milestones are released. It typically takes a few days for the milestone to be integrated in GlassFish 4 after the release.

How do you know which milestone is integrated in GlassFish 4 ?

Issue the following commmand in glassfish/modules directory:

unzip -p org.eclipse.persistence.core.jar META-INF/MANIFEST.MF | grep Bundle-Version

to see an output as:

Bundle-Version: 2.5.0.v20130110-d839ca4

If we break the version string then it shows this is version 2.5.0 and dated 20130110 in the format YYYYMMDD, that would be Jan 10, 2013. Based upon the milestone release dates, this indicates M6 is integrated.

I tried this with the latest nightly build (dated Jan 18). By the time you read this blog, a newer version may be integrated and so the version string may look different.

Now lets see this in action!

The sample code explained below can be downloaded here and run on GlassFish 4 1/17 nightly. A promoted build after this nightly should work too.

Create an Entity class as:

@Entity
@Table
@NamedQueries({
 @NamedQuery(name = "Employee.findAll", query = "SELECT e FROM Employee e")
})
public class Employee implements Serializable {
 private static final long serialVersionUID = 1L;
 @Id
 @GeneratedValue(strategy = GenerationType.AUTO)
 private int id;
 
 @Column(length=40)
 private String name;

This is a simple Employee entity that has two fields id and name. A trivial @NamedQuery is defined to retrieve the list of employees.

The associated persistence.xml looks like:

<?xml version="1.0" encoding="UTF-8"?>
<persistence version="2.0" xmlns="http://java.sun.com/xml/ns/persistence" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://java.sun.com/xml/ns/persistence http://java.sun.com/xml/ns/persistence/persistence_2_0.xsd">
 <persistence-unit name="MyPU" transaction-type="JTA">
 <jta-data-source>jdbc/sample</jta-data-source>
 <properties>
 <property name="javax.persistence.schema-generation-action" value="drop-and-create"/>
 <property name="javax.persistence.schema-generation-target" value="database"/> 
 <property name="eclipselink.deploy-on-startup" value="true"/>
 </properties>
 </persistence-unit>
</persistence>

Other than the usual elements like <persistence-unit> and <jta-data-source>, the newly introduced properties - javax.persistence.schema-generation-action and javax.persistence.schema-generation-target define the action and target for the schema generation. The action is to drop and create the tables. The target defines to perform the action in the database. These properties control the behavior of schema generation and their meaning is defined in TOTD #187. Notice, the third property is EclipseLink specific and is specified to eagerly initialize the Persistence Unit. This will ensure that the schema is generated during the application deployment itself. Otherwise it is generated when the PU is first accessed.

This will generate the table in the database defined by jdbc/sample JDBC resource. This resource is pre-defined for JavaDB that is already bundled with GlassFish 4.

After this, you can write a simple EJB as:

@Stateless
public class EmployeeBean {

 @PersistenceContext
 EntityManager em;
 
 public void persist(Employee e) {
 em.persist(e);
 }
 
 public List<Employee> get() {
 return em.createNamedQuery("Employee.findAll", Employee.class).getResultList();
 }
}

And invoke it from a Servlet as:

for (int i=0; i<5; i++) {
 bean.persist(new Employee("Name" + i));
}
for (Employee e : bean.get()) {
 out.println(e.getName() + "<br>");
}

A different set of properties may be specified as:

<properties>
 <property name="javax.persistence.schema-generation-action" value="drop-and-create"/>
 <property name="javax.persistence.schema-generation-target" value="scripts"/> 
 <property name="javax.persistence.ddl-create-script-target" value="createfoo.sql"/> 
 <property name="javax.persistence.ddl-drop-script-target" value="dropfoo.sql"/> 
 <property name="eclipselink.deploy-on-startup" value="true"/>
 <property name="eclipselink.application-location" value="/tmp"/>
</properties>

These properties specify the action as "drop-and-create", i.e. drop and create the tables. The target specifies the the action to be performed in a script. The *.script-target property specifies the name of the files for create and drop DDL. The following scripts are generated:

more /tmp/createfoo.sql 
CREATE TABLE EMPLOYEE (ID INTEGER NOT NULL, NAME VARCHAR(40), PRIMARY KEY (ID))
CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT DECIMAL(15), PRIMARY KEY (SEQ_NAME))
INSERT INTO SEQUENCE(SEQ_NAME, SEQ_COUNT) values ('SEQ_GEN', 0)
CREATE TABLE SEQUENCE (SEQ_NAME VARCHAR(50) NOT NULL, SEQ_COUNT DECIMAL(15), PRIMARY KEY (SEQ_NAME))
INSERT INTO SEQUENCE(SEQ_NAME, SEQ_COUNT) values ('SEQ_GEN', 0)

more /tmp/dropfoo.sql 
DROP TABLE EMPLOYEE
DELETE FROM SEQUENCE WHERE SEQ_NAME = 'SEQ_GEN'

By default, the scripts are generated in glassfish/domains/domain1 directory. In this case, an EclipseLink-specific property to identify the base location of the generated files is specified.

As TOTD #187 explains, you can bundle DDL and DML scripts to generate and populate the database. Are you ready to test drive JPA 2.1 implemented using EclipseLink 2.5 in GlassFish 4 ?

JPA 2.1 Public Review specification has been available for a few days now. The Appendix A in the specification provide revision history in case you want to focus on the newly added features only. If you are a JUG member, you may consider adopting this JSR and provide feedback!

JAX-RS Client API and GlassFish 4 - Logging HTTP messages (TOTD #194)

2013-01-11T22:32:18+00:00

One of the main features added in JAX-RS 2 is Client API. This API is used to access Web resources and provides integration with JAX-RS Providers. Without this API, the users need to use a low-level HttpUrlConnection to access the REST endpoint.

If the resource looks like:

@Path("/fruit")
public class MyResource {

 @GET
 public String get() {

then, before this API, the endpoint can be accessed as:

URL url = new URL("http://. . ./webresources/fruit");
HttpURLConnection conn = (HttpURLConnection) url.openConnection();
conn.setRequestMethod("GET");
conn.setDoInput(true);
conn.setDoOutput(false);
BufferedReader br = new BufferedReader(new InputStreamReader(conn.getInputStream()));
String line;
while ((line = br.readLine()) != null) {
    //. . .
}

With this newly introduced API, the endpoint can be accessed as:

Client client = ClientFactory.newClient();
WebTarget target = client.target("http://. . ./webresources/fruit");
String response = target.request().get(String.class);

Client is the entry point to the Client API and is used to build and execute client requests and consume responses returned. The default instance of Client can be obtained by calling ClientFactory.newClient. Using this we can create a WebTarget by specifying URI of the web resource. These targets are then used to prepare client request invocation by specifying additional query or matrix parameters and resolving the URI template for different names. Finally, one of the HTTP methods is invoked on the prepared client.

The fluency of the API hides the complexity but a better understanding of the flow allows to write better code.

All the classes introduced in the specification are available in javax.ws.rs.client package.

Lets take a look at a complete sample. The complete source code can be downloaded here.

For a resource defined as:

@Path("/fruit")
public class MyResource {

 @GET
 public String get() {
 return Database.getAll();
 }
 
 @GET
 @Path("{name}")
 public String get(@PathParam("name")String payload) {
 return Database.get(payload);
 }
 
 @POST
 public void post(String payload) {
 Database.add(payload);
 }
 
 @PUT
 public void put(String payload) {
 Database.add(payload);
 }
 
 @DELETE
 public void delete(String payload) {
 Database.delete(payload);
 }
}

A Client invoking all the HTTP methods look like:

Client client = ClientFactory.newClient();
WebTarget target = client.target("http://" 
 + request.getServerName() 
 + ":"
 + request.getServerPort()
 + request.getContextPath()
 + "/webresources/fruit");

// POST
target.request().post(Entity.text("apple"));

// PUT
target.request().put(Entity.text("banana"));

// GET (all)
String r = target.request().get(String.class);

// GET (one)
r = target.path("apple").request().get(String.class);

// DELETE
target.path("banana").request().delete();

// GET (all)
r = target.request().get(String.class);

And here are the message dumps:

INFO: 1 * LoggingFilter - Request received on thread http-listener-1(5)
1 > POST http://localhost:8080/endpoint/webresources/fruit
1 > Content-Type: text/plain
apple

INFO: 2 * LoggingFilter - Response received on thread http-listener-1(5)
2 < 204
2 < Date: Fri, 11 Jan 2013 22:21:23 GMT
2 < Server: GlassFish Server Open Source Edition 4.0
2 < X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 4.0 Java/Oracle Corporation/1.7)

INFO: 3 * LoggingFilter - Request received on thread http-listener-1(5)
3 > PUT http://localhost:8080/endpoint/webresources/fruit
3 > Content-Type: text/plain
banana

INFO: 4 * LoggingFilter - Response received on thread http-listener-1(5)
4 < 204
4 < Date: Fri, 11 Jan 2013 22:21:23 GMT
4 < Server: GlassFish Server Open Source Edition 4.0
4 < X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 4.0 Java/Oracle Corporation/1.7)

INFO: 5 * LoggingFilter - Request received on thread http-listener-1(5)
5 > GET http://localhost:8080/endpoint/webresources/fruit

INFO: 6 * LoggingFilter - Response received on thread http-listener-1(5)
6 < 200
6 < Date: Fri, 11 Jan 2013 22:21:23 GMT
6 < Content-Length: 15
6 < Content-Type: text/html
6 < Server: GlassFish Server Open Source Edition 4.0
6 < X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 4.0 Java/Oracle Corporation/1.7)
[apple, banana]

INFO: 7 * LoggingFilter - Request received on thread http-listener-1(5)
7 > GET http://localhost:8080/endpoint/webresources/fruit/apple

INFO: 8 * LoggingFilter - Response received on thread http-listener-1(5)
8 < 200
8 < Date: Fri, 11 Jan 2013 22:21:23 GMT
8 < Content-Length: 5
8 < Content-Type: text/html
8 < Server: GlassFish Server Open Source Edition 4.0
8 < X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 4.0 Java/Oracle Corporation/1.7)
apple

INFO: 9 * LoggingFilter - Request received on thread http-listener-1(5)
9 > DELETE http://localhost:8080/endpoint/webresources/fruit/banana

INFO: 10 * LoggingFilter - Response received on thread http-listener-1(5)
10 < 204
10 < Date: Fri, 11 Jan 2013 22:21:23 GMT
10 < Server: GlassFish Server Open Source Edition 4.0
10 < X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 4.0 Java/Oracle Corporation/1.7)

INFO: 11 * LoggingFilter - Request received on thread http-listener-1(5)
11 > GET http://localhost:8080/endpoint/webresources/fruit

INFO: 12 * LoggingFilter - Response received on thread http-listener-1(5)
12 < 200
12 < Date: Fri, 11 Jan 2013 22:21:23 GMT
12 < Content-Length: 7
12 < Content-Type: text/html
12 < Server: GlassFish Server Open Source Edition 4.0
12 < X-Powered-By: Servlet/3.0 JSP/2.2 (GlassFish Server Open Source Edition 4.0 Java/Oracle Corporation/1.7)
[apple]

This has been tested on GlassFish 4 build 70 with the following dependencies:

<dependency>
 <groupId>javax.ws.rs</groupId>
 <artifactId>javax.ws.rs-api</artifactId>
 <version>2.0-m10</version>
 <type>jar</type>
 <scope>provided</scope>
</dependency>
<dependency>
 <groupId>org.glassfish.jersey.core</groupId>
 <artifactId>jersey-common</artifactId>
 <version>2.0-m10</version>
 <type>jar</type>
</dependency>

Here are some more pointers to follow:

JAX-RS 2 Specification Public Review
Latest status on specification (jax-rs-spec.java.net)
Latest JAX-RS 2.0 Javadocs
Latest status on Jersey (Reference Implementation of JAX-RS 2 - jersey.java.net)
Latest Jersey API Javadocs
Latest GlassFish 4.0 Promoted Build
Follow @gf_jersey

Provide feedback on Jersey 2 to users@jersey.java.net and JAX-RS specification to users@jax-rs-spec.java.net.

JAX-RS Custom Entity Providers (TOTD #193)

2013-01-07T21:49:52+00:00

JAX-RS defines Entity Providers that supply mapping services between on-the-wire representations and their associated Java types. The entities, also known as "message payload" or "payload" represent the main part of an HTTP message. These are specified as method parameters and return types of resource methods. Several standard Java types such as String, byte[], javax.xml.bind.JAXBElement, java.io.InputStream, java.io.File, and others have a pre-defined mapping and is required by the specification. Applications may provide their own mapping to custom types using MessageBodyReader and MessageBodyWriter interfaces. This allows to extend the JAX-RS runtime easily to support your own custom entity providers.

The MessageBodyReader interface defines the contract for a provider that supports the conversion of a stream to a Java type. The MessageBodyWriter interface defines the contract for a provider that supports the conversion of a Java type to a stream. This Tip Of The Day (TOTD) will explain how to write these custom entity providers.

Note, this functionality was defined in JAX-RS 1.0 as opposed to Client API, Client- and Server-side async, Hypermedia, and many other features. The complete source code for this sample application can be downloaded here and will work on GlassFish 4.0 b70.

Here is a simple resource that returns name of the fruit based upon the index passed as parameter:

@Path("fruits")
public class MyResource {
 private String[] response = { "apple", "banana", "mango" };
 
 @POST
 public String getFruit(int index) {
 return response[index % 3];
 }
}

This resource can be invoked using the newly introduced Client API as:

Client client = ClientFactory.newClient();
WebTarget target = client.target("http://"
 + request.getServerName()
 + ":"
 + request.getServerPort()
 + request.getContextPath()
 + "/webresources/fruits");
String fruit = target
 .request()
 .post(Entity.text("1"), String.class);

If we update the resource such that the index parameter is passed as the following object:

public class MyObject implements Serializable {
 public static final String MIME_TYPE = "application/myType";

 private int index;

 public MyObject() {
 }

 public MyObject(int index) {
 this.index = index;
 }

 public int getIndex() {
 return index;
 }

 public void setIndex(int index) {
 this.index = index;
 }
}

Then the resource method would look like:

@POST
@Consumes(value=MyObject.MIME_TYPE)
public String getFruit(MyObject mo) {
 return response[Integer.valueOf(mo.getIndex()) % 3];
}

The additional @Consumes annotation defines the media type that the method can accept. The following custom entity providers are defined to support this custom type. The first one, MyReader, defines the conversion of on-the-wire representation to MyObject Java type.

@Provider
@Consumes(MyObject.MIME_TYPE)
public class MyReader implements MessageBodyReader<MyObject> {

 @Override
 public boolean isReadable(Class<?> type, Type type1, Annotation[] antns, MediaType mt) {
 return MyObject.class.isAssignableFrom(type);
 }

 @Override
 public MyObject readFrom(Class<MyObject> type, 
 Type type1, 
 Annotation[] antns, 
 MediaType mt, MultivaluedMap<String, String> mm, 
 InputStream in) throws IOException, WebApplicationException {
 try {
 ObjectInputStream ois = new ObjectInputStream(in);
 return (MyObject)ois.readObject();
 } catch (ClassNotFoundException ex) {
 Logger.getLogger(MyReader.class.getName()).log(Level.SEVERE, null, ex);
 }
 return null;
 }
}

The interface require two methods, isReadable and readFrom, to be implemented. The implementation has @Consumes annotation restricting the media type supported by this entity provider.

The second one, MyWriter, defines the conversion from MyObject Java type to on-the-wire representation.

@Provider
@Produces(MyObject.MIME_TYPE)
public class MyWriter implements MessageBodyWriter<MyObject> {

 @Override
 public boolean isWriteable(Class<?> type, Type type1, Annotation[] antns, MediaType mt) {
 return MyObject.class.isAssignableFrom(type);
 }

 @Override
 public long getSize(MyObject t, Class<?> type, Type type1, Annotation[] antns, MediaType mt) {
 // As of JAX-RS 2.0, the method has been deprecated and the 
 // value returned by the method is ignored by a JAX-RS runtime. 
 // All MessageBodyWriter implementations are advised to return -1 from 
 // the method.
 
 return -1;
 }

 @Override
 public void writeTo(MyObject t, 
 Class<?> type, 
 Type type1, 
 Annotation[] antns, 
 MediaType mt, 
 MultivaluedMap<String, Object> mm, 
 OutputStream out) throws IOException, WebApplicationException {
 ObjectOutputStream oos = new ObjectOutputStream(out);
 oos.writeObject(t);
 }
}

The interface require three methods isWriteable, getSize, writeTo to be implemented. The implementation of getSize method is recommended to return -1 as JAX-RS runtime is required to compute the actual Content-Length header value. The implementation has @Produces annotation restricting the media type supported by this entity provider.

The reader and writer entity providers are marked with @Provider and are thus automatically discovered at runtime on the server-side. But until JERSEY-1634 is fixed, they need to be explicitly specified in the Application class as:

@ApplicationPath("webresources")
public class MyApplication extends Application {
 @Override
 public Set<Class<?>> getClasses() {
 Set<Class<?>> resources = new java.util.HashSet<>();
 resources.add(MyResource.class);
 resources.add(MyReader.class);
 resources.add(MyWriter.class);
 return resources;
 }
}

On the client-side, the providers need to be explicitly registered as shown:

Client client = ClientFactory.newClient();
client
 .configuration()
 .register(MyReader.class)
 .register(MyWriter.class);
String fruit = target
 .request()
 .post(Entity.entity(new MyObject(1), MyObject.MIME_TYPE), String.class);

Notice, how invoking the endpoint requires to specify the media type as part of post method invocation.

The complete source code for this sample application can be downloaded here and will work on GlassFish 4.0 b70.

Here are some more pointers to follow

JAX-RS 2 Specification Public Review
Latest status on specification (jax-rs-spec.java.net)
Latest JAX-RS 2.0 Javadocs
Latest status on Jersey (Reference Implementation of JAX-RS 2 - jersey.java.net)
Latest Jersey API Javadocs
Latest GlassFish 4.0 Promoted Build
Follow @gf_jersey

Provide feedback on Jersey 2 to users@jersey.java.net and JAX-RS specification to users@jax-rs-spec.java.net.

Batch Applications in Java EE 7 - Undertanding JSR 352 Concepts: TOTD #192

2013-01-02T23:34:26+00:00

Batch processing is execution of series of "jobs" that is suitable for non-interactive, bulk-oriented and long-running tasks. Typical examples are end-of-month bank statement generation, end-of-day jobs such as interest calculation, and ETL (extract-transform-load) in a data warehouse. These tasks are typically data or computationally intensive, execute sequentially or in parallel, and may be initiated through various invocation models, including ad-hoc, scheduled, and on-demand.

JSR 352 will define a programming model for batch applications and a runtime for scheduling and executing jobs. This blog will explain the main concepts in JSR 352.

The diagram below highlight the key concepts of a batch processing architecture.

A Job is an instance that encapsulates an entire batch process. A job is typically put together using a Job Specification Language and consists of multiple steps. The Job Specification Language for JSR 352 is implemented with XML and is referred as "Job XML".
A Step is a domain object that encapsulates an independent, sequential phase of a job. A step contains all of the information necessary to define and control the actual batch processing.
JobOperator provides an interface to manage all aspects of job processing, including operational commands, such as start, restart, and stop, as well as job repository commands, such as retrieval of job and step executions.
JobRepository holds information about jobs current running and jobs that run in the past. JobOperator provides access to this repository.
Reader-Processor-Writer pattern is the primary pattern and is called as Chunk-oriented processing. In this, ItemReader reads one item at a time, ItemProcessor processes the item based upon the business logic, such as calculate account balance and hands it to ItemWriter for aggregation. Once the 'chunk' number of items are aggregated, they are written out, and the transaction is committed.

JSR 352 also defines roll-your-own batch pattern, called as Batchlet. This batch pattern is invoked once, runs to completion, and returns an exit status. This pattern must implement and honor a "cancel" callback to enable operational termination of the Batchlet.

A Job XML for a chunk-oriented processing may look like:


<job id="myJob" xmlns="http://batch.jsr352/jsl">
 <step id="myStep" >
 <chunk reader="MyItemReader" 
 writer="MyItemWriter" 
 processor="MyItemProcessor"
 buffer-size="5"
 checkpoint-policy="item"
 commit-interval="10" /> 
 </step>
</job>

The <job> has an "id" attribute that defines the logical name of the job and is used for identification purposes.
Each <job> can multiple <step>s where each <step> identifies a job step and it's characteristics. Each <step> has an "id" attribute that defines the logical name of the job and is used for identification purposes.
A <step> may have <chunk> or <batchlet> element, this <step> has a <chunk>. A <chunk> identifies a chunk type step and implements the reader-processor-writer pattern of batch.
The "reader", "processor", and "writer" attributes specify the class names of an item reader, processor, and writer respectively.
"buffer-size" specifies number of items to read and buffer before writing. When enough items have been read to fill the buffer, the buffer is emptied to a list and the configured ItemWriter is invoked with the list of items.
"checkpoint-policy" attribute specifies the checkpoint policy that governs commit behavior for this chunk. Valid values are "item", "time" and "custom". The "item" policy means chunk is checkpointed after a specified number of items are processed. The "time" policy means the chunk is committed after a specified amount of time. The "custom" policy means the chunk is checkpointed according to a checkpoint algorithm implementation. The default policy is "item".
"commit-interval" specifies the commit interval for the specified checkpointed policy. The unit meaning of the commit-interval specifies depends on the specified checkpoint policy. For "item" policy, commit-interval specifies a number of items. For "time" policy, commit- interval specifies a number of seconds. The commit-interval attribute is ignored for "custom" policy.

When the configured checkpoint policy directs it is time to checkpoint, all the items read and processed so far are passed to the "writer".

Here is a simple reader:

@ItemReader
public class MyItemReader {
 private static int id;
 MyCheckPoint checkpoint = null;
 
 @Open
 void open(MyCheckPoint checkpoint) {
 this.checkpoint = checkpoint;
 System.out.println(getClass().getName() + ".open: " + checkpoint.getItemCount());
 }
 
 @ReadItem
 MyBatchRecord read() {
 checkpoint.incrementByOne();
 return new MyBatchRecord(++id);
 }
 
 @CheckpointInfo
 MyCheckPoint getCheckPoint() {
 return checkpoint;
 }
}

Methods marked with @Open, @ReadItem, and @CheckpointInfo are required.

Here is a simple processor that rejects every other item:

@ItemProcessor
public class MyItemProcessor {
 @ProcessItem
 MyBatchRecord process(MyBatchRecord record) {
 return (record.getId() % 2 == 0) ? record : null;
 }
}

And here is a simple writer:

@ItemWriter
public class MyItemWriter {
 MyCheckPoint checkpoint = null;
 
 @Open
 void open(MyCheckPoint checkpoint) {
 this.checkpoint = checkpoint;
 System.out.println(getClass().getName() + ".open: " + checkpoint.getItemCount());
 }
 
 @WriteItems
 void write(List<MyBatchRecord> list) {
 System.out.println("Writing the chunk...");
 for (MyBatchRecord record : list) {
 System.out.println(record.getId());
 }
 checkpoint.increment(list.size());
 System.out.println("... done.");
 }
 
 @CheckpointInfo
 MyCheckPoint getCheckPoint() {
 return checkpoint;
 }
}

Finally a simple implementation of MyCheckpoint:

public class MyCheckPoint {
 int itemCount;

 public int getItemCount() {
 return itemCount;
 }

 public void setItemCount(int itemCount) {
 this.itemCount = itemCount;
 }
 
 void incrementByOne() {
 itemCount++;
 }

 void increment(int size) {
 itemCount += size;
 }
}

Together, MyItemReader, MyItemWriter, MyItemProcessor, MyCheckPoint, and batch.xml, will read/process/write 5 items and commit when 10 such items have been processed.

JSR 352 specification defines several other concepts such as how Job XML can define sequencing of jobs, listeners to interpose on job execution, transaction management, and running jobs in partitioned and concurrent modes. Subsequent blog will explain some of those concepts.

A complete replay of Java Batch for Cost-Optimized Business Efficiency from JavaOne 2012 can be seen here (click on CON4105_mp4_4105_001 in Media).

Each feature will be added to the JSR subject to EG approval. You can share your feedback to public@jbatch.java.net.

The APIs and implementation of JSR 352 are not integrated in GlassFish 4 promoted builds yet.

Here are some more references for you:

Java API for Batch Processing Public Review Downloads
Specification Project (jbatch.java.net)
JSR Expert Group Discussion Archive (public@jbatch.java.net)
Java EE 7 Specification Status

Here are some other Java EE 7 primers published so far:

Simple JMS 2.0 Sample (TOTD #191)
What's New in Servlet 3.1 ?
Concurrency Utilities for Java EE (JSR 236)
Collaborative Whiteboard using WebSocket in GlassFish 4 (TOTD #189)
Non-blocking I/O using Servlet 3.1 (TOTD #188)
What's New in EJB 3.2 ?
JPA 2.1 Schema Generation (TOTD #187)
WebSocket Applications using Java (JSR 356)
Jersey 2 in GlassFish 4 (TOTD #182)
WebSocket and Java EE 7 (TOTD #181)
Java API for JSON Processing (JSR 353)
JMS 2.0 Early Draft (JSR 343)

And of course, more on their way! Do you want to see any particular one first ?

Simple JMS 2.0 Sample - @JMSDestinationDefinition and Synchronous Message Receive: TOTD #191

2012-12-26T20:59:19+00:00

JMS 2.0 Early Draft - Simplified API Sample Code explained some of the changes that are made in JMS 2.0 to "catch up" with all the changes in the Java SE and EE platform over the past few years. The main goals of JMS 2.0 are:

Changes to improve ease-of-development
Clarification of relationship between JMS and other Java EE specifications
Definition of a new mandatory API to allow any JMS provider to be integrated with any other Java EE Application Server
Other enhancements as requested by the community

This Tip Of The Day (TOTD) will explain a simple sample showing how to send a message and receive it synchronously. The complete source code for the sample can be downloaded here.

This is a Stateless EJB that has a single method to send a message.

@Stateless
public class MessageSender {

 @Inject
 JMSContext context;
 
 @Resource(mappedName="java:global/jms/myQueue")
 Queue queue;

 public void sendMessage(String message) {
 context.createProducer().send(queue, message);
 }
}

In this code:

JMSContext is a new interface introduced in the simplified API in JMS 2.0. This combines in a single object the functionality of two separate objects from the JMS 1.1 API: a Connection and a Session.

A JMSContext may be injected in the Java EE web and EJB containers using the @Inject annotation. A JMSContext created in this way is described as being container-managed. A container-managed JMSContext will be closed automatically by the container. Applications running in the Java EE web and EJB containers are not permitted to create more than one active session on a connection. This allows to combine them in a single object offering a simpler API. This is the recommended way for creating JMS context in Java EE applications.

A JMSContext may be created by calling one of the createContext methods on a ConnectionFactory. A JMSContext that is created this way is described as being application-managed. An application-managed JMSContext must be closed when no longer needed by calling its close method. Applications running in a Java SE environment or in the Java EE application client container are permitted to create multiple active sessions on the same connection. This allows the same physical connection to be used in multiple threads simultaneously. The createContext method is recommended to create JMSContext in such applications.
The Java EE Platform requires a preconfigured JMS ConnectionFactory accessible to the application under the JNDI name:
```
java:comp/DefaultJMSConnectionFactory
```
The annotation @JMSConnectionFactory may be used to specify the JNDI lookup name of the ConnectionFactory used to create the JMSContext as:
```
@Inject
@JMSConnectionFactory("java:comp/DefaultJMSConnectionFactory")
JMSContext context;
```
If no lookup name is specified or the @JMSConnectionFactory is omitted then the platform default JMS connection factory will be used. The above code fragment is equivalent to:
```
@Inject
JMSContext context;
```
@Resource defines a dependency on a resource needed by the application. In this case, it specifies the JNDI name of the destination to which the message needs to be sent.
When an application needs to send messages it uses the createProducer method to create JMSProducer which provides methods to configure and send messages. The various setProperty methods are used to set property on the message being sent. There are several other methods like setPriority, setDeliveryDelay, and setTimeToLive to set other quality-of-service attributes for the message being sent.

Messages may be sent synchronously or asynchronously. Synchronous messages are sent using one of the send methods. Asynchronous messages are sent using setAsync method and assigning a CompletionListener. When the message has been successfully sent the JMS provider invokes the callback method onCompletion on the CompletionListener object. If the message is not sent for some reason or an acknowledgement from the remote JMS server is not received then onException callback method is called. An asynchronous send is not permitted in a Java EE application.

This is a Stateless EJB that has a single method to receive the message synchronously.

@Stateless
public class MessageReceiverSync {

 @Inject
 private JMSContext context;
 
 @Resource(mappedName="java:global/jms/myQueue")
 Queue myQueue;

 public String receiveMessage() {
 String message = context.createConsumer(myQueue).receiveBody(String.class, 1000);
 return "Received " + message;
 }
}

In this code:

JMSContext referring to the preconfigured JMS ConnectionFactory is injected by the container.
@Resource defines a dependency on the JMS destination on which the message is received.
When an application needs to receive messages it uses one of the several createConsumer or createDurableConsumer methods to create a JMSConsumer. createConsumer creates a non-durable subscription on the specified destination. This means that a client will only see the messages published on the destination when the subscriber is active. If the subscriber is not active, it is missing messages published on the destination. createDurableConsumer creates an unshared durable subscription of a specified topic and creates a consumer on that subscription. This allows the subscriber will receive all messages published on a topic, including the ones published when there is no active consumer associated with it. The JMS provider retains a record of this durable subscription and ensures that all messages from the topic's publishers are retained until they are delivered to, and acknowledged by, a consumer on this durable subscription or until they have expired.

A JMSConsumer provides methods to receive messages either synchronously or asynchronously. receive methods are used for synchronous delivery of the messages. A MessageListener object may be registered with the client for asynchronous delivery of the messages. onMessage method of the MessageListener object are called as messages are received. Asynchronous delivery of messages will not work until MQ-264 is fixed.

Next is a Servlet that ties all the pieces together. It defines the JMS Destination and send and receive the message using the previously defined EJBs.

@JMSDestinationDefinition(name = "java:global/jms/myQueue",
 resourceAdapterName = "jmsra",
 className = "javax.jms.Queue",
 destinationName="queue1234",
 description="My Queue")
@WebServlet(urlPatterns = {"/TestServlet"})
public class TestServlet extends HttpServlet {
 
 @EJB MessageSender sender;
 
 @EJB MessageReceiverSync receiver;


 void doGet(HttpServletRequest request, HttpServletResponse response) {
 . . .
 String m = "Hello there";
 sender.sendMessage(m);
 out.format("Message sent: %1$s.<br>", m);
 out.println("Receiving message...<br>");
 String message = receiver.receiveMessage();
 out.println("Message received: " + message); 
 . . .
 }

In this code:

@JMSDestinationDefinition defines the JMS destination. The name attribute defines the JNDI name of the destination being defined, destinationName attribute defines the name of the queue or topic, and className attribute defines the JMS destination implementation class name.
doGet method uses the injected EJBs to send and receive the message.

The complete source code for the sample can be downloaded here. "mvn package" and deploy the generated WAR file.

Download GlassFish 4 build 68 onwards and try this sample today!

The latest progress on JMS 2.0 can be tracked at:

jms-spec.java.net
JSR 343 EG archive at jsr343-experts
Discussion at users@jms-spec
JSR 343

Latest Specification
Latest Javadocs (download, online)

Help us make JMS 2.0 better, simpler, easier to use. Join users@jms-spec and contribute!

JavaOne 2013 Russia, India, China, USA: Save the Date

2012-12-21T18:24:13+00:00

Moscow, Russia: April 23-24, 2013^*

Hyderabad, India: May 8-9, 2013^*

Shanghai, China: Jul 23-25, 2013^*

San Francisco, USA: Sep 22-26, 2013^*

^* The dates are subject to change.

Venue, Agenda, CFP, and other details to come later.

Did you know that recording of all Technical Sessions from JavaOne San Francisco 2012 is available ? Watch them there!

Adopt-a-JSR for Java EE 7 - Getting Started

2012-12-19T13:26:06+00:00

Adopt-a-JSR is an initiative started by JUG leaders to encourage JUG members to get involved in a JSR, in order to increase grass roots participation. This allows JUG members to provide early feedback to specifications before they are finalized in the JCP. The standards in turn become more complete and developer-friendly after getting feedback from a wide variety of audience. adoptajsr.org provide more details about the logistics and benefits for you and your JUG. A similar activity was conducted for OpenJDK as well. Markus Eisele also provide a great introduction to the program (in German).

Java EE 7 (JSR 342) is scheduled to go final in Q2 2013. There are several new JSRs that are getting included in the platform (e.g. WebSocket, JSON, and Batch), a few existing ones are getting an overhaul (e.g. JAX-RS 2 and JMS 2), and several other getting minor updates (e.g. JPA 2.1 and Servlets 3.1). Each Java EE 7 JSR can leverage your expertise and would love your JUG to adopt a JSR.

What does it mean to adopt a JSR ?

Your JUG is going to identify a particular JSR, or multiple JSRs, that is of interest to the JUG members. This is mostly done by polling/discussing on your local JUG members list.
Your JUG will download and review the specification(s) and javadocs for clarity and completeness. The complete set of Java EE 7 specifications, their download links, and EG archives are listed here. glassfish.org/adoptajsr provide specific areas where different specification leads are looking for feedback.
Your JUG can then think of a sample application that can be built using the chosen specification(s). An existing use case (from work or a personal hobby project) may be chosen to be implemented instead. This is where your creativity and uniqueness comes into play.

Most of the implementations are already integrated in GlassFish 4 and others will be integrated soon. You can also explore integration of multiple technologies and provide feedback on the simplicity and ease-of-use of the programming model. Especially look for integration with existing Java EE technologies and see if you find any discrepancies. Report any missing features that may be included in future release of the specification.

The most important part is to provide feedback by filing bugs on the corresponding spec or RI project. Any thing that is not clear either in the spec or implementation should be filed as a bug. This is what will ensure that specification and implementation leads are getting the required feedback and improving the quality of the final deliverable of the JSR.

How do I get started ?

A simple way to get started can be achieved by following S.M.A.R.T. as explained below.

Specific	Identify who all will be involved ? What would you like to accomplish ? For example, even though building a sample app will provide real-world validity of the API but because of time constraints you may identify that reviewing the specification and javadocs only can be accomplished. Establish a time frame by which the activities need to be complete.
Measurable	Define a success for metrics. For example, this could be the number of bugs filed. Remember, quality of bugs is more important that quantity of bugs. Define your end goal, for example, reviewing 4 chapters of the specification or completing the sample application. Create a dashboard that will highlight your JUG's contribution to this effort.
Attainable	Make sure JUG members understand the time commitment required for providing feedback. This can vary based upon the level of involvement (any is good!) and the number of specifications picked. adoptajsr.org defines different categories of involvement. Once again, any level of involvement is good. Just reviewing a chapter, a section, or javadocs for your usecase is helpful.
Relevant	Pick JSRs that JUG members are willing and able to work. If the JUG members are not interested then they might loose motivation half-way through. The "able" part is tricky as you can always stretch yourself and learn a new skill ;-)
Time-bound	Define a time table of activities with clearly defined tasks. A tentative time table may look like: Dec 25: Discuss and agree upon the specifications with JUG Jan 1: Start Adopt-a-JSR for Java EE 7 Jan 15: Initial spec reading complete. Keep thinking through the application that will be implemented. Jan 22: Early design of the sample application is ready Jan 29: JUG members agree upon the application Next 4 weeks: Implement the application Of course, you'll need to alter this based upon your commitment. Maintaining an activity dashboard will help you monitor and track the progress. Make sure to keep filing bugs through out the process!

12 JUGs from around the world (SouJava, Campinas JUG, Chennai JUG, London Java Community, BeJUG, Morocco JUG, Peru JUG, Indonesia JUG, Congo JUG, Silicon Valley JUG, Madrid JUG, and Houston JUG) have already adopted one of the Java EE 7 JSRs. I'm already helping some JUGs bootstrap and would love to help your JUG too.

What are you waiting for ?

What's new in Servlet 3.1 ? - Java EE 7 moving forward

2012-12-18T21:35:14+00:00

Servlet 3.0 was released as part of Java EE 6 and made huge changes focused at ease-of-use. The idea was to leverage the latest language features such as annotations and generics and modernize how Servlets can be written. The web.xml was made as optional as possible. Servet 3.1 (JSR 340), scheduled to be part of Java EE 7, is an incremental release focusing on couple of key features and some clarifications in the specification.

The main features of Servlet 3.1 are explained below:

Non-blocking I/O - Servlet 3.0 allowed asynchronous request processing but only traditional I/O was permitted. This can restrict scalability of your applications. Non-blocking I/O allow to build scalable applications. TOTD #188 provide more details about how non-blocking I/O can be done using Servlet 3.1.
HTTP protocol upgrade mechanism - Section 14.42 in the HTTP 1.1 specification (RFC 2616) defines an upgrade mechanism that allows to transition from HTTP 1.1 to some other, incompatible protocol. The capabilities and nature of the application-layer communication after the protocol change is entirely dependent upon the new protocol chosen. After an upgrade is negotiated between the client and the server, the subsequent requests use the new chosen protocol for message exchanges. A typical example is how WebSocket protocol is upgraded from HTTP as described in Opening Handshake section of RFC 6455.

The decision to upgrade is made in Servlet.service method. This is achieved by adding a new method: HttpServletRequest.upgrade and two new interfaces: javax.servlet.http.HttpUpgradeHandler and javax.servlet.http.WebConnection.

TyrusHttpUpgradeHandler shows how WebSocket protocol upgrade is done in Tyrus (Reference Implementation for Java API for WebSocket).
Security enhancements

Applying run-as security roles to #init and #destroy methods
Session fixation attack by adding HttpServletRequest.changeSessionId and a new interface HttpSessionIdListener. You can listen for any session id changes using these methods.
Default security semantic for non-specified HTTP method in <security-constraint>
Clarifying the semantics if a parameter is specified in the URI and payload

Miscellaneous

ServletResponse.reset clears any data that exists in the buffer as well as the status code, headers. In addition, Servlet 3.1 will also clears the state of calling getServletOutputStream or getWriter.
ServletResponse.setCharacterEncoding: Sets the character encoding (MIME charset) of the response being sent to the client, for example, to UTF-8.
Relative protocol URL can be specified in HttpServletResponse.sendRedirect. This will allow a URL to be specified without a scheme. That means instead of specifying "http://anotherhost.com/foo/bar.jsp" as a redirect address, "//anotherhost.com/foo/bar.jsp" can be specified. In this case the scheme of the corresponding request will be used.
Clarification in HttpServletRequest.getPart and .getParts without multipart configuration.
Clarification that ServletContainerInitializer is independent of metadata-complete and is instantiated per web application.

A complete replay of What's New in Servlet 3.1: An Overview from JavaOne 2012 can be seen here (click on CON6793_mp4_6793_001 in Media).

Each feature will be added to the JSR subject to EG approval. You can share your feedback to users@servlet-spec.java.net.

Here are some more references for you:

Servlet 3.1 Public Review Candidate Downloads

Several features have already been integrated in GlassFish 4 Promoted Builds. Have you tried any of them ?

Here are some other Java EE 7 primers published so far:

Concurrency Utilities for Java EE (JSR 236)
Collaborative Whiteboard using WebSocket in GlassFish 4 (TOTD #189)
Non-blocking I/O using Servlet 3.1 (TOTD #188)
What's New in EJB 3.2 ?
JPA 2.1 Schema Generation (TOTD #187)
WebSocket Applications using Java (JSR 356)
Jersey 2 in GlassFish 4 (TOTD #182)
WebSocket and Java EE 7 (TOTD #181)
Java API for JSON Processing (JSR 353)
JMS 2.0 Early Draft (JSR 343)

And of course, more on their way! Do you want to see any particular one first ?