Re: Time to retire from Apache

[Patricia Shanahan]

> On Feb 23, 2021, at 15:51, Bryan Thompson  wrote:
> 
> 
> 
> At this point I know precisely nothing other than the fact that they have
> decided that someone violated the code of conduct.
>> 
>> 

What actually happened was a decision to remove an individual from a PMC. 

Much of the board’s normal activity is concerned with creating, monitoring, and 
terminating PMCs. The bylaws give the board the option of removing an 
individual from one. 

Re: Board feedback - Request discuss attic for River

[Patricia Shanahan]

The board tends to be more concerned about an active community than 
technical matters. We need to discuss whether there is a pool of 
potential contributors who are likely to become active.


On 5/20/2020 5:51 PM, Peter Firmstone wrote:

Hello River Folk,

I've received feedback from the Board this morning, they are requesting 
that we discuss the Attic for River.


Personally I think the project still has a lot of potential to pick up 
again once the modular build is complete, and it is a useful place to 
send patches and discuss changes.


A very important patch was sent in June last year by Shawn Ellis for 
Java 11.0.3 and later for services using SSL/TLS.


Another important change to the JERI protocol was discussed in September 
last year.


http://mail-archives.apache.org/mod_mbox/river-dev/201909.mbox/browser

What are your thoughts?

I don't think the board is asking that we send River to the attic, just 
that we discuss it.


Regards,

Peter.

Re: Draft Report River - May 2020

[Patricia Shanahan]

+1, and thanks for getting on to this early.

On 5/7/2020 12:31 AM, Peter Firmstone wrote:

Hello River Folk,

Please review the May report draft below.   With work starting to slow 
down, I should have some time to complete the modular build soon.


How are you being impacted by Covid-19?

Regards,

Peter Firmstone.

## Description:

  - Apache River provides a platform for dynamic discovery and lookup
     search of network services.  Services may be implemented in a number
     of languages, while clients are required to be jvm based (presently at
     least), to allow proxy jvm byte code to be provisioned dynamically.

## Issues:
- There are no issues requiring board attention at this time.

## Activity:

  -  Minimal activity at present, initial work on the modular build 
structure has commenced.  The current monolithic build is complex, with 
it's own build tool classdepandjar, it adds complexity for new 
developers. In recent months I have had work commitments that have 
limited my ability to integrate the modular build.  The other committers 
are waiting for the modular build and I have done a lot of work on this 
locally, this work has been a significant undertaking integrating the 
works of Dennis Reedy, Dan Rollo and myself.  This is also a mature 
codebase, having been in development since the late 1990's.


- The monolithic code has been svn moved into modules into an initial 
maven build structure, next step is to move junit tests to each module.


- Until the monolithic build has been broken up into maven modules, we 
are likely to have difficulty attracting new contributors due to the 
appearance of complexity.


Release roadmap:

River 3.1 - Modular build restructure (&   binary release)
River 3.2 - Input validation 4 Serialization, delayed unmarshalling&
safe ServiceRegistrar  lookup service.River 3.3 - OSGi support

## Health report:

  - River is a mature codebase with existing deployments, it was 
primarily designed for dynamic discovery of services on private 
networks.  IPv4 NAT limitations historically prevented the use of River 
on public networks, however the use of IPv6 on public networks removes 
these limitations.  Web services evolved with the publish subscribe 
model of today's internet, River has the potential to dynamically 
discover services on IPv6 networks, peer to peer, blurring current 
distinctions between client and server, it has the potential to address 
many of the security issues currently experienced with IoT and avoid any 
dependency on the proprietary cloud for "things".


- Future Direction:

    * Target IOT space with support for OSGi and IPv6 (security fixes
  required prior to announcement)
    * Input validation for java deserialization - prevents DOS and
  Gadget attacks.
    * IPv6 Multicast Service Discovery (River currently only supports
  IPv4 multicast discovery).
    * Delayed unmarshalling for Service Lookup and Discovery (includes
  SafeServiceRegistrar mentioned in release roadmap), so
  authentication can occur prior to downloading service proxy's,
  this addresses a long standing security issue with service lookup
  while significantly improving performance under some use cases.
    * Security fixes for SSL endpoints, updated to TLS v1.2 with removal
  of support for insecure cypher's.
    * Secure TLS SocketFactory's for RMI Registry, uses
  the currently logged in Subject for authentication.
  The RMI Registry still plays a minor role in service activation,
  this allows those who still use the Registry to secure it.
    * Maven build to replace existing ant built that uses
  classdepandjar, a bytecode dependency analysis build tool.
    * Updating the Jini specifications.

## Project Composition:

     There are currently 16 committers and 12 PMC members in this project.
     The Committer-to-PMC ratio is 4:3.

## Community changes, past quarter:

     No new PMC members. Last addition was Dan Rollo on 2017-12-01.
     No new committers. Last addition was Dan Rollo on 2017-11-02.

## Project Release Activity:
- Recent releases:

     River-3.0.0 was released on 2016-10-06.
     river-jtsk-2.2.3 was released on 2016-02-21.
     river-examples-1.0 was released on 2015-08-10.




--
This email has been checked for viruses by AVG.
https://www.avg.com

Re: February Board Report Draft

[Patricia Shanahan]

+1

On 2/26/2020 10:26 PM, Peter Firmstone wrote:
I didn't make the February deadline, so I'll post the report in time for 
March.


+1 Peter.

Please vote at your convenience.

Regards,

Peter.


On 2/20/2020 6:29 AM, Dan Rollo wrote:

Looks good to me. +1

Dan Rollo


From: Peter Firmstone 
Subject: February Board Report Draft
Date: February 18, 2020 at 10:10:04 PM EST
To: dev@river.apache.org


Hello River folk, please review / comment / suggest / changes for the 
draft board report for February below.


Regards,

Peter.

## Description:
  - Apache River provides a platform for dynamic discovery and lookup
 search of network services.  Services may be implemented in a number
 of languages, while clients are required to be jvm based 
(presently at

 least), to allow proxy jvm byte code to be provisioned dynamically.

## Issues:
- There are no issues requiring board attention at this time.

## Activity:

  -  Minimal activity at present, initial work on the modular build 
structure has commenced.  The current monolithic build is complex, 
with it's own build tool classdepandjar, it adds complexity for new 
developers. In recent months I have had work committments that have 
limited my ability to integrate the modular build.  The other 
committers are waiting for the modular build and I have done a lot of 
work on this locally, this work has been a significant undertaking 
integrating the works of Dennis Reedy, Dan Rollo and myself.  This is 
also a mature codebase, having been in development since the late 1990's.


- The monolithic code has been svn moved into modules into an initial 
maven build structure, next step is to move junit tests to each module.


- Until the monolithic build has been broken up into maven modules, we 
are likely to have difficulty attracting new contributors due to the 
appearance of complexity.


Release roadmap:

River 3.1 - Modular build restructure (&   binary release)
River 3.2 - Input validation 4 Serialization, delayed unmarshalling&
safe ServiceRegistrar  lookup service.River 3.3 - OSGi support

## Health report:

  - River is a mature codebase with existing deployments, it was 
primarily designed for dynamic discovery of services on private 
networks.  IPv4 NAT limitations historically prevented the use of 
River on public networks, however the use of IPv6 on public networks 
removes these limitations.  Web services evolved with the publish 
subscribe model of todays internet, River has the potential to 
dynamically discover services on IPv6 networks, peer to peer, blurring 
current destinctions between client and server, it has the potential 
to address many of the security issues currently experienced with IoT 
and avoid any dependency on the proprietary cloud for "things".


- Future Direction:

    * Target IOT space with support for OSGi and IPv6 (security fixes
  required prior to announcement)
    * Input validation for java deserialization - prevents DOS and
  Gadget attacks.
    * IPv6 Multicast Service Discovery (River currently only supports
  IPv4 multicast discovery).
    * Delayed unmarshalling for Service Lookup and Discovery (includes
  SafeServiceRegistrar mentioned in release roadmap), so
  authentication can occur prior to downloading service proxy's,
  this addresses a long standing security issue with service lookup
  while significantly improving performance under some use cases.
    * Security fixes for SSL endpoints, updated to TLS v1.2 with removal
  of support for insecure cyphers.
    * Secure TLS SocketFactory's for RMI Registry, uses
  the currently logged in Subject for authentication.
  The RMI Registry still plays a minor role in service activation,
  this allows those who still use the Registry to secure it.
    * Maven build to replace existing ant built that uses
  classdepandjar, a bytecode dependency analysis build tool.
    * Updating the Jini specifications.

## Project Composition:

 There are currently 16 committers and 12 PMC members in this 
project.

 The Committer-to-PMC ratio is 4:3.

## Community changes, past quarter:

 No new PMC members. Last addition was Dan Rollo on 2017-12-01.
 No new committers. Last addition was Dan Rollo on 2017-11-02.

## Project Release Activity:
- Recent releases:

 River-3.0.0 was released on 2016-10-06.
 river-jtsk-2.2.3 was released on 2016-02-21.
 river-examples-1.0 was released on 2015-08-10.


--
This email has been checked for viruses by AVG.
https://www.avg.com

Re: November Board Report Draft

[Patricia Shanahan]

+1

On 11/8/2019 3:47 PM, Peter Firmstone wrote:
Hello River folk, please review / comment / suggest / changes for the 
draft board report for November below.


Regards,

Peter.

## Description:
  - Apache River provides a platform for dynamic discovery and lookup
     search of network services.  Services may be implemented in a number
     of languages, while clients are required to be jvm based (presently at
     least), to allow proxy jvm byte code to be provisioned dynamically.

## Issues:
- There are no issues requiring board attention at this time.

## Activity:

  -  Minimal activity at present, initial work on the modular build 
structure has commenced.  The current monolithic build is complex, with 
it's own build tool classdepandjar, it adds complexity for new 
developers. In recent months I have had work committments that have 
limited my ability to integrate the modular build.  The other committers 
are waiting for the modular build and I have done a lot of work on this 
locally, this work has been a significant undertaking integrating the 
works of Dennis Reedy, Dan Rollo and myself.  This is also a mature 
codebase, having been in development since the late 1990's.


- The monolithic code has been svn moved into modules into an initial 
maven build structure, next step is to move junit tests to each module.


Release roadmap:

River 3.1 - Modular build restructure (&   binary release)
River 3.2 - Input validation 4 Serialization, delayed unmarshalling&
safe ServiceRegistrar  lookup service.River 3.3 - OSGi support

## Health report:

  - River is a mature codebase with existing deployments, it was 
primarily designed for dynamic discovery of services on private 
networks.  IPv4 NAT limitations historically prevented the use of River 
on public networks, however the use of IPv6 on public networks removes 
these limitations.  Web services evolved with the publish subscribe 
model of todays internet, River has the potential to dynamically 
discover services on IPv6 networks, peer to peer, blurring current 
destinctions between client and server, it has the potential to address 
many of the security issues currently experienced with IoT and avoid any 
dependency on the proprietary cloud for "things".


- Future Direction:

    * Target IOT space with support for OSGi and IPv6 (security fixes
  required prior to announcement)
    * Input validation for java deserialization - prevents DOS and
  Gadget attacks.
    * IPv6 Multicast Service Discovery (River currently only supports
  IPv4 multicast discovery).
    * Delayed unmarshalling for Service Lookup and Discovery (includes
  SafeServiceRegistrar mentioned in release roadmap), so
  authentication can occur prior to downloading service proxy's,
  this addresses a long standing security issue with service lookup
  while significantly improving performance under some use cases.
    * Security fixes for SSL endpoints, updated to TLS v1.2 with removal
  of support for insecure cyphers.
    * Secure TLS SocketFactory's for RMI Registry, uses
  the currently logged in Subject for authentication.
  The RMI Registry still plays a minor role in service activation,
  this allows those who still use the Registry to secure it.
    * Maven build to replace existing ant built that uses
  classdepandjar, a bytecode dependency analysis build tool.
    * Updating the Jini specifications.

## Project Composition:

     There are currently 16 committers and 12 PMC members in this project.
     The Committer-to-PMC ratio is 4:3.

## Community changes, past quarter:

     No new PMC members. Last addition was Dan Rollo on 2017-12-01.
     No new committers. Last addition was Dan Rollo on 2017-11-02.

## Project Release Activity:
- Recent releases:

     River-3.0.0 was released on 2016-10-06.
     river-jtsk-2.2.3 was released on 2016-02-21.
     river-examples-1.0 was released on 2015-08-10.

## JIRA activity:
     1 issue opened in JIRA, past quarter (no change)
     0 issues closed in JIRA, past quarter (-100% decrease)

Re: August Board Report - Draft

[Patricia Shanahan]

+1

Patricia

On 8/9/2019 4:51 PM, Peter Firmstone wrote:
Hello River folk, please review / comment / suggest / changes for the 
draft board report for August below.


Regards,

Peter.

## Description:
  - Apache River provides a platform for dynamic discovery and lookup
     search of network services.  Services may be implemented in a number
     of languages, while clients are required to be jvm based (presently at
     least), to allow proxy jvm byte code to be provisioned dynamically.

## Issues:
- There are no issues requiring board attention at this time.

## Activity:

  -  Minimal activity at present, initial work on the modular build 
structure has commenced.  The current monolithic build is complex, with 
it's own build tool classdepandjar, it adds complexity for new 
developers. In recent months I have had work committments that have 
limited my ability to integrate the modular build.  The other committers 
are waiting for the modular build and I have done a lot of work on this 
locally, this work has been a significant undertaking integrating the 
works of Dennis Reedy, Dan Rollo and myself.  This is also a mature 
codebase, having been in development since the late 1990's.


Release roadmap:

River 3.1 - Modular build restructure (&   binary release)
River 3.2 - Input validation 4 Serialization, delayed unmarshalling&
safe ServiceRegistrar  lookup service.River 3.3 - OSGi support

## Health report:

  - River is a mature codebase with existing deployments, it was 
primarily designed for dynamic discovery of services on private 
networks.  IPv4 NAT limitations historically prevented the use of River 
on public networks, however the use of IPv6 on public networks removes 
these limitations.  Web services evolved with the publish subscribe 
model of todays internet, River has the potential to dynamically 
discover services on IPv6 networks, peer to peer, blurring current 
destinctions between client and server, it has the potential to address 
many of the security issues currently experienced with IoT and avoid any 
dependency on the proprietary cloud for "things".


- Future Direction:

    * Target IOT space with support for OSGi and IPv6 (security fixes
  required prior to announcement)
    * Input validation for java deserialization - prevents DOS and
  Gadget attacks.
    * IPv6 Multicast Service Discovery (River currently only supports
  IPv4 multicast discovery).
    * Delayed unmarshalling for Service Lookup and Discovery (includes
  SafeServiceRegistrar mentioned in release roadmap), so
  authentication can occur prior to downloading service proxy's,
  this addresses a long standing security issue with service lookup
  while significantly improving performance under some use cases.
    * Security fixes for SSL endpoints, updated to TLS v1.2 with removal
  of support for insecure cyphers.
    * Secure TLS SocketFactory's for RMI Registry, uses
  the currently logged in Subject for authentication.
  The RMI Registry still plays a minor role in service activation,
  this allows those who still use the Registry to secure it.
    * Maven build to replace existing ant built that uses
  classdepandjar, a bytecode dependency analysis build tool.
    * Updating the Jini specifications.

## PMC changes:

- Currently 12 PMC members.
- No new PMC members added in the last 3 months
- Last PMC addition was Dan Rollo on Fri Dec 01 2017

## Committer base changes:

- Currently 16 committers.
- No new committers added in the last 3 months
- Last committer addition was Dan Rollo at Thu Nov 02 2017

## Releases:

- Last release was River-3.0.0 on Thu Oct 06 2016

## Mailing list activity:

- dev@river.apache.org:
- 90 subscribers (up 0 in the last 3 months):
- 4 emails sent to list (4 in previous quarter)

- u...@river.apache.org:
- 90 subscribers (up 0 in the last 3 months):
- 1 emails sent to list (1 in previous quarter)


## JIRA activity:

- 1 JIRA tickets created in the last 3 months
- 0 JIRA tickets closed/resolved in the last 3 months



---
This email has been checked for viruses by AVG.
https://www.avg.com

Re: River Board Report

[Patricia Shanahan]

+1

Patricia

On 6/5/2019 2:04 PM, Peter Firmstone wrote:
Hello River folk, please review / comment / suggest / changes for the 
draft board report for June below.


Regards,

Peter.

## Description:
  - Apache River provides a platform for dynamic discovery and lookup
     search of network services.  Services may be implemented in a number
     of languages, while clients are required to be jvm based (presently 
at least), to allow proxy jvm byte code to be provisioned dynamically.


## Issues:

- No significant issues requiring board attention at this time.

## Activity:

  -  Minimal activity at present, initial work on the modular build 
structure has commenced.  The current monolithic build is complex, with 
it's own build tool classdepandjar, it adds complexity for new 
developers. In recent months I have had work committments that have 
limited my ability to integrate the modular build.  The other committers 
are waiting for the modular build and I have done a lot of work on this 
locally, this work has been a significant undertaking integrating the 
works of Dennis Reedy, Dan Rollo and myself.  This is also a mature 
codebase, having been in development since the late 1990's.


Release roadmap:

River 3.1 - Modular build restructure (&   binary release)
River 3.2 - Input validation for Serialization, delayed unmarshalling&
safe ServiceRegistrar  lookup service.River 3.3 - OSGi support

## Health report:

  - River is a mature codebase with existing deployments, it was 
primarily designed for dynamic discovery of services on private 
networks.  IPv4 NAT limitations historically prevented the use of River 
on public networks, however the use of IPv6 on public networks removes 
these limitations.  Web services evolved with the publish subscribe 
model of todays internet, River has the potential to dynamically 
discover services on IPv6 networks, peer to peer, blurring current 
destinctions between client and server, it has the potential to address 
many of the security issues currently experienced with IoT and avoid any 
dependency on the proprietary cloud for "things".


- Future Direction:

    * Target IOT space with support for OSGi and IPv6 (security fixes
  required prior to announcement)
    * Input validation for java deserialization - prevents DOS and
  Gadget attacks.
    * IPv6 Multicast Service Discovery (River currently only supports
  IPv4 multicast discovery).
    * Delayed unmarshalling for Service Lookup and Discovery (includes
  SafeServiceRegistrar mentioned in release roadmap), so
  authentication can occur prior to downloading service proxy's,
  this addresses a long standing security issue with service lookup
  while significantly improving performance under some use cases.
    * Security fixes for SSL endpoints, updated to TLS v1.2 with removal
  of support for insecure cyphers.
    * Secure TLS SocketFactory's for RMI Registry, uses
  the currently logged in Subject for authentication.
  The RMI Registry still plays a minor role in service activation,
  this allows those who still use the Registry to secure it.
    * Maven build to replace existing ant built that uses
  classdepandjar, a bytecode dependency analysis build tool.
    * Updating the Jini specifications.

## PMC changes:

  - Currently 12 PMC members.
  - No new PMC members added in the last 3 months
  - Last PMC addition was Dan Rollo on Fri Dec 01 2017

## Committer base changes:

  - Currently 16 committers.
  - No new committers added in the last 3 months
  - Last committer addition was Dan Rollo at Thu Nov 02 2017

## Releases:

  - Last release was River-3.0.0 on Thu Oct 06 2016

## Mailing list activity:

  - dev@river.apache.org:
     - 90 subscribers (up 1 in the last 3 months):
     - 4 emails sent to list (5 in previous quarter)

  - u...@river.apache.org:
     - 90 subscribers (down -2 in the last 3 months):
     - 1 emails sent to list (0 in previous quarter)

Re: Draft February Board report.

[Patricia Shanahan]

+1

On 2/20/2018 3:00 PM, Dan Rollo wrote:

+1


Subject: Draft February Board report.
Date: February 17, 2018 at 5:44:29 AM EST
To: "" 


Hi River folks,

Draft board report for February, I'm running a little late, so this might have 
to be postponed untill March.

Regards,

Peter.

<===>

## Description:

- Apache River provides a platform for dynamic discovery and lookup search of 
network services.  Services may be implemented in a number of languages, while 
clients are required to be jvm based (presently at least), to allow proxy jvm 
byte code to be provisioned dynamically.

## Issues:

No significant issues requiring board attention at this time.

## Activity:

Interest in making Jini specifications programming language agnostic.

Release roadmap:

River 3.0.1 - thread leak fix
River 3.1 - Modular build restructure (&  binary release)
River 3.2 - Input validation 4 Serialization, delayed unmarshalling&  safe 
ServiceRegistrar  lookup service.
River 3.3 - OSGi support

## Health report:

- Minimal activity at present on dev.
- No recent commit activity, but there are plans for more work in near future.

- Future Direction:

   * Target IOT space with support for OSGi and IPv6 (security fixes required 
prior to announcement)
   * Input validation for java deserialization - prevents DOS and
 Gadget attacks.
   * IPv6 Multicast Service Discovery (River currently only support
 IPv4 multicast discovery).
   * Delayed unmarshalling for Service Lookup and Discovery (includes
 SafeServiceRegistrar mentioned in release roadmap), so
 authentication can occur prior to downloading service proxy's,
 this addresses a long standing security issue with service lookup
 while significantly improving performance under some use cases.
   * Security fixes for SSL endpoints, updated to TLS v1.2 with removal
 of support for insecure cyphers.
   * Maven build to replace existing ant built that uses
 classdepandjar, a bytecode dependency analysis build tool.
   * Updating the Jini specifications.

## PMC changes:

- Currently 12 PMC members.
- One new PMC members added in the last 3 months
- Last PMC addition was Dan Rollo on Fri 1st December 2017

## Committer base changes:

- Currently 16 committers.

## Releases:

- River-3.0.0 was released on Wed Oct 05 2016

## Mailing list activity:

- Relatively quiet in comparison to recent months, however this appears as a 
result of reaching concensus after a period of discussion.

## JIRA activity:

- Activity around making Jini specifications programming language agnostic.



---
This email has been checked for viruses by AVG.
http://www.avg.com

Change of Chair

[Patricia Shanahan]

The board today unanimously passed the resolution accepting my 
resignation as River PMC Chair, and appointing Peter Firmstone to 
replace me.


Peter: Congratulations/commiseration, and thanks for volunteering. Let 
me know if there is anything I can do to help.

Change of Chair

[Patricia Shanahan]

I have been PMC chair for 3 years, and have become much less involved in 
River during that time. Accordingly, I think it is time for a new chair. 
I am posting this to dev@ to get the widest possible range of volunteers.


I plan to resign effective at the September board meeting, so there will 
 be time to select and vote on my successor. If things go fast, we can 
do the change at the August meeting, but we would have to vote in time 
to get a resolution on the agenda.


The main responsibility of a PMC Chair is to maintain communication 
between the PMC and the Board, especially filing the quarterly report.

Re: [Report] Apache River - Draft

[Patricia Shanahan]

Thanks for taking care of that, and simplifying a busy month for me.

On 5/7/2017 5:35 PM, Peter wrote:

+1 Peter.  I've uploaded the report.

Sent from my Samsung device.

  Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 06/05/2017 10:40:19 am
To: dev@river.apache.org
Subject: Re: [Report] Apache River - Draft

+1

On 5/5/2017 12:55 AM, Peter wrote:

 Hi River folks,

 Draft board report for May, please make suggestions, remember this is
 only my point of view, if yours differs please say so.  It's probably a
 bit wordy, so could use improvement, but I want to be honest with the
 board about the current state of development.

 Regards,

 Peter.

 <===>

 ## Description:

  - Apache River provides a platform for dynamic discovery and lookup
 search of network services.  Services may be implemented in a number of
 languages, while clients are required to be jvm based, to allow proxy
 jvm byte code to be provisioned dynamically.

 ## Issues:

  No significant issues requiring board attention at this time.

 ## Activity:

  - Significant drop in activity since February (205 emails on dev), down
 to 6 in March and 8 in April.

 - Proposed Release roadmap received positive responses:

 Proposed Release roadmap:


  River 3.0.1 - thread leak fix
  River 3.1 - Modular build restructure (&  binary release)
  River 3.2 - Input validation 4 Serialization, delayed unmarshalling&
 safe ServiceRegistrar  lookup service.
  River 3.3 - OSGi support


 ## Health report:

  - Minimal activity at present on dev.
  - Plan to update website with more recent success stories of River
 deployment, in one large scale deployment example maintenance costs are
 low to non existance while reliability is reportedly very solid in the
 face of external system failures.  There seem to be at least four recent
 examples that need to be added to our success stories.
  - No recent commit activity, but there are plans for more work in near
 future.
  - Future Direction:

* Target IOT space with support for OSGi and IPv6 (security fixes
 required prior to announcement)
* Input validation for java deserialization - prevents DOS and
  Gadget attacks.
* IPv6 Multicast Service Discovery (River currently only support
  IPv4 multicast discovery).
* Delayed unmarshalling for Service Lookup and Discovery (includes
  SafeServiceRegistrar mentioned in release roadmap), so
  authentication can occur prior to downloading service proxy's,
  this addresses a long standing security issue with service lookup
  while significantly improving performance under some use cases.
* Security fixes for SSL endpoints, updated to TLS v1.2 with removal
  of support for insecure cyphers.
* Maven build to replace existing ant built that uses
  classdepandjar, a bytecode dependency analysis build tool.

 ## PMC changes:

  - Currently 11 PMC members.
  - No new PMC members added in the last 3 months
  - Last PMC addition was Bryan Thompson on Sun Aug 30 2015

 ## Committer base changes:

  - Currently 15 committers.
  - Zsolt Kúti was added as a committer on Wed Dec 07 2016
  - Bharath Kumar was added as a committer on the 23th March 2017

 ## Releases:

  - River-3.0.0 was released on Wed Oct 05 2016

 ## Mailing list activity:

  - Relatively quiet in comparison to recent months, however this appears
 as a result of reaching concensus after a period of discussion.

 ## JIRA activity:

 - Nil Activity this period.

Re: [Report] Apache River - Draft

[Patricia Shanahan]

+1

On 5/5/2017 12:55 AM, Peter wrote:

Hi River folks,

Draft board report for May, please make suggestions, remember this is
only my point of view, if yours differs please say so.  It's probably a
bit wordy, so could use improvement, but I want to be honest with the
board about the current state of development.

Regards,

Peter.

<===>

## Description:

 - Apache River provides a platform for dynamic discovery and lookup
search of network services.  Services may be implemented in a number of
languages, while clients are required to be jvm based, to allow proxy
jvm byte code to be provisioned dynamically.

## Issues:

 No significant issues requiring board attention at this time.

## Activity:

 - Significant drop in activity since February (205 emails on dev), down
to 6 in March and 8 in April.

- Proposed Release roadmap received positive responses:

Proposed Release roadmap:


 River 3.0.1 - thread leak fix
 River 3.1 - Modular build restructure (&  binary release)
 River 3.2 - Input validation 4 Serialization, delayed unmarshalling&
safe ServiceRegistrar  lookup service.
 River 3.3 - OSGi support


## Health report:

 - Minimal activity at present on dev.
 - Plan to update website with more recent success stories of River
deployment, in one large scale deployment example maintenance costs are
low to non existance while reliability is reportedly very solid in the
face of external system failures.  There seem to be at least four recent
examples that need to be added to our success stories.
 - No recent commit activity, but there are plans for more work in near
