Abandon Fish! Migrating from GlassFish to JBoss or TomEE

I'v been a bit busy lately writing and reviewing stuff and didn't really had the chance to wrap up content for my blog. But things will change again and I am truly looking forward to that. So this is just a small reminder about one of the latest things I've been working on. RebelLabs published their latest report yesterday and it was my pleasure to put some efforts into it.

Since a while the GlassFish community is a bit uncertain about the future of GlassFish and many developers are looking into alternatives. There are plenty of recommendations backed by vendors and evangelists. And nobody looked into the details and problem areas. It was time to change that and a bunch of people put together their thoughts and experiences about what it takes and which would be the best migration target. The outcome is the Abandon Fish! report. You can get it for free (at least for the price of your email if you want the PDF) and it contains all about the history of GlassFish, an assessment of the political situation and influencing parameters and a solid analysis about the different containers and reference implementations used on different servers. The outcome are 34 pages, beautifully designed and easy to read which guide you through the first steps and give you very good hints on what to expect when trying to migrate your existing applications from GlassFish to WildFly or TomEE.


WildFly 8 vs. GlassFish 4 – Which Application Server to Choose.

It's been a while since my last blog. I've obviously been busy with different things including my main job. After some more questions regarding the right choice for application servers cross my way it is the right time to pick this topic up again and share my thoughts.

One of the most read post on this blog is the post about which Java EE 6 application server to choose. I've been looking at a bunch of criteria and knocked down the different certified servers according to a very basic but common pattern. Given the main guideline that each server should be available as OSS and commercially supported variant the post concludes with recommending both GlassFish 3 and JBoss AS7 as valid choices. After the GlassFish roadmap updates from last November the situation seems to have changed and many people tend to accept that AS7/WildFly now remain the only alternative. Today I'd like to shift the focus on this a bit and try to put the discussion back into a more strategical context and elaborate further on the impact on the GlassFish vs. WildFly decision as of today.

Basic Strategy Principle for Java EE Applications
Beginning with having made the decision to develop a new application based on Java EE you already assumed a couple of things. Java EE is called an industry standard for a reason. It means it is widely adopted and still not officially captured by one of the official standards or standardization organisations like DIN/ISO or IEEE. The JCP provides rules and regulations for it and governs it along a broad contribution from different individuals and organizations. Calling it an open industry standard is common and valid for me. You may weight the difference between both on your own. In principle the Java EE certification list provides you with a range of different products which at least comply to the so called Java EE TCK. The TCK is heavily discussed and it is safe to assume that it does not cover every single line of all contained specifications completely. But every certified Java EE server should basically be ready to execute a Java EE application. The write once - run everywhere principle can be achieved (at least to a certain extend).
Bottom line of your decision is: Avoid (vendor) specific features and build your new application on an open industry standard which provides flexibility and choice between different products and vendors.
Beside this you gain additional value by having the flexibility to choose from a broad range of companies and developers offering skills and services in Java EE technologies.

WildFly 8 and GlassFish 4 are equal from a Java EE 7 Perspective
With the announcement of WildFly 8 CR1 it passes the Java EE 7 TCK. Even if the official paperwork obviously haven't been completely processed it looks like the 8 final will officially be certified. At least with regards to the Java EE 7 technologies both servers offer the same. There is and always has been different additional features surrounding the core technology stack but I haven't done a complete feature comparison of them and I honestly have no intend of doing it.
If you plan on doing a greenfield development come up with your own decision making process and weight those additional metrics in. You're already and Oracle or Red Hat customer? Or using additional infrastructural components which work best with the one or the other? In my experience you also need to weight in a couple of others (from my own experience we are talking about >=30) and rank them accordingly.

Migrate from GlassFish 2.x, 3.x to 4.0?
The most commonly asked question these days. What should I do with the applications which are already running on GlassFish 2.x or 3.x? It probably is the hardest one. I would need to know a bit more from you to answer it.

