Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Added lenientValidation support to REMReM generate #128

Merged
merged 5 commits into from
Aug 14, 2020

Conversation

raja-maragani
Copy link

@raja-maragani raja-maragani commented Jul 17, 2020

Applicable Issues

eiffel-community/eiffel-remrem-generate#171

Description of the Change

Added Lenient Validation support to REMReM Semantics protocol, The Lenient Validation will perform the only mandatory field validation and non-mandatory validation failures will place in Eiffel message as a new property(remremGenerateFailures)

Alternate Designs

Benefits

The REMReM generate validation will not fail on non-fetal Eiffel message field issues. This feature is an option to the user, the user can decide the enable/disable the Lenient Validation. By default it is disabled.

Possible Drawbacks

Sign-off

Developer's Certificate of Origin 1.1

By making a contribution to this project, I certify that:

(a) The contribution was created in whole or in part by me and I
have the right to submit it under the open source license
indicated in the file; or

(b) The contribution is based upon previous work that, to the best
of my knowledge, is covered under an appropriate open source
license and I have the right under that license to submit that
work with modifications, whether created in whole or in part
by me, under the same open source license (unless I am
permitted to submit under a different license), as indicated
in the file; or

(c) The contribution was provided directly to me by some other
person who certified (a), (b) or (c) and I have not modified
it.

(d) I understand and agree that this project and the contribution
are public and that a record of the contribution (including all
personal information I submit with it, including my sign-off) is
maintained indefinitely and may be redistributed consistent with
this project or the open source license(s) involved.

Signed-off-by: @raja-maragani

Copy link
Member

@magnusbaeck magnusbaeck left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • The PR doesn't reference any issue or anything else that explains why this change is being made. It's not clear to me why it would be useful to only enable validation on mandatory fields (because that's what lenient validation means, right?). Why would we want to expose a feature that makes it easy for users to produce invalid messages?
  • The documentation should be updated to explain the lenient validation feature and exactly what it means.

@raja-maragani
Copy link
Author

  • The PR doesn't reference any issue or anything else that explains why this change is being made. It's not clear to me why it would be useful to only enable validation on mandatory fields (because that's what lenient validation means, right?). Why would we want to expose a feature that makes it easy for users to produce invalid messages?
  • The documentation should be updated to explain the lenient validation feature and exactly what it means.

Created an issue for this change: eiffel-community/eiffel-remrem-generate#171
I will update the wiki also once PR's approved on this feature.

@raja-maragani
Copy link
Author

@magnusbaeck added code changes for your comments.

@raja-maragani
Copy link
Author

@magnusbaeck added code changes for your comments.

@magnusbaeck do you have time to review this PR?

@magnusbaeck
Copy link
Member

I was waiting for a response to my questions in eiffel-community/eiffel-remrem-generate#171, but I've been away for the past couple of days so I haven't been able to digest what you wrote.

@magnusbaeck
Copy link
Member

I've posted a comment in the issue.

I will update the wiki also once PR's approved on this feature.

The wiki contents is stored in the wiki subdirectory in the repository, so why not update the documentation in this PR?

@raja-maragani
Copy link
Author

I've posted a comment in the issue.

I will update the wiki also once PR's approved on this feature.

The wiki contents is stored in the wiki subdirectory in the repository, so why not update the documentation in this PR?

Hi, later I identified the documentation part.
I updated documentation also.
Documentation changes are available in the below links.
https://github.com/raja-maragani/eiffel-remrem-generate/blob/master/wiki/markdown/usage/generate-cli.md
https://github.com/eiffel-community/eiffel-remrem-generate/blob/509510486c00c7c1d607af13da66fb6e38928381/wiki/markdown/usage/lenientvalidation.md

@Umadevi-Kapu
Copy link
Contributor

+1

@raja-maragani
Copy link
Author

I got 2 approvals.
@magnusbaeck I hope requested changes/clarifications are done, could you please check once.
Thanks in advance.

@magnusbaeck
Copy link
Member

I hope requested changes/clarifications are done, could you please check once.

I'll have a look during Monday.

}

@Override
public String generateMsg(String msgType, JsonObject bodyJson, Boolean lenientValidation) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Didn't we agree to not call this lenientValidation?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

from our latest discussion we are using two param names i.e
Config param - lenientValidationEnabledToUsers
Rest Param - okToLeaveOutInvalidOptionalFields
Naming still we are using the lenient validation

log.debug(message, e);
throw new EiffelValidationException(message, e);
}
}
private void handleErrorReport(JsonObject jsonObjectInput, ProcessingReport report) throws EiffelValidationException {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Blank line between methods please (here and in several other places in the file).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

if (!report.isSuccess()) {
log.error("Eiffel message validation failed");
log.error(jsonObjectInput.toString());
throw new EiffelValidationException(getErrorsList(report));
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The strategy for error logging and exception handling seems haphazard. Logging and throwing an exception from the same place usually isn't a great idea (you're likely to log duplicate information, plus it's makes the code verbose). Here you're logging the input message at the error level with no information about the error itself, throwing an exception with the errors, which is caught on line 113 and logged at the debug level, then re-raised as a new exception that wraps the original exception. Perhaps the exception from line 116 is also logged somewhere?

Wouldn't it be better to raise an exception that contains all relevant information and log that in one place?

But I realize most of this is old code that shouldn't be modified in this PR.

Also, when logging, please don't call the logger multiple times for what's effectively a single message (like the case with lines 121-122).

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I agree loggers are not required here, we are raising the exception with validation errors.

private static final String SLASH = "/";
private static final String DOT = ".";
private static final String REMREM_GENERATE_FAILURES = "remremGenerateFailures";
private static final String PATH2 = "path";
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why PATH2 and not PATH?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

object.addProperty(PATH2, path);
return object;
}
private JsonObject addRemremGenerateFailuresToCustomData(JsonObject inputJson, JsonArray remremGenerateFailures) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since you're mutating the input JsonObject, why not make this a void method? Returning a JsonObject reference gives the impression that the input JsonObject is left untouched.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes but I directly return the output and inputJson is formed while calling this method.

Comment on lines +162 to +172
private String getPath(String errorPath) {
final Pattern pattern = Pattern.compile(REGEX_PATH, Pattern.MULTILINE);
final Matcher matcher = pattern.matcher(errorPath);
while (matcher.find()) {
if(matcher.group(0).length()>1) {
errorPath = errorPath.substring(0, errorPath.indexOf(matcher.group(0))+matcher.group(0).length());
errorPath = errorPath.replaceAll(matcher.group(0), "["+matcher.group(0).substring(1)+"]");
}
}
return "$" + errorPath.replace(SLASH, DOT);
}
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No tests for this code?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its private method and we don't have the unit tests for private methods. but we added unit tests for validations with lenient validations.

@raja-maragani
Copy link
Author

If no other comments, I will merge this PR.

@raja-maragani raja-maragani merged commit 07d8ab4 into eiffel-community:master Aug 14, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants