Re: Lotj - languages other than java

[Peter]

Hi Bishnu,

You'll need to use JERI instead of jrmp.

Hi Bishnu,

Replace JrmpExporter with BasicJeriExporter in your configuration, you'll want 
to check out the javadoc.

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Bishnu Gautam <bishn...@hotmail.com>
Sent: 07/07/2016 07:19:48 pm
To: dev@river.apache.org <dev@river.apache.org>
Subject: RE: Lotj - languages other than java

Hi Peter 
Thanks for your valuable reply.Could you elaborate more on serverHost string. I 
found serverHost variable on phoenix.policy file. Currently I am just using a 
simple reggie(Jrmp-reggie) in order to register of my proxy. And, I started it 
inside localnetwork to which I could connect from outside network by using port 
forwarding. However, as I stated in my previous email, once it got the proxy, 
it is assigned by local IP and could not download the remaining codes of the 
services. I would like to set the dns name string instead of InetAddress. Could 
you elaborate more about it so that I can configure more properly. I think I 
may have missed that. 
RegardsBishnu 


Bishnu Prasad Gautam


> Date: Wed, 6 Jul 2016 21:01:53 +1000 
> From: j...@zeus.net.au 
> Subject: Re: Lotj - languages other than java 
> To: dev@river.apache.org 
>  
> Hi Bishnu, 
>  
> The serverHost is a dns name string argument that you use in your 
>configuration when choosing & creating an instance of a ServerEndpoint, if 
>this is null, it defaults to the InetAddress.   
>  
> Endpoints support multiple ip addresses, the first successful address is used 
>during dns resolution . 
>  
> Regards, 
>  
> Peter. 
>  
> Sent from my Samsung device. 
>   
>   Include original message 
>  Original message  
> From: Bishnu Gautam <bishn...@hotmail.com> 
> Sent: 06/07/2016 08:11:49 pm 
> To: dev@river.apache.org <dev@river.apache.org> 
> Subject: RE: Lotj - languages other than java 
>  
> Thanks Peter For the introduction of new implementation. I will go through 
>it.Between, here is the scenario that I often faced and I am pretty sure that 
>most of the users have faced is this:  
> 1. It is possible to invoke lookup service from the internet and even getting 
>the registrar is possible. In fact I was able to find the lookup server behind 
>the NAT and firewall.2. Once I get the registrar the service registered in 
>this registrar seems to have local IP3. Therefore the client from the internet 
>is not able to set up the connection by using the proxy as it gave you local 
>IP.  
> This problem occurred because the lookup service was running in private IP 
>and not assigned by global IP directly into its interface. If the lookupserver 
>is directly assigned by global IP, there would be no problem to publicize the 
>current lookup server. However, in our case and most of the servers inside the 
>networks are not directly assigned global IP but are assigned in a gateway 
>machine having NAT facility due to security reasons. The static NAT  and some 
>other techniques are applied in order to access the services through outside 
>network and it is quite possible because they are port forwarded and 
>synchronize the filtering rules properly. However port forwarding technique 
>alone is not helpful in the case of river. Because registrar (kept inside 
>firewall and NAT) seems to have the proxy service which has local IP whenever 
>it is downloaded to the client machine. In the first connection, it is 
>possible to locate the lookuplocater by using port forwarding technique 
>however once it is located it returns the proxy services having local IP. This 
>scenario is becoming a possible design flaw  in River and limiting the users 
>of this technology.I would like to suggest you to assign domain name in any 
>case rather than assigning IP in its proxy. Because if you assign domain name 
>rather than IP, the lookup can be made without considering whether a call from 
>local network or global network. Because when lookup is done from within a 
>network, dns will return local IP and it will return global IP whenever it is 
>done from outside network. In this case, there will be no problem once it is 
>accessed by port forwarding technique too. So, we should rely upon DNS. So, it 
>is quite possible that the codebase is assigning the local IP to its proxy 
>service. So, need to tweak this scenario too. This seems lookup overhead but 
>it seems to be the only solution to overcome NAT and Firewall locking to the 
>River solution I think that this issue can be solved by you guys with minimal 
>effort. Let me know if you could tweak the code of registrar as explained 
>above. This will certainly enable a huge potential to this technology. Please 
>correct me if something is mis

RE: Lotj - languages other than java

[Bishnu Gautam]

Hi Peter
Thanks for your valuable reply.Could you elaborate more on serverHost string. I 
found serverHost variable on phoenix.policy file. Currently I am just using a 
simple reggie(Jrmp-reggie) in order to register of my proxy. And, I started it 
inside localnetwork to which I could connect from outside network by using port 
forwarding. However, as I stated in my previous email, once it got the proxy, 
it is assigned by local IP and could not download the remaining codes of the 
services. I would like to set the dns name string instead of InetAddress. Could 
you elaborate more about it so that I can configure more properly. I think I 
may have missed that.
RegardsBishnu


Bishnu Prasad Gautam


