Re: [DISCUSS] Moving Apache River to the Attic

[Dan Rollo]

I agree it is time.

Well said Jeremy! Thanks for sharing.
I have fond memories of Jini conferences in Chicago and Brussels (even if all I 
remember is the Delirium Cafe).

Dan Rollo


> On Feb 9, 2022, at 10:03 AM, Jeremy R. Easton-Marks 
>  wrote:
> 
> I, sadly, agree that it is time to move this project to the Attic. While I
> hoped to work on this as a side project, I have not been able to carve out
> time for it. While I do think this project has a lot of potential, without
> some type of sponsorship in time and resources I don't see it moving
> forward. Thank you Roy for stepping up as the chair as well as the rest of
> the River team for contributing to this project over the years. It has been
> great watching the discussions in these threads.
> 
> On a personal note, seeing this project move into the Attic while sad, it
> will hopefully be cathartic. My father, Peter C. Marks, was one of the
> original developers at Sun who worked on Jini. I remember him being very
> excited about the potential for the technology and he enjoyed demoing it. I
> even remember accompanying him to Amsterdam to demo it at a conference when
> I was younger. I have some of the original Jini books sitting in my office
> right now that have been signed by some of the original team members.
> 
> I had hoped to see the project keep going, maybe with it moving into the
> Attic River can move forward in a different way.
> 
> On Mon, Feb 7, 2022 at 6:41 PM Roy T. Fielding  wrote:
> 
>> Hello everyone,
>> 
>> It's that time of year when I try to figure out what I am doing and
>> what I am not, and try to cut back on the stuff that seems unlikely
>> to succeed. I suspect the same is true of others.
>> 
>> I had hoped that more new people at River would result in more activity,
>> but that hasn't occurred over the past 9 months and doesn't seem likely
>> in the future. Aside from ASF echoes and Infra-driven website replacement,
>> there has been nothing to report about River the entire time that I have
>> been the chair pro tem, and there hasn't been any chatter by users either.
>> 
>> Please feel free to let me know if I am missing something.
>> 
>> If not, I'd like us to accept the reality of this situation and move the
>> River project to the Attic. The code will still be available there, and
>> folks are welcome to copy it under the license, move it to Github, or
>> otherwise seek to re-mold it into a collaborative project wherever is
>> most convenient for them.
>> 
>> Cheers,
>> 
>> Roy
>> 
>> 
> 
> -- 
> Jeremy R. Easton-Marks
> 
> "être fort pour être utile"

Re: Patricia Shanahan

[Dan Rollo]

Well said. She was always positive and helpful.

Dan

> On Jul 19, 2021, at 5:03 PM, Gregg Wonderly  wrote:
> 
> That’s sad news Roy!  Thanks for letting everyone know and for your warm 
> insight into her contributions!
> 
> Gregg Wonderly
> 
>> On Jul 19, 2021, at 11:56 AM, Roy T. Fielding  wrote:
>> 
>> We received the sad news last week that our friend and PMC member,
>> Patricia Shanahan, has passed away peacefully after a long battle
>> with cancer. I have put together a memorial page for her at
>> 
>>  https://www.apache.org/memorials/patricia_shanahan.html 
>> 
>> 
>> and will eventually update the River site as well. Please let me know
>> if you would like to add anything to that page.
>> 
>> Roy
>> 
> 

Re: Call for PMC volunteers for Apache River

[Dan Rollo]

I’m in the same boat as Phil, but happy to volunteer.

Dan Rollo

> On Mar 12, 2021, at 4:22 PM, Phillip Rhodes  wrote:
> 
> I haven't contributed much, but I will offer myself up as a volunteer
> nonetheless.
> 
> 
> Phil
> 
> 
> On Fri, Mar 12, 2021 at 9:34 AM Dennis Reedy  wrote:
>> 
>> Roy,
>> 
>> I'd be interested in volunteering as well.
>> 
>> Regards
>> 
>> Dennis Reedy
>> 
>> On Thu, Mar 11, 2021 at 6:29 PM Roy T. Fielding  wrote:
>> 
>>> Hello again,
>>> 
>>> The River project seems to be short on PMC members, which is a
>>> problem for Apache projects because we require at least three active
>>> PMC members to continue.
>>> 
>>> This is a call for volunteers. If you would like to be on the River PMC
>>> and have demonstrated some form of contribution to the project
>>> (via email, bug reports, documentation, testing, teaching, etc.),
>>> please respond to this message. It doesn't have to be a huge
>>> contribution -- just enough to show that your heart is in the right
>>> place and you are willing to contribute.
>>> 
>>> After we collect a list of volunteers (if any), I will ask the board to
>>> consider a resolution to recreate the PMC from that list, plus
>>> Patricia Shanahan and Bryan Thompson (who have already
>>> volunteered to continue on the PMC).
>>> 
>>> Cheers,
>>> 
>>> Roy T. Fielding
>>> Board Chair, The Apache Software Foundation
>>> 
>>> 

Git conversion (was Re: Project Health / Interest)

[Dan Rollo]

Hi Peter,

Silly questions to follow.

I found the empty repo at: river-ldj-tests.git 
<https://git.apache.org/repos/asf/river-ldj-tests.git>  
(https://git.apache.org/repos/asf/river-ldj-tests.git)

As a sanity check: Is the one to migrate from?: 
http://svn.apache.org/repos/asf/river/jtsk/trunk

While I agree refactoring of the project structure into separate, stand alone 
git repos would be an improvement, I’m wondering if a safer first step would be 
to move the svn repo to git as is? That way, we start from a working state in 
git, and preserve all the svn history. From there, we can start to “break 
things” (literally and figuratively) into smaller repos. The underlying 
assumption is just about everything will be easier to do (merging, etc) with a 
git repo.

Either way, I’ll start looking for lines along which I could break things.

Dan


> On Feb 9, 2021, at 3:42 AM, Peter Firmstone  
> wrote:
> 
> Thanks Dan,
> 
> https://infra.apache.org/svn-to-git-migration.html
> 
> https://gitbox.apache.org/setup/newrepo.html
> 
> http://svn.apache.org/viewvc/river/
> 
> https://gitbox.apache.org/repos/asf#river
> 
> I just created a git repository for the "Apache river JiniTM Technology 
> Lookup, Discovery, and Join Compatibility Kit", I figure it might be easier 
> to start with something that's had relatively few commits as an experiment.
> 
> But basically everything we have on svn needs to be broken up into separate 
> projects, typical of what people are used to seeing on github.
> 
> The QA test suite is an ant build project, it's currently part of trunk, but 
> I was thinking of separating it out into it's own build.
> 
> On 9/02/2021 12:31 pm, Dan Rollo wrote:
>> Hi Peter,
>> 
>> I’m apologize for not being more help. I haven’t had much time of late. Is 
>> there a thread I could pull regarding the Git migration? Where to start?
>> 
>> The plan you itemize makes sense to me.
>> 
>> Dan Rollo
>> 
>>> On Feb 8, 2021, at 8:35 PM, Peter Firmstone  
>>> wrote:
>>> 
>>> Hello River folk,
>>> 
>>> There's an upcoming board report due shortly, I wanted to gauge people's 
>>> interest in the project.
>>> 
>>> We've got two pending tasks:
>>> 
>>> 1. SVN to Git Migration
>>> 2. Website migration
>>> 
>>> Following the Git Migration, the plan is to continue with the modular 
>>> build, using gradle?
>>> 
>>> Lately we don't have a lot of participation, I was hoping that we would 
>>> have some more buy in, especially with the Git migration.
>>> 
>>> I don't want to be making decisions alone, are there people on this list 
>>> who have time to assist, are willing to assist or intend to do so in future 
>>> when they have time?
>>> 
>>> -- 
>>> Regards,
>>> Peter Firmstone
>>> 
> -- 
> Regards,
> Peter Firmstone
> 

Re: Project Health / Interest

[Dan Rollo]

Hi Peter,

I’m apologize for not being more help. I haven’t had much time of late. Is 
there a thread I could pull regarding the Git migration? Where to start?

The plan you itemize makes sense to me.

Dan Rollo

> On Feb 8, 2021, at 8:35 PM, Peter Firmstone  
> wrote:
> 
> Hello River folk,
> 
> There's an upcoming board report due shortly, I wanted to gauge people's 
> interest in the project.
> 
> We've got two pending tasks:
> 
> 1. SVN to Git Migration
> 2. Website migration
> 
> Following the Git Migration, the plan is to continue with the modular build, 
> using gradle?
> 
> Lately we don't have a lot of participation, I was hoping that we would have 
> some more buy in, especially with the Git migration.
> 
> I don't want to be making decisions alone, are there people on this list who 
> have time to assist, are willing to assist or intend to do so in future when 
> they have time?
> 
> -- 
> Regards,
> Peter Firmstone
> 

Re: Next steps

[Dan Rollo]

Hi Peter,

Sounds good to me.

If you have any idiot proof tasks, let me know, I’d be happy to help.

Dan


> On Nov 21, 2020, at 6:16 PM, Peter Firmstone  
> wrote:
> 
> Hello River folk,
> 
> What I had in mind next was to SVN move the existing trunk out of the way, 
> then SVN move the modular branch to trunk, then SVN move other relevant code 
> branches we wanted to keep into trunk as well.  Then finally we can ask INFRA 
> to migrate us to git.
> 
> Please feel free to discuss or mention any ideas you have, or if you think it 
> should be done a little differently.  I'd like to retain our SVN history when 
> making the git transition, so we can track everything back to the original 
> Sun Microsystems contribution in 2007.
> 
> For the next fortnight, I'll be in remote Queensland, so hoping to get some 
> time over Christmas to get this done, and all help will be gladly welcomed.
> 
> -- 
> Regards,
> Peter
> 

Re: November Board Report [DRAFT]

[Dan Rollo]

+1

> On Nov 7, 2020, at 10:54 PM, Peter Firmstone  
> wrote:
> 
> Hello River folk,
> 
> Please review or make any suggestions you'd like to communicate to the board.
> 
> Regards,
> 
> Peter.
> 
> The River project typically operates in maintenance mode, however there is an 
> ongoing long term undertaking to make River's monolithic codebase modular.
> 
> The project has voted to move from SVN to Git.
> 
> The modules branch will become the trunk branch after the next release, this 
> modular build has been a significant undertaking, hence the long time since 
> the project's last release.
> 
> ## Description:
> The mission of River is the creation and maintenance of software related to
> Jini service oriented architecture
> 
> ## Issues:
> No issues warranting attention at this time.
> 
> ## Membership Data:
> Apache River was founded 2011-01-19 (10 years ago)
> 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.
> - Recently we have received new contributions and we are likely to see new 
> additions in the near future.
> 
> 
> ## Project Activity:
> 
> 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.
> 
> ## Community Health:
> dev@river.apache.org had a 75% decrease in traffic in the past quarter (24 
> emails compared to 96)
> 
> ## Busiest email threads:
> 
> * dev@river.apache.org/[VOTE]: make trunk an unstable development
>   branch./(8 emails)
> * dev@river.apache.org/Example Gradle Buuild/(4 emails)
> * dev@river.apache.org/August Board Report [DRAFT]/(3 emails)
> * dev@river.apache.org/Your project website/(2 emails)
> * dev@river.apache.org/Why jtreg/(2 emails)
> * dev@river.apache.org/Git repository/(2 emails)
> * dev@river.apache.org/Serialization and serial form/(1 emails)
> * dev@river.apache.org/Java Deserialization CVE's/(1 emails)
> * dev@river.apache.org/Problems starting Infra services with new
>   build/(1 emails)
> 

Odd compile error, not sure why

[Dan Rollo]

Hi Peter,

I was looking into a build failure I saw in JGDMS, and saw something odd:

On my local machine, I’m seeing the compile error below (using jdk 11 [openjdk 
version "11.0.6" 2020-01-14] or jdk 8 [java version “1.8.0_221"]):

[ERROR] Failed to execute goal 
org.apache.maven.plugins:maven-compiler-plugin:3.8.1:compile (default-compile) 
on project outrigger-dl: Compilation failure: Compilation failure: 
[ERROR] 
/Users/bhamail/javadev/github/bhamail/JGDMS/JGDMS/services/outrigger/outrigger-dl/src/main/java/org/apache/river/outrigger/proxy/EntryRep.java:[492,68]
 unreported exception java.lang.NoSuchMethodException; must be caught or 
declared to be thrown
[ERROR] 
/Users/bhamail/javadev/github/bhamail/JGDMS/JGDMS/services/outrigger/outrigger-dl/src/main/java/org/apache/river/outrigger/proxy/EntryRep.java:[492,82]
 unreported exception java.lang.reflect.InvocationTargetException; must be 
caught or declared to be thrown


I can easily fix this by adding additional “catch” blocks. I will gladly push a 
PR if it makes sense to do so.

What has me confused is my CI build is not getting this compile error, and I’m 
not sure why.

Looking forward to learning what you think might cause this.

Dan

Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for River

[Dan Rollo]

Phil,

If nothing else comes of this, I want to thank you for the phrase "FSM help 
me”. I had to look it up, and had a huge grin reading the wikipedia page I 
found. Wow!

Any way, I think Peter’s work includes much of the conversion to a build using 
maven modules. I am not maven averse, but neither am I gradle negative. My 
enthusiasm for the maven build is based on a hope it would lead to clearer 
delineation of  components (some of which share the same source code, but 
produce separate jars with some of the same class files as needed). I’d be 
happy to lend a hand with any maven issue that pops up, but would not lambast a 
gradle approach.

Dan


> Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss attic for 
> River
>   12518 by: Phillip Rhodes
> 
> Administrivia:
> 
> -
> To post to the list, e-mail: dev@river.apache.org
> To unsubscribe, e-mail: dev-digest-unsubscr...@river.apache.org
> For additional commands, e-mail: dev-digest-h...@river.apache.org
> 
> --
> 
> 
> From: Phillip Rhodes 
> Subject: Re: Gradle Build [PREVIOUSLY] Re: Board feedback - Request discuss 
> attic for River
> Date: July 1, 2020 at 10:10:29 PM EDT
> To: dev@river.apache.org
> Cc: Michael Sobolewski , dennis.re...@gmail.com
> 
> 
> A Gradle build would be nice. I'm willing to invest some time trying
> to help make it happen if need be. But I am curious.., it looks like
> someone started a Maven build a while back.. From what I can see it
> seems to maybe be incomplete, or just bit-rotted. But depending on the
> details of the state of that work, would there be any reason to prefer
> sticking with maven? (FSM help me, I can't believe I just said that in
> a public forum).
> 
> I'm not the biggest Maven fan in the world, so I only raise this issue
> from the "can we use existing work instead of starting from scratch"
> perspective.
> 
> 
> Phil
> 
> 
> 

Re: Proxy identity behaves unexpectedly for secure services.

[Dan Rollo]

I don’t know the historical reason for the proxy identity changing behavior you 
describe.
Assuming no good reason to keep it, I’m +1 to remove MethodConstraints from the 
proxy identity logic.

Dan


From: Peter Firmstone 
Subject: Proxy identity behaves unexpectedly for secure services.
Date: May 26, 2020 at 4:10:50 AM EDT
To: dev@river.apache.org


Hello River folk.

As you are probably aware, I have an interest in security and have been focused 
on simplifying the use of secure services.

In JGDMS the qa suite runs in jsse mode, which means the majority of tests are 
run with a login Subject and services use SSL/TLS Endpoints.

A number of tests that passed with non secure Endpoint's failed with SSL/TLS 
Endpoints. Activation also failed, like the failing tests, it made assumptions 
on proxy identity.

One of the problems I faced was proxy identity is defined by the underlying 
InvocationHandler's equals method, namely that of BasicObjectEndpoint.

BasicObjectEndpoint was including the client's MethodConstraints in the Proxy's 
identity.

This meant the service proxy's identity changed after the client applied 
constraints, and as a result, the tests weren't passing because the proxy's 
identity wasn't as expected.   Also Activation would fail as the ActivationID 
would be different.

A code comment in placed in ActivatableInvocationHandler:activate0() method, 
for working around this issue.

/* Equality of ActivationID instances are influenced by the
 * equality of their Activator proxy's InvocationHandler,
 * when client constraints differ, and everything else is
 * identical, they will not be equal.  Proxy's deserialized
 * by atomic input streams will inherit the constraints of
 * the stream from which they were deserialized. */

//if (!id.equals(handler.id)) {
if (id.hashCode() != handler.getActivationID().hashCode()) { // Same 
UID.
StringBuilder sb = new StringBuilder(128);
sb.append("unexpected activation id: ")
.append(handler.getActivationID())
.append(" expected: ")
.append(id);
throw new ActivateFailedException(sb.toString());
}


It got worse when I implemented AtomicILFactory, in Atomic streams, when 
proxy's are unmarshalled, they inherit any client constraints applied to the 
stream, to prevent elevation of privilege gadget attacks, where a third party 
proxy might bypass an integrity or privacy constraint for instance such as 
allow a connection that wasn't encrypted, or not authenticated.   Again this 
changed feature the identity of the proxy and tests failed as the proxy the 
test had to confirm the test passed didn't have client constraints applied.

So it appears to me that client's MethodConstraints shouldn't be part of proxy 
identity.

Does anyone have a good reason why client MethodConstraints should be part of 
proxy identity?   It doesn't seem right to me that the client is able to change 
the identity of a proxy, just by applying constraints.

This seems to have been overlooked in the implementation.

Also as a side note, I needed to make a lot of changes to existing services to 
support secure endpoints, as the server's often didn't reply to call back 
proxy's using their Subject, for example EventLIstener's didn't work in a 
secure environment.  I fixed that of course.

These are changes I'd like to make to River, to make secure services behave 
like insecure services, but with security. :)  So that security can be a 
configuration concern.   So new developers can develop and test their 
application, later configure it to be secure without it breaking.

Thanks,

Peter.

Re: Board feedback - Request discuss attic for River

[Dan Rollo]

Regarding a gradle build: 
I’m not against a gradle build, but I’m by no means a gradle expert.

For the initial modular build, I think the “opinionated” nature of maven is 
helpful in providing some guard rails, but that could just be a function of me 
having more familiarity with maven.

Dan

Re: Board feedback - Request discuss attic for River

[Dan Rollo]

Hi Peter,

I acknowledge the contributions are slow to come, but I agree with your 
observation that contributions are still coming. I would prefer the River 
project not be moved to the attic just yet. (“I don’t want to go on the cart. I 
feel better”….to soon? ;)

Dan


From: Peter Firmstone 
Subject: Board feedback - Request discuss attic for River
Date: May 20, 2020 at 8:51:42 PM EDT
To: dev@river.apache.org


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: dev Digest 7 May 2020 15:27:04 -0000 Issue 1659

[Dan Rollo]

+1

Oddly enough, I work remotely, and it seems things are busier than 
pre-pandemic. 

Thankfully, healthy so far. Happy hermit life.

Dan



> On May 7, 2020, at 11:27 AM, dev-digest-h...@river.apache.org wrote:
> 
> From: Peter Firmstone  <mailto:peter.firmst...@zeus.net.au>>
> Subject: Draft Report River - May 2020
> Date: May 7, 2020 at 3:31:09 AM EDT
> To: dev@river.apache.org <mailto:dev@river.apache.org>
> 
> 
> 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.
> 

February Board Report Draft

[Dan Rollo]

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.

Re: August Board Report - Draft

[Dan Rollo]

+1 

Dan

From: Peter Firmstone mailto:peter.firmst...@zeus.net.au>>
Subject: August Board Report - Draft
Date: August 9, 2019 at 7:51:12 PM EDT
To: "mailto:dev@river.apache.org>>" 
mailto:dev@river.apache.org>>


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 <mailto: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 <mailto: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

Re: River Board Report

[Dan Rollo]

+1

Dan


From: Peter Firmstone mailto:peter.firmst...@zeus.net.au>>
Subject: River Board Report
Date: June 5, 2019 at 5:04:37 PM EDT
To: "mailto:dev@river.apache.org>>" 
mailto:dev@river.apache.org>>

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 <mailto: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 <mailto:u...@river.apache.org>:
   - 90 subscribers (down -2 in the last 3 months):
   - 1 emails sent to list (0 in previous quarter)

Re: River Board Report

[Dan Rollo]

+1

Dan


From: Peter Firmstone mailto:peter.firmst...@zeus.net.au>>
Subject: River Board Report
Date: March 19, 2019 at 7:58:14 PM EDT
To: "mailto:dev@river.apache.org>>" 
mailto:dev@river.apache.org>>


Hello River folk, please review / comment / suggest / changes for the draft 
board report for March 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:
- Answers to board questions:
idf: It's been a year since the last committer addition. Are there a
new prospects?
- Not at present, due to low activity and the complexity of the unique 
monolithic build system.  We are working to resolve this with a Maven modular 
build structure.

rs: given 12 vs 16 members of PMC and committership roster, is there
   anything preventing the remaining 4 committers to consider
   joining the PMC?
- There are no blockers, I will ask them to join the PMC.

## 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

## /dist/ errors: 4
- TODO - Developer certificates expired, investigate solution.   I created new 
certificates, prior to the expiry of my old certificates, should I resign the 
release artifacts with the new certificates?

## Mailing list activity:

- Relatively quiet

- dev@river.apache.org <mailto:dev@river.apache.org>:
   - 89 subscribers (down -1 in the last 3 months):
   - 5 emails sent to list (9 in previous quarter)

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

Re: November Board Report

[Dan Rollo]

+ 1

Dan

> From: Peter Firmstone 
> Subject: November Board Report
> Date: November 17, 2018 at 5:03:05 AM EST
> To: "" 
> 
> 
> 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:
> 
> - No significant issues requiring board attention at this time.
> 
> ## Activity:
> 
> -  Minimal activity at present, initial work modular build structure has 
> commenced, awaiting to be populated with River 3.0 code.
> 
> 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:
> 
> - Relatively quiet.
> 
>  - dev@river.apache.org:
>- 91 subscribers (down -3 in the last 3 months):
>- 7 emails sent to list (6 in previous quarter)
> 
> - u...@river.apache.org:
>- 92 subscribers (up 0 in the last 3 months):
>- 1 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: May Board Report

[Dan Rollo]

+1 , The report looks fine to me.

Dan

From: Bryan Thompson >
Subject: Re: May Board Report
Date: May 13, 2018 at 9:58:35 AM EDT
To: dev@river.apache.org 


Peter, the report is Ok.

+1

Bryan

On Sat, May 12, 2018 at 17:07 Peter Firmstone >
wrote:

Re: River-452 Review proposed changes to standards.

[Dan Rollo]

Hi Peter,

I started to try and find 'River-452’ in Jira, but can not having any luck 
finding our Jira. What am I missing?

The JIRA link on this page: https://river.apache.org/user-doc/found-a-bug.htm
never returns: http://issues.apache.org/jira/browse/RIVER

-Dan

Re: Draft February Board report.

[Dan Rollo]

+1


Subject: Draft February Board report.
Date: February 17, 2018 at 5:44:29 AM EST
To: "<dev@river.apache.org>" <dev@river.apache.org>


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.

Re: Modular build

[Dan Rollo]

Hi Peter,

I’ll try to pitch in where I can.

Dan


From: Peter 
Subject: Modular build
Date: January 30, 2018 at 5:11:08 AM EST
To: "" 


Hello fellow River folks!

How do we want to start the modular build, should we create a new svn branch 
and replace trunk when it's complete?

I'm just initially looking at creating the build structure and copying across 
the relevant packages.

This will be based on the JGDMS build structure, but with River code from trunk 
as it is now.

Apart from modularity, the JGDMS build also checks for known security bugs and 
uses findbugs to perform static analysis.

Once we've got a modular build working, we can compare the JGDMS code, module 
by module.

Anyone have any spare cycles to help?

Regards,

Peter.

Re: [Report] Apache River - Draft

[Dan Rollo]

+1

-Dan

> 
> From: Peter <j...@zeus.net.au>
> Subject: [Report] Apache River - Draft
> Date: December 1, 2017 at 12:42:51 AM EST
> To: "<dev@river.apache.org>" <dev@river.apache.org>
> 
> 
> Hi River folks,
> 
> Draft board report for November, postponed until December.
> 
> 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:
> 
> Minimal activity at present.
> 
> - Planned relase map:
> 
> 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.
> 
> ## 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:
> 
> - Nil Activity this period.
> 
> 
> 
> 
> 

Re: Change of Chair

[Dan Rollo]

+1

Thank You Patricia for your work!
Duck and cover Peter. ;)

Dan


> From: Rupinder Singh 
> Subject: Re: Change of Chair
> Date: September 22, 2017 at 8:57:25 AM EDT
> To: dev@river.apache.org
> 
> 
> Congrats Peter!
> 
> On 21 Sep 2017 16:09, "Peter"  wrote:
>> 
>> Thank you :)
>> 
>> I can use all the help I can get.
>> 
>> Cheers,
>> 
>> Peter.
>> 
>> 
>> On 21/09/2017 5:59 AM, Patricia Shanahan wrote:
>>> 
>>> 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.
>>> 
>> 
> 
> 

