> From: Daniel Rall [mailto:[EMAIL PROTECTED]]
>
>
> Jose Alberto Fernandez <[EMAIL PROTECTED]> writes:
>
> > > From: Geir Magnusson Jr. [mailto:[EMAIL PROTECTED]]
> > > Yes and no. One thing to consider is that there are
> other resource
> > > collisions that one has to manage in a large shop :
> > > libraries, packages,
> > > templates, whatever. VMs would be another. And conflicts
> > > don't happen
> > > silently : you can lock out the replacement of a VM if it
> is already
> > > defined. This also produces log output, so it's not much
> of a mystery
> > > if you watch your log.
> > >
> >
> > I do not buy this argument. In Java, libraries, packages, V
> templates
> > they all live in a hierarchical namespace (either defined by the
> > hierarchical file system structure, or the namespaces defined by
> > Java packages). To just say that you can look in the log
> file for errors
> > is just asking people to dealt with the problem in the
> worst time possible,
> > once the template in on a production environment.
>
> WOW! Do fill us in on how you successfully skip development
> and testing...
>
As Gier notice with the sentence I had just after this one. The issue
is not on testing individual applications. Which I presume will happen and
everything will be fine. The problem will occur when you install
this application on the same environment as others (that have also been
tested by themselves). Because of the global macros, not the two apps
may interact in unforseable manners and the problems show up.
Two different organizations within an enterprise may have bought or develop
their own thing, and not until they are both installed in the common
production server, that we will discover these problems.
The point is that we need to be able to provide some compositional
guarantees. And the first tenant of that is component isolation.
Component should only interact thru well defined APIs.
Jose Alberto
