-
Notifications
You must be signed in to change notification settings - Fork 55
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
Conversation
There was a problem hiding this 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.
src/test/java/com/ericsson/eiffel/remrem/semantics/ServiceTest.java
Outdated
Show resolved
Hide resolved
src/test/java/com/ericsson/eiffel/remrem/semantics/ServiceTest.java
Outdated
Show resolved
Hide resolved
src/main/java/com/ericsson/eiffel/remrem/semantics/SemanticsService.java
Show resolved
Hide resolved
src/main/java/com/ericsson/eiffel/remrem/semantics/SemanticsService.java
Outdated
Show resolved
Hide resolved
src/main/java/com/ericsson/eiffel/remrem/semantics/validator/EiffelValidator.java
Outdated
Show resolved
Hide resolved
src/main/java/com/ericsson/eiffel/remrem/semantics/validator/EiffelValidator.java
Outdated
Show resolved
Hide resolved
Created an issue for this change: eiffel-community/eiffel-remrem-generate#171 |
@magnusbaeck added code changes for your comments. |
src/main/java/com/ericsson/eiffel/remrem/semantics/validator/EiffelValidator.java
Outdated
Show resolved
Hide resolved
@magnusbaeck do you have time to review this PR? |
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. |
I've posted a comment in the issue.
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. |
+1 |
I got 2 approvals. |
I'll have a look during Monday. |
} | ||
|
||
@Override | ||
public String generateMsg(String msgType, JsonObject bodyJson, Boolean lenientValidation) { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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)); |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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"; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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) { |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
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); | ||
} |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
If no other comments, I will merge this PR. |
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