Return-Path: Delivered-To: apmail-incubator-geronimo-dev-archive@www.apache.org Received: (qmail 29261 invoked from network); 2 Oct 2003 15:19:48 -0000 Received: from daedalus.apache.org (HELO mail.apache.org) (208.185.179.12) by minotaur-2.apache.org with SMTP; 2 Oct 2003 15:19:48 -0000 Received: (qmail 79459 invoked by uid 500); 2 Oct 2003 15:19:34 -0000 Delivered-To: apmail-incubator-geronimo-dev-archive@incubator.apache.org Received: (qmail 79406 invoked by uid 500); 2 Oct 2003 15:19:33 -0000 Mailing-List: contact geronimo-dev-help@incubator.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: list-post: Reply-To: geronimo-dev@incubator.apache.org Delivered-To: mailing list geronimo-dev@incubator.apache.org Received: (qmail 79393 invoked from network); 2 Oct 2003 15:19:33 -0000 Received: from unknown (HELO hotmail.com) (207.68.163.22) by daedalus.apache.org with SMTP; 2 Oct 2003 15:19:33 -0000 Received: from mail pickup service by hotmail.com with Microsoft SMTPSVC; Thu, 2 Oct 2003 08:19:36 -0700 Received: from 144.139.161.5 by sea1fd.sea1.hotmail.msn.com with HTTP; Thu, 02 Oct 2003 15:19:35 GMT X-Originating-IP: [144.139.161.5] X-Originating-Email: [gianny_damour@hotmail.com] From: "gianny DAMOUR" To: geronimo-dev@incubator.apache.org Bcc: Subject: ClassSpace - parent CL Date: Thu, 02 Oct 2003 17:19:35 +0200 Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1; format=flowed Message-ID: X-OriginalArrivalTime: 02 Oct 2003 15:19:36.0432 (UTC) FILETIME=[97121F00:01C388F8] X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: minotaur-2.apache.org 1.6.2 0/1000/N Hello, I was just trying to solve the problem of Matt Kurjanowicz, which seems to be a weird CL problem and during my investigations I have discovered three points: - the Eclipse set-up I use to simulate a running server is simply flawed (grrr...); - the Resource Adapter Deployer I have submitted does not work, when deployed within a running instance launched via maven run:main (grrrrr...); and - the parent CL of a ClassSpace is the TCCL if defined or the CL of the ClassSpace class. Regarding this last point, I really find it weird for the following reason: If one creates a ClassSpace for a deployment unit, say a resource adapter, and if I want to define a specific parent for such a ClassSpace, I will need to set the TCCL. However, because this TCCL is outside our control between the moment this TCCL is set and the actual creation of my ClassSpace (other deployment planners could wish to set their own TCCL), it is impossible to know for sure which CL will be the parent of the deployment unit ClassSpace. So, I would like to know if one can add to ClassSpaceMetadata an attribute referencing the name of the parent ClassSpace of the ClassSpace to be created via this ClassSpaceMetadata. This way, a deployment unit could explicitely defines its direct CL and the parent of this CL. I have applied this fix and it solved my resource adapter deployer problem. More accurately, the parent CL of the ClassSpace containing the resource adapter archives is the geronimo.system:role=ClassSpace,name=System ClassSpace (defined during the boot). Gianny _________________________________________________________________ MSN Search, le moteur de recherche qui pense comme vous ! http://search.msn.fr/