Oracle/GlassFish Customer/Shop and not changing anything?
Are you already using the Oracle GlassFish Server (commercially supported version) or are you using the Open Source version? Do you plan on extending the application or use newly introduced Java EE 7 features? If you are hooked up with Oracle or the commercial version already and you are NOT planning on making any changes you basically don't have to worry about migrating at all. Existing Oracle GlassFish Server 2.1.x and 3.1.x commercial customers will continue to be supported according to the Oracle Lifetime Support Policy (PDF). I basically don't recommend to migrate at all if you're in that kind of setting. The extended support for both servers ends in January 2017 (GFv2) respectively March 2019 (GFv3).

Oracle/GlassFish Customer/Shop and willing to use new Java EE 7 features early?
So you are an Oracle Customer and you are keen to use latest technology early? Or you need to heavily modify your applications?
You basically have three options: Stick with the GlassFish 4 OSS Version (without support contract) or move to the WebLogic 12c (12.1.4) which will most likely have full EE 7 support or do this step by step by first moving to GF 4 and then to WebLogic 12.1.4 later.
Directly switching to GlassFish and planning to go on with WebLogic in production later carries the risk of using different application servers in development and production. You need to value this in and handle it accordingly.
To completely reduce the risk I would recommend to wait for at least the WebLogic 12.1.3 which is expected to have a first set of new Java EE 7 specifications and will hopefully available sometime during the first half of CY2014.
If you don't run a mission critical application and you don't need a support contract I recommend to migrate to GlassFish 4.0 in order to facilitate the already available infrastructure and skills and contracts. To me there is no point in hastily switching vendors. Be prepared for ending support contracts and plan on evaluating your decisions about the right Open Source Application Server then.

Not really and Oracle Customer/Shop, not changing anything no interest in new EE 7 features?
Don't migrate at all until your requirements change. You might start evaluating your next Java EE 7 server product soon. But as of today there aren't many certified alternatives available.

Not really and Oracle Customer/Shop, changing requirements, will to use new EE 7 features?
Might be time to revisit your IT landscape this year. It seems as if you've decided to go with GlassFish at some point. You might have to revisit your former decision and evaluate what to do. To make a well grounded decision about your next Java EE server you are too early. The certification matrix for EE 7 servers is mostly empty. Wait for more alternatives to come up. I expect this to take most of CY2014.
If you have the need for new EE 7 features as of today and you need to be able to buy commercial support in the future but don't need it right here and now the only alternative you have is WildFly 8.

What does the future hold for GlassFish 4?
I wish I could tell you. I guess I made my points in the earlier posting. Oracle needs GlassFish to stick around as Java EE Reference Implementation and given the number of commonly used components in both WebLogic and GlassFish it will always be there. And it is safe to assume that the Java EE specifications will always be the latest and greatest in GlassFish. But the Java EE ecosystem lead to a bunch of vendor specific extensions and features which are not really covered by any specification. Those are commodity  to all of us (mostly clustering, admin Features, embedded server) and we don't want to miss them in many cases. Further on the patch frequency and grade of community participation will be crucial factors for the successful spread of GlassFish among projects and developers.

R.I.P. GlassFish – Thanks for all the fish.

We've all heard it coming probably. Yesterday the official roadmap update for JavaEE and GlassFish was updated and published. And beginning with the title the whole post was basically about one thing: GlassFish Server as we know it today is deprecated from a full blown product to a toy product.

The Long Road from Sun to Oracle
GlassFish was something to worry about right from the start. After the merger it took some time to silence the voices which insisted on "Oracle killing GlassFish". Oracle did a decent job in nurturing the community and keeping their stuff together. I've written a couple of blogs myself helping to get the word out. The 100-day releases 2.1.2 and 3.0.1 have somehow become the milestone to prove the will to improve. And we all have been fine with it after a while. Even back in January 2013 I compiled a list of open source application servers and which one to pick. The final criteria was vendor support. That kicked WAS CE out of the game. As of yesterday it would also removed GlassFish. The two remaining alternatives burned down to one: Which is JBoss AS7 / WildFly.

Customers Need Support for their Servers
But come on, what is the issue here? Who wants support anyway? And Oracle obviously did not make enough money out of the commercial licenses otherwise they wouldn't have killed the offering at all. It might not be a very obvious reason but I can offer some kind of explanation. First of all if a vendor is not only developing an open source alternative but also has a commercial offering this leads to different things that will be taken care of implicitly:
- Changes/Bugs discovered by customers go into the oss release
- Changes need to have a decent quality. Developers knowing about the need to support their solutions will be (at least a bit) more careful implementing stuff.
- Developers knowing that their stuff is run under decent load think differently implementing it. The complete list of non-functional criteria changes with that move.
- Customers demand more frequent releases and security patches which also end up in the oss version.
- Customers have different requirements than people using free and open source servers. One prominent example is clustering. Which is rarely used among oss projects.