Re: The current plan - path to modularity and JGDMS code donation / integration.

[Dan Rollo]

Hi Peter,

Sounds good to me. +1 (not binding)

Dan

> 
> From: Peter 
> Subject: The current plan - path to modularity and JGDMS code donation / 
> integration.
> Date: September 3, 2017 at 2:52:02 AM EDT
> To: "" 
> 
> 
> Appended below is the reactor build order for JGDMS, although a fork of 
> River, dependencies are determined by imports in code, so River's modules are 
> likely to be very similar (names may differ).
> 
> The plan is to first modularise River, then the code from JGDMS will be 
> donated, one module at a time.   When code from JGDMS has been reviewed and 
> included in a River module, that module will be removed from JGDMS and 
> dependant modules will be dependant on River.  This process will be repeated 
> until there a no modules remaining in JGDMS, at which time that projects 
> front page will be changed to encourage users to migrate to River.
> 
> The order that the code will be donated, reviewed and integrated will be in 
> the Reactor Build Order.  This makes it much easier to review changes.  It 
> also means that breaking changes (if any) will be detected as modules further 
> down on the reactor build order list will only contain River code.
> 
> Tests will be added to the test suite when each relevant module is complete.
> 
> Note that unlike River's source only ant build, the modular build will 
> produce compiled jar files as well.
> 
> [INFO] 
> 
> [INFO] Reactor Build Order:
> [INFO]
> [INFO] JGDMS Project
> [INFO] Module :: JGDMS Collection
> [INFO] Module :: JGDMS Jini Platform
> [INFO] Module :: JGDMS Loader
> [INFO] Module :: JGDMS Jini Extensible Remote Invocation
> [INFO] Module :: JGDMS Resources
> [INFO] Module :: JGDMS URL providers and Integrity
> [INFO] Module :: JGDMS Activation Platform
> [INFO] Module :: JGDMS Service DL Library
> [INFO] Module :: JGDMS Lookup Discovery Providers
> [INFO] Module :: JGDMS Service Library
> [INFO] Module :: JGDMS Service Starter
> [INFO] Module :: JGDMS SharedGroup Destroy
> [INFO] Module :: JGDMS IIOP
> [INFO] Module :: JGDMS JRMP
> [INFO] Module :: JGDMS Service DL Library UI Factory
> [INFO] Module :: Jini 2.1 compatibility
> [INFO] Module :: JSK Platform
> [INFO] Module :: JSK Library
> [INFO] Module :: Outrigger
> [INFO] Module :: Outrigger Service Download classes
> [INFO] Module :: Outrigger Service Implementation
> [INFO] Module :: Outrigger Snaplogstore
> [INFO] Module :: Lookup Service
> [INFO] Module :: Reggie Service Download classes
> [INFO] Module :: Reggie Service Implementation
> [INFO] Module :: Mahalo
> [INFO] Module :: Mahalo Service Download classes
> [INFO] Module :: Mahalo Service Implementation
> [INFO] Module :: Mercury the Event Mailbox
> [INFO] Module :: Mercury Service Download classes
> [INFO] Module :: Mercury Service Implementation
> [INFO] Module :: Norm
> [INFO] Module :: Norm Service Download classes
> [INFO] Module :: Norm Service Implementation
> [INFO] Module :: Group
> [INFO] Module :: Group Service Download classes
> [INFO] Module :: Group Service Implementation
> [INFO] Module :: Fiddler the LookupDiscoveryService
> [INFO] Module :: Fiddler LookupDiscoveryService Download classes
> [INFO] Module :: Fiddler LookupDiscoveryService Implementation
> [INFO] Module :: Tools
> [INFO] Tool :: Check ConfigurationFile
> [INFO] Tool :: Check serialversionUid
> [INFO] Tool :: ClassDep
> [INFO] Tool :: Class Server
> [INFO] Tool :: Compute message digest
> [INFO] Tool :: Compute httpmd codebase
> [INFO] Tool :: Environment Check
> [INFO] Tool :: Jar wrapper
> [INFO] Tool :: Preferred classes list generator
> [INFO] Module :: DebugDyanamicPolicyProvider and SecurityPolicyWriter
> [INFO] Module :: Phoenix Activation
> [INFO] Module :: Phoenix Download
> [INFO] Module :: Phoenix Common
> [INFO] Module :: Phoenix
> [INFO] Module :: Phoenix Group
> [INFO] Module :: Phoenix Init
> [INFO] Module :: Groovy Configuration
> [INFO] JGDMS Distribution
> [INFO] Module :: JGDMS Service Browser
> [INFO] Module :: JGDMS Extra service utilities
> [INFO]
> [INFO] 
> 
> 
> 
> 

