As having them all live in a single PropertyReader header / source
file was getting far too big. Additionally, sue some of our aliased
types to shorted lines (sVec, sList, uPtr etc)
Now things are working for the most part, move the readers into their
own internal namespace. Also start creating an actual separation of the
interface and the implementation with some Interface classes at the
non internal level.
Currently, it's more of a blob inspector than a full-blown
implementation, but this code does have the ability to understand a Corda
serialized blob and build a set of deserialisers to handle a blob. It
does this in the same way the native java implementation works by
interrogating the types (as per the definition in the envelope) and
building recursive type readers that are able to pull the relevant
information out of the byte stream.
Lots of future work to undertake, but as a starting point its a little
bit useful with the scope it could be made much more useful with some
work.
* Start pooling classpath scanning
Quickly patch synchronisation of attachment class loader cache. Needs a revisit but more complicated due to DJVM.
Annotate away for DJVM
Take ClassGraph utils into their own file so we can exclude for DJVM
Clean up a little
* Daemonize the threads
* Seems to be some concurrency problems with use of ClassGraph. Using a mutex for now to work around.
Move Raft and BFT-Smart notaries back into node to preserve backwards compatibility.
* Allow overriding full node config when using internal mock network parameters.
* Make BFT-Smart notary start up in prod mode as well
* Move raft & bftsmart notaries to net.corda.notary.experimental package
* Make sure Raft notary handles reference state edge cases correctly.
* Make sure BFT-Smart notary handles reference state edge cases correctly.
* Include notary schemas in node internal schemas
* Undo Raft notary table schema changes to maintain compatibility.
* Split Workflow and contracts of Finance App into separate Cordapps, part 1 - content which is different between OS and ENT is still in contract Cordapp.
* Move CashSelection implementations to workflow module.
* Move CashSelection implmentations to workflow module.
* Move finance module to finance-flows, top level finance module is empty.
* Move finance module to finance-flows, top level finance module is empty.
* Updated build comment.
* Revert publication of combined (contracts and flows) corda-finance.jar (to maintain backwards compatibility with 3rd party cordapps dependent on finance)
* Added backwards compatibility clarification comment.
* Re-instate new cordapp metadata.
* Global rename of `finance-flows` to `finance-workflows` to follow adopted naming conventions.
* Addressed final review comments.
* Rename application to "Corda Finance Demo"
* Generation of original corda-finance jar from new sub-modules.
* Fixed and tested demobench with new split finance contract and workflow jars.
* Renamed finance sub-modules to contracts and workflows.
* Remove Michele!!!
* Minor fix to filtering logic.
* Align CorDapp configuration filename with workflows jar.
* Fix breaks caused by finance module naming changes.
* Final alignment between OS/ENT of finance contract code.
* Implementation of Contract and Workflow attribute identifiers.
* Fixes following rebase from master.
* Fix broken JUnit test.
* Fix broken JUnit test.
* Fix broken JUnit test.
* Added missing constants.
* Further clean-up.
* Updated documentation.
* Added changelog entry.
* Updated all samples (using new Gradle Plugin 4.0.37 functionality)
* Temporarily resolve gradle plugins from latest published snapshot.
* Temporarily resolve gradle plugins from latest published snapshot.
* Updates following feedback from PR review.
* Move constants into CordappInfo companion object.
* Contract and Workflow attribute `version` to `versionId` (as version is a reserved gradle variable)
* Clarified warning message on incorrect version identifier.
* Align version identifier processing logic with gradle cordapp plugin.
* Updated comment.
* Minor fixes following rebase from master.
* Fixed broken unit test.
* Improved exception reporting.
* Update to use 4.0.37 of Gradle Plugins.
* Added support for combined Contract and Workflow CorDapp info.
* Updated following discussions with Shams + cleanup.
* Updated following Shams PR review.
* Minor API improvements.
* Added missing cordapp info causing deployNodes to fail.
FinalityHandler is insecure in that it is open to receive any transaction from any party.
Any CorDapp targeting platform version 4 or above is required use the new c'tors which take in FlowSession objects to the counterpart flow. This flow must subcall ReceiveFinalityFlow to receive and record the finalised transaction.
Old CorDapps (with target platform version < 4) will continue to work as previously. However if there are no old CorDapps loaded then the node will disable FinalityHandler.
* Introduce public subset of config to tweak config via mock net work without exposing internal node config.
* Removal of functions exposing (internal) NodeConfiguration from the public test API
* Code review fixes
* Blank lines removed
* Documented mock network API change in upgrade notes.
* Updated documentation and API doc.
* More documentation/API doc
* Migrated all non-BFT notary implementations to use async commits.
* Mock network: await for async operation completion. When calling runNetwork()
it keeps "pumping" messages between participants until no more messages are generated.
The problem comes in when a flow suspends on an async operation: the mock network
thinks the flow finished the work for the current step, and since no more messages
are generated, completes the runNetwork() function. The message that the flow
generates once it resumes after async operation completion never gets processed.
This change makes runNetwork() wait until all flow async operations finish,
and only then check whether no more messages can be transferred.
The configuration objects for specific notary implementations have been replaced
by a single untyped "extraConfig" Config object that is left to the notary service
itself to parse.
* Remove the raft bootstrapping command from node, we'll need a different
mechanism for that.
* Remove pre-generated identity config value.
* Split up obtainIdentity() in AbstractNode to make it easier to read.
* A temporary workaround for the bootstrapper tool to support BFT notaries.
* Update docs
* Add upgrade notes
* Fix rebase issue
* Add a config diff for the bft notary as well
* ENT-2610: Separate passwords for store and for private keys in Corda OS.
When it comes to KeyStores there are *2* passwords: 1 for the keyStore as a whole and separately there is one private keys within this keyStore.
Unfortunately, those 2 passwords have to be the same due to Artemis limitation, for more details please see:
`org.apache.activemq.artemis.core.remoting.impl.ssl.SSLSupport.loadKeyManagerFactory`
where it is calling `KeyManagerFactory.init()` with store password.
Before change in this PR, throughout our codebase there are multiple places where we assume that storePassword is the same as keyPassword, even in the classes that have nothing to do with Artemis.
This is of course less than ideal as TLS communication may be used not only for Artemis connectivity (e.g. Bridge/Float interaction in Ent) and it is unfair to impose same passwords constraint on that communication channel.
Therefore this PR is removing this limitation and properly separating storePassword from keyPassword.
Linked Jira(https://r3-cev.atlassian.net/browse/ENT-2610) has for more background info.
Suggest to start review from `net.corda.core.crypto.X509NameConstraintsTest` to get an idea about the nature of the changes made.
* ENT-2610: Address PR input from @kchalkias
* ENT-2610: Address PR input from @kchalkias, s/privateKeyPassword/entryPassword/
* ENT-2610: Address PR input from @kchalkias, s/keyPassword/entryPassword/
In the implementation of `CertificateStoreSupplier`
* Upgrade gradle plugin; add target version attribute to finance and sample cordapps.
* Remove '-SNAPSHOT' from gradlePluginsVersion.
* Fix naming.
* Update docs.
* Respond to feedback.
* Fix irs demo
* Fix more samples
* Fix more samples
* Fix deployNodes
* Fix deployNodes
* more fixes
* fix simm valuation
* more fixes
* more fixes
* more fixes
* more fixes
* Publication should have *nothing* to do with cordformation and deployNodes.
Remove it! And if this exposes a bug then "so be it".
* Disable CorDapp signing for Cordapp Configuration and Network Verifier.
* Disable CorDapp signing for SIMM Valuation Demo.
* Remove remaining publishing nonsense from samples.
* Workarounds fpr cordapp-configuration, network-verifier and simm-valuation-demo:
JarSigner rejects jars with duplicates inside, so remove them.
* Upgrade to Gradle plugin 4.0.32 and reenable CorDapp signing for samples.
* Move Raft and BFT notaries into separate modules
* Move schemas
* Fix tests & demos
* Modified logic for creating notary services:
Added a new field 'className' to the notary configuration. The node now
loads the specified implementation via reflection. The default className
value points to the simple notary implementation for backwards compatibility.
Relevant schemas are loaded in a similar fashion.
For backwards compatibility purposes the default SimpleNotaryService will
remain built-in to node, but its cordapp will be generated on startup – so
the loading of notary services is streamlined.
* Move test namedcache factory to test utils
The list of CorDapps jars is no longer passed in via the cmd line but is now expected to be placed in the bootstrapped directory.
Ended up being a bit of a refactor to cater for unit testing, and also tidied up the bootstrapper docs.
As reported in [CORDA-1609](https://r3-cev.atlassian.net/browse/CORDA-1609),
`CordaRPCClientConfiguration.default` is not accessible from Java since
`default` is a reserved keyword.
As part of the refactor made in #2831, `CordaRPCClientConfiguration` went
from being a data class to an interface with a backing implementation of
type `CordaRPCClientConfigurationImpl`.
This resulted in Java users having to rewrite code that was on the form:
```java
final CordaRPCClient client = new CordaRPCClient(
nodeAddress, CordaRPCClientConfiguration.DEFAULT
);
```
to something like this:
```java
final CordaRPCClient client = new CordaRPCClient(
nodeAddress, CordaRPCClientConfiguration.Companion.default()
);
```
However, this does not work. The user would get a compilation error because
`default` is a reserved keyword in Java.
Since `CordaRPCClientConfiguration` has been made an interface, there is no
easy way of introducing a static final field on the interface from Kotlin.
Consequently, I've changed this back to using a `class` with a static field
named `DEFAULT` instead of the static method `default()`.
It should be noted that `default()` / `DEFAULT` is currently only used
internally to pass in default values in `CordaRPCClient.kt` and
`CordaRPCClientUtils.kt`. That said, it is exposed as part of our API
surface and consequently shouldn't be broken.
The latter means that in the above example, the user would actually not
have to provide the parameter at all:
```java
final CordaRPCClient client = new CordaRPCClient(nodeAddress);
```
As can be seen from the definition of `CordaRPCClient`:
```kotlin
class CordaRPCClient private constructor(...) {
@JvmOverloads
constructor(
hostAndPort: NetworkHostAndPort,
configuration: CordaRPCClientConfiguration = CordaRPCClientConfiguration.DEFAULT
) : this(hostAndPort, configuration, null)
```
The mentioned [refactor](7a077e76f0 (diff-0948c125db93a22263eb81eaf3161c17R65))
did not make it into the 3.1 release, so from an API-stability perspective,
this change can be applied without affecting our commitment to a
backwards compatible API..