Another factor is driven by experience. I would never try to develop project on a completely different setting than the production setting is at. Even that both WLS and GF understand at least a bit of each others deployment descriptors there is a high risk buried in here that such a setting is the road to trouble.

The bottom line of my argumentation basically is, that the need for providing a commercial distribution improves the overall quality and reliability by changing some relevant non functional requirements for the product. If those aren't there and nobody is consequently taking care of them ... they will not be in there.

Why will Java EE suffer from a dead GlassFish?
The quality of the Java EE TCK has been questioned a lot. And in the past many people used GF as a showcase for not working code. On top of that some production scenarios and errors lead to different implementations and last but not least specifications. All the practical field knowledge has been in the heads of the team. I don't know how Oracle is running WLS development internally but I expect it do be different from what the team did for GF, probably a bit heavier. Extracting specification edge-cases and removing product specific parts from WLS based customer cases will for sure be trickier and not happen very frequently. So I expect the spec to be a little less Oracle driven and a little less mature generally. Not the worst part in the story. But given the fact that some very bright minds are working in that area I expect that their passion and knowledge will be missed a lot. And there is nobody there to catch them falling.

Which Parts of GlassFish will die?
So GlassFish will stay the reference implementation for upcoming Java EE standards. Oracle needs it to be around just for that one reason. With the emerging JCP which is becoming more and more open it isn't a big surprise that they are not simply going to define WLS as the RI. But that will be the cut between things that will die and things that will be around. I DON'T have any insights here and I'm just speculating and I could make an educated guess about the first comment on this blog but .. bottom line for me is, that everything that isn't covered by the Java EE spec is going to age very fast. This could include clustering and for sure some of the admin features and security also is a good candidate (PAM realm and others). And frankly I can't confirm any of them. It is pure speculation!

Is there a good part in that at all?
Well, yes: The move leaves a field wide open for strengthened competition. And this is not only WildFly but for sure also TomEE with tomitribe. Congratulations to them. Further on many customers will save a lot of license fees. GF and WLS are differently licensed and using WLS standard gives customers more options on picking the right license. And at least the WLS team will be strengthened with those people don't having to switch heads anymore working frequently on different products.

Can Oracle do something to make the killing worth it?
As of today it is a senseless death. Users can simply sit back and wait for the next minor release which probably will happen once a year. If you've been complaining about infrequent releases until today .. prepare for even less in the future. There are indeed a couple of things Oracle could do to make this a strategic move for everybody and not only themselves:
1) Develop and support a clear upgrade path. Find a way to at least support a development setting based on a very lightweight server and only deploy to a full blown WLS in production. With the given features and differences between the two this is hardly a working story as of today.
2) Make an attractive licensing offering for GF users. Not only to the customers as of today but for all. Or even better: Come up with a bunch of licensing terms in the OTN license which allows NPOs to use WLS free of charge.
3) Consequently open-source GF (under a decent license) and make community contributions attractive. The used infrastructure and OCA makes this impossible as of today. Move the server code (including modules) to GitHub and appoint a change manager who reviews and pulls in proposed fixes and changes. Let the community decide on releases.

The Echoes Are Gone In The Hall
Basically the news isn't a big surprise. We all understand the move. Having two servers instead of one is a double burden. With the BEA merger Oracle killed their own application server. Now it was GlassFish's turn. Oracle already tried to reduce the needed efforts to maintain it by merging the teams and also discussed different options along merging WLS to HK2 or extending the use of the same components for both servers. Some things happened and pushed the time for yesterdays announcement out by a couple of months but finally did not prevent it. So. R.I.P. GlassFish. It was nice. Thanks for all the fish.



R.I.P. GlassFish – Thanks for all the fish.