Re: On Kerberos Endpoints and other interesting stuff.

[Dan Rollo]

Hi Peter,

I don’t know diddly about Kerberos, but that passive wifi sure looks nifty.

Dan


From: Peter 
Subject: On Kerberos Endpoints and other interesting stuff.
Date: July 20, 2017 at 5:22:44 AM EDT
To: "" 


Anyone out there still using JERI Kerberos?

If so, I'd like to know.

While the JERI Kerberos implementation (including discovery) hasn't been 
testing in a long while (never in the history of Apache River), parts of the 
implementation are shared with other JERI implementations.  The main issue has 
been that testing requires setting up a KDC.

JERI Kerberos supports delegation, so services may act on behalf of logged in 
clients, for example this may be useful to access a database a service utilises.

JERI Kerberos is the last piece of code that still uses sun implementation code:

com.sun.security.jgss.GSSUtil.createSubject(GSSName name, GSSCredential 
credentials)

Basically, this code retrieves the KerberosPrincipal and places the 
KerberosTicket's and KerberosKey's it retrieves from the GSSCredentials into 
the Subject's private credential set.

So the next time the a Kerberos connection is made using this Subject, the 
Principal, tickets and key are used to create the GSSCredentials used to 
establish the next connection.

Anyway, it turns out there's a cross platform way to do the same thing.

