Mailing-List: contact dev-help@geronimo.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@geronimo.apache.org
Received-SPF: pass (nike.apache.org: domain of rickmcg@gmail.com designates
 209.85.160.182 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:reply-to:user-agent:mime-version:to:subject
         :references:in-reply-to:content-type:content-transfer-encoding;
        b=GGxlV46WZjMwZeP4YJVEkJZoxsKtMJfTNCYyYKUVZN5pUfQ9k7N9oOv/6zRLgGJ5Tp
         9IaOg6aFntRpxcSV1AoOt4x5Y/ph4RPuPPnZc8e7ap0gdyhzgiH1secZd8Qcfck772tP
         ZdAcAV97kcKDulVbjD+ZpZmlEiqy1otif90Pw=
Message-ID: <4C48741F.6020404@gmail.com>
Date: Thu, 22 Jul 2010 12:38:55 -0400
From: Rick McGuire <rickmcg@gmail.com>
Reply-To: rickmcg@gmail.com
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: Geronimo Dev <dev@geronimo.apache.org>
Subject: Re: Possible split package issue
References: <CB690B3E-6D3D-4E50-B174-C36DE1DEDF0A@yahoo.com>
 <4C45E20B.3090907@gmail.com>
In-Reply-To: <4C45E20B.3090907@gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 7/20/2010 1:51 PM, Rick McGuire wrote:
> On 7/6/2010 3:38 AM, David Jencks wrote:
>> In the last couple days I've started seeing major problems running 
>> the tck here.  Generally tests subclass com.sun.ts.lib.harness.EETest 
>> which is not included in tsharness.jar, instead it's in each test 
>> ear.   However there are plenty of other classes in 
>> com.sun.ts.lib.harness that are in tsharness.jar and are needed for 
>> tests to work.
>>
>> I've seen this after upgrading the cts bundles to the latest tck, but 
>> don't see any change in them  to explain this new behavior.
>>
>> I don't see why it wouldn't have been a problem previously, but it 
>> just started for me.
>>
>> Does anyone else see this?  Anyone have an idea what might be causing 
>> this problem now?
>>
>> I'm wondering if we could create a tsharness bundle that does include 
>> all the classes in the packages it supplies.
>>
>> thanks
>> david jencks
>>
>>
> I was able to create a very simple test to demonstrate this problem 
> and opened a Jira against Felix.  The should be able to recreate this 
> fairly easily now, so hopefully we'll see a fix in 3.1.0.  The Jira is 
> here:
>
> https://issues.apache.org/jira/browse/FELIX-2479

Richard Hall's come up with a fix for this, so I'll bump the felix 
version to 3.1.0-SNAPSHOT.  I'm not sure when this will be deployed, so 
we should keep the TCK runs using equinox for now.

Rick

>
> and includes a full maven project for running the tests.
>
> For the curious, this was sort of an interesting problem.  I created a 
> series of jars/bundles that recreated the class/package structure of 
> the test case, then used the following method calls:
>
>         Class cls = 
> bundle1.loadClass("org.apache.geronimo.embedded.TestClass");
>         // this will force the fields classes to be resolved.
>         cls.getDeclaredFields();
>
> This worked without error on all framework versions I ran it against.  
> However, if I changed this to:
>
>        // if this line is commented out, then the second loadClass() 
> call will succeed. If
>         // this load occurs first, then a NoClassDefFound error 
> results on the load for TestClass.
>         Class cls1 = 
> bundle1.loadClass("org.apache.geronimo.harness.EETestDummy");
>
>         Class cls = 
> bundle1.loadClass("org.apache.geronimo.embedded.TestClass");
>         // this will force the fields classes to be resolved.
>         cls.getDeclaredFields();
>
> The getDeclaredFields() call gave the same NoClassDefFound error as 
> the TCK.  The class resolution result has been altered by first 
> loading a class that gets pulled in from the Require-Bundle reference.
>
> Rick