river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Firmstone <j...@zeus.net.au>
Subject Re: Dependency on Sun internal API's
Date Thu, 22 May 2014 12:08:50 GMT
The build will be ready for release when test failures are low, once we 
reach that milestone, we can perform rapid iterative releases.

The recent fix to JERI appears to have increased stability, at least 
locally, although this isn't showing through on Jenkins yet.

You could say I took some time out, to do something easy, at least 
compared to the hair pulling concurrency bugs and race conditions I've 
been focused on.

Cheers,

Peter.

On 22/05/2014 9:31 PM, Bryan Thompson wrote:
> This is all good, but I would personally be interested in getting to a
> release based on the QA branch with less remaining development.  I would
> suggest rapid iterations for releases with incremental change until a QA
> branch based release is stable.
>
>
> On Thu, May 22, 2014 at 7:24 AM, Peter Firmstone<jini@zeus.net.au>  wrote:
>
>>     [java] -----------------------------------------
>>       [java] GENERAL HARNESS CONFIGURATION INFORMATION:
>>       [java]
>>       [java]    Date started:
>>       [java]       Thu May 22 11:23:39 UTC 2014
>>       [java]    Installation directory of the JSK:
>>       [java]       com.sun.jini.jsk.home=/home/hudson/jenkins-slave/
>> workspace/river-qa-refactor-j9/trunk
>>       [java]    Installation directory of the harness:
>>       [java]       com.sun.jini.qa.home=/home/hudson/jenkins-slave/
>> workspace/river-qa-refactor-j9/trunk/qa
>>       [java]    Categories being tested:
>>       [java]       categories=id loader policyprovider locatordiscovery
>> activation config discoverymanager joinmanager url iiop jrmp reliability
>> thread renewalmanager constraint export lookupdiscovery servicediscovery io
>> security lookupservice renewalservice eventmailbox jeri start
>> discoveryservice discoveryproviders javaspace txnmanager
>>       [java] -----------------------------------------
>>       [java] ENVIRONMENT PROPERTIES:
>>       [java]
>>       [java]    JVM information:
>>       [java]       IBM J9 VM, 2.4, 64 bit VM mode
>>       [java]       IBM Corporation
>>       [java]    OS information:
>>       [java]       Linux, 3.2.0-51-generic, amd64
>>       [java]
>>       [java] -----------------------------------------
>>       [java] STARTING TO RUN THE TESTS
>>       [java]
>>       [java]
>>
>>
>>
>>
>> On 22/05/2014 9:10 PM, Peter Firmstone wrote:
>>
>>> Jini has a small but loyal user base in financial services.
>>>
>>> Looks like River is building on J9, real time java and IIOP seems to be
>>> working too.
>>>
>>> I'm not expecting many tests to pass at this stage, since many
>>> permissions will be different, at least it's all compilling now.
>>>
>>> Cheers,
>>>
>>> Peter.
>>>
>>> On 22/05/2014 6:53 PM, Dawid Loubser wrote:
>>>
>>>> Wow Peter, that sounds great! I imagine that a significant percentage of
>>>> the (rather small) River user base might operate in environments requiring
>>>> some of these other Java VMs with particular qualities around real-time
>>>> processing, etc.
>>>>
>>>> Dawid
>>>>
>>>>
>>>> On 22/05/2014 06:29, Peter Firmstone wrote:
>>>>
>>>>> Presently we are prevented from compilling and running on J9, JRockit
>>>>> or other Java VM's.
>>>>>
>>>>> I've been able to modify Phoenix to use reflection at runtime to call
>>>>> Sun private implementations, meaning that Phoenix is strictly a Sun JVM
>>>>> only component, but would no longer prevent compilling and testing on
other
>>>>> architectures.
>>>>>
>>>>> There is one test that, com.sun.jini.test.impl.reggie.MultiHomedClientTest
>>>>> that uses the following internal sun API:
>>>>>
>>>>> sun.net.spi.nameservice.NameService;
>>>>> sun.net.spi.nameservice.NameServiceDescriptor;
>>>>>
>>>>> If I was to change this test and associated classes to .txt extensions,
>>>>> we could run these manually on Sun's JVM, while allowing River to build
on
>>>>> other architectures.
>>>>>
>>>>> Regards,
>>>>>
>>>>> Peter.
>>>>>
>>>>


Mime
View raw message