> Date: Wed, 6 Jul 2016 21:01:53 +1000
> From: j...@zeus.net.au
> Subject: Re: Lotj - languages other than java
> To: dev@river.apache.org
> 
> Hi Bishnu,
> 
> The serverHost is a dns name string argument that you use in your 
> configuration when choosing & creating an instance of a ServerEndpoint, if 
> this is null, it defaults to the InetAddress.  
> 
> Endpoints support multiple ip addresses, the first successful address is used 
> during dns resolution .
> 
> Regards,
> 
> Peter.
> 
> Sent from my Samsung device.
>  
>   Include original message
>  Original message 
> From: Bishnu Gautam <bishn...@hotmail.com>
> Sent: 06/07/2016 08:11:49 pm
> To: dev@river.apache.org <dev@river.apache.org>
> Subject: RE: Lotj - languages other than java
> 
> Thanks Peter For the introduction of new implementation. I will go through 
> it.Between, here is the scenario that I often faced and I am pretty sure that 
> most of the users have faced is this: 
> 1. It is possible to invoke lookup service from the internet and even getting 
> the registrar is possible. In fact I was able to find the lookup server 
> behind the NAT and firewall.2. Once I get the registrar the service 
> registered in this registrar seems to have local IP3. Therefore the client 
> from the internet is not able to set up the connection by using the proxy as 
> it gave you local IP. 
> This problem occurred because the lookup service was running in private IP 
> and not assigned by global IP directly into its interface. If the 
> lookupserver is directly assigned by global IP, there would be no problem to 
> publicize the current lookup server. However, in our case and most of the 
> servers inside the networks are not directly assigned global IP but are 
> assigned in a gateway machine having NAT facility due to security reasons. 
> The static NAT  and some other techniques are applied in order to access the 
> services through outside network and it is quite possible because they are 
> port forwarded and synchronize the filtering rules properly. However port 
> forwarding technique alone is not helpful in the case of river. Because 
> registrar (kept inside firewall and NAT) seems to have the proxy service 
> which has local IP whenever it is downloaded to the client machine. In the 
> first connection, it is possible to locate the lookuplocater by using port 
> forwarding technique however once it is located it returns the proxy services 
> having local IP. This scenario is becoming a possible design flaw  in River 
> and limiting the users of this technology.I would like to suggest you to 
> assign domain name in any case rather than assigning IP in its proxy. Because 
> if you assign domain name rather than IP, the lookup can be made without 
> considering whether a call from local network or global network. Because when 
> lookup is done from within a network, dns will return local IP and it will 
> return global IP whenever it is done from outside network. In this case, 
> there will be no problem once it is accessed by port forwarding technique 
> too. So, we should rely upon DNS. So, it is quite possible that the codebase 
> is assigning the local IP to its proxy service. So, need to tweak this 
> scenario too. This seems lookup overhead but it seems to be the only solution 
> to overcome NAT and Firewall locking to the River solution I think that this 
> issue can be solved by you guys with minimal effort. Let me know if you could 
> tweak the code of registrar as explained above. This will certainly enable a 
> huge potential to this technology. Please correct me if something is missing 
> here. 
> RegardsBishnu 
> 
> 
> Bishnu Prasad Gautam
> 
> 
> > Date: Wed, 6 Jul 2016 16:25:12 +1000 
> > From: j...@zeus.net.au 
> > To: dev@river.apache.org 
> > Subject: Re: Lotj - languages other than java 
> >  
> > Thanks Bishnu, 
> >  
> > I plan to set up a public lookup service later this year, or early next  
> > over IPv6 (dependant on me completing the w

RE: Lotj - languages other than java

[Bishnu Gautam]

Hi Peter
Thanks for your valuable reply.Could you elaborate more on serverHost string. I 
found serverHost variable on phoenix.policy file. Currently I am just using a 
simple reggie(Jrmp-reggie) in order to register of my proxy. And, I started it 
inside localnetwork to which I could connect from outside network by using port 
forwarding. However, as I stated in my previous email, once it got the proxy, 
it is assigned by local IP and could not download the remaining codes of the 
services. I would like to set the dns name string instead of InetAddress. Could 
you elaborate more about it so that I can configure more properly. I think I 
may have missed that.
RegardsBishnu


Bishnu Prasad Gautam


> Date: Wed, 6 Jul 2016 21:01:53 +1000
> From: j...@zeus.net.au
> Subject: Re: Lotj - languages other than java
> To: dev@river.apache.org
> 
> Hi Bishnu,
> 
> The serverHost is a dns name string argument that you use in your 
> configuration when choosing & creating an instance of a ServerEndpoint, if 
> this is null, it defaults to the InetAddress.  
> 
> Endpoints support multiple ip addresses, the first successful address is used 
> during dns resolution .
> 
> Regards,
> 
> Peter.
> 
> Sent from my Samsung device.
>  
>   Include original message
>  Original message 
> From: Bishnu Gautam <bishn...@hotmail.com>
> Sent: 06/07/2016 08:11:49 pm
> To: dev@river.apache.org <dev@river.apache.org>
> Subject: RE: Lotj - languages other than java
> 
> Thanks Peter For the introduction of new implementation. I will go through 
> it.Between, here is the scenario that I often faced and I am pretty sure that 
> most of the users have faced is this: 
> 1. It is possible to invoke lookup service from the internet and even getting 
> the registrar is possible. In fact I was able to find the lookup server 
> behind the NAT and firewall.2. Once I get the registrar the service 
> registered in this registrar seems to have local IP3. Therefore the client 
> from the internet is not able to set up the connection by using the proxy as 
> it gave you local IP. 
> This problem occurred because the lookup service was running in private IP 
> and not assigned by global IP directly into its interface. If the 
> lookupserver is directly assigned by global IP, there would be no problem to 
> publicize the current lookup server. However, in our case and most of the 
> servers inside the networks are not directly assigned global IP but are 
> assigned in a gateway machine having NAT facility due to security reasons. 
> The static NAT  and some other techniques are applied in order to access the 
> services through outside network and it is quite possible because they are 
> port forwarded and synchronize the filtering rules properly. However port 
> forwarding technique alone is not helpful in the case of river. Because 
> registrar (kept inside firewall and NAT) seems to have the proxy service 
> which has local IP whenever it is downloaded to the client machine. In the 
> first connection, it is possible to locate the lookuplocater by using port 
> forwarding technique however once it is located it returns the proxy services 
> having local IP. This scenario is becoming a possible design flaw  in River 
> and limiting the users of this technology.I would like to suggest you to 
> assign domain name in any case rather than assigning IP in its proxy. Because 
> if you assign domain name rather than IP, the lookup can be made without 
> considering whether a call from local network or global network. Because when 
> lookup is done from within a network, dns will return local IP and it will 
> return global IP whenever it is done from outside network. In this case, 
> there will be no problem once it is accessed by port forwarding technique 
> too. So, we should rely upon DNS. So, it is quite possible that the codebase 
> is assigning the local IP to its proxy service. So, need to tweak this 
> scenario too. This seems lookup overhead but it seems to be the only solution 
> to overcome NAT and Firewall locking to the River solution I think that this 
> issue can be solved by you guys with minimal effort. Let me know if you could 
> tweak the code of registrar as explained above. This will certainly enable a 
> huge potential to this technology. Please correct me if something is missing 
> here. 
> RegardsBishnu 
> 
> 
> Bishnu Prasad Gautam
> 
> 
> > Date: Wed, 6 Jul 2016 16:25:12 +1000 
> > From: j...@zeus.net.au 
> > To: dev@river.apache.org 
> > Subject: Re: Lotj - languages other than java 
> >  
> > Thanks Bishnu, 
> >  
> > I plan to set up a public lookup service later this year, or early next  
> > over IPv6 (dependant on me completing the w

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

[Peter]

A long term support version of River 2.2.x should be sufficient to keep those 
who desire minimal change satisfied, without them feeling threatened by a more 
progressive pace of development.  Git would make managing the separate branches 
easier.

Bugs that were reported and fixed in 2.2.x were often already fixed in the 
trunk branch.  Also there are tests in the 2.2.x branch that fail, because 
they're unmaintained, these tests haven't passed on recent jvm's.

Determining bug fixes that go into the lts support branch is somewhat 
difficult, clearly race condition fixes wouldn't be included, nor would 
security fixes, I'd suggest only the occassional major bug reported by users of 
the lts version. The 2.2.x branch code is written to the old java memory model, 
prior to JSR133 released with Java 1.5.

If we based the River 2.2.x lts support on the availability of support for 
suitable jvm's and Oracle's end of public updates, the lts River version 2.2.x 
branch would probably end late 2017 or early 2018.  The US is predicted to have 
 70% IPv6 deployment by that time.

Support for loading the policy provider into the extension ClassLoader will be 
removed in Java 9, this will reintroduce a policy deadlock bug  for 2.2.x that 
were fixed by loading policy providers into the extension ClassLoader.  These 
bugs won't affect River 3.0.

Back porting the policy provider from River 3.0 is not an option, as this is 
almost non blocking (very good for avoiding deadlock) and would cause many 
latent race condition bugs to emerge.

If River 3.0.0 is released soon, that allows two years for migration, 
remembering that River 3.0.0 is largely a JMM compliance bug fix release, with 
a com.sun.jini to org.apache.river namespace change.

After River 3, I'd like to see focus on IPv6, security (fixes, updates and 
simplification), IoT and a protocol based lookup service that supports other 
languages.

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Bryan Thompson <br...@blazegraph.com>
Sent: 06/07/2016 11:22:49 pm
To: dev@river.apache.org <dev@river.apache.org>
Subject: Re: Attic? Was: Re: Lotj - languages other than java

I look at git in terms of the ease of use for branch/merge patterns and the 
support of pull requests for code review and historical change tracking. 
It is really far superior in its flexibility.  Even just the diff facility 
if a big step forward. 

I do agree that projects benefit significantly from governance.  If it 
degenerates to everyone creating their own fork then nothing good would 
come of that.  I am not suggesting git because it makes forking easier. 
But because it makes team development easier. 

Bryan 

On Wednesday, July 6, 2016, Simon IJskes - QCG <si...@qcg.nl> wrote: 

> On 05-07-16 14:51, Bryan Thompson wrote: 
> 
>> GitHub (at least) provides excellent tracking.  It is a matter of how you 
>> define policy for PRs.  We do not accept PRs unless the author is a 
>> contributor with appropriate CLAs for the project.  So it works out very 
>> nicely for us.  Every single commit and its authorship remains visible and 
>> that metadata can be easily accessed. 
>> 
> 
> Is changing the version control system really going to change the problems 
> we have? 
> 
> The same goes for maven or not, gradle or ant, etc. 
> 
> One direction wants a stable release with bugfixes, and strict maintaining 
> of the original api, the other side wants to change things. 
> 
> No resolution in sight. I really like the Apache governance, and it gives 
> everybody the freedom to fork it under its own. Apache is definitly not the 
> problem here. 
> 
> Apache is a tool, a tool that shows us that we need to cooperate in order 
> to make progress. You can switch to git, and fork all you like, like so 
> many other projects. But then you have a few forks, sitting stale on 
> github. With sometimes an individual caring about it, or more times not. 
> Apache goes beyond individuals, and currently it shows we haven't made that 
> step. 
> 
> G. Simon 
> 
> -- 
> QCG, Software development, 071-5890970, http://www.qcg.nl 
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397 
> 

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

[Bryan Thompson]

I look at git in terms of the ease of use for branch/merge patterns and the
support of pull requests for code review and historical change tracking.
It is really far superior in its flexibility.  Even just the diff facility
if a big step forward.

I do agree that projects benefit significantly from governance.  If it
degenerates to everyone creating their own fork then nothing good would
come of that.  I am not suggesting git because it makes forking easier.
But because it makes team development easier.

Bryan

On Wednesday, July 6, 2016, Simon IJskes - QCG  wrote:

> On 05-07-16 14:51, Bryan Thompson wrote:
>
>> GitHub (at least) provides excellent tracking.  It is a matter of how you
>> define policy for PRs.  We do not accept PRs unless the author is a
>> contributor with appropriate CLAs for the project.  So it works out very
>> nicely for us.  Every single commit and its authorship remains visible and
>> that metadata can be easily accessed.
>>
>
> Is changing the version control system really going to change the problems
> we have?
>
> The same goes for maven or not, gradle or ant, etc.
>
> One direction wants a stable release with bugfixes, and strict maintaining
> of the original api, the other side wants to change things.
>
> No resolution in sight. I really like the Apache governance, and it gives
> everybody the freedom to fork it under its own. Apache is definitly not the
> problem here.
>
> Apache is a tool, a tool that shows us that we need to cooperate in order
> to make progress. You can switch to git, and fork all you like, like so
> many other projects. But then you have a few forks, sitting stale on
> github. With sometimes an individual caring about it, or more times not.
> Apache goes beyond individuals, and currently it shows we haven't made that
> step.
>
> G. Simon
>
> --
> QCG, Software development, 071-5890970, http://www.qcg.nl
> Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397
>

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

[Peter]

Actually the org.apache.river namespace change should be sufficient to justify 
it.  Even though it isn't public api, people use these packages and it's  a 
breaking change.  To be honest I'm surprised it got through without any 
arguments.

Regards,

Peter.

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

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

Re: Lotj - languages other than java

[Peter]

Hi Bishnu,

The serverHost is a dns name string argument that you use in your configuration 
when choosing & creating an instance of a ServerEndpoint, if this is null, it 
defaults to the InetAddress.  

Endpoints support multiple ip addresses, the first successful address is used 
during dns resolution .

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Bishnu Gautam <bishn...@hotmail.com>
Sent: 06/07/2016 08:11:49 pm
To: dev@river.apache.org <dev@river.apache.org>
Subject: RE: Lotj - languages other than java

Thanks Peter For the introduction of new implementation. I will go through 
it.Between, here is the scenario that I often faced and I am pretty sure that 
most of the users have faced is this: 
1. It is possible to invoke lookup service from the internet and even getting 
the registrar is possible. In fact I was able to find the lookup server behind 
the NAT and firewall.2. Once I get the registrar the service registered in this 
registrar seems to have local IP3. Therefore the client from the internet is 
not able to set up the connection by using the proxy as it gave you local IP. 
This problem occurred because the lookup service was running in private IP and 
not assigned by global IP directly into its interface. If the lookupserver is 
directly assigned by global IP, there would be no problem to publicize the 
current lookup server. However, in our case and most of the servers inside the 
networks are not directly assigned global IP but are assigned in a gateway 
machine having NAT facility due to security reasons. The static NAT  and some 
other techniques are applied in order to access the services through outside 
network and it is quite possible because they are port forwarded and 
synchronize the filtering rules properly. However port forwarding technique 
alone is not helpful in the case of river. Because registrar (kept inside 
firewall and NAT) seems to have the proxy service which has local IP whenever 
it is downloaded to the client machine. In the first connection, it is possible 
to locate the lookuplocater by using port forwarding technique however once it 
is located it returns the proxy services having local IP. This scenario is 
becoming a possible design flaw  in River and limiting the users of this 
technology.I would like to suggest you to assign domain name in any case rather 
than assigning IP in its proxy. Because if you assign domain name rather than 
IP, the lookup can be made without considering whether a call from local 
network or global network. Because when lookup is done from within a network, 
dns will return local IP and it will return global IP whenever it is done from 
outside network. In this case, there will be no problem once it is accessed by 
port forwarding technique too. So, we should rely upon DNS. So, it is quite 
possible that the codebase is assigning the local IP to its proxy service. So, 
need to tweak this scenario too. This seems lookup overhead but it seems to be 
the only solution to overcome NAT and Firewall locking to the River solution I 
think that this issue can be solved by you guys with minimal effort. Let me 
know if you could tweak the code of registrar as explained above. This will 
certainly enable a huge potential to this technology. Please correct me if 
something is missing here. 
RegardsBishnu 


Bishnu Prasad Gautam


> Date: Wed, 6 Jul 2016 16:25:12 +1000 
> From: j...@zeus.net.au 
> To: dev@river.apache.org 
> Subject: Re: Lotj - languages other than java 
>  
> Thanks Bishnu, 
>  
> I plan to set up a public lookup service later this year, or early next  
> over IPv6 (dependant on me completing the work on github), there's a  
> beta release of the code available you can experiment with. 
>  
> It will be possible to discover this lookup service dynamically using  
> the global IPv6 multicast address FF0X::155 for Jini-announcement. 
>  
> For DOS reasons, Jini-request will only be available for local network use. 
>  
> 
>http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml
> 
>  
> Before I could make a lookup service publicly available, I've had to do  
> a lot of work on addressing security issues: 
>  
>1. Serialization atomic input validation. 
>2. Two new default methods in ServiceRegistrar so that clients can 
>   authenticate services, prior to deserializing their proxy's, 
>   Entry's and downloading or provisioning codebases. 
>3. New discovery providers with updated cryptographic hash functions 
>   for secure discovery and added input validation for 
>   deserialization of registrar proxy. 
>4. Dynamic granting of DownloadPermission and 
>   DeserializationPermission (similar to deserialization 
>   whitelisting) to authenticated services (to allow their proxy t

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

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

[Peter]

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

RE: Lotj - languages other than java

[Bishnu Gautam]

Thanks Peter For the introduction of new implementation. I will go through 
it.Between, here is the scenario that I often faced and I am pretty sure that 
most of the users have faced is this:
1. It is possible to invoke lookup service from the internet and even getting 
the registrar is possible. In fact I was able to find the lookup server behind 
the NAT and firewall.2. Once I get the registrar the service registered in this 
registrar seems to have local IP3. Therefore the client from the internet is 
not able to set up the connection by using the proxy as it gave you local IP.
This problem occurred because the lookup service was running in private IP and 
not assigned by global IP directly into its interface. If the lookupserver is 
directly assigned by global IP, there would be no problem to publicize the 
current lookup server. However, in our case and most of the servers inside the 
networks are not directly assigned global IP but are assigned in a gateway 
machine having NAT facility due to security reasons. The static NAT  and some 
other techniques are applied in order to access the services through outside 
network and it is quite possible because they are port forwarded and 
synchronize the filtering rules properly. However port forwarding technique 
alone is not helpful in the case of river. Because registrar (kept inside 
firewall and NAT) seems to have the proxy service which has local IP whenever 
it is downloaded to the client machine. In the first connection, it is possible 
to locate the lookuplocater by using port forwarding technique however once it 
is located it returns the proxy services having local IP. This scenario is 
becoming a possible design flaw  in River and limiting the users of this 
technology.I would like to suggest you to assign domain name in any case rather 
than assigning IP in its proxy. Because if you assign domain name rather than 
IP, the lookup can be made without considering whether a call from local 
network or global network. Because when lookup is done from within a network, 
dns will return local IP and it will return global IP whenever it is done from 
outside network. In this case, there will be no problem once it is accessed by 
port forwarding technique too. So, we should rely upon DNS. So, it is quite 
possible that the codebase is assigning the local IP to its proxy service. So, 
need to tweak this scenario too. This seems lookup overhead but it seems to be 
the only solution to overcome NAT and Firewall locking to the River solution. I 
think that this issue can be solved by you guys with minimal effort. Let me 
know if you could tweak the code of registrar as explained above. This will 
certainly enable a huge potential to this technology. Please correct me if 
something is missing here.
RegardsBishnu


Bishnu Prasad Gautam


> Date: Wed, 6 Jul 2016 16:25:12 +1000
> From: j...@zeus.net.au
> To: dev@river.apache.org
> Subject: Re: Lotj - languages other than java
> 
> Thanks Bishnu,
> 
> I plan to set up a public lookup service later this year, or early next 
> over IPv6 (dependant on me completing the work on github), there's a 
> beta release of the code available you can experiment with.
> 
> It will be possible to discover this lookup service dynamically using 
> the global IPv6 multicast address FF0X::155 for Jini-announcement.
> 
> For DOS reasons, Jini-request will only be available for local network use.
> 
> http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml
> 
> Before I could make a lookup service publicly available, I've had to do 
> a lot of work on addressing security issues:
> 
>1. Serialization atomic input validation.
>2. Two new default methods in ServiceRegistrar so that clients can
>   authenticate services, prior to deserializing their proxy's,
>   Entry's and downloading or provisioning codebases.
>3. New discovery providers with updated cryptographic hash functions
>   for secure discovery and added input validation for
>   deserialization of registrar proxy.
>4. Dynamic granting of DownloadPermission and
>   DeserializationPermission (similar to deserialization
>   whitelisting) to authenticated services (to allow their proxy to
>   be deserialized / downloaded).
>5. Allow listing of Permissions within jar files, for smart proxy's
>   and have these granted dynamically if service authentication succeeds.
>6. Update encryption cyphers and invocation constraints.
> 
> Existing River / Jini deployments will not be able to contact this 
> lookup service, in the event they could, they cannot satisfy the 
> ConfidentialityStrength invocation constraints either unfortunately.  On 
> local networks security could be relaxed sufficiently to allow 
> compatibility with an existing River deployment, but public lookup 
&

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

[Simon IJskes - QCG]

On 05-07-16 14:51, Bryan Thompson wrote:

GitHub (at least) provides excellent tracking.  It is a matter of how you
define policy for PRs.  We do not accept PRs unless the author is a
contributor with appropriate CLAs for the project.  So it works out very
nicely for us.  Every single commit and its authorship remains visible and
that metadata can be easily accessed.


Is changing the version control system really going to change the 
problems we have?


The same goes for maven or not, gradle or ant, etc.

One direction wants a stable release with bugfixes, and strict 
maintaining of the original api, the other side wants to change things.


No resolution in sight. I really like the Apache governance, and it 
gives everybody the freedom to fork it under its own. Apache is 
definitly not the problem here.


Apache is a tool, a tool that shows us that we need to cooperate in 
order to make progress. You can switch to git, and fork all you like, 
like so many other projects. But then you have a few forks, sitting 
stale on github. With sometimes an individual caring about it, or more 
times not. Apache goes beyond individuals, and currently it shows we 
haven't made that step.


G. Simon

--
QCG, Software development, 071-5890970, http://www.qcg.nl
Quality Consultancy Group b.v., Leiderdorp, Kvk Den Haag: 28088397

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

[Peter]

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  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: Lotj - languages other than java

[Peter]

Thanks Bishnu,

I plan to set up a public lookup service later this year, or early next 
over IPv6 (dependant on me completing the work on github), there's a 
beta release of the code available you can experiment with.


It will be possible to discover this lookup service dynamically using 
the global IPv6 multicast address FF0X::155 for Jini-announcement.


For DOS reasons, Jini-request will only be available for local network use.

http://www.iana.org/assignments/ipv6-multicast-addresses/ipv6-multicast-addresses.xhtml

Before I could make a lookup service publicly available, I've had to do 
a lot of work on addressing security issues:


  1. Serialization atomic input validation.
  2. Two new default methods in ServiceRegistrar so that clients can
 authenticate services, prior to deserializing their proxy's,
 Entry's and downloading or provisioning codebases.
  3. New discovery providers with updated cryptographic hash functions
 for secure discovery and added input validation for
 deserialization of registrar proxy.
  4. Dynamic granting of DownloadPermission and
 DeserializationPermission (similar to deserialization
 whitelisting) to authenticated services (to allow their proxy to
 be deserialized / downloaded).
  5. Allow listing of Permissions within jar files, for smart proxy's
 and have these granted dynamically if service authentication succeeds.
  6. Update encryption cyphers and invocation constraints.

Existing River / Jini deployments will not be able to contact this 
lookup service, in the event they could, they cannot satisfy the 
ConfidentialityStrength invocation constraints either unfortunately.  On 
local networks security could be relaxed sufficiently to allow 
compatibility with an existing River deployment, but public lookup 
services should not make that compromise.


The Serial form of objects are compatible with River.

This is all beta, new API may change if adopted by River.

Regards,

Peter.

On 6/07/2016 3:36 PM, Bishnu Gautam wrote:

Thanks Peter for your detail explanation regarding River on Internet.I will go 
through it. By the way do you have any publicly available Lookup service to 
which I can register my proxy service and this proxy service will refer my web 
server by which I could download my rest of the actual service codes (fully 
implemented) from the publicly available web server(in which my service codes 
are located). In fact I am trying to avail Lookup Server publicly so that the 
user could register their proxy services in my lookup server.Let me know if 
anybody already made it available for public use. Once we are able to do it we 
do not need to rely upon REST too and also do not need to tackle with NATing 
and packet filtering issues. I am looking whether there are any workable 
publicly available lookup services to which I can register my proxy.
RegardsBishnu


Bishnu Prasad Gautam



Date: Tue, 5 Jul 2016 17:46:14 +1000
From: j...@zeus.net.au
To: dev@river.apache.org
Subject: Re: Lotj - languages other than java

Thanks Bishnu,

Mark Brouwer originally pointed out many years ago, that while jini had
https jeri endpoints, there was no support to perform unicast discover
over https in LookupLocator discovery.

I have implemented that.

Now, you can have any number of publicly available lookup services, and
contact them using https unicast with LookupLocator,
ConstrainableLookupLocator and LookupLocatorDiscovery.  DNS-SD is an
obvious substitute for multicast discovery for clients behind firewalls,
but it hasn't been implemented yet.

With public lookup services, even when not discoverable with multicast
discovery (because your clients are behind firewalls), can register with
each other, using multicast discovery, allowing clients behind firewalls
to find others, so they only need to know a few permanent registrars to
find others, when they don't have access to multicast discovery.

Non public service clients (behind firewalls or NAT) can locate public
services.  Non public clients can listen behind NAT and firewalls, when
they register a listener with a lookup service, they will be notified of
new service registrations, because https jeri endpoints will keep the
connection (ports) open between a lookup service and clients behind
firewalls.

So lets say for example, you have an embedded client behind a firewall,
which is also a master for an IoT wireless local network and there are
several devices that will send a video stream or other data, then for
instance a public consumer service, could register with a lookup service
where the embedded client was listening, then be contacted and
authenticated by the embedded client and access a service directly from
the client to receive live data streams from that wireless network, this
may then republish the data accumulated from multiple such embedded
clients via a web site.  Clients behind NAT must initiate contact, only
then can they be contacted.

JERI multiplexes, so you can

Re: Lotj - languages other than java

[Peter]

ever, 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.
RegardsBishnu


Bishnu Prasad Gautam



Date: Mon, 4 Jul 2016 18:37:25 +1000
From: j...@zeus.net.au
Subject: Re: Lotj - languages other than java
To: dev@river.apache.org
CC: si...@qcg.nl




Sim,

I'd like to see the project return to the days where we had a number of active 
committers working together on the same goals.

I've got a project on github, where I've continued work that was controversial, 
I'd like to bring this work back to the project if possible.  It has some minor 
breaking changes, but if backward compatibility was essential, it could be 
accommodated.

Changes:
* New secure discovery providers, including https among others, including added 
https protocol support for LookupLocator.  However since firewalls may not 
allow ipv6 multicast packets through, DNS-SD would be useful.
* IPv6 Discovery, global and local groups.
* Discovery V2 support added to LookupLocator's getRegistrar method.
* Updated encryption ciphers, removal of insecure ones.
* Deprecation of ProxyTrust et al.
* New default methods added to ServiceRegistrar to allow establising trust with 
a service, prior to obtaining a service proxy, or Entry's (works with both 
maven codebase provisioning and traditional codebase downloads).
* Input validation for untrusted serial data.
* META-INF/permissions.perm files list permissions required by codebase, 
accessible from ClassLoader using mixin interface.

I recall you had a need for a SocketFactory in LookupLocator, at that time 
LookupLocator only used discovery v1, which was deprecated, I'd like to include 
a way to enable SocketFactory support in discovery V2.  Note that LookupLocator 
isn't serialized during discovery.

While the River codebase was a little difficult to understand at first, I find 
it's quite easy to work with now.

While I'm a critic of Rivers flaws, addressing th em is straight forward, the 
greatest challenge is convincing everyone that flaws exist, or that they need 
addressing, there's still plenty of good stuff left worth saving.

Regards,

Peter.


Sent from my Samsung device.

  Include original message
 Original message 
From: Peter<j...@zeus.net.au>
Sent: 01/07/2016 04:35:16 pm
To: dev@river.apache.org<dev@river.apache.org>
Subject: Re: Lotj - languages other than java





Thanks Sim,

These are all good questions we need to consider.

I like the model of micro services where each service is responsible for 
implementing its own back end persistence and state.  Do you consider a 
microservice to be web based?

I have an implementation of discovery using multicast ipv6.  However for 
firewalls with limited open ports such as https over ipv6, we have JERI https 
endpoints, but no discovery, DNS-SD is a good discovery alternative waiting to 
be implemented.

For my own environment I will be adopting ipv6 , the global address space and 
autoconfiguration solve many problems that users experience with ipv4 today.

I admit the locked down api caused me frustration, but I think it's clear now 
that we need a process for managing api evolution.

Complexity - The proxy preparation api tries to determine trust after 
downloading untrusted code and deserialization of unverified data.  As gadget 
attacks demonstrate, too little too late at great complexity.  This was an 
attempt to bolt security onto the existing lookup service.

JERI is good, method constraints are good, proxy trust is obsolete.  River's 
current ssl and https JERI endpoints need to be brought up to date as they're 
no longer secure.  I've already done this work externally, it can be donated 
when appropriate for the project.

If we address security issues, we can provide a secure alternative to RMI  
Oracle has chosen 'whack a mole' security for Serialization, rather than 
address some fundamental design flaws with ObjectInputStream, for this reason, 
authentication of the source must occur prior to accepting serial data.  
Despite common belief, white listing isn't a completely secure solution and 
adds conplexity as it's too fine grained.

For multi language support, this would limit the type system, but then, there's 
a lot that can be done with strings, primitive types and byte arrays.  This 
doesn't have to limit java service types, I think language support should be 
something determined during lookup, so we don't limit the type systems of more 
powerful languages to primitives.

Looking at most Entry's used for lookup, most fields are strings and integers.  
If you look at the way lookup searches are implemented, an entry is represented 
by a string name and each field is a tuple name value pair.

I think a ground up redesign of the lookup service, would address language 
compatibility as well as complex

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

[Peter]

Thanks Patricia, I can follow up with infra.

Regards,

Peter.

Sent from my Samsung device.
 
  Include original message
 Original message 
From: Patricia Shanahan <p...@acm.org>
Sent: 05/07/2016 07:12:20 pm
To: dev@river.apache.org
Subject: Re: Attic? Was: Re: Lotj - languages other than java

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

[Bishnu Gautam]

Hi Patricia


Bishnu Prasad Gautam


> Subject: Re: Lotj - languages other than java
> To: dev@river.apache.org
> From: p...@acm.org
> Date: Tue, 5 Jul 2016 01:48:11 -0700
> 
> On 7/4/2016 11:38 PM, Bishnu Gautam wrote:
> > Hi Patricia
> >
> >>
> >> 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.
> >
> > Do you have scheme of recruitment with payment or complete
> > volunteers? If it is volunteers, internship program would be the mos
> > practical one. In that context it is quite possible to recruit
> > developers in River by putting internship programs who can work
> > together with active committers or developers in River project. If
> > you open internship program, I can also send my students to work
> > together online with active members of River project. I think this is
> > the most practical solution if they need to work as volunteers. In
> > the beginning we can start from a small scale and once someone is
> > ready to contribute enough from the internship, then we can scale out
> > with more numbers and in this way, the community would be increase.
> > Let me know if you are interested about it.
> >
> 
> No, we can't pay any money.
> Ok I understood.
> I'll be interested in the views of the active committers on the 
> internship model. My current involvement is mainly administrative, but I 
> could help with running an internship program, if it seems likely to 
> work for both the students and River. I am a retired programmer and 
> computer architect, and received a PhD in computer science from UCSD in 
> 2009. I have contributed to StackOverflow especially in Java.
Great to know!. Could you let me know if any active member in River is willing 
to support internship program here. How about opening an internship program 
with specified mentor.  And also what can be learned from that internship 
program in details. I would be able to put some of my students on board if such 
internship program is started in River.  I am pretty sure that this will help 
River community largely in a long term.
RegardsBishnu
> 
> Patricia
> 
  

Re: Lotj - languages other than java

[Tom Hobbs]

My personal jury on River On The Internet is still out...

I like the broadcast UDP model of just firing up a lookup service and finding 
stuff.  That works well for me and my applications are typically contained 
within well defined and secure networks.  I can see the benefit of something 
similar for IoT devices, I can’t yet figure out what the really compelling use 
case is though.

A language agnostic lookup service interface would be really nice though, even 
if it was reduced to just serving up information about what was available 
rather than service proxies for RMI etc.  I have wanted something like that for 
one of my recent projects but couldn’t find anything that would Just Work.  The 
closest I could find was consul.io, but even that required more configuration 
for multiple hosts than I really wanted and didn’t allow me to express 
arbitrary service characteristics.

A REST interface for reggie could work well, but it would still need to have 
language adapters so you can talk to it in ‘your’ language.  I do dislike 
having to use some HTTP library in my Java/Scala code to talk to some service 
hosted on some remote JVM because it only exposes a HTTP(S) REST interface.  If 
my ecosystem is heterogeneous then I shouldn’t have to do that.

If there was a small reggie executable that I could wrap in an init.d service 
or similar and run it on all my hosts, that would be brilliant and is what I am 
intending to pursue when I finally get some down time.  It would be interesting 
to see something like that in competition to ZooKeeper or Apache Curator.  But 
for me, it would have to be really lightweight (like consul.io) with the 
default config out of the box good enough for most internal-network use cases.  
I would be quite happy to see things like the service proxy, code downloading 
etc, all stripped out and replaced with plugin-able options.

The transaction service, spaces and so on aren’t on my radar right now.


> On 5 Jul 2016, at 04:33, Bishnu Gautam <bishn...@hotmail.com> 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.
> RegardsBishnu
> 
> 
> Bishnu Prasad Gautam
> 
> 
>> Date: Mon, 4 Jul 2016 18:37:25 +1000
>> From: j...@zeus.net.au
>> Subject: Re: Lotj - languages other than java
>> To: dev@river.apache.org
>> CC: si...@qcg.nl
>> 
>> 
>> 
>> 
>> Sim,
>> 
>> I'd like to see the project return to the days where we had a number of 
>> active committers working together on the same goals.
>> 
>> I've got a project on github, where I've continued work that was 
>> controversial, I'd like to bring this work back to the project if possible.  
>> It has some minor breaking changes, but if backward compatibility was 
>> essential, it could be accommodated.
>> 
>> Changes:
>> * New secure discovery providers, including https among others, including 
>> added https protocol support for LookupLocator.  However since firewalls may 
>> not allow ipv6 multicast packets through, DNS-SD would be useful.
>> * IPv6 Discovery, global and local groups.
>> * Discovery V2 support added to LookupLocator's getRegistrar method.
>> * Updated encryption ciphers, removal of insecure ones.
>> * Deprecation of ProxyTrust et al.
>> * New default methods added to ServiceRegistrar to allow establising trust 
>> with a service, prior to obtaining a service proxy, or Entry's (works with 
>> both maven codebase provisioning and traditional codebase downloads).
>> * Input validation for untrusted serial data.
>> * META-INF/permissions.perm files list permissions required by codebase, 
>> accessible from ClassLoader using mixin interface.
>> 
>> I recall you had a need for a SocketFactory in LookupLocator, at that time 
>> LookupLocator only used discovery v1, which was deprecated, I'd like to 
>> include a way to enable SocketFactory support in discovery V2.  Note that 
>> LookupLocator isn't serialized during discovery.
>> 
>> While the River codebase was a little difficult to understand at fi

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

