commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dain Sundstrom <>
Subject Re: Commons server infrastructure proposal
Date Mon, 12 Apr 2004 21:10:47 GMT
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:

View raw message