PROTON-1224: Upgrade BouncyCastle #75
Conversation
| @@ -99,7 +99,7 @@ mvn test \ | |||
| <dependency> | |||
| <groupId>org.bouncycastle</groupId> | |||
| <artifactId>bcpkix-jdk15on</artifactId> | |||
| <version>1.47</version> | |||
| <version>1.48</version> | |||
There was a problem hiding this comment.
Given the idea is to update it probably makes sense to go for the latest version rather than this 3+ year old version (same goes for the other instance).
|
I still need to have a final look, but if you could address the couple niggles I commented on that would be good. As I mentioned before, if you could also please remove merge commits from PRs that would be good, you have added a second in this version. Feel free to rebase the PR and squash all the commits, you don't need to open a new PR. |
|
Robbie - thanks for reviewing and sorry for the slow response, i'll look to try and resolve these today. As previously discussed i'm not an enormous fan of this reflective approach but the cmake build process for java floored me a bit w.r.t how to achieve the maven style dependency at compile time. |
|
OK ... my lack of high-wire skills with GIT is really showing through now ... i'm completely stumped as to how to 'not' include other commits when pushing back to my fork .. I've tried squashing but always end up with merge conflicts with the Fork This is why they don't typically let architects edit code ;-) |
The test was comparing exact error message text, changed by previous fix to include the transport error. Modified to check for a reliable substring.
container::schedule() with simple example of sending messages at a fixed interval. Examples for C++03 and C++11. Modified inject() to use the same proton::void_function0 as schedule for C++03. Note: the example chains schedule() calls at a fixed interval. A precise fixed-frequency sender should take account of the actual time to correct for variations.
- Make all member functions in container class pure virtual (except destructor) - Add a new standard_container class that has the standard behaviour of the variant overloads - Make all container implementations use standard_container class - Remove unnecessary includes of container_impl
…is bound Previously the reactor would be put on the transport's attachment list when a socket selector was created for the transport. If the socket setup fails then no selector is created and the reactor is never added to the transport. This would result in a crash as the code depends on the reactor being present in the transport when transport events are generated.
|
i think this is royally screwed up now, the file-change list looks clean but using a rebase rather than a pull (to remove the merge commits) now appears to be having an even worse affect. I'm open to suggestions - i can close this PR, trash my fork, and then re-create the change if that's going to be a simpler path forward but before that i would like to better understand the fork/pull/commit/push/PR cycle when there may be multiple commits to the fork before the PR is actually raised. Squashing after commits have been pushed seems to just open world of hurt |
|
you just need to ensure you have the upstream repo up to date, then rebase your fork against it, then [force] push to your fork, which should result in your commit(s) sitting at the head of the branch with the current upstream commits preceding them and no unnecessary merge commits. You can repeat that process as many times as you like. You obviously want to avoid force pushes on branches you are using to directly collaborate with other people on, but typically you commit work on a specific branch for the PR and then since noone else is likely to be depending on it doing such a force push is of little consequence to anyone. |
|
I would like to close this PR and open a new one with (hopefully) a much cleaner change delta ... |
|
Closing for re-creation |
Support 1.48+ of BouncyCastle
Added unit-test and associated certificate and key test resources.