Set privateCredentials = new Set();
privateCredentials.add(gssCredentials);
Set principals = new Set();
principals.add(new KerberosPrincipal(gssName.toString()));

Subject clientSubject  = new Subject(true, principals, Collections.emptySet(), 
privateCredentials);

It turns out that the Kerberos provider implementations also look for 
GSSCredential in a Subject's private credentials, so this is a cross platform 
way of performing delegation.

Something else I'm considering Kerberos for is RPC for the IoT space.

Check out lower power passive wifi here:

http://passivewifi.cs.washington.edu/

When it comes to low power, passive wifi, C, Kerberos and RPC aren't a bad 
combination.  All they need is a discovery protocol and a RPC Kerberos jeri 
endpoint, so a registration service can discover them and register them with 
the Jini lookup service.

Cheers,

Peter.

Re: Jini Print API

[Dan Rollo]

minor typo in url (missing . ):

https://github.com/pfirmstone/Jini-Print-API 



From: Peter 
Subject: Jini Print API
Date: May 22, 2017 at 7:00:26 AM EDT
To: "dev@river.apache.org" 


Tommorrow's the 17th anniversary of the release of the Jini print api draft 
standard.

The Jini print api went on to form the basis of the java print api included in 
java 1.4

In 2005, the draft standard (javadoc) was released under the AL2.0 along with 
the rest of the jini standards.

