Hit the api

In this exercise, according to the requirements described here I have added the following features.

Added functions for creating a game, adding scores and getting all scores from the API
Used Arrow functions to implement the functionalities.
Added functionality for the refresh button.
Used async/await for functions implementation.

Hi @BahirHakimy
Great work on making the changes requested by a previous reviewer 👏 You've done well implementing some of the requested changes, but there are still some which aren't addressed yet.
Highlights

Linter set up well and checks pass 🟢
Git flow followed 👌
.gitignore used to ignore requested files 📁
Commit messages are meaningful and written in imperative tense 📝
PR description is descriptive 📝

Required Changes ♻

Since there is no change on utils.js file I can't pick the lines, as the previous reviewer requested, kindly make sure you use es6 arrow functions for all of your functions 👍

Check the comments under the review.
Optional suggestions
Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear. Please, remember to tag me in your question so I can receive the notification.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.
As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

Hi @BahirHakimy
Great work on making the changes requested by a previous reviewer 👏 You've done well implementing some of the requested changes, but there are still some which aren't addressed yet.
Highlights

Linter set up well and checks pass 🟢
Git flow followed 👌
.gitignore used to ignore requested files 📁
Commit messages are meaningful and written in imperative tense 📝
PR description is descriptive 📝

Required Changes ♻

Since there is no change on utils.js file I can't pick the lines, as the previous reviewer requested, kindly make sure you use es6 arrow functions for all of your functions 👍

Check the comments under the review.
Optional suggestions
Every comment with the [OPTIONAL] prefix won't stop the approval of this PR. However, I strongly recommend you to take them into account as they can make your code better. Some of them were simply missed by the previous reviewer and addressing them will really improve your application.
Cheers and Happy coding!👏👏👏
Feel free to leave any questions or comments in the PR thread if something is not 100% clear. Please, remember to tag me in your question so I can receive the notification.
Please, do not open a new Pull Request for re-reviews. You should use the same Pull Request submitted for the first review, either valid or invalid unless it is requested otherwise.
As described in the Code reviews limits policy you have a limited number of reviews per project (check the exact number in your Dashboard). If you think that the code review was not fair, you can request a second opinion using this form.

Hi @HAMMAS-SALEEM,
Thanks for your kind reviews, but that file contains utility functions and it's not part of the main application code, so I think I am free on deciding how kind of functions would I use on that. I already noticed that as the previous reviewer suggested, but that is not part main application functionalities and it doesn't make a difference whether I use arrow functions or regular functions

Hi @huseyinbiyik, Thanks for your kind reviews, but that file contains utility functions and it's not part of the main application code, so I think I am free on deciding how kind of functions would I use on that. I already noticed that as the previous reviewer suggested, but that is not part of the main application functionalities and it doesn't make a difference whether I use arrow functions or regular functions for that

I will also face some Linters issues when refactoring to arrow function


Android Studio 3.0 support  kotlin  And Butterknife also support

Android Studio 3.0 support  kotlin  And Butterknife also support
i think  it  cause this promble
Error:Unable to find method 'com.android.build.gradle.internal.variant.BaseVariantData.getOutputs()Ljava/util/List

Use 9.0.0-SNAPSHOT for now.


TFRS - administrative adjustment transaction types for Historical Data Entry

Title: Administrative adjustment transaction types for Historical Data Entry
Description:

Add a new transaction type(s) to the Historical Data Entry
Label is Administrative adjustment
Uses compliance units, so can be positive or negative adjustment
Can consider having two transaction types, one for positive and one for negative, if that is simpler to implement.
Includes creating a new view page(s) for the transaction (one for positive & one for negative).
Transaction will impact available credit balance calculations, based on the transaction's effective date. This follows similar logic to Part 3 Awards and Credit Transfers, where transactions within a particular compliance period impacts the available credit balance for that period but also if it has an effective date in the first 3 months of the following compliance period (Jan 1 to Mar 31, YYYY+1) it also impacts the available credit balance for the previous period. This is the 3 months after the period has ended but before the Mar 31 reporting deadline. For example, a transaction with an effective date of February 15, 2024 will impact the available credit balance for the 2023 compliance period.

Wireframe:
Historical Data Entry:
View page, positive adjustment:

View page, negative adjustment:

Purpose and benefit to user:
Enables Ministry staff to make administrative adjustments to a supplier's compliance unit balance in the event that there is an error in issuing credits.
Acceptance Criteria:

[ ] Given I am an IDIR user, when I am using the Historical Data Entry feature, then there is a transaction type(s) called "administrative adjustment" that allows me to create an adjustment transaction that increases or decreases an organization's compliance unit balance.

Development Checklist:

[ ] A
[ ] B
[ ] C

Notes:
We still need to keep the "Validation" and "Reduction" transaction types using the credit/debit system as these labels may be used for supplemental reporting for 2022 and prior.

Hey team! Please add your planning poker estimate with Zenhub @AlexZorkin @tim738745

Hey team! Please add your planning poker estimate with Zenhub @jig-patel @prv-proton

There is a followup ticket created that will handle the merge of the delayed effective_date of credits to an organization.
https://app.zenhub.com/workspaces/team-zelda-637d5bc12e6201001055b745/issues/gh/bcgov/tfrs/2538
This ticket will need to be completed after the next production release and merge to master.


Tetra Duplication Glitch

Using the Tetra mod and clicking scroll wheel throws almost every item in my inventory into the Tetra workbench and if I click the scroll wheel again it will duplicate any item that was added into the workbench.
Ex: 1 sword, 1 pickaxe, 1 axe, 1 bow, 37 diamonds, 6 iron blocks, 3 stacks of birch planks, 64 torches, 64 steak, 1 crafting table, and 3 potions of regeneration. Clicking Scroll wheel will send almost all the items into the workbench and clicking it again will make the workbench spit out the items as if duplicating and if I break the workbench I would get as a result: 1 sword, 2 pickaxes, 1 axe, 1 bow, 72 diamonds, 12 iron blocks, 6 stacks of birch planks, 2 stacks of torches, 2 stacks of steak, 2 crafting tables, and 3 potions of regeneration.
Minimal setup needed to reproduce
Forge version: 34.1.41
Tetra version: 3.3.1
Inventory Tweaks Renewed Version: 1.16.2 - 1.0.0
Steps to reproduce

Have Tetra
Click scroll wheel inside Tetra workbench
Most items will be transferred into Tetra workbench
Click scroll wheel again
Duplicate items will pop out of the top of the Tetra workbench
Break Tetra workbench to get items that were transferred inside

This can be fixed by inserting this in the invtweaks config:
[[sorting.containerOverrides]]
	containerClass = "se.mickelus.tetra.blocks.workbench.WorkbenchContainer"
	sortRange = ""

This seems to be an issue you should bring up to Tetra, it's not really fixable unless with a config like above.


Handle 404 error when querying validators

While testing on Kiln, querying the latest slot via Lodestar API returned 404 and staker notifier does not currently handle this and crashes.
Need to investigate whether missing slot is a valid scenario, or whether it was just a timing issue and could be handled with a retry.

Fixed in #15


Improve configuration loading/saving

summary of the changes made here:

each config instance holds a reference to it's parent, except global which doesn't have one
when a config instance is loaded, first, the values from the file are loaded. they are then merged with settings taken from the parent node. The configs own settings take priority
When saving a config, settings are excluded from the file if they're also set to the parent config, and are associated with the same value.

Obtaining a working build requires this branch https://github.com/SpongePowered/configurate/tree/feature/walk of configurate installed in your local Maven repo - pending the merge of https://github.com/SpongePowered/configurate/pull/103
Even once that is merged, we'll still most likely have to keep shading our own copy of configurate - until the newer versions begin to be shaded into Sponge jars

@lucko Mind updating PR for latest sponge configurate changes? Thanks!

Yep, all done :)
Also included the fix for merging list values


Mangles dead links

For example, in https://en.wikipedia.org/w/index.php?title=Deep_Sehgal&diff=prev&oldid=1068084640, it changes the BAFTA citation from a dead bare URL that redirects to the homepage to a filled in citation for the homepage of the site. A better solution would be to tag the link as dead in cases like that, since citing the homepage is rarely intended.

