commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noel J. Bergman" <n...@devtech.com>
Subject RE: Commons server infrastructure proposal
Date Mon, 12 Apr 2004 22:40:24 GMT
> Frankly have not look a lot at a Geronimo project (I will),
> but one thing I can say for sure is that it is a huge one.

We're only talking about the core on which it is built, not the entire
project.

> Ok, the Geronimo has a cool micro-kernel, Tomcat has a great jmx
> manageability, etc...

Yes, and isn't it a shame that they don't work well together (yet)?  It
would be nice to see that change.  FWIW, as I understand it, Geronimo's
kernel is based on JSR's 77 and 88.

> All of that is fine but IMHO I still need to do a huge amount
> of work to make a simple echo server from any of those.

Anytime you have a container architecture, there is some overhead, but I
agree that it would be nice to be able to write a simple echo server
component, and have minimal requirements to load and run it.

> > From a chat with the Geronimo team today: "The Geronimo
> > contains an IOC (dependency injection) micro-kernel which
> > provides only basic wiring of services and life cycle
> > management."

> Are the guys willing to pull that out, and what's most important do they
> feel it's a reusable enough for a clustered session replicator or a IPv6
> reverse proxy ssl server for example?

Dain already replied to these.  Talking with Dain in more depth, he sees the
kernel as the defining Geronimo technology.  He doesn't see Geronimo as
deliverying just a J2EE web server.  He sees an "empty" kernel for use by
other projects as a Geronimo deliverable.  You and I may debate whether or
not the reusable kernel is a separate project or not, but as long as it is
available for people to reuse and collaborate on, I'll put the location in
the "a rose by any other name" category.

Not all common code need be in a place called Commons, e.g., the Logging
project.

So, the answer seems to be "yes" in terms of making it available for other
projects to use.  Geronimo is open to other developers who want to
collaborate on the kernel and core services.

> Well, those kind of applications (beside JK3 and NIO based
> coyote connector) are the one that this _component_ should
> help to unify, and hopefully make a development a lot easier.

Yes.  And if that also means that some future version of Tomcat is also
based on the same technology, making it easier to plug Geronimo and Tomcat
together, that would be another bonus.

> you must agree that there is some redundancy among them.

That's my point, too.  So I'd like to see collaboration on a common codebase
that could serve multiple needs.

> I'm not saying that I found the holy grail that could both fit
> geronimo tomcat and avalon

But if we don't try ... :-)

We may not get every project using common code for the everything, but we
can always try.  I've said the same thing to Geronimo, Avalon, and other
projects when talking about using Jakarta Commons code rather than
implementing new code or going to outside sources.  We should be letting our
ASF peers know what changes we need to be able to reuse our own code.

With James, when we wanted something better than our ugly mordred JDBC pool,
we didn't implement a new one, look elsewhere, or bring in another one from
our own libraries -- we adopted DBCP.  I also mentioned that we need better
logging support, but in the meantime I wrote an adapter to bridge DBCP with
Avalon's logging.

Hence, I'm suggesting that we take a look at Geronimo, see whether or not it
is "adequate" to fill the need, and try to converge on a uniform solution in
that problem domain.

	--- Noel


---------------------------------------------------------------------
To unsubscribe, e-mail: commons-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: commons-dev-help@jakarta.apache.org


Mime
View raw message