On Sun, 25 Jul 2004 17:07:53 +1200, Simon Kitching <[EMAIL PROTECTED]> 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
