Verso

The first preview release of the Java EE 6 Tutorial was released yesterday.

Get it by installing the Java EE 6 SDK Preview and ugprading the Java EE 6 Tutorial package using the Update Tool.

We've got a bunch of new material and examples in this release, including:

• JavaServer Faces 2.0, including Facelets, an XHTML-based display technology that is much easier than JSP.
• JAX-RS 1.1, the RESTful web services API.
• EJB 3.1, which really simplifies EJB development, and allows you to package enterprise beans within web applications.
• The Java Persistence API 2.0, with support for collections (including Maps) within entities, mixed field/property access, and orphan removal for one-to-many and one-to-one relationships.
• Servlet 3.0, which now uses annotations to truly make the web.xml deployment descriptor optional.

Our examples are developed as a java.net project, so if you find bugs or want to file enhancement requests we'd love to hear about them.

Our mailing lists provide another way of giving feedback, and are also good places to start if you're interested in contributing source code or material for the Java EE 6 Tutorial.

With the help of the excellent media team here at Sun, I recorded a screencast screencast demonstrating how to deploy and run the ClickToDial sample application on Project SailFin, aka GlassFish Communications Server.

To follow along with the screencast, you'll need the following software:

• SailFin Milestone 4 1.5, available at the SailFin project home page.
• The NetBeans 6.o IDE, or the newly release 6.1 6.5, available at netbeans.org.
• The SIP Servlet 1.1 version of ClickToDial.
• The XLite 3.0 softphone, available for free download at Counterpath's web site.

Here's a downloadable offline version of the screencast.

Edit: New link with screencast controls.

Edit: I updated the screencast and the example code to use SIP Servlet 1.1 (JSR 289) features.

I just read on Salon that Sheldon Brown passed away on February 3rd, 2008. Brown provided one of the first repositories of bicycling information on the web, one of the first bike shops online, and championed single-speed and fixed-gear bikes. His obituary was run in the London Times.

I never met him in person, but he was an active presence on some bicycling mailing lists and message board during the early days of the 'net, and was knowledgeable, funny, and all-around one of those people that made communicating electronically worthwhile rather than just an exercise in personality disorder diagnosis. His posts by his alter-ego, Carrapace Completed Umber, were always hilarious.

His articles on riding fixed-gear bikes convinced me to build up my fixie back in 1999, before I was aware of it being a totem of urban hipsterdom. That bike has some parts I ordered from the shop he worked for, Harris Cyclery. It'd be nice to think a little bit of his spirit is in my bike, and probably thousands of bikes around the world.

I wasn't aware of his illness from multiple sclerosis, as I haven't really kept up with those lists and sites. I'm sorry to hear about his passing, and that for the last two years he couldn't participate in the activity and lifestyle he so clearly cherished. My condolences go out to his wife and kids (whom he loved dearly), and his friends, virtual and IRL.

Edit: Memorial donation info here.

Third Opinion: Perennially Mistaken Tech Journalist Overreacts

Honestly, is anybody more consistently wrong in his assessments than John Dvorak? He's like the drunken blowhard uncle of the tech industry: he's family, so he's always invited to the party. But he always makes a scene after his third Dewars.

The tradition of the troll is a long and storied one, and Dvorak has to be considered one of the old pros. He got his start with opinion pages in the cheap-newsprint free monthlies you'd find at the local mom & pop computer shop, but nowadays, well into the Participation Age as our Fearless Leaders like to call it, he's got to compete with every young buck that has access to a WiFi connection and a blogging service.

