The leader in enterprise class, open source middleware

JBoss Enterprise Middleware

Subscribe to JBoss Enterprise Middleware: eMailAlertsEmail Alerts newslettersWeekly Newsletters
Get JBoss Enterprise Middleware: homepageHomepage mobileMobile rssRSS facebookFacebook twitterTwitter linkedinLinkedIn


JBoss Authors: Stackify Blog, XebiaLabs Blog, Dynatrace Blog, Michael Kopp, Jayaram Krishnaswamy

Related Topics: Java EE Journal, JBoss Enterprise Middleware, Java Developer Magazine

J2EE Journal: Article

JBoss Group Commits to J2EE 1.4 Certification for JBoss Open Source Java Application Server

JBoss Group Commits to J2EE 1.4 Certification for JBoss Open Source Java Application Server

JBoss Group LLC announced this week that it has reached an agreement with Sun Microsystems, Inc. to license the J2EE 1.4 technology compatibility kit to certify the industry's most popular open source, Java-based application server, JBoss. In an exclusive statement to JDJ, JBoss explains their take on certification:

"JBoss Group's commitment to J2EE certification for the JBoss application server is part of our strategy of delivering Professional Open Source, this means making Open Source the "safe" choice for enterprise IT. As JBoss is increasingly used in development and production in large government and corporate IT environments, we recognize the importance of accommodating the level of people in the application server decision-making process, for whom J2EE certification is important. Another driving force in our push for certification has been our software and services partners. Through our JBoss J2EE Founders Program, which includes Borland Software Corporation, IONA, SchlumbergerSema, Sonic Software, Unisys and webMethods, we leverage the larger JBoss community in a testing process that not only involves licensing fees from Sun, but significant staff and system resources to complete over the next six to nine months."

"This moves JBoss into the enterprise server market and reaffirms the strength of the J2EE brand, adding a huge user base and providing an inexpensive development and deployment platform to the list of J2EE products," commented Joseph Ottinger, JDJ's J2EE editor. "This is excellent news; for JBoss users, it means JBoss will have a larger potential market; for developers, it adds an inexpensive development platform; for J2EE, it adds critical mass to the marketplace."

JBoss Group is testing its product with Sun's J2EE 1.4 Compatibility Test Suite (CTS), a suite of tests, tools and documentation that provides a standard way of testing an implementation for compatibility with the J2EE specification, thus demonstrating the company's commitment to the J2EE value proposition of choice, flexibility and compatibility.

"At this stage, we are able to make this major financial commitment because of the impressive success JBoss Group is experiencing with production and developer support, plus training around JBoss," said Marc Fleury, founder of JBoss.org and president of JBoss Group. "As JBoss grows in popularity for both development and deployment, JBoss Group believes it's important to invest the funds and resources necessary to test and certify JBoss. It will further cement partnerships with major independent software vendors and the largest enterprises and system integrators."

"We particularly want to thank our partners for their support," said Bob Bickel, vice president strategy and corporate development, JBoss Group. "The JBoss community will be invited to assist us in making sure we achieve certification as soon as possible. Information will be available on our web site on how other partners can assist with this important program."

"J2EE Compatibility continues to be a critical customer requirement for enterprise software, one that prevents vendor lock-in and provides customers with choice and flexibility. As such, Sun is pleased to welcome JBoss Group into the Java community," said Rick Schultz, group product manager for J2EE and Sun Java System Application Server. "The agreement reached between Sun and JBoss Group makes it possible for JBoss Group to plan the delivery of its first J2EE Compatible application server that will in turn provide greater selection of tested J2EE technologies, and will extend the benefits of compatibility to the open source community."

More Stories By Java News Desk

JDJ News Desk monitors the world of Java to present IT professionals with updates on technology advances, business trends, new products and standards in the Java and i-technology space.

Comments (12) View Comments

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.


Most Recent Comments
Zandro 11/25/03 01:55:00 PM EST

You guys are something else at JDJ. You print a scathing report on Sun''s free app server which IS J2EE compliant and soft sell the fact JBoss is FINALLY doing the right thing and certifying. This article should be titled "JBoss bait and switch starts". The simple truth is JBoss Group is trying to make money off of their own ''free'' product. For all of Fleury''s posturing and simple minded rhetoric, this was always the plan. JBoss is losing market share and few large companies will gamble on their lack of certification. The big question is did they wait too long to certify.

Fernando Lozano 11/24/03 12:07:38 PM EST

It''s not ridiculous to expect the specs to provide everything I need to build and deploy a real-world applicaton, whatever Aplication Server I choose. Are you deploying J2EE apps which doen''t use relational databases at all? No, so it sould be part of the specs. It isn''t because vendors don''t want to free users from their proprietary OO maping tools.

Imagine if Internet e-mail standards did not provied for binary file attachments because new file formats are born everyday. Maybe we could just tell "there''s uuencode already, so there''s no need for MIME". E-mail would have its usefulness very limited.

