commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rory Winston" <>
Subject RE: Commons server infrastructure proposal
Date Tue, 13 Apr 2004 16:54:46 GMT
Just for the record, I think this is a great idea. I've been mulling over
something like this for a while. There were/are a couple of Commons projects
that almost but not quite fitted what I was looking for in this regard. I
would be glad to pitch in if enough people are interested to make this a

-----Original Message-----
From: Dain Sundstrom []
Sent: 12 April 2004 22:11
To: Jakarta Commons Developers List
Subject: Re: Commons server infrastructure proposal

On Apr 12, 2004, at 3:43 PM, Mladen Turk wrote:

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

No, but it is isolated and will be published as a standalone jar.

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

There is already a clustering project that is (or will be shortly)
using this code. As for a reverse proxy, maybe.  It would depend on
having an http protocol implementation, which we don't, but I do expect
to have people create an ejb reverse proxy server (think of a web load
balancer, but dealing with ejb requests instead).

> So, I'm not saying that there isn't a lot of code and most importantly
> the
> knowledge around, but you must agree that there is some redundancy
> among
> them. The trick is to find them, and hopefully they will be used if
> found
> adequate. I'm not saying that I found the holy grail that could both
> fit
> geronimo tomcat and avalon, or that it'll ever gonna be used in any of
> them,
> but IMHO that's the case with any commons project.

IMHO that is the problem I have with most commons projects.  They tend
to be generalized with out any specific use case, so the bloat.

> Also take a look at a simple things like a uri or cookie parsing.
> httpclient, tomcat, geronimo and others has it's own implementations
> although they are all dealing with the same RFC.

We use JDK 1.4 uri parsing and we don't deal with cookie parsing, as
http is provided by Jetty (and yes eventually tomcat).

> If you don't build a
> commons for such a things, each new project will have to make it's own
> implementation.

That is a good argument, but in geronimo we tend to avoid stuff from
jakarta commons as the modules tend to be highly coupled, so if I only
want one jar I end up getting 11 mbs of jars.  Now don't get me wrong,
I like common libraries, but they need to be highly decoupled, tight
and address truly common complex problems (if something is trivial or
not common, I'll just copy the code in).


To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message