geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Madl Alfred" <>
Subject RE: [ObjectWeb architecture] Re: licenses for ObjectWeb components & Apache/OW collaboration
Date Tue, 07 Oct 2003 14:05:08 GMT
Hi !

There is even no reason why not to have alternatives for the "glue"
also. But it would be nice to have a COMPATIBLE services architecture
(are there any standards / JSRs for that ?) to have some kind of
plug&play between Jonas and Geronimo services.

Just my 2 cents...

Alfred Madl

-----Original Message-----
From: Miroslav Halas [] 
Sent: Dienstag, 07. Oktober 2003 15:49
To: Brian Behlendorf; Jean-Bernard Stefani;;;;;
Subject: [ObjectWeb architecture] Re: licenses for ObjectWeb components
& Apache/OW collaboration

 > > > maybe this is a silly question, but somewhere
 > > > ( I
 > > > read that one of the main purposes behind starting Geronimo
 > project was
 > > > absence of ASF (or BSD like) licensed J2EE server. If Objectweb
 > > > willing to change license on some of its components, maybe it
 > would be
 > > > possible to change the license of Jonas as well.
 > > > Question: Would that be possible / feasible at all ?
 > > I can't speak for ObjectWeb on licensing all of JOnAS under the
 > > can say that even if they were to do so, there might still be good
 > reason
 > > to have an more than one BSD-licensed Sun-certified J2EE server.
 > > "Duplication of effort" should be avoided of course, but even when
 > writing
 > > standards-conformant software, there can be genuinely different
 > approaches
 > > with different tradeoffs - speed vs. code complexity, for example,
 > > small runtime memory size versus everything else.  Furthermore, if
 > > teams are separately trying to solve the same problem, your odds of
 > > finding the right answer are greater than if you just had one team
 > > similar size, and both teams can probably enjoy the fruits of the
 > winning
 > > team's efforts.

Don't get me wrong, I have absolutely no reason to object to competition

which usually results in improvement of both sides and benefits users 
(once they get past the point of figuring out what to support and how

I am just trying to understand what is (or suppose to be) the difference

between Jonas and Geronimo.

In my understanding J2EE server consists of set of services implementing

individual pieces of the J2EE stack and "glue" which puts them together.

Design and implementation of individual services have the most impact on

performance and functionality of the server once the server is running. 
The "glue" has most impact on usability, managability and performance of

such things as server startup.

My point is that if you want to replace the individual services, why 
don't use the "glue" from jonas. If you want to replace the "glue" why 
don't use the complete set of services from jonas. This way you may be 
able to get towards usable outcome faster and both communities can

Jonas was already designed and implemented with notion of plug-in 
services. Proof of it is that it supports Jetty and Tomcat at the same 
time. It is just to the benefit of Jonas (and it's users) to support any

other services which would come as outcome of Geronimo if they are 
better that it's own and vice versa.

Just in idea, maybe the best way is to learn from KDE/Gnome coexistance.

They both follow specifications and standards set by to ensure interoperability. It may be beneficial

to come up with setting up standards for 
interoperability of free j2ee implementations (either of glue or pieces 
of the stack) to make easier for all implementors to support/reuse each 
other's pieces. This can for example specify what form individual 
services take (e.g. interfaces to manage them) and what form the glue 
take. Lots of this is probably set by different JSR's but I am not 
following it to so much details so know if it even specifies details how

to reuse implementations of j2ee stack.

In any case, these are exciting times and I am glad I can be part of ti


View raw message