[Tom Hobbs]

+1 for Bryan’s PR/GitHub email.  I don’t see any way we couldn’t attribute any 
code change to some user with a CLA active at any given time.

I don’t think the attic represents defeat, I’m reluctant to let it go to the 
attic but right now it seems that more work is being done on the ASF 
administrative stuff than actual code.  That’s not a criticism of Peter or 
anyone else and all the effort has been put into various branches and so on.  
Rather it’s a statement of fact that there are very few us and we’re all busy.

River could always be taken back out of the attic should a new community grow 
around it.

I would be tempted to vote for the attic, whilst simultaneously moving River 
code (v3 if Peter is willing) into a GitHub repo and give the current 
PMC/committers read/write access to it.  (Those that want it, of course.)  
Provide a link from the ASF page to GitHub and back again.  We can carry on 
much the same as before, but without the overhead of filing reports and so on.  
As long as we stick to Bryan’s PR rules below, there shouldn’t be any problem 
giving any changes we eventually make back to the ASF should it be decided to 
do so.

The attic isn’t a defeat, it’s an evolution.

> On 5 Jul 2016, at 13:51, Bryan Thompson  wrote:
> 
> GitHub (at least) provides excellent tracking.  It is a matter of how you
> define policy for PRs.  We do not accept PRs unless the author is a
> contributor with appropriate CLAs for the project.  So it works out very
> nicely for us.  Every single commit and its authorship remains visible and
> that metadata can be easily accessed.
> 
> Thanks,
> Bryan
> 
> On Jul 5, 2016 2:12 AM, "Patricia Shanahan"  wrote:
> 
>> 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: Attic? Was: Re: Lotj - languages other than java