We've all heard it coming probably. Yesterday the official roadmap update for JavaEE and GlassFish was updated and published. And beginning with the title the whole post was basically about one thing: GlassFish Server as we know it today is deprecated from a full blown product to a toy product.

The Long Road from Sun to Oracle
GlassFish was something to worry about right from the start. After the merger it took some time to silence the voices which insisted on "Oracle killing GlassFish". Oracle did a decent job in nurturing the community and keeping their stuff together. I've written a couple of blogs myself helping to get the word out. The 100-day releases 2.1.2 and 3.0.1 have somehow become the milestone to prove the will to improve. And we all have been fine with it after a while. Even back in January 2013 I compiled a list of open source application servers and which one to pick. The final criteria was vendor support. That kicked WAS CE out of the game. As of yesterday it would also removed GlassFish. The two remaining alternatives burned down to one: Which is JBoss AS7 / WildFly.

Customers Need Support for their Servers
But come on, what is the issue here? Who wants support anyway? And Oracle obviously did not make enough money out of the commercial licenses otherwise they wouldn't have killed the offering at all. It might not be a very obvious reason but I can offer some kind of explanation. First of all if a vendor is not only developing an open source alternative but also has a commercial offering this leads to different things that will be taken care of implicitly:
- Changes/Bugs discovered by customers go into the oss release
- Changes need to have a decent quality. Developers knowing about the need to support their solutions will be (at least a bit) more careful implementing stuff.
- Developers knowing that their stuff is run under decent load think differently implementing it. The complete list of non-functional criteria changes with that move.
- Customers demand more frequent releases and security patches which also end up in the oss version.
- Customers have different requirements than people using free and open source servers. One prominent example is clustering. Which is rarely used among oss projects.

Another factor is driven by experience. I would never try to develop project on a completely different setting than the production setting is at. Even that both WLS and GF understand at least a bit of each others deployment descriptors there is a high risk buried in here that such a setting is the road to trouble.

The bottom line of my argumentation basically is, that the need for providing a commercial distribution improves the overall quality and reliability by changing some relevant non functional requirements for the product. If those aren't there and nobody is consequently taking care of them ... they will not be in there.

Why will Java EE suffer from a dead GlassFish?
The quality of the Java EE TCK has been questioned a lot. And in the past many people used GF as a showcase for not working code. On top of that some production scenarios and errors lead to different implementations and last but not least specifications. All the practical field knowledge has been in the heads of the team. I don't know how Oracle is running WLS development internally but I expect it do be different from what the team did for GF, probably a bit heavier. Extracting specification edge-cases and removing product specific parts from WLS based customer cases will for sure be trickier and not happen very frequently. So I expect the spec to be a little less Oracle driven and a little less mature generally. Not the worst part in the story. But given the fact that some very bright minds are working in that area I expect that their passion and knowledge will be missed a lot. And there is nobody there to catch them falling.

Which Parts of GlassFish will die?
So GlassFish will stay the reference implementation for upcoming Java EE standards. Oracle needs it to be around just for that one reason. With the emerging JCP which is becoming more and more open it isn't a big surprise that they are not simply going to define WLS as the RI. But that will be the cut between things that will die and things that will be around. I DON'T have any insights here and I'm just speculating and I could make an educated guess about the first comment on this blog but .. bottom line for me is, that everything that isn't covered by the Java EE spec is going to age very fast. This could include clustering and for sure some of the admin features and security also is a good candidate (PAM realm and others). And frankly I can't confirm any of them. It is pure speculation!

Is there a good part in that at all?
Well, yes: The move leaves a field wide open for strengthened competition. And this is not only WildFly but for sure also TomEE with tomitribe. Congratulations to them. Further on many customers will save a lot of license fees. GF and WLS are differently licensed and using WLS standard gives customers more options on picking the right license. And at least the WLS team will be strengthened with those people don't having to switch heads anymore working frequently on different products.