Providing specs for OO-Relational mapping does not precludes other technologies (that''s what BMP Entity beans are for). And, if some other tecnology (say, XML databases) become widespread, I expect the specs provide a standard way to map my entites to it.

I didn''t knew the next specs for JDO would provide a standard mapping. I hope it is complete, so I can replace CMP by JDO.

Brad O''Hearne 11/22/03 08:27:22 PM EST

> I think before the spec is fixed regarding obscure issues
> like Classloaders..."

Classloading isn''t an "obscure issue", its the basis for dynamically loading components -- so its pretty much integral. I also don''t even really think the spec needs to be fixed. Not all parts of specifications fall under the "compiler enforced" category. Spec''s that lay out design patterns are like this, and in the case of class loading, I think this falls more under the category of common sense than anything. If a spec expresses a goal of vendor agnostic components, I think it a reasonable assumption that implementations wouldn''t prohibit this.

Larry Schmidt 11/22/03 12:06:51 AM EST

It''s ridiculous to think that the EJB specification should go so far as to over object-relation mapping mechanisms. If they threw in every possible area where an enterprise system could be extended, then it would never have been released. The correct way is to leave it as a vendor-specific extension until a separate standard specification is created to cover these areas. Work is already under progress for the next major version of the JDO spec for O/R mappings.

Fernando Lozano 11/21/03 11:50:15 AM EST

I think before the spec is fixed regarding obscure issues like Classloaders (which aren''t found until someone implements the specs -- that''s why the Internet is so great: IETF first gets running, production-quality code, then it endorses the spec -- the JCP, OSI and others take too long only on paper) we should put pressure on the JCP to make real, workabable and complete specs.

Take the EJB specs, for example. Can you write a real-world app just using the specs? NO! It doesn''t tell how the OO/Relational mapping on EJBs should be. So you cannot write a portable, standards-compliant, app using EJB CMP. Your app will be tied to a particular vendor OO-Relational mapping tool, and it''ll be pain to move to another app server.

That''s why people uses Hybernate, JDO, etc. And them become tied to another vendor (because JDO also does not specifu the syntax for the OO-Relational mapping descriptor).

This only an example of incomplete, unworkable specs from the JCP. The vendors should stop doing politics and delivering real standards, that lets users free to choose the best product, instead of promoting standards just so they can use the name on advertisement.

Anonymous 11/21/03 10:55:25 AM EST

Sure, but if there''s a problem with the spec, the thing to do isn''t to talk about app servers being unusable or whatever - it''s to mail the spec maintainers and get them to fix it. (I have told them about it, BTW.)

Brad O''Hearne 11/21/03 10:53:30 AM EST

Whether its "legal" or not is not really the issue in the pragmatic world. The issue is whether in practice, the implementation prevents the spirit of the spec or some crucial functionality. Having class-version conflicts between different, unrelated 3rd party components is a glaring weakness in implementation. And it doesn''t really matter who does it, Bea, Jboss, whomever -- its a potential deal-killer for those who wish to use an application server to plug third party components (a major driving force behind component development), rather than develop everything in house.

This isn''t the only example of this in the Java API. Plenty of things are "legal" while being very ill-advised. Threading or state inside a servlet is a good example. I won''t get into this here, but the idea is the same -- legal != usable. And there''s no value in a certification, regardless of legality, if it isn''t usable.

Anonymous 11/21/03 10:44:09 AM EST

Well, I''ve read the J2EE spec in detail, and the unified classloader is acceptable. References to the classloader in the spec are hard to find: the SERVLET spec recommends that the webapp''s library path be searched first, but that''s ONLY a recommendation. Thus, app servers that do it "wrong" (i.e., through a unified classloader) like WAS and JBoss are still within spec. (For the record, WebLogic used to do this, too.)

Brad O''Hearne 11/21/03 10:39:17 AM EST

It will be interesting to see if Sun''s certification process addresses JBoss'' unified classloader, which creates potential versioning problems with integrating third-party components -- one of the primary tenets of the J2EE spec and server-side component development in general. I''ll also be interested to see if JBG finally decides to consider alternatives to the unified classloader as a result.

Leonardo Mendoza III 11/21/03 09:44:35 AM EST

JBoss is not exactly open source - it''s called ''professional open source'' according to JBoss people (thus the fees for product documentation). Since JBoss generates cash and other open source projects do not may be the reason why they need to pay for certification.

JBoss being certified is certainly a good thing. This makes JBoss a really viable alternative for corporations who are very concious about these things.

Perhaps we can see a drastic reduction in prices from other J2EE server brands in the future.

Ridai 11/21/03 01:26:19 AM EST

I''m a bit disapointed.... I''m using JBoss for almost 2 years, I never missed the "certified" fuzz. So, I hope that this doesn''t mean that JBoss will slowly become a "not-that-open" software.

John Schmidt 11/21/03 12:15:42 AM EST

Surprising lack of feedback after all the mud Sun and JBoss competitors were throwing around.

The real story is that JBoss had to pay, while other OSS projects did not.

--Jack