[Bryan Thompson]

GitHub (at least) provides excellent tracking.  It is a matter of how you
define policy for PRs.  We do not accept PRs unless the author is a
contributor with appropriate CLAs for the project.  So it works out very
nicely for us.  Every single commit and its authorship remains visible and
that metadata can be easily accessed.

Thanks,
Bryan

On Jul 5, 2016 2:12 AM, "Patricia Shanahan"  wrote:

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

[Peter]

Thanks Sim, hold that thought, you never know.

The good thing is, we're talking about these things again, without 
heated argument.


An incompatible branch is fine as long as it doesn't have the same 
namespace as the long term support branch, so both can coexist in the 
same jvm.   Those that wish to support a long term support branch or a 
slow moving branch, could do so without impeding a research / 
experimental branch in a different namespace.


It would allow existing deployments to migrate over a long period of time.

Cheers,

Peter.

On 4/07/2016 11:44 PM, Simon IJskes - QCG wrote:

On 04-07-16 10:37, Peter wrote:

I'd like to see the project return to the days where we had a number of
active committers working together on the same goals

I'm sorry that i did not immediately answered your email. I think there
needs to be more buy-in for change, than only the two of us.

Also, the needs that i had for a easy communication system are covered
by code developed in house. It allows for send and post, and async
return of exceptions. A deviation from the river model.