Can Oracle do something to make the killing worth it?
As of today it is a senseless death. Users can simply sit back and wait for the next minor release which probably will happen once a year. If you've been complaining about infrequent releases until today .. prepare for even less in the future. There are indeed a couple of things Oracle could do to make this a strategic move for everybody and not only themselves:
1) Develop and support a clear upgrade path. Find a way to at least support a development setting based on a very lightweight server and only deploy to a full blown WLS in production. With the given features and differences between the two this is hardly a working story as of today.
2) Make an attractive licensing offering for GF users. Not only to the customers as of today but for all. Or even better: Come up with a bunch of licensing terms in the OTN license which allows NPOs to use WLS free of charge.
3) Consequently open-source GF (under a decent license) and make community contributions attractive. The used infrastructure and OCA makes this impossible as of today. Move the server code (including modules) to GitHub and appoint a change manager who reviews and pulls in proposed fixes and changes. Let the community decide on releases.

The Echoes Are Gone In The Hall
Basically the news isn't a big surprise. We all understand the move. Having two servers instead of one is a double burden. With the BEA merger Oracle killed their own application server. Now it was GlassFish's turn. Oracle already tried to reduce the needed efforts to maintain it by merging the teams and also discussed different options along merging WLS to HK2 or extending the use of the same components for both servers. Some things happened and pushed the time for yesterdays announcement out by a couple of months but finally did not prevent it. So. R.I.P. GlassFish. It was nice. Thanks for all the fish.



GlassFish 4 brings Java EE 7

What a surprise. Apple had nothing to offer at wwdc except the new iOS 7 launch. Might be coincidence that shortly after their keynote another 7 made an official appearance. GlassFish 4.0 was release yesterday evening (obviously unwanted). The new Java EE 7 reference implementation automatically is the first Java EE 7 application server available today.

New Website 
After 89 promoted builds (first from 14-Sep-2011) it took the team 1 year, 8 months and 1 day to get the new release ready. Congratulations to the release. Everything seems to point to the fact, that it should have been released for the June 12 launch event. Some links on the completely reworked website didn't work yesterday and the NetBeans 7.3.1 release which finally supports Java EE 7 isn't available as of today. The commercial offering which is called "Oracle GlassFish Server" also didn't seem to have hit it's place on OTN.

New Java EE 7 Example
The launch comes with a completely revamped Java EE 7 Example. The "First Cup" application calculates the age of Duke, the Java mascot and interacts with the users. Duke was born May 23, 1995, when the first demo of Java technology was publicly released. It contains JAX-RS, EJB, JSF and JPA. Find the source and some more information on the java.net project website. The complete code is developed under a BSD license and you're free to play around with it.

Now that everything already is here there is still some time to register for the Java EE 7 launch event tomorrow.

Links and further reading:
Official Java EE 7 SDK on OTN
Java EE 7 API
The Java EE 7 Tutorial
Your First Cup: An Introduction to the Java EE Platform
Java EE 7 Technical Documentation

GlassFish 4 brings Java EE 7

What a surprise. Apple had nothing to offer at wwdc except the new iOS 7 launch. Might be coincidence that shortly after their keynote another 7 made an official appearance. GlassFish 4.0 was release yesterday evening (obviously unwanted). The new Java EE 7 reference implementation automatically is the first Java EE 7 application server available today.

New Website 
After 89 promoted builds (first from 14-Sep-2011) it took the team 1 year, 8 months and 1 day to get the new release ready. Congratulations to the release. Everything seems to point to the fact, that it should have been released for the June 12 launch event. Some links on the completely reworked website didn't work yesterday and the NetBeans 7.3.1 release which finally supports Java EE 7 isn't available as of today. The commercial offering which is called "Oracle GlassFish Server" also didn't seem to have hit it's place on OTN.

New Java EE 7 Example
The launch comes with a completely revamped Java EE 7 Example. The "First Cup" application calculates the age of Duke, the Java mascot and interacts with the users. Duke was born May 23, 1995, when the first demo of Java technology was publicly released. It contains JAX-RS, EJB, JSF and JPA. Find the source and some more information on the java.net project website. The complete code is developed under a BSD license and you're free to play around with it.

Now that everything already is here there is still some time to register for the Java EE 7 launch event tomorrow.

Links and further reading:
Official Java EE 7 SDK on OTN
Java EE 7 API
The Java EE 7 Tutorial
Your First Cup: An Introduction to the Java EE Platform
Java EE 7 Technical Documentation

GlassFish 4 brings Java EE 7