So I've reimplemented the standard from javadoc, bringing it up to date with 
the latest internet printing protocol standard attributes from 2.0, 2.1 and 2.2 
as well as 3D printing, it was originally designed around IPP1.1.  The jini 
print standard api pre dated Jini 2.0, so it's also been brought up to date 
there too.  The attributes can also be used to bring the java print api up to 
date.

Figured it might be useful for the iot push

Get the code here and let me know your thoughts.

https://githubcom/pfirmstone/Jini-Print-API

Cheers,

Peter.

Sent from my Samsung device.

Re: [Report] Apache River - Draft

[Dan Rollo]

+1


> On May 7, 2017, at 8:09 AM, dev-digest-h...@river.apache.org wrote:
> 
> From: Peter >
> Subject: [Report] Apache River - Draft
> Date: May 5, 2017 at 3:55:36 AM EDT
> To: ">" 
> >
> 
> 
> 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: Roadmap proposal

[Dan Rollo]

+1

Dan


From: Gregg Wonderly >
Subject: Re: Roadmap proposal
Date: March 18, 2017 at 10:54:02 PM EDT
To: dev@river.apache.org 


Looks like a great plan of attack!

Gregg

Sent from my iPhone

> On Mar 17, 2017, at 11:15 PM, Peter Firmstone  > wrote:
> 
> 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
> 
> Changes in the modular build and delayed unmarshalling would set us up for 
> later OSGi support.
> 
> I think this might allay any fears people have regarding the pace of change, 
> in the past, latent race conditions prevented stabilisation, hence a 
> significant amount of work was required leading up to River 3.0's release.
> 
> Thoughts?
> 
> Regards,
> 
> Peter.
> 
> Sent from my Samsung device.

svn error with http checkout (was: Re: about 3.0 artifacts and announcement)

[Dan Rollo]

I was just trying to do a clean checkout from “trunk” to test the 
build/release steps (and hopefully help with publishing binaries to Central), 
but I’m getting a subversion error during checkout:


$ svn checkout http://svn.apache.org/repos/asf/river/jtsk/trunk river
Ariver/test
Ariver/test/conf
...
Ariver/test/src/org/apache/river/concurrent/ReferenceMapTest.java
Ariver/test/quarantined-src/README
svn: E175002: GET request returned unexpected delta base: 
/repos/asf/!svn/rvr/1726456/river/jtsk/trunk/LICENSE

Anybody else seeing similar issues with a clean checkout using “http” 
(anonymous) url?


For kicks, I also tried the https URL given under the ‘Developer Access’ 
section (show below), and that worked. 
Is this expected? If so, maybe we should change the 'Anonymous access’ URL docs 
to use https.

$ svn checkout https://svn.apache.org/repos/asf/river/jtsk/trunk river


-Dan



From: Zsolt Kúti >
Subject: about 3.0 artifacts and announcement
Date: January 5, 2017 at 3:51:07 PM EST
To: dev@river.apache.org 


Hi,

Can somebody tell if our release process documentation is up-to date:
http://river.apache.org/dev-doc/building-a-release.html 


As to the release, the last mail was:
http://mail-archives.apache.org/mod_mbox/river-dev/201610.mbox/%3cCAK_o9cH7JPsfd_CK4-pOGb3nswH4R8jB1Kh6=UTWF2c0Ge9V=w...@mail.gmail.com%3e
 


The 3.0.0 release artifacts (no binary) are available from here:
http://www.apache.org/dyn/closer.cgi/river/ 

So nothing is against a release announcement on our website, isn't  it?


If nobody else is willing to, I can take a look into how to add our jars to
maven repo,.

Cheers,
Zsolt

Re: site revamp

[Dan Rollo]

Wow, looks great!

I noticed one link on the front page seems broken:

JERI 


http://river.staging.apache.org/release-doc/2.2.3/api/net/jini/jeri/connection/doc-files/mux.html
 


-Dan

> On Dec 22, 2016, at 12:24 PM, dev-digest-h...@river.apache.org wrote:
> 
> From: Zsolt Kúti >
> Subject: site revamp
> Date: December 22, 2016 at 12:24:20 PM EST
> To: dev@river.apache.org 
> 
> 
> Hello,
> 
> The revamped site is now staged and can be reviewed here:
> http://river.staging.apache.org/ 
> 
> Community decides when to publish it.
> 
> Cheers,
> Zsolt

Re: River revamp

[Dan Rollo]

+1 to breaking up code into independently released modules. This would avoid 
tricky builds that re-use the same source files to produce different jars 
containing the same .class files, and it would ensure interdependencies are 
validated by build tooling. This approach would also avoid a “boil the ocean” 
syndrome where nothing can be released until it’s “all done”.

-Dan

From: Peter >
Subject: Re: River revamp
Date: November 12, 2016 at 1:25:49 AM EST
To: dev@river.apache.org 


We could make this the basis for a new release, almost as is.  I'd need to 
create some JIRA issues to capture the changes.  This would include Secure 
serialization, which is a step towards secure IoT.

However I'm also tempted to break up the codebase into modules and release each 
separately; a further step along the pathe of the secure IoT theme, from the 
root of the dependency tree.

The qa test suite would remain a separate ant build.

Regards,

Peter.

Re: dev Digest 8 Aug 2016 20:21:35 -0000 Issue 1437

[Dan Rollo]

+1

> On Aug 8, 2016, at 4:21 PM, dev-digest-h...@river.apache.org wrote:
> 
> From: Patricia Shanahan >
> Subject: Re: Draft report
> Date: August 7, 2016 at 3:09:36 AM EDT
> To: dev@river.apache.org 
> 
> 
> 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 > > 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

[Dan Rollo]

+1


From: Bryan Thompson >
Subject: Re: Draft report
Date: May 10, 2016 at 10:08:14 AM EDT
To: ">" 
>


+1

On Tue, May 10, 2016 at 10:06 AM, Patricia Shanahan > wrote:

> +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

