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.

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.

> 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.

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.

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.

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.)

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.

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.)

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.

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.

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.

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