Like watching Rod Carew in the '80s at Angel Stadium, we should just sit back and marvel at the hyperbole (worst acquisition ever?) and odd asides (umm, you're still bitter about a marginal acquisition from 1987?), how effortlessly and economically they come. It takes years to shut up the mind's internal censor enough to make clumsy, inappropriate, oh-so-close-to-bigoted comparisons to Mao Zedong, and ominous conspiracy theories darkly hinted at through mid-story headings, so keep practicing kids! The upstart trolls of this generation are as free swinging with the facts as ol' Johnny D, but the kind of willful ignorance of the modern rules of the game he displays (in this case, how the terms of the GPL precludes any company, including Sun, from "wresting control" of MySQL's codebase; also, suggesting that Oracle and Sun have some sort of back-handed and massively illegal accounting pipeline being used to fund the MySQL acquisition)? Well, that's just audacious. He's enshrined under the Big Bridge at Cooperstown for good reason.

So Mr. Dvorak, from this young troll just starting out, I say, "Master."

My wife Katie and I are hosting Thanksgiving this year for the first time, as it just didn't work out for us to travel down to Southern California. A few weeks ago I ordered a heritage turkey from Bi-Rite Market, a chichi small grocery in the Mission here in San Francisco.

"Heritage" is to turkeys what "heirloom" is to tomatoes, breeds that had been forgotten about as agriculture became mechanized in the 20th century. Supposedly they have a richer taste, and more dark meat, than your standard turkey. My turkey apparently came from Good Shepard Turkey Ranch, in Kansas.

My bird came with a tracking number, GSRA674, which allows you to look up where it came from. It was sort of odd finding out personal information about the food you're going to eat (mine was born last spring, and was killed--or "met its final destiny" as they put it on the website--when it was 24 weeks old). I, like most Americans, am not used to associating the food I consume with the farms and ranches where it's grown.

Good ol' GSRA674 is currently brining in my refrigerator in a lime green tub I bought last spring, when good ol' GSRA674 was but a young hatchling. I got the tub for my friend Ashwin's "Thanksgiving in May" party. He basically really wanted leftover turkey to make something he calls toastettes (turkey sandwiches sealed in an iron contraption and roasted over the fire, something like a meat pie I guess), and found an excuse to do so. That's where I first tried brining, and the turkeys we made were incredible.

Recently a user sent a question to the ejb@glassfish.dev.java.net mailing list about an error he was seeing when trying to deploy an EJB JAR containing only Java Persistence API entities. Doing this causes a deployment error, and the user was confused. The reason for the error is that JPA entities are not EJB components, even though they were introduced in the EJB 3.0 specification.

I simply wasn't aware that POJOs annotated with @Entity are not considered EJB components in contrast to POJOs annotated with @Stateless for example.

The user mentioned reading articles and tutorials (vanity alert: definitely not my tutorials) about JPA entities that refer to them as EJB 3.0 entity beans, which is incorrect, if understandable. The reason why Java Persistence was part of the EJB 3.0 spec has nothing to do with the technology, and everything to do with the JCP procedures that govern the release of Java EE. Basically, when the architecture of Java Persistence was decided on by the EJB expert group (i.e. that entities would not be EJB components) it was too late to introduce a separate JSR. So, the choice was to wait until Java EE 6, or piggyback on EJB 3.0. Put another way, the choice was to frustrate and anger developers or confuse them.

So, kids, remember that Java Persistence API entities are not EJB components, and there's no such thing as EJB 3.0 entity beans.

We recently received some feedback asking:

At the J2EE for dummies level, I would like a diagram that shows a clear relationship between JPA and (EJBs, Hibernate, Toplink, ...). Maybe an onion model. As it is, JPA claims to have incorporated the best of several models but at the same time it seems to be a wrapper for the available models.

The Java EE architecture diagram here shows where the Java Persistence API fits into the Java EE concept of containers, but this might be confusing for some people, as it gets lost with all the other boxes full of acronyms. A more simple diagram might look something like this:

Here, an application I'm calling App 1 has three components, a web component, an EJB component, and a JPA component. It's deployed to a Java EE server, which runs on top of Java SE. So far, so good. When the JPA component is being used in the application, what's happening behind the scenes in the Java EE server?

Regardless of whether an enterprise bean or a web component is using the JPA component, the container (EJB or web) communicates with the configured JPA provider to access the underlying data. Because the Java Persistence API is required in Java EE 5 servers, every Java EE server has a default JPA provider. With GlassFish/Sun Java System Application Server, the default JPA provider is TopLink Essentials. TopLink Essentials is also the reference implementation of JPA.

There are other implementations of the Java Persistence API, though. Hibernate is a popular one. Another is OpenJPA. All of them, including TopLink, provide the baseline functionality of JPA, and also include implementation-specific features that go beyond the JPA specification. If your app uses one of these features, it's not portable across all JPA implementations. For example, if you use a Hibernate-specific feature, you can't deploy the application unchanged to a GlassFish server.

You can, however, configure your application to use an alternate JPA provider, provided that you make the alternate provider available to the Java EE server. The easiest way of doing this is to package the other provider's JAR with your application.

In this case, App 1 is bypassing GlassFish's default JPA provider, TopLink, in favor of Hibernate, which they have made available to GlassFish by packaging the Hibernate JAR with App 1, and configured their JPA component to use Hibernate. The EJB and web containers will use Hibernate to manage App 1's persistence unit.

Update: I should point out that if you want to avoid having to package the alternate JPA provider's JAR with each application, you can copy the JAR to GlassFish's INSTALL/lib directory and restart GlassFish so the JAR's classes are in GlassFish's runtime classpath.

I recently got some feedback from a Java EE 5 Tutorial user who saw some odd behavior when using a modified version of the EJB Timer Service example. The user's modified app attempts to create a repeating 3 second timer like this:

public void setTimer(long intervalDuration) {
  Timer timer = timerService.createTimer(0, intervalDuration,  "Created new timer");
}

And on the client:

long intervalDuration = 3000;
timer.setTimer(intervalDuration);

The user added a call to check the system time to measure the accuracy of the timeout in the @Timeout method in TimerSessionBean:

@Timeout
public void timeout(Timer timer) {
    logger.info(System.currentTimeMillis() + "Timeout occurred");
}

The user was surprised to see the interval timing as 7 seconds, not 3 seconds. I was surprised as well. I posed the question to the ejb@glassfish.dev.java.net mailing list, and heard back from Ken Saks, the EJB.next spec lead and the lead engineer for EJB 3 here at Sun:

The EJB Timer Service is not targeted towards very fine-grained timeouts, so there's a default minimum imeout interval of 7000 ms defined within Glassfish. That property can be changed via the minimum-delivery-interval-in-millis attribute in domain.xml.

Note that this is GlassFish-specific behavior. The EJB 3 spec doesn't define minimum timeout values, although it does say that the Timer Service is not designed for extremely precise operations required by real-time applications, as Ken pointed out in his response.

Update: I corrected Ken's email above to fix his typo of 7 ms to 7000 ms (that is, 7 seconds). domain.xml's DTD specifies a default value of 7000 ms for minimum-delivery-interval-in-millis.

Update 2: Update 4 of the Java EE 5 Tutorial contains an updated example with an 8 second/8000 ms timer, and a note on GlassFish's minimum default timeout value.

Some users have had build errors similar to the following:

This error is caused by the javaee.domain property not being set, usually because you haven't completed the configuration of the tutorial as detailed in the SWDP Tutorial 2.0's preface.

Briefly, you should rename:

to:

and set the properties to match your environment. javaee.domain is initally set to domain1, the GlassFish default domain, so you should only change it if you changed the domain in which you installed the SWDP JARs in the SWDP installer.

This week I'm attending the Web 2.0 Expo here in San Francisco. Yesterday I attended two sessions, one about security (or the lack thereof) in Web 2.0 applications, the other about how Facebook redesigned their developer APIs to use a SQL-like language to help simplify things for their 3rd-party developers.

 Complicating matters is my chipped scaphoid bone in my left hand, thanks to a bike accident last week.
 Luckily I got my plaster splint off yesterday, which was replaced by a wrist brace, so I can type a little bit better, and can shower without a plastic garbage bag over my arm. I'd never had a cast before, and I can say that for the 4 days I had to wear it, it was more uncomfortable than I ever imagined.

Anyway, the first session, "Vulnerabilities 2.0 in Web 2.0: Next Generation Web Apps from a Hacker's Perspective" by Alex Stamos was quite interesting. It turns out that many of the same sorts of security problems that existed in older web apps are still present in Ajax-style applications, but are much more difficult to analyze and track down due to the nature of discreet HTTP sub-calls within a single page in an Ajax app. Some of the fundamental aspects of Web 2.0 applications, like mash-ups, and JavaScript proxies that run on the client browser, allow for many more vectors of attack from malicious users.

The fundamental problem appears to be the lack of standard security profiles on the client-side. All client browser security is handled ad-hoc by the browser vendors. For example, cookies are shared across multiple domains during a session, which means malicious sites could use security credentials embedded within a particular cookie along with the local JavaScript proxy APIs to do things like transfer money from your bank account to another without your knowledge. Unlike phishing, this requires nothing more than simply visiting a site or opening a spam email from a webmail account. Ooops.

It'll be interesting to see how these problems are addressed, or if we will see a migration away from Ajax apps for more security-critical actions.

The second session was less interesting to me. I mostly attended "The Story Behind Facebook's APIs: From REST to FQL" to see what they had to say about REST (it turns out, not much). The story mostly seemed to be about how to design an easy-to-use API, and how they eventually decided to use a SQL-like query language to deal with the data available through their API. I suppose this is a good model for opening an API and the underlying data for a site like Facebook. I particularly liked the discussion of the confusing method names in Flickr's APIs, and the fact that they implemented their conversion to FQL (Facebook Query Langauge) in less than 2 months. But implementation details are sort of uninteresting to anybody not currently implementing anything.

If you are trying to use the Java EE 5 Tutorial with Application Server 9.1/GlassFish v2 Beta, you will encounter problems with the JAX-WS examples when running them in NetBeans. Here's the error message for simpleclient:

init:deps-jar:
wsimport-init:
Created dir:
C:\javaeetutorial5\examples\jaxws\simpleclient\build\generated\wsimport\client
Created dir: 
C:\javaeetutorial5\examples\jaxws\simpleclient\build\generated\wsimport\binaries
wsimport-client-check-HelloService:
wsimport-client-HelloService:
Consider using <depends>/<produces> so that wsimport won't do 
unnecessary compilation
parsing WSDL...
[ERROR] 
http://127.0.0.1:8080/helloservice/HelloService/__container$publishing$subctx/WEB-INF/wsdl/HelloService_schema1.xsd
unknown location
[ERROR] 
http://127.0.0.1:8080/helloservice/HelloService/__container$publishing$subctx/WEB-INF/wsdl/HelloService_schema1.xsd
unknown location

The error is due to the changes in JAX-WS 2.1 and JAXB 2.1, which are included in Application Server 9.1/GlassFish v2 Beta. For web service clients NetBeans uses a local copy of the WSDL to generate the artifacts needed to communicate with the service. The WSDL included with simpleclient uses the JAX-WS 2.0/JAXB 2.0 schema URI, as seen above in the error message.

The work-around is to retrieve a new copy of the WSDL. For example, for simpleclient:

1. Deploy helloservice to Application Server 9.1/GlassFish v2 Beta.
2. Open simpleclient in NetBeans.
3. In the Projects pane, expand Web Service References and right-click on HelloService.
4. Select Refresh Client.
5. Right-click on simpleclient and select Run.

Another work-around is to follow the ant instructions for simpleclient.

We're working on a more permanent fix for the examples, and will release a new tutorial bundle as soon as we have a working solution.

There is a bug in NextIdBean.ejbCreate() in update 4 of the J2EE 1.4 Tutorial.

public Object ejbCreate() throws CreateException { return null; }

should be:

public String ejbCreate() throws CreateException { return null; }

This bug doesn't show up when using J2SE 5, only when using J2SE 1.4. J2SE 5 allows subclasses to have different return types. Look for a bug-fix update to the J2EE 1.4 Tutorial within a few weeks.

For J2EE 5, Sun is putting a lot of effort into making enterprise applications easier to create, deploy, and use. Deployment descriptors consistently come up as a source of discontent with the J2EE development process. Right now we're scoping the J2EE 5 Tutorial, and would like your feedback on how the Tutorial should deal with deployment descriptors.

Of these three options, which do you prefer?

1. No discussion of deployment descriptors, provide pre-assembled JARs/WARs/EARs
2. Provide detailed instructions on assembling the JARs/WARs/EARs with a graphical tool like deploytool
3. Provide both "fast track" instructions (option 1) and "slow track" instructions (option 2)

Related to this, what is your preferred development environment?

1. IDE (like NetBeans, Java Studio Creator, Eclipse, JBuilder)
2. command-line tools & text editor (vi, Emacs, TextEdit, etc.)