Mailing-List: contact dev-help@river.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@river.apache.org
Received-SPF: pass (athena.apache.org: domain of pats@acm.org designates
 209.86.89.62 as permitted sender)
Message-ID: <4E0C0419.9070508@acm.org>
Date: Wed, 29 Jun 2011 22:05:29 -0700
From: Patricia Shanahan <pats@acm.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US;
 rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: dev@river.apache.org
Subject: Re: Release 2.2 comments
References: <4E094D72.9050202@acm.org>
	<1309245510.2159.5.camel@Nokia-N900-51-1>	<4E0A3C53.4090106@acm.org>
	<1309315283.2956.5.camel@Nokia-N900-51-1>
	<BANLkTim50wmBePsB_7jg9z44rcDndrypYw@mail.gmail.com>
	<4E0B9166.4040505@acm.org>
 <BANLkTikP65x7AZvDgR-ttCUZqGzTuns_6w@mail.gmail.com>
 <4E0BF409.9040200@acm.org>
In-Reply-To: <4E0BF409.9040200@acm.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I'm signing off for the night. Sill one failure.

Patricia


On 6/29/2011 8:56 PM, Patricia Shanahan wrote:
> I got a QA test failure,
> com/sun/jini/test/impl/reggie/MultihomedClientTest.td. The failure is
> due to the missing
> com.sun.jini.test.impl.reggie.NameServiceDescriptorImpl class.
>
> That leaves us with the following options:
>
> 1. Insist on Java 5 compilation, and change the code to match the Java 5
> version of the interface.
>
> 2. Delete the files, and drop one or more tests which are presumably
> testing configurations that nothing else tests.
>
> I'm inclined towards the first answer, but not strongly.
>
> Patricia
>
>
> On 6/29/2011 2:17 PM, Tom Hobbs wrote:
>> Well that's something. A good something! Fingers cross on the QA
>> tests. I'm just about to sign off now, but please check the deletions
>> into the trunk if/when you're happy with them and I'll create some new
>> RCs.
>>
>> If only all fixes were as simple.
>>
>>
>> On Wed, Jun 29, 2011 at 9:56 PM, Patricia Shanahan<pats@acm.org> wrote:
>>> I've done a clean build with the classes in question deleted. It got a
>>> "BUILD SUCCESSFUL". I'll start the QA tests that way, but I suggest
>>> making
>>> that change. (I'm not checking in anything to the trunk right now, to
>>> avoid
>>> risk of tripping up your efforts).
>>>
>>> Patricia
>>>
>>> On 6/29/2011 1:07 PM, Tom Hobbs wrote:
>>>>
>>>> I've just done a quick search for uses of NameServiceImpl and the only
>>>> thing I could find was in NameServiceDescriptorImpl. And I couldn't
>>>> find any references for that.
>>>>
>>>> Given that the package is "com.sun.jini.test.impl.reggie" for both of
>>>> these classes, can I assume that they're for some test only? Does
>>>> anyone know what they're for? Can we just remove them? (I love
>>>> deleting code!)
>>>>
>>>> I'm sure you guys are aware of the problem, but for anyone new to the
>>>> party; NameServiceImpl implements NameService which is an *internal*
>>>> Sun class, which by rights we shouldn't really be using anyway. The
>>>> return type of a the lookupAllHostAddr method differs from Java 5 to
>>>> 6, so we're unable to build a release that satisfies both Java
>>>> versions.
>>>>
>>>> If we can't get around this, it looks like we might be stuck at Java 5
>>>> and only 5 until we come up with something clever.
>>>>
>>>> This is disappointing because I was hoping to build some new release
>>>> candidates tonight...
>>>>
>>>> Thoughts?
>>>>
>>>> Tom
>>>>
>>>> On Wed, Jun 29, 2011 at 3:41 AM, Peter<jini@zeus.net.au> wrote:
>>>>>
>>>>> We have a number of uses of internal sun impl classes, I'd agree they
>>>>> should all be replaced so we can expand beyond the sun
>>>>> implementation. Is
>>>>> there a related jira?
>>>>>
>>>>> If you can see a simple fix eliminating the sun dependency, go for it,
>>>>> otherwise I think just fix it enough to get our release out.
>>>>>
>>>>> I hadn't given it further consideration last time I looked.
>>>>>
>>>>> Cheers,
>>>>>
>>>>> Peter.
>>>>>
>>>>> ----- Original message -----
>>>>>>
>>>>>> I think the problem may go deeper.
>>>>>> sun.net.spi.nameservice.NameService
>>>>>> is a sun.net interface that can change from version to version. Is it
>>>>>> essential that we have our own implementation?
>>>>>>
>>>>>> Patricia
>>>>>>
>>>>>>
>>>>>> On 6/28/2011 12:18 AM, Peter wrote:
>>>>>>>
>>>>>>> Oops, I fixed that but didn't commit, sorry Not near my dev box, but
>>>>>>> the fix
>>>>>>> is relatively simple, get byte array from each InetAddress, and
>>>>>>> return
>>>>>>> byte[][] instead, can someone fix it?
>>>>>>>
>>>>>>> ----- Original message -----
>>>>>>>>
>>>>>>>> I downloaded the source, and tried a naive build on Windows XP,
>>>>>>>> Cygwin.
>>>>>>>> I put a JDK 1.5 bin directory at the start of my path, and ran "ant
>>>>>>>> all.build". It failed with the following errors:
>>>>>>>>
>>>>>>>> compile:
>>>>>>>> [javac] Compiling 1993 source files to
>>>>>>>> C:\Documents and
>>>>>>>> Settings\Administrator\My
>>>>>>>>
>>>>>>>> Documents\River_2.2\apache-river-2.2.0-src\apache-river-2.2.0\qa\build\classes
>>>>>>>>
>>>>>>>> [javac] C:/Documents and
>>>>>>>> Settings/Administrator/My
>>>>>>>>
>>>>>>>> Documents/River_2.2/apache-river-2.2.0-src/apache-river-2.2.0/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java:29:
>>>>>>>>
>>>>>>>> com.sun.jini.test.impl.reggie.NameServiceImpl is not abstract
>>>>>>>> and does
>>>>>>>> not override abstract method lookupAllHostAddr(java.lang.String) in
>>>>>>>> sun.net.spi.nameservice.NameService
>>>>>>>> [javac] public class NameServiceImpl implements
>>>>>>>> NameService {
>>>>>>>> [javac] ^
>>>>>>>> [javac] C:/Documents and
>>>>>>>> Settings/Administrator/My
>>>>>>>>
>>>>>>>> Documents/River_2.2/apache-river-2.2.0-src/apache-river-2.2.0/qa/src/com/sun/jini/test/impl/reggie/NameServiceImpl.java:42:
>>>>>>>>
>>>>>>>> lookupAllHostAddr(java.lang.String) in
>>>>>>>> com.sun.jini.test.impl.reggie.NameServiceImpl cannot implement
>>>>>>>> lookupAllHostAddr(java.lang.String) in
>>>>>>>> sun.net.spi.nameservice.NameService; attempting to use incompatible
>>>>>>>> return type
>>>>>>>> [javac] found : java.net.InetAddress[]
>>>>>>>> [javac] required: byte[][]
>>>>>>>> [javac] public InetAddress[]
>>>>>>>> lookupAllHostAddr(String host)
>>>>>>>> [javac]
>>>>>>>> ^
>>>>>>>> [javac] Note: Some input files use or override a
>>>>>>>> deprecated API.
>>>>>>>> [javac] Note: Recompile with -Xlint:deprecation
>>>>>>>> for details.
>>>>>>>> [javac] Note: Some input files use unchecked or
>>>>>>>> unsafe operations.
>>>>>>>> [javac] Note: Recompile with -Xlint:unchecked
>>>>>>>> for details.
>>>>>>>> [javac] 2 errors
>>>>>>>>
>>>>>>>> (I'm not worried about the deprecated APIs, just the compile
>>>>>>>> failures.)
>>>>>>>>
>>>>>>>> I next tried to find instructions. I looked at
>>>>>>>> src-doc/static/build.html. It says "The bin directory of the
>>>>>>>> Java(TM)
>>>>>>>> 2
>>>>>>>> SDK, Standard Edition, v 1.4 (or later) must be in your executable
>>>>>>>> search path."
>>>>>>>>
>>>>>>>> I believe we now need 1.5 or later.
>>>>>>>>
>>>>>>>> Patricia
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>
>>>
>>>
>>
>
>