Exactly! Too bad I cannot say it in 4 lines the way you do ;-) Miro
Madl Alfred wrote on 10/7/2003, 9:05 AM: > 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 [mailto:[EMAIL PROTECTED] > Sent: Dienstag, 07. Oktober 2003 15:49 > To: Brian Behlendorf; Jean-Bernard Stefani; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED]; > [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: [ObjectWeb architecture] Re: licenses for ObjectWeb components > & Apache/OW collaboration > > > > > > maybe this is a silly question, but somewhere > > > > (http://incubator.apache.org/projects/geronimo-proposal.html) I > have > > > > read that one of the main purposes behind starting Geronimo > > project was > > > > absence of ASF (or BSD like) licensed J2EE server. If Objectweb > is > > > > 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 > BSD. I > > > 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, > or > > > small runtime memory size versus everything else. Furthermore, if > two > > > 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 > of > > > 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 > benefit. > > 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 > http://freedesktop.org/ to ensure interoperability. It may be beneficial > > to come up with http://freej2ee.org/ 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 > ;-) > > Miro > > >