Maybe we can restart as a universal library for safe-RMI. With easy
options for connections to and from known (or discovered by outside
means) endpoints, IPv6, poking through UPNP and NAT firewalls,
multi-homed host capable (without -D options on the command line).

Modular addable lookup services, discovery, identity, locking, tspaces,
etc. But at least a system with a very low knowledge threshold, and
small jar footprint to get things working.

We could use a more modern declarative system for specifying security
needs, so that later we could create adapters for in and outbound rpc
protocols with a bigger market reach.

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

[Peter]

Can we move to git, without moving to GitHub?

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.

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.


Regards,

Peter.

On 5/07/2016 1:47 AM, Patricia Shanahan wrote:

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  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: Lotj - languages other than java

[Peter]

Thanks Bishnu,

Mark Brouwer originally pointed out many years ago, that while jini had 
https jeri endpoints, there was no support to perform unicast discover 
over https in LookupLocator discovery.


I have implemented that.

Now, you can have any number of publicly available lookup services, and 
contact them using https unicast with LookupLocator, 
ConstrainableLookupLocator and LookupLocatorDiscovery.  DNS-SD is an 
obvious substitute for multicast discovery for clients behind firewalls, 
but it hasn't been implemented yet.


With public lookup services, even when not discoverable with multicast 
discovery (because your clients are behind firewalls), can register with 
each other, using multicast discovery, allowing clients behind firewalls 
to find others, so they only need to know a few permanent registrars to 
find others, when they don't have access to multicast discovery.