While a diff is useful in reports (thanks) the first thing that has to be done in triage is to extract just the problematic URL and run that through reFill on its own, i.e.
http://www.bafta.org/wales/awards/2011-bafta-cymru-awards,1770,BA.html
is processed by reFill to:
{{Cite web|url=https://www.bafta.org/|title=BAFTA Home Page|date=22 May 2014|website=www.bafta.org}}
Looking at the HTTP response, Cloudflare first returns a 302 (Found) to redirect from http to https, followed by a 301 (Moved Permanently) redirecting to https://www.bafta.org.
The request for https://www.bafta.org returns a 200.
How would you envisage detecting that the requested page is actually gone as it does not return a 4xx? The response from the server could just be (should just be) taking the user to the page's new location.

The CheckIfDead library used by InternetArchiveBot includes code to check for the specific case of redirecting to the domain root (https://github.com/wikimedia/DeadlinkChecker/blob/8841c56c7c5a1cff82f135e1731d84f36d5e001f/src/CheckIfDead.php#L662). ReFill could do something similar as well, but that wouldn't catch all cases of this.
Another idea to avoid this would be to not follow redirects that point to a URL more than X characters shorter than the original URL (leaving the original URL in the template). This would mean that it would still produce a garbage title, but at least it would leave the original URL alone so a human could fix the problem without having to dig through the page history, and in cases where the URL isn't dead would do no harm.
I wrote a Python script to find recent ReFill edits that removed more than 5 bytes of URL (total). It produced:

https://en.wikipedia.org/w/index.php?diff=1070858909 (fine)
https://en.wikipedia.org/w/index.php?diff=1070844795 (another example of this issue)
https://en.wikipedia.org/w/index.php?diff=1070843885 (fine, the URL being shortened is https://www.milb.com/palm-beach/news/luken-baker-wins-florida-state-league-player-of-the-month/c-310534082)
https://en.wikipedia.org/w/index.php?diff=1070832629 (example of this issue where the redirect is to a different domain)
https://en.wikipedia.org/w/index.php?diff=1070826363 (example of this issue where the redirect isn't to the root)
https://en.wikipedia.org/w/index.php?diff=1070821043 (fine)

Code for that script and more results at https://public.paws.wmcloud.org/User:Pppery/ReFill.ipynb


HDDS-3341. Checkstyle fails for new modules/versions

What changes were proposed in this pull request?
Make checkstyle.sh work with new modules/versions:

first attempt to run the check only
if it fails due to anything other than style violation, try to compile sources, too.

Ignore violations on Protobuf generated sources.
Output from the first attempt is only printed with some delay only if and when it completes successfully, to avoid duplicate Maven logs.  This may be a bit annoying when run manually.  Please let me know if duplicated but immediate output is preferred.
https://issues.apache.org/jira/browse/HDDS-3341
How was this patch tested?

Tested on HDDS-3312, which introduces a new hadoop-hdds-hadoop-dependency-client module and fails with Could not find artifact org.apache.hadoop:hadoop-hdds-hadoop-dependency-client:jar:0.6.0-SNAPSHOT in apache.snapshots.https.  With this change the check passes:

$ hadoop-ozone/dev-support/checks/checkstyle.sh
...
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  02:55 min
...
$ echo $?
0

Tested on master, where all modules are available, so no compilation is needed:

$ hadoop-ozone/dev-support/checks/checkstyle.sh
...
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  14.093 s
...
$ echo $?
0

Introduced an unused import, verified that violation is reported:

$ hadoop-ozone/dev-support/checks/checkstyle.sh
...
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  6.226 s
...
hadoop-ozone/common/src/main/java/org/apache/hadoop/hdds/protocol/StorageType.java
 20: Unused import - java.util.List.
$ echo $?
1

https://github.com/adoroszlai/hadoop-ozone/runs/558999926

Thanks @dineshchitlangia for reviewing and merging this.

Good trick.
The related problem is that our daily build is failing on the apache jenkins (which did the deploy) and our github daily build doesn't have permission to upload to the apache snapshot repository. We might need to ask INFRA to set a secret to make it possible to deploy. (Which would make the original problem more rare)


Add methods to perform batch gets/deletes/updates of blobs

To simplify some common use cases of batch requests we could add to Blob class some static methods to do batch gets/deletes/updates:
Blob.get(storage, blobInfo1, blobInfo2, ...)
Blob.update(storage, blobInfo1, blobInfo2, ...)
Blob.delete(storage, blob1Info, blob2Info, ...)

We could also consider putting these methods in a dedicated Blobs class, what do you think?

+1 for static Blob and Bucket operations.
Another option would be to move (or also add) these bulk operations to storage (e.g. storage.get(blobInfo...) which returns blobInfo).

I like having them in Blob. Event though they take BlobInfo parameters they can return Iterable<Blob> (or Iterable<Boolean> for delete).
What about adding them both to storage with the signature you propose and to Blob returning Iterable<Blob> instead? (I know you don't like multiple ways of doing the same thing but forgive me:)

SGTM.

I was wondering whether we should return Iterable<BlobInfo> where a null item means failed request (or not found) or Iterable<BatchResponse.Result<BlobInfo>> that contains more information on the error. Thoughts?
If we decide to go with Iterable<BatchResponse.Result<BlobInfo>> we need to figure out what to do with the methods in functional Blob as BatchResponse.Result accepts only Serializable types.

Let me also add to this that for storage.delete(blobInfo...) we need to return an Iterable<Boolean> where null makes a lot less sense.
Also, naming the method storage.update(blobInfo...) causes ambiguity with storage.update(blobInfo, option...), I suggest we call these methods getAll, updateAll and deleteAll.

I don't have a strong opinion about it.
Because this is mostly a syntactic sugar for a simplified use-case of Batch with a single operation and without blob options I would slightly prefer to go with a simple response Iterable<BlobInfo>' with null`
when an item failed. Because this request does not include options I think the only reason for such
a failure would be HTTP_NOT_FOUND (triggered by NoSuchKey or AccessDenied) and if so that
would be consistent with the single-blob get.
@BrandonY  can you confirm that?

Let me also add to this that for storage.delete(blobInfo...) we need to return an Iterable where null makes a lot less sense.

Again, we can simplify here and make this method always return True (deleted) or False (not deleted for what ever reason).

Also, naming the method storage.update(blobInfo...) causes ambiguity with storage.update(blobInfo, option...)

The way we dealt with that before is by using this signature: storage.delete(blobInfo, blobInfo...)

Another thing to consider is if we should return an Iterable or Iterator.
The benefit of the latter would be that it could allow use to chunk the input into multiple lazy batch requests.

I prefer keeping this simple as well!

The way we dealt with that before is by using this signature: storage.delete(blobInfo, blobInfo...)

I thought adding All might have been a more meaningful name but if you used this elsewhere we better stick to the delete, update, get naming.
Is there any reason you to prefer Iterable over List for this specific api?

Is there any reason you to prefer Iterable over List for this specific api?

Theoretically we could even make Iterator return a lazy Iterator.

Yes but for batch requests there's no support for pagination, right? Are we going to use lazy iterators for this?
I'm asking because using List might be friendlier.

Yes but for batch requests there's no support for pagination, right? Are we going to use lazy iterators for this?

Right, that is what I was suggesting. lets say a user requests 100 blobs and we define max batch size is 50 than we could get it in 2 sequential batches.

I'm asking because using List might be friendlier.
Yes, I agree. for a return type this would typically be better.
I am fine either way. Your call.

Just some more thoughts.

Right, that is what I was suggesting. lets say a user requests 100 blobs and we define max batch size is 50 than we could get it in 2 sequential batches.

If we ever want to, I think we could do this using a List as well. We can support get(i) and listIterator by using the input array of BlobInfo as a reference while all operation that modify the list throw UnsupportedOperationException.

If we ever want to, I think we could do this using a List as well. We can support get(i) and listIterator by using the input array of BlobInfo as a reference while all operation that modify the list throw UnsupportedOperationException.

Yes, we could document the return type as immutable list where all the operation that tries to
modify it throws UnsupportedOperationException.
I think the problem is that there are more side-effects such as list.size() which is typically a quick
operation can block for a long time.
Regardless, I actually think that it is more important to support a large input (which may exceed the
batch limitation) than dealing with a large result set. Therefore, a list could be just fine and we could
potentially chunk the request to multiple batches and populate the list one by one before we return it.

Closed with #233


[Engine][Task] Add cancel Task

Add task cancel and modify the test code
Purpose of this pull request

Check list

[x] Code changed are covered with tests, or it does not need tests for reason:
[x] If any new Jar binary package adding in your PR, please add License Notice according
New License Guide
[x] If necessary, please update the documentation to describe the new feature. https://github.com/apache/incubator-seatunnel/tree/dev/docs

@Hisoka-X PTAL Thanks


Capacity Pool - storage replication

Please clarify how the underlying data / storage is protected in an Azure NetApp Files Capacity Pool.
For example, in a normal Azure storage account, you might have LRS (3 copies in the same data center) or ZRS (copies distributed between different data centres in the same Azure region).
In ANF terms, how many copies of the data are there, or is it possible to state the expected durability (again, to compare with Azure storage accounts, LRS has a durability of 11 nines)?
Also, please clarify if ANF is protected against loss of a single datacenter in an Azure Region (i.e. comparable with ZRS) or is the resilience comparable with LRS only (i.e. all storage is held in a single data center within the Azure region)?
Thanks
Si

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: ae600625-2712-9d01-488c-5e971563cb91
Version Independent ID: 0103077a-efad-2140-7927-77c5b6cc1c47
Content: Storage hierarchy of Azure NetApp Files
Content Source: articles/azure-netapp-files/azure-netapp-files-understand-storage-hierarchy.md
Service: azure-netapp-files
GitHub Login: @b-hchen
Microsoft Alias: anfdocs

si-chan - Thanks for the questions. We'll consult the content stakeholders and get back to you.

Thanks for the feedback! I have assigned the issue to the content author to investigate further and update the document as appropriate.

@si-chan -
In discussion with our product team, we don’t currently plan to include the requested information in the public documentation.  If you are a Microsoft or NetApp internal team member and would like to continue this discussion, feel free to connect via email<EMAIL_ADDRESS>or<EMAIL_ADDRESS> Thanks.
#please-close


Explicit termination method 'end' not called

Originates from int statusCode = urlConnection.getResponseCode();.
(line numbers from Dispatcher are not accurate in the stacktrace)
E/StrictMode: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
java.lang.Throwable: Explicit termination method 'end' not called
    at dalvik.system.CloseGuard.open(CloseGuard.java:180)
    at java.util.zip.Inflater.<init>(Inflater.java:104)
    at com.android.okhttp.okio.GzipSource.<init>(GzipSource.java:62)
    at com.android.okhttp.internal.http.HttpEngine.unzip(HttpEngine.java:645)
    at com.android.okhttp.internal.http.HttpEngine.readResponse(HttpEngine.java:821)
    at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:463)
    at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponse(HttpURLConnectionImpl.java:405)
    at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getResponseCode(HttpURLConnectionImpl.java:521)
    at org.piwik.sdk.dispatcher.Dispatcher.dispatch(Dispatcher.java:250)
    at org.piwik.sdk.dispatcher.Dispatcher$1.run(Dispatcher.java:169)
    at java.lang.Thread.run(Thread.java:761)

Only visible with:
        StrictMode.setVmPolicy(new StrictMode.VmPolicy.Builder()
                .detectAll()
                .penaltyLog()
                .build());

First thought internal Android bug, but the same happens when using okhttp:3.6.0. Google fu shows lots of other reports, but no clear cut solution.
Not really sure if this even is an issue, lets note this here for now.

I also seem to get it on BufferedWriter writer = new BufferedWriter(new OutputStreamWriter(urlConnection.getOutputStream(), "UTF-8"));
E/StrictMode: A resource was acquired at attached stack trace but never released. See java.io.Closeable for information on avoiding resource leaks.
java.lang.Throwable: Explicit termination method 'close' not called
    at dalvik.system.CloseGuard.open(CloseGuard.java:180)
    at com.android.org.conscrypt.Platform.closeGuardOpen(Platform.java:282)
    at com.android.org.conscrypt.OpenSSLSocketImpl.startHandshake(OpenSSLSocketImpl.java:316)
    at com.android.okhttp.Connection.connectTls(Connection.java:235)
    at com.android.okhttp.Connection.connectSocket(Connection.java:199)
    at com.android.okhttp.Connection.connect(Connection.java:172)
    at com.android.okhttp.Connection.connectAndSetOwner(Connection.java:367)
    at com.android.okhttp.OkHttpClient$1.connectAndSetOwner(OkHttpClient.java:130)
    at com.android.okhttp.internal.http.HttpEngine.connect(HttpEngine.java:329)
    at com.android.okhttp.internal.http.HttpEngine.sendRequest(HttpEngine.java:246)
    at com.android.okhttp.internal.huc.HttpURLConnectionImpl.execute(HttpURLConnectionImpl.java:457)
    at com.android.okhttp.internal.huc.HttpURLConnectionImpl.connect(HttpURLConnectionImpl.java:126)
    at com.android.okhttp.internal.huc.HttpURLConnectionImpl.getOutputStream(HttpURLConnectionImpl.java:257)
    at com.android.okhttp.internal.huc.DelegatingHttpsURLConnection.getOutputStream(DelegatingHttpsURLConnection.java:218)
    at com.android.okhttp.internal.huc.HttpsURLConnectionImpl.getOutputStream(HttpsURLConnectionImpl.java)
    at org.piwik.sdk.dispatcher.Dispatcher.dispatch(Dispatcher.java:210)
    at org.piwik.sdk.dispatcher.Dispatcher$1.run(Dispatcher.java:159)
    at java.lang.Thread.run(Thread.java:761)

@aegis123 always? or randomly? What Android version?

Im running 7.1.1 on a nexus 5x and it seems randomly.

Seeing it too on 7.1.1, just on 7+.
I just noticed that we should close the stream in a finally, depending on where an exception happens we might not close it. From my logs though, there was no exception before this strictmode warning, so I don't think this is the issue.

HttpURLConnection.getResponseCode() opens another stream which we didn't close and if an exception happens, we didn't close the gzip stream either.
So this should now be fixed.


chore: release 1.1.5

:robot: I have created a release *beep* *boop*
1.1.5 (2022-11-24)
更新更多功能

test (524096d)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/Galaxy-Wish-Star/E-commerce/releases/tag/v1.1.5 :sunflower:


Plus layer rotate out of button when using delegate to change button color

Was trying to change the button color when the button is in open/close stage. I implement the two delegate methods like so:
func floatyWillOpen(_ floaty: Floaty) {
        floaty.buttonColor = UIColor.init(red: 217, green: 217, blue: 217)
        floaty.setNeedsDisplay()
}

func floatyWillClose(_ floaty: Floaty) {
        floaty.buttonColor = UIColor.init(red: 0, green: 101, blue: 100)
        floaty.setNeedsDisplay()
}

When clicking the button, the color did changed, but the "plus" was rotated out of the frame

Any solution for this?

Hi,
I have the same issue, Any ideas ?

I ended up using two custom images (plus and cross) to replace the plus sign, and change the image in the delegate methods. The rotation animation is gone though, which is kind of annoying.
func floatyWillOpen(_ floaty: Floaty) ,
    floaty.buttonColor = UIColor.init(red: 217, green: 217, blue: 217)
    floaty.buttonImage = UIImage(named: "floaty_cross")
}

func floatyWillClose(_ floaty: Floaty) {
    floaty.buttonColor = UIColor.init(red: 0, green: 101, blue: 100)
    floaty.buttonImage = UIImage(named: "floaty_plus")
}


Fix broken links

Changes:

Propose to remove fosteropenscience.eu e-learning platform. The links to this platform have been failing for a while, so it was removed from the list in software_management_plan.md.
Another broken link was fixed.

Thanks!


Add a toleration to avoid removing the taint on the master nodes

What this PR does / why we need it:
Add a toleration to the daemonset to allow scheduling of the pods without removing the taint on the master nodes.
With this toleration, you don't need to do "kubectl taint nodes --all node-role.kubernetes.io/master-" as described in the README:
https://github.com/vmware/kubernetes/blob/enable-vcp-uxi/README.md
Which issue(s) this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close the issue(s) when PR gets merged):
Fixes #
Special notes for your reviewer:
Release note:

NONE

@sguyennet change looks good to me.
I will update documentation.

/lgtm

Hi,
I just noticed that you updated the documentation, but you didn't push a new image on Docker hub:
https://hub.docker.com/r/cnastorage/enablevcp/tags/
The modification I did is embedded in the Docker images, therefore you should build a new one and push it to Docker hub.

@sguyennet I will build and upload new image today.


Desired artifacts will not be downloaded if other published artifacts are unchecked

Agent Version and Platform
Version of your agent? 2.150.0
OS of the machine running the agent? Windows
Azure DevOps Type and Version
dev.azure.com
If dev.azure.com, what is your organization name? https://dev.azure.com/lolinctest (though I reproed it on a second org as well)
What's not working?
If multiple artifacts are uploaded in a single build and then a release pipeline is instructed to download only one of them, nothing will be downloaded.

Create a build pipeline

pool:
  name: Hosted VS2017
steps:
- task: PublishPipelineArtifact@0
  displayName: 'Publish Pipeline Artifact'
  inputs:
    artifactName: drop1
    targetPath: '$(System.DefaultWorkingDirectory)'

- task: PublishPipelineArtifact@0
  displayName: 'Publish Pipeline Artifact'
  inputs:
    artifactName: drop2
    targetPath: '$(System.DefaultWorkingDirectory)'

Create a release pipeline that is linked to the above build. The issue requires no explicit tasks.
Run the pipeline

==============================================================================
Task         : Download Pipeline Artifact
Description  : Download Pipeline Artifact
Version      : 1.1.0
Author       : Microsoft Corporation
Help         : Download named artifact from a pipeline to a local path.
==============================================================================
Download artifact to: D:\a\r1\a/artifacts/drop2
Information, Minimatch patterns: [**]
Information, Filtered 6 files from the Minimatch filters supplied.

Note that 'drop2' download 6 files
Edit the agent job to only download 'drop2'

Run the pipeline

==============================================================================
Task         : Download Pipeline Artifact
Description  : Download Pipeline Artifact
Version      : 1.1.0
Author       : Microsoft Corporation
Help         : Download named artifact from a pipeline to a local path.
==============================================================================
Download artifact to: D:\a\r1\a/artifacts/drop2
Information, Minimatch patterns: [drop2/**]

Note that 'drop2' downloaded zero files instead of 6.
Note also that the minimatch pattern is specified only in the latter instance.

So this seems to be an issue with the use of the Download Pipeline Artifact task, and not the task itself.
Agent and Worker's Diagnostic Logs
I'm not seeing where these logs are, but this issue is pretty easy to repro.

@owenhuynMSFT @madhurig


Unexpected Application Error on startup

First of all, thanks for sharing this package.
I've added the module to my TizenBrew but get the following error directly after showing the Jellyfin logo:

I finally can run the Jellyfin app using the docker approach


Add unit tests

Hello,
I found this repo interesting and I am thinking to refactor it.
I did a bit of work which you can have a look at https://github.com/ashokdey/promnom
If you can add a few unit tests, fixing things becomes very easy
Thanks!

@ashokdey Here you go!

Looking forward to fixing the code now. Thanks

Looking forward to fixing the code now. Thanks

It may take some time, the schedule is going a bit heavy

Looking forward to fixing the code now. Thanks

It may take some time, the schedule is going a bit heavy

That's alright! Araam se! 😅

@ashokdey Hi, any updates ?

Hey, I am busy with some family work which is getting delayed due to COVID scenarios, I have it in my todos


Alpha are developing a public API

Hi,
It appears alpha are finally developing a read only API.
https://github.com/alphaess-developer
Hopefully this will remove some of the issues faced with constant changes.
It should be ready in a month or so.

Reported elsewhere


StartConversationAsync() returns null

HI
In BotConnectorApp project, I am able to retrieve token but the subsequent call to StartConversationAsync() always returns null.
           var conversation = await directLineClient.Conversations.StartConversationAsync();
            var conversationtId = conversation.ConversationId;  -> conversation is null
            string inputMessage;

I am trying to run this project with PVA bot and the Token End Point is somethin like
https://defaultXXXX.3b.environment.api.powerplatform.com/powervirtualagents/botsbyschema/new_bot_XXXX/directline/token?api-version=2022-03-01-preview
XXX-> guids

I am facing a similar issue.

Hi, I need help... Is there a way to run this bot connector api app on a european environment?
I read on MS that the default uri used is https://directline.botframework.com/ and the eu version is https://europe.directline.botframework.com/. Here's the link i read from https://learn.microsoft.com/en-us/azure/bot-service/rest-api/bot-framework-rest-direct-line-3-0-api-reference?view=azure-bot-service-4.0


Adding TLS support to the Java client and JDBC driver

re: Issue #2209
TLS connections are already supported by VTGate, gRPC, and all of the non-Java clients.  For Java to reach parity, support is needed in the grpc-client, client, and jdbc modules under src/github.com/youtube/vitess/java.
This PR is a work in progress... visible for early review and vetting, but not yet ready to merge.
At this point, the VitessJDBCUrl class parses an optional parameter, which indicates that a connection should use SSL.  The parameter follows standard MySQL JDBC conventions.
Pending commits will:

Update GrpcClientFactory, to expose a method for creating a TLS-enabled RpcClient in addition to the current plaintext one.
Update VitessVTGateManager, to use this new method when the JDBC URL calls for SSL.
Write unit test coverage for the above, using a vtgateclienttest mock in a style similar to the src/github.com/youtube/vitess/test/encrypted_transport.py script.
End-to-end testing.  Update examples/local/vtgate-up.sh, to use TLS with a self-signed cert when an optional parameter is passed.  Also update the examples/client_jdbc.sh test script, to likewise use a TLS connection when an optional parameter is passed.

Any feedback about this approach is definitely welcomed!

This change is

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 60 at r4 (raw file):
Previously, steve-perkins wrote…
Hi Harshit, my latest commit addresses all of the other comments you've raised... but I'm a bit unsure on how to proceed with this one.
Client vs. Server
I started down the path of initializing an SslContext object with GrpcSslContexts.forClient(), because it seemed like this code would always be a "client" context (i.e. its in GrpcClientFactory after all).  Are you saying that its possible to be in a "server" context here, and I should have some logical branching to detect that and build the SslContext differently for each branch?
keyManager(...)
OR.... are you agreeing that this is indeed a "client" context, but are instead taking issue with the keyManager(...) call on the next line?  If so, then is the issue:

keyManager and trustManager can be optional (i.e. if VTGate is configured with certs that are publicly verifiable through Verisign or whoever, and need no special client config)?  So I shouldn't call these two mutators if they keyStore and trustStore properties are null.
Or are you saying that if I call keyManager, then I should not also be using trustManager?  If so, then I'm totally lost.  :)

Or is the requested change something other than any of the possibilities above?  Thanks!

The KeyManager is not required always. Only when on VTGate the client authentication is enabled. Then it is required to pass.
So, here on the client side.
If privateKeyWrapper is not null than only use keyManager while creating grpc ssl context.

Comments from Reviewable

Reviewed 2 of 5 files at r4, 3 of 4 files at r5, 1 of 3 files at r6.
Review status: 6 of 9 files reviewed at latest revision, 13 unresolved discussions, some commit checks failed.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsTest.java, line 40 at r6 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
I'm starting to get a bit over my head in this area, and could use some high-level guidance from @harshit-gangal or @alainjobart.  I'm adapting logic from Alain's encrypted_transport.py script, but barely understand much of what I'm adapting.
I THINK that I just want to:

Create a CA
Use that CA to create signed certificates for the VTGate server and the client
Start a VTGate server process (or vtgateclienttest mock in this case), configured with the server cert
Start a gRPC client connection, using the client cert

However, the Python script is creating numerous other certs (e.g. separate ones for VTGate and VTTablet)... and even seems to be using separate CA's for some reason.
Can you please give me a sanity check, to be sure I'm not going too far down the wrong path?  I think I just need to better understand what that Python script is doing at the high-level, so I can either replicate it appropriately or else only borrow a subset if it's overkill for this case.  Thanks!

You can check this.
http://vitess.io/user-guide/transport-security-model.html#grpc-encrypted-transport
@alainjobart can add more.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsTest.java, line 128 at r6 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
This askHarshit step is taken straight from the encrypted_transport.py test script (line 102), but I don't really understand what it's doing.  The -in and -out parameters are the same filename.

@alainjobart

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsTest.java, line 177 at r6 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
Tied in with my comment toward @harshit-gangal and @alainjobart above.  I'm not sure if I'm really using the right flags and artifacts here.

@alainjobart

Comments from Reviewable

Review status: 6 of 9 files reviewed at latest revision, 12 unresolved discussions, some commit checks failed.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 60 at r4 (raw file):
Previously, harshit-gangal wrote…
The KeyManager is not required always. Only when on VTGate the client authentication is enabled. Then it is required to pass.
So, here on the client side.
If privateKeyWrapper is not null than only use keyManager while creating grpc ssl context.

What do you mean "client authentication enabled" on the VTGate side?  Which flag passed to the VTGate executable?  Are you talking about something other than the flags to enable SSL?  (e.g. grpc_cert, grpc_key, gprc_ca)
If it is possible to use SSL without client authentication enabled, then GrpcSslContexts.forClient() doesn't need anything else added to it?  From the end-user perspective they simply wouldn't set any properties, so that privateKeyWrapper ends up null here?
Assuming that I am correctly following you in the paragraph above, then I'm still not sure about your last sentence (i.e. "only use keyManager").  Are you saying NOT to set trustManager too?

Comments from Reviewable

Review status: 6 of 9 files reviewed at latest revision, 12 unresolved discussions, some commit checks failed.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 16 at r4 (raw file):
Previously, harshit-gangal wrote…
Instead of import package.* add all the classes getting used.

Done.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 85 at r4 (raw file):
Previously, harshit-gangal wrote…
move "JKS" to constant file.

Done.

java/jdbc/src/main/java/com/flipkart/vitess/jdbc/VitessJDBCUrl.java, line 29 at r1 (raw file):
Previously, harshit-gangal wrote…
nitpick: name it as useSSL so that is maps to the property.

Done.

java/jdbc/src/main/java/com/flipkart/vitess/jdbc/VitessJDBCUrl.java, line 113 at r1 (raw file):
Previously, harshit-gangal wrote…
Kindly use equal with ignore case.

Done.

java/jdbc/src/main/java/com/flipkart/vitess/jdbc/VitessJDBCUrl.java, line 65 at r4 (raw file):
Previously, harshit-gangal wrote…
nit: truststore -> trustStore

Done.

java/jdbc/src/main/java/com/flipkart/vitess/jdbc/VitessJDBCUrl.java, line 148 at r4 (raw file):
Previously, harshit-gangal wrote…
ssl is no used.

Done.

java/jdbc/src/main/java/com/flipkart/vitess/jdbc/VitessJDBCUrl.java, line 347 at r4 (raw file):
Previously, harshit-gangal wrote…
key != null is a redundant check.

Done.

java/jdbc/src/main/java/com/flipkart/vitess/jdbc/VitessVTGateManager.java, line 75 at r4 (raw file):
Previously, harshit-gangal wrote…
nit: VTGateConne -> VTGateConn

Done.

Comments from Reviewable

Reviewed 1 of 4 files at r5.
Review status: 7 of 9 files reviewed at latest revision, 4 unresolved discussions, some commit checks failed.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 60 at r4 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
What do you mean "client authentication enabled" on the VTGate side?  Which flag passed to the VTGate executable?  Are you talking about something other than the flags to enable SSL?  (e.g. grpc_cert, grpc_key, gprc_ca)
If it is possible to use SSL without client authentication enabled, then GrpcSslContexts.forClient() doesn't need anything else added to it?  From the end-user perspective they simply wouldn't set any properties, so that privateKeyWrapper ends up null here?
Assuming that I am correctly following you in the paragraph above, then I'm still not sure about your last sentence (i.e. "only use keyManager").  Are you saying NOT to set trustManager too?

I meant trustManager will be used always. As this will check if the client is connecting to correct VTGate.
If on VTGate, client authentication is enabled by setting grpc_ca flag, then on client side KeyManager needs to be set.
As we cannot check whether someone has enabled/disabled this flag.
So, if  someone has provided the property to set PrivateKeyWrapper.
We will also set KeyManager in grpc ssl context.
Setting TrustManager is required by default.

Comments from Reviewable

Review status: 6 of 9 files reviewed at latest revision, 4 unresolved discussions.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 60 at r4 (raw file):
Previously, harshit-gangal wrote…
I meant trustManager will be used always. As this will check if the client is connecting to correct VTGate.
If on VTGate, client authentication is enabled by setting grpc_ca flag, then on client side KeyManager needs to be set.
As we cannot check whether someone has enabled/disabled this flag.
So, if  someone has provided the property to set PrivateKeyWrapper.
We will also set KeyManager in grpc ssl context.
Setting TrustManager is required by default.

I've pushed a new commit... which always sets trustManager, but does not set keyManager when the caller does make a valid keyStore available.  Please let me know if I'm on the right track here.  Thanks!

Comments from Reviewable

Review status: 5 of 10 files reviewed at latest revision, 6 unresolved discussions.

java/grpc-client/pom.xml, line 36 at r8 (raw file):

      <version>2.5</version>
    </dependency>
    <dependency>

Once GrpcClientTlsTest started using SSL on the client and vtgateclienttest ends, I ran into the error message:  "Jetty ALPN/NPN has not been properly configured.".
That lead me to this grpc-java GitHub issue, which lead me to this grpc-java documentation... indicating that Jetty ALPN/NPN is essentially deprecated, and this netty-tcnativedependency should be added to one's Maven POM instead.
I'm hoping that you concur... because man, does that JDK version-specific ALPN/NPN bootloader dependency seem nasty!

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 60 at r4 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
I've pushed a new commit... which always sets trustManager, but does not set keyManager when the caller does make a valid keyStore available.  Please let me know if I'm on the right track here.  Thanks!

After a discussion with some of my company's security guys, I think I better understand now what you're trying to get across.
You can create a basic SSL connection, in which the client verifies the server and traffic gets encrypted.  The server-side needs a private key and public certificate (i.e. keyStore), and the client-side needs a trusted CA certificate (i.e. trustStore).
On top of that you can add client authentication, in which the client-side also needs a key and cert (i.e. keyStore), and the server-side also needs a trusted CA certificate (i.e. trustStore).  The trustStore could be the same on both ends, if the same CA was used to sign both certs.
So for now, this unit test is only testing a basic SSL connection.  I'll add client authentication in a follow-up test suite.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsTest.java, line 177 at r6 (raw file):
Previously, harshit-gangal wrote…
@alainjobart

I think I have the gist now, based on the discussion above regarding basic SSL vs. SSL with client authentication.  Adding the -grpc_ca flag here enables the latter.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsTest.java, line 144 at r8 (raw file):

                                Context.getDefault().withDeadlineAfter(Duration.millis(5000)),
                                new InetSocketAddress("localhost", port),
                                tlsOptions

Okay, I'm now testing SSL "end-to-end" (sorta... with a mock, anyway).
At first I experienced Jetty ALPN/NPN issues, which I addressed through the new dependency added to the Maven POM file.
However, I'm now seeing a lot of these errors:  java.security.cert.CertificateException: No name matching localhost found.
Research indicates that this problem stems from having a certificate generated with a CN other than the hostname being used at runtime.  I've tried changing all CN references to "localhost", here in this unit test suite as well as the ca.config file.  However, it's had no effect.
Suggestions are appreciated if you see something I've missed!  Otherwise, I'll look at with fresh eyes tomorrow.

Comments from Reviewable

Reviewed 1 of 1 files at r7.
Review status: 5 of 10 files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 60 at r4 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
I've pushed a new commit... which always sets trustManager, but does not set keyManager when the caller does make a valid keyStore available.  Please let me know if I'm on the right track here.  Thanks!

AFAIK, it should work. It will need an end to end test to validate it.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 60 at r7 (raw file):

      final KeyStore trustStore = loadKeyStore(tlsOptions.getTrustStore(), tlsOptions.getTrustStorePassword());
      final X509Certificate[] trustCertCollection = {
              (X509Certificate) trustStore.getCertificate(tlsOptions.getTrustAlias())

loadKeyStore can return null. Hence check for trustStore == null and throw appropriate exception back.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 71 at r8 (raw file):

                : loadPrivateKeyEntryForAlias(keyStore, tlsOptions.getKeyAlias(), tlsOptions.getKeyStorePassword(), tlsOptions.getKeyPassword());
        sslContextBuilder.keyManager(
                privateKeyWrapper.getPrivateKey(),

loadPrivateKeyEntry and loadPrivateKeyEntryForAlias can return null
hence all these method calls can return in Null Pointer Exception.
privateKeyWrapper.getPrivateKey(),
privateKeyWrapper.getPassword(),
privateKeyWrapper.getCertificateChain()

Comments from Reviewable

Review status: 5 of 10 files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsTest.java, line 128 at r6 (raw file):
Previously, harshit-gangal wrote…
@alainjobart

In conversation with my company's Security guys, they suggested that this was probably done in the Python script to strip a password (which I'm not doing in the first place with this more simple Java test).
After establishing a successful connection to vtgateclienttest, I tried commenting-out this step... and it did not impact the result at all.  So I'm leaving it out, unless @alainjobart raises a concern later.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsTest.java, line 144 at r8 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
Okay, I'm now testing SSL "end-to-end" (sorta... with a mock, anyway).
At first I experienced Jetty ALPN/NPN issues, which I addressed through the new dependency added to the Maven POM file.
However, I'm now seeing a lot of these errors:  java.security.cert.CertificateException: No name matching localhost found.
Research indicates that this problem stems from having a certificate generated with a CN other than the hostname being used at runtime.  I've tried changing all CN references to "localhost", here in this unit test suite as well as the ca.config file.  However, it's had no effect.
Suggestions are appreciated if you see something I've missed!  Otherwise, I'll look at with fresh eyes tomorrow.

I was using token-substitution to inject the CN value "localhost" into the cert-template.config template, and there was a bug in that.  Once it started using "localhost", the test started succeeding.  Will be updated in the next PR.

Comments from Reviewable

Review status: 5 of 10 files reviewed at latest revision, 8 unresolved discussions.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 60 at r7 (raw file):
Previously, harshit-gangal wrote…
loadKeyStore can return null. Hence check for trustStore == null and throw appropriate exception back.

The enclosing block is already catching NullPointerException, and throwing a RuntimeException that wraps the original.  Are you saying that you would like me to create a new custom exception type?

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 71 at r8 (raw file):
Previously, harshit-gangal wrote…
loadPrivateKeyEntry and loadPrivateKeyEntryForAlias can return null
hence all these method calls can return in Null Pointer Exception.
privateKeyWrapper.getPrivateKey(),
privateKeyWrapper.getPassword(),
privateKeyWrapper.getCertificateChain()

Same question as above.

Comments from Reviewable

Review status: 5 of 11 files reviewed at latest revision, 8 unresolved discussions.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 60 at r4 (raw file):
Previously, harshit-gangal wrote…
AFAIK, it should work. It will need an end to end test to validate it.

Done.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsTest.java, line 40 at r6 (raw file):
Previously, harshit-gangal wrote…
You can check this.
http://vitess.io/user-guide/transport-security-model.html#grpc-encrypted-transport
@alainjobart can add more.

Done.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsTest.java, line 128 at r6 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
In conversation with my company's Security guys, they suggested that this was probably done in the Python script to strip a password (which I'm not doing in the first place with this more simple Java test).
After establishing a successful connection to vtgateclienttest, I tried commenting-out this step... and it did not impact the result at all.  So I'm leaving it out, unless @alainjobart raises a concern later.

Done.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsTest.java, line 177 at r6 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
I think I have the gist now, based on the discussion above regarding basic SSL vs. SSL with client authentication.  Adding the -grpc_ca flag here enables the latter.

Done.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsTest.java, line 144 at r8 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
I was using token-substitution to inject the CN value "localhost" into the cert-template.config template, and there was a bug in that.  Once it started using "localhost", the test started succeeding.  Will be updated in the next PR.

Done.

Comments from Reviewable

Review status: 5 of 11 files reviewed at latest revision, 9 unresolved discussions.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsClientAuthTest.java, line 83 at r9 (raw file):

                .trustAlias("cacert");

        client = new GrpcClientFactory()

I now have the original unit test suite (which tests a basic SSL connection with no client auth), and this new test suite which adds the client auth.
The original is working fine now (yea!!!).  However, this client auth version throws a slew of stacktraces such as the following one.  I suspect that something is wrong with the netty-tcnative gRPC dependency added by this pull request (why did gRPC go this native/JNI route, instead of using BouncyCastle or some other pure Java SSL library?!?).
I'll have to wrestle with this some more tomorrow.  If you have some experience with Jetty ALPN/NPN and/or netty-tcnative dependency configuration, and can offer some suggestions, it would definitely be appreciated.  Thanks!
Caused by: io.grpc.StatusRuntimeException: UNKNOWN
	at io.grpc.Status.asRuntimeException(Status.java:536)
	at io.grpc.internal.DelayedClientTransport.startBackoff(DelayedClientTransport.java:325)
	at io.grpc.internal.TransportSet$2.run(TransportSet.java:281)
	at io.grpc.internal.TransportSet$TransportListener.transportShutdown(TransportSet.java:461)
	at io.grpc.netty.ClientTransportLifecycleManager.notifyShutdown(ClientTransportLifecycleManager.java:68)
	at io.grpc.netty.NettyClientHandler.onConnectionError(NettyClientHandler.java:306)
	at io.netty.handler.codec.http2.Http2ConnectionHandler.onError(Http2ConnectionHandler.java:550)
	at io.grpc.netty.AbstractNettyHandler.exceptionCaught(AbstractNettyHandler.java:88)
	at io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:295)
	at io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:274)
	at io.netty.channel.AbstractChannelHandlerContext.fireExceptionCaught(AbstractChannelHandlerContext.java:266)
	at io.netty.handler.ssl.SslHandler.exceptionCaught(SslHandler.java:743)
	at io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:295)
	at io.netty.channel.AbstractChannelHandlerContext.notifyHandlerException(AbstractChannelHandlerContext.java:862)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:123)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:571)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:512)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:426)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:398)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:877)
	at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
	... 1 more
Caused by: io.netty.handler.codec.DecoderException: java.lang.AbstractMethodError
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
	... 14 more
Caused by: java.lang.AbstractMethodError
	at org.apache.tomcat.jni.SSL.readFromSSL(Native Method)
	at io.netty.handler.ssl.OpenSslEngine.readPlaintextData(OpenSslEngine.java:381)
	at io.netty.handler.ssl.OpenSslEngine.unwrap(OpenSslEngine.java:748)
	at io.netty.handler.ssl.OpenSslEngine.unwrap(OpenSslEngine.java:855)
	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1088)
	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:966)
	at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:900)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
	... 16 more

Comments from Reviewable

Reviewed 2 of 4 files at r8, 1 of 3 files at r9.
Review status: 8 of 11 files reviewed at latest revision, 8 unresolved discussions, some commit checks failed.

java/grpc-client/pom.xml, line 36 at r8 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
Once GrpcClientTlsTest started using SSL on the client and vtgateclienttest ends, I ran into the error message:  "Jetty ALPN/NPN has not been properly configured.".
That lead me to this grpc-java GitHub issue, which lead me to this grpc-java documentation... indicating that Jetty ALPN/NPN is essentially deprecated, and this netty-tcnativedependency should be added to one's Maven POM instead.
I'm hoping that you concur... because man, does that JDK version-specific ALPN/NPN bootloader dependency seem nasty!

There is a newer release
https://mvnrepository.com/artifact/io.netty/netty-tcnative-boringssl-static/1.1.33.Fork24

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 60 at r7 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
The enclosing block is already catching NullPointerException, and throwing a RuntimeException that wraps the original.  Are you saying that you would like me to create a new custom exception type?

It is good to check it than waiting for the Exception to be thrown. As it adds performance overhead.
For more info: https://www.securecoding.cert.org/confluence/display/java/ERR08-J.+Do+not+catch+NullPointerException+or+any+of+its+ancestors

Comments from Reviewable

Review status: 7 of 12 files reviewed at latest revision, 8 unresolved discussions.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsClientAuthTest.java, line 83 at r9 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
I now have the original unit test suite (which tests a basic SSL connection with no client auth), and this new test suite which adds the client auth.
The original is working fine now (yea!!!).  However, this client auth version throws a slew of stacktraces such as the following one.  I suspect that something is wrong with the netty-tcnative gRPC dependency added by this pull request (why did gRPC go this native/JNI route, instead of using BouncyCastle or some other pure Java SSL library?!?).
I'll have to wrestle with this some more tomorrow.  If you have some experience with Jetty ALPN/NPN and/or netty-tcnative dependency configuration, and can offer some suggestions, it would definitely be appreciated.  Thanks!
Caused by: io.grpc.StatusRuntimeException: UNKNOWN
	at io.grpc.Status.asRuntimeException(Status.java:536)
	at io.grpc.internal.DelayedClientTransport.startBackoff(DelayedClientTransport.java:325)
	at io.grpc.internal.TransportSet$2.run(TransportSet.java:281)
	at io.grpc.internal.TransportSet$TransportListener.transportShutdown(TransportSet.java:461)
	at io.grpc.netty.ClientTransportLifecycleManager.notifyShutdown(ClientTransportLifecycleManager.java:68)
	at io.grpc.netty.NettyClientHandler.onConnectionError(NettyClientHandler.java:306)
	at io.netty.handler.codec.http2.Http2ConnectionHandler.onError(Http2ConnectionHandler.java:550)
	at io.grpc.netty.AbstractNettyHandler.exceptionCaught(AbstractNettyHandler.java:88)
	at io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:295)
	at io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:274)
	at io.netty.channel.AbstractChannelHandlerContext.fireExceptionCaught(AbstractChannelHandlerContext.java:266)
	at io.netty.handler.ssl.SslHandler.exceptionCaught(SslHandler.java:743)
	at io.netty.channel.AbstractChannelHandlerContext.invokeExceptionCaught(AbstractChannelHandlerContext.java:295)
	at io.netty.channel.AbstractChannelHandlerContext.notifyHandlerException(AbstractChannelHandlerContext.java:862)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:374)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
	at io.netty.channel.AbstractChannelHandlerContext.fireChannelRead(AbstractChannelHandlerContext.java:350)
	at io.netty.channel.DefaultChannelPipeline$HeadContext.channelRead(DefaultChannelPipeline.java:1334)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:358)
	at io.netty.channel.DefaultChannelPipeline.fireChannelRead(DefaultChannelPipeline.java:926)
	at io.netty.channel.nio.AbstractNioByteChannel$NioByteUnsafe.read(AbstractNioByteChannel.java:123)
	at io.netty.channel.nio.NioEventLoop.processSelectedKey(NioEventLoop.java:571)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeysOptimized(NioEventLoop.java:512)
	at io.netty.channel.nio.NioEventLoop.processSelectedKeys(NioEventLoop.java:426)
	at io.netty.channel.nio.NioEventLoop.run(NioEventLoop.java:398)
	at io.netty.util.concurrent.SingleThreadEventExecutor$5.run(SingleThreadEventExecutor.java:877)
	at io.netty.util.concurrent.DefaultThreadFactory$DefaultRunnableDecorator.run(DefaultThreadFactory.java:144)
	... 1 more
Caused by: io.netty.handler.codec.DecoderException: java.lang.AbstractMethodError
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:442)
	at io.netty.handler.codec.ByteToMessageDecoder.channelRead(ByteToMessageDecoder.java:248)
	at io.netty.channel.AbstractChannelHandlerContext.invokeChannelRead(AbstractChannelHandlerContext.java:372)
	... 14 more
Caused by: java.lang.AbstractMethodError
	at org.apache.tomcat.jni.SSL.readFromSSL(Native Method)
	at io.netty.handler.ssl.OpenSslEngine.readPlaintextData(OpenSslEngine.java:381)
	at io.netty.handler.ssl.OpenSslEngine.unwrap(OpenSslEngine.java:748)
	at io.netty.handler.ssl.OpenSslEngine.unwrap(OpenSslEngine.java:855)
	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:1088)
	at io.netty.handler.ssl.SslHandler.unwrap(SslHandler.java:966)
	at io.netty.handler.ssl.SslHandler.decode(SslHandler.java:900)
	at io.netty.handler.codec.ByteToMessageDecoder.callDecode(ByteToMessageDecoder.java:411)
	... 16 more

Updating the underlying grpc-all Maven dependency to the latest version (i.e. 1.0.0 -> 1.0.2) resolved this problem.

Comments from Reviewable

Review status: 7 of 12 files reviewed at latest revision, 6 unresolved discussions.

java/grpc-client/pom.xml, line 36 at r8 (raw file):
Previously, harshit-gangal wrote…
There is a newer release
https://mvnrepository.com/artifact/io.netty/netty-tcnative-boringssl-static/1.1.33.Fork24

Done.

Comments from Reviewable

I just looked at this PR, overall it looks good. The Java SSL stuff is just complicated, whichever way you look at it, it's a lot of boilerplate code. But there is no way around it. Thank you for contributing this!

This PR is shaping well now.

Reviewed 1 of 4 files at r8, 2 of 3 files at r9, 2 of 2 files at r10.
Review status: all files reviewed at latest revision, 3 unresolved discussions.

Comments from Reviewable

Thanks, guys!  It's been a great learning experience.  From here, I need to:

Add some null-checks as requested
Write Javadocs for all the methods I've marked with "TODO's"
Add some optional args to the /examples/local test scripts, to support end-to-end testing with a real VTGate.

From there I don't have anything else planned at this time.  I could be wrapped tomorrow... mostly likely early next week.

Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks broke.

Comments from Reviewable

Review status: 11 of 12 files reviewed at latest revision, 2 unresolved discussions.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 60 at r7 (raw file):
Previously, harshit-gangal wrote…
It is good to check it than waiting for the Exception to be thrown. As it adds performance overhead.
For more info: https://www.securecoding.cert.org/confluence/display/java/ERR08-J.+Do+not+catch+NullPointerException+or+any+of+its+ancestors

Done.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 71 at r8 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
Same question as above.

Done.

Comments from Reviewable

This PR looks good.
2 minor comments.

Reviewed 1 of 1 files at r11, 8 of 8 files at r12.
Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks broke.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 135 at r12 (raw file):

    try {
      final X509Certificate[] certCollection = {

certCollection is redundant. Can directly return the value.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsClientAuthTest.java, line 69 at r12 (raw file):

        final String vtgate = String.format("%s -grpc_cert %s -grpc_key %s -grpc_ca %s -logtostderr -grpc_port %s -service_map grpc-vtgateservice",
                vtRoot + "/bin/vtgateclienttest", cert, key, caCert, Integer.toString(port));
        System.out.println(vtgate);

If this is for your test, then remove this. Otherwise, give some meaningful prefix.

Comments from Reviewable

Review status: all files reviewed at latest revision, 2 unresolved discussions, some commit checks broke.

Comments from Reviewable

This is looking good to me now. Anything else needs to happen here?
Before this can be merged, please:

squash everything in one commit
edit the PR message to not be WIP any more.

Thanks!

@alainjobart:  I think @harshit-gangal had one last minor nitpick to address, and I'd like to replace all of those TODO's with method-level JavaDocs.  Otherwise, it's just squashing down the commits and calling it a wrap.
Today's a bit crazy, getting ready for holiday PTO... it will probably be tomorrow (Tues) when I remove the "WIP" prefix.

Review status: 11 of 17 files reviewed at latest revision, 2 unresolved discussions, some commit checks failed.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 135 at r12 (raw file):
Previously, harshit-gangal wrote…
certCollection is redundant. Can directly return the value.

Done.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTlsClientAuthTest.java, line 69 at r12 (raw file):
Previously, harshit-gangal wrote…
If this is for your test, then remove this. Otherwise, give some meaningful prefix.

Done.

Comments from Reviewable

Apologies for not having this wrapped up ahead of the holiday break.  I have now completed all of the action items outlined above.  I discovered a new issue with GrpcClientFactor, see my comment below on that file.  However, I'm not sure whether that should be addressed with this pull request.  Let me know, and if not then this PR is ready to merge on my end.  I'm removing the "WIP" prefix.  Thanks!

Review status: 11 of 17 files reviewed at latest revision, 3 unresolved discussions, some commit checks failed.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 43 at r13 (raw file):

   */
  @Override
  public RpcClient create(Context ctx, InetSocketAddress address) {

All of the existing code which calls this method is passing Context objects, which set timeout duration values and sometimes the caller ID.  However, I just noticed that these Context objects are dropped on the floor and never actually used for anything.
This isn't new code that I introduced (although I am following the same pattern with createTls(...) below.  Rather, this was the pre-existing state to begin with.
Obviously this is cruft of SOME kind.  Either this method once used those Context objects, and had to change for some reason... or maybe this parameter was added in anticipation of doing something with it someday, and then that never happened?  Either way, it seems that those timeout duration and caller ID values SHOULD be applied.  I'm not really sure how though, as NettyChannelBuilder is much lower in the stack than this Context class.

Comments from Reviewable

Reviewed 6 of 6 files at r13.
Review status: all files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 43 at r13 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
All of the existing code which calls this method is passing Context objects, which set timeout duration values and sometimes the caller ID.  However, I just noticed that these Context objects are dropped on the floor and never actually used for anything.
This isn't new code that I introduced (although I am following the same pattern with createTls(...) below.  Rather, this was the pre-existing state to begin with.
Obviously this is cruft of SOME kind.  Either this method once used those Context objects, and had to change for some reason... or maybe this parameter was added in anticipation of doing something with it someday, and then that never happened?  Either way, it seems that those timeout duration and caller ID values SHOULD be applied.  I'm not really sure how though, as NettyChannelBuilder is much lower in the stack than this Context class.

AFAIK, Context is kept to timeout the connection. But, as of now, When a query is sent then only the actual connection is created with the VTGates. therefore this is not used.
Similar is the case with CallerID, it is used when the data is actually send to VTGates.

Comments from Reviewable

There are some merge conflict that needs to be resolved.

Pull request squashed down to a single commit.

Review status: 14 of 17 files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable

@steve-perkins The build is failing. Can you address that?

@steve-perkins I am getting the same error as Travis build in my local.
It seems the VtGate is not up.
java.sql.SQLTransientException: io.grpc.StatusRuntimeException: UNAVAILABLE

Review status: 12 of 17 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 43 at r13 (raw file):
Previously, harshit-gangal wrote…
AFAIK, Context is kept to timeout the connection. But, as of now, When a query is sent then only the actual connection is created with the VTGates. therefore this is not used.
Similar is the case with CallerID, it is used when the data is actually send to VTGates.

Can you explain a bit more about this comment?  The most promising theory that I've heard yet is a timeout value is too low on the client side, and so results can vary between my local machine and slower environments.  However, presently it doesn't look like the Java client side has the ability to set a timeout value at all.
Are you saying that the timeout value is actually set through other means?
If not, then do you have any suggestions for how I might bridge the gap between the Context object here, and the NettyChannelBuilder factory class?  I'm not exactly sure what the timeout control is in the latter.

Comments from Reviewable

That's expected.  The rest of the message should read:  Channel in TRANSIENT_FAILURE state.
With additional logging, the error is shown to be caused by an SSL handshake not succeeding.  However, if you modify the unit test suites, to remove the TLS options on both the VTGate server side and the client connection side, the same code succeeds.

Review status: 12 of 17 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

Comments from Reviewable

Reviewed 3 of 3 files at r14.
Review status: 12 of 17 files reviewed at latest revision, 1 unresolved discussion, some commit checks failed.

java/grpc-client/src/main/java/com/youtube/vitess/client/grpc/GrpcClientFactory.java, line 43 at r13 (raw file):
Previously, steve-perkins (Steve Perkins) wrote…
Can you explain a bit more about this comment?  The most promising theory that I've heard yet is a timeout value is too low on the client side, and so results can vary between my local machine and slower environments.  However, presently it doesn't look like the Java client side has the ability to set a timeout value at all.
Are you saying that the timeout value is actually set through other means?
If not, then do you have any suggestions for how I might bridge the gap between the Context object here, and the NettyChannelBuilder factory class?  I'm not exactly sure what the timeout control is in the latter.

AFAIK, The timeout is not used in the connection creation. It is only used in execute calls.

Comments from Reviewable

I finally tracked down the root cause of why unit tests were passing on my local machine yet failing on the Travis CI box.
Java 7 and above refuse to work with RSA certs that are less than 1024 bits, because that's too insecure.  On my local machine, OpenSSL uses a default bitsize of 2048.  It turns out that on Travis, the default is 512 bytes.
So I made changes in the unit test suites to execute OpenSSL processes with a bitsize explicitly specified.  All is working well!  I have squashed down the commit history, and this PR is ready for merge as far as I know (trying to figure out why the googlebot has started complaining about a missing CLA).

Review status: 11 of 152 files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable

Okay, the CLA issue was due to not properly squashing my git commits, and that is now corrected.  So tests are passing, CLA's are in place, and this PR is ready for merge pending approval.  Whew!

Review status: 11 of 18 files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable

This is cool :)
LGTM

Reviewed 1 of 4 files at r15, 1 of 3 files at r16, 6 of 148 files at r17.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

Review status: 15 of 18 files reviewed at latest revision, 1 unresolved discussion.

java/grpc-client/src/test/java/com/youtube/vitess/client/grpc/GrpcClientTest.java, line 47 at r19 (raw file):
Previously, alainjobart (Alain Jobart) wrote…
Do we still need this sleep and the one below? It seems the java grpc client will retry until timeout if the server is not there yet, so we don't need to wait?

I have removed the two sleepoperations from this non-TLS test suite, and also found that the sleep operation in the tearDown methods of the two TLS-related test suites can be removed.  However, things are just not happy (only on the Travis CI box) when you don't pause for a moment in between launching the vtgateclient process and attempting to connect to it.

Comments from Reviewable

@steve-perkins i just noticed that your PR conflicted with mine which was recently merged https://github.com/youtube/vitess/pull/2478. The crux of that PR was to move configuration out of VitessJDBCUrl and into its own class -- ConnectionProperties.  Hopefully there are enough examples in that class with the existing configs I added to give you a sense how to do that. But if you need any help let me know. Basically you're going to want to create a new member variable in that class of type StringConnectionProperty, BooleanConnectionProperty, or EnumConnectionProperty (or create a new type), then create a getter. Once you have the getter it will be available on the VitessConnection

@steve-perkins Can you resolve the merge conflicts? Hopefully for the last time? Sorry about the delay on this. It kind of fell through the cracks.

I have merged the latest from master, and worked through all the merge conflicts.  At least to the extent that all the Java code compiles and the examples/local/client_jdbc.sh test suite successfully runs.
However, before this gets merged, I need to take a closer look at @bbeaudreault 's PR that caused the merge conflict, and update my TLS code to be logically consistent.
I think I'll retain the handling of all the JDBC URL parameters (and falling back to check the system properties if they're unset)... because that's the established MySQL/MariaDB pattern that people will be used to.  However, it looks like I need to add logic to check this new ConnectionProperties object prior to checking the URL.
I'll add another comment (hopefully tomorrow) once I've had a chance to do that work.

Review status: 11 of 19 files reviewed at latest revision, 1 unresolved discussion.

Comments from Reviewable

Hey @steve-perkins, the basics of that PR is that we still parse the JDBC URL, but instead of accessing properties within VitessJDBCUrl.java,  the actual definition of accessors and configs is in ConnectionProperties.  JDBC URL parses any key/value in the URL, and sets those key/value pairs onto the passed Properties object. The ConnectionProperties class is basically a wrapper around that Properties object, where you define getters for the configs you want to retrieve. VitessConnection extends ConnectionProperties, so you can use those getters throughout the code in that way. I.E. connection.getUseSSL()
I would suggest that you move all of your configs into ConnectionProperties.  That way the configs are defined in a unified location. However, all of those values will still be parseable through the JDBC url.  They will also be passable through java properties files.
Take a look at mysql-connector-j for what this was modeled after.  Specifically, most of your configs are found in ConnectionPropertiesImpl

I presume that I have to wait till ConnectionProperties is fixed?

I would prefer we move the settings into ConnectionProperties before merging

Discussed on slack, we're going to let this go through for now. It would be somewhat odd to pass this through to another constructor while the object itself is constructing. In a separate PR @steve-perkins or I will do a mild refactor. Instead of doing so much work in the VitessConnection constructor, we will break it into 2 calls in VitessDriver: one to instantiate VitessConnection, and one to establish VTGate connections after successful instantiation.
LGTM


2021 week 27: rebase off upstream

No conflicts during the rebase.

But we get 3 errors when compiling:
error[E0599]: no function or associated item named `bind` found for struct `Binder` in the current scope
  --> compiler/rustc_codegen_llvm/src/gotoc/monomorphize/collector.rs:38:33
   |
38 |     let trait_ref = ty::Binder::bind(
   |                                 ^^^^ function or associated item not found in `Binder<'_, _>`

error[E0599]: no method named `recursion_limit` found for reference `&Session` in the current scope
   --> compiler/rustc_codegen_llvm/src/gotoc/monomorphize/collector.rs:304:18
    |
304 |     if !tcx.sess.recursion_limit().value_within_limit(adjusted_recursion_depth) {
    |                  ^^^^^^^^^^^^^^^ method not found in `&Session`

error[E0599]: no method named `type_length_limit` found for reference `&Session` in the current scope
   --> compiler/rustc_codegen_llvm/src/gotoc/monomorphize/collector.rs:338:18
    |
338 |     if !tcx.sess.type_length_limit().value_within_limit(type_length) {
    |                  ^^^^^^^^^^^^^^^^^ method not found in `&Session`

error: aborting due to 3 previous errors

Investigating now.

The last ones are due to a rework on the limits, which are not an attribute of the session but of the Rust typing context directly. This commit and this commit showed what changes were needed.

The first one is due to this commit that removes bind from Binder.

Candidate branch is main-153-2021-07-09 which can be found here. CI fails since the fixes have been submitted for review in #318

#318 was merged and main-153-2021-07-09 is now the default branch.


Connected or Disconnected

Hi friend,
If possible, do a plugin show in screen: Connected or Disconnected. It's is cool for application.
Thanks

http://www.crypchania.com/tutorials/connection-lost/


add a manpage

Hi!
I've just discovered llama, but I had a really strong good first impression and I'm liking it a lot!
However, llama had the unfortunate chance of being the nth program I've seen this week without a manual page and I felt the urge to change the situation, so I wrote one.  Of course, I'll be happy to help maintaining the manpage in the longer term too.
Thanks for maintaining llama!

Hi 👋🏻 thanks.
How this different from readme? How this man should be installed?

A manpage and the README are two different kind of documentation, both very important.  A README is perfect to introduce the user to the project, so that they can "get" what it's about, and usually also further information about the project itself (i.e. where and how to file bug, how to contribute, how to build, ...), while a manpage is a different kind of documentation that's aimed ad describing (with a precise format) everything about the tool itself.  They have some overlap, but they're different media for the documentation.  Also, a manual page is usually installed in the system and so it's in sync with the program version, whereas a README is usually consulted online and it's relative to the latest version.  (manpage also have other advantages: they have a semantic markdown written explicitly for documenting things -- mandoc -- that allows to export them easily to a variety of formats, to have different UIs for reading them, and finally to quickly search system-wide, and I could go on, but I've already written a wall of text, apologies! :-)
Installing the manpage it's a duty of who packages it.  I don't think go provides a way to install the documentation (regardless of the form), but that's fine.  The packagers who maintain this package for a distribution will take care of making it available in the user.
Just a final note that I forgot to include in my previous message: to read the manpage type man -l llama.1.  When installed system-wide (usually /usr/local/share/man/man1 on linux but it may depend on the distro) it'll be available as man llama just like any other manual page.
Cheers

Makes sense)
another question: what with copyright?

force pushed because I've missed shift+arrows, g and G, plus I've did some minor reformatting (the keybindings table is a bit nicer now.)
regarding the copyright honestly I don't mind.  The proposed manpage has the ISC blurb at the top simply because it's my default license for various projects (and i did a copy-paste to initialize the file), but if you prefer I can license the manpage with a different license.

rebased and updated to include the new stuff :)


Feature/issue 243 questionnaire popup

This is currently set to show after three minutes. You can manually set the value in modal_notification.tsx to test.  A couple file renames (notifications_list -> notifications and notification -> expiring_notification) make this PR look larger than it is.

One way to make PRs with file renames easier to review is to do the renames in its own commit.

@rasmus-storjohann-PG this is ready for another check.


Typo

There was a little typo in the code example. The closing bracket should be a '}' not a ')'

Thanks !


Can't install v1.3.9 with Gradle

In our project using Gradle, I've been able to use v1.2.20 without issue. After attempting to update to v1.3.9 in the build.gradle:
// ...
compile group: 'org.opencds.cqf', name: 'cql-engine', version: '1.3.9'
// ...

We get following output:
> Could not resolve all files for configuration ':compileClasspath'.
   > Could not resolve org.opencds.cqf:cql-engine:1.3.9.
     Required by:
         project :
      > Could not resolve org.opencds.cqf:cql-engine:1.3.9.
         > Could not parse POM https://jcenter.bintray.com/org/opencds/cqf/cql-engine/1.3.9/cql-engine-1.3.9.pom
            > Could not find org.opencds.cqf:cql_engine:1.3.9.
              Searched in the following locations:
                - https://jcenter.bintray.com/org/opencds/cqf/cql_engine/1.3.9/cql_engine-1.3.9.pom
                - https://jcenter.bintray.com/org/opencds/cqf/cql_engine/1.3.9/cql_engine-1.3.9.jar
                - https://repo.maven.apache.org/maven2/org/opencds/cqf/cql_engine/1.3.9/cql_engine-1.3.9.pom
                - https://repo.maven.apache.org/maven2/org/opencds/cqf/cql_engine/1.3.9/cql_engine-1.3.9.jar
                - https://oss.sonatype.org/content/repositories/snapshots/org/opencds/cqf/cql_engine/1.3.9/cql_engine-1.3.9.pom
                - https://oss.sonatype.org/content/repositories/snapshots/org/opencds/cqf/cql_engine/1.3.9/cql_engine-1.3.9.jar
      > Could not resolve org.opencds.cqf:cql-engine:1.3.9.
         > Could not parse POM https://repo.maven.apache.org/maven2/org/opencds/cqf/cql-engine/1.3.9/cql-engine-1.3.9.pom
            > Could not find org.opencds.cqf:cql_engine:1.3.9.

Looks like the POM for cql-engine points to  a parent artifact at cql_engine which doesn't exist. I also noticed the POM seems to point to version 1.3.16-SNAPSHOT of cql-to-elm. I'm guessing this should actually point to the release version 1.3.17?

Apologies. There was an issue with the 1.3.9 Release. Would you mind using the 1.3.10-SNAPSHOT?

1.3.10-SNAPSHOT works but seems to turn on all our DEBUG logs... which is not desirable.

You can't override the log4j settings?

Try this:
compile (group: 'org.opencds.cqf', name: 'cql-engine', version: '1.3.10-SNAPSHOT') {
exclude group: 'org.slf4j', module: 'slf4j-log4j12'
}

Just tested overriding with log4j.xml and that works just fine. Which method would be preferable?

Either way we have a solution I suppose :)


