• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other Pie Elite all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
  • Mikalai Zaikin

Java EE 7 Tutorial book question

Ranch Hand
Posts: 59
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Eric et al,

This tutorial seems to require the use of Glassfish and Netbeans. With no criticism of these tools intended, how hard will it be if I use a different app server or development tool? We use a different Java development environment than Netbeans, for example.

Also, what do you consider the most significant change/addition in this version of Java 7 EE and why? There are a lot of pieces to absorb. Thanks.

Posts: 6
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
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.
    Bookmark Topic Watch Topic
  • New Topic