Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
From: "Reinhard Poetz" <reinhard@apache.org>
To: <dev@cocoon.apache.org>
Subject: RE: Renaming Rhino Packages
Date: Thu, 19 Feb 2004 10:36:08 +0100
Message-ID: <003201c3f6cb$ce180320$1e01a8c0@WRPO>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
In-Reply-To: 
 <33304.10.0.0.5.1077156918.squirrel@ags01.agsoftware.dnsalias.com>
Importance: Normal


From: Antonio Gallardo

> Reinhard Poetz dijo:
> >
> > From: Christopher Oliver
> >
> >> What do you think of renaming the Rhino packages in the 
> cocoondev.org 
> >> version of Rhino used by Cocoon? It appears both Weblogic and 
> >> Websphere ship their own versions of Rhino that are exposed to the 
> >> class loader used by Cocoon. This prevents using flowscript 
> >> "out-of-the-box" or at all with these containers. Although 
> this is a 
> >> brute force approach it seems straightforward and foolproof to 
> >> implement. In contrast, attempting to implement some form of class 
> >> loader isolation seems difficult and error prone given the 
> lack of a 
> >> proper architecture to support it in Rhino, Cocoon, and in 
> Weblogic 
> >> and Websphere.
> >>
> >> Your thoughts?
> >
> > I've proposed this some time ago so +1 from me. From a 
> technical POV 
> > it would make sense to move the sources into the Cocoon CVS 
> but IIRC 
> > the board wouldn't be happy with this step.
> 
> I don't like this idea because of the forking we will 
> encourage. I think the best approach is to try to integrate 
> the continuations in mozilla.

Indeed, but it is *a lot* of work that has to be done and IIU Chris
correctly many things in Rhino have changed which makes the integration
not easier. Additionally our community consists mainly of experts in the
area of web publishing or web applications and not of people who are
familiar with interpreters - maybe I'm wrong here, but this is my
impression.

Moreover this doesn't help with the classloading issues because
commercial containers don't upgrade their libraries as often as we do.
Also many companies that use those containers don't use the latest
versions because this means a high load of work. In short, if we use the
mozilla package names the classloading issues will remain for years.

> BTW, how many classes are there? Maybe we can divide the work 
> and that way it could be easier. If we will do this, would be 
> fine to talk with mozilla people about this.

--
Reinhard