Docs: mention that Inoreader API omits enclosures

This is inspired by https://github.com/newsboat/newsboat/issues/252#issuecomment-903343014.
The warning-caption thing adds a large emoji next to the warning.
Without this, Asciidoctor would use the text "WARNING" instead, which
doesn't look as eye-catching as an emoji. The recipe for this is taken
from [1] and [2]. The icon used is U+26A0 WARNING SIGN.

https://docs.asciidoctor.org/asciidoc/latest/blocks/admonitions/#using-emoji-for-admonition-icons
https://github.com/asciidoctor/asciidoctor.org/issues/571

Reviews are welcome! I'll merge this once @der-lyse have taken a look and there are no unaddressed review comments.

Oh yeah, I should've mentioned that the reason I bothered with emoji is that the alternative is to use Font Awesome. We can't override where the font is loaded from, so I opted to use an emoji — this makes the docs usable even offline.
Thanks for the review! Coveralls experiences an outage right now, but I'll merge this nonetheless; docs don't affect coverage :)

Coverage remained the same at 59.277% when pulling 56c135ab6cb7d99577f72cd1ea1271be1f0da226 on feature/mention-lack-of-podcasts-with-inoreader into 4377d448233c575b282257332c60457d096919b6 on master.


Replace quickeck with proptest