future.
 - Future Direction:

   * Target IOT space with support for OSGi and IPv6 (security fixes
required prior to announcement)
   * Input validation for java deserialization - prevents DOS and
 Gadget attacks.
   * IPv6 Multicast Service Discovery (River currently only support
 IPv4 multicast discovery).
   * Delayed unmarshalling for Service Lookup and Discovery (includes
 SafeServiceRegistrar mentioned in release roadmap), so
 authentication can occur prior to downloading service proxy's,
 this addresses a long standing security issue with service lookup
 while significantly improving performance under some use cases.
   * Security fixes for SSL endpoints, updated to TLS v1.2 with removal
 of support for insecure cyphers.
   * Maven build to replace existing ant built that uses
 classdepandjar, a bytecode dependency analysis build tool.

## PMC changes:

 - Currently 11 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Bryan Thompson on Sun Aug 30 2015

## Committer base changes:

 - Currently 15 committers.
 - Zsolt Kúti was added as a committer on Wed Dec 07 2016
 - Bharath Kumar was added as a committer on the 23th March 2017

## Releases:

 - River-3.0.0 was released on Wed Oct 05 2016

## Mailing list activity:

 - Relatively quiet in comparison to recent months, however this appears
as a result of reaching concensus after a period of discussion.

## JIRA activity:

- Nil Activity this period.

Re: [Report] Apache River - Draft

[Patricia Shanahan]

Remember your audience, the ASF board. They care about community and big 
picture strategy.


On 5/2/2017 12:40 AM, Peter wrote:


Yes, thanks for the feedback.

Very valid points re production code and modularity, we've built on that by 
paying back our technical debt as well.

Once, making a change usually meant a test failure in something unrelated, now 
the code is rock solid, making the transition to modularity is/was relatively 
straightforward as the architecture is well designed.  The benefits of 
simplicity and ease of use by changing to the maven build system is 
outstanding, new users will no longer have to learn a new build system in order 
to utilise River and can digest the api in smaller bites.

Serialization frameworks are being looked at more closely in the aftermath of 
Java deserialization flaws and security experts are finding similar problems in 
other frameworks.

Will focus on the positive and try again.

Cheers,

Peter.


Sent from my Samsung device.

  Include original message
 Original message 
From: Bryan Thompson <br...@blazegraph.com>
Sent: 01/05/2017 11:27:07 pm
To: <dev@river.apache.org> <dev@river.apache.org>
Subject: Re: [Report] Apache River - Draft

My sense is that it is overly negative.  I think that we made great
progress on agreeing on a new direction, getting beyond some of the
deadlocks that were holding back development, new look and feel for the
site, etc.  It is also significant that committers were added.

It will take a while to get to the point where the project is "healthy" by
the measure of many active committers.  Breaking down the code into more
modular build will help.  Focusing on a broad application area (e.g.,
secure IoT) will help.  This is also a project with production grade code,
which means quite a bit.

So, I would suggest changing the emphasis to how the project is beginning
to execute on its new direction, what that direction is, that new
committers have been added, what they are working on, and how this builds
towards the project goals and a healthier community.

Thanks,
Bryan

On Mon, May 1, 2017 at 6:04 AM, Patricia Shanahan <p...@acm.org> wrote:


 My first impression is too much technical detail. Also we had a request
 from a board member last month "It would be helpful if you could expand a
 little (a couple of sentences is fine) on the discussions for future
 directions in your next report.". That needs to be easily identifiable in
 the report.

 On 5/1/2017 1:26 AM, Peter wrote:


 Hi River folks,

 Draft board report for May, please make suggestions, remember this is
 only my point of view, if yours differs please say so.  It's probably a
 bit wordy, so could use improvement, but I want to be honest with the
 board about the current state of development.

 Regards,

 Peter.

 <===>

 ## Description:

  - Apache River provides a platform for dynamic discovery and lookup
 search of network services.  Services may be implemented in a number of
 languages, while clients are required to be jvm based, to allow proxy
 jvm byte code to be provisioned dynamically.

 ## Issues:

  - River community has over time settled on a stable trunk development
 model.  The community tends towards risk aversion regarding code
 modifications, this has suppressed active development in the past.

 - The River 3.0 release included hundreds of internal bug fixes for
 latent race conditions, with minimal breaking changes to public api
 (com.sun packages renamed to org.apache.river).  We have had one newly
 introduced bug reported (thread memory leak) since release.  River 3.0
 was developed in an experimental branch, there were some issues
 experienced during merging, which lead to an effort to migrate to git,
 however that effort has stalled as some members (now emeritus) raised
 concerns about migration, this requires further investigation and
 discussion before it can be resolved.

 Some features are being developed outside the project by one pmc member,
 at the request of another member (also now emeritus) who had raised
 objections.  The current plan is to confirm feature stability outside
 the project and submit diff patches to jira once a feature has been
 accepted by the community.

 We are still waiting for more user feedback regarding the 3.0 release,
 one user has reported success using River 3.0 with OSGi, while having
 been unsuccessful with earlier releases.  The com.sun ->
 org.apacheriver namespace change has caused breaking changes for
 downstream projects, which may be slowing uptake of this release.  A
 compatibility layer package has been developed externally, while
 relatively new, it may assist with uptake for River 3.0.

 - If River 3.0 is well recieved, it will likely lead to more confidence
 and acceptance of new features and experimental development in future.

 ## Activity:

  - Significant drop in interest since Fe

Re: [Report] Apache River - Draft

[Patricia Shanahan]

My first impression is too much technical detail. Also we had a request 
from a board member last month "It would be helpful if you could expand 
a little (a couple of sentences is fine) on the discussions for future 
directions in your next report.". That needs to be easily identifiable 
in the report.


On 5/1/2017 1:26 AM, Peter wrote:

Hi River folks,

Draft board report for May, please make suggestions, remember this is
only my point of view, if yours differs please say so.  It's probably a
bit wordy, so could use improvement, but I want to be honest with the
board about the current state of development.

Regards,

Peter.

<===>

## Description:

 - Apache River provides a platform for dynamic discovery and lookup
search of network services.  Services may be implemented in a number of
languages, while clients are required to be jvm based, to allow proxy
jvm byte code to be provisioned dynamically.

## Issues:

 - River community has over time settled on a stable trunk development
model.  The community tends towards risk aversion regarding code
modifications, this has suppressed active development in the past.

- The River 3.0 release included hundreds of internal bug fixes for
latent race conditions, with minimal breaking changes to public api
(com.sun packages renamed to org.apache.river).  We have had one newly
introduced bug reported (thread memory leak) since release.  River 3.0
was developed in an experimental branch, there were some issues
experienced during merging, which lead to an effort to migrate to git,
however that effort has stalled as some members (now emeritus) raised
concerns about migration, this requires further investigation and
discussion before it can be resolved.

Some features are being developed outside the project by one pmc member,
at the request of another member (also now emeritus) who had raised
objections.  The current plan is to confirm feature stability outside
the project and submit diff patches to jira once a feature has been
accepted by the community.

We are still waiting for more user feedback regarding the 3.0 release,
one user has reported success using River 3.0 with OSGi, while having
been unsuccessful with earlier releases.  The com.sun ->
org.apache.river namespace change has caused breaking changes for
downstream projects, which may be slowing uptake of this release.  A
compatibility layer package has been developed externally, while
relatively new, it may assist with uptake for River 3.0.

- If River 3.0 is well recieved, it will likely lead to more confidence
and acceptance of new features and experimental development in future.

## Activity:

 - Significant drop in interest since February (205 emails on dev), down
to 6 in March and 8 in April.  No more emails on user, no commits since
Feb.

- Proposed Release roadmap received positive responses:

Proposed Release roadmap:


 River 3.0.1 - thread leak fix
 River 3.1 - Modular build restructure (&  binary release)
 River 3.2 - Input validation 4 Serialization, delayed unmarshalling&
safe ServiceRegistrar

lookup service.

 River 3.3 - OSGi support


## Health report:

 - Little activity at present on dev.
 - No recent commit activity.
 - Development has continued outside the project for contraversial
features (there seems to be more acceptance of these features recently):

   * Input validation for java deserialization - prevents DOS and
 Gadget attacks.
   * IPv6 Multicast Service Discovery (River currently only support
 IPv4 multicast discovery).
   * Delayed unmarshalling for Service Lookup and Discovery (includes
 SafeServiceRegistrar mentioned in release roadmap), so
 authentication can occur prior to downloading service proxy's,
 this addresses a long standing security issue with service lookup
 while significantly improving performance under some use cases.
   * Security fixes for SSL endpoints, updated to TLS v1.2 with removal
 of support for insecure cyphers.
   * Maven build to replace existing ant built that uses
 classdepandjar, a bytecode dependency analysis build tool.
   * Security tool to generate security policy files based on principle
 of least privilege, this has been rejected as the system is likely
 to be vulnerable to attack while the policy files are being
 generated.  The tool was written in response to requests for more
 tooling to make River easier to use.

## PMC changes:

 - Currently 11 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Bryan Thompson on Sun Aug 30 2015

## Committer base changes:

 - Currently 15 committers.
 - Zsolt Kúti was added as a committer on Wed Dec 07 2016
 - Bharath Kumar was added as a committer on the 23th March 2017

## Releases:

 - River-3.0.0 was released on Wed Oct 05 2016

## Mailing list activity:

 - Minimal.

## JIRA activity:

- Nil Activity.

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

[Patricia Shanahan]

Sorry, I'm trying to find out the meaning of the current subject line. 
I'm not sure when it changed to "OSGi MP Complete".


On 2/12/2017 10:50 PM, Michał Kłeczek wrote:

Sorry, NP Completness of what?
I have been the first to mention NP hardness of constraint satisfaction
problem
but I am not sure if this is what you are asking about.

Thanks,
Michal

Patricia Shanahan wrote:

Are you literally claiming NP Completeness, or just using that as an
analogy for really, really difficult?

Re: OSGi NP Complete Was: OSGi - deserialization remote invocation strategy

[Patricia Shanahan]

Are you literally claiming NP Completeness, or just using that as an 
analogy for really, really difficult?


On 2/11/2017 1:23 PM, Michał Kłeczek wrote:

I am sorry but I think that to solve various issues we need to make sure
fundamentals are right:

1. There is NO such a thing as "reflective non-smart" proxy - EVERY
proxy is "smart" (even if it is "reflective") - there is an
InvocationHandler down there, isn't there?
2. Solving this on service discovery level is trying to do it on the
WRONG level of abstraction. Services DEPEND on class loading - not the
other way around.
3. What you propose is a partial "solution". Not being able to register
"smart" event listeners means no custom endpoints for example
(UDPEndpoint anyone?)
4. Trying to squeeze partial solutions into the framework is IMHO a BIG
no no.
This is simply creating more code, more maintenance burden and more
headache for users trying to workaround "edge, unsupported cases".

Please - lets try to come up with the RIGHT solution that is going to
REALLY fix class loading issues.

Thanks,
Michal

Peter wrote:

In a word, ServiceDiscoveryManager

ServiceDiscoveryManager is the solution.

ServiceDiscoveryManager performs discovery and looks up services from
registrars based on filters.  ServiceDiscoveryManager then performs
local filtering.  This allows time for proxy bundles to be installed,
resolve, started and confirmed type compatible, prior to them being
made available (via OSGi service registry if you so desire) for client
use.

The new interfaces that are part of JGDMS that I'd like to see their
way into River, found here:

https://github.com/pfirmstone/JGDMS/blob/Maven_build/modularize/JGDMS/jgdms-lib-dl/src/main/java/net/jini/lookup/SafeServiceRegistrar.java


https://github.com/pfirmstone/JGDMS/blob/Maven_build/modularize/JGDMS/jgdms-lib-dl/src/main/java/net/jini/lookup/ServiceAttributesAccessor.java

https://github.com/pfirmstone/JGDMS/blob/Maven_build/modularize/JGDMS/jgdms-lib-dl/src/main/java/net/jini/lookup/ServiceCodebaseAccessor.java

https://github.com/pfirmstone/JGDMS/blob/Maven_build/modularize/JGDMS/jgdms-lib-dl/src/main/java/net/jini/lookup/ServiceIDAccessor.java

https://github.com/pfirmstone/JGDMS/blob/Maven_build/modularize/JGDMS/jgdms-lib-dl/src/main/java/net/jini/lookup/ServiceProxyAccessor.java


ServiceCodebaseAccessor is also used as part of secure discovery, but
the codebase string and certs are transferred as primitives over the
network.

In this case codebase annotations don't need to be included in the
stream, the JERI endpoints don't need them at all.

How so?

We can use ServiceItemFilter and ProxyPreparer to install, resolve and
start out proxy codebase, before downloading the proxy.  The
interfaces listed above allow an array bootstrap proxy's
(java.lang.reflect.Proxy) to be obtained from SafeServiceRegistrar.

Firstly the bootstrap proxy's JERI endpoint will be loaded in the
ServiceDiscoveryManager's ClassLoader, so after we've retrieved the
codebase annotation and signers, created a bundle for the proxy,
resolved it's dependencies (via OSGi resolution and repository
services), we need to remarshall the bootstrap proxy into a
MarshalledInstance, then unmarshall it using the ClassLoader of the
recently started proxy bundle.  Then when we cast the bootstrap proxy
to ServiceProxyAccessor and retrieve the smart proxy, it will be
loaded into the same ClassLoader that the bootstrap proxy uses, our
newly provisioned and loaded bundle (the correct ClassLoader) without
need to serialize any annotations, then the smart proxy can have
constraints applied etc and be registered as an OSGi service with the
OSGi registrar, where client code can interact with the remote proxy.

Now if public Serializable classes that are imported by the proxy's
bundle (service api) or private classes in the proxy's bundle can be
deserialized and the JERI endpoint has a reference to the ClassLoader
of the proxy.

This should be good enough so we don't require the "bundle stack"
proposed earlier, which also saves the need to explain it and
simplifies the solution (the intent of the bundle stack was to allow
deserialization of private classes within other bundles whose packages
have been imported by the proxy).