What a surprise. Apple had nothing to offer at wwdc except the new iOS 7 launch. Might be coincidence that shortly after their keynote another 7 made an official appearance. GlassFish 4.0 was release yesterday evening (obviously unwanted). The new Java EE 7 reference implementation automatically is the first Java EE 7 application server available today.

New Website 
After 89 promoted builds (first from 14-Sep-2011) it took the team 1 year, 8 months and 1 day to get the new release ready. Congratulations to the release. Everything seems to point to the fact, that it should have been released for the June 12 launch event. Some links on the completely reworked website didn't work yesterday and the NetBeans 7.3.1 release which finally supports Java EE 7 isn't available as of today. The commercial offering which is called "Oracle GlassFish Server" also didn't seem to have hit it's place on OTN.

New Java EE 7 Example
The launch comes with a completely revamped Java EE 7 Example. The "First Cup" application calculates the age of Duke, the Java mascot and interacts with the users. Duke was born May 23, 1995, when the first demo of Java technology was publicly released. It contains JAX-RS, EJB, JSF and JPA. Find the source and some more information on the java.net project website. The complete code is developed under a BSD license and you're free to play around with it.

Now that everything already is here there is still some time to register for the Java EE 7 launch event tomorrow.

Links and further reading:
Official Java EE 7 SDK on OTN
Java EE 7 API
The Java EE 7 Tutorial
Your First Cup: An Introduction to the Java EE Platform
Java EE 7 Technical Documentation

GlassFish 4 brings Java EE 7

What a surprise. Apple had nothing to offer at wwdc except the new iOS 7 launch. Might be coincidence that shortly after their keynote another 7 made an official appearance. GlassFish 4.0 was release yesterday evening (obviously unwanted). The new Java EE 7 reference implementation automatically is the first Java EE 7 application server available today.

New Website 
After 89 promoted builds (first from 14-Sep-2011) it took the team 1 year, 8 months and 1 day to get the new release ready. Congratulations to the release. Everything seems to point to the fact, that it should have been released for the June 12 launch event. Some links on the completely reworked website didn't work yesterday and the NetBeans 7.3.1 release which finally supports Java EE 7 isn't available as of today. The commercial offering which is called "Oracle GlassFish Server" also didn't seem to have hit it's place on OTN.

New Java EE 7 Example
The launch comes with a completely revamped Java EE 7 Example. The "First Cup" application calculates the age of Duke, the Java mascot and interacts with the users. Duke was born May 23, 1995, when the first demo of Java technology was publicly released. It contains JAX-RS, EJB, JSF and JPA. Find the source and some more information on the java.net project website. The complete code is developed under a BSD license and you're free to play around with it.

Now that everything already is here there is still some time to register for the Java EE 7 launch event tomorrow.

Links and further reading:
Official Java EE 7 SDK on OTN
Java EE 7 API
The Java EE 7 Tutorial
Your First Cup: An Introduction to the Java EE Platform
Java EE 7 Technical Documentation

JavaEE 7 with GlassFish on Eclipse Juno

Java EE 7 is hot. The first four JSRs passed the final approval ballot recently and GlassFish 4 reached promoted build 83 in the meantime. If you are following my blog you know, that I do most of my work with NetBeans. But I indeed recognize, that there are other IDE users out there which also have a valid right of also testdriving the latest and greatest in enterprise Java.

The GlassFish Eclipse Plugins
The starting place for Eclipse are the GlassFish Eclipse plugins. They moved into the Oracle Enterprise Pack for Eclipse (OEPE) project a while back and are still there to be installed and configured separately. The easiest way to get them is to use the pre-packaged OEPE bundle. Simply download the suitable version and get started. If you already have you favorite Java EE Eclipse version you can also use the java.net update site for Eclipse Juno. The OEPE package contains oficial releases (more stable, tested) of GF plugins and new releases come one or two times per year. The update sites on java.net contain developer builds that are released as needed, typically a lot more often then OEPE. You can download from whatever meets your needs.

Install the Plugin
This works as expected. If you stick to the update site you simply go to Preferences->Install/Update->Available Software Sites and make sure that the above mentioned site is defined and checked. Install the GlassFish Tools and the Java EE 6 and/or Java EE 7 documentation and sources according to your needs. Click next two times, read through the license and check accept. Click Finish to install. The download gets everything in place and you have to finish the installation with a re-start.