Non public service clients (behind firewalls or NAT) can locate public 
services.  Non public clients can listen behind NAT and firewalls, when 
they register a listener with a lookup service, they will be notified of 
new service registrations, because https jeri endpoints will keep the 
connection (ports) open between a lookup service and clients behind 
firewalls.


So lets say for example, you have an embedded client behind a firewall, 
which is also a master for an IoT wireless local network and there are 
several devices that will send a video stream or other data, then for 
instance a public consumer service, could register with a lookup service 
where the embedded client was listening, then be contacted and 
authenticated by the embedded client and access a service directly from 
the client to receive live data streams from that wireless network, this 
may then republish the data accumulated from multiple such embedded 
clients via a web site.  Clients behind NAT must initiate contact, only 
then can they be contacted.


JERI multiplexes, so you can have 127 active service connections over 
one connection between two nodes.


LetsEncrypt.org is a free certificate authority than can be utilised for 
https jeri endpoints.  LetsEncrypt.org doesn't provide code 
certificates, so they can't be used for signing jar files.


To avoid the expense of CA signed codebase certificates, https discovery 
automatically grants DownloadPermission and DeserializationPermission 
(which is required to allow proxy deserialization over a https jeri 
endpoint with an InputValidation constraint), to an anoymous code signer 
certificate and uri exchanged during the discovery process, but only if 
authentication is successful.  The codebase jar file can also contain 
the permissions it requires, so that these can be granted dynamically by 
the client during proxy preparation.


