Wednesday Nov 06, 2013

6 Facts About GlassFish Announcement

Since Oracle announced the end of commercial support for future Oracle GlassFish Server versions, the Java EE world has started wondering what will happen to GlassFish Server Open Source Edition. Unfortunately, there's a lot of misleading information going around. So let me clarify some things with facts, not FUD.


Fact #1 - GlassFish Open Source Edition is not dead

GlassFish Server Open Source Edition will remain the reference implementation of Java EE. The current trunk is where an implementation for Java EE 8 will flourish, and this will become the future GlassFish 5.0. Calling "GlassFish is dead" does no good to the Java EE ecosystem. The GlassFish Community will remain strong towards the future of Java EE. Without revenue-focused mind, this might actually help the GlassFish community to shape the next version, and set free from any ties with commercial decisions.


Fact #2 - OGS support is not over

As I said before, GlassFish Server Open Source Edition will continue. Main change is that there will be no more future commercial releases of Oracle GlassFish Server. New and existing OGS 2.1.x and 3.1.x commercial customers will continue to be supported according to the Oracle Lifetime Support Policy. In parallel, I believe there's no other company in the Java EE business that offers commercial support to more than one build of a Java EE application server. This new direction can actually help customers and partners, simplifying decision through commercial negotiations.


Fact #3 - WebLogic is not always more expensive than OGS

Oracle GlassFish Server ("OGS") is a build of GlassFish Server Open Source Edition bundled with a set of commercial features called GlassFish Server Control and license bundles such as Java SE Support. OGS has at the moment of this writing the pricelist of U$ 5,000 / processor. One information that some bloggers are mentioning is that WebLogic is more expensive than this. Fact 3.1: it is not necessarily the case. The initial edition of WebLogic is called "Standard Edition" and falls into a policy where some “Standard Edition” products are licensed on a per socket basis. As of current pricelist, US$ 10,000 / socket. If you do the math, you will realize that WebLogic SE can actually be significantly more cost effective than OGS, and a customer can save money if running on a CPU with 4 cores or more for example. Quote from the price list:


“When licensing Oracle programs with Standard Edition One or Standard Edition in the product name (with the exception of Java SE Support, Java SE Advanced, and Java SE Suite), a processor is counted equivalent to an occupied socket; however, in the case of multi-chip modules, each chip in the multi-chip module is counted as one occupied socket.”


For more details speak to your Oracle sales representative - this is clearly at list price and every customer typically has a relationship with Oracle (like they do with other vendors) and different contractual details may apply.


And although OGS has always been production-ready for Java EE applications, it is no secret that WebLogic has always been more enterprise, mission critical application server than OGS since BEA. Different editions of WLS provide features and upgrade irons like the WebLogic Diagnostic Framework, Work Managers, Side by Side Deployment, ADF and TopLink bundled license, Web Tier (Oracle HTTP Server) bundled licensed, Fusion Middleware stack support, Oracle DB integration features, Oracle RAC features (such as GridLink), Coherence Management capabilities, Advanced HA (Whole Service Migration and Server Migration), Java Mission Control, Flight Recorder, Oracle JDK support, etc.

Update 24-11-2013:  clustering support is available on WebLogic Enterprise and Suite editions.

Fact #4 - There’s no major vendor supporting community builds of Java EE app servers

There are no major vendors providing support for community builds of any Open Source application server. For example, IBM used to provide community support for builds of Apache Geronimo, not anymore. Red Hat does not commercially support builds of WildFly and if I remember correctly, never supported community builds of former JBoss AS. Oracle has never commercially supported GlassFish Server Open Source Edition builds. Tomitribe appears to be the exception to the rule, offering commercial support for Apache TomEE.


Fact #5 - WebLogic and GlassFish share several Java EE implementations

It has been no secret that although GlassFish and WebLogic share some JSR implementations (as stated in the The Aquarium announcement: JPA, JSF, WebSockets, CDI, Bean Validation, JAX-WS, JAXB, and WS-AT) and WebLogic understands GlassFish deployment descriptors, they are not from the same codebase.


Fact #6 - WebLogic is not for GlassFish what JBoss EAP is for WildFly

WebLogic is closed-source offering. It is commercialized through a license-based plus support fee model. OGS although from an Open Source code, has had the same commercial model as WebLogic. Still, one cannot compare GlassFish/WebLogic to WildFly/JBoss EAP. It is simply not the same case, since Oracle has had two different products from different codebases. The comparison should be limited to GlassFish Open Source / Oracle GlassFish Server versus WildFly / JBoss EAP.


But the message now is much clear: Oracle will commercially support only the proprietary product WebLogic, and invest on GlassFish Server Open Source Edition as the reference implementation for the Java EE platform and future Java EE 8, as a developer-friendly community distribution, and encourages community participation through Adopt a JSR and contributions to GlassFish.