Starting a new Java EE 7 Project
Once that it done you can start with configuring your GlassFish 4.0 domain. The simplest way is to create a New Project > Other > Web > New Dynamic Web Project and select the "New Runtime" button next to target runtime. The New Server Runtime Environment dialogue pops up and you can select "GlassFish 4.0" from the GlassFish folder. Make sure to select a Java SE 7 JDK and the appropriate GlassFish Server Directory to use (or even install). In this example I am using the latest promoted build 83 freshly downloaded from the GlassFish website. Click Finish. Now add a simple servlet which does nothing spectacular but use some Java API for Processing JSON to write a simple JSON string.

protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
response.setContentType("application/json");
PrintWriter out = response.getWriter();

JsonObjectBuilder builder = Json.createObjectBuilder();
builder.add(
"person",
Json.createObjectBuilder().add("firstName", "Markus")
.add("lastName", "Eisele"));
JsonObject result = builder.build();
StringWriter sw = new StringWriter();
try (JsonWriter writer = Json.createWriter(sw)) {
writer.writeObject(result);
}
out.print(sw.toString());
}

Right click the project and select "Run as .." > "Run on Server" > GlassFish 4.0. Now point your browser to localhost and see the result working. The server view gives you the well know overview about your instance. And there you go. Have fun doing your Java EE 7 developments with Eclipse :)

JavaEE 7 with GlassFish on Eclipse Juno

Java EE 7 is hot. The first four JSRs passed the final approval ballot recently and GlassFish 4 reached promoted build 83 in the meantime. If you are following my blog you know, that I do most of my work with NetBeans. But I indeed recognize, that there are other IDE users out there which also have a valid right of also testdriving the latest and greatest in enterprise Java.

The GlassFish Eclipse Plugins
The starting place for Eclipse are the GlassFish Eclipse plugins. They moved into the Oracle Enterprise Pack for Eclipse (OEPE) project a while back and are still there to be installed and configured separately. The easiest way to get them is to use the pre-packaged OEPE bundle. Simply download the suitable version and get started. If you already have you favorite Java EE Eclipse version you can also use the java.net update site for Eclipse Juno. The OEPE package contains oficial releases (more stable, tested) of GF plugins and new releases come one or two times per year. The update sites on java.net contain developer builds that are released as needed, typically a lot more often then OEPE. You can download from whatever meets your needs.

Install the Plugin
This works as expected. If you stick to the update site you simply go to Preferences->Install/Update->Available Software Sites and make sure that the above mentioned site is defined and checked. Install the GlassFish Tools and the Java EE 6 and/or Java EE 7 documentation and sources according to your needs. Click next two times, read through the license and check accept. Click Finish to install. The download gets everything in place and you have to finish the installation with a re-start.

Starting a new Java EE 7 Project
Once that it done you can start with configuring your GlassFish 4.0 domain. The simplest way is to create a New Project > Other > Web > New Dynamic Web Project and select the "New Runtime" button next to target runtime. The New Server Runtime Environment dialogue pops up and you can select "GlassFish 4.0" from the GlassFish folder. Make sure to select a Java SE 7 JDK and the appropriate GlassFish Server Directory to use (or even install). In this example I am using the latest promoted build 83 freshly downloaded from the GlassFish website. Click Finish. Now add a simple servlet which does nothing spectacular but use some Java API for Processing JSON to write a simple JSON string.

protected void doGet(HttpServletRequest request,
HttpServletResponse response) throws ServletException, IOException {
response.setContentType("application/json");
PrintWriter out = response.getWriter();

JsonObjectBuilder builder = Json.createObjectBuilder();
builder.add(
"person",
Json.createObjectBuilder().add("firstName", "Markus")
.add("lastName", "Eisele"));
JsonObject result = builder.build();
StringWriter sw = new StringWriter();
try (JsonWriter writer = Json.createWriter(sw)) {
writer.writeObject(result);
}
out.print(sw.toString());
}

Right click the project and select "Run as .." > "Run on Server" > GlassFish 4.0. Now point your browser to localhost and see the result working. The server view gives you the well know overview about your instance. And there you go. Have fun doing your Java EE 7 developments with Eclipse :)