replace quickcheck with proptest, and write a few tests

@irevoire, I have fixed the rebase on the #1916 branch instead, I will close this one, since #1916 is based on this.


[BUG] : Port conflict between Homer and plugin for CLN: RTL/c-lightning-Rest

Describe the bug
In the guides, both of these services are setup to use port 4091.  This will cause either nginx or the node process for c-lightning rest plugin documentation to fail depending on which is started first
Location in guide
For Homer, this is established in these places

UFW setting

https://github.com/raspibolt/raspibolt/blame/master/guide/bonus/raspberry-pi/homer.md#L61

Guidance for NGINX

https://github.com/raspibolt/raspibolt/blame/master/guide/bonus/raspberry-pi/homer.md#L61

listen directive in server block of homer-ssl.conf

https://github.com/raspibolt/raspibolt/blame/master/guide/bonus/raspberry-pi/homer.md#L150-151

Guidance for initial testing access in browser

https://github.com/raspibolt/raspibolt/blame/master/guide/bonus/raspberry-pi/homer.md#L443

Guidance for testing access in browser after started as a service

https://github.com/raspibolt/raspibolt/blame/master/guide/bonus/raspberry-pi/homer.md#L496

Listing firewall rules for Homer

https://github.com/raspibolt/raspibolt/blame/master/guide/bonus/raspberry-pi/homer.md#L660

