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).


-dain


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to