Re: Test Failures on ARM, maybe I'm missing setup?

[Dan Rollo]

Thanks Greg. That’s got my local CI build passing. 

Now I just need to figure out which is the best target to call for my little CI 
build.

Also wondering how best to have the test results displayed. (HTML publisher 
does OK for the text file test results (qa/results…), but I’m wondering how 
Jenkins at apache is setup to detect/publish jtreg test success/failure).

Dan

> 
> 
> Subject: Re: Test Failures on ARM, maybe I'm missing setup?
> Date: January 21, 2016 at 11:10:14 PM EST
> To: dev@river.apache.org 
> 
> 
> Hi Dan:
> 
> I couldn’t find your exact patch (might have been suppressed by the list), 
> but I did the change to qaDefaults.properties manually, and said it was your 
> patch in the commit message.
> 
> ‘svn update’ and give it a try!
> 
> Cheers,
> 
> Greg Trasuk

Re: Test Failures on ARM, maybe I'm missing setup?

[Dan Rollo]

Just a quick ping to see if this patch to remove the “-server” switch could get 
into trunk?

Thanks,
Dan



Subject Re: Test Failures on ARM, maybe I'm missing setup?
DateTue, 05 Jan 2016 22:39:05 GMT
Thanks Dan, consider it removed.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Dan Rollo <danro...@gmail.com>
Sent: 06/01/2016 05:34:26 am
To: Cc: dev@river.apache.org
Subject: Re: Test Failures on ARM, maybe I'm missing setup?

I couldn’t find a way to detect if the “-server” switch would be supported 
without actually running the jvm, and then searching the value of a system 
property (like: System.getProperty("java.vmname")) for the text: “server”. 
Seems nasty.


FWIW, the following docs suggest the “-server” mode is the default now on 
non-32 bit jvms:

(http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html - same doc 
info for other os flavors)


-server 
Selects the Java HotSpot Server VM. The 64-bit version of the JDK supports only 
the Server VM, so in that case the option is implicit.


I guess I'm trying to make the case that just removing the “-server” arg is 
acceptable. :)


Dan 


…

> On Jan 4, 2016, at 5:20 PM, Dan Rollo <danro...@gmail.com> wrote:
> 
> Thanks Greg, and Peter. I was able to apply the “remove -server” fix to 
> qaDefaults.properties, and the test ran fine on a Pi. I’ve attached a patch 
> with these fixes against trunk. If there is a better way to submit such a 
> patch, please point me in the right direction ( - dare I ask about git? :) .
> 
> Dan
> 
> 
> 
> 

Re: dev Digest 11 Jan 2016 23:55:58 -0000 Issue 1373

[Dan Rollo]

Just to clarify, I’m not talking about “releasing" anything in final form 
without a vote, but instead about “staging” candidate artifacts (with poms, 
etc) in a staging repository. This allows people to test the artifacts (and 
poms, etc) and various dependency declarations using the “staging” repository 
(which they would have to activate manually). Only after the staged artifacts 
are promoted (after votes pass, etc) would the artifacts be “released” 
(published to central). The “staged” items can easily be deleted if the vote 
does not pass, and/or if new items need to be restaged.


> On Jan 11, 2016, at 6:55 PM, dev-digest-h...@river.apache.org wrote:
> 
> From: Peter <j...@zeus.net.au <mailto:j...@zeus.net.au>>
> Subject: Re: River - 3.0.0 Release candidate
> Date: January 10, 2016 at 1:34:44 AM EST
> To: dev@river.apache.org <mailto:dev@river.apache.org>
> 
> 
> I tend to agree, unfortunately we're not allowed to release anything 
> externally until after the release artifacts have been voted on.
> 
> On 10/01/2016 12:56 PM, Dan Rollo wrote:
>> Do we have a process for staging the river artifacts in the maven central 
>> staging repo? And/or where do the related “pom.xml” files live (or get 
>> generated)?
>> 
>> I tried to do some validation of the 3.0.0 jars using Dennis Reedy’s samples 
>> project on github, and ran into some dependency issues. Having staged 
>> artifacts/poms would clarify some dependency questions.
>> 
>> Thanks,
>> Dan
>> 
>> 
>>>>  On Jan 8, 2016, at 6:56 AM, Peter Firmstone<peter.firmst...@zeus.net.au 
>>>> <mailto:peter.firmst...@zeus.net.au><mailto:peter.firmst...@zeus.net.au 
>>>> <mailto:peter.firmst...@zeus.net.au>>>  wrote:
>>>> 
>>>>  The Apache River 3.0.0 Release candidate is available here:
>>>> 
>>>> http://people.apache.org/~peter_firmstone/<http://people.apache.org/~peter_firmstone/>
>>>>  
>>>> <http://people.apache.org/~peter_firmstone/%3Chttp://people.apache.org/~peter_firmstone/%3E>
>>>> 
>>>>  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<http://www.apache.org/dev/release-publishing.html>
>>>>  
>>>> <http://www.apache.org/dev/release-publishing.html%3Chttp://www.apache.org/dev/release-publishing.html%3E>
>>>> 
>>>>  Regards,
>>>> 
>>>>  Peter.

Re: Test Failures on ARM, maybe I'm missing setup?

[Dan Rollo]

I couldn’t find a way to detect if the “-server” switch would be supported 
without actually running the jvm, and then searching the value of a system 
property (like: System.getProperty("java.vm.name")) for the text: “server”. 
Seems nasty.

FWIW, the following docs suggest the “-server” mode is the default now on 
non-32 bit jvms:
(http://docs.oracle.com/javase/8/docs/technotes/tools/unix/java.html - same doc 
info for other os flavors)

-server
Selects the Java HotSpot Server VM. The 64-bit version of the JDK supports only 
the Server VM, so in that case the option is implicit.

I guess I'm trying to make the case that just removing the “-server” arg is 
acceptable. :)

Dan