In addition https jeri endpoint encryption cyphers have all been updated 
to modern secure cyphers and support for insecure cyphers has been removed.


Default methods have been added to ServiceRegistrar, to allow the client 
to authenticate services prior to retrieving proxy's and Entry's.  
ProxyTrust verfiiers are no longer necessary as the proxy is obtained 
directly from the service after authentication, rather than via a third 
party.  The proxy is already trusted.


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

I hope to get this accepted by River at some point, I figure that 
creating a demonstration will assist the understanding process for other 
developers, as I wasn't able to communicate effectively enough to avoid 
strong resistance and criticism when I originally proposed it.


Regards,

Peter.


On 5/07/2016 1: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.
RegardsBishnu


Bishnu Prasad Gautam



Date: Mon, 4 Jul 2016 18:37:25 +1000
From: j...@zeus.net.au
Subject: Re: Lotj - languages other than java
To: dev@river.apache.org
CC: si...@qcg.nl




Sim,

I'd like to see the project return to the days where we had a number of active 
committers working together on the same goals.

I've got a project on github, where I've continued work that was controversial, 
I'd like to bring this work back to the project if possible.  It has some minor 
breaking changes, but if backward compatibility was essential, it could be 
accommodated.

Changes

RE: Lotj - languages other than java

[Bishnu Gautam]

Hi Patricia

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

Do you have scheme of recruitment with payment or complete volunteers? If it is 
volunteers, internship program would be the mos practical one. In that context 
it is quite possible to recruit developers in River by putting internship 
programs who can work together with active committers or developers in River 
project. If you open internship program, I can also send my students to work 
together online with active members of River project. I think this is the most 
practical solution if they need to work as volunteers. In the beginning we can 
start from a small scale and once someone is ready to contribute enough from 
the internship, then we can scale out with more numbers and in this way, the 
community would be increase. Let me know if you are interested about it.
RegardsBishnu 

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: Lotj - languages other than java

[Bishnu Gautam]

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.
RegardsBishnu


Bishnu Prasad Gautam


> Date: Mon, 4 Jul 2016 18:37:25 +1000
> From: j...@zeus.net.au
> Subject: Re: Lotj - languages other than java
> To: dev@river.apache.org
> CC: si...@qcg.nl
> 
>  
>  
>  
> Sim,
> 
> I'd like to see the project return to the days where we had a number of 
> active committers working together on the same goals.
> 
> I've got a project on github, where I've continued work that was 
> controversial, I'd like to bring this work back to the project if possible.  
> It has some minor breaking changes, but if backward compatibility was 
> essential, it could be accommodated.
> 
> Changes:
> * New secure discovery providers, including https among others, including 
> added https protocol support for LookupLocator.  However since firewalls may 
> not allow ipv6 multicast packets through, DNS-SD would be useful.
> * IPv6 Discovery, global and local groups.
> * Discovery V2 support added to LookupLocator's getRegistrar method.
> * Updated encryption ciphers, removal of insecure ones.
> * Deprecation of ProxyTrust et al.
> * New default methods added to ServiceRegistrar to allow establising trust 
> with a service, prior to obtaining a service proxy, or Entry's (works with 
> both maven codebase provisioning and traditional codebase downloads).
> * Input validation for untrusted serial data.
> * META-INF/permissions.perm files list permissions required by codebase, 
> accessible from ClassLoader using mixin interface.
> 
> I recall you had a need for a SocketFactory in LookupLocator, at that time 
> LookupLocator only used discovery v1, which was deprecated, I'd like to 
> include a way to enable SocketFactory support in discovery V2.  Note that 
> LookupLocator isn't serialized during discovery.
> 
> While the River codebase was a little difficult to understand at first, I 
> find it's quite easy to work with now.  
> 
> While I'm a critic of Rivers flaws, addressing th em is straight forward, the 
> greatest challenge is convincing everyone that flaws exist, or that they need 
> addressing, there's still plenty of good stuff left worth saving.
> 
> Regards,
> 
> Peter.
> 
> 
> Sent from my Samsung device.
>  
>   Include original message
>  Original message ----
> From: Peter <j...@zeus.net.au>
> Sent: 01/07/2016 04:35:16 pm
> To: dev@river.apache.org <dev@river.apache.org>
> Subject: Re: Lotj - languages other than java
> 
>  
>  
>  
>  
> Thanks Sim,
> 
> These are all good questions we need to consider.
> 
> I like the model of micro services where each service is responsible for 
> implementing its own back end persistence and state.  Do you consider a 
> microservice to be web based? 
> 
> I have an implementation of discovery using multicast ipv6.  However for 
> firewalls with limited open ports such as https over ipv6, we have JERI https 
> endpoints, but no discovery, DNS-SD is a good discovery alternative waiting 
> to be implemented.
> 
> For my own environment I will be adopting ipv6 , the global address space and 
> autoconfiguration solve many problems that users experience with ipv4 today.
> 
> I admit the locked down api caused me frustration, but I think it's clear now 
> that we need a process for managing api evolution.  
> 
> Complexity - The proxy preparation api tries to determine trust after 
> downloading untrusted code and deserialization of unverified data.  As gadget 
> attacks demonstrate, too little too late at great complexity.  This was an 
> attempt to bolt security onto the existing lookup service.
> 
> JERI is good, method constraints are good, proxy trust is obsolete.  River's 
> current ssl and https JERI endpoints need to be brought up to date as they're 
> no longer secure.  I've already done this work externally, it can be donated 
> when appropriate for the project.
> 
> If we address security issues, we can provide a secure alternative to RMI  
> Oracle has chosen 'whack a mole' security for Se

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

