You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Peter Firmstone <ji...@zeus.net.au> on 2014/05/22 06:29:22 UTC
Dependency on Sun internal API's
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.
Re: Dependency on Sun internal API's [Duplicate Apology]
Posted by Dawid Loubser <da...@travellinck.com>.
Apologies for the partial duplicate message, silly mail client on slow
internet connection...
On 22/05/2014 10:51, Dawid Loubser wrote:
> Wow Peter, that sounds great! One would have to think one of the
> target (niche) environments of River is that requiring some of these
> other more interesting Java V/Ms./
>
> 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.
>
Re: Dependency on Sun internal API's
Posted by Dawid Loubser <da...@travellinck.com>.
Wow Peter, that sounds great! One would have to think one of the target
(niche) environments of River is that requiring some of these other more
interesting Java V/Ms./
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.
Re: Dependency on Sun internal API's
Posted by Peter Firmstone <ji...@zeus.net.au>.
Well the news is someone aborted the build, this is quite common with
River builds, I don't know whether it's because people think the build
is hung, because it goes for so long or they need to shutdown a node for
maintenance, who knows.
If people can perform test runs on their own hardware, it would
definitely helpful. Jenkins seems more suited to short test runs.
Regards,
Peter.
On 22/05/2014 9:24 PM, Peter Firmstone 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.
>>>
>>
>
Re: Dependency on Sun internal API's
Posted by Dennis Reedy <de...@gmail.com>.
Sent from my iPhone
>>
>> The original concern raised, was significant changes between the 2.2 branch and trunk. Qa_refactor is branched off trunk although trunk has a couple of commits after the branch point, so it'd probably be easier to apply those changes to qa_refactor, rather than the other way around.
>>
>> However I suspect what you meant was to apply the changes in qa_refactor to the 2.2 branch?
>
> I thought the plan was to merge qa_refactor over to trunk, and leave the 2.2. branch as-is.
This makes the most amount of sense to me. Let's leave the 2.2 branch as is, merge qa_refactor to trunk.
Regards
Dennis
Re: Dependency on Sun internal API's
Posted by Peter Firmstone <ji...@zeus.net.au>.
On 25/05/2014 11:07 AM, Greg Trasuk wrote:
> On May 24, 2014, at 8:42 PM, Peter Firmstone<ji...@zeus.net.au> wrote:
>
>> On 23/05/2014 9:53 PM, Simon IJskes - QCG wrote:
>>> Yes, if possible we could sync up the trunk, by visual diffing trunk and qa_refactor, merging patches into trunk, commiting to trunk and release in small controlled steps. Netbeans is capable of doing that.
>>>
>>> Gr. Simon
>>>
>>>
>> The original concern raised, was significant changes between the 2.2 branch and trunk. Qa_refactor is branched off trunk although trunk has a couple of commits after the branch point, so it'd probably be easier to apply those changes to qa_refactor, rather than the other way around.
>>
>> However I suspect what you meant was to apply the changes in qa_refactor to the 2.2 branch?
>>
> I thought the plan was to merge qa_refactor over to trunk, and leave the 2.2. branch as-is.
>
> Greg.
>
Yes I believe it is, but we already have an svn commit history with
comments that explain changes from a recent trunk snapshot, we'd loose
those comments, since trunk has been relatively static, it would be
easier to merge trunk into qa_refactor and replace trunk.
My understanding is that we'd release qa_refactor and make incremental
changes to it in multiple releases until it stabilised.
Trunk was branched because it became unstable.
Although qa refactor is quite stable, looking at Jenkins you could be
forgiven for thinking otherwise, it's worth remembering the current
snapshot hasn't run on Jenkins. I have enabled a test that failed (as
documented) during the Jini 2.1 release, that is now stable.
ServiceDiscoveryManager still has a race that presents occassionally,
but I don't think its a reason not to release.
IIOP isn't running on IBM J9, it hasn't had the opportunity for a full
test run, but results so far are better than expected.
For now I'm waiting for Jenkins to run the current snapshot on all
architectures, probably a couple of weeks wait for the outcome.
Regards,
Peter.
Re: Dependency on Sun internal API's
Posted by Greg Trasuk <tr...@stratuscom.com>.
On May 24, 2014, at 8:42 PM, Peter Firmstone <ji...@zeus.net.au> wrote:
> On 23/05/2014 9:53 PM, Simon IJskes - QCG wrote:
>>
>> Yes, if possible we could sync up the trunk, by visual diffing trunk and qa_refactor, merging patches into trunk, commiting to trunk and release in small controlled steps. Netbeans is capable of doing that.
>>
>> Gr. Simon
>>
>>
>
> The original concern raised, was significant changes between the 2.2 branch and trunk. Qa_refactor is branched off trunk although trunk has a couple of commits after the branch point, so it'd probably be easier to apply those changes to qa_refactor, rather than the other way around.
>
> However I suspect what you meant was to apply the changes in qa_refactor to the 2.2 branch?
>
I thought the plan was to merge qa_refactor over to trunk, and leave the 2.2. branch as-is.
Greg.
> Peter.
Re: Dependency on Sun internal API's
Posted by Peter Firmstone <ji...@zeus.net.au>.
On 23/05/2014 9:53 PM, Simon IJskes - QCG wrote:
>
> Yes, if possible we could sync up the trunk, by visual diffing trunk
> and qa_refactor, merging patches into trunk, commiting to trunk and
> release in small controlled steps. Netbeans is capable of doing that.
>
> Gr. Simon
>
>
The original concern raised, was significant changes between the 2.2
branch and trunk. Qa_refactor is branched off trunk although trunk has
a couple of commits after the branch point, so it'd probably be easier
to apply those changes to qa_refactor, rather than the other way around.
However I suspect what you meant was to apply the changes in qa_refactor
to the 2.2 branch?
Peter.
Re: Dependency on Sun internal API's
Posted by Simon IJskes - QCG <si...@qcg.nl>.
On 22-05-14 13:31, 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.
Yes, if possible we could sync up the trunk, by visual diffing trunk and
qa_refactor, merging patches into trunk, commiting to trunk and release
in small controlled steps. Netbeans is capable of doing that.
Gr. Simon
Re: Dependency on Sun internal API's
Posted by Bryan Thompson <br...@systap.com>.
Yes, very much. Bryan
> On May 22, 2014, at 8:19 AM, Dawid Loubser <da...@travellinck.com> wrote:
>
> Much-deserved easy tak, Peter!
> I hope many others on this list share my quiet appreciation for the
> massive work you are putting into the codebase.
>
> Dawid
>
>
>> On 22/05/2014 14:08, Peter Firmstone wrote:
>> 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<ji...@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.
>
>
Re: Dependency on Sun internal API's
Posted by Dawid Loubser <da...@travellinck.com>.
Much-deserved easy tak, Peter!
I hope many others on this list share my quiet appreciation for the
massive work you are putting into the codebase.
Dawid
On 22/05/2014 14:08, Peter Firmstone wrote:
> 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<ji...@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.
>>>>>>
>>>>>
>
Re: Dependency on Sun internal API's
Posted by tr...@stratuscom.com.
Greg Trasuk
Original Message
From: Peter
Sent: Thursday, May 22, 2014 4:47 PM
To: dev@river.apache.org
Reply To: dev@river.apache.org
Subject: Re: Dependency on Sun internal API's
Thanks Patricia, will do, much appreciated.
Peter.
----- Original message -----
> On 5/22/2014 5:08 AM, Peter Firmstone wrote:
> ...
> > 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.
> ...
>
> When you are ready to return to the concurrency bugs and race
> conditions, send me information on how to set up and run a failing test,
> and I'll work with you on it.
>
> Patricia
Re: Dependency on Sun internal API's
Posted by Peter <ji...@zeus.net.au>.
Thanks Patricia, will do, much appreciated.
Peter.
----- Original message -----
> On 5/22/2014 5:08 AM, Peter Firmstone wrote:
> ...
> > 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.
> ...
>
> When you are ready to return to the concurrency bugs and race
> conditions, send me information on how to set up and run a failing test,
> and I'll work with you on it.
>
> Patricia
Re: Dependency on Sun internal API's
Posted by Patricia Shanahan <pa...@acm.org>.
On 5/22/2014 5:08 AM, Peter Firmstone wrote:
...
> 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.
...
When you are ready to return to the concurrency bugs and race
conditions, send me information on how to set up and run a failing test,
and I'll work with you on it.
Patricia
Re: Dependency on Sun internal API's
Posted by Peter Firmstone <ji...@zeus.net.au>.
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<ji...@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.
>>>>>
>>>>
Re: Dependency on Sun internal API's
Posted by Bryan Thompson <br...@systap.com>.
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 <ji...@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.
>>>>
>>>
>>>
>>
>
Re: Dependency on Sun internal API's
Posted by Peter Firmstone <ji...@zeus.net.au>.
[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.
>>
>
Re: Dependency on Sun internal API's
Posted by Peter Firmstone <ji...@zeus.net.au>.
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.
>
Re: Dependency on Sun internal API's
Posted by Dawid Loubser <da...@travellinck.com>.
Wow Peter, that sounds great! I ima//gine 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.