The client won't be able to pass a smart proxy to the service (like a
Listener), but it can still pass a non smart proxy and it will still
function.  So clients can still export their own remote service
(albiet without a codebase, excluding smart proxy's), but it'll be
good enough for a listener etc.

Cheers,

Peter.


On 8/02/2017 1:09 PM, Niclas Hedhman wrote:

Maybe there are some misunderstanding somewhere... see below;

On Wed, Feb 8, 2017 at 3:35 AM, Peter  wrote:

I'm currently only considering OSGi server ->  OSGi client.  Mick's

investigating all four options.

Ok, makes it a lot easier for me to follow.


Not expecting the client calling bundle to resolve everything, hence
the
stack, so we have the full 

Re: Draft of February 2017 report

[Patricia Shanahan]

+1

Active PMC members: Please approve or comment.

On 2/4/2017 9:35 AM, Patricia Shanahan wrote:

## Description:

 - Apache River software provides a standards-compliant JINI service.

## Issues:

 - There are no issues requiring board attention at this time.

## Activity:

 - Continued discussion of River's future direction, this quarter mainly
on OSGi and serialization.

 - Zsolt Kúti reworked the River web site.

## Health report:

 - The future directions discussion continues.

 - Attracting new developers will remain difficult until the future
direction is firmed up and made visible. We did add one committer this
quarter.

## PMC changes:

 - Currently 11 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Bryan Thompson on Sun Aug 30 2015

## Committer base changes:

 - Currently 14 committers.
 - Zsolt Kúti was added as a committer on Wed Dec 07 2016

## Releases:

 - River-3.0.0 was released on Wed Oct 05 2016

## Mailing list activity:

 - There has been a recent increase in dev@ activity due to a lively
technical discussion of OSGi and serialization in the context of River.
That discussion is on-going.

 - dev@river.apache.org:
- 95 subscribers (up 0 in the last 3 months):
- 201 emails sent to list (114 in previous quarter)

 - u...@river.apache.org:
- 96 subscribers (up 0 in the last 3 months):
- 2 emails sent to list (3 in previous quarter)


## JIRA activity:

 - 2 JIRA tickets created in the last 3 months
 - 1 JIRA tickets closed/resolved in the last 3 months

Fwd: Fwd: IoT at the ASF -- ApacheCon and Project DOAPs [was: Does your project play in the IoT space?]

[Patricia Shanahan]

Does River have/need a position on the general Apache IoT push?


 Forwarded Message 
Subject: Fwd: IoT at the ASF -- ApacheCon and Project DOAPs [was: Does 
your project play in the IoT space?]

Date: Sat, 4 Feb 2017 14:31:31 -0600
From: Trevor Grant 
Reply-To: d...@community.apache.org
To: us...@apex.apache.org, u...@beam.incubator.apache.org, 
d...@brooklyn.apache.org, u...@cassandra.apache.org, 
d...@community.apache.org, d...@edgent.apache.org, u...@geode.apache.org, 
us...@iota.incubator.apache.org, us...@kafka.apache.org, 
u...@mahout.apache.org, d...@mynewt.incubator.apache.org, 
us...@nifi.apache.org, us...@tomcat.apache.org, u...@zeppelin.apache.org


The first Apache IoT mini-con is happening this year at ApacheCon, Miami!!

http://us.apacheiot.org/

The following is a snipped from Roman Shaponshnik on the dev@community
list, perfectly describes the spirit of the mini-con:

"The whole premise of the track will be "Not your gramps IoT" which means
that unlike IoT events that grew out of the embedded industry we're talking
a very holistic, system view on IoT. Our hope is that Apache IoT will be a
meeting place for next generation IoT 2.0 built by developer, for
developers under the Apache Way governance model.

ASF's breadth starts making a lot of sense when you consider what kind of
technology is needed to build an end-to-end user experience in IoT 2.0: you
start at the edge, you consider the gateways, go to a data center and end
up on a client mobile device. All technology providers are now realizing
that the key to success is allowing developers unprecedented ease of
management and deployment of their business logic all throughout these
layers. Just look at what Amazon is doing with Lambda on the edge
(Amazon's Greengrass)!

The good news is that at ASF we've got all the building blocks available to
us in various communities. So regardless of whether you're an Apache
Mynewt (incubating) developer working on the far fringes of the edge, or
you are a Apache Brooklyn developer automating microservices provisioning
or you're plumbing data streams with Kafka, NiFi or Geode or
you're analyzing that data with Hadoop or you're a Tomcat or httpd
guru facilitating the end-user experience -- we all have pieces to
contribute to the IoT 2.0 puzzle."

I apologize for the mass email (and if you got this multiple times)
however, the Call for Submissions closes February 11th.  All of the
communities copied have something of significance to contribute to IoT, and
the list is not exhaustive- please feel free to forward to any who might be
interested.

Thanks and see you in Miami!


Trevor Grant
Data Scientist
https://github.com/rawkintrevo
http://stackexchange.com/users/3002022/rawkintrevo
http://trevorgrant.org

*"Fortunate is he, who is able to know the causes of things."  -Virgil*

Draft of February 2017 report

[Patricia Shanahan]

## Description:

 - Apache River software provides a standards-compliant JINI service.

## Issues:

 - There are no issues requiring board attention at this time.

## Activity:

 - Continued discussion of River's future direction, this quarter 
mainly on OSGi and serialization.


 - Zsolt Kúti reworked the River web site.

## Health report:

 - The future directions discussion continues.

 - Attracting new developers will remain difficult until the future 
direction is firmed up and made visible. We did add one committer this 
quarter.


## PMC changes:

 - Currently 11 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Bryan Thompson on Sun Aug 30 2015

## Committer base changes:

 - Currently 14 committers.
 - Zsolt Kúti was added as a committer on Wed Dec 07 2016

## Releases:

 - River-3.0.0 was released on Wed Oct 05 2016

## Mailing list activity:

 - There has been a recent increase in dev@ activity due to a lively 
technical discussion of OSGi and serialization in the context of River. 
That discussion is on-going.


 - dev@river.apache.org:
- 95 subscribers (up 0 in the last 3 months):
- 201 emails sent to list (114 in previous quarter)

 - u...@river.apache.org:
- 96 subscribers (up 0 in the last 3 months):
- 2 emails sent to list (3 in previous quarter)


## JIRA activity:

 - 2 JIRA tickets created in the last 3 months
 - 1 JIRA tickets closed/resolved in the last 3 months

Re: [jira] [Commented] (RIVER-447) Leaked Executor Service Threads in LoadClass

[Patricia Shanahan]

Looks like a good way of checking it out. I'm in favor of committing to 
trunk.


On 1/19/2017 7:26 PM, Peter wrote:

Thanks Shawn & Dan for reviewing,

I'm happy to commit that to trunk now using lazy concensus.

Pat, do you feel about this as a user review process?

Regards,

Peter.

Sent from my Samsung device.

  Include original message
 Original message 
From: Dan Rollo (JIRA) 
Sent: 20/01/2017 01:29:26 am
To: comm...@river.apache.org
Subject: [jira] [Commented] (RIVER-447) Leaked Executor Service Threads in 
LoadClass


[ 
https://issues.apache.org/jira/browse/RIVER-447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15830100#comment-15830100
 ]

Dan Rollo commented on RIVER-447:
-

The 'River-447.patch' looks good.


 Leaked Executor Service Threads in LoadClass
 

 Key: RIVER-447
 URL: https://issues.apache.org/jira/browse/RIVER-447
 Project: River
  Issue Type: Bug
  Components: net_jini_loader
Affects Versions: River_3.0.0
 Environment: Linux with either JDK 1.7 or 1.8
Reporter: Shawn Ellis
  Labels: PreferredClassLoader, leaks, threads
 Attachments: ExecutorShutdown.patch, River-447.patch


 I am seeing an overall thread usage increase when using Apache River 3.0. I'm 
able to reproduce the problem with both JDK 1.7 and 1.8. The issue is that 
LoadClass makes use of a loaderMap that contains an Executor Service. After 10 
seconds, the loaderMap will garbage collect the Executor Service, but the 
Executor Service will not be shutdown. This leaves the Executor Service thread 
still running and waiting for work.
  How to Reproduce:
  1. Start up an Apache River 3.0 instance
  2. Have a client connect to the River instance
  3. Wait 10 seconds
  4. Have the client connect to the River instance a second time. The number
 of threads will have increased.
  The leaked threads have a stack trace similar to the one below.

"net.jini.loader.pref.PreferredClassLoader@7af8260a["httpmd://10.0.1.5:9070/reggie-dl.jar;sha=6c5b83e0caec74d5d4226dcd2c2311d29e81ac0a
 
httpmd://10.0.1.5:9070/jsk-dl.jar;sha=002bca7b77431ba20385d7ca5be8fa8ec1124a01"]_thread-0"
 #30149 prio=5 os_prio=0 tid=0x3fff68f79000 nid=0x5db9 waiting on condition [0x3ffdc344d000]
   java.lang.Thread.State: WAITING (parking)
at sun.misc.Unsafe.park(Native Method)
- parking to wait for  <0xf2955ff0> (a 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject)
at 
java.util.concurrent.locks.LockSupport.park(LockSupport.java:175)
at 
java.util.concurrent.locks.AbstractQueuedSynchronizer$ConditionObject.await(AbstractQueuedSynchronizer.java:2039)
at 
java.util.concurrent.LinkedBlockingQueue.take(LinkedBlockingQueue.java:442)
at 
java.util.concurrent.ThreadPoolExecutor.getTask(ThreadPoolExecutor.java:1067)
at 
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1127)
at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Threadrun(Thread.java:745)

Re: Summary of my external work

[Patricia Shanahan]

I think integrating back as you go along would make more sense, but the 
real issue is getting more people actively involved in the development. 
I am not the right person for that - not knowing enough about 
River-in-practice. Indeed, I would be very happy to turn over the PMC chair.


On an unrelated but important issue, there is a big discussion of 
trademarks on the board@ list. This is probably not the right time to 
have a PMC member using "river" in a URL. It makes it look as though the 
River PMC is not policing the trademark correctly.


On 1/17/2017 4:28 AM, Peter wrote:

Which changes (a subset) would you consider voting for in an Apache Release?  
Is it possible more of these features could be integrated over time?

Regards,

Peter.


Sent from my Samsung device.

  Include original message
 Original message ----
From: Patricia Shanahan <p...@acm.org>
Sent: 12/01/2017 02:17:40 am
To: dev@river.apache.org
Subject: Re: Summary of my external work

How do you envisage the future of this work?

Personally, given the volume of changes outside svn, without any review
or commit messages, I am not sure I would vote for an Apache release
based on this code. Do you have a quorum of PMC members who do feel
comfortable with this process?

On 1/11/2017 3:43 AM, Peter Firmstone wrote:

 Forked from River trunk just before 3.0 release.

* Security focused:

  o Supports updated modern cyphers, support for vulnerable
cypers removed.
  o Reimplementation of serialization, includes input validation
and defensive programming.
  o Additional SafeServiceRegistrar interface with lookup method
that allows clients to authenticate services prior to
downloading.
  o ServiceDiscoveryManager configured to use new lookup method,
without changes to API.
  o proxy jar files can contain META-INF permissions.perm files
with advisory permissions (same format as OSGi local
permissions).
  o New secure multicast discovery providers that dynamically
grant download and deserialization permission for
authenticated lookup services.
  o Phoenix now supports using TLS sockets for Registry.
  o LookupLocator now supports https unicast discovery for
firewall/proxy traversal.
* IPv6 Multicast discovery support
* Better support for Java 9, no longer accessing sun jvm
  implementation packages
  o Phoenix uses RMI Registry now instead of RegistrySunExporter
  o KerberosServerEndpoint reflectively accesses
com.sun.security.jgss.GSSUtil.createSubject, but only when
using client token delegation.  Delegation not supported on
other vendors jvm's.
* Deprecated:
  o RegistrySunExporter
  o SunJRMPExporter
  o ProxyTrust

 Currently working on a Modular Maven based build.

* Uniting packages and removing some dependencies to assist OSGi
  developers (like some package changes for non api org.apache.river
  namspaces).
  o org.apache.river.reggie.proxy
  o org.apache.river.reggie.service
* OSGi bundles with package based dependencies.


 Looking forward to donating this code to River.

 [INFO]
 
 [INFO] Reactor Summary:
 [INFO]
 [INFO] JGDMS Project . SUCCESS [
 0.712 s]
 [INFO] Module :: JGDMS Collection . SUCCESS [
 18.139 s]
 [INFO] Module :: JGDMS Jini Platform .. SUCCESS
 [01:17 min]
 [INFO] Module :: JGDMS Loader . SUCCESS [
 18.179 s]
 [INFO] Module :: JGDMS Extensible Remote Invocation ... SUCCESS [
 45.867 s]
 [INFO] Module :: JGDMS Resources ... SUCCESS [
 0.099 s]
 [INFO] Module :: JGDMS URL providers and Integrity ... SUCCESS [
 17.804 s]
 [INFO] Module :: JGDMS Activation Platform ... SUCCESS [
 23.309 s]
 [INFO] Module :: JGDMS Service DL Library  SUCCESS [
 18.373 s]
 [INFO] Module :: JGDMS Lookup Discovery Providers  SUCCESS [
 17.094 s]
 [INFO] Module :: JGDMS Service Library  SUCCESS [
 22.786 s]
 [INFO] Module :: JGDMS Service Starter  SUCCESS [
 27.622 s]
 [INFO] Module :: JGDMS SharedGroup Destroy  SUCCESS [
 22.416 s]
 [INFO] Module :: JGDMS IIOP ... SUCCESS [
 13.330 s]
 [INFO] Module :: JGDMS JRMP ... SUCCESS [
 13.663 s]
 [INFO] Module :: JGDMS Service DL Library UI Factory .. SUCCESS [
 21.488 s]
 [INFO] Module :: Jini 2.1 compatibility ... SUCCESS [
 16.572 s]
 [INFO] Module :: Outrigger  SUCCESS [
 0.017 s]
 [INFO] Module :: Outrigger Service Download classes ... SUCCESS [
 15.488 s

Re: Summary of my external work

[Patricia Shanahan]

How do you envisage the future of this work?

Personally, given the volume of changes outside svn, without any review 
or commit messages, I am not sure I would vote for an Apache release 
based on this code. Do you have a quorum of PMC members who do feel 
comfortable with this process?


On 1/11/2017 3:43 AM, Peter Firmstone wrote:

Forked from River trunk just before 3.0 release.

   * Security focused:

 o Supports updated modern cyphers, support for vulnerable
   cypers removed.
 o Reimplementation of serialization, includes input validation
   and defensive programming.
 o Additional SafeServiceRegistrar interface with lookup method
   that allows clients to authenticate services prior to
   downloading.
 o ServiceDiscoveryManager configured to use new lookup method,
   without changes to API.
 o proxy jar files can contain META-INF permissions.perm files
   with advisory permissions (same format as OSGi local
   permissions).
 o New secure multicast discovery providers that dynamically
   grant download and deserialization permission for
   authenticated lookup services.
 o Phoenix now supports using TLS sockets for Registry.
 o LookupLocator now supports https unicast discovery for
   firewall/proxy traversal.
   * IPv6 Multicast discovery support
   * Better support for Java 9, no longer accessing sun jvm
 implementation packages
 o Phoenix uses RMI Registry now instead of RegistrySunExporter
 o KerberosServerEndpoint reflectively accesses
   com.sun.security.jgss.GSSUtil.createSubject, but only when
   using client token delegation.  Delegation not supported on
   other vendors jvm's.
   * Deprecated:
 o RegistrySunExporter
 o SunJRMPExporter
 o ProxyTrust

Currently working on a Modular Maven based build.

   * Uniting packages and removing some dependencies to assist OSGi
 developers (like some package changes for non api org.apache.river
 namspaces).
 o org.apache.river.reggie.proxy
 o org.apache.river.reggie.service
   * OSGi bundles with package based dependencies.


Looking forward to donating this code to River.

[INFO]

[INFO] Reactor Summary:
[INFO]
[INFO] JGDMS Project .. SUCCESS [
0.712 s]
[INFO] Module :: JGDMS Collection . SUCCESS [
18.139 s]
[INFO] Module :: JGDMS Jini Platform .. SUCCESS
[01:17 min]
[INFO] Module :: JGDMS Loader . SUCCESS [
18.179 s]
[INFO] Module :: JGDMS Extensible Remote Invocation ... SUCCESS [
45.867 s]
[INFO] Module :: JGDMS Resources .. SUCCESS [
0.099 s]
[INFO] Module :: JGDMS URL providers and Integrity  SUCCESS [
17.804 s]
[INFO] Module :: JGDMS Activation Platform  SUCCESS [
23.309 s]
[INFO] Module :: JGDMS Service DL Library . SUCCESS [
18.373 s]
[INFO] Module :: JGDMS Lookup Discovery Providers . SUCCESS [
17.094 s]
[INFO] Module :: JGDMS Service Library  SUCCESS [
22.786 s]
[INFO] Module :: JGDMS Service Starter  SUCCESS [
27.622 s]
[INFO] Module :: JGDMS SharedGroup Destroy  SUCCESS [
22.416 s]
[INFO] Module :: JGDMS IIOP ... SUCCESS [
13.330 s]
[INFO] Module :: JGDMS JRMP ... SUCCESS [
13.663 s]
[INFO] Module :: JGDMS Service DL Library UI Factory .. SUCCESS [
21.488 s]
[INFO] Module :: Jini 2.1 compatibility ... SUCCESS [
16.572 s]
[INFO] Module :: Outrigger  SUCCESS [
0.017 s]
[INFO] Module :: Outrigger Service Download classes ... SUCCESS [
15.488 s]
[INFO] Module :: Outrigger Service Implementation . SUCCESS [
27.113 s]
[INFO] Module :: Outrigger Snaplogstore ... SUCCESS [
16.609 s]
[INFO] Module :: Lookup Service ... SUCCESS [
0.014 s]
[INFO] Module :: Reggie Service Download classes .. SUCCESS [
14.048 s]
[INFO] Module :: Reggie Service Implementation  SUCCESS [
23.095 s]
[INFO] Module :: Mahalo ... SUCCESS [
0.014 s]
[INFO] Module :: Mahalo Service Download classes .. SUCCESS [
13.727 s]
[INFO] Module :: Mahalo Service Implementation  SUCCESS [
22.967 s]
[INFO] Module :: Mercury the Event Mailbox  SUCCESS [
0.014 s]
[INFO] Module :: Mercury Service Download classes . SUCCESS [
21.990 s]
[INFO] Module :: Mercury Service Implementation ... SUCCESS [
16.790 s]
[INFO] Module :: Norm . SUCCESS [
0.014 s]
[INFO] Module :: Norm Service Download classes  SUCCESS [
20.415 s]
[INFO] Module :: Norm Service 

Access for new committer

[Patricia Shanahan]

Zsolt Kúti is now in the River committer group. Do I need to do anything 
else to grant access to the SVN repository? If so, what?

Re: River revamp

[Patricia Shanahan]

I am a little troubled by the need to do the rearranging in svn before 
copying to git. That seems to imply svn has better reorganization features.


On 11/11/2016 3:22 AM, Peter wrote:

We've got a little work to do.

Cheers,

Peter.



[https://issues.apache.org/jira/browse/INFRA-12432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Chris Lambertus updated INFRA-12432:

 Status: Waiting for user  (was: Waiting for Infra)

This will be complicated and time consuming as the svn repo doesn't
fit the usual trunk/branches/tags format. You may want to do some
consolidation or break this down into multiple git repos, for example,
river-site.git, river-rt-tools.git, etc. prior to us doing an SVN->Git
migration. If you'd rather have it all in one repo, let us know and
we'll see what we can do.



>  Apache River migration from SVN to Git - Git commit access
>  --
>
>   Key: INFRA-12432
>
URL:https://issues.apache.org/jira/browse/INFRA-12432
>   Project: Infrastructure
>Issue Type: New Git Repo
>Components: Git
>  Reporter: Peter Firmstone
>



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)





On 11/11/2016 3:23 PM, Niclas Hedhman wrote:

File a JIRA ticket on INFRA project should work.

Specify which SVN subtree to migrate into each repository.



On Fri, Nov 11, 2016 at 1:15 PM, Patricia Shanahan<p...@acm.org>  wrote:


What is the current process for getting a writable GIT repository within
ASF?


On 11/10/2016 8:25 PM, Peter wrote:


Thinking about how to proceed with code and repo...

* I want to bring code in from an existing git repo and keep commit
history (I'm the only committer).  Branched off a recent version of
River
trunk.
* We want to change to using a git repo for River.
* Start building maven style modules from the ground up, starting with
JERI at low level.
* Separate out the qa test suite (integration tests), which is an ant
build that only depends on jars from river build.
* Where should jtreg test suite ( unit and regression tests) go?  Maybe
with each relevant module?
* junit tests with appropriate module...

Thoughts / suggestions?

Regards,

Peter.

Sent from my Samsung device.

   Include original message
 Original message 
From: Peter<j...@zeus.net.au>
Sent: 06/11/2016 08:23:06 pm
To: dev@river.apache.org
Subject: Re: River revamp

Yes same pattern, some details are different for security reasons,
additional support is required for lower level protocols as object
endpoints.

Also, for example, devices were on a 6LowPAN network, different
types of
devices would subscribe to different multicast groups, to minimise
their
responses, since some devices may rely on battery power, we don't want
them to announce their presence or respond unnecessarily as that wastes
power.

There are a number of new IoT protocols being developed, I think we'll
need to provide some support for some to start with.

AMQP is another interesting protocol.

On the discovery side, in order to make a connection, the multicast
response will need to contain the application layer name, transport
layer name, contact address and port, eg:  MQTT, TCP, IP address:port.
Typically the nework layer will define the method of multicast.

Cheers,

Peter.

On 6/11/2016 1:05 PM, Niclas Hedhman wrote:


  Ok, so this is more or less classic "surrogate" setup with JINI,
right,
  with some additional SEC stuff, right?

  And that is a cool way to achieve interoperability with smaller
devices
  without ability to run a JVM, especially the original dream where
devices
  don't know about each other ahead of time (except by some interface)

  I also see value where "IoT Service" doesn't bother with "Service
  Registrar" in the "Jini sense" and the "IoT Device" only
participate in
  "Discovery" and then get a secure/trusted channel, onto which a
  light-weight protocol, such as MQTT or CoAP, can be funneled in
either
  direction.



  On Sat, Nov 5, 2016 at 2:26 PM, Peter<j...@zeus.net.au>   wrote:

  Hmm lets try Ascii, hope line wrapping doesn't wreck it.


   |<--| Multicast request
  Multicast   |   |
  response|-->| Connection&   auth
   |   | to discovered address
  RPCSEC_GSS  |<--|
  auth|-->| RPCSEC_GSS Auth
   |   | success, request
   |   | bytes containing
   |   | service proxy
   |  Register service |
   |proxy&   attributes |--->|
Registration
   |  Mange reg lease  |<

Re: River revamp

[Patricia Shanahan]

C equivalent of Java RMI.

 Cheers,

 Peter.

 On 5/11/2016 10:32 AM, Niclas Hedhman wrote:


 Sorry, I get the feeling that too much detail thinking is still in your
 head. Hard for me to follow your thought process. A simple picture (ascii
 art would do) would go a long way...

 Niclas

 On Sat, Nov 5, 2016 at 8:04 AM, Peter<j...@zeus.net.au>   wrote:

 Thinking about C and power constrained devices, how about the following:

 * Write an ONC RPC java compiler, to create java code (instead of C)
 client stubs.

 * Provide support for TLS and constraints.

 * Provide an IPv6 constrained device announcement (C) and discovery
 (Java)
 utilities.  Create a standard so other languages can be supported by
 others.

 * Write a java utility and service that manages proxies, registers
 discovered constrained devices with a lookup service and manages it's
 lease.  This utility can generate attributes (from Configuration) and
 provide a bootstrap proxy (service) to allow clients to authenticate and
 obtain the smart proxy used to communicate directly with the device.

 * Provide an interface for clients to notify the utility service when a
 device is down.

 Regards,

 Peter.

 Sent from my Samsung device.

 Include original message
  Original message 
 From: Zsolt Kúti<la.ti...@gmail.com>
 Sent: 03/11/2016 05:37:45 pm
 To: dev@river.apache.org
 Subject: Re: River revamp

 A small footprint implementation of Jini's lookup service written in C,
 fully JCK compliant.
 http://www.psinapticcom/link_files/PsiNapticTelematics.pdf


 A few years ago being involved in developing a streelighting management
 system I tried to access them to no avail.

 On Thu, Nov 3, 2016 at 8:09 AM, Peter<j...@zeus.net.au>   wrote:

 I've been conaidering that.  It should be possible to implement service

 discovery in C, any serialized java bytes required for a proxy could be
 stored on the device.

 So these devices are services, but not clients.

 Will respond with more soon

 Regards,

 Peter.

 Sent from my Samsung device.

 Include original message
  Original message 
 From: Niclas Hedhman<nic...@hedhman.org>
 Sent: 03/11/2016 12:39:33 pm
 To: dev@river.apache.org
 Subject: Re: River revamp

 "IoT" is a term that for this discussion is a bit too wide. The
 "thermostat" runs with a kB-sized microcontroller and is


 struggling to get


 security features in at all, and the "home router" is typically (still)
 running from a 4-8MByte flash, which is impossible to even get a Java
 ME
 onto, so there is a lot of challenges when using "IoT"


 as a blanket term.


 So, I think a couple of concrete, do-able, use-cases
 need to be highlighted
 as examples, maybe a kind of "blue print" paper on how to
 do it with River.

 I totally agree that the "mothership" model is
 outrageous from a consumer's
 perspective, a nasty vendor lock-in, that all vendors are


 pushing for and


 all consumers/users need to fight the best we can.

 A very active home automation project is called "OpenHAB", a flurry of
 activity, connecting just about everything from your thermostat to your
 dog's toys. I have not looked closely at it, don't even know if it is a
 Java project as such, but it is one of the most active projects in the
 field of Home IoT.

 Cheers
 Niclas

 On Wed, Nov 2, 2016 at 10:41 PM, Patricia Shanahan<p...@acm.org>
 wrote:

 I think for this to work it is necessary to find out
 where IoT people hang


 out, and discuss it there Do they already have a plan for a secure
 framework?

 As a potential IoT user I'm looking for two things:

 1. Security.

 2. Server independence.

 I don't want my thermostat to stop working if a server I don't control
 goes down or is taken out of service for any reason.

 I think River may be a good basis for those features.


 On 11/2/2016 7:22 AM, Bryan Thompson wrote:

 I look at this as open source for secure IoT.  The
 need for security in

 IoT

 has been aptly demonstrated by recent DDOS


 attaches based on compromised
 devices.

 I do feel that interop is critical to success here.

 Do we have any lurkers from the IoT manufacturing


 space here?  People or
 companies willing to invest time and resources for
 a secure IOT platform?
 Bryan

 On Wednesday, November 2, 2016, Peter<j...@zeus.net.au>   wrote:

 Utilising most of the existing discovery code, we could use ipv6


 multicast, for an exported remote object (service).

 Then create a new class called RemoteDiscovery to discover a service
 dynamically, based on a name

 So you export a service and it becomes dynamically discoverable.

 It's not going to step on any Jini discovery lookup


 stuff and it's going

 to be easily deployed by new users.

 Then once users realise there's more on offer they


 can take advantage as

 their understanding develops.

 Cheers,

 Peter.

 Sent from my Samsung device.

 Include original

Re: Draft Board Report

[Patricia Shanahan]

+1

On 11/6/2016 2:14 PM, Patricia Shanahan wrote:

## Description:

 - Apache River software provides a standards-compliant JINI service.

## Issues:

 - There are no issues requiring board attention at this time.

## Activity:

 - Wrapped up River-3.0.0, released this quarter.
 - Continued discussion of River's future direction.

## Health report:

 - The ongoing future directions discussion has progressed from high
level strategy to discussion of specific features and use-cases.

 - Two PMC members resigned during the quarter, a concern because at
this point there is no stream of incoming developers to provide new
committers and PMC members. Attracting new developers will be difficult
until the future direction is firmed up and made visible.

## PMC changes:

 - Currently 11 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Bryan Thompson on Sun Aug 30 2015
 - Two PMC members resigned (went emeritus) during the quarter, Simon
IJskes (2016-10-23), and Tom Hobbs (2016-08-19)

## Committer base changes:

 - Currently 15 committers.
 - No new committers added in the last 3 months
 - Last committer addition was Dan Creswell at Mon Jun 20 2016

## Releases:

 - River-3.0.0 was released on Wed Oct 05 2016

## Mailing list activity:

 - The increased activity level in the dev@ mailing list is due to the
combination of completing a release and the future direction discussion.

 - dev@river.apache.org:
- 94 subscribers (up 0 in the last 3 months):
- 128 emails sent to list (74 in previous quarter)

 - u...@river.apache.org:
- 95 subscribers (down -2 in the last 3 months):
- 3 emails sent to list (3 in previous quarter)


## JIRA activity:

 - 1 JIRA tickets created in the last 3 months
 - 0 JIRA tickets closed/resolved in the last 3 months

Draft Board Report

[Patricia Shanahan]

## Description:

 - Apache River software provides a standards-compliant JINI service.

## Issues:

 - There are no issues requiring board attention at this time.

## Activity:

 - Wrapped up River-3.0.0, released this quarter.
 - Continued discussion of River's future direction.

## Health report:

 - The ongoing future directions discussion has progressed from high 
level strategy to discussion of specific features and use-cases.


 - Two PMC members resigned during the quarter, a concern because at 
this point there is no stream of incoming developers to provide new 
committers and PMC members. Attracting new developers will be difficult 
until the future direction is firmed up and made visible.


## PMC changes:

 - Currently 11 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Bryan Thompson on Sun Aug 30 2015
 - Two PMC members resigned (went emeritus) during the quarter, Simon 
IJskes (2016-10-23), and Tom Hobbs (2016-08-19)


## Committer base changes:

 - Currently 15 committers.
 - No new committers added in the last 3 months
 - Last committer addition was Dan Creswell at Mon Jun 20 2016

## Releases:

 - River-3.0.0 was released on Wed Oct 05 2016

## Mailing list activity:

 - The increased activity level in the dev@ mailing list is due to the 
combination of completing a release and the future direction discussion.


 - dev@river.apache.org:
- 94 subscribers (up 0 in the last 3 months):
- 128 emails sent to list (74 in previous quarter)

 - u...@river.apache.org:
- 95 subscribers (down -2 in the last 3 months):
- 3 emails sent to list (3 in previous quarter)


## JIRA activity:

 - 1 JIRA tickets created in the last 3 months
 - 0 JIRA tickets closed/resolved in the last 3 months

Re: Future of River

[Patricia Shanahan]

To get the feedback you need, you have to reach a far wider audience 
than dev@


Including the user@ list is necessary, but far from sufficient.

You need to identify the potential users for your vision, find out where 
they discuss things, and meet with them there. Is there a gap that a 
reworked River would fill well?


Think in terms of a business plan. You will be asking people to invest 
time and energy, not money, but it is still an investment that can only 
be motivated by an unmet need.


On 10/8/2016 5:35 AM, Peter wrote:

Thanks Patricia.

It would be nice if we could hear a little about what people want for
River going forward.

Regards,

Peter.


On 7/10/2016 5:08 PM, Patricia Shanahan wrote:

This message is to change the subject line. These comments are far too
important to be mistaken for being part of wrapping up the 3.0 release.

On 10/6/2016 10:57 PM, Peter wrote:

To answer my own question, a list of items that require attention:
1. Modular build.
2. Improved IPv6 support
3. Update to TLS v1.2 and update constraints.
4. Investigate Maven codebase provisioning, do we need to use the
Maven ClassWorlds ClassLoaders, what about proxy identity?
5. Fix security.
6. Update website.
7. Development guide for River devs.
8. Redundancy?
9. Update user docs, perhaps update Jan Newmarch's book?

Cheers,

Peter.




Sent from my Samsung device.

  Include original message
 Original message 
From: Peter <j...@zeus.net.au>
Sent: 07/10/2016 12:25:01 pm
To: dev@river.apache.org
Subject: Re: [VOTE] Release Apache River 3.0.0

The question is of course where to next?

As people are aware I've been working on addressing security issues and
how to make River better and more secure.  I've been working on this
outside the project because my attempts to discuss it caused heated
arguments.  I figured that if I could demonstrate a working example that
people could try out, it could allevieate any misunderstandings that may
have developed due to language or culture differences.

River's approach to security (a result of the Jini Davis project) is
quite complex and contains a flaw borne out of two limitations around
the time it was developed:

   1. The assumption that the Java sandbox and java serialization was
  secure (we know today this isn't the case).
   2. Interfaces cannot be changed (no longer true with java 8), in this
  case ServiceRegistrar was designed prior to the later added on
  security features.

What's wrong with River's approach?

Answer:  It validates and authenticates after downloading code and
deserializing untrusted data, using the proxy trust framework, by asking
an already downloaded and deserialized service proxy for a bootstrap
proxy, the client code then uses the boostrap proxy to determine if the
service proxy can be trusted.  Too little too late.  Why not instead
recieve a bootstrap proxy, deserialized using input validation, without
code download, authenticate the remote endpoint, then ask the bootstrap
proxy for the service proxy?

The trouble with the existing approach today is an attacker has
opportunity to take control of a computer using deserialization alone.
For those who think a network firewall is sufficient protection and the
flawed security design isn't an issue on local networks, even in air
gapped networks, an attacker can leave a USB key in a car park
containing malware that looks for network transmissions that contain
java serialized data, hoping that someone will pick it up and plug it
into their pc, the malware will send serial data containing a gadget
attack to a listening network port that accepts java serial data and
take over the infected computer.

All network communications using standard java serialization must be
both authenticated and encrypted, prior to reading in any data to ensure
that the data is trusted.

I think we can all accept that these vulnerabilities exist and googling
java serialization gadget attacks should convince even the most doubtful
sceptic.

Relevant links:
https://www.apache.org/dev/committers.html#apache-way
http://www.apache.org/security/committers.html

I would like the opportunity to explain more, and go through working
examples of solutions before we start arguing about whether we should
solve these problems.  Anyone reading the Apache Way will realise that
security is a mandatory feature of Apache Software and therefore we
should consider how we should fix existing security issues in River and
while doing so, take the opportunity to make security simpler to
implement.  Arguments should not be about the relevance of security
issues, but rather the suitablility of solutions.

Regards,

Peter.

On 6/10/2016 2:04 PM, Bryan Thompson wrote:

 Excellent.  A great step.
 Bryan

 On Wednesday, October 5, 2016, Peter
Firmstone<peter.firmst...@zeus.net.au>
 wrote:


 Results:

 3 binding votes
 1 non binding

 None against.

 The artifacts have been published, we need to wait 24 hours before
 announcin

Re: Fwd: [jira] [Updated] (INFRA-12432) Apache River migration from SVN to Git - Git commit access

[Patricia Shanahan]

I may have missed something, but I didn't see a proposal for dealing 
with the comment:


"This will be complicated and time consuming as the svn repo doesn't fit 
the usual trunk/branches/tags format. You may want to do some 
consolidation or break this down into multiple git repos, for example, 
river-site.git, river-rt-tools.git, etc. prior to us doing an SVN->Git 
migration. If you'd rather have it all in one repo, let us know and 
we'll see what we can do."


What is the response to this?

On 9/29/2016 12:39 AM, Peter wrote:

Are there any remaining objections to git migration?

If so, lets discuss.

Regards,

Peter.

Sent from my Samsung device.

  Include original message
 Original message 
From: Daniel Takamori (JIRA) 
Sent: 29/09/2016 03:52:20 am
To: j...@zeus.net.au
Subject: [jira] [Updated] (INFRA-12432) Apache River migration from SVN to Git 
- Git commit access


 [ 
https://issues.apache.org/jira/browse/INFRA-12432?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Takamori updated INFRA-12432:

Status: Waiting for user  (was: Waiting for Infra)


 Apache River migration from SVN to Git - Git commit access
 --

 Key: INFRA-12432
 URL: https://issues.apache.org/jira/browse/INFRA-12432
 Project: Infrastructure
  Issue Type: New Git Repo
  Components: Git
Reporter: Peter Firmstone

Re: Fwd: Call For Papers - Deadline: Oct 10; Int'l Conf on Internet of Things (CSCI-ISOT: Dec 15-17, 2016, Las Vegas); Publisher: IEEE CPS

[Patricia Shanahan]

As we get closer, I can use some academic contacts to check which 
conferences would be best for us next year.


On 9/21/2016 12:28 AM, Peter wrote:


It's probably a little early at this stage.

River 3.0 addresses a number of long standing issues, but still needs to 
address security and add support for ipv6 multicast.

Should we be planning to write a paper for  the symposium next year?

Regards,

Peter.

Sent from my Samsung device.

  Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 21/09/2016 12:31:36 pm
To: dev@river.apache.org
Subject: Fwd: Call For Papers - Deadline: Oct 10; Int'l Conf on Internet of 
Things (CSCI-ISOT: Dec 15-17, 2016, Las Vegas); Publisher: IEEE CPS

Any thoughts on writing papers about River and IoT? I don't think we are
quite there yet, but it is something to keep in mind.


 Forwarded Message 
Subject: Call For Papers - Deadline: Oct 10; Int'l Conf on Internet of
Things (CSCI-ISOT: Dec 15-17, 2016, Las Vegas); Publisher: IEEE CPS
Date: Tue, 20 Sep 2016 22:29:19 -0400
From: IoT <han...@american-cse.org>
To: pshan...@cs.ucsd.edu


   CALL  FOR  PAPERS
  Paper Submission Deadline: October 10, 2016

 The 2016 International Symposium on Internet of Things
  & Internet of Everything (CSCI-ISOT)
  December 15-17, 2016, Las Vegas, USA

   Publisher: IEEE CPS & IEEE Xplore
   http://americancse.org/events/csci2016/Symposiums/csci-isot
 http://www.americancse.org/events/csci2016   (Accepted
papers will be published in the proceedings of The
   2016 International Conference on Computational Science and
   Computational Intelligence, CSCI; by IEEE CPS & IEEE Xplore)


PUBLISHER:

CPS:
http://www.ieee.org/publications_standards/publications/services/comp_society.html

All accepted papers of the symposium will be published by Conference
Publishing Services of IEEE Computer Society (CPS) in the proceedings
of The 2016 International Conference on Computational Science and
Computational Intelligence (CSCI). Past conference proceedings can be
accessed via IEEE Xplore Digital Library at:
Volume I (2014):
http://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=6822065Volume
II (2014): http://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=6822285
Volume (2015):
http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=7420813
and via ACM Digital Library at: http://dl.acm.org/
The proceedings will be indexed in science citation databases that track
citation frequency/data. Extended versions of selected papers of the
symposium will also appear in journals and edited research books.


SCOPE AND LIST OF TOPICS:

O. Intelligent Systems for IoT
O. Environmental Monitoring
O. Energy Aware Systems and Efficiency
O. Machine to Machine/Device Communications
O. Network Design and Architecture
O. Networking and Communication Protocols
O. Wireless Systems and Applications
O. Infrastructure Management
O. IoT and e-Government, e-Commerce, e-Science and Novel Technologies
O. IoT and Big Data
O. Home Automation
O Software Architecture, Middleware, and Frameworks
O. Services Computing
O. Health Informatics as a Service
O. Financial Software as a Service
O. Business Process as a Service
O. Natural Science as a Service
O. Integration as a Service
O. Large Scale Deployments
O. Mobile Services
O. Knowledge Management
O. Location-awareness
O. Security and Privacy
O. Social Implications of IoT
O. Technological focus for Smart Environments
O. Smart City Case Studies
O. Data Analysis and Visualization
O. Architecture for secure and interactive IoT
O. Intelligent Infrastructure and Guidance Systems
O. Sensor Networks, Remote Diagnosis and Development
O. Transportation Management
O. Pattern Recognition and Recommendation Systems
O. Green Computing
O. Smart City and Novel Methodologies
O. Data Processing Techniques
O. Analytics and Statistical Methods
O. Data Center Enabled Technologies
O. Sensor, Wireless Technologies and APIs
O. Networking and Social Networks
O. IoT in Social Sciences
O. Education and Learning
O. Business, Finance and Management
O. Open data: Issues, Services and Solutions
O. Earth Science Simulation and Processing
O. Practical Adoption of IoT and Case Studies
O. Healthcare Services and Health Informatics
O. Cloud, Grid and Cluster Computing
O. Emerging IoT


INVITATION:

You are invited to submit a paper for consideration. All accepted papers
will be published by IEEE CPS (+ IEEE Xplore) in the proceedings of The
2016 International Conference on Computational Science and Computational
Intelligence (CSCI). The proceedings will be indexed in scienc

Fwd: Call For Papers - Deadline: Oct 10; Int'l Conf on Internet of Things (CSCI-ISOT: Dec 15-17, 2016, Las Vegas); Publisher: IEEE CPS

[Patricia Shanahan]

Any thoughts on writing papers about River and IoT? I don't think we are 
quite there yet, but it is something to keep in mind.



 Forwarded Message 
Subject: Call For Papers - Deadline: Oct 10; Int'l Conf on Internet of 
Things (CSCI-ISOT: Dec 15-17, 2016, Las Vegas); Publisher: IEEE CPS

Date: Tue, 20 Sep 2016 22:29:19 -0400
From: IoT 
To: pshan...@cs.ucsd.edu


  CALL  FOR  PAPERS
 Paper Submission Deadline: October 10, 2016

The 2016 International Symposium on Internet of Things
 & Internet of Everything (CSCI-ISOT)
 December 15-17, 2016, Las Vegas, USA

  Publisher: IEEE CPS & IEEE Xplore
  http://americancse.org/events/csci2016/Symposiums/csci-isot 
http://www.americancse.org/events/csci2016   (Accepted 
papers will be published in the proceedings of The

  2016 International Conference on Computational Science and
  Computational Intelligence, CSCI; by IEEE CPS & IEEE Xplore)


PUBLISHER:

   CPS: 
http://www.ieee.org/publications_standards/publications/services/comp_society.html 


   All accepted papers of the symposium will be published by Conference
   Publishing Services of IEEE Computer Society (CPS) in the proceedings
   of The 2016 International Conference on Computational Science and
   Computational Intelligence (CSCI). Past conference proceedings can be
   accessed via IEEE Xplore Digital Library at:
   Volume I (2014): 
http://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=6822065Volume 
II (2014): http://ieeexplore.ieee.org/xpl/tocresult.jsp?isnumber=6822285 
   Volume (2015): 
http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=7420813 
and via ACM Digital Library at: http://dl.acm.org/

   The proceedings will be indexed in science citation databases that track
   citation frequency/data. Extended versions of selected papers of the
   symposium will also appear in journals and edited research books.


SCOPE AND LIST OF TOPICS:

   O. Intelligent Systems for IoT
   O. Environmental Monitoring
   O. Energy Aware Systems and Efficiency
   O. Machine to Machine/Device Communications
   O. Network Design and Architecture
   O. Networking and Communication Protocols
   O. Wireless Systems and Applications
   O. Infrastructure Management
   O. IoT and e-Government, e-Commerce, e-Science and Novel Technologies
   O. IoT and Big Data
   O. Home Automation
   O. Software Architecture, Middleware, and Frameworks
   O. Services Computing
   O. Health Informatics as a Service
   O. Financial Software as a Service
   O. Business Process as a Service
   O. Natural Science as a Service
   O. Integration as a Service
   O. Large Scale Deployments
   O. Mobile Services
   O. Knowledge Management
   O. Location-awareness
   O. Security and Privacy
   O. Social Implications of IoT
   O. Technological focus for Smart Environments
   O. Smart City Case Studies
   O. Data Analysis and Visualization
   O. Architecture for secure and interactive IoT
   O. Intelligent Infrastructure and Guidance Systems
   O. Sensor Networks, Remote Diagnosis and Development
   O. Transportation Management
   O. Pattern Recognition and Recommendation Systems
   O. Green Computing
   O. Smart City and Novel Methodologies
   O. Data Processing Techniques
   O. Analytics and Statistical Methods
   O. Data Center Enabled Technologies
   O. Sensor, Wireless Technologies and APIs
   O. Networking and Social Networks
   O. IoT in Social Sciences
   O. Education and Learning
   O. Business, Finance and Management
   O. Open data: Issues, Services and Solutions
   O. Earth Science Simulation and Processing
   O. Practical Adoption of IoT and Case Studies
   O. Healthcare Services and Health Informatics
   O. Cloud, Grid and Cluster Computing
   O. Emerging IoT


INVITATION:

   You are invited to submit a paper for consideration. All accepted papers
   will be published by IEEE CPS (+ IEEE Xplore) in the proceedings of The
   2016 International Conference on Computational Science and Computational
   Intelligence (CSCI). The proceedings will be indexed in science citation
   databases that track citation frequency/data. Extended versions of
   selected papers of the conference will also appear in journals and
   edited research books (Springer, Elsevier, BMC, ...). The published
   proceedings can be accessed via IEEE CPS and other Digital libraries.


INSTRUCTIONS FOR SUBMISSION OF PAPERS FOR EVALUATION:

   All accepted papers of this symposium will be published by IEEE CPS:

http://www.ieee.org/publications_standards/publications/services/comp_society.html 
   as part of the proceedings of The 2016 International Conference on

   Computational Science and Computational Intelligence (CSCI'16). Past
   year's CSCI proceedings are indexed into IEEE Xplore Digital Library and
   can be accessed via:
   Volume I (2014): 

Re: [VOTE] Release Apache River 3.0.0

[Patricia Shanahan]

+1 Binding.

On 9/2/2016 6:18 PM, Peter wrote:

River 3.0.0 is the latest release of Apache River.

The release artifacts and signatures for the release candidate are
available at:
https://dist.apache.org/repos/dist/dev/river/

[  ] +1: I vote in favour of this release.
[  ] +0: I am not against this release.
[  ] -1: I am against this release (please provide discussion and reasons)

The vote will remain open for 28 days, expiring on the 1st of October 2016.

Regards,

Peter.

Re: QA test failure River 3.0

[Patricia Shanahan]

Good news. I fully updated my Ubuntu box, and it subsequently did a 
completely clean qa.run.


I just need to do the signature checks, and I'll be ready to vote in 
favor of River 3.0.


On 09/17/2016 09:57 PM, Peter wrote:

Looks like a problem with the IcedTea jdk when retrieving the 
AccessControlContext.  River appears to have handled the socket closure 
properly.

The stress test doesn't stress River much, it uses TaskManager which causes 
contention within  the test code.  TaskManager is only retained for backward 
compatibility and some tests that still use it.

Perhaps try installing Oracle's jdk.

Alternatively, there's a file here:

qa/src/org/apache/river/test/resources (I think from memory).  It called 
qa_defaults (I think again from memory).  Will confirm later.

In this file, you can enable core dumps, then a back trace might reveal the 
actual problem.

Thanks & regards,

Peter.

Sent from my Samsung device.
  
   Include original message

 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 18/09/2016 08:47:43 am
To: dev@river.apache.org
Subject: QA test failure River 3.0

Is this an actual problem with River 3.0, or just an indication that my
Linux box is not tough enough for this stress test?

   [java] Running
org/apache/river/test/impl/outrigger/matching/StressTestInterleavedWithShutdown.td
   [java] Time is Sat Sep 17 12:36:29 PDT 2016
   [java] Starting test in separate process with command:
   [java] /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java
-Djava.security.manager=org.apache.river.api.security.CombinerSecurityManager
-Djava.security.policy=file:/River_3.0/apache-river-3.0.0/qa/harness/policy/defaulttest.policy
'-Djava.rmi.server.codebase=http://pats-acer1:9082/qa1-outrigger-dl.jar
http://pats-acer1:9082/qa1-share-dl.jar' -cp
/River_3.0/apache-river-3.0.0/qa/lib/jiniharness.jar:/River_3.0/apache-river-3.0.0/qa/lib/jinitests.jar:/River_3.0/apache-river-3.0.0/lib/jsk-platform.jar:/River_3.0/apache-river-3.0.0/lib/jsk-lib.jar:/River_3.0/apache-river-30.0/lib/high-scale-lib.jar:/River_3.0/apache-river-3.0.0/lib/custard-apple-1.0.3.jar
-ea -esa
-Djava.ext.dirs=/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext:/usr/java/packages/lib/ext:/River_3.0/apache-river-3.0.0/qa/lib-ext:/River_3.0/apache-river-3.0.0/lib-ext
-Dorg.apache.river.jsk.port=9080 -Dorg.apache.river.qa.port=9081
-Dorg.apache.river.jsk.home=/River_3.0/apache-river-3.0.0
-Dorg.apache.river.qa.home=/River_3.0/apache-river-3.0.0/qa
-Dorg.apacheriver.qa.harness.harnessJar=/River_3.0/apache-river-3.0.0/qa/lib/jiniharness.jar
-Dorg.apache.river.qa.harness.testJar=/River_3.0/apache-river-3.0.0/qa/lib/jinitests.jar
-Dorg.apache.river.qa.harness.runjiniserver=true
-Dorg.apache.river.qa.harness.runkitserver=true
-Djava.security.properties=file:/River_3.0/apache-river-3.0.0/qa/harness/trust/dynamic-policy.properties
-Dorg.apache.river.qa.harness.testhosts=
-Djava.util.logging.config.file=/River_3.0/apache-river-3.0.0/qa/src/org/apache/river/test/resources/qa1.logging
-Djava.rmi.server.useCodebaseOnly=false
-Dnet.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse=true
-Dorg.apache.river.test.home=/River_3.0/apache-river-3.0.0/qa
-Dorg.apache.river.test.port=9082
-Dorg.apache.river.qa.harness.policies=file:/River_3.0/apache-river-3.0.0/qa/src/org/apache/river/test/resources/jinitest.policy
-Djava.ext.dirs=/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext:/usr/java/packages/lib/ext:/River_3.0/apache-river-3.0.0/qa/lib-ext:/River_30/apache-river-3.0.0/lib-ext
org.apache.river.qa.harness.MasterTest
org/apache/river/test/impl/outrigger/matching/StressTestInterleavedWithShutdown.td

   [java]
   [java] TIME: 12:36:30 PM
   [java]
   [java] MasterTest.doTest INFO:
   [java] == CALLING CONSTRUCT()
==
   [java]
   [java] MasterTest.doTest INFO:
   [java] === CALLING RUN()
===
   [java]
   [java] NonActGrp-out: #
   [java] NonActGrp-out: # A fatal error has been detected by the
Java Runtime Environment:
   [java] NonActGrp-out: #
   [java] NonActGrp-out: #  SIGSEGV (0xb) at pc=0x7f6f16b24fdc,
pid=934, tid=140113942001408
   [java] NonActGrp-out: #
   [java] NonActGrp-out: # JRE version: OpenJDK Runtime Environment
(7.0_95) (build 1.7.0_95-b00)
   [java] NonActGrp-out: # Java VM: OpenJDK 64-Bit Server VM
(24.95-b01 mixed mode linux-amd64 compressed oops)
   [java] NonActGrp-out: # Derivative: IcedTea 2.6.4
   [java] NonActGrp-out: # Distribution: Ubuntu 14.04.3 LTS, package
7u95-2.6.4-0ubuntu0.14.04.1
   [java] NonActGrp-out: # Problematic frame:
   [java] NonActGrp-out: # V  [libjvm.so+0x62dfdc]
JVM_GetStackAccessControlContext+0x1fc
   [java] NonActGrp-out: #
   [java] NonActGrp-out: # Failed to write core dump. Core dumps have
been disabled. To enable core dumping, try "ulimit -c unlimited&q

QA test failure River 3.0

[Patricia Shanahan]

Is this an actual problem with River 3.0, or just an indication that my 
Linux box is not tough enough for this stress test?


 [java] Running 
org/apache/river/test/impl/outrigger/matching/StressTestInterleavedWithShutdown.td

 [java] Time is Sat Sep 17 12:36:29 PDT 2016
 [java] Starting test in separate process with command:
 [java] /usr/lib/jvm/java-7-openjdk-amd64/jre/bin/java 
-Djava.security.manager=org.apache.river.api.security.CombinerSecurityManager 
-Djava.security.policy=file:/River_3.0/apache-river-3.0.0/qa/harness/policy/defaulttest.policy 
'-Djava.rmi.server.codebase=http://pats-acer1:9082/qa1-outrigger-dl.jar 
http://pats-acer1:9082/qa1-share-dl.jar' -cp 
/River_3.0/apache-river-3.0.0/qa/lib/jiniharness.jar:/River_3.0/apache-river-3.0.0/qa/lib/jinitests.jar:/River_3.0/apache-river-3.0.0/lib/jsk-platform.jar:/River_3.0/apache-river-3.0.0/lib/jsk-lib.jar:/River_3.0/apache-river-3.0.0/lib/high-scale-lib.jar:/River_3.0/apache-river-3.0.0/lib/custard-apple-1.0.3.jar 
-ea -esa 
-Djava.ext.dirs=/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext:/usr/java/packages/lib/ext:/River_3.0/apache-river-3.0.0/qa/lib-ext:/River_3.0/apache-river-3.0.0/lib-ext 
-Dorg.apache.river.jsk.port=9080 -Dorg.apache.river.qa.port=9081 
-Dorg.apache.river.jsk.home=/River_3.0/apache-river-3.0.0 
-Dorg.apache.river.qa.home=/River_3.0/apache-river-3.0.0/qa 
-Dorg.apache.river.qa.harness.harnessJar=/River_3.0/apache-river-3.0.0/qa/lib/jiniharness.jar 
-Dorg.apache.river.qa.harness.testJar=/River_3.0/apache-river-3.0.0/qa/lib/jinitests.jar 
-Dorg.apache.river.qa.harness.runjiniserver=true 
-Dorg.apache.river.qa.harness.runkitserver=true 
-Djava.security.properties=file:/River_3.0/apache-river-3.0.0/qa/harness/trust/dynamic-policy.properties 
-Dorg.apache.river.qa.harness.testhosts= 
-Djava.util.logging.config.file=/River_3.0/apache-river-3.0.0/qa/src/org/apache/river/test/resources/qa1.logging 
-Djava.rmi.server.useCodebaseOnly=false 
-Dnet.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse=true 
-Dorg.apache.river.test.home=/River_3.0/apache-river-3.0.0/qa 
-Dorg.apache.river.test.port=9082 
-Dorg.apache.river.qa.harness.policies=file:/River_3.0/apache-river-3.0.0/qa/src/org/apache/river/test/resources/jinitest.policy 
-Djava.ext.dirs=/usr/lib/jvm/java-7-openjdk-amd64/jre/lib/ext:/usr/java/packages/lib/ext:/River_3.0/apache-river-3.0.0/qa/lib-ext:/River_3.0/apache-river-3.0.0/lib-ext 
org.apache.river.qa.harness.MasterTest 
org/apache/river/test/impl/outrigger/matching/StressTestInterleavedWithShutdown.td 


 [java]
 [java] TIME: 12:36:30 PM
 [java]
 [java] MasterTest.doTest INFO:
 [java] == CALLING CONSTRUCT() 
==

 [java]
 [java] MasterTest.doTest INFO:
 [java] === CALLING RUN() 
===

 [java]
 [java] NonActGrp-out: #
 [java] NonActGrp-out: # A fatal error has been detected by the 
Java Runtime Environment:

 [java] NonActGrp-out: #
 [java] NonActGrp-out: #  SIGSEGV (0xb) at pc=0x7f6f16b24fdc, 
pid=934, tid=140113942001408

 [java] NonActGrp-out: #
 [java] NonActGrp-out: # JRE version: OpenJDK Runtime Environment 
(7.0_95) (build 1.7.0_95-b00)
 [java] NonActGrp-out: # Java VM: OpenJDK 64-Bit Server VM 
(24.95-b01 mixed mode linux-amd64 compressed oops)

 [java] NonActGrp-out: # Derivative: IcedTea 2.6.4
 [java] NonActGrp-out: # Distribution: Ubuntu 14.04.3 LTS, package 
7u95-2.6.4-0ubuntu0.14.04.1

 [java] NonActGrp-out: # Problematic frame:
 [java] NonActGrp-out: # V  [libjvm.so+0x62dfdc] 
JVM_GetStackAccessControlContext+0x1fc

 [java] NonActGrp-out: #
 [java] NonActGrp-out: # Failed to write core dump. Core dumps have 
been disabled. To enable core dumping, try "ulimit -c unlimited" before 
starting Java again

 [java] NonActGrp-out: #
 [java] NonActGrp-out: # An error report file with more information 
is saved as:
 [java] NonActGrp-out: # 
/River_3.0/apache-river-3.0.0/qa/hs_err_pid934.log

 [java] NonActGrp-out: [thread 140113841469184 also had an error]
 [java] NonActGrp-out: Compiled method (nm)  128380  486 n   
java.security.AccessController::getStackAccessControlContext (native)
 [java] NonActGrp-out:  total in heap 
[0x7f6f0d12c810,0x7f6f0d12cb98] = 904
 [java] NonActGrp-out:  relocation 
[0x7f6f0d12c930,0x7f6f0d12c990] = 96
 [java] NonActGrp-out:  main code 
[0x7f6f0d12c9a0,0x7f6f0d12cb98] = 504

 [java] NonActGrp-out: #
 [java] NonActGrp-out: # If you would like to submit a bug report, 
please include
 [java] NonActGrp-out: # instructions on how to reproduce the bug 
and visit:

 [java] NonActGrp-out: #   http://icedtea.classpath.org/bugzilla
 [java] NonActGrp-out: #
 [java] java.rmi.UnmarshalException: exception unmarshalling 
response; nested exception is:
 [java] java.io.IOException: I/O error reading 

Testing 3.0

[Patricia Shanahan]

What is the best/latest set of instructions for running the River QA tests?

Re: release artifacts

[Patricia Shanahan]

Thanks. I'll go ahead with my own build and test.

On 9/4/2016 6:27 AM, Bryan Thompson wrote:

I can do this.

Bryan

On Thu, Sep 1, 2016 at 8:52 AM, Patricia Shanahan <p...@acm.org> wrote:


My reason for asking this is to make sure there are at least three of us.
If Peter and I both build and test the release, it won't be enough to make
it an official Apache release. We will need a third PMC member who is
active enough to do it.

On 9/1/2016 6:31 AM, Patricia Shanahan wrote:


How many PMC members are ready and willing to build and test, so that
they can upvote the release?

Peter: Why jar files in the release? Isn't it supposed to be source code?

On 9/1/2016 4:57 AM, Peter Firmstone wrote:


Getting another set of release artifacts 4 River3 ready and have run
all tests again, need to generate pgp signatures on weekend.

Decided not to use X500 release cert to sign jar files this release to
prevent holding up progress, since I haven't worked out how others can
verify release artifacts as the pgp signatures will be different when
comparing artifacts containing signed jars with those that don't, then
there's the issue of how to integrate it into the build process.

Regards,

Peter.

Sent from my Samsung device.

Re: release artifacts

[Patricia Shanahan]

My reason for asking this is to make sure there are at least three of 
us. If Peter and I both build and test the release, it won't be enough 
to make it an official Apache release. We will need a third PMC member 
who is active enough to do it.


On 9/1/2016 6:31 AM, Patricia Shanahan wrote:

How many PMC members are ready and willing to build and test, so that
they can upvote the release?

Peter: Why jar files in the release? Isn't it supposed to be source code?

On 9/1/2016 4:57 AM, Peter Firmstone wrote:

Getting another set of release artifacts 4 River3 ready and have run
all tests again, need to generate pgp signatures on weekend.

Decided not to use X500 release cert to sign jar files this release to
prevent holding up progress, since I haven't worked out how others can
verify release artifacts as the pgp signatures will be different when
comparing artifacts containing signed jars with those that don't, then
there's the issue of how to integrate it into the build process.

Regards,

Peter.

Sent from my Samsung device.

Re: release artifacts

[Patricia Shanahan]

How many PMC members are ready and willing to build and test, so that 
they can upvote the release?


Peter: Why jar files in the release? Isn't it supposed to be source code?

On 9/1/2016 4:57 AM, Peter Firmstone wrote:

Getting another set of release artifacts 4 River3 ready and have run all tests 
again, need to generate pgp signatures on weekend.

Decided not to use X500 release cert to sign jar files this release to prevent 
holding up progress, since I haven't worked out how others can verify release 
artifacts as the pgp signatures will be different when comparing artifacts 
containing signed jars with those that don't, then there's the issue of how to 
integrate it into the build process.

Regards,

Peter.

Sent from my Samsung device.

Re: JDK9 permission checks leaking outside of module boundaries

[Patricia Shanahan]

Do these grants create a security risk?

On 8/21/2016 3:18 AM, Peter wrote:


There are a number of permission checks leaking outside module
boundaries, because their classes call jvm library code that eventually
cause these permission checks.

Is this correct?

I've had to grant the following permissions in policy files, but the
classes involved are not accessing these packages directly:

permission java.lang.RuntimePermission
"accessClassInPackage.sun.util.logging.resources";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.util";
permission java.lang.RuntimePermission
"accessClassInPackage.jdk.internal.misc";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.ssl";
permission java.lang.RuntimePermission
"accessClassInPackage.sun.security.action";

See similar below:

 [java] -
 [java]
 [java] Running
org/apache/river/test/spec/jeri/ssl/SslServerConstructorAccessor.td
 [java] Time is Sun Aug 21 20:00:16 AEST 2016
 [java] Starting test in separate process with command:
 [java] 'C:\Program Files\Java\jdk-9\bin\java'
-Djava.security.manager=org.apache.river.api.security.CombinerSecurityManager

-Djava.security.policy=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/spec/jeri/transport/resources/ssl.policy

-cp
C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\lib\jiniharness.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\lib\jinitests.jar;\mergedpolicyprovider.jar;\jsk-policy.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\lib\jsk-platform.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\lib\jsk-lib.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\lib\high-scale-lib.jar;C:\Users\User\Documents\NetBeansProjects\River\trunk\lib\custard-apple-1.0.3.jar

-ea -esa -Dorg.apache.river.jsk.port=9080
-Dorg.apache.river.qa.port=9081
-Dorg.apache.river.jsk.home=C:\Users\User\Documents\NetBeansProjects\River\trunk

-Dorg.apache.river.qa.home=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa

-Dorg.apache.river.qa.harness.harnessJar=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\lib\jiniharness.jar

-Dorg.apache.river.qa.harness.testJar=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\lib\jinitests.jar

-Dorg.apache.river.qa.harness.runjiniserver=false
-Dorg.apache.river.qa.harness.runkitserver=false
-Djava.security.properties=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/harness/trust/dynamic-policy.properties

-Dorg.apache.river.qa.harness.testhosts=
-Djava.util.logging.config.file=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa\src\org\apache\river\test\resources\qa1.logging

-Djava.rmi.server.useCodebaseOnly=false
-Dnet.jini.core.lookup.ServiceRegistrar.portAbitraryIfInUse=true
-Dorg.apache.river.test.home=C:\Users\User\Documents\NetBeansProjects\River\trunk\qa

-Dorg.apache.river.test.port=9082
-Dorg.apache.river.qa.harness.policies=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/resources/jinitest.policy

-Djava.security.auth.login.config=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/spec/jeri/transport/resources/ssl.login

-DkeyStoreURL=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/spec/jeri/transport/resources/keystore

-DkeyStorePasswordURL=file:/C:/Users/User/Documents/NetBeansProjects/River/trunk/qa/src/org/apache/river/test/spec/jeri/transport/resources/keystore.password

org.apache.river.qa.harness.MasterTest
org/apache/river/test/spec/jeri/ssl/SslServerConstructorAccessor.td
 [java]
 [java] TIME: 8:00:20 PM
 [java]
 [java] MasterTest.doTest INFO:
 [java] == CALLING CONSTRUCT()
==
 [java]
 [java] MasterTest.doTest INFO:
 [java] === CALLING RUN()
===
 [java]
 [java] java.util.ServiceConfigurationError:
javax.security.auth.spi.LoginModule: Provider
com.sun.security.auth.module.KeyStoreLoginModule could not be instantiated
 [java] at
java.util.ServiceLoader.fail(java.base@9-ea/ServiceLoader.java:379)
 [java] at
java.util.ServiceLoader.access$800(java.base@9-ea/ServiceLoader.java:218)
 [java] at
java.util.ServiceLoader$ModuleServicesIterator.nextService(java.base@9-ea/ServiceLoader.java:741)

 [java] at
java.util.ServiceLoader$RestrictedIterator$2.run(java.base@9-ea/ServiceLoader.java:541)

 [java] at
java.security.AccessController.doPrivileged(java.base@9-ea/Native Method)
 [java] at
java.util.ServiceLoader$RestrictedIterator.next(java.base@9-ea/ServiceLoader.java:543)

 [java] at
java.util.ServiceLoader$2.next(java.base@9-ea/ServiceLoader.java:921)
 [java] at

Re: Phoenix RMI Registry and jdk9

[Patricia Shanahan]

To what extent is it feasible to move away from depending on com.sun.* 
classes in general?


On 8/16/2016 1:46 AM, Peter wrote:

Phoenix specific JRMP Exporters for  Activation and Registry don't play well 
with jdk9 as they access sun.* classes.

Only the Registry exporter is required, to allow ActivationGroup to find the 
ActivationSystem using the RMI Registry.  There are JERI alternatives for all 
other Phoenix's exported remote objects.

Phoenix has its own read-only Registry implementation.

I think it would be wise to deprecate all JRMP Exporters, given their recent 
removal from the 2.2.x branch.

Phoenix can use the standard RMI registry instead by default, I propose three 
configuration entries to allow Phoenix to create a standard RMI Registry using 
only public hava api's, with specified port and RMI SocketFactory instances, 
which allow users to use TLS should they wish to prevent unauthorised access to 
the Registry.

Regards,

Peter.

Sent from my Samsung device.

Testing Apache River with JDK 9 Early Access builds

[Patricia Shanahan]

I have received a request from Oracle's OpenJDK Quality Group for 
information on any testing with have done with JDK 9 early access 
builds. Has any testing been done? Is that a reasonable project going 
forward?

Re: Draft report

[Patricia Shanahan]

+1

On 8/7/2016 12:09 AM, Patricia Shanahan wrote:

Also, PMC members: please vote as soon as possible. I am a bit late sending 
this because it is due to the board on Wednesday.

Patricia


On Aug 6, 2016, at 12:59, Patricia Shanahan <p...@acm.org> wrote:

Here is a draft of the August 2016 board report. As always, suggested changes 
are welcome.

==

## Description:
  - Apache River software provides a standards-compliant JINI service.

## Issues:

  - There are no issues requiring board attention at this time. Although the 
troubles discussed last quarter persist, there is on-going discussion of 
possible future directions.

## Activity:

  - There has been little activity.

## Health report:

  - The technical and people problems discussed last quarter have not yet been 
solved, but neither have they killed the project. In the last two months there 
have been threads on dev@river.apache.org, involving a total of 6 people, 
discussing how to support languages other than Java and how to take River in an 
IoT direction.

## PMC changes:

  - Currently 13 PMC members.
  - No new PMC members added in the last 3 months
  - Last PMC addition was Bryan Thompson on Sun Aug 30 2015

## Committer base changes:

  - Currently 15 committers.
  - Dan Creswell was added as a committer on Mon Jun 20 2016

## Releases:

  - Last release was river-jtsk-2.2.3 on Sat Feb 20 2016

Re: Draft report

[Patricia Shanahan]

Also, PMC members: please vote as soon as possible. I am a bit late sending 
this because it is due to the board on Wednesday. 

Patricia

> On Aug 6, 2016, at 12:59, Patricia Shanahan <p...@acm.org> wrote:
> 
> Here is a draft of the August 2016 board report. As always, suggested changes 
> are welcome.
> 
> ==
> 
> ## Description:
>   - Apache River software provides a standards-compliant JINI service.
> 
> ## Issues:
> 
>   - There are no issues requiring board attention at this time. Although the 
> troubles discussed last quarter persist, there is on-going discussion of 
> possible future directions.
> 
> ## Activity:
> 
>   - There has been little activity.
> 
> ## Health report:
> 
>   - The technical and people problems discussed last quarter have not yet 
> been solved, but neither have they killed the project. In the last two months 
> there have been threads on dev@river.apache.org, involving a total of 6 
> people, discussing how to support languages other than Java and how to take 
> River in an IoT direction.
> 
> ## PMC changes:
> 
>   - Currently 13 PMC members.
>   - No new PMC members added in the last 3 months
>   - Last PMC addition was Bryan Thompson on Sun Aug 30 2015
> 
> ## Committer base changes:
> 
>   - Currently 15 committers.
>   - Dan Creswell was added as a committer on Mon Jun 20 2016
> 
> ## Releases:
> 
>   - Last release was river-jtsk-2.2.3 on Sat Feb 20 2016
> 
> 
> 

Draft report

[Patricia Shanahan]

Here is a draft of the August 2016 board report. As always, suggested 
changes are welcome.


==

## Description:
   - Apache River software provides a standards-compliant JINI service.

## Issues:

   - There are no issues requiring board attention at this time. 
Although the troubles discussed last quarter persist, there is on-going 
discussion of possible future directions.


## Activity:

   - There has been little activity.

## Health report:

   - The technical and people problems discussed last quarter have not 
yet been solved, but neither have they killed the project. In the last 
two months there have been threads on dev@river.apache.org, involving a 
total of 6 people, discussing how to support languages other than Java 
and how to take River in an IoT direction.


## PMC changes:

   - Currently 13 PMC members.
   - No new PMC members added in the last 3 months
   - Last PMC addition was Bryan Thompson on Sun Aug 30 2015

## Committer base changes:

   - Currently 15 committers.
   - Dan Creswell was added as a committer on Mon Jun 20 2016

## Releases:

   - Last release was river-jtsk-2.2.3 on Sat Feb 20 2016

State of the Project

[Patricia Shanahan]

We are due to file a board report next month. Last cycle, I first 
initiated an open-ended discussion of the state of the project. I 
included a summary in the board report. The feedback from the board was 
positive:



mt: Thanks for the frank assessment of River's health.

  sc: +1 to mt: bad news is fine - the fact you're clearly analyzing
  and working on it is the great part of this report.


I would like to repeat the analysis each quarter, both for my own 
information and in order to keep the board informed.


Any opinions on where we are and where we are going?

Thanks,

Patricia

Re: Attic? Was: Re: Lotj - languages other than java

[Patricia Shanahan]

Are we changing the minimum supported Java version for user code? If so, 
we definitely need to change the major version number.


Even if we are not changing Java versions, I feel the volume of change 
calls for a new major version number, even if each individual change 
would not.


On 7/6/2016 3:26 AM, Peter wrote:

I know, thankfully that failure wasn't hard to track down and fix,
hopefully no more blocking issues arise, I like to have a full
weekend to generate release artifacts, run tests and rat reports.

There's an occassional bug in classdep that causes failures so you
have to test every build to make sure all's well.

We can move to git after the release, for now though, there's no harm
asking about the possibility of migrating.

I suppose we could just leave the version at 3.0.0 instead of
changing it to 2.3.0?  There are no breaking changes, so it's non
compliant with agreed versioning, but it would avoid a lot of updates
to JIRA.

Regards,

Peter.


Sent from my Samsung device.

Include original message  Original message  From: Patricia
Shanahan <p...@acm.org> Sent: 06/07/2016 06:59:14 pm To:
dev@river.apache.org Subject: Re: Attic? Was: Re: Lotj - languages
other than java

I just hope a move to git does not become yet another reason to delay
a release. A few months ago we were really close - just a matter of
fixing a qa build failure.

On 7/5/2016 11:44 PM, Peter wrote:

Thanks Brian,

Hang in there, I think we can get back on track without
fragmenting, I've seen the developers on this project work well
together in the past.  I do agree GitHub is less work for releases,
I'm going to attempt to get access to Apache's git wip repository.
My experience has been that much more communication occurs on
Apache River mail lists.  The traffic I get with my fork on GitHub
relates to input validation for deserialization.

Regards,

Peter.


On 5/07/2016 12:49 AM, Bryan Thompson wrote:

I am just not that familiar with Apache policy.  However, river
is a real, functional, deployed in use platform.   I certainly
agree that there is deadlock at this point in terms of the people
and process.  However, I am not sure that an attic is the right
place for a well grounded and fielded technology.  While the
community might not be able to move ahead along a clear roadmap,
there is still support from the community for the technology.

Maybe a move to github would help to break things loose?  Open up
the development and release process more?  Right now things are
hung up in part on Apache process. Maybe Apache is just not the
right place at this time for this technology?

Thanks, Bryan

On Mon, Jul 4, 2016 at 10:08 AM, Patricia Shanahan<p...@acm.org>
wrote:


I think it is time to raise on the user list moving River to
the attic.

There is no sign of progress on a release. What interest there
is in development seems to be going in different directions.
Using portions of River code in other projects would still be
feasible with it in the attic, but there would be no need for a
PMC, and board reports.

Patricia

On 7/4/2016 6:44 AM, Simon IJskes - QCG wrote: ...


But then again, there are a lot of people reading this, and a
big part of them having no interest at all in incompatible
improvements, and i see no other option than leaving them
behind, with a jini compatible maintenance release. This will
certainly tear the river community apart, or at least cause a
lot of friction. So when i see only the two of us, moving in
a new direction, i can't help feeling, what is the use of it
 all.

G. Simon

Interns?

[Patricia Shanahan]

Bishnu Gautam has suggested that we should start taking interns, with 
assigned mentors, and might be able to steer some students our way.


What do you think? Would the proposed projects be able to use students? 
To be fair to the students, they would need mentors they could learn 
from, not just to be thrown a project and left to sink or swim.


In the longer terms, Apache participates in the Google Summer of Code 
each year, so we might be able to get one or more summer interns into that.


Patricia

Re: Attic? Was: Re: Lotj - languages other than java

[Patricia Shanahan]

I just hope a move to git does not become yet another reason to delay a 
release. A few months ago we were really close - just a matter of fixing 
a qa build failure.


On 7/5/2016 11:44 PM, Peter wrote:

Thanks Brian,

Hang in there, I think we can get back on track without fragmenting,
I've seen the developers on this project work well together in the
past.  I do agree GitHub is less work for releases, I'm going to attempt
to get access to Apache's git wip repository.  My experience has been
that much more communication occurs on Apache River mail lists.  The
traffic I get with my fork on GitHub relates to input validation for
deserialization.

Regards,

Peter.


On 5/07/2016 12:49 AM, Bryan Thompson wrote:

I am just not that familiar with Apache policy.  However, river is a
real,
functional, deployed in use platform.   I certainly agree that there is
deadlock at this point in terms of the people and process.  However, I am
not sure that an attic is the right place for a well grounded and fielded
technology.  While the community might not be able to move ahead along a
clear roadmap, there is still support from the community for the
technology.

Maybe a move to github would help to break things loose?  Open up the
development and release process more?  Right now things are hung up in
part
on Apache process. Maybe Apache is just not the right place at this time
for this technology?

Thanks,
Bryan

On Mon, Jul 4, 2016 at 10:08 AM, Patricia Shanahan<p...@acm.org>  wrote:


I think it is time to raise on the user list moving River to the attic.

There is no sign of progress on a release. What interest there is in
development seems to be going in different directions. Using portions of
River code in other projects would still be feasible with it in the
attic,
but there would be no need for a PMC, and board reports.

Patricia

On 7/4/2016 6:44 AM, Simon IJskes - QCG wrote:
...


But then again, there are a lot of people reading this, and a big part
of them having no interest at all in incompatible improvements, and i
see no other option than leaving them behind, with a jini compatible
maintenance release. This will certainly tear the river community
apart,
or at least cause a lot of friction. So when i see only the two of us,
moving in a new direction, i can't help feeling, what is the use of it
all.

G. Simon

Re: Attic? Was: Re: Lotj - languages other than java

[Patricia Shanahan]

On 7/5/2016 1:26 AM, Peter wrote:

Can we move to git, without moving to GitHub?


Not currently. There is an experiment underway for a system that uses 
GitHub with an Apache-controlled mirror. I will look again at the status 
of that project.


We can get a read-only git mirror. See http://www.apache.org/dev/git.html



https://www.linux.com/blog/apache-hadoop-transitions-git

A concern I have with moving to GitHub is DCMA take down notices and IP:

https://github.com/github/dmca

The Apache foundation provides us with legal support as well as governance.


The git and legal issues are very closely related. One of Apache's 
objectives is to be able to tie every change in any Apache code to a 
license agreement. The foundation wants to be able to say, for example 
"That block of code was checked in on date X by person Y, and here is an 
ICLA from Y that was in effect on date X."


As I understand the issue, normal Git is too flexible to give the 
required provenance tracking.




I always thought we could find a common code base that people can agree
on, without hobbling the abilities or ambitions of those that want to do
more.

The next steps for me, when I have time, will be to update trunk version
to River 2.3.0 from River 3.0.0, update the release notes, generate and
sign the release artifacts with our new code signing certs, that Apache
recently paid for, for our next round of voting.

I'm not ready to admit defeat yet, that's what the attic represents.
The project has survived longer periods of stagnation or disagreement in
the past, such as during incubation and become active again.


OK - I'll wait to see what happens.

Patricia

Re: Lotj - languages other than java

[Patricia Shanahan]

On 7/4/2016 8:33 PM, Bishnu Gautam wrote:

Hi Peter It is great that you pointed out lookup locator issue in
firewall and its potential solution. It would be great to see the
developments in River in which they really focus to have lookup
discovery beyond the firewall without requiring port forward and
other demanding packet filtering techniques. Once this obstacle in
River is crossed, I am pretty sure that there will be new paradigm
shift in IoT or ICT technology. This technology has a tremendous
potential. However, I never understand why River community never try
to bring this issue on the first place. River in Internet would be
the most wonderful solutions for millions of users around the world.
Please think, discuss and try to work on it. It would be a great news
for us.


Do you have any ideas for how to recruit River developers? Even the 
committers we have do not have enough time to finish an almost complete 
release.

Re: Attic? Was: Re: Lotj - languages other than java

[Patricia Shanahan]

See https://attic.apache.org/ for an introduction.

The question I am raising is whether River is viable as an Apache 
project, not whether it is a valuable body of code. Your second 
paragraph is exactly my point.


Apache brings some good stuff to its projects in the form of licensing 
with carefully controlled provenance and signed, tested releases. The 
downside is a process that is incompatible with Github, and some 
bureaucracy around the release process.


If that is not currently the right trade-off for River the best thing to 
do is to move to the attic. Any individual, or group of individuals, can 
download the code and use it any way they like that is compatible with 
Apache's license, which allows a lot. In particular, people who agree on 
a direction can start their own Github repository based on the River 
code. They do have to preserve some notices and make it clear that they 
have modified the code. See http://www.apache.org/licenses/LICENSE-2.0 
for details.


Patricia

On 7/4/2016 7:49 AM, Bryan Thompson wrote:

I am just not that familiar with Apache policy.  However, river is a real,
functional, deployed in use platform.   I certainly agree that there is
deadlock at this point in terms of the people and process.  However, I am
not sure that an attic is the right place for a well grounded and fielded
technology.  While the community might not be able to move ahead along a
clear roadmap, there is still support from the community for the technology.

Maybe a move to github would help to break things loose?  Open up the
development and release process more?  Right now things are hung up in part
on Apache process. Maybe Apache is just not the right place at this time
for this technology?

Thanks,
Bryan

On Mon, Jul 4, 2016 at 10:08 AM, Patricia Shanahan <p...@acm.org> wrote:


I think it is time to raise on the user list moving River to the attic.

There is no sign of progress on a release. What interest there is in
development seems to be going in different directions. Using portions of
River code in other projects would still be feasible with it in the attic,
but there would be no need for a PMC, and board reports.

Patricia

On 7/4/2016 6:44 AM, Simon IJskes - QCG wrote:
...


But then again, there are a lot of people reading this, and a big part
of them having no interest at all in incompatible improvements, and i
see no other option than leaving them behind, with a jini compatible
maintenance release. This will certainly tear the river community apart,
or at least cause a lot of friction. So when i see only the two of us,
moving in a new direction, i can't help feeling, what is the use of it
all.

G. Simon

Attic? Was: Re: Lotj - languages other than java

[Patricia Shanahan]

I think it is time to raise on the user list moving River to the attic.

There is no sign of progress on a release. What interest there is in 
development seems to be going in different directions. Using portions of 
River code in other projects would still be feasible with it in the 
attic, but there would be no need for a PMC, and board reports.


Patricia

On 7/4/2016 6:44 AM, Simon IJskes - QCG wrote:
...

But then again, there are a lot of people reading this, and a big part
of them having no interest at all in incompatible improvements, and i
see no other option than leaving them behind, with a jini compatible
maintenance release. This will certainly tear the river community apart,
or at least cause a lot of friction. So when i see only the two of us,
moving in a new direction, i can't help feeling, what is the use of it all.

G. Simon

Re: Draft report

[Patricia Shanahan]

+1

On 5/9/2016 7:59 AM, Patricia Shanahan wrote:

This is a draft for the May 2016 board report.

==

## Description:
 - Apache River software provides a standards-compliant JINI service.

## Issues:
 - As discussed under "Health report", the project does have issues to
deal with, but it also has a functioning PMC to deal with them.

## Activity:
 - The main activity is preparing for the next release, currently
renamed 2.3.0

## Health report:
 - One of the active PMC members has resigned (moved to emeritus list).
Given the small size of the active core, this is a significant blow,
triggering discussion of the state and future of the project.

 - The project has technical issues, including age of code, lack of
support for use in languages other than Java, lack of support for
Android, and dependence on Java serialization.

 - Possibly as a result of the technical issues, there may be a tapering
off of interest in the project, making it hard to attract new committers
and PMC members.

 - Future paths that will be considered by the PMC include carrying on
as-is, making radical changes possibly in the direction of IoT, or going
to the attic. We intend to complete at least one more release first.

## PMC changes:
 - Currently 13 PMC members.
 - No new PMC members added in the last 3 months
 - Greg Trasuk resigned
 - Last PMC addition was Bryan Thompson on Sun Aug 30 2015

## Committer base changes:

 - Currently 13 committers.
 - No new committers added in the last 3 months
 - Last committer addition was Bryan Thompson at Mon Aug 31 2015

## Releases:

 - river-jtsk-2.2.3 was released on Sat Feb 20 2016

Draft report

[Patricia Shanahan]

This is a draft for the May 2016 board report.

==

## Description:
 - Apache River software provides a standards-compliant JINI service.

## Issues:
 - As discussed under "Health report", the project does have issues to 
deal with, but it also has a functioning PMC to deal with them.


## Activity:
 - The main activity is preparing for the next release, currently 
renamed 2.3.0


## Health report:
 - One of the active PMC members has resigned (moved to emeritus list). 
Given the small size of the active core, this is a significant blow, 
triggering discussion of the state and future of the project.


 - The project has technical issues, including age of code, lack of 
support for use in languages other than Java, lack of support for 
Android, and dependence on Java serialization.


 - Possibly as a result of the technical issues, there may be a 
tapering off of interest in the project, making it hard to attract new 
committers and PMC members.


 - Future paths that will be considered by the PMC include carrying on 
as-is, making radical changes possibly in the direction of IoT, or going 
to the attic. We intend to complete at least one more release first.


## PMC changes:
 - Currently 13 PMC members.
 - No new PMC members added in the last 3 months
 - Greg Trasuk resigned
 - Last PMC addition was Bryan Thompson on Sun Aug 30 2015

## Committer base changes:

 - Currently 13 committers.
 - No new committers added in the last 3 months
 - Last committer addition was Bryan Thompson at Mon Aug 31 2015

## Releases:

 - river-jtsk-2.2.3 was released on Sat Feb 20 2016

Re: State of the project

[Patricia Shanahan]

In the longer term, my understanding is that the Infrastructure team is 
working on ways of using Git that are compatible with ASF's IP history 
requirements. They are running a small experiment with a couple of projects.


I will continue to monitor board@ in the hope of adding Git read/write 
access to the River source code when feasible.


On 5/5/2016 5:15 AM, Bryan Thompson wrote:

There are several key reasons for moving to git, and a read-only repository
would not support most of them:

* Git makes it significantly easier to branch and merge when compared to
SVN, CVS, etc.
* Git pull requests encapsulate an opportunity for feedback on branches and
easy diffs between branches that is unparalleled by SVN, etc.
* PRs can be contributed more easily from the broader community (but such
PRs would require Apache CLAs, etc. before they could be incorporated into
an Apache project so we might not get much utility from this).
* Git repositories can be easily forked (a read-only view would support
this), and these forks can flow updates back to the original project (this
would again run into trouble with the Apache CLA process).

Thanks,
Bryan

On Tue, May 3, 2016 at 7:48 AM, Patricia Shanahan <p...@acm.org> wrote:


Currently, I believe only read-only Git mirrors are supported for most
projects. See http://www.apache.org/dev/git.html. It looks as though the
process for adding a mirror is fairly simple. Would that level of support
be useful?

There is an experiment going on to extend Git use. I suggest at least one
of you should subscribe to the infrastructure-dev@ list to follow what is
happening.

On 5/3/2016 4:22 AM, Tom Hobbs wrote:


Could we consider a service registrar that doesn't require code

downloads? Other language support?  What might it look like?



This is my particular itch right now.  I’m happy to work on pulling
reggie out as one of the first modules.

And +1 for git.


On 3 May 2016, at 11:29, Peter <j...@zeus.net.au> wrote:


Could we consider a service registrar that doesn't require code
downloads? Other language support?  What might it look like?

Re: State of the project

[Patricia Shanahan]

Currently, I believe only read-only Git mirrors are supported for most 
projects. See http://www.apache.org/dev/git.html. It looks as though the 
process for adding a mirror is fairly simple. Would that level of 
support be useful?


There is an experiment going on to extend Git use. I suggest at least 
one of you should subscribe to the infrastructure-dev@ list to follow 
what is happening.


On 5/3/2016 4:22 AM, Tom Hobbs wrote:

Could we consider a service registrar that doesn't require code downloads? 
Other language support?  What might it look like?


This is my particular itch right now.  I’m happy to work on pulling reggie out 
as one of the first modules.

And +1 for git.



On 3 May 2016, at 11:29, Peter  wrote:

Could we consider a service registrar that doesn't require code downloads? 
Other language support?  What might it look like?

State of the project

[Patricia Shanahan]

The next River report to the board is due May 11th. I am supposed to 
keep the board informed of the state of the community. With that in 
mind, I would welcome input from anyone with an opinion on the matter.

Re: River 3.0 API changes

[Patricia Shanahan]

My initial feeling is in favor of reverting - if we have test failures, 
we should investigate whether the bug is in River or in the test. If it 
is in the test, fix the test.


I have been trying to think whether there is a simple way of finding and 
reviewing suspect tests. Presumably a test would have to be affected by 
the changes to have a bug that is fixed by them?


Patricia

On 4/25/2016 3:46 PM, Peter wrote:

If I don't receive any responses, I'll revert these changes, prior to 
publishing the River 3.0 release artifacts next week end.

Regards,

Peter.

Sent from my Samsung device.

  Include original message
 Original message 
From: Peter 
Sent: 25/04/2016 09:23:16 pm
To: dev@river.apache.org
Subject: Re: River 3.0 API changes

Correction:

net.jini.core.discovery.LookupLocator (incorrect package listed below),
also has two protected fields that have been made final, host and port.

Regards,

Peter.

On 25/04/2016 8:58 PM, Peter wrote:

 Before we release River 3.0, I think it's important to discuss changes
 to the public api.

 Changes to api have been minimal, however we should come to concensus
 prior to release.  Note that changes made were for correctness reasons
 only, but the community should decide whether we should favour
 correctness or backward compatibility.

 The changes:

 net.jini.core.event.RemoteEvent - protected fields changed to final &
 private.
 net.jini.core.lookup.ServiceEvent - protected fields changed to final
 protected.
 net.jini.discovery.RemoteDiscoveryEvent - protected field discarded
 changed to final protected, protected fields; marshalledRegs, regs &
 groups changed to private final.

 Note that net.jini.lookup.LookupLocator's serial from changed in River
 2.2, in a non backward compatible way, however the LookupLocator in
 River 3.0 doesn't include the change, but it's serial form is backward
 compatible with both versions (at some point I'd like to address the
 issue that change intended to address).

 In all cases serial form has been preserved.

 These changes were made at the same time the new Startable.start()
 interface was created, that didn't go down too well, I didn't get
 around to discussing the above changes after the fallout from that.

 Prior to making a decision, I'd like to discuss why the changes were
 made, examples of impacts it will have on downstream code, including
 what's updates are required.  Keep in mind that people will need to
 recompile River 3.0 due to namespace changes, so this should be based
 on whether the changes required can be done so without impacting
 client code backward compatibiliy.

 I'm not against reverting these changes, however we need to understand
 that doing so will result in dropped events in tests, caused by unsafe
 publication, causing some test failures.  River 3.0 has far less
 blocking than the 2.2 branch, this exposes race conditions.

 It's worth noting I haven't fixed all race conditions in River 3.0,
 but I have fixed the majority.

 Regards,

 Peter.

 What I would have liked to fix but didn't (I did manage to work around
 it), a fundamental design issue with lease identity is, an expired
 lease is equal to a current lease, if both leases have the same id,
 when really the renew method should return a new lease with the same
 lease id, that isn't equal,  in my mind LeaseMap should have also been
 immutable, with a new map containing renewed leases returned upon
 renewal:

 Sun Bug: 4287125
 Norm: Client leases are being renewed after the set they are
 in should
 have expired.

 A given client lease should not be renewed after the
 set it is in
 has expired.  An iron-clad guarantee can't be made
 here because
 we can't hold onto locks while leases are being
 renewed.  However,
 the problem with Norm was worse than could be
 explained by the
 short window between committing to renew a client
 lease and
 performing the actual renewal.  The problem arose because
 there was no check in the renewal threads to make sure
 that
 the set the client lease was in still current, and
 because the
 thread that removed sets from the service often runs
 late.  Such
 a check is now performed so the window where a client
 lease renewal
 can occur, after the lease on the set the client lease
 is in has
 expired, is very small.

 Comment by P. Firmstone Apr 21st 2016: 
 These issues would not occur with immutable leases and
 sets,
 upon renewal a new set with successfully renewed leases
 would be returned

Re: [DISCUSS] [vote] should we fix security flaws?

[Patricia Shanahan]

Thank you. After the release, during the future direction discussion, 
I'll support discussing this issue to try to at least get mutual 
understanding, if not consensus.


On 4/8/2016 9:59 AM, Peter wrote:

you're right no need for this to happen now, consider it postponed.

Sent from my Samsung device.

   Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 08/04/2016 11:15:44 pm
To: dev@river.apache.org
Subject: Re: [DISCUSS] [vote] should we fix security flaws?

I am curious not so much about why a vote as about why a vote at this
particular time

I thought we had a consensus in favor of a future direction discussion
after the River 3.0 release. I was thinking about how to facilitate
constructive communication with a view to reaching a consensus wherever
possible. That should include everyone listening to your security
concerns, and considering them in the light of actual use-cases for River.

Even though you have time available now that cannot be applied to River
3.0, I am not at all sure that is true for everyone. I attributed the
lack of release progress to people being too busy.

Is there any way you could consider delaying this vote until the end of
the post-release future direction discussion, and then only holding it
if we fail to reach consensus?

On 4/8/2016 12:29 AM, Peter wrote:

  To provide some context on why I've put this to  a vote:

  Previous arguments against fixing security have suggested it's not relevant 
to local networks where River is deployed.

  But I've received some mixed messages regarding security recently.

  Although we can never fully guarantee complete security, we can address known 
issues if we choose to.

  Having this vote will help clarify whether security is important or not to 
the community.

  Once that is determined it will be easier to guage whether the time and 
effort in creating proofs for the existance of vulnerabilities is worthwhile.

  Regards,

  Peter.

  Sent from my Samsung device.

 Include original message
   Original message 
  From: Peter <j...@zeus.net.au>
  Sent: 08/04/2016 11:38:40 am
  To: dev@river.apache.org <d...@riverapache.org>
  Subject: Re: [DISCUSS] [vote] should we fix security flaws?


  I don't think we should delay the release to fix security.

  You have your reasons for not voting and I respect that.

Fixing security isn't technically difficult and I  have fixes available, 
I'm hoping for collaborative development, so they receive peer review / 
modification / alternate solutions / suggestions / feedback / rejection etc.

I haven't been successful communicating / discussing security and I think 
that will take some time to sort out.

  The ability to take down servers using dos is annoying and easily 
demonstrated (I've started writing some code to do so), however Gadget attacks 
allow an attacker to take over systems, steal data etc, but are less easily 
demonstrated.  While there are existing known gadget attacks, the ones I'm 
aware of have fixes, so I'll be looking for a zero day to demonstrate.  While 
whack a mole is one approach to fixes, it would be better to provide an api to 
support input validation.

  http://frohoff.github.io/appseccali-marshalling-pickles/

  Gadget attacks create object graphs using existing local classes to create 
execution paths that perform malicious actions during deserialization, this is 
a relatively recent development.  Security advisories recommend against 
deserializing from untrusted sources.

  The intent of the vote request is to determine whether fixing security issues 
is an option in future.

  If the result is no, it's my intention is to focus on getting River off svn 
into git, so it's easier to maintain my own branch while sharing and 
contributing to a common code base.

  If yes then I'll work on improving my communication skills for discussing  
security related issue's.

  Discussing this won't hold up a release as the time windows available for me 
to work on producing a release are weekends only.  I'm going to have to create 
the release artifacts on MSWindows, so need to check the scripts work properly 
and understand recent build changes.

  I also have other goals, I'll be ready to set up a public service registrar, 
discoverable over ipv6 in the near future.

  If the no vote wins, I promise not to mention security on this list again.

  Regards,

  Peter.

  Sent from my Samsung device.

 Include original message
   Original message ----
  From: Patricia Shanahan <p...@acm.org>
  Sent: 08/04/2016 06:34:23 am
  To: dev@riverapacheorg
  Subject: [DISCUSS] [vote] should we fix security flaws?

  I am not prepared to vote on this.

  First of all, I would need, on a private list where we can go into
  details of security issues, to get a feeling for the seriousness of the
  flaws in question. A denial of service is, in many contexts, less
  serious than file corruption.

 

[DISCUSS] [vote] should we fix security flaws?

[Patricia Shanahan]

I am not prepared to vote on this.

First of all, I would need, on a private list where we can go into 
details of security issues, to get a feeling for the seriousness of the 
flaws in question. A denial of service is, in many contexts, less 
serious than file corruption.


We may want to consider investigating the actual and proposed use-cases 
for River before deciding this.


Do you feel any of the security flaws in question are release-blockers 
for River 3.0? How long would fixing them first delay the release?


On 4/7/2016 12:36 PM, Peter wrote:

How do people on this project feel about security flaws?

Should we be fixing them?

I can provide evidence of vulnerabilities, I'm not proposing my fixes be 
adopted.

Vote:

  +1 Yes we should aim to fix security flaws.
0 don't care.
-1 No.

Regards,

Peter.



Sent from my Samsung device.

Re: The future thing

[Patricia Shanahan]

Remember we are an open source organization. Getting source releases out 
is the main thing. Binary artifacts are an optional extra.


Can you state your concerns with making the Trunk River 3.0? Do you feel 
it is a regression relative to our current release? My impression is 
that it is better, and should be the field release.


As always, I welcome input to the board report. I do feel it should 
either report we have released River 3.0, or discuss the barriers to 
getting it released.


On 4/6/2016 3:24 PM, Peter wrote:

We should perhaps raise some of the development problems we're having with the 
board.

I can create another release artifact in the near future, I need to look into 
how to create binary artifacts and stage the maven artifacts.

Regards,

Peter.

Sent from my Samsung device.

   Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 06/04/2016 11:15:06 pm
To: dev@river.apache.org
Subject: Re: The future thing

The ability to spin releases is a key aspect of being a viable project.
If we can't do that, I need to raise it as an issue in my next board
report. The problem of divergence between the last release and the trunk
is only going to get worse with time.

On 4/6/2016 3:54 AM, Peter wrote:

  Thanks Tom,

  I don't think the River community is ready to abandon the 2.2 branch
  just yet.

  It doesn't look like anyone's about to volunteer to spin another 3.0.0
  release just yet either.   Concerns remain about River 3.0 being ready
  for prime time, in any case we're only set up for source releases at
  present, so it would seem best to leave trunk as it is for people to
  check out, build and test until confidence improves.  In any case
  there's a 2.2 series release to tide people over.

  Can others on the list tell us more about where they think River's
  future development path should be?

  What other repetitive tasks do people do now that we could develop tools
  for?

  Regards,

  Peter.

  On 2/03/2016 7:05 AM, Tom Hobbs wrote:

  Can you tell us more about the tools River requires for deployment
  inside

  docker containers?

  The answer could be "nothing to do", but anyway it is a job for Future
  Tom.  I'm sure he'll be happy to share when he figures it out.  :-)  In
  fact was intending to commit the Dockerfiles when I get them sorted out.

  +1 on setting goals.  Clear goals and direction are a must.  Last time I
  looked (ages ago!) there is /nothing/ on our backlog that looked fun (to
  me).  A roadmap and unscoped (?) backlog items might help to change that

  Good luck on securing services over the net - and I mean that seriously.
  Since my previous email, I've got half a use case bubbling away in the
  back
  my mind which might just find it useful.

  Talking about Git.  What do people thing about deploying 3.0 as the fresh
  new source in (Apache's) Git and just locking/deprecating/abandoning
  whatever is in SVN?


  On Mon, Feb 29, 2016 at 12:04 PM, Peter<j...@zeus.net.au>  wrote:


  Can you tell us more about the tools River requires for deployment
  inside
  docker containers?

  River needs to establish goals and it needs committers willing to work
  towards those goals, at the moment we don't have little of either, so
  establishing some may help the project survive.

  I'm working on a secure version of River, forked from River trunk,
  for use
  on either side of the firewall, I'm tempted to consider removal of all
  dependencies on rmi code, but presently it is backward compatible with
  River.  I think most people misunderstand the concept of River on the
  web,
  or the internet, it's not something that would run from within a web
  browser like a plugin, it's just a way for programs to send messages to
  each other, peer to peer, globally, without requiring setting up web
  servers and clients, it's not the sever ->  client  / content provider&
  consumer model.  It has a lot more in common with the IoT model.

  In any case, securing river isn't that big a deal, it's somewhat
  easier to
  understand as ProxyTrust has been deprecated and there are performance
  improvements, but don't take my word for it, go see for yourself.

  https://github.com/pfirmstone/river-internet

  Regards,

  Peter



  On 28/02/2016 12:10 AM, Tom Hobbs wrote:


  +1 on making it easy.  Spark has their "here's how you can use Spark to
  stream a word count program" example, as far as I'm aware River doesn't
  have anything similar.

  +1 on the Docker mention, I've been doing lots of Docker recently with
  Consul as a service discovery mechanism, I think River would really
  benefit
  from Docker-isation.  Both in terms of running Reggie, Outrigger etc
  inside
  containers, and also using Reggie et al to orchestrate containers.  In
  fact, that's on my list of things to do.

  Like Greg, I see River being used behind the firewall.  I'm
  intending on
  using it for a prototype somethi

Re: Build without doing any tests?

[Patricia Shanahan]

Sorry, wrong mailing list. 

Patricia

> On Mar 13, 2016, at 07:57, Patricia Shanahan <p...@acm.org> wrote:
> 
> I am currently building a debug version of AOO, including using 
> --enable-dbgutil. I lost a few hours overnight because it did a test that 
> triggered an assertion dialog, and waited for me to wake up and click "No" to 
> continue.
> 
> I would prefer to separate building and the tests that are normally done 
> during "build --all", so that I can build while I am away from the computer 
> and test while I'm there to respond to any dialogs.
> 
> Patricia

Build without doing any tests?

[Patricia Shanahan]

I am currently building a debug version of AOO, including using 
--enable-dbgutil. I lost a few hours overnight because it did a test 
that triggered an assertion dialog, and waited for me to wake up and 
click "No" to continue.


I would prefer to separate building and the tests that are normally done 
during "build --all", so that I can build while I am away from the 
computer and test while I'm there to respond to any dialogs.


Patricia

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Patricia Shanahan]

My feeling is that there should be some way to document that it is not a 
real release, keep it as a development download for testing only, but 
make more users aware of it on those terms.


Can we e.g. put "beta" in its name?

What do other people think?

On 3/4/2016 7:57 AM, Greg Trasuk wrote:

Changing my vote to +0 for the moment.

OK, so what we have here is a build bug.

If you do an ‘ant clean’ then ‘ant river-runtime’, all is good.
Do ‘ant river-runtime’ again, you get the failure that Patricia is seeing.

If you ‘cd qa’ then do ‘ant run-categories’ the qa suite runs without error.  
That target doesn’t attempt to rebuild the main distribution.  The ‘run’ target 
inside ‘qa’ _does_ rebuild the main distribution (I’m not sure why that was put 
in there, but that’s the way it’s been forever).  Hence it shows the error 
mentioned above.

When I was doing my testing, I ran ‘ant run-categories’ to run the test suite, 
so I didn’t see this build bug.

On the one hand, I’m inclined to cancel the vote, figure out the bug, and spin 
a new release.  That could potentially take a while, because the bug smells of 
a nasty circularity in the build (or it could be trivial).

On the other hand, we did say that this was a “technology preview” release that 
is supposed to get 3.0.0 into the hands of potential users, knowing full well 
that there are a lot of changes from the 2.2 branch, and people might find 
operational bugs.  People have run the qa suite, and it the whole package 
probably works just fine.  And the licensing is fine.  So we could probably 
just go ahead and release it.

I’m not sure what to do.  Any opinions?

Cheers,

Greg Trasuk.

On Mar 3, 2016, at 4:57 PM, Patricia Shanahan <p...@acm.org> wrote:

The file wk1 in the attached zip is the result of:

pats@pats-acer1:/River_3.0/src/apache-river-3.0.0$ ant clean 2>&1 >wk1
pats@pats-acer1:/River_3.0/src/apache-river-3.0.0$ ant -v 2>&1 >>wk1




On 03/03/2016 09:01 AM, Greg Trasuk wrote:

That’s quite odd.  Can you do an ‘ant clean’, then ‘ant -v’ and post the 
complete scrollback, from the ‘ant clean’ command, to the final ‘build failed’?

There is a chance, I suppose, that Ubuntu uses a different version of Java 
(i.e. OpenJDK rather than Oracle JDK) or has something else pre-installed that 
is interfering with the build.  I haven’t tried building on Ubuntu myself, but 
I’m pretty sure I’ve used OpenJDK at some point, and it was fine.

Cheers,

Greg Trasuk


On Mar 3, 2016, at 11:35 AM, Patricia Shanahan <p...@acm.org> wrote:

Tried that. I even went back and re-extracted the .zip file, in case prior 
attempts had left tire marks. After the extract I did

ant
ant qa.run

and got the same errors. This is on Ubuntu.

Unfortunately, I cannot cast a binding vote for a release I cannot run.

On 3/3/2016 6:20 AM, Greg Trasuk wrote:

Try running just ‘ant’ before you do ‘ant qa.run’.  That should run the default 
build target.

It appears that ‘qa.run’ is skipping the step where it downloads the external 
dependencies.  ‘ant’ on its own should do the build, then ‘ant qa.run’ should 
work.

Cheers,

Greg Trasuk


On Mar 2, 2016, at 8:26 PM, Patricia Shanahan <p...@acm.org> wrote:

I seem to be missing some set-up that needs doing before "ant qa.run".

ng: Class not found: groovy.lang.MetaMethod
 [java] Warning: Class not found: org.codehaus.groovy.reflection.ClassInfo
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.wrappers.Wrapper
 [java] Warning: Class not found: groovy.lang.Reference
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.callsite.CallSiteArray
 [java] Warning: Class not found: groovy.lang.GroovyCodeSource
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.callsite.CallSite
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.GeneratedClosure
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.typehandling.ShortTypeHandling
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter
 [java] Warning: Class not found: groovy.lang.Closure
 [java] Warning: Class not found: groovy.lang.MetaClass
 [java] Warning: Class not found: 
org.cliffc.high_scale_lib.NonBlockingHashMap
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.BytecodeInterface8
 [java] Warning: Class not found: org.codehaus.groovy.runtime.ArrayUtil
 [java] Warning: Class not found: groovy.lang.GroovyObject
 [java] Warning: Class not found: groovy.lang.GroovyClassLoader
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation
 [java] Warning: Class not found: 
org.codehaus.groovy.control.CompilerConfiguration
 [java] Warning: Class not found: org.codehaus.groovy.runtime.GStringImpl
 [java] Warning: Class not found: groovy.lang.MissingPropertyException
  [jar] Building jar: /River_3.0/src/apac

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Patricia Shanahan]

Will do, probably this afternoon. I have a tax prep appointment for the 
rest of this morning.


Patricia

On 3/3/2016 9:01 AM, Greg Trasuk wrote:

That’s quite odd.  Can you do an ‘ant clean’, then ‘ant -v’ and post
the complete scrollback, from the ‘ant clean’ command, to the final
‘build failed’?

There is a chance, I suppose, that Ubuntu uses a different version of
Java (i.e. OpenJDK rather than Oracle JDK) or has something else
pre-installed that is interfering with the build.  I haven’t tried
building on Ubuntu myself, but I’m pretty sure I’ve used OpenJDK at
some point, and it was fine.

Cheers,

Greg Trasuk


On Mar 3, 2016, at 11:35 AM, Patricia Shanahan <p...@acm.org>
wrote:

Tried that. I even went back and re-extracted the .zip file, in
case prior attempts had left tire marks. After the extract I did

ant ant qa.run

and got the same errors. This is on Ubuntu.

Unfortunately, I cannot cast a binding vote for a release I cannot
run.

On 3/3/2016 6:20 AM, Greg Trasuk wrote:


Try running just ‘ant’ before you do ‘ant qa.run’.  That should
run the default build target.

It appears that ‘qa.run’ is skipping the step where it downloads
the external dependencies.  ‘ant’ on its own should do the build,
then ‘ant qa.run’ should work.

Cheers,

Greg Trasuk


On Mar 2, 2016, at 8:26 PM, Patricia Shanahan <p...@acm.org>
wrote:

I seem to be missing some set-up that needs doing before "ant
qa.run".

ng: Class not found: groovy.lang.MetaMethod [java] Warning:
Class not found: org.codehaus.groovy.reflection.ClassInfo
[java] Warning: Class not found:
org.codehaus.groovy.runtime.wrappers.Wrapper [java] Warning:
Class not found: groovy.lang.Reference [java] Warning: Class
not found: org.codehaus.groovy.runtime.callsite.CallSiteArray
[java] Warning: Class not found: groovy.lang.GroovyCodeSource
[java] Warning: Class not found:
org.codehaus.groovy.runtime.callsite.CallSite [java] Warning:
Class not found: org.codehaus.groovy.runtime.GeneratedClosure
[java] Warning: Class not found:
org.codehaus.groovy.runtime.typehandling.ShortTypeHandling
[java] Warning: Class not found:
org.codehaus.groovy.runtime.ScriptBytecodeAdapter [java]
Warning: Class not found: groovy.lang.Closure [java] Warning:
Class not found: groovy.lang.MetaClass [java] Warning: Class
not found: org.cliffc.high_scale_lib.NonBlockingHashMap [java]
Warning: Class not found:
org.codehaus.groovy.runtime.BytecodeInterface8 [java] Warning:
Class not found: org.codehaus.groovy.runtime.ArrayUtil [java]
Warning: Class not found: groovy.lang.GroovyObject [java]
Warning: Class not found: groovy.lang.GroovyClassLoader [java]
Warning: Class not found:
org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation


[java] Warning: Class not found: 
org.codehaus.groovy.control.CompilerConfiguration

[java] Warning: Class not found:
org.codehaus.groovy.runtime.GStringImpl [java] Warning: Class
not found: groovy.lang.MissingPropertyException [jar] Building
jar: /River_3.0/src/apache-river-3.0.0/lib/jsk-platform.jar
[java] no text found: "preflistgen.error" [java]
java.lang.NoClassDefFoundError:
org/codehaus/groovy/runtime/GeneratedClosure [java] at
java.lang.ClassLoader.defineClass1(Native Method) [java] at
java.lang.ClassLoader.defineClass(ClassLoader.java:800) [java]
at
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)



[java] at java.net.URLClassLoader.defineClass(URLClassLoader.java:449)

[java] at
java.net.URLClassLoader.access$100(URLClassLoader.java:71)
[java] at
java.net.URLClassLoader$1.run(URLClassLoader.java:361) [java]
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
[java] at
java.security.AccessController.doPrivileged(Native Method)
[java] at
java.net.URLClassLoader.findClass(URLClassLoader.java:354)
[java] at
java.lang.ClassLoader.loadClass(ClassLoader.java:425) [java]
at java.lang.ClassLoader.loadClass(ClassLoader.java:358) [java]
at java.lang.Class.forName0(Native Method) [java] at
java.lang.Class.forName(Class.java:278) [java] at
org.apache.river.tool.PreferredListGen.compute(PreferredListGen.java:1162)


[java] at 
org.apache.river.tool.PreferredListGen.main(PreferredListGen.java:1420)

[java] Caused by: java.lang.ClassNotFoundException:
org.codehaus.groovy.runtime.GeneratedClosure [java] at
java.net.URLClassLoader$1.run(URLClassLoader.java:366) [java]
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
[java] at
java.security.AccessController.doPrivileged(Native Method)
[java] at
java.net.URLClassLoader.findClass(URLClassLoader.java:354)
[java] at
java.lang.ClassLoader.loadClass(ClassLoader.java:425) [java]
at java.lang.ClassLoader.loadClass(ClassLoader.java:358) [java]
... 15 more

BUILD FAILED /River_3.0/src/apache-river-3.0.0/build.xml:2205:
The following error occurred while executing this line:
/River_3.0/src/apache-river-3.0.0/qa/build.xml:144: The
following error occurred while executing this line:
/

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Patricia Shanahan]

