Return-Path: 
 <dev-return-13239-apmail-geronimo-dev-archive=geronimo.apache.org@geronimo.apache.org>
Delivered-To: apmail-geronimo-dev-archive@www.apache.org
Received: (qmail 52616 invoked from network); 26 Jun 2005 16:50:09 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 26 Jun 2005 16:50:09 -0000
Received: (qmail 63430 invoked by uid 500); 26 Jun 2005 16:50:04 -0000
Delivered-To: apmail-geronimo-dev-archive@geronimo.apache.org
Received: (qmail 63384 invoked by uid 500); 26 Jun 2005 16:50:03 -0000
Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:dev-help@geronimo.apache.org>
list-unsubscribe: <mailto:dev-unsubscribe@geronimo.apache.org>
List-Post: <mailto:dev@geronimo.apache.org>
Reply-To: dev@geronimo.apache.org
List-Id: <dev.geronimo.apache.org>
Delivered-To: mailing list dev@geronimo.apache.org
Delivered-To: moderator for dev@geronimo.apache.org
Received: (qmail 97497 invoked by uid 99); 26 Jun 2005 15:27:24 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <42BEC95F.1000208@senselogic.se>
Date: Sun, 26 Jun 2005 17:27:27 +0200
From: =?ISO-8859-1?Q?Rickard_=D6berg?= <rickard.oberg@senselogic.se>
User-Agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: dev@picocontainer.codehaus.org
CC: dev@geronimo.apache.org
Subject: Re: [picocontainer-dev] Re: ClassLoader Architecture
References: <d8ms7e$is6$1@sea.gmane.org>
 <8C051B4D-95E3-4876-8941-1D9855BB8003@iq80.com>
 <6E8E8A09-5D16-4A5E-999A-52AD75888F7D@apache.org>
In-Reply-To: <6E8E8A09-5D16-4A5E-999A-52AD75888F7D@apache.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked by ClamAV on apache.org
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

Paul Hammant wrote:
> Comp A and B (in separate classloaders) can see Common-API, which can 
> see the classloader that contains PicoContainer who's parent is the 
> classes in rt.jar
<snip>

One thing that I have whined about before, and I'm not sure whether it's 
been fixed yet, is that a component A needs to be able to have an 
internal structure (component!=1 object) and it needs to be able to 
expose API implementations to other components without having to expose 
its own internal structure. In the discussions so far I have not seen 
mention of this problem (but maybe I have simply missed it).

I have my own solution for fixing this, but I am wondering if a more 
standard solution to this is available? (now or later) My own solution 
is more of a best-practice use of Pico rather than an extension, and if 
anyone is interested I can describe it in more detail.

It really is a big big big issue once you get either loads of components 
or large components. We have both cases in our system right now.

/Rickard