Thanks Roy, I'll keep that in mind.
On 16/02/2022 3:15 am, Roy T. Fielding wrote:
On Feb 15, 2022, at 4:05 AM, Peter Firmstone
wrote:
I think the PMC has already decided River's fate, and I tend to agree with
their decision, the problem is that historically, it hasn't been possible
and Jini, would be
much appreciated.
Regards,
Peter.
On 16/02/2022 9:32 pm, Peter Firmstone wrote:
Hi Michał,
I didn't take it personal, and don't expect you to take it personal
either when I say, I'm pretty sure everyone here is aware of River /
Jini limitations.
Anyway River has been a lot
,
Peter.
On 16/02/2022 7:53 pm, Michał Kłeczek wrote:
Hi Peter,
On 16 Feb 2022, at 10:01, Peter Firmstone
wrote:
Inline below.
On 16/02/2022 5:24 pm, Michał Kłeczek wrote:
On 16 Feb 2022, at 04:25, Peter Firmstone
wrote:
From the CodebaseAccessor service.
The CodebaseAccessor proxy
Hi Michał,
Inline below.
On 16/02/2022 5:24 pm, Michał Kłeczek wrote:
On 16 Feb 2022, at 04:25, Peter Firmstone wrote:
From the CodebaseAccessor service.
The CodebaseAccessor proxy (local code) is passed as a parameter along with a
MarshalledInstance of the proxy, by ProxySerializer
Hi Michał, responses inline below.
On 15/02/2022 10:22 pm, Michał Kłeczek wrote:
On 15 Feb 2022, at 13:05, Peter Firmstone
wrote:
How the client knows the code needed to deserialise?
The service provides this information, typically in a services
configuration,
How
On 15/02/2022 8:29 pm, Michał Kłeczek wrote:
Hi Peter,
JGDMS uses a new implementation of a subset of the Java
Serialization’s stream format, with input validation and defenses
against malicious data (all connections are first authenticated when
using secure endpoints). Codebase
*/
public byte [] getEncodedCerts() throws IOException;
}
On 15/02/2022 1:07 am, Michał Kłeczek wrote:
Hi All,
Based on the excelent work of (mainly) Peter Firmstone (et al) I am personally
working on “River 4.0” right now and was planning to share my work with the
community soon(tm).
1.
published. We are preparing
next paper that shows the potential of River to integrate with other
technologies so that more users will understand how to utilize this
technology.
Bishnu Prasad Gautam
*From:* Peter Firmstone
Even in the Attic, River will remain a valuable resource of information.
When OpenJDK published JEP411 in April 2021, they believed what we were
already doing with River was impossible, which succinctly sums up a
number of River's features.
I'm so sorry to hear Patricia lost her battle with cancer, she had a
stabilizing influence on all of us, especially when there was strong
disagreement among developers, she would find a way to rationalize the
discussion. She would thoroughly investigate and document problems with
the code,
.
--
Regards,
Peter Firmstone.
Hi Dennis,
Did you want to commit your Gradle build changes to trunk?
Cheers,
Peter.
On 16/02/2021 7:19 am, Peter Firmstone wrote:
Hi Dennis,
Yes & No, this is a module Gradle build of trunk, looking forward to
some contribution from you on that front. We're currently trying to
fi
ll the
svn history. From there, we can start to “break things” (literally
and figuratively) into smaller repos. The underlying assumption is
just about everything will be easier to do (merging, etc) with a
git repo.
Either way, I’ll start looking for lines along which I co
break things” (literally and
figuratively) into smaller repos. The underlying assumption is just
about everything will be easier to do (merging, etc) with a git repo.
Either way, I’ll start looking for lines along which I could break things.
Dan
On Feb 9, 2021, at 3:42 AM, Peter Firmstone
mailto:
Hello River Folk,
This is a concept test class, for testing a Public Serialization API,
for supporting alternative serialization frameworks. Note this doesn't
implement Serializable for clarity.
--
Regards,
Peter
/*
* Copyright 2021 The Apache Software Foundation.
*
* Licensed under
ion? Where to start?
The plan you itemize makes sense to me.
Dan Rollo
On Feb 8, 2021, at 8:35 PM, Peter Firmstone wrote:
Hello River folk,
There's an upcoming board report due shortly, I wanted to gauge people's
interest in the project.
We've got two pending tasks:
1. SVN to Git Migration
?
--
Regards,
Peter Firmstone
Anyone have some cycles to help out with the SVN to Git migration?
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
by the end of last year. There
are still a number using the Apache CMS, and we have not set a hard
deadline for shutting it down. However, the system is becoming less
reliable, so moving sooner rather than later is probably a good idea.
Andrew
On Wed, Feb 3, 2021 at 8:08 PM Peter Firmstone
wrote
source=link_campaign=sig-email_content=webmail
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
like Sparkplug have an impact on
system design!
Gregg
Sent from my iPhone
On Jan 30, 2021, at 12:05 AM, Peter Firmstone
wrote:
Hi Gregg,
Yes, of course, if the service was using Java Serialization, the bytes would be
the same, but if a different Serialzation protocol was used, the bytes w
han the stream of bytes that
existing serialization creates through Object methods to help clarify?
Gregg
Sent from my iPhone
On Jan 29, 2021, at 3:46 PM, Peter Firmstone
wrote:
A question came up recently about supporting other serialization protocols.
JERI currently has three layers to i
have not implemented an explicit serialization API, it, or something
similar could easily be used as a serialization provider interface,
which would allow wrappers for various serialization protocols to be
implemented.
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
into view in a way that is also “easy” to consume.
Gregg
On Jan 18, 2021, at 4:44 PM, Peter Firmstone
wrote:
Hello River folk,
Just an update on progress, the git mirror was out of date, it has been deleted
to clear the way for copying our current SVN.
https://issues.apache.org/jira/browse
currently.
I welcome suggestions as to how the git repositories should be structured.
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
assistance from INFRA.
--
Regards,
Peter Firmstone
0498 286 363
Zeus Project Services Pty Ltd.
No pressure if you're not comfortable, I should have some time in a
fortnight.
On 11/22/2020 4:21 PM, Peter Firmstone wrote:
If you feel confident enough to have a go at SVN move. :-)
On 11/22/2020 11:03 AM, Dan Rollo wrote:
Hi Peter,
Sounds good to me.
If you have any idiot proof tasks
If you feel confident enough to have a go at SVN move. :-)
On 11/22/2020 11:03 AM, Dan Rollo wrote:
Hi Peter,
Sounds good to me.
If you have any idiot proof tasks, let me know, I’d be happy to help.
Dan
On Nov 21, 2020, at 6:16 PM, Peter Firmstone
wrote:
Hello River folk,
What I had
Hello River folk,
What I had in mind next was to SVN move the existing trunk out of the
way, then SVN move the modular branch to trunk, then SVN move other
relevant code branches we wanted to keep into trunk as well. Then
finally we can ask INFRA to migrate us to git.
Please feel free to
Hello River folk,
Please review or make any suggestions you'd like to communicate to the
board.
Regards,
Peter.
The River project typically operates in maintenance mode, however there
is an ongoing long term undertaking to make River's monolithic codebase
modular.
The project has voted
The vote passes with 4 binding and 1 non binding:
+1 Dan Rollo
+1 Dennis Reedy
+1 Phillip Rhodes (non binding)
+1 Bryan Thompson
+1 Peter Firmstone
Regards,
Peter.
On 10/15/2020 12:12 AM, danro...@gmail.com wrote:
+1
On Oct 14, 2020, at 8:57 AM, Dennis Reedy wrote:
+1
On Oct 12
The following is an interesting slide:
https://speakerdeck.com/pwntester/surviving-the-java-deserialization-apocalypse?slide=31
Oracle has stated they will not fix these security issues with
Collection classes for de-serialization.
River-49 also identifies serial form issues with
at, Oct 10, 2020 at 15:10 Peter Firmstone
wrote:
Some additional rationale:
The original reason some people wanted a stable trunk branch was they
were concerned about the pace of development moving too fast, clearly
that's no longer a problem, now the stable development branch has become
an
, Peter Firmstone wrote:
Currently the trunk branch is a stable branch, it is not for
development code, let's make it so we can develop in trunk. The vote
concludes in two weeks.
+1 Peter.
Rationale:
The project needs to migrate from SVN to GIT.
The trunk branch is the GIT branch, currently it's
A good summary of all known Java deserialization vulnerabilities.
https://github.com/PalindromeLabs/Java-Deserialization-CVEs
Cheers,
Peter.
,
Peter.
On 10/10/2020 9:03 AM, Peter Firmstone wrote:
Currently the trunk branch is a stable branch, it is not for
development code, let's make it so we can develop in trunk. The vote
concludes in two weeks.
+1 Peter.
Rationale:
The project needs to migrate from SVN to GIT.
The trunk branch
Currently the trunk branch is a stable branch, it is not for development
code, let's make it so we can develop in trunk. The vote concludes in
two weeks.
+1 Peter.
Rationale:
The project needs to migrate from SVN to GIT.
The trunk branch is the GIT branch, currently it's only read only but
I'd like to see us do that, and do
it with the approved move to a Git repository.
Regards
Dennis
On Sat, Jul 11, 2020 at 8:32 PM Peter Firmstone
wrote:
Hi Dennis,
Yes definitely, if you're ok with that.
The qa test suite could potentially be modularized as well, I'm guessing
it would be eas
as the primary repo? Or
have we already?
Phil
On Wed, Jun 17, 2020 at 12:58 AM Peter Firmstone
wrote:
We seem to have a few smaller projects outside of river trunk, including
the website and the modular build.
http://svn.apache.org/viewvc/river/
It may be easier to replace trunk with the modular
Hello River folk,
Please review or make any suggestions you'd like to communicate to the
board.
Regards,
Peter.
As per the boards request we discussed the Attic and there was strong
support for continuing the River project, despite activity being
relatively quiet, it does appear that the
Why not indeed :)
I'd be in favour of moving "unit tests" out of the jtreg and qa tests
suites into junit first . I'd suggesting leaving the jtreg bug
regression tests where they are for now at least, as far more work is
required and they may not all be relevant; we no longer have bug
On 7/13/2020 6:14 AM, Zsolt Kúti wrote:
On Sat, Jul 11, 2020 at 3:16 PM Dennis Reedy wrote:
Hi Zsolt,
There are a few tests in there, most are in the qa directory in the main
svn repository. I think it would be great if we could find a way to merge
them into the modules and follow
into the project. I merged the modules for
expediency. I’ll spend some time next week doing that if we’d like to move it
forward.
Regards
Dennis
On Jul 11, 2020, at 5:04 AM, Peter Firmstone
wrote:
HI Dennis,
Had a quick look just now, I can see why gradle is attractive.
I'm not a big fan
Thanks Phil,
Definitely a bonus, I guess now we need to get the qa suite of tests
running against the new module jar's.
There will be a lot of test failures due to security policy file changes
that will be required, this usually happens with every major Java
version change in any case.
HI Dennis,
Had a quick look just now, I can see why gradle is attractive.
I'm not a big fan of the larger modules, but you have demonstrated it
can work.
I guess it's a trade off between maintainability and avoiding the need
to untangle the circular links.
Have you had a look at the code
Oh, it builds now, I think there are some remaining junit tests that
need relocating too.
Cheers,
Peter.
On 7/9/2020 8:17 PM, Peter Firmstone wrote:
I've created issue River-471 all commits to this issue are untangling
circular links.
Please review.
On 7/9/2020 8:10 PM, peter_firmst
I've created issue River-471 all commits to this issue are untangling
circular links.
Please review.
On 7/9/2020 8:10 PM, peter_firmst...@apache.org wrote:
Author: peter_firmstone
Date: Thu Jul 9 10:10:53 2020
New Revision: 1879695
URL: http://svn.apache.org/viewvc?rev=1879695=rev
Log:
Perhaps we could agglomerate the modules, in the case below however,
this would make river-platform depend on river-lib, which depends on
river-dl, due to other dependencies and we don't really want that either.
In practise I was able to eliminate the circular dependencies in JGDMS
without
ead the following articles:
[ERROR] [Help 1]
http://cwiki.apache.org/confluence/display/MAVEN/ProjectBuildingException
Is this what I should expect?
On Sun, Jul 5, 2020 at 2:41 PM Phillip Rhodes
mailto:motley.crue@gmail.com>> wrote:
On Sun, Jul 5, 2020 at 8:07 AM Peter
client code depended on, others can be added as
required. Using a compatibility layer module for breaking changes
appears to be a good approach.
Cheers,
Peter.
On 7/6/2020 4:41 AM, Phillip Rhodes wrote:
On Sun, Jul 5, 2020 at 8:07 AM Peter Firmstone
wrote:
Hi Phil,
I've been going through
Hi Phil,
I've been going through your patch, you've got a lot of work done in a
short time. :)
I've just committed your changes.
I'll have a look at the circular dependencies and see what I can do in
the coming week.
Cheers,
Peter.
On 7/5/2020 3:46 AM, Phillip Rhodes wrote:
Hi Phil,
Hi Phil,
Wow, you're really getting into the code, thank you.
It's late here, I'll post again in the morning, just some quick
clarifications, the discovery providers depend on the platform, but the
platform shouldn't depend on the discovery providers, try removing that
dependency from the
Hi Phil,
Yes, we'd like your patches :)
You can upload them here:
https://issues.apache.org/jira/projects/RIVER/issues/RIVER-300
It depends on river-dl, this module was renamed from river-lib-dl.
Cheers,
Pete.
On 7/4/2020 7:10 AM, Phillip Rhodes wrote:
Moving this to a new thread.
I
Hi Philip,
The most recent modular build attempt is here:
http://svn.apache.org/viewvc/river/jtsk/modules/
Cheers,
Peter.
On 7/3/2020 2:19 PM, Phillip Rhodes wrote:
Aaah, I may not be using the latest code then. For me, the maven build
is failing right now due to missing dependencies on
Hi Phil,
It's great to have your help. :)
The maven build structure is almost complete, there are some junit tests
that need to be moved over to their relevant modules from the old ant
build. After that there will be some minor implementation dependencies
between the modules that need to be
We seem to have a few smaller projects outside of river trunk, including
the website and the modular build.
http://svn.apache.org/viewvc/river/
It may be easier to replace trunk with the modular build in svn as this
includes all work over the last three years, then make git primary.
Where
,
org.apache.river.test.share.BaseQATest.class,
Compression.DEFLATE
)
);
On 6/8/2020 2:58 PM, Peter Firmstone wrote:
Hello River folk,
A couple of years or so ago I was working on using Pack200 for
compression of proxy codebases, then it was deprecated and more
recently
Hello River folk,
A couple of years or so ago I was working on using Pack200 for
compression of proxy codebases, then it was deprecated and more recently
removed from Java 14.
Initially I took pack 200 from Harmony and started working on that, at
the time I thought the JDK version was
().equals(((RemoteMethodControl)originalProxy).setConstraints(localClientConstraints).getServiceIdentity())
== true
My 2 cents :)
Thanks,
Michal
On 26/05/2020 10:10:50, "Peter Firmstone"
wrote:
Hello River folk.
As you are probably aware, I have an interest in security and have
be
No worries, happy to help.
Cheers,
Peter.
On 6/3/2020 9:50 AM, Dennis Reedy wrote:
Hey Peter,
Thanks for the reference. I think it would be great to get this done this
month, might need some assistance.
Regards Dennis
On Jun 2, 2020, at 5:35 PM, Peter Firmstone wrote:
Dennis,
How
Dennis,
How soon did you want to migrate to git?
The following seems like a good guide:
https://cwiki.apache.org/confluence/display/commons/MovingToGit
Regards,
Peter.
On 5/30/2020 12:11 AM, Dennis Reedy wrote:
With 4 in favor, 0 against, the vote to change from subversion to Git is
the support for
TLS connections with RemoteEvents.
On Jun 2, 2020, at 12:41 PM, Peter Firmstone
mailto:peter.firmst...@zeus.net.au>> wrote:
Hi Shawn,
Confirming I have stateless TLS working now.
It required a few more changes, but nothing substantial, it builds
other work I've been chippin
Just confirming I've found failing tests, still working on it
On 6/1/2020 10:12 PM, Peter Firmstone wrote:
Thanks Shawn,
I've been testing on JDK 11 and 13 recently, I've just downloaded JDK
14.0.1
I ran the qa suite lookupservice tests with JSSE enabled (Using qa
suite on JGDMS which
Thanks Shawn,
I've been testing on JDK 11 and 13 recently, I've just downloaded JDK 14.0.1
I ran the qa suite lookupservice tests with JSSE enabled (Using qa suite
on JGDMS which is working with JSSE).
Confirmed the tests hang and fail.
Looked at JDK-8242008
Notably: "SSLSessions obtained
Hi Dennis,
Yes, the vote passed (minimum 3 committers), you can post a [RESULT]
email with the voting results of all voters.
I found the following:
https://cwiki.apache.org/confluence/display/commons/MovingToGit
The Maven project's progress:
at the Multidisciplinary Science and Technology
Center with git/gradle uniform build automation, distributions and
testing. I do not see another better alternative for River than
git/gradle.
If Dennis needs my help I am available.
Regards
Mike
On May 27, 2020, at 3:33 AM, Peter Firmstone
mailto:peter.firmst
+1 Peter
On 5/28/2020 9:26 AM, Dennis Reedy wrote:
Git provides greater flexibility for distributed development, feature branches,
pull requests, etc... this is a vote to move River from subversion to git
using subversion?
Dennis
On May 27, 2020, at 4:33 AM, Peter Firmstone
wrote:
Thanks Dan,
Hi Dennis,
I recall Michael from Sorcer Soft (cc'd) also showed interest in a
Gradle build.
The modular build is here:
https://svn.apache.org/viewvc/river/jtsk/modules/
svn checkout http
From: Peter Firmstone
Subject: Proxy identity behaves unexpectedly for secure services.
Date: May 26, 2020 at 4:10:50 AM EDT
To: dev@river.apache.org
Hello River folk.
As you are probably aware, I have an interest in security and have been focused
on simplifying the use of secure services
Thanks Dan,
Hi Dennis,
I recall Michael from Sorcer Soft (cc'd) also showed interest in a
Gradle build.
The modular build is here:
https://svn.apache.org/viewvc/river/jtsk/modules/
svn checkout http://svn.apache.org/repos/asf/river/jtsk/modules
Do you still have svn access? It's a
up these changes.
Regards
Dennis
On Fri, May 22, 2020 at 12:07 AM Peter Firmstone <
peter.firmst...@zeus.net.au> wrote:
Hi Dennis,
Good to hear from you.
The truth is, I'm no build expert, Dan is much more capable than I am,
so I'm waiting to hear Dan's opinion on Gradle, it certainly
owards this. When will the project reach a state where it
will engage a new group of developers and what actions will it take to help
make that happen beyond the technology development?
Bryan
On Thu, May 21, 2020 at 01:46 Peter Firmstone
Thanks Patricia,
I'm not sure we're going to see a signi
to be more concerned about an active community than
technical matters. We need to discuss whether there is a pool of
potential contributors who are likely to become active.
On 5/20/2020 5:51 PM, Peter Firmstone wrote:
Hello River Folk,
I've received feedback from the Board this morning
feel better”….to soon? ;)
Dan
From: Peter Firmstone
Subject: Board feedback - Request discuss attic for River
Date: May 20, 2020 at 8:51:42 PM EDT
To: dev@river.apache.org
Hello River Folk,
I've received feedback from the Board this morning, they are requesting that we
discuss the Attic
if they don't want to.
This will also eliminate the many problems that codebase annotation loss
causes for new developers.
Regards,
Peter Firmstone.
Hello River Folk,
I've received feedback from the Board this morning, they are requesting
that we discuss the Attic for River.
Personally I think the project still has a lot of potential to pick up
again once the modular build is complete, and it is a useful place to
send patches and
will work for me. Could you share the codes and the
documents about it. I would really appreciate for that.
Sincerely Yours
Bishnu Prasad Gautam
____
From: Peter Firmstone
Sent: Wednesday, May 13, 2020 7:52 AM
To: dev@river.apache.org
Subject: Re: Further update regarding
Project loom looks very promising:
http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html
River uses a lot of threads, many block waiting for network responses...
Virtual Threads could help significantly with salability.
Something else I've thought about in the past is Pack200, since
Hi Bishnu,
Can you use IPv6?
I have a Unicast https implementation (to get through https firewalls)
and IPv6 multicast discovery (can be configured to be global or limited
to your intranet)
There were a number of different types of IPv4 NAT firewalls / routers,
so it was never going to be
so far. Happy hermit life.
Dan
On May 7, 2020, at 11:27 AM, dev-digest-h...@river.apache.org
<mailto:dev-digest-h...@river.apache.org> wrote:
*From:*Peter Firmstone <mailto:peter.firmst...@zeus.net.au>>
*Subject:**Draft Report River - May 2020*
*Date:*May 7, 2020 at 3:31:09
Hello River Folk,
Please review the May report draft below. With work starting to slow
down, I should have some time to complete the modular build soon.
How are you being impacted by Covid-19?
Regards,
Peter Firmstone.
## Description:
- Apache River provides a platform for dynamic
I didn't make the February deadline, so I'll post the report in time for
March.
+1 Peter.
Please vote at your convenience.
Regards,
Peter.
On 2/20/2020 6:29 AM, Dan Rollo wrote:
Looks good to me. +1
Dan Rollo
From: Peter Firmstone
Subject: February Board Report Draft
Date: February 18
Hello River folk, please review / comment / suggest / changes for the
draft board report for February below.
Regards,
Peter.
## Description:
- Apache River provides a platform for dynamic discovery and lookup
search of network services. Services may be implemented in a number
of
Hello River folk, please review / comment / suggest / changes for the
draft board report for November below.
Regards,
Peter.
## Description:
- Apache River provides a platform for dynamic discovery and lookup
search of network services. Services may be implemented in a number
of
Wonderly wrote:
I think considering an unsigned byte value should be a reasonable step.
Gregg
Sent from my iPhone
On Sep 1, 2019, at 9:41 PM, Peter Firmstone wrote:
Hello,
The JERI multiplexing protocol allows 128 sessions between two nodes, when this
value is exceeded, an exception is thrown
As most are probably aware, we are progressing with the Maven build of
River, all packages have been moved and now it's time to commence moving
the junit tests to their maven modules.
The maven build structure is based on the work we've done in JGDMS, but
there's no java code coming in from
Hello River folk, please review / comment / suggest / changes for the
draft board report for August below.
Regards,
Peter.
## Description:
- Apache River provides a platform for dynamic discovery and lookup
search of network services. Services may be implemented in a number
of
Hello River folk, please review / comment / suggest / changes for the
draft board report for June below.
Regards,
Peter.
## Description:
- Apache River provides a platform for dynamic discovery and lookup
search of network services. Services may be implemented in a number
of
Hello River folk, please review / comment / suggest / changes for the
draft board report for March below.
Regards,
Peter.
## Description:
- Apache River provides a platform for dynamic discovery and lookup
search of network services. Services may be implemented in a number
of
Hello River folk, please review / comment / suggest / changes for the
draft board report for November below.
Regards,
Peter.
## Description:
- Apache River provides a platform for dynamic discovery and lookup
search of network services. Services may be implemented in a number
of
Thanks Shawn,
Well spotted and sorted.
Regards,
Peter.
On 5/11/2018 6:46 AM, Shawn Ellis (JIRA) wrote:
[
https://issues.apache.org/jira/browse/RIVER-467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Ellis updated RIVER-467:
--
/apache/river/test/impl/mahalo/AdminIFShutdownTest.td
N.B. This only affects people using secure services.
Regards,
Peter.
On 18/10/2018 6:40 AM, Bryan Thompson wrote:
I've never used that aspect. Nothing to offer.
B
On Wed, Oct 17, 2018 at 3:57 AM Peter Firmstone
wrote:
LookupLocator's
LookupLocator's identity contract:
/**
* Two locators are equal if they have the same host and
* port fields. The case of the host is
ignored.
* Alternative forms of the same IPv6 addresses for the
host
* value are treated as being unequal.
*/
At some point in
Hello River Folk,
My focus in recent years has been addressing security concerns, such as
deserialization and TSLv1.2 secure endpoints, during the River project's
existance, we've only tested the TCP endpoints with the qa suite (the
majority of tests), apart from some jtreg tests that test
Hello River folk, please review / comment / suggest / changes for the
draft board report for August below.
Regards,
Peter.
## Description:
- Apache River provides a platform for dynamic discovery and lookup
search of network services. Services may be implemented in a number
of
I've been a little quiet, but have been busy testing, testing,
testing. Will get back to work on River's modular build in the near
future.
AtomicILFactory, is a JERI invocation layer factory alternative to
BasicILFactory, which uses atomic input validation during
deserialization. Unlike
Thanks Shawn,
A deceptively simple fix, must have taken time and investigation to work
out why it was getting unecessarily delayed, interesting given that it
has gone on for so long too.
Cheers,
Peter.
On 14/05/2018 5:57 AM, Shawn Ellis (JIRA) wrote:
[
Actually we can still submit up to 24 hours prior to the meeting.
Does anyone have any thoughts or anything they want to add?
Regards,
Peter.
On 12/05/2018 8:41 AM, Peter wrote:
This board report is due, however it will need to be delayed until June,
I have been aware since last month that
Have we been doing codebase annotations wrong?
Could RMIClassLoader have been better conceived?
Could a simpler alternative be utilised instead?
For example, classes are resolved differently during deserialization
than how classes are resolved at runtime. At runtime a ClassLoader
delegates
https://dzone.com/articles/tlsssl-explained-examples-of-a-tls-vulnerability-a?edition=298008_source=Daily%20Digest_medium=email_campaign=dd%202017-05-07
Sent from my Samsung device.
1 - 100 of 522 matches
Mail list logo
