As predicted, the Apache Geronimo open source Java EE application server is beginning to receive support from appserver vendors looking to build off of Geronimo rather than support their own code bases. In the first of such announcements for Geronimo, Denmark-based Trifork, maker of the Trifork J2EE application server, has donated their commercial CORBA implementation to Apache Geronimo.

The CORBA implementation, needed to implement the IIOP support mandated by the J2EE 1.4 spec, is probably one of biggest pain points for open source J2EE appservers, as IIOP is arguably one of the least used features of a Java EE appserver. Donating a commercial CORBA implementation to Geronimo is a big deal, and removes the burden on the Geronimo team to have to maintain and tune their own version, allowing them to focus more valuable parts of the J2EE 1.4 spec.

In addition to the donation of the CORBA code, Trifork also announced that all future versions of their application server will be based on Geronimo. Trifork 5 will be based on the Geronimo foundation while utilizing Trifork's own EJB and WEB containers. Trifork will continue to support previous versions of the application server, the J2EE 1.3 compatible Trifork EAS and the J2EE 1.4 compatible Trifork
T4.

"We congratulate the Apache Geronimo project team on the 100% pass of the J2EE 1.4 test suite;" says Jørn Larsen, CEO of Trifork, "but we know from experience that there is a long way from here to a real product, and we're committed to go all the way with Geronimo."

Like IBM and BEA, Trifork will also be providing worldwide professional support for the Geronimo platform, including professional services and training.

JBoss too has seen support like this in the past, with Novell, ATG, and IONA making similar announcements in the last few years.

Geronimo's transition to be using Trifork's CORBA technology is expected to be able to complete in a less than four months.

As predicted...

Moving away from shipping home-grown J2EE app servers, to an open source solution is not a new phenomenon, Floyd. More well known, and forward looking vendors like Iona, Novell, and ATG have already made this move awhile back.

More well known, and forward looking vendors like Iona, Novell, and ATG have already made this move awhile back.

Thanks for pointing that out, I edited the first post to include mention of this, we take balanced editorial very seriously.

BTW, TSS has reported on those news items awhile back, as well.

Floyd

On a different post I had made my point that Sun should also do similar thing. There is no point in open sourcing failed commercial projects as Sun is doing with Glassfish. Instead Sun should donate areas in which their app server is good to any open source (whichever one Sun finds interesting). Sun will do a lot good to the community if Sun could invest those resources on other more important/pressing needs of the community. Unfortunately some people from Sun did not like it and thought I was bashing Sun. Far from bashing Sun, I was suggesting that as benevolent grand daddy of Java, Sun can help the community by doing so. I would not make a similar suggestion for other companies as they are not in same league as Sun as far as community based benevolence is concerned.

Surprise, JBoss drone pipes in to slag the competition.

Maybe Geronimo will one day displace my favorite free J2EE Container - Sun Java System Application Server.

As predicted...

Moving away from shipping home-grown J2EE app servers, to an open source solution is not a new phenomenon, Floyd. More well known, and forward looking vendors like Iona, Novell, and ATG have already made this move awhile back.

:-)) yep, you're right. and guess what. those announcements back than were as useless as this one :-))

As predicted...

Moving away from shipping home-grown J2EE app servers, to an open source solution is not a new phenomenon, Floyd. More well known, and forward looking vendors like Iona, Novell, and ATG have already made this move awhile back.

What code/components/subsystems did Iona, Novell, and ATG donate to JBoss in return for using the appserver?

As predicted...

Moving away from shipping home-grown J2EE app servers, to an open source solution is not a new phenomenon, Floyd. More well known, and forward looking vendors like Iona, Novell, and ATG have already made this move awhile back.

What code/components/subsystems did Iona, Novell, and ATG donate to JBoss in return for using the appserver?

There really aren't any huge gaping holes in our middleware stack where we would need a huge contribution like an ORB. This isn't to say we don't encourage or welcome corporate contributors or contributions. For instance, Novell has a deep relationship as they have committed programming resources to projects like JBoss Portal and app server. Unisys puts resources into our next-gen admin console. HP and Intel help out a lot in our benchmarking efforts. There's also something called the JBoss Federation. It is the same idea as sites like Codehaus, except we also create a business network. Really, the proliferation of our professional open source model.

The CORBA implementation, needed to implement the IIOP support mandated by the J2EE 1.4 spec, is probably one of biggest pain points for open source J2EE appservers, as IIOP is arguably one of the least used features of a Java EE appserver.

This is probably so, but this is a great pity, as Corba support is in theory a great feature: just plug your C++ or Visual Basic client application to your EJBs. In practice it is difficult, as you get an IDL which fit's to the EJB remote interface and which isn't a "natural" Corba IDL nor easy to read or implement.

Concerning the ORB, I regret very much that Geronimo cannot use the excellent JacORB ORB which is based on an open source community and not a product dumped by a company, but its LGPL license is probably not compatible to the Apache license.