[Bryan Thompson]

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  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: Lotj - languages other than java

[Simon IJskes - QCG]

On 04-07-16 10:37, Peter wrote:
> I'd like to see the project return to the days where we had a number of
> active committers working together on the same goals

I'm sorry that i did not immediately answered your email. I think there
needs to be more buy-in for change, than only the two of us.

Also, the needs that i had for a easy communication system are covered
by code developed in house. It allows for send and post, and async
return of exceptions. A deviation from the river model.

Maybe we can restart as a universal library for safe-RMI. With easy
options for connections to and from known (or discovered by outside
means) endpoints, IPv6, poking through UPNP and NAT firewalls,
multi-homed host capable (without -D options on the command line).

Modular addable lookup services, discovery, identity, locking, tspaces,
etc. But at least a system with a very low knowledge threshold, and
small jar footprint to get things working.

We could use a more modern declarative system for specifying security
needs, so that later we could create adapters for in and outbound rpc
protocols with a bigger market reach.

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: Lotj - languages other than java

[Peter]

 
 
 
Sim,

I'd like to see the project return to the days where we had a number of active 
committers working together on the same goals.

I've got a project on github, where I've continued work that was controversial, 
I'd like to bring this work back to the project if possible.  It has some minor 
breaking changes, but if backward compatibility was essential, it could be 
accommodated.

Changes:
* New secure discovery providers, including https among others, including added 
https protocol support for LookupLocator.  However since firewalls may not 
allow ipv6 multicast packets through, DNS-SD would be useful.
* IPv6 Discovery, global and local groups.
* Discovery V2 support added to LookupLocator's getRegistrar method.
* Updated encryption ciphers, removal of insecure ones.
* Deprecation of ProxyTrust et al.
* New default methods added to ServiceRegistrar to allow establising trust with 
a service, prior to obtaining a service proxy, or Entry's (works with both 
maven codebase provisioning and traditional codebase downloads).
* Input validation for untrusted serial data.
* META-INF/permissions.perm files list permissions required by codebase, 
accessible from ClassLoader using mixin interface.

I recall you had a need for a SocketFactory in LookupLocator, at that time 
LookupLocator only used discovery v1, which was deprecated, I'd like to include 
a way to enable SocketFactory support in discovery V2.  Note that LookupLocator 
isn't serialized during discovery.

While the River codebase was a little difficult to understand at first, I find 
it's quite easy to work with now.  

While I'm a critic of Rivers flaws, addressing th em is straight forward, the 
greatest challenge is convincing everyone that flaws exist, or that they need 
addressing, there's still plenty of good stuff left worth saving.

Regards,

Peter.


Sent from my Samsung device.
 
  Include original message
 Original message 
From: Peter <j...@zeus.net.au>
Sent: 01/07/2016 04:35:16 pm
To: dev@river.apache.org <dev@river.apache.org>
Subject: Re: Lotj - languages other than java

 
 
 
 
Thanks Sim,

These are all good questions we need to consider.

I like the model of micro services where each service is responsible for 
implementing its own back end persistence and state.  Do you consider a 
microservice to be web based? 

I have an implementation of discovery using multicast ipv6.  However for 
firewalls with limited open ports such as https over ipv6, we have JERI https 
endpoints, but no discovery, DNS-SD is a good discovery alternative waiting to 
be implemented.

For my own environment I will be adopting ipv6 , the global address space and 
autoconfiguration solve many problems that users experience with ipv4 today.

I admit the locked down api caused me frustration, but I think it's clear now 
that we need a process for managing api evolution.  

Complexity - The proxy preparation api tries to determine trust after 
downloading untrusted code and deserialization of unverified data.  As gadget 
attacks demonstrate, too little too late at great complexity.  This was an 
attempt to bolt security onto the existing lookup service.

JERI is good, method constraints are good, proxy trust is obsolete.  River's 
current ssl and https JERI endpoints need to be brought up to date as they're 
no longer secure.  I've already done this work externally, it can be donated 
when appropriate for the project.

If we address security issues, we can provide a secure alternative to RMI  
Oracle has chosen 'whack a mole' security for Serialization, rather than 
address some fundamental design flaws with ObjectInputStream, for this reason, 
authentication of the source must occur prior to accepting serial data.  
Despite common belief, white listing isn't a completely secure solution and 
adds conplexity as it's too fine grained.

For multi language support, this would limit the type system, but then, there's 
a lot that can be done with strings, primitive types and byte arrays.  This 
doesn't have to limit java service types, I think language support should be 
something determined during lookup, so we don't limit the type systems of more 
powerful languages to primitives.

Looking at most Entry's used for lookup, most fields are strings and integers.  
If you look at the way lookup searches are implemented, an entry is represented 
by a string name and each field is a tuple name value pair.

I think a ground up redesign of the lookup service, would address language 
compatibility as well as complexity and security.

In other words, recognise the need for a lookup & registration protocol, as 
well as discovery, after that, the service & client should be able to negotiate 
 whatever rpc protocol they have in common and to do that, we'll also need a 
connection negotiation protocol.  We could write specifications for these 
protocols.  This way we could allow any language/ platform to register and 
provide services.  The c

Re: Lotj - languages other than java

[Simon IJskes - QCG]

If you solve the 'barrier' of the service discovery, do you also want to 
provide universal access to the java services in the form of microservices?


It is doable to take any 'more used' service discovery solution and use 
this as the river discovery. To introduce a level of abstraction with 
the same primitives as the current river discovery mechanism offers.


River would then have adapted a more common discovery mechanism.

Next thing that we should decide, is how far do we go into universality. 
I see univeral type systems, different serialisation plugins on the horizon.


The biggest showstopper for me was the API compatibility. In order to 
make any progress we need a more agile process for modifing the API.


If we leave compatibility behind us, we could ask our selfs, what 
benefit are we providing for the users? What can we introduce that does 
not duplicate what is already in the market. For a java developer, i 
think there is no need to convince, they can see benefits in just having 
a java API to program against. We need to think about the environment 
where java receives a lot of 'non-love', how we can create a 'whow, java 
isn't all that bad, look at that easy solution' experience.


I think that river lost the spot it could have, as a java only solution 
to JSON, XMLRPC, SOAP, etc libraries for java. From a helicopter view, 
what does it do? Whe provide secure RPC, with discovery and scaling. And 
we make it hard to use.


G. Simon


On 30-06-16 05:37, Peter wrote:

Currently with River, you need java to participate.  Other languages can 
provide services, but you need a jvm to participate.

Most of discovery is language agnostic, so any language can participate in 
discovery.

The major limitation for other languages is the lookup service.  Security 
issues and complexity also relate to the lookup service.

My thoughts are that a lookup service that performs search and registration, 
but provides a language independent  and secure means of contacting service 
providers would be beneficial.

Anyone interested in discussing further?

Regards,

Peter.


Sent from my Samsung device.

Lotj - languages other than java

[Peter]

Currently with River, you need java to participate.  Other languages can 
provide services, but you need a jvm to participate.

Most of discovery is language agnostic, so any language can participate in 
discovery.

The major limitation for other languages is the lookup service.  Security 
issues and complexity also relate to the lookup service.

My thoughts are that a lookup service that performs search and registration, 
but provides a language independent  and secure means of contacting service 
providers would be beneficial.  

Anyone interested in discussing further?

Regards,

Peter.


Sent from my Samsung device.