Hi Zsolt,
See inline below...
On 7/01/2017 10:16 PM, Zsolt Kúti wrote:
Hi Peter,
I remember some of your mails having summarized developments for 3.0.0. I
have been browsing the mailing list for an hour now, but I am yet to find
any of them.
Do you have one of those by any chance?
I am aware of the followings:
RIVER-431: Java Memory Model Compliance
https://issues.apache.org/jira/browse/RIVER-431
RIVER-420: Export during construction
https://issues.apache.org/jira/browse/RIVER-420
RIVER-418: Service server implementations start threads before construction
is complete allow "this" to escape
https://issues.apache.org/jira/browse/RIVER-418
Java 9 compliant
Not yet, the Java 9 changes aren't included in the River 3.0 release,
although the jsk-policy.jar doesn't need to be in the extension
ClassLoader like earlier releases. Java 9 doesn't allow extensions.
permission tool?
http://mail-archives.apache.org/mod_mbox/river-dev/201604.mbox/%3c5704fd9d.2030...@zeus.net.au%3e
The security policy file generation tool was created in response to
requests to develop tools to make configuring River security easier,
however it was rejected by a committer citing security concerns. The
tool grants AllPermission, while it determines required permissions and
writes them to a policy file.
The original intent was to advise the djinn network be air gapped, or
use a test network environment, while using the tool to establish /
generate security policy files, once the policy files are generated,
have been reviewed and are in force, the network could be connected to
outside networks.
It's possible that the tool could be modified to use an interactive GUI,
where an administrator can "ok" new permissions as they are requested,
however doing so would be complex:
* A number of jvm's may be generating their policy files at the same
time, they may or may not be headless, which may require a remote
service, in order to communicate with an administrator
interactively, which creates other security problems.
* During a SecurityManager.checkPermission call, it's important to
avoid recursive calls where additional permission checks are
required in order to interact with an administrator using a
service / GUI.
It's something we could look into again.
Has this patch been revoked?
http://mail-archives.apache.org/mod_mbox/river-dev/201604.mbox/%3c570cccaa.5090...@zeus.net.au%3e
No, this patch is included.
Cheers,
Zsolt
Release Notes - River 3.0.0
Sub-task
Release Notes - River - Version River_3.0.0
Sub-task
* [RIVER-319 <https://issues.apache.org/jira/browse/RIVER-319>] -
Change River Build Dist structure to support jtreg test automation
* [RIVER-344 <https://issues.apache.org/jira/browse/RIVER-344>] -
com.sun.jini.thread.TaskManager scalability and concurrency.
Bug
* [RIVER-19 <https://issues.apache.org/jira/browse/RIVER-19>] -
PreferredClassLoader doesn't implement preferred semantics for
getResources(String)
* [RIVER-113 <https://issues.apache.org/jira/browse/RIVER-113>] -
JoinManager synchronization on each proxyReg should be reviewed,
doc'd and fixed where appropriate
* [RIVER-145 <https://issues.apache.org/jira/browse/RIVER-145>] -
JoinManager synchronization on serviceItem should be reviewed,
doc'd and fixed where appropriate
* [RIVER-148 <https://issues.apache.org/jira/browse/RIVER-148>] -
JoinManager.ProxyReg.fail synchronization may be wrong or may be
able to simplify it
* [RIVER-265 <https://issues.apache.org/jira/browse/RIVER-265>] -
PreferredClassProvider performs 'unlucky' caching
* [RIVER-282 <https://issues.apache.org/jira/browse/RIVER-282>] -
Suspect exception cast
* [RIVER-335 <https://issues.apache.org/jira/browse/RIVER-335>] -
com.sun.jini.phoenix.ConstrainableAID missing from phoenix.jar
* [RIVER-337 <https://issues.apache.org/jira/browse/RIVER-337>] -
Attempted discard of unknown registrar kills
LookupLocatorDiscovery thread
* [RIVER-345 <https://issues.apache.org/jira/browse/RIVER-345>] -
SDM LookupCache multi-LUS stale proxy/discard problems
* [RIVER-348 <https://issues.apache.org/jira/browse/RIVER-348>] -
Possible race condition in net.jini.lookup.ServiceDiscoveryManager
addProxyReg
* [RIVER-367 <https://issues.apache.org/jira/browse/RIVER-367>] -
com.sun.jini.mahalo.TxnManagerImpl fails to abort a Transaction
when notified of its lease expiration.
* [RIVER-387 <https://issues.apache.org/jira/browse/RIVER-387>] -
KerberosServerEndpoint calls com.sun.security methods,
animal-sniffer warns
* [RIVER-395 <https://issues.apache.org/jira/browse/RIVER-395>] -
Ill-behaved DiscoveryListener can terminate discovery notifier
threads
* [RIVER-402 <https://issues.apache.org/jira/browse/RIVER-402>] -
NullPointerException in LookupCacheImpl.notifyServiceMap
* [RIVER-418 <https://issues.apache.org/jira/browse/RIVER-418>] -
Service server implementations start threads before construction
is complete allow "this" to escape
* [RIVER-420 <https://issues.apache.org/jira/browse/RIVER-420>] -
Export during construction.
* [RIVER-422 <https://issues.apache.org/jira/browse/RIVER-422>] -
Missing reference-collections and high-scale-lib in Manifest for
jsk-platform
* [RIVER-431 <https://issues.apache.org/jira/browse/RIVER-431>] -
Java Memory Model Compliance
* [RIVER-433 <https://issues.apache.org/jira/browse/RIVER-433>] -
Test suite freeze while testing service discovery category
Improvement
* [RIVER-26 <https://issues.apache.org/jira/browse/RIVER-26>] - Make
UmbrellaGrantPermission work with DynamicPolicy
* [RIVER-107 <https://issues.apache.org/jira/browse/RIVER-107>] -
DynamicPolicyProvider could use finer grained locking
* [RIVER-123 <https://issues.apache.org/jira/browse/RIVER-123>] -
ConfigurationFile should support arithmetic operations
* [RIVER-140 <https://issues.apache.org/jira/browse/RIVER-140>] -
JoinManager synchronization strategy should be reviewed,
documented, and fixed where appropriate
* [RIVER-193 <https://issues.apache.org/jira/browse/RIVER-193>] -
support declaring entries in a "common" configuration source for
use in other configuration sources
* [RIVER-249 <https://issues.apache.org/jira/browse/RIVER-249>] -
DynamicPolicy providers do not support UmbrellaGrantPermission
* [RIVER-274 <https://issues.apache.org/jira/browse/RIVER-274>] -
Improve logging of diagnostic messages in ServiceDiscoveryManager
* [RIVER-343 <https://issues.apache.org/jira/browse/RIVER-343>] -
Private class extends java.lang.Thread, causing synchronization
bottleneck.
* [RIVER-386 <https://issues.apache.org/jira/browse/RIVER-386>] -
Refactor of FastList inside of Outrigger
* [RIVER-401 <https://issues.apache.org/jira/browse/RIVER-401>] -
PreferredClassProvider using URL as key in map
* [RIVER-412 <https://issues.apache.org/jira/browse/RIVER-412>] -
rename com.sun.jini packages to org.apache.river.impl
* [RIVER-439 <https://issues.apache.org/jira/browse/RIVER-439>] -
River only builds on Sun's JVM, add support for other JVM's
New Feature
* [RIVER-313 <https://issues.apache.org/jira/browse/RIVER-313>] -
Provide mechanism to swap in alternatives to Java DSL for service
configuration
* [RIVER-340 <https://issues.apache.org/jira/browse/RIVER-340>] -
Additional Dynamic Grants and Revokeable Permissions
Question
* [RIVER-365 <https://issues.apache.org/jira/browse/RIVER-365>] -
main build.xml contains remarks about deprecated (and to be
removed) targets, needs clarification
TCK Challenge
* [RIVER-419 <https://issues.apache.org/jira/browse/RIVER-419>] -
ServiceDiscoveryManager lookup qa TCK tests need to be reviewed
Task
* [RIVER-261 <https://issues.apache.org/jira/browse/RIVER-261>] -
update com.sun.* namespace to org.apache.river.*
Test
* [RIVER-304 <https://issues.apache.org/jira/browse/RIVER-304>] -
Reactivate River jtreg tests
On Thu, Jan 5, 2017 at 11:58 PM, Peter<j...@zeus.net.au> wrote:
BTW I'm happy for you to announce 3.0 on the new website.
Cheers,
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: Peter<j...@zeus.net.au>
Sent: 06/01/2017 07:35:52 am
To: dev@river.apache.org<dev@river.apache.org>
Subject: Re: about 3.0 artifacts and announcement
Hi Zsolt,
The release process looks up to date, it doesn't contain
any detail on publishing jars to Maven, as a binary build
isn't currently implemented. Due to a bug in ClassDep that
causes class files to be omitted from jars on occassion, we must run the
full test suite to validate the build. I also have
Apache jar signer certs for signing release jars.
As you're probably aware I'm working on / experimenting
with a Maven build on git. I'm finding the build process
on Maven much simpler, modularity should lower the
bar for new developers as it clearly demarcates components,
allowing them to focus on one component. With the
recent discussion surrounding OSGi, I'm also creating
bundles to allow us to explore the use of OSGi to
manage the modules at runtime. Merging& donating this
work back to River can occur as soon as River is tranisitioned to git
Cheers,
Peter.
Sent from my Samsung device.
Include original message
---- Original message ----
From: Zsolt Kúti<la.ti...@gmail.com>
Sent: 06/01/2017 06:51:07 am
To: dev@river.apache.org
Subject: about 3.0 artifacts and announcement
Hi,
Can somebody tell if our release process documentation is up-to date:
http://river.apache.org/dev-doc/building-a-release.html
As to the release, the last mail was:
http://mail-archives.apache.org/mod_mbox/river-dev/201610.
mbox/%3cCAK_o9cH7JPsfd_CK4-pOGb3nswH4R8jB1Kh6=
UTWF2c0Ge9V=w...@mail.gmail.com%3e
The 3.0.0 release artifacts (no binary) are available from here:
http://www.apache.org/dyn/closer.cgi/river/
So nothing is against a release announcement on our website, isn't it?
If nobody else is willing to, I can take a look into how to
add our jars to
maven repo,.
Cheers,
Zsolt
