Return-Path: Delivered-To: apmail-cocoon-dev-archive@www.apache.org Received: (qmail 49218 invoked from network); 15 Aug 2008 14:04:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Aug 2008 14:04:22 -0000 Received: (qmail 62573 invoked by uid 500); 15 Aug 2008 14:04:20 -0000 Delivered-To: apmail-cocoon-dev-archive@cocoon.apache.org Received: (qmail 62486 invoked by uid 500); 15 Aug 2008 14:04:20 -0000 Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: Reply-To: dev@cocoon.apache.org List-Id: Delivered-To: mailing list dev@cocoon.apache.org Received: (qmail 62475 invoked by uid 99); 15 Aug 2008 14:04:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Aug 2008 07:04:20 -0700 X-ASF-Spam-Status: No, hits=-1.0 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of grek@tuffmail.com designates 216.86.168.178 as permitted sender) Received: from [216.86.168.178] (HELO mxout-03.mxes.net) (216.86.168.178) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 15 Aug 2008 14:03:23 +0000 Received: from [192.168.1.232] (unknown [217.116.183.178]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTP id 110A723E49E for ; Fri, 15 Aug 2008 10:02:49 -0400 (EDT) Message-ID: <48A58C71.5030207@tuffmail.com> Date: Fri, 15 Aug 2008 16:02:25 +0200 From: Grzegorz Kossakowski User-Agent: Thunderbird 2.0.0.12 (X11/20071114) MIME-Version: 1.0 To: Cocoon's dev mailing list Subject: RCL plug-in and different classloaders issues Content-Type: text/plain; charset=ISO-8859-2; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org Hi, I'm just playing around with Cocoon's RCL plug-in in some more complicated scenario and stumbled upon a problem when the same class is loaded by two different classloaders. In brief, following steps are performed: 1. Class from my block is loaded using ResourceStoreClassLoader. Let's call this class MAIN. 2. This class accesses some static method of another class loaded by ResourceStoreClassLoader (because this class comes from my block as well) and sets some value on static field. Let's call this class STATIC 3. Then another class (3RDPARTY) is being loaded which is not part of my block, it's from third-party jar. It's loaded by parent classloader to ResourceStoreClassLoader. As part of configuration of this class I pass a name of class which is some kind of extension point and is implemented by class coming from my block; let's call this class EXTENSION. 4. 3RDPARTY creates new instance of EXTENSION class (and this class is again not loaded by ResourceStoreClassLoader but by parent), but in EXTENSION class one tries to access field set in STATIC. 5. While EXTENSION tries to access STATIC, STATIC is being loaded again, using parent classloader. The value in STATIC is gone, obviously. So the basic problem is that, this STATIC class is loaded by two different classloaders. I'm wondering if there is any kind of general solution to such problems. The only one I can think of is to enforce loading of 3RDPARTY class by ResourceStoreClassLoader so everything stays within one classloader and even reflection tricks are not dangerous. However, that would mean that one needs to modify commons-jci project. Is there any simpler method? -- Grzegorz Kossakowski