For Core Lightning with the rest plugin for Ride the Lightning

DOCPORT assignment in lightningd config file

https://github.com/raspibolt/raspibolt/blame/master/guide/bonus/lightning/cln.md#L433

And the rest config file

https://github.com/raspibolt/raspibolt/blame/master/guide/bonus/lightning/cln.md#L455

Sample log output

https://github.com/raspibolt/raspibolt/blame/master/guide/bonus/lightning/cln.md#L489

Expected behavior
There should be no port conflicts for any of the guide combinations used.
Each guide should have its own unique port.
Recommend creation of a PORTS.MD file or other central point to quickly reference for what each of the service ports are.
Additional context
To mitigate this, the port can be changed in either Homer or Core Lightning rest plugin.  We resolved in homer-ssl.conf by using a different port.  Port 4873 was chosen (based on 4000 + BIP39 word for "home" = 873).

Recommend creation of a PORTS.MD file or other central point to quickly reference for what each of the service ports are.

Agree!

Should not be closed.

Enabled Wiki setting in repository and started an initial page for used ports: https://github.com/raspibolt/raspibolt/wiki/Ports

I think it would be better to keep this as a doc in git repo instead. Wiki is GitHub specific thing, removes flexibility to potentially move from GitHub to some other platform in future.

A fix is proposed here: https://github.com/raspibolt/raspibolt/pull/1260, but this PR had no review or comment in two months.