I seem to be missing some set-up that needs doing before "ant qa.run".

ng: Class not found: groovy.lang.MetaMethod
 [java] Warning: Class not found: 
org.codehaus.groovy.reflection.ClassInfo
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.wrappers.Wrapper

 [java] Warning: Class not found: groovy.lang.Reference
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.callsite.CallSiteArray

 [java] Warning: Class not found: groovy.lang.GroovyCodeSource
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.callsite.CallSite
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.GeneratedClosure
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.typehandling.ShortTypeHandling
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.ScriptBytecodeAdapter

 [java] Warning: Class not found: groovy.lang.Closure
 [java] Warning: Class not found: groovy.lang.MetaClass
 [java] Warning: Class not found: 
org.cliffc.high_scale_lib.NonBlockingHashMap
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.BytecodeInterface8

 [java] Warning: Class not found: org.codehaus.groovy.runtime.ArrayUtil
 [java] Warning: Class not found: groovy.lang.GroovyObject
 [java] Warning: Class not found: groovy.lang.GroovyClassLoader
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.typehandling.DefaultTypeTransformation
 [java] Warning: Class not found: 
org.codehaus.groovy.control.CompilerConfiguration
 [java] Warning: Class not found: 
org.codehaus.groovy.runtime.GStringImpl

 [java] Warning: Class not found: groovy.lang.MissingPropertyException
  [jar] Building jar: 
