commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Craig McClanahan <craig...@gmail.com>
Subject Re: [digester] dependencies for 1.6 release
Date Sun, 25 Jul 2004 16:37:50 GMT
On Sun, 25 Jul 2004 17:07:53 +1200, Simon Kitching
<simon@ecnetwork.co.nz> wrote:
> 
> I've thought some more about this.
> 
> Why exactly would a container expose Digester to the "containees"?
> 
> If a container wants to use Digester to parse its configuration files,
> then that is an internal matter for that container, and the Digester lib
> (plus all that it depends upon) should be loaded by a container-specific
> classloader that isn't exposed to the containees.
> 

That's exactly why Tomcat supports a server/lib directory that is
visible to the internals of the container, but *not* visible to
applications.  And that's where Tomcat puts its internal copy of
Digester by default.

> And with that setup, we don't need to be *overly* concerned about binary
> compatibility. The container uses version X of Digester, and each
> containee uses their own version.
> 
> Surely exposing a library that is only used for internal purposes within
> a container is poor design - even worse than exposing private methods
> and variables.
> 

Sounds sub-optimal to me.

> Do you know of any containers that actually do use Digester and make it
> visible to containee code?

Good question.

But, regardless of the answer, wasn't the original question in this
thread related to whether a new Digester release should specify a new
BeansUtil release as a dependency (and thus allow it to not require
commons-collections)?  I still think that's a good idea, and have lost
track of the current thinking on that topic.

> 
> 
> 
> Regards,
> 
> Simon
> 

Craig

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