[Feature] Add Version Info to BoilR

Unless I am blind, I cannot find what version of BoilR I am running. Can the version be added to the title?

This will be in the next release


Added the document.ready call to the multiple example section. Necess…

This pull request includes a BUG FIX on:
https://select2.github.io/examples.html
The following changes were made:
I noticed on the examples page that the the basic example includes the document.ready() function necessary to make it work. However, on the "multiple" example, it does not. When I first came to select2 to use the tool, I was not very familiar with Javascript and it took me way too long to realize that was the one line I was missing. I made the changes and submitted a pull request because I think it is necessary to help users who may not be as familiar with JavaScript.
Before:

After:

This was not related to a specific ticket. It is something I personally noticed and wanting to change.

Actually, when I look at other jQuery plugins' documentation, they do seem to include the $(document).ready wrapper or something similar.  Take a look at:

https://mottie.github.io/tablesorter/docs/#Getting-Started
http://eonasdan.github.io/bootstrap-datetimepicker/#minimum-setup

Maybe we should include this after all.

@alexweissman Now that I have a few years of Javascript experience under my belt, I laugh at the fact that I needed help with this. However, I still agree and think it would be good to have for people who are starting out.

Haha yep, sometimes it's harder to see where you came from, once you're on the other side.
I've updated the documentation: https://select2.org/getting-started/basic-usage


