Eric Jendrock

To be used right out of the box, the tutorial does indeed require the use of Oracle GlassFish Server Open Source Edition as the application server and NetBeans IDE as the IDE. Can you switch to a different IDE? Certainly. There are very few NetBeans-specific settings in our projects. One could switch to using Eclipse as an alternative IDE fairly painlessly. All of our examples are Maven projects in which we tried to keep IDE neutral. I believe that any NetBeans-specific settings can be ignored with no ill effects.

Switching to a different Java EE 7 application server will be much more difficult. To date, GlassFish is the only Java EE 7-compliant Full Profile application server out there. GlassFish and WildFly, from RedHat, are the only Java EE 7-compliant Web Profile implementations. Others are working toward offering compliant application servers and will have them available at some later date. The applications (examples) that we include in the tutorial largely avoid using features or mechanisms that tie the application to the Glassfish application server. Two of our case studies, Duke's Forest and Duke's Tutoring, require GlassFish-specific packages for creating the JDBC realm that is used for authentication. We use the GlassFish Maven plugin for exec'ing asadmin commands through Maven, for creating the JDBC realm (see the pom.xml file in the examples/dukes-forest/entities directory) or activating the default principal to role mapping setting in GlassFish (see the pom.xml file in the examples/dukes-forest/dukes-store directory). We also use Cargo to start and stop the application server, start and stop the database server, etc. You would have to have access to an exec plugin and a mechanism like Cargo for any application server you choose to run the applications on. An alternative is to do these things manually using the administrative capabilities of the application server (like asadmin in GlassFish).

On the surface, it seems to be a trivial exercise but, alas, we found it more difficult than we imagined. We ported most of the examples for the Java EE 6 Tutorial to WebLogic Server 12.1.2. The web examples were fairly easy to do, as were the web-based CDI examples. EJB, JPA, JMS, and JAX-WS examples that included an application client (as opposed to a web client) were much more difficult to port. The takeaway from the porting exercise that we did was this. Create whatever resources you need using a command line admin tool. Manually convert any application server-specific deployment descriptors yourself. GlassFish was simpler, so the mapping was always simple to more complex. Start, stop, deploy, undeploy everything manually. This is much simpler than finding the necessary plugins and adjusting all of the Maven dependencies. In short, be prepared to do much on your own with less automation. The examples are definitely portable. The porting process is just not a simple or trivial one, in our experience.

Other folks that have migrated Java EE applications to diferent application servers (see Arun Gupta's article about migrating a Java EE application from GlassFish to WildFly at http://wildfly.org/news/2014/02/06/GlassFish-to-WildFly-migration/) can probably add pointers regarding other areas that were difficult to port. In general, I think the exercise depends largely on the complexity of server to which you are migrating.

I'll try to answer some of your questions.

1) The primary benefit provided by the Batch Processing APIs (JSR 352) in Java EE 7 is standardization. As you pointed out, many application servers have been providing batch processing capabilities but each did so in its own way. Java EE 7 standardizes this capability so applications that use this feature can be run on another application server with minimal changes.

2) GlassFish 4 is not a production quality application server, so it is not optimized for massively scaled applications, such as the case that you mention. Scalability is a production quality feature that would be supported by commercial application servers, not an open source one like GlassFish. Without quoting numbers, in general, WebSocket applications do run with a higher efficiency and a decreased latency in cases using many small messages, including chat and stock ticker updates for example. An application could be written in a manner that stores conversations between clients, but we don't have an example of this to show you.

3) In the case of an asynchronous servlet, you correctly described the action. Asynchronous Servlets allow you to handle the request and write the response in a different thread from the one that was used to send the request.

4) When a second-level cache is used with JPA 2.1, it helps improve performance by avoiding expensive database calls, keeping the entity data local to the application. How memory is maintained and used is entirely implementation specific.

Thank you for your suggestions about organizing the information in the chapters.

Contexts and Dependency Injection for Java EE has been a part of the Java EE platform since Java EE 6. In Java EE 7, it has been enhanced and has a direct impact on a greater number of technologies than in Java EE 6.

With the introduction of JavaServer Faces in Java EE 5, JSP has become less important to the platform. The Java EE 5 Tutorial (see http://docs.oracle.com/javaee/5/tutorial/doc/) covers the JSP technology very thoroughly. Since Java EE 5, very few changes have been made in this technology. The Java EE 6 Tutorial and Java EE 7 Tutorial focus on JavaServer Faces and Facelets as the presentation layer for web applications.

William is monitoring the forum as well and will respond to questions and comments where appropriate as well.

You do need to create the user on the server and then map that user to a role on the server. The way to do this varies from application server to application server.

With your experience level, you will be able to handle the Java EE 7 Tutorial.

I really can't answer which is more popular, Spring or Java EE 7. We concentrate on teaching about the platform, Spring and other frameworks provide what they feel users need to develop applications that will run in a Java EE environment. Typically, frameworks address shortcomings in the platform or in platform technologies or offer an easier way to accomplish something. Spring 4 offers support for JMS 2.0, JPA 2.1, Bean Validation 1.1, Servlet 3.1, and WebSocket, so they have kept pace with the platform. Since frameworks are not in my area of expertise, I'll let other users chime in with their preferences.