/River_3.0/src/apache-river-3.0.0/lib/jsk-platform.jar

 [java] no text found: "preflistgen.error"
 [java] java.lang.NoClassDefFoundError: 
org/codehaus/groovy/runtime/GeneratedClosure

 [java] at java.lang.ClassLoader.defineClass1(Native Method)
 [java] at java.lang.ClassLoader.defineClass(ClassLoader.java:800)
 [java] at 
java.security.SecureClassLoader.defineClass(SecureClassLoader.java:142)
 [java] at 
java.net.URLClassLoader.defineClass(URLClassLoader.java:449)
 [java] at 
java.net.URLClassLoader.access$100(URLClassLoader.java:71)

 [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:361)
 [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
 [java] at java.security.AccessController.doPrivileged(Native 
Method)
 [java] at 
java.net.URLClassLoader.findClass(URLClassLoader.java:354)

 [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
 [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 [java] at java.lang.Class.forName0(Native Method)
 [java] at java.lang.Class.forName(Class.java:278)
 [java] at 
org.apache.river.tool.PreferredListGen.compute(PreferredListGen.java:1162)
 [java] at 
org.apache.river.tool.PreferredListGen.main(PreferredListGen.java:1420)
 [java] Caused by: java.lang.ClassNotFoundException: 
org.codehaus.groovy.runtime.GeneratedClosure

 [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
 [java] at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
 [java] at java.security.AccessController.doPrivileged(Native 
Method)
 [java] at 
java.net.URLClassLoader.findClass(URLClassLoader.java:354)

 [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:425)
 [java] at java.lang.ClassLoader.loadClass(ClassLoader.java:358)
 [java] ... 15 more

BUILD FAILED
/River_3.0/src/apache-river-3.0.0/build.xml:2205: The following error 
occurred while executing this line:
/River_3.0/src/apache-river-3.0.0/qa/build.xml:144: The following error 
occurred while executing this line:
/River_3.0/src/apache-river-3.0.0/build.xml:973: The following error 
occurred while executing this line:

/River_3.0/src/apache-river-3.0.0/common.xml:253: Java returned: 1



On 03/02/2016 04:20 PM, Peter wrote:

ant qa.run
ant test

Regards,

Peter.

Sent from my Samsung device.
  
   Include original message

 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 03/03/2016 09:44:57 am
To: dev@river.apache.org
Subject: Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

I have built from the release artifacts, on a Ubuntu box. What is the
simplest way of running some tests against my build result?

On 3/2/2016 2:25 PM, Patricia Shanahan wrote:

  I have just got done with another project that was my highest priority
  for a couple of weeks. I'll attempt to build and test so that I can cast
  a binding vote.

  On 3/2/2016 12:12 PM, Greg Trasuk wrote:

  Hi folks - we’re still short one binding vote for this release.  So,
  if you can, please have a look at the artifacts and have your say..

  Cheers,

  Greg Trasuk

  On Feb 23, 2016, at 

Re: Reminder: [Vote] Release Apache River JTSK 3.0.0

[Patricia Shanahan]

I have built from the release artifacts, on a Ubuntu box. What is the 
simplest way of running some tests against my build result?


On 3/2/2016 2:25 PM, Patricia Shanahan wrote:

I have just got done with another project that was my highest priority
for a couple of weeks. I'll attempt to build and test so that I can cast
a binding vote.

On 3/2/2016 12:12 PM, Greg Trasuk wrote:

Hi folks - we’re still short one binding vote for this release.  So,
if you can, please have a look at the artifacts and have your say..

Cheers,

Greg Trasuk

On Feb 23, 2016, at 3:43 PM, Greg Trasuk <tras...@stratuscom.com> wrote:

Hello all:

Release candidate artifacts can be found at
https://dist.apache.org/repos/dist/dev/river/

Binary release artifacts are staged in
https://repository.apache.org/content/repositories/orgapacheriver-1003/

The vote will remain open for at least 72 hours (Ending no sooner
than 2100UTC 20160226.

[  ] +1 : I am in favour of this release
[  ] +0 : I am not opposed to this release.
[  ] -1: I am against this release (please provide your reasons).

Cheers,

Greg Trasuk

Re: The future thing

[Patricia Shanahan]

Thanks for getting this started.

I think you have a high level vision of where you see River going in the 
future. It might be useful to state it here. The costs and benefits of 
changes are best evaluated in that sort of context.


On 2/25/2016 3:52 AM, Peter Firmstone wrote:

While we're waiting for people to review River 3.0's Release
artifacts...

I've posted some of my more contraversial work on River security and
ipv6 global discovery (internet announcement protocol) on github.
The river community is free to cherry pick the code if it wants.  I
would have much preferred to have developed it collaboratively,
there's room for improvement.

Features:

...

Where to start?

[Patricia Shanahan]

I expect to complete my "Building on Windows" project in the next day or 
so, by documenting the results in 
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7


That means it is time to pick another project. Any suggestions?

Here is a brief resume:

Education:

B.Sc. Mathematics, Imperial College London, 1970
M.Sc. Computer Science, Birkbeck College London University, 1975
Ph.D. Computer Science, UC San Diego, 2009

Work:

I worked from 1970 to 2002 for NCR, Celerity, FPS, Cray Research, and 
Sun Microsystems. I worked on application software, operating systems, 
compilers, system performance, and server platform architecture. I was 
performance architect for the Sun E1 and 15K.


Unfortunately, my professional end-user applications development 
experience was writing programs that expected punch card or paper tape 
input. More recently, I have written computer performance models in C++ 
and Java, and did simulations in Java for my dissertation research.


Although my C++ experience is rusty and predates widespread availability 
of the STL, I should be able to get it up to date relatively easily. I 
have used templates and operator overloading.

Re: Where to start?

[Patricia Shanahan]

Apologies for sending this to the wrong list. I think the best thing I 
can do right now for River is to be a technically-neutral moderator for 
the River futures discussion.


On 2/11/2016 8:18 AM, Patricia Shanahan wrote:

I expect to complete my "Building on Windows" project in the next day or
so, by documenting the results in
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7


That means it is time to pick another project. Any suggestions?

Here is a brief resume:

Education:

B.Sc. Mathematics, Imperial College London, 1970
M.Sc. Computer Science, Birkbeck College London University, 1975
Ph.D. Computer Science, UC San Diego, 2009

Work:

I worked from 1970 to 2002 for NCR, Celerity, FPS, Cray Research, and
Sun Microsystems. I worked on application software, operating systems,
compilers, system performance, and server platform architecture. I was
performance architect for the Sun E1 and 15K.

Unfortunately, my professional end-user applications development
experience was writing programs that expected punch card or paper tape
input. More recently, I have written computer performance models in C++
and Java, and did simulations in Java for my dissertation research.

Although my C++ experience is rusty and predates widespread availability
of the STL, I should be able to get it up to date relatively easily. I
have used templates and operator overloading.

Re: Where to start?

[Patricia Shanahan]

Thanks - I got used to openoffice being the default, and then sent 
several messages to river.


On 2/11/2016 8:33 AM, Damjan Jovanovic wrote:

Hi Patricia

I think you meant to email this to d...@openoffice.apache.org, not
dev@river.apache.org. Luckily I am on both lists.

Damjan

On Thu, Feb 11, 2016 at 6:18 PM, Patricia Shanahan <p...@acm.org> wrote:

I expect to complete my "Building on Windows" project in the next day or so,
by documenting the results in
https://wiki.openoffice.org/wiki/Documentation/Building_Guide_AOO/Step_by_step#Windows_7

That means it is time to pick another project. Any suggestions?

Here is a brief resume:

Education:

B.Sc. Mathematics, Imperial College London, 1970
M.Sc. Computer Science, Birkbeck College London University, 1975
Ph.D. Computer Science, UC San Diego, 2009

Work:

I worked from 1970 to 2002 for NCR, Celerity, FPS, Cray Research, and Sun
Microsystems. I worked on application software, operating systems,
compilers, system performance, and server platform architecture. I was
performance architect for the Sun E1 and 15K.

Unfortunately, my professional end-user applications development experience
was writing programs that expected punch card or paper tape input. More
recently, I have written computer performance models in C++ and Java, and
did simulations in Java for my dissertation research.

Although my C++ experience is rusty and predates widespread availability of
the STL, I should be able to get it up to date relatively easily. I have
used templates and operator overloading.

Re: Draft report

[Patricia Shanahan]

Can I report this as a "+1"?

On 2/3/2016 9:29 PM, Greg Trasuk wrote:

Works for me.

Greg Trasuk


On Feb 3, 2016, at 8:44 PM, Patricia Shanahan <p...@acm.org> wrote:

Here is a draft of the February report. Please review and suggest any corrections, 
additions etc. In particular, does the "Health report" section represent the 
general consensus?

=

## Description:
   Apache River software provides a standards-compliant JINI service.

## Issues:
- There are no issues requiring board attention at this time.

## Activity:
- The main activity is preparing for release 3.0

## Health report:
- Activity continues at a level limited by the developers other commitments. 
There is forwards progress towards the 3.0 release.

- Different PMC members have different visions for River's post 3.0 direction. 
There is general agreement to set those issues aside in favor of getting the 
release done. We plan to discuss future directions after the 3.0 release.

## PMC changes:

- Currently 14 PMC members.
- No new PMC members added in the last 3 months
- Last PMC addition was Bryan Thompson on Sun Aug 30 2015

## Committer base changes:

- Currently 14 committers.
- No new committers added in the last 3 months
- Last committer addition was Bryan Thompson at Mon Aug 31 2015

## Releases:

- Last release was river-examples-1.0 on Sun Aug 09 2015

## Mailing list activity:

- dev@river.apache.org:
- 96 subscribers (up 2 in the last 3 months):
- 234 emails sent to list (214 in previous quarter)

- u...@river.apache.org:
- 97 subscribers (down -1 in the last 3 months):
- 15 emails sent to list (2 in previous quarter)


## JIRA activity:

- 1 JIRA tickets created in the last 3 months
- 40 JIRA tickets closed/resolved in the last 3 months

Re: Draft report

[Patricia Shanahan]

The board seems to start worrying about whether a report is real if it 
looks much the same from cycle to cycle. Collecting PMC +1 votes on the 
draft is one way to show both that the report was considered, not just a 
blind copy-paste, and that we have PMC members paying attention to the 
mailing lists. I prefer that to arbitrary reformatting just to make it 
look different.


On 2/4/2016 1:15 PM, Greg Trasuk wrote:

Didn’t realize we were voting.

+1

Greg Trasuk


On Feb 4, 2016, at 4:14 PM, Patricia Shanahan <p...@acm.org> wrote:

Can I report this as a "+1"?

On 2/3/2016 9:29 PM, Greg Trasuk wrote:

Works for me.

Greg Trasuk


On Feb 3, 2016, at 8:44 PM, Patricia Shanahan <p...@acm.org> wrote:

Here is a draft of the February report. Please review and suggest any corrections, 
additions etc. In particular, does the "Health report" section represent the 
general consensus?

=

## Description:
   Apache River software provides a standards-compliant JINI service.

## Issues:
- There are no issues requiring board attention at this time.

## Activity:
- The main activity is preparing for release 3.0

## Health report:
- Activity continues at a level limited by the developers other commitments. 
There is forwards progress towards the 3.0 release.

- Different PMC members have different visions for River's post 3.0 direction. 
There is general agreement to set those issues aside in favor of getting the 
release done. We plan to discuss future directions after the 3.0 release.

## PMC changes:

- Currently 14 PMC members.
- No new PMC members added in the last 3 months
- Last PMC addition was Bryan Thompson on Sun Aug 30 2015

## Committer base changes:

- Currently 14 committers.
- No new committers added in the last 3 months
- Last committer addition was Bryan Thompson at Mon Aug 31 2015

## Releases:

- Last release was river-examples-1.0 on Sun Aug 09 2015

## Mailing list activity:

- dev@river.apache.org:
- 96 subscribers (up 2 in the last 3 months):
- 234 emails sent to list (214 in previous quarter)

- u...@river.apache.org:
- 97 subscribers (down -1 in the last 3 months):
- 15 emails sent to list (2 in previous quarter)


## JIRA activity:

- 1 JIRA tickets created in the last 3 months
- 40 JIRA tickets closed/resolved in the last 3 months

Draft report

[Patricia Shanahan]

Here is a draft of the February report. Please review and suggest any 
corrections, additions etc. In particular, does the "Health report" 
section represent the general consensus?


=

## Description:
   Apache River software provides a standards-compliant JINI service.

## Issues:
 - There are no issues requiring board attention at this time.

## Activity:
 - The main activity is preparing for release 3.0

## Health report:
 - Activity continues at a level limited by the developers other 
commitments. There is forwards progress towards the 3.0 release.


 - Different PMC members have different visions for River's post 3.0 
direction. There is general agreement to set those issues aside in favor 
of getting the release done. We plan to discuss future directions after 
the 3.0 release.


## PMC changes:

 - Currently 14 PMC members.
 - No new PMC members added in the last 3 months
 - Last PMC addition was Bryan Thompson on Sun Aug 30 2015

## Committer base changes:

 - Currently 14 committers.
 - No new committers added in the last 3 months
 - Last committer addition was Bryan Thompson at Mon Aug 31 2015

## Releases:

 - Last release was river-examples-1.0 on Sun Aug 09 2015

## Mailing list activity:

 - dev@river.apache.org:
- 96 subscribers (up 2 in the last 3 months):
- 234 emails sent to list (214 in previous quarter)

 - u...@river.apache.org:
- 97 subscribers (down -1 in the last 3 months):
- 15 emails sent to list (2 in previous quarter)


## JIRA activity:

 - 1 JIRA tickets created in the last 3 months
 - 40 JIRA tickets closed/resolved in the last 3 months

Board report

[Patricia Shanahan]

February is a board report month for River, and the board meeting is 
relatively early in the month, so I should submit our report by February 
10th.


Are there any particular points I should be making?

Patricia

Re: Does it really make sense to have a "Convenience Binary" artifact?

[Patricia Shanahan]

On 1/21/2016 3:24 AM, Simon IJskes - QCG wrote:

On 21-01-16 09:51, Greg Trasuk wrote:


In going through the exercise of cleaning up the release artifacts,
I’ve started to wonder if it actually makes sense to publish a
“binary distribution” of the JTSK separately from publishing the
artifacts to Maven Central.



Opinions?


Please keep the binary distribution. I can't imagine that it is so hard
to keep the few extra lines in the scripts.

G. Simon



As I understand it, the main argument for getting rid of the binary
distribution is a lack of practical uses. The most powerful counter to
that argument would be to describe one or more ways the binary
distribution is used, or is likely to be used in the future.

Re: Release vote procedure

[Patricia Shanahan]

Remember that a PMC member voting +1 is asserting that they have 
personally downloaded, built, and tested the release candidate, as well 
as reviewing its licensing.


Do we have three PMC members who can do that within 72 hours? Anybody 
who would vote -1 on that schedule?


(I do not expect to be able to vote in favor in 72 hours from now, but 
will not vote against unless someone reports a real problem. Most 
likely, I'll not vote at all.)


Patricia

On 1/9/2016 11:42 AM, Greg Trasuk wrote:


What I actually meant (sorry for not writing precisely) is why not call the 
72-hour vote now and release it?

Cheers,

Greg.

On Jan 9, 2016, at 12:39 PM, Patricia Shanahan <p...@acm.org> wrote:

Now that we have a release candidate (YEAH!), we need to sort out how
and when to vote on it. We have two proposals, copied from different
e-mails.

Peter Firmstone:

Voting on this release will commence in 4 weeks, to allow time for
people to check they can reproduce these artifacts and test their
code and report back with any issues.


Greg Trasuk:

Why not just go ahead and call the vote now?  Once we have 3 ‘+1’s
saying it meets the license requirements, then we can put it up on
the main page.


Each of these has possible problems.

Peter's plan takes at least 31 days: 4 weeks followed by a minimum of 72
hours for the vote. That may be longer than necessary.

On the other hand, people who succeed in building and testing may be
ready to vote sooner than people who have problems, so we could hit
three +1 votes early, even if there would also have been three -1 votes.
A vote needs to have a definite time period. Also, releases are not
vetoed by -1 votes, but if anyone detects a serious problem we need to
stop and regroup, even if three PMC members have built and tested
successfully.

I suggest a two phase process similar to Peter's plan, but without the
fixed time frame. Instead, anyone who plans to vote should record their
intent here, proceed with building and testing, and report their
results. Deal with any issues on a consensus basis - I'm hoping there
will be none because the issues have already been discussed.

When most PMC members who plan to vote have reported success, we can
call an immediate 72 hour (or slightly longer) vote.

Patricia

Re: River - 3.0.0 Release candidate

[Patricia Shanahan]

These are the sorts of issues that I think should be sorted out, on a 
consensus basis, during a preliminary review-and-test phase.


On 1/9/2016 12:16 PM, Greg Trasuk wrote:

- I also though we had agreed to take the ‘examples’ folder out of the JTSK.

Cheers,

Greg


On Jan 9, 2016, at 3:05 PM, Greg Trasuk  wrote:


I’ve only looked at the ‘apache-river-3.0.0.tar.gz’ archive.  A few issues…

- we can’t have jar files in the source distribution.  Which means we have a 
problem with ‘dep-libs’.  You could either setup a separate download for 
developers to retrieve, or just give a list of the libraries that are needed.  
What I’d recommend is to modify the build script to use Apache Ivy to go get 
the requisite libraries at build time.  See the 2.2 branch for an example on 
how to do this.
- as above for ‘test/lib’
- The ‘tar_release_test’ folder should be removed
- There is a “LICENSE” and a “LICENSE.txt” file in the root of the 
distribution.  They’re identical - delete LICENSE.txt
- Same with NOTICE and NOTICE.txt.
- Both of the above will need to be reviewed when the jar files have been 
sorted out.  Also, we may need a different LICENSE and NOTICE file for the 
binary convenience artifacts.
- ‘doap-river.rdf’ is not really specific to the 3.0.0 release, so it shouldn’t 
be in the release artifact.
- ‘build.properties’ doesn’t have a license header.
- I’d remove the ‘nbproject’ folder myself - the project shouldn’t be dependent 
on the IDE.  Although we might want to include instructions on how to open it 
in an IDE.
- I could be wrong on this, but I think the current recommendation is to not 
include a “KEYS” file, but for the release manager to register his/her keys on 
‘id.apache.org’.

Cheers,

Greg Trasuk


On Jan 8, 2016, at 6:56 AM, Peter Firmstone  wrote:

The Apache River 3.0.0 Release candidate is available here:

http://people.apache.org/~peter_firmstone/

Voting on this release will commence in 4 weeks, to allow time for people to 
check they can reproduce these artifacts and test their code and report back 
with any issues.

The code is currently in trunk, this will be branched after the 4 week review 
period and Voting passes.

See also http://www.apache.org/dev/release-publishing.html

Regards,

Peter.

Re: VOTE: Take Security seriously or my resignation.

[Patricia Shanahan]

Please, please cancel this.

We do need to have a serious discussion of River future direction. I
expect that discussion to take a lot longer than a week, and hope it
will involve as many users and potential users of River as possible. For
example, we may need to canvas other project mailing lists to find out
whether a River with specific changes would be useful to them.

It will certainly take me more than a week to study the subject, and the
various opinions about it, sufficiently to be prepared to vote.

I feel, very strongly, that we need to get River 3.0 out the door ASAP.
Even with enough time for proper study, holding the River future
discussion first will inevitably distract from that objective and delay
the release. I thought that was also the PMC consensus.

My preferred plan is get existing changes out as River 3.0 first, then
discussion and study, then vote on future direction. I am sorely tempted
to resign if this premature vote goes ahead, regardless of the outcome,
but will not because I don't think such threats are an appropriate way
of influencing PMC votes.

Patricia

On 1/6/2016 4:21 AM, Peter Firmstone wrote:

Option 1.  I propose that we take security seriously, no security patches are 
to be rejected prior to review, that we review and analyse them properly based 
on merit. That discussions about security issues be taken seriously.

Option 2.  Alternatively I resign my River committer status

Please cast your vote, the vote is open for 7 days.

Let the community decide.

Regards,

Peter

Sent from my Samsung device.

Re: committer keys for release

[Patricia Shanahan]

I do not currently have keys, and this is not a good time to try to get 
a key into the web of trust. My understanding is that keys from people 
other than the release manager are optional.


On 12/21/2015 7:29 PM, Peter Firmstone wrote:

Committers who have contributed to River, please append your pgp public key to 
the KEYS file in the trunk directory in preparation for release.

Thank you,

Peter.

Sent from my Samsung device.

How to test?

[Patricia Shanahan]

I got myself a Ubuntu system set up, and was able to build River on it 
relatively easily, compared to Windows.


Now I need to run the tests. What is the latest/best documentation on 
how to do so?

Re: Preparation for Release - one more volunteer needed

[Patricia Shanahan]

I have some config files modified. Would you like me to check files in 
batch-by-batch, or wait until I have a lot of them done?


I got a "Jenkins build is still unstable" when I checked in the update 
to the RAT script. When do you expect that to go away?


On 12/9/2015 4:15 PM, Peter wrote:

Yes, check them in, I'll test them, the integration tests are running again 
now, so we'll quickly identify any problems.

Peter.

Sent from my Samsung device.
   Include original message
 Original message ----
From: Patricia Shanahan <p...@acm.org>
Sent: 10/12/2015 12:00:10 am
To: dev@river.apache.org
Subject: Re: Preparation for Release - one more volunteer needed

Note that this is not quite a release candidate. I'm working on fixing
some missing license statements in scripts and configuration files.

I am also working on getting together a build environment, having not
built River for some time.

Normally, I would wait for the script changes until I can build, so that
I can test what I am doing. In the current situation, would it be better
to do the changes, and check them in, without testing them?

Patricia

On 12/8/2015 4:25 PM, Peter wrote:

  Thanks Brian,

  Brad,

  The code is now in River's trunk branch.

  All com.sun.jini.* packages have changed to org.apache.river.*

  Some configuration options have changed since 2.2, ExecutorService has 
replaced TaskManager, where specified.

  Codebase grant's to URL's in policy files now by default, no longer resolve 
to ip addresses, this was done for two reasons:

  1. To reduce dns calls.
  2. To allow multiple codebase servers with different ip addresses to serve 
one domain name for increased redundancy or fail over.

  There's a system property that you can set if you need to revert to the 
previous behaviour.

  Interested to know how it goes.

  Regards,

  Peter.




  Sent from my Samsung device.
 Include original message
   Original message 
  From: Bryan Thompson <br...@systap.com>
  Sent: 09/12/2015 05:38:52 am
  To: <dev@river.apache.org> <dev@river.apache.org>; Brad Bebee 
<be...@systap.com>
  Subject: Re: Preparation for Release - one more volunteer needed

  Peter,

  Brad (Cc) is working to put the River 3 candidate release into CI for our
  platform.  This will allow us to test it in the highly available
  replication cluster mode of the database.

  Thanks,
  Bryan

  
  Bryan Thompson
  Chief Scientist & Founder
  SYSTAP, LLC
  4501 Tower Road
  Greensboro, NC 27410
  br...@systap.com
  http://blazegraph.com
  http://blog.blazegraph.com

  Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
  graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
  APIs.  Blazegraph is now available with GPU acceleration using our disruptive
  technology to accelerate data-parallel graph analytics and graph query.

  CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
  for the sole use of the intended recipient(s) and are confidential or
  proprietary to SYSTAP. Any unauthorized review, use, disclosure,
  dissemination or copying of this email or its contents or attachments is
  prohibited. If you have received this communication in error, please notify
  the sender by reply email and permanently delete all copies of the email
  and its contents and attachments.

  On Tue, Dec 8, 2015 at 2:29 PM, Peter <j...@zeusnet.au> wrote:


Thanks Patricia,

We need at least three binding votes for release, at the very least we
need one more committer willing to assist with the release process

Any volunteers?  We cannot do it without you.

Regards,

Peter.

Sent from my Samsung device.
  Include original message
     Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 08/12/2015 01:54:08 pm
To: dev@river.apache.org
Subject: Preparation for Release

This is probably unnecessary, but I wanted to make sure everyone
understands the requirements for casting binding votes in favor of a
release. See http://www.apache.org/legal/release-policy

In particular "Before casting +1 binding votes, individuals are REQUIRED
to download all signed source code packages onto their own hardware,
verify that they meet all requirements of ASF policy on releases as
described below, validate all cryptographic signatures, compile as
provided, and test the result on their own platform"

I am preparing for this by working on being able to build and test River
on one of my computers.

Patricia

Preparation for Release

[Patricia Shanahan]

This is probably unnecessary, but I wanted to make sure everyone 
understands the requirements for casting binding votes in favor of a 
release. See http://www.apache.org/legal/release-policy


In particular "Before casting +1 binding votes, individuals are REQUIRED 
to download all signed source code packages onto their own hardware, 
verify that they meet all requirements of ASF policy on releases as 
described below, validate all cryptographic signatures, compile as 
provided, and test the result on their own platform."


I am preparing for this by working on being able to build and test River 
on one of my computers.


Patricia

Re: RAT reports

[Patricia Shanahan]

Does anyone how one puts a license header in a manifest (.mf) file?

Patricia

On 12/5/2015 8:12 PM, Peter wrote:

Thanks Patricia.

Looks like there's a number of policy files and scripts that need header files.

Anyone have time to write a script to parse the Rat reports and prepend license 
headers?

I reconfigured the integration tests to run against trunk.  I noticed there are 
about 7 test failures in the unit tests, although none look particularly 
concerning, I'll have a better look later to make sure.

It would be nice if the jtreg tests ran on hudson, unfortunately they don't 
presently; the jtreg platform library isn't installed correctly.

I have run the jtreg tests locally and 132 pass on linux as expected.  There 
are some remaining Windows path issues, so not all pass on that platform.

I'm about to generate and update the release notes.  I'd also like to include a 
link to Dennis' examples on github.

Next we need to get our pgp encryption keys ready.  My old key expired so I'll 
have to generate a new one.

We're almost there, any assistance will be most appreciated.

Regards,

Peter.

Sent from my Samsung device.
   Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 06/12/2015 12:59:41 pm
To: dev@river.apache.org
Subject: RAT reports

RAT is still Java - it is just packaged as a .bin.zip.

I was not able to run the script directly in Cygwin, but was able to get
the reports by pasting the guts of it into a bash window. I attach the
resulting reports, and hope the mail system will let them through.

Re: Trunk merge and thread pools

[Patricia Shanahan]

Although we don't have a formal release schedule, I think there is
general agreement that getting 3.0 out in the field is way, way past
due. It should be considered frozen except for fixing really critical
bugs in the current functionality. Even livable bugs should be
documented and put off to 3.1.

Patricia

On 12/3/2015 10:57 PM, Greg Trasuk wrote:

On Dec 4, 2015, at 1:16 AM, Peter  wrote:

Since ObjectInputStream is a big hotspot,  for testing purposes, I merged these 
changes into my local version of River,  my validating ObjectInputStream 
outperforms the standard java ois

Then TaskManager, used by the test became a problem, with tasks in contention 
up to 30% of the time.

Next I replaced TaskManager with an ExecutorService (River 3, only uses 
TaskManager in tests now, it's no longer used by release code), but there was 
still contention  although not quite as bad.

Then I notice that tasks in the test call Thread.yield(), which tends to 
thrash, so I replaced it with a short sleep of 100ms.

Now monitor state was a maximum of 5%, much better.

After these changes, the hotspot consuming 27% cpu was JERI's 
ConnectionManager.connect,  followed by Class.getDeclaredMethod at 15.5%, 
Socket.accept 14.4% and Class.newInstance at 10.8%.




First - performance optimization:  Unless you’re testing with real-life 
workloads, in real-ife-like network environments, you’re wasting your time.  In 
the real world, clients discover services pretty rarely, and real-world 
architects always make sure that communications time is small compared to 
processing time.  In the real world, remote call latency is controlled by 
network bandwidth and the speed of light.  Running in the integration test 
environment, you’re seeing processor loads, not network loads.  There isn’t any 
need for this kind of micro-optimization.  All you’re doing is delaying 
shipping, no matter how wonderful you keep telling us it is.



My validating ois,  originating from apache harmony, was modified to use 
explicit constructors during deserialization.  This addressed finalizer 
attacks, final field immutability and input stream validation and the ois 
itself places a limit on downloaded bytes by controlling array creation and 
expecting a stream reset every so often, if it doesn't receive one, it throws 
an exception  The reset ensures the receiver will regain control of the stream 
before any DOS can occur, even for long running connections that transfer a lot 
of data.  There is no support for circular links in object graphs at this stage.

The deserialization constructor accepts a parameter that's caller sensitive, so 
each class in an object's inheritance hierarchy has it's own get field 
namespace.

A child class can validate it's parent class invariants by creating a 
superclass only instance, calling its constructor and passing the caller 
sensitive parameter (it cannot create this itself, it's created by the ois), 
once the class has validated all invariants including the superclasses , the 
client class knows it's safe to proceed with construction, otherwise it throws 
an exception, an instance has not been created and deserialization is 
terminated there.

Validation is performed inside static methods, prior to an object instance 
being created.

The openjdk team have adopted static method validation, but not the 
constructor.  Unfortunately, that alone, wouldn't provide the level of security 
required for an internet visible service or registrar.

The constructor and validation are very simple  to implement.

This would allow an internet based registrar to safely download only the 
bootstrap proxy to clients, so the client can authenticate it, before 
downloading Entry's for local filtering or ServiceUI, followed by the smart 
proxy.  This would be performed by proxy preparation.  So clients using SDM 
wouldn't require modification, with changes being backward compatible.

This would provide both security and delayed unmarshalling along with a 
significant increase in performance, as clients only ever download what they 
need and permit.

The validating ois was designed for bootstrap proxy's, the lookup service and 
unicast discovery,  but can be also implemented by services as well, as I have 
done.  A new constraint determines whether validating, or standard 
serialization is used.

Since we can now take advantage of interface default methods, we have an 
opportunity to alter the lookup service interface, should we wish to leave 
existing methods as they are and implement delayed unmarshalling and 
authenticate prior to unmarshalling smart proxy’s


Second - River on the Internet:  We’ve talked about this as a community.  River 
on the Internet is your pet, not the community’s interest.  Please stop trying 
to make River on the Internet happen.  It’s not going to happen.

If you want to indulge your obsession with making River safe for untrusted 
code, call it something else and go do it on Github, or go 

Re: Trunk merge and thread pools

[Patricia Shanahan]

If you have a real world workload that shows contention, we could make
serious progress on performance improvement - after 3.0 ships.

I am not even disagreeing with changes that are only shown to make the
tests more effective - after 3.0 ships.

I am unsure about whether Peter is tilting at windmills or showing the
optimum future direction for River with his security ideas. I would be
happy to discuss the topic - after 3.0 ships.

River 2.2.2, was released November 18, 2013, over two years ago. There
is already a lot of good stuff in 3.0 that should be available to users.

I have a feeling at this point that we will still be discussing what
should be in 3.0 this time next year. In order to get 3.0 out, I believe
we need to freeze it. That means two types of changes only until it
ships - changes related to organizing the release and fixes for
deal-killing regression bugs.

If I had the right skills and knowledge to finish up the release I would
do it. I don't. Ironically, I do know about multiprocessor performance -
I was performance architect for the Sun E1 and SunFire 15k. Given a
suitable benchmark environment, I would love to work on contention -
after 3.0 ships.

Patricia



On 12/4/2015 6:19 AM, Gregg Wonderly wrote:

With a handful of clients, you can ignore contention.  My
applications have 20s of threads per client making very frequent
calls through the service and this means that 10ms delays evolve into
seconds of delay fairly quickly.

I believe that if you can measure the contention with tooling, on
your desktop, it is a viable goal to reduce it or eliminate it.

It's like system time vs user time optimizations of old.  Now we are
contending for processor cores instead of the processor, locked in
the kernel, unable to dispatch more network traffic where it is
always convenient to bury latency.

Gregg

Sent from my iPhone

On Dec 4, 2015, at 9:57 AM, Greg Trasuk 
wrote:


On Dec 4, 2015, at 1:16 AM, Peter  wrote:

Since ObjectInputStream is a big hotspot,  for testing purposes,
I merged these changes into my local version of River,  my
validating ObjectInputStream outperforms the standard java ois

Then TaskManager, used by the test became a problem, with tasks
in contention up to 30% of the time.

Next I replaced TaskManager with an ExecutorService (River 3,
only uses TaskManager in tests now, it's no longer used by
release code), but there was still contention  although not quite
as bad.

Then I notice that tasks in the test call Thread.yield(), which
tends to thrash, so I replaced it with a short sleep of 100ms.

Now monitor state was a maximum of 5%, much better.

After these changes, the hotspot consuming 27% cpu was JERI's
ConnectionManager.connect,  followed by Class.getDeclaredMethod
at 15.5%, Socket.accept 14.4% and Class.newInstance at 10.8%.



First - performance optimization:  Unless you’re testing with
real-life workloads, in real-ife-like network environments, you’re
wasting your time.  In the real world, clients discover services
pretty rarely, and real-world architects always make sure that
communications time is small compared to processing time.  In the
real world, remote call latency is controlled by network bandwidth
and the speed of light.  Running in the integration test
environment, you’re seeing processor loads, not network loads.
There isn’t any need for this kind of micro-optimization.  All
you’re doing is delaying shipping, no matter how wonderful you keep
telling us it is.



My validating ois,  originating from apache harmony, was modified
to use explicit constructors during deserialization.  This
addressed finalizer attacks, final field immutability and input
stream validation and the ois itself places a limit on downloaded
bytes by controlling

Re: Trunk merge and thread pools

[Patricia Shanahan]

I'll look into it.

On 12/4/2015 8:01 PM, Peter wrote:

Yes,

There's a tool called Rat, there's a shell script it's included in our trunk, 
it checks our license headers etc are compliant for release.  I don't recall 
the details unfortunately, but I think you download the rat tool, set an env 
variable and run the script.  That would be very helpful.

Thanks,

Peter.

Sent from my Samsung device.
   Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 05/12/2015 12:01:04 pm
To: dev@river.apache.org
Subject: Re: Trunk merge and thread pools

Are there any practical things I can do to expedite the release? For
example, if you rough draft documentation and/or release notes, I can do
some editing.

On 12/4/2015 5:08 PM, Peter wrote:

  Trunk has now been replaced.  The only changes I'll make now are
  documentation, release notes, build scripts, license header checks
  and key signing.

  I could use some help as i am time poor.

  Presently I'm marking bugs on Jira as resolved, then I'll generate
  the release notes.

  This release has been more thoroughly tested than any previous River
  release

  After 3 is released, we could really utilise your experience
  Patricia, especially with JERI's ConnectionManager and Multiplexer,
  it uses complex shared and nested locks, supports 128 concurrent
  connections (shared endpoints) over one Socket or Channel.  If I can
  get contention with 2 cpu's, it's only going to get worse in a real
  world situation.

  This contention would only affect nodes that share multiple remote
  objects between them.  I suspect Gregg's use case will have multiple
  connections between node pairs and hit this contention, I also
  suspect that Greg is likely to  only have 1 or 2 connections between
  nodes.  Once two nodes have more than 128 connections (connections
  are directly proportional to the number of remote objects, server or
  client shared between two nodes) another multiplexer will be created,
  and so on, multiplexers sync on the ConnectionManager's monitor.

  I have a Sun T5240 (128 way 64GB Ram), with DilOS (an Illumos based
  distro with Debian package management).  Soon, I should have an high
  speed ipv6 connection courtesy of the NBN. When I do I'll set you up
  with a remote login for testing.

  I'll delay further discussion of security until after 3 is released.
  The changes I propose will have no bearing (won't be in their call
  stack) on those who aren't concerned about security.

  I'll be gratefull for an opportunity to present my security code,
  perhaps doing so may even dispell some fears.

  Regards,

  Peter.


  Sent from my Samsung device. Include original message  Original
  message  From: Patricia Shanahan <p...@acm.org> Sent: 05/12/2015
  01:37:10 am To: dev@river.apache.org Subject: Re: Trunk merge and
  thread pools

  If you have a real world workload that shows contention, we could
  make serious progress on performance improvement - after 3.0 ships.

  I am not even disagreeing with changes that are only shown to make
  the tests more effective - after 3.0 ships.

  I am unsure about whether Peter is tilting at windmills or showing
  the optimum future direction for River with his security ideas. I
  would be happy to discuss the topic - after 3.0 ships.

  River 2.2.2, was released November 18, 2013, over two years ago
  There is already a lot of good stuff in 3.0 that should be available
  to users.

  I have a feeling at this point that we will still be discussing what
  should be in 3..0 this time next year. In order to get 3.0 out, I
  believe we need to freeze it. That means two types of changes only
  until it ships - changes related to organizing the release and fixes
  for deal-killing regression bugs.

  If I had the right skills and knowledge to finish up the release I
  would do it. I don't. Ironically, I do know about multiprocessor
  performance - I was performance architect for the Sun E1 and
  SunFire 15k. Given a suitable benchmark environment, I would love to
  work on contention - after 3.0 ships.

  Patricia



  On 12/4/2015 6:19 AM, Gregg Wonderly wrote:

  With a handful of clients, you can ignore contention.  My
  applications have 20s of threads per client making very frequent
  calls through the service and this means that 10ms delays evolve
  into seconds of delay fairly quickly.

  I believe that if you can measure the contention with tooling, on
  your desktop, it is a viable goal to reduce it or eliminate it.

  It's like system time vs user time optimizations of old.  Now we
  are contending for processor cores instead of the processor, locked
  in the kernel, unable to dispatch more network traffic where it is
  always convenient to bury latency.

  Gregg

  Sent from my iPhone

  On Dec 4, 2015, at 9:57 AM, Greg Trasuk <tras...@stratuscom.com>
  wrote:


  On Dec 4, 2015, at 1:16 AM, Peter <j...@zeus.net.au> wrote:

 

Re: Trunk merge and thread pools

[Patricia Shanahan]

Thanks for getting that done.

There is a more general message in your thread pool observation. Any 
time we do something a certain way for performance, we should be 
prepared for the possibility that the opposite choice will become better 
in the future.


In general, there has been a trend for object creation and GC to get 
more efficient, so that object pooling that improved performance on 
early Java versions is a disoptimization now. Still, I'm surprised that 
it extends to thread creation.


On 12/1/2015 5:04 AM, Peter wrote:

Completed local merge of trunk into qa-refactor-namespace. Ran qa and
regression test suites.

Performed some profiling on outrigger stress tests, found blocking
queue in org.apache.river.thread.ThreadPool to be a significant hot
spot.  Tested all blocking queue implementations, no improvement.

Wild idea: don't pool threads, create new, let used threads be gc'd
after completion.

Test result; hot spot eliminated, less threads required.

I didn't expect that result.

Hotspot's now serialization.

Going to test jeri mux for graceful degredation under load when oome
occurs next.

Regards,

Peter.

Sent from my Samsung device.

Re: svn commit: r1716613

[Patricia Shanahan]

I think part of the problem is that it is difficult to understand and
reason about the Java memory model, because it is designed to be
implemented on many different hardware memory models.

On 11/29/2015 1:16 AM, Gregg Wonderly wrote:

I’ve tried to stress, over the years, how many different issues I
have encountered regarding contention and locking as well as outright
bugs.  Many people seem to have use cases which don’t expose all
these problems that you have worked so hard to take care of.  I
encountered lots of problems with SDM not working reliably.  DNS and
massive downloads also made for huge latency problems on desktop
applications which use serviceUI for admin and application UIs.  The
policy stuff… what a nightmare when secure performance is needed…  I
still encounter lots of people that have no idea how Java 5 JMM
changed what you must do, because of the non-Intel processors, if you
want things to actually work on the other processors.  I still loath
the non-volatile boolean loop hoist, but can not convince anyone that
it’s actually a huge problem because it actually changes the visible
execution of the program, with no observable details.  Instead, you
can log the boolean control and see it change and the loop never
exits.  Yes its a data race, but the JMM says that it may be possible
to observe the non-volatile write.  With the old memory model, where
Vector and Hashtable constantly created happens before, it did work
reliably.

Gregg


On Nov 28, 2015, at 9:40 PM, Peter  wrote:

Thanks for your support Gregg,

This should be an interesting release and it's been a long time in
the making.   Changes made are in response to years of requests
made on jini users and river dev to fix bottlenecks and performance
issues.

All remaining bottle necks (that I'm aware of) are native methods.

What's new?

Elimination of unnecessary DNS calls.

World's fastest scalable policy provider.

World's fastest class loading thanks to elimination of contention
using thread confinement and RFC3986 compliant URI normalisation.

Use of modern concurrent executors, deprecated TaskManager.  Stress
tests in the qa suite still use TaskManager, but no longer stress
their intended targets, instead the tests themselves are hotspots
now.

We've also fixed a heap of race conditions and atomicity bugs, even
ServiceDiscoveryManager and DGC work reliably now.
UnresovedPermission's always resolve as they should now too (fixed
a race condition in Java using thread confinement).  Safe
publication has also been used to fix race conditions in Permission
classes that use lazy init, but are documented as being immutable.
All services that implement Startable are safely exported, even
when using Phoenix Activation.

Then there a heap of latent bugs fixed as well, findbugs was used
along with visual auditing to find and fix many of them.

The Jini public api maintains backward compatibility.

The next step is to get this work back into trunk, the package
rename is making merge too difficult, so I think I'll do a diff of
the current trunk to the branch point where qa refactor originated,
then rename packages in the diff file and apply it against qa
refactor namspace.

Then I'll relace trunk.

That's the plan, dependant on available time.  Anyone have time to
volunteer with River 3.0's release once merging is complete?

Regards,

Peter.




Sent from my Samsung device. Include original message  Original
message  From: Gregg Wonderly  Sent:
29/11/2015 02:25:53 am To: dev@river.apache.org Subject: Re: svn
commit: r1716613

These kinds of contention reductions can be a huge gain for overall
performance.

The fastest time through is never faster than the time through the
highest contended spot!

Gregg

Sent from my iPhone


On Nov 27, 2015, at 4:46 PM, Peter  wrote:

Last attempt at sending this to the list:

During stress testing, the jeri multiplexer can fail when the jvm
runs out of memory and cannot create new Threads.  The mux lock
can also become a point of thread contention.  The changes avoid
creating new objects, using a bitset and array  (that doesn't
allocate new objects) instead of collection classes.

The code changes also reduce the time a monitor is held, thus
reducing contention under load.

Peter.



In order to properly review changes, it would be great to know
what the problem it is that you’re fixing - could you share?

Cheers,

Greg Trasuk

Draft report

[Patricia Shanahan]

## Description:
   Apache River software provides a standards-compilant JINI service.

## Issues:
 - There are no issues requiring board attention at this time

## Activity:
 - We have added a new PMC Member and Committer, Bryan Thompson.
 - A new, more usable, set of examples was released in August.
 - Several release-related issues were resolved early in the quarter.
 - There has been a quiet period for the last couple of months.

## Health report:
 - The project continues to make progress whenever committers have time 
to work on it, but that is not all the time.


## PMC changes:

 - Currently 14 PMC members.
 - Bryan Thompson was added to the PMC on Sun Aug 30 2015

## Committer base changes:

 - Currently 14 committers.
 - Bryan Thompson was added as a committer on Mon Aug 31 2015

## Releases:

 - river-examples-1.0 was released on Sun Aug 09 2015

## Mailing list activity:

 - dev@river.apache.org:
- 94 subscribers (down -2 in the last 3 months):
- 220 emails sent to list (93 in previous quarter)

 - u...@river.apache.org:
- 100 subscribers (up 0 in the last 3 months):
- 2 emails sent to list (3 in previous quarter)


## JIRA activity:

 - 0 JIRA tickets created in the last 3 months
 - 1 JIRA tickets closed/resolved in the last 3 months

November is board report month

[Patricia Shanahan]

I am due to file a River report for the November board meeting. Does 
anyone have anything I should include? Activity on the release seems to 
have stopped - what should I say about it?


Thanks,

Patricia

Re: Release 3.0 merge into trunk

[Patricia Shanahan]

For moving to Git, see http://www.apache.org/dev/writable-git

Is the support provided sufficient? How do committers in general feel 
about moving River to Git? If it is a good idea, should we do it before 
Release 3.0? The alternative might be to rename the current SVN branch 
and release from there.


On 9/22/2015 4:31 AM, Bryan Thompson wrote:

SVN gets really messy for this sort of thing.  We wound not bringing a
project with a large delta back to the trunk because of these issues and
just did releases from branches after that.

What kind of support does Apache offer for switching to git?  That might be
easier.

Thanks,
Bryan

On Mon, Sep 21, 2015 at 4:49 PM, Patricia Shanahan <p...@acm.org> wrote:


I think the next thing we need to do to make Release 3.0 a reality is to
merge it into the trunk.

If you agree, I would like opinions on the best way to go about it.
Ideally, we will preserve revision history for modules that have moved from
one directory/package to another.

Re: Release 3.0 merge into trunk

[Patricia Shanahan]

One concern I have with moving to Git before Release 3.0 is the tension 
between really thinking through the Git move and getting 3.0 out quickly.


On 9/22/2015 7:23 AM, Greg Trasuk wrote:

Apache’s Git support is just fine, and includes the ability to accept
pull requests from Github, in a way that suits our need to ensure
code provenance.  The River Container work that I did was in the Git
repository
https://git-wip-us.apache.org/repos/asf/river-container.git.

I’m all for switching to git, but we need to actually discuss it and
work out the desired workflow and project structure.  For instance,
git doesn’t really encourage long-lived branches in a repository.
So, should we have separate repositories for the 2.2 and 3.0
branches?  Should we split out reggie, outrigger, JERI, etc into
their own repositories/deliverables?  Should we have a set of
repositories that reflect our release engineering processes?  i.e. a
development repo, QA repo, release repo, etc?

Simply “switching to git” and then having one big canonical git
repository that we use exactly the same way as we use svn doesn’t
seem to offer many advantages, really.  If the argument is “but then
we could take Github pull requests”, well, we can already do that
with the git mirrors that are there already.

As far as “svn gets really messy for that kind of merge”, I’m not
convinced that’s a tool issue - the fundamental problem is that the
qa-refactor branch has diverged from the main branch for years
without a release or much attention from anyone but Peter, blowing
away the “develop on trunk” philosophy, and making “diffs” impossible
to evaluate.  No tool is going to help that. We simply need to either
go through it revision by revision, or just accept it as “the way
forward”.  We’ve decided to accept it.

For now, the current “jtsk/trunk” is an unknown factor as much as
“jtsk/skunk/qa-refactor-namespace/trunk”.  I’d suggest renaming
“jtsk/trunk” to “jtsk/abandoned” or something, then rename
“jtsk/skunk/qa-refactor-namespace/trunk” to “jtsk/trunk” and release
from there.  That’s the path of least bikeshedding.

Cheers,

Greg Trasuk



On Sep 22, 2015, at 9:40 AM, Patricia Shanahan <p...@acm.org>
wrote:

For moving to Git, see http://www.apache.org/dev/writable-git

Is the support provided sufficient? How do committers in general
feel about moving River to Git? If it is a good idea, should we do
it before Release 3.0? The alternative might be to rename the
current SVN branch and release from there.

On 9/22/2015 4:31 AM, Bryan Thompson wrote:

SVN gets really messy for this sort of thing.  We wound not
bringing a project with a large delta back to the trunk because
of these issues and just did releases from branches after that.

What kind of support does Apache offer for switching to git?
That might be easier.

Thanks, Bryan

On Mon, Sep 21, 2015 at 4:49 PM, Patricia Shanahan <p...@acm.org>
wrote:


I think the next thing we need to do to make Release 3.0 a
reality is to merge it into the trunk.

If you agree, I would like opinions on the best way to go about
it. Ideally, we will preserve revision history for modules that
have moved from one directory/package to another.

Re: Compatibility

[Patricia Shanahan]

It may be worth thinking about the process for moving a network to 3.0.
Is there a practical strategy other than simultaneous update of the
entire network?

On 9/10/2015 9:55 AM, Dennis Reedy wrote:

I’m not sure this is about release notes. You seem quite keen on
getting 3.0 out the door, while I applaud the urgency, lets not dump
the baby out with the bath water. The net.jini namespace has not been
changed, the implementation of those interfaces has.

I should be able to discover a ServiceRegistrar started from 3.0 from
a 2.x client. The classes required should be dynamically downloaded
with the proxy. The change here that has been aded to jsk-platform
has resulted in classes (org.apache.river.api.util.ID for starters),
not being available. I’m not so sure this is good. It’s certainly not
a good thing for projects that may want to use existing tools for
discovery.

Regards

Dennis


On Sep 10, 2015, at 1242PM, Bryan Thompson 
wrote:

I guess the question is whether River 2.x is a breaking change in
terms of cross service communications with River 3.x.  As this is a
major release, I see it an opportunity to make breaking changes if
we need to make them. But there is no reason to break
interoperability by accident.

So, are there good reasons why River 2.x will not be able to talk
to River 3.x?  If so, can we capture them here and then summarize
them in release notes?  Is there a specific location in which the
release notes are being developed (SVN file, wiki page, etc.)?

Thanks, Bryan

 Bryan Thompson Chief Scientist & Founder SYSTAP, LLC 4501
Tower Road Greensboro, NC 27410 br...@systap.com
http://blazegraph.com http://blog.bigdata.com 
http://mapgraph.io

Blazegraph™  is our ultra
high-performance graph database that supports both RDF/SPARQL and
Tinkerpop/Blueprints APIs.  Blazegraph is now available with GPU
acceleration using our disruptive technology to accelerate
data-parallel graph analytics and graph query.

CONFIDENTIALITY NOTICE:  This email and its contents and
attachments are for the sole use of the intended recipient(s) and
are confidential or proprietary to SYSTAP. Any unauthorized review,
use, disclosure, dissemination or copying of this email or its
contents or attachments is prohibited. If you have received this
communication in error, please notify the sender by reply email and
permanently delete all copies of the email and its contents and
attachments.

On Thu, Sep 10, 2015 at 12:37 PM, Dennis Reedy
 wrote:


Hi,

I’m building and running an example that I based off of Greg’s
example from the qa-refactor-namespace branch. I had a browser
utility that I use at times running that is based on 2.2.2. I
could not discover reggie with the browser utility because of

Caused by: java.lang.ClassNotFoundException:
org.apache.river.api.util.ID at
java.net.URLClassLoader$1.run(URLClassLoader.java:372) at
java.net.URLClassLoader$1.run(URLClassLoader.java:361) at
java.security.AccessController.doPrivileged(Native Method) at
java.net.URLClassLoader.findClass(URLClassLoader.java:360)

The org.apache.river.api.util.ID class is an interface:

/** * A mix in interface that provides an identity to be used as
a key in Collections. * * @param  Object identity. * @author
peter */ public interface ID {

/** * @return object representing identity, usually a Uuid. */
public T identity(); }

Seems to be used by the following classes:

./src/org/apache/river/fiddler/FiddlerLease.java:import
org.apache.river.api.util.ID;
./src/org/apache/river/impl/lease/AbstractLeaseMap.java:import
org.apache.river.api.util.ID;
./src/org/apache/river/landlord/LandlordLease.java:import
org.apache.river.api.util.ID;
./src/org/apache/river/lease/AbstractLease.java:import
org.apache.river.api.util.ID;
./src/org/apache/river/reggie/RegistrarLease.java:import
org.apache.river.api.util.ID;

Perhaps org.apache.river.api.util.ID should be in jsk-dl.jar
instead?

As a user I might expect that I should be able to use Apache
River 3.0 services from 2.x (perhaps not the other way around).
What do others think?

Regards

Dennis

Re: Compatibility

[Patricia Shanahan]

On 9/10/2015 4:37 PM, Peter wrote:
...

Now that the project has decided the only api is net.jini.* it would
seem appropriate to move the org.apache.river.api packages into
org.apache.river.

...

Have we decided that?

In general principle, in order to move forward, we need somewhere to add 
API that is not part of the Jini standard.


My main agenda is that there should be a clear distinction between what 
we intend to support long term as API vs. implementation code that can 
change from release to release.

Re: Compatibility

[Patricia Shanahan]

If reflection does turn out to be too slow, could we catch 
java.lang.NoSuchMethodError?


On 9/10/2015 6:34 PM, Peter wrote:

The change was made for River-336.

Can we refactor the Proxy's to use reflection, first discover if the the
method exists, if not revert to RMIClassLoader.getClassAnnotation?

This affects proxy's for Reggie, Outrigger and Norm.

Regards,

Peter.


On 11/09/2015 10:36 AM, Dennis Reedy wrote:

Hi Perter,

I don’t know if this one is fixable. There are changes to
net.jini.loader.ClassLoading, that force incompatibility with it’s
predecessor. I get this for starters:

java.lang.NoSuchMethodError:
net.jini.loader.ClassLoading.getClassAnnotation(Ljava/lang/Class;)Ljava/lang/String;

at
org.apache.river.reggie.EntryClassBase.setCodebase(EntryClassBase.java:54)

at
org.apache.river.reggie.ClassMapper.toEntryClassBase(ClassMapper.java:156)

at
org.apache.river.reggie.ClassMapper.toEntryClassBase(ClassMapper.java:117)

at org.apache.river.reggie.EntryClass.toClass(EntryClass.java:180)
at org.apache.river.reggie.EntryRep.get(EntryRep.java:98)
at org.apache.river.reggie.EntryRep.toEntry(EntryRep.java:202)
at org.apache.river.reggie.Item.get(Item.java:160)
at org.apache.river.reggie.Item.toServiceItem(Item.java:185)
at org.apache.river.reggie.Matches.get(Matches.java:63)
at
org.apache.river.reggie.RegistrarProxy.lookup(RegistrarProxy.java:128)
at net.jini.core.lookup.ServiceRegistrar$lookup.call(Unknown Source)

Dennis


On Sep 10, 2015, at 636PM, Peter  wrote:

Thanks Dennis,

Well spotted.

This class shouldn't be in platform.jar, it should be in jsk-lib.jar
and jsk-dl.jar

It's used by org.apache.river.impl.lease.AbstractLeaseMap, which is a
replacement for org.apache.river.lease.AbstractLeaseMap.

It's also used by FiddlerLease, LandlordLease and RegistrarLease.

FiddlerLeaseMap, LandlordLeaseMap and RegistrarLeaseMap all extend
the replacement AbstractLeaseMap.

This is the javadoc from the new AbstractLeaseMap:

/**
* AbstractLeaseMap is intended to work around some minor design warts
in the
* {@link Lease} interface:
*
* In the real world, when a Lease is renewed, a new Lease contract
document
* is issued, however when an electronic Lease is renewed the Lease
expiry
* date is changed and the record of the previous Lease is lost.
Ideally the
* renew method would return a new Lease.
*
* Current Lease implementations rely on a {@link Uuid} to represents
the lease,
* the expiry date is not included the equals or hashCode
calculations.  For this
* reason, two Lease objects, one expired and one valid, may be equal,
this
* is undesirable.
*
* The Lease interface doesn't specify a contract for equals or hashCode,
* all Lease implementations are also mutable, previous implementations
* of {@link LeaseMap} used Leases as keys.
*
* AbstractLeaseMap uses only the {@link ID}, usually a {@link Uuid}
* provided by a Lease for internal map keys, if {@link ID} is not
implemented
* then the Lease itself is used as the key.
*
* Both Lease keys and Long values are actually stored internally as
values
* referred to by ID keys, allowing Lease implementations to either
not override
* hashCode and equals object methods or allow implementations that more
* accurately model reality.
*
* This implementation is thread safe, concurrent and doesn't require
external
* synchronization.

Regards,

Peter.


On 11/09/2015 2:55 AM, Dennis Reedy wrote:

I’m not sure this is about release notes. You seem quite keen on
getting 3.0 out the door, while I applaud the urgency, lets not dump
the baby out with the bath water. The net.jini namespace has not
been changed, the implementation of those interfaces has.

I should be able to discover a ServiceRegistrar started from 3.0
from a 2.x client. The classes required should be dynamically
downloaded with the proxy. The change here that has been aded to
jsk-platform has resulted in classes (org.apache.river.api.util.ID
for starters), not being available. I’m not so sure this is good.
It’s certainly not a good thing for projects that may want to use
existing tools for discovery.

Regards

Dennis


On Sep 10, 2015, at 1242PM, Bryan Thompson   wrote:

I guess the question is whether River 2.x is a breaking change in
terms of
cross service communications with River 3.x.  As this is a major
release, I
see it an opportunity to make breaking changes if we need to make
them.
But there is no reason to break interoperability by accident.

So, are there good reasons why River 2.x will not be able to talk
to River
3.x?  If so, can we capture them here and then summarize them in
release
notes?  Is there a specific location in which the release notes are
being
developed (SVN file, wiki page, etc.)?

Thanks,
Bryan


Bryan Thompson
Chief Scientist&   Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@systap.com
http://blazegraph.com
http://blog.bigdata.com
http://mapgraph.io

Re: Don't let Jini Standards become an impediment to development

[Patricia Shanahan]

Peter,

It is absolutely essential to do this in 3.0, rather than e.g. in 3.1?

I propose freezing 3.0 except for fixing significant regressions and 
integrating custard-apple, so we can get it out the door.


Patricia

On 9/9/2015 4:04 PM, Peter wrote:

In order to enable defensive copying of Entries within SDM or
LookupCache, as per Greg's suggestion, we need to make AbstractEntry
implement Cloneable.

At present, ServiceItem is Cloneable, but only a shallow copy of the
attributes array is made, so user expectations won't be realised, unless
Entries are also Cloneable.

I'll make the changes and commit, thank you for assisting to solve an
important problem within the api.

Bryan, did you want to make the changes to the api documentation, as per
your suggestion?

Regards,

Peter.

On 10/09/2015 6:56 AM, Bryan Thompson wrote:

So can we capture this information about snapshots in the service
interface
javadoc?  For example,

LookupCache::

ServiceItem[]

lookup(ServiceItemFilter

filter,
int maxMatches)

ServiceItem[] array whose elements each satisfy the filter, and that were
previously discovered to be registered with one or more lookup
services in
the managed set. An empty array will be returned if noServiceItem is
found
that matches the criteria or if the cache is empty.

We can state that the returned ServiceItem[] contains a snapshot of the
discovered ServiceItems, that changes to the returned array do not effect
the LookupCache, etc.

Or

JoinManager

public JoinManager(Object


serviceProxy,
Entry
[]
attrSets,
ServiceID

serviceID,
DiscoveryManagement


discoveryMgr,
LeaseRenewalManager


leaseMgr)
 throws IOException




attrSets - array of Entry consisting of the attribute sets with which to
register the service

The documentation for attrSets could state that a snapshot of the
attributes will be made by the JoinManager.

I freely admit that there could be a lot of places where such
clarification
might be added.

This suggests an obvious tradeoff between applying what is basically the
same change to a bunch of javadoc annotations (and verifying in each case
that this is true of the implementation, or simply assuming that it is
true
of the contract for that implementation?) and adding a package.html or
wiki
page that discusses the contract for Entry and Entry[] and captures the
outputs of this discussion. And then point people to that contract.

I would personally opt for the latter. Maybe as part of a FAQ dealing (in
this case) with River and concurrency.

Thanks,
Bryan




Bryan Thompson
Chief Scientist&  Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@systap.com
http://blazegraph.com
http://blog.bigdata.com
http://mapgraph.io

Blazegraph™  is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  Blazegraph is now available with GPU acceleration using our
disruptive
technology to accelerate data-parallel graph analytics and graph query.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please
notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

On Wed, Sep 9, 2015 at 4:19 PM, Greg Trasuk
wrote:


On Sep 9, 2015, at 10:20 AM, Bryan Thompson  wrote:

I have found this to be a very interesting conversation.  My own
bias is,
we are talking about 4.0. Let's focus on releasing 3.0 ;-)


Don’t get me started :-)


I completely understand Peter's concerns about reasoning about
visibility
for concurrency.

I understand from Greg that the visibility comes from the network

barrier.

How does this play out when changes are published into either a service

or

a client cache for the attributes used to publish or discover a proxy?
This would seem to be the place where there is an opportunity for
concurrency issues.

Looking at
http://river.apache.org/doc/api/net/jini/core/lookup/ServiceItem.html,
I
see that the ServiceItem is three fields:

Re: Questions about the Reference Collection dependencies. Was: Re: Release 3.0

[Patricia Shanahan]

+1

On 9/1/2015 7:35 AM, Bryan Thompson wrote:

Peter,

I hardly think it matters.  It just needs to be checked in under
org.apache.river as far as I understand it.  So my suggestion was:

org.apache.river.concurrent

Probably do this in Dennis's branch:
https://svn.apache.org/repos/asf/river/jtsk/skunk/qa-refactor-namespace/trunk/

Once checked in as source, the dependency imports can be changed to use the
new namespace.  I am willing to volunteer to make that code change if it
reduces your burden and moves us closer to a release.  I expect that this
is just running a script over the imports to change the package names from
au.net.zeus to org.apache.river.concurrent.

Thanks,
Bryan



Bryan Thompson
Chief Scientist & Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@systap.com
http://blazegraph.com
http://blog.bigdata.com <http://bigdata.com>
http://mapgraph.io

Blazegraph™ <http://www.blazegraph.com/> is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  Blazegraph is now available with GPU acceleration using our disruptive
technology to accelerate data-parallel graph analytics and graph query.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

On Tue, Sep 1, 2015 at 8:38 AM, Peter <j...@zeus.net.au> wrote:


Where would you like the code committed?  The less work for me, the faster
it will happen.

Regards,

Peter.

On 1/09/2015 12:36 AM, Greg Trasuk wrote:


Yes and no.  He put the sources in a jar file inside the deps-lib/rc-libs
folder in the qa-refactor branch.

Branch is at:
https://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk/<
https://svn.apache.org/repos/asf/river/jtsk/skunk/qa_refactor/trunk/>

or Dennis’s namespace refactoring at


https://svn.apache.org/repos/asf/river/jtsk/skunk/qa-refactor-namespace/trunk/
<
https://svn.apache.org/repos/asf/river/jtsk/skunk/qa-refactor-namespace/trunk/





Cheers,

Greg Trasuk

On Aug 31, 2015, at 10:18 AM, Bryan Thompson<br...@systap.com>  wrote:


I am pretty sure Peter also indicated that the code is in fact checked in
to apache river right now - part of the qa branch as I recall.  Thus it
is
already contributed by Peter.  Right?  I believe that all that is
required
is a package rename into org.apache.river

Can someone please confirm the current branch and how to check it out?
Per
[1], this would be the trunk.  I just would like to make sure that I am
looking at the right branch for these discussions.

svn checkout http://svn.apache.org/repos/asf/river/jtsk/trunk river


Thanks,
Bryan

[1] https://river.apache.org/source-code.html


Bryan Thompson
Chief Scientist&  Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@systap.com
http://blazegraph.com
http://blog.bigdata.com<http://bigdata.com>
http://mapgraph.io

Blazegraph™<http://www.blazegraph.com/>  is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  Blazegraph is now available with GPU acceleration using our
disruptive
technology to accelerate data-parallel graph analytics and graph query.

CONFIDENTIALITY NOTICE:  This email and its contents and attachments are
for the sole use of the intended recipient(s) and are confidential or
proprietary to SYSTAP. Any unauthorized review, use, disclosure,
dissemination or copying of this email or its contents or attachments is
prohibited. If you have received this communication in error, please
notify
the sender by reply email and permanently delete all copies of the email
and its contents and attachments.

On Mon, Aug 31, 2015 at 10:07 AM, Patricia Shanahan<p...@acm.org>
wrote:

Although Peter has indicated approval, from a licensing point of view it

might be best if he were the one to check it in.


On 8/31/2015 6:11 AM, Bryan Thompson wrote:

Fine by me.  I am pretty sure Peter already indicated approval for this.

I
was just offering to help remove a potential blocker for the release.

+1 for publishing apple custard as a river artifact.

Bryan


Bryan Thompson
Chief Scientist&  Founder
SYSTAP, LLC
4501 Tower Road
Greensboro, NC 27410
br...@systap.com
http://blazegraph.com
http://blog.bigdata.com<http://bigdata.com>
http://mapgraph.io

Blazegraph™<http://www.blazegraph.com/>  is our ultra high-performance
graph database that supports both RDF/SPARQL and Tinkerpop/Blueprints
APIs.  Blazegraph is now available with GPU acceleration using our
disruptive
technology to accelerate data-parallel graph analy

Re: River Musings

[Patricia Shanahan]

On 8/31/2015 4:07 PM, Bryan Thompson wrote:
...

Why use net.jini.* rather than net.river.*?


Do mean "net.river" rather than "org.apache.river"?

We have domain names jini.net and river.apache.org, and can base package 
names on either of those. If we want to use anything else, we would need 
to acquire the corresponding domain name.


In my opinion, for branding reasons, we should use org.apache.river.* 
wherever possible.

Re: River Musings

[Patricia Shanahan]

On 8/31/2015 4:07 PM, Bryan Thompson wrote:
...

Apologies if I am behind the curve here.  It would probably be easier for
me to understand if the package namespace cleanup was proposed as a list of
X => Y renames so I could look at the source tree and understand more
clearly what is involved.

...

Good idea. It may be useful for the release notes, as well as for our
discussion. I have started putting one together. Here is an arbitrary
extract from the raw data:

names_2.2.txt:./com/sun/jini/action/GetBooleanAction.java
names_2.2.txt:./com/sun/jini/action/GetIntegerAction.java
names_2.2.txt:./com/sun/jini/action/GetLongAction.java
names_2.2.txt:./com/sun/jini/action/GetPropertyAction.java
names_3.0.txt:./org/apache/river/action/GetBooleanAction.java
names_3.0.txt:./org/apache/river/action/GetIntegerAction.java
names_3.0.txt:./org/apache/river/action/GetLongAction.java
names_3.0.txt:./org/apache/river/action/GetPropertyAction.java

The "action" package keeps the same content. It changed from
com.sun.jini.action to org.apache.river.action. That loses the strong
internal-only use-at-your-own-risk implication that the com.sun packages
had, so we need to do something else to mark these classes as not
supported API.

I will continue to work on building the package map.

Patricia