CREATE TABLE PPGen

On the PPGen examples there are some snippets of syntax examples that contain table properties such as SQLPP_DROP_IF_EXISTS and SQLPP_CREATE_IF_NOT_EXISTS. However, these don't work. Seeing as PPgen was worked on in 2016 is it ever going to be added?
Perhaps handy to ping the creator @niXman

Hi,
Read please: https://github.com/rbock/sqlpp11/issues/63
I'm sorry, but at the moment I can't work for free because I was left without work...

I see, thank you. That's awful to hear. If it turns out this feature is critical for me I'll let you know and support you through donations to add it.

I added table creation to the wish list I am compiling. Closing this ticket.


#2591 address browser_ttl.default value issue of not being able to be set to 0

Summary
Hi there, this is a possible resolution to issue #2591.
I'm unable to run the acceptance tests locally, so any guidance would be greatly appreciated!

@iveelsm can you clarify the expected behaviour here and if this was intentional?

@jacobbednarz This was intentional. I will surface it more on the issue as well, but this is the underlying implementation leaking through here. The general problem here is that a Browser TTL of "Override Origin" set to 0 actually translates on the backend to "Respect Origin".
I have a new feature for Browser Bypass which is rolling out soon, but we should not allow people to specify 0 here until the legacy API contracts are sufficiently wrangled.

