Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
  s=s1024; d=yahoo.com;
  h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding;
  b=pDTklnoRJ7xNlmgiHtFlT8Bpo7K3eo1mRdfYNqy1AqoXJSy0Mk1tmn1rvuDGEfGIC4BZdNlK9DTeWEKiSzfNtZvRuwYj+nJ3Kd4GeNJ+fitUBIXfkI0kkwftEMm+gt8UBrxoUSf8HO7peSrrp10RWs+Asbwb44UeuM85E081Iag=
  ;
Message-ID: <20050918181056.15730.qmail@web54413.mail.yahoo.com>
Date: Sun, 18 Sep 2005 11:10:56 -0700 (PDT)
From: David Jencks <david_jencks@yahoo.com>
Subject: Re: Multi-parent classloaders
To: dev@geronimo.apache.org
In-Reply-To: <74e15baa050917210133c8810c@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit


--- Aaron Mulder <ammulder@alumni.princeton.edu>
wrote:

>     So with the new multi-parent class loader
> support, what's the
> difference between parentId, import, include, and
> dependency?

parentId and import both relate to other
configurations.  A list consisting of parentId
followed  by any imports is constructed and used as
the parent classloaders.  The first element of this
list is used to get the domain and server for the
object names in the configuration.  For a
configuration without any parentId or imports, you
must specify the domain and server explicitly. 
parentId is theoretically unnecessary but I suggest
retaining it for backward compatibility, ease of use
when only one parent is needed, and clarity of
determining which parent configuration determines the
domain and server object name components.


Include and dependency both relate to items in the
repository and add them to the URL[] of the current
configurations classloader.  dependency elements use
the items in place in  the repo, whereas include
elements result in the item being copied into the
configuration itself.  I'm not sure include is tested
enough to be reliable.

thanks
david jencks