In comparison

Oracle's decision has pretty much the same goal as to when IBM killed support for Websphere Community Edition; and to when Red Hat decided to change the name of JBoss Community Edition to WildFly, simplifying and clarifying marketing message and leaving the commercial field wide open to JBoss EAP only. Oracle can now, as any other vendor has already been doing, focus on only one commercial offer.


Some users are saying they will now move to WildFly, but it is important to note that Red Hat does not offer commercial support for WildFly builds. Although the future JBoss EAP versions will come from the same codebase as WildFly, the builds will definitely not be the same, nor sharing 100% of their functionalities and bug fixes. This means there will be no company running a WildFly build in production with support from Red Hat.


This discussion has also raised an important and interesting information: Oracle offers a free for developers OTN License for WebLogic. For other environments this is different, but please note this is the same policy Red Hat applies to JBoss EAP, as stated in their download page and terms. Oracle had the same policy for OGS.


TL;DR;

GlassFish Server Open Source Edition isn’t dead. Current and new OGS 2.x/3.x customers will continue to have support (respecting LSP). WebLogic is not necessarily more expensive than OGS. Oracle will focus on one commercially supported Java EE application server, like other vendors also limit themselves to support one build/product only. Community builds are hardly supported. Commercially supported builds of Open Source products are not exactly from the same codebase as community builds.


What's next for GlassFish and the Java EE community?

There are conversations in place to tackle some of the community desires, most of them stated by Markus Eisele in his blog post. We will keep you posted.

Friday Aug 03, 2012

Issue dev'ing RESTful JSON services on NetBeans

Here is a tricky issue that you may find if you are developing RESTful services with Java EE on NetBeans and GlassFish or WebLogic. If you want to support the JSON format but need to access some implementation classes like @JsonIgnore, you need to add the JAX-RS RI, Jersey, to your project's Libraries definition. How to add the RI? You will probably do this:

  1. Open project's Properties (right click on the project)
  2. Go to Libraries
  3. Click on 'Add Library'
  4. Select 'Jersey 1.8 (JAX-RS RI)

But you won't have your service running fine. You may find these exceptions: (added here so Google can help future users)

1 - If you try to access your RESTful service to get a JSON format of it, you will get this exception:

com.sun.jersey.spi.inject.Errors$ErrorMessagesException
  at com.sun.jersey.spi.inject.Errors.processErrorMessages(Errors.java:170)
  at com.sun.jersey.spi.inject.Errors.postProcess(Errors.java:136)
at com.sun.jersey.spi.inject.Errors.processWithErrors(Errors.java:199)

2 - If you try to access your RESTful service to get an XML format, you will get this exception:

java.lang.RuntimeException: javax.naming.NameNotFoundException: Unable to resolve 'com.sun.jersey.config.CDIExtension'. Resolved 'com.sun.jersey.config'; remaining name 'CDIExtension'
  at com.sun.jersey.server.impl.cdi.CDIExtension.getInitializedExtension(CDIExtension.java:177)
  at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactory.(CDIComponentProviderFactory.java:92)
  at com.sun.jersey.server.impl.cdi.CDIComponentProviderFactoryInitializer.initialize(CDIComponentProviderFactoryInitializer.java:75)
  at com.sun.jersey.spi.container.servlet.WebComponent.configure(WebComponent.java:576)
  at com.sun.jersey.spi.container.servlet.ServletContainer$InternalWebComponent.configure(ServletContainer.java:311)

 If you look at your server's log, (in my case, I was using WebLogic 12c) you may find this message somewhere:

WARNING: 
**********
The application is using ServletContainerInitializer class com.sun.jersey.server.impl.container.servlet.JerseyServletContainerInitializer that is loaded from:file:/labs/wls1211/modules/com.sun.jersey.server_1.1.0.0_1-9.jar. This initializer overrides the one available in the system.
**********

When you added Jersey to your library, the "package" checkbox was checked by default. So the JAR ended up going into WEB-INF/lib of your project, conflicting to the already provided by the container. 

So, how to fix this issue? Follow these steps:

  1. Open project's Properties (right click on the project)
  2. Go to Libraries
  3. Uncheck the checkbox 'Package' for Jersey 1.8 (JAX-RS RI)
  4. Click on 'OK'
  5.  Clean & Build (right click on the project) ---> remember to clean and rebuild your project
  6. (re)Deploy application

Done! :_)

 

About


Bruno has been having fun working with Java since 2000 and now helps Oracle on sharing the technology accross all Latin America. Also plays videogames, does trekking and loves beer.

Follow me on Twitter! @brunoborges

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today