Thanks for clarifying @iveelsm

Sure thing @nialdaly! Thank you for the PR! This is just one of those unfortunate things where our API internally isn't quite as logical as we need it to be and requires a lot of backend work before this would work.

That makes sense, thanks for the additional context!


#No such module 'Toast_Swift'

Hi,
I am using this in Swift 4 and XCode 9.2.
While Archiving showing error "No such module 'Toast_Swift'".
But, while running/building project no error comes.
Please check bellow screenshot for more details and please help me out in this.
Thanks....

Same issue here!

Same problem here

+1

+1

+1

watch out your Swift & xcode version
the document says :
Version 4.x.x requires Swift 4.2 and Xcode 10.
Version 3.x.x requires Swift 4 and Xcode 9.
so if you just Swift 4 , you should install  toast version 3.x.x

+1

If you install with cocoa pod, you have to add the pod line in the podfile , import the module,  comment that line and close xcode before to run the pod install command.
After installation, open xcode and decomment the import line.

no such module 'Toast_Swift'
import Toast_Swift
^
** BUILD FAILED **

The following build commands failed:
	CompileSwift normal armv7
	CompileSwiftSources normal arm64 com.apple.xcode.tools.swift.compiler
	CompileSwift normal arm64
(3 failures)```

This is no need to import it. It is developed as an extension of UIView. Simply call view.makeToast().

Its working with v5.0.0


Define logs in packages' syscfg files

Define logs in packages' syscfg files
Defining logs in syscfg files provides a few benefits:

Ability to set log level per module at build time.  Setting a global log level of 0 (LOG_LEVEL=0) might produce an image that is too big.  Instead, we can enable debug logging only for the modules we are interested in.

Easier to visualize system log configuration (see below).

Log modules can be remapped at build time in case of conflicts.

The following procedure was used for choosing module and level syscfg names:

If the package already defines these settings, keep them unchanged.
Otherwise, define:

<package-name>_LOG_MOD
<package-name>_LOG_LVL

To see the system-wide log configuration, use either of these commands:
newt target logcfg brief <target-name>
newt target logcfg show <target-name>

Example output:
newt target logcfg brief slinky-nordic_pca10056

Brief log config for targets/slinky-nordic_pca10056:
           LOG | MODULE   | LEVEL
---------------+----------+--------------
      DFLT_LOG | 0        | 1 (INFO)
    IMGMGR_LOG | 176      | 0 (DEBUG)

newt target logcfg show slinky-nordic_pca10056

Log config for targets/slinky-nordic_pca10056:
DFLT_LOG:
    Package: @apache-mynewt-core/sys/log/common
    Module:  0                [DFLT_LOG_MOD]
    Level:   1 (INFO)         [DFLT_LOG_LVL]

IMGMGR_LOG:
    Package: @apache-mynewt-core/mgmt/imgmgr
    Module:  176              [IMGMGR_LOG_MOD]
    Level:   0 (DEBUG)        [IMGMGR_LOG_LVL]

Thanks for the reviews, all.
@kasjer, I have added the missing periods.
Also, I noticed there were two packages I missed:

hw/drivers/sensors/dps368
sys/mfg


Formatting on an existing date time value not working

Formatting date time control using a date time object. (e.g. 08/07/2015 13:05)
using moment with a locale of en_gb and a format setting of 'L LT'
js to initialise component..
$('#id_start_datetimepicker').datetimepicker({
defaultDate: 'now',
showTodayButton: true,
format: 'L LT'
});
When creating a new form record, the date time formatting is correct (DD/MM/YYYY HH:mm) and the picker working as expected. However when editing a record, the stored value (2015-07-08 13:05) flashes briefly in the picker controls input edit, its unformatted and then the edit controls input clears showing no value.
Any ideas very much appriciated

check the extraFormats option. It will allow the input to be valid in several formats

By adding the additional extraFormats setting appears to work.
$('#id_start_datetimepicker').datetimepicker({
defaultDate: 'now',
showTodayButton: true,
format: 'L LT',
extraFormats: [ 'YYYY-MM-DD HH:mm' ]
});
Many thanks