> On Jan 5, 2016, at 11:03 AM, dev-digest-h...@river.apache.org wrote:
> 
> From: Peter <j...@zeus.net.au <mailto:j...@zeus.net.au>>
> Subject: Re: Test Failures on ARM, maybe I'm missing setup?
> Date: January 4, 2016 at 9:46:52 PM EST
> To: "dev@river.apache.org <mailto:dev@river.apache.org>" 
> <dev@river.apache.org <mailto:dev@river.apache.org>>
> 
> 
> Is there a way we can detect the platform,  we use server for testing as jit 
> optimisations are more agressive and more likely to highlight problems or 
> bugs?
> 
> Peter.
> 
> Sent from my Samsung device.
>  
>   Include original message
>  Original message 
> From: Dan Rollo <danro...@gmail.com <mailto:danro...@gmail.com>>
> Sent: 05/01/2016 08:20:52 am
> To: dev@river.apache.org <mailto:dev@river.apache.org>
> Subject: Re: Test Failures on ARM, maybe I'm missing setup?
> 
> Thanks Greg, and Peter. I was able to apply the “remove -server” fix to 
> qaDefaults.properties, and the test ran fine on a Pi. I’ve attached a patch 
> with these fixes against trunk. If there is a better way to submit such a 
> patch, please point me in the right direction ( - dare I ask about git? :) . 
> 
> Dan 

Re: Test Failures on ARM, maybe I'm missing setup?

[Dan Rollo]

Thanks Greg, and Peter. I was able to apply the “remove -server” fix to 
qaDefaults.properties, and the test ran fine on a Pi. I’ve attached a patch 
with these fixes against trunk. If there is a better way to submit such a 
patch, please point me in the right direction ( - dare I ask about git? :) .

Dan

Test Failures on ARM, maybe I'm missing setup?

[Dan Rollo]

I tried to follow the steps here: https://river.apache.org/building-river.html, 
but I probably missed something.

My first attempt to build things was to setup my own Jenkins build (on 
RaspberryPi Model 2’s) using the ant target: 
"hudson-aa-arm"

In case it matters, I’m using ant-1.9.4, and jdk: jdk-7-oracle-armhf (and had 
similar failures with jdk: jdk-8-oracle-arm-vfp-hflt).

The first test failure I see is:
...
[java] -
 [java] 
org/apache/river/test/impl/locatordiscovery/BadLocatorDiscoveryListener.td
 [java] Test Failed: Construct Failed: 
org.apache.river.qa.harness.TestException: Problem creating service for 
net.jini.core.lookup.ServiceRegistrar; nested exception is: 
 [java] Failed to start the shared nonactivatable group; nested 
exception is: 
 [java] NonActivatableGroupAdmin: Failed to exec the group; nested 
exception is: 
 [java] null
 
And a number of later tests fail also, for example:
...
[java] org/apache/river/test/impl/locatordiscovery/UnicastDelay.td 
 [java] Test Skipped: verifiers are: 
org.apache.river.qa.harness.SkipConfigTestVerifier 
 [java]  
 [java] org/apache/river/test/spec/locatordiscovery/AddDiscoveryListenerNull.td 
 [java] Test Failed: Construct Failed: 
org.apache.river.qa.harness.TestException: Problem creating service for 
net.jini.core.lookup.ServiceRegistrar; nested exception is: 
 [java] Failed to start the shared nonactivatable group; nested exception is: 
 [java] NonActivatableGroupAdmin: Failed to exec the group; nested exception 
is: 
 [java] null  


I tried running the first failing test (BadLocatorDiscoveryListener.td) by 
itself (on a Mac - not the ARM) via ant: ~/devtools/apache-ant-1.9.6/bin/ant 
-Drun.tests=org/apache/river/test/impl/locatordiscovery/BadLocatorDiscoveryListener.td
 run-tests
and of course the tests passes.

Any suggestions?

Thanks,
Dan Rollo

Re: River-examples project - followup

[Dan Rollo]

Hi Greg,

I finally took some time to try this out. It really looks great to me!

I noticed one minor thing that I thought might confuse users: While going 
through tutorial steps, I decided to stop (via cntrl+c) are restart the 
hello-service a couple times. This resulted in the service being shown multiple 
times in the service browser (screenshot attached). It appeared all the 
duplicate instances in the browser “worked” (I could “show info” and “browse 
service” on all of them). Eventually, the duplicate registrations “cleaned up” 
and I was left with just one. I’m not sure how best to avoid confusion about 
this situation. Would more doc about “why”/“how” that works just complicate 
things? Is there any sort of “force lease check” to do in the browser that 
could clear up the duplicates sooner? (And if so, would that be worth noting in 
the tutorial?). So basically, not sure this is a “problem”, but thought I’d ask…

Thanks!
Dan

Re: Security

[Dan Rollo]

Very interesting. Looking forward to the next episode. 

 On Feb 4, 2015, at 9:11 AM, dev-digest-h...@river.apache.org wrote:
 
 to be continued...

[VOTE] Patricia Shanahan for PMC Chair

[Dan Rollo]

+1

Dan Rollo

Maven deployment: Deploy sources too?

[Dan Rollo]

Hi Dennis,

It is great to see the jars getting ready to deploy to Central. I think 
just having the poms and interrelated dependencies declared will be a 
big help!


Under the category of give an inch, ask for a mile: Could we also 
deploy these artifacts with related source files? I realise the source 
trees do not perfectly match to the various jars, but even with certain 
overlap, having the source jars for each production jar in the central 
repo makes debugging in IDEs very nice.


That said, I previously struggled to get 'mvn deploy:deploy-file' to 
work with sources (you have to do both production jar and source jar 
together for it to work). The key was adding 'files', 'types', and 
'classifiers' args for each attached artifact. Here's an example that 
deploys a production dist jar, and its sources and javadoc jars:


  ...=mvn deploy:deploy-file +
  -Durl=${repository-url} +
  -DrepositoryId=${repository-id}+
  -DpomFile=${pom}+
  -Dfile=${dist-jar}+
  -Dfiles=${maven-sources-jar},${maven-javadoc-jar}+
  -Dtypes=jar,jar+
  -Dclassifiers=sources,javadoc

Of course I'm not even sure if we produce 'sources' jar currently (much 
less how best to match them to each production jar).


Dan Rollo



in: river/jtsk/trunk/poms/deploy_river.groovy

+String deployCommand = mvn deploy:deploy-file +
+   -DrepositoryId=apache.releases.https +
+   -Dversion=${version} +
+   -DgeneratePom=false -Dpackaging=jar +
+   -DgroupId=${gId} +
+   -DartifactId=${aId} +
+   -Dfile=${dir}/${aId}.jar +
+   -DpomFile=./${aId}.pom +
+ 
-Durl=https://repository.apache.org/service/local/staging/deploy/maven2;

Re: commits Digest 14 Jul 2012 06:45:14 -0000 Issue 1165

[Dan Rollo]

Hi Peter,

Lurker comment: Should most of those 'static' fields also be 'final'?

Dan


On 07/14/2012 02:45 AM, commits-digest-h...@river.apache.org wrote:

+class UriString {