-
Notifications
You must be signed in to change notification settings - Fork 3
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
DATAGO-75198: Dynamic config for configpush #185
DATAGO-75198: Dynamic config for configpush #185
Conversation
…98-configpush-with-dynamic-config
…98-configpush-with-dynamic-config
<dependency> | ||
<groupId>org.springframework.boot</groupId> | ||
<artifactId>spring-boot-starter-validation</artifactId> | ||
</dependency> |
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.
So that we can use Constraint validations such as @NotBlank
@NotNull
etc.
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.
public class EventBrokerResourceConfiguration extends ResourceConfiguration { | ||
@NotBlank | ||
private String id; | ||
private String brokerType; | ||
@NotBlank | ||
private String name; | ||
private List<EventBrokerConnectionConfiguration> connections; | ||
@NotEmpty | ||
private List<@Valid EventBrokerConnectionConfiguration> connections; | ||
@NotNull | ||
private ResourceConfigurationType resourceConfigurationType; |
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.
All the model classes are updated to use Constraint Validation. This is much cleaner and IMO provides clear understanding of the validation requirements
public class ValidationConfiguration { | ||
|
||
@Bean | ||
public static LocalValidatorFactoryBean defaultValidator() { | ||
LocalValidatorFactoryBean factoryBean = new LocalValidatorFactoryBean(); | ||
MessageInterpolatorFactory interpolatorFactory = new MessageInterpolatorFactory(); | ||
factoryBean.setMessageInterpolator(interpolatorFactory.getObject()); | ||
return factoryBean; | ||
} | ||
|
||
@Bean | ||
public static MethodValidationPostProcessor methodValidationPostProcessor(Environment environment, Validator validator) { | ||
MethodValidationPostProcessor processor = new MethodValidationPostProcessor(); | ||
boolean proxyTargetClass = environment.getProperty("spring.aop.proxy-target-class", Boolean.class, true); | ||
processor.setProxyTargetClass(proxyTargetClass); | ||
processor.setValidator(validator); | ||
return processor; | ||
} | ||
} |
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.
So that we can use Constraint validation in model classes
log.error("Error while processing inbound message from queue for mopMessageSubclass: {}", mopMessageSubclass); | ||
throw new IllegalArgumentException(e); | ||
if (processor != null && message != null) { | ||
log.error("Error while processing inbound message from queue for mopMessageSubclass: {}", mopMessageSubclass); | ||
processor.onFailure(e, processor.castToMessageClass(message)); | ||
} else { | ||
log.error("Unsupported message and/or processor encountered. Skipping processing", e); | ||
} | ||
|
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.
Discussed with @mynecker. We MUST not throw exception from the message receiver thread, rather we should handle the exception. I already implemented the processor.onFailure
for ConfigPushMessageProcessor. We SHOULD do the same thing for scan
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.
processor.onFailure(e, processor.castToMessageClass(message));
exceptions that might be thrown within the onFailure(...)
method should be handled, too. Logging the exception should be ok
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
@Getter | ||
private PersistentMessageReceiver persistentMessageReceiver; |
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.
Use Lombok instead of writing the Getter
@Override | ||
public void onFailure(Exception e, ScanCommandMessage message) { | ||
log.debug("Requires implementation"); | ||
} |
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.
We must implement this for Scan.
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.
That's coming up next? Can we potentially hit this after the PR is merged? Seems more like a warning at least.
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.
@CameronRushton already implemented in another PR following this one
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.
Minor non-blocking comments
@Test | ||
void testMapToMessagingServiceEvent() { |
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.
⛏️ Good candidate for soft assertions in this test
validateConstraintViolationException(invalidResource, Set.of("mapToMessagingServiceEvent.eventBrokerResource.name: must not be blank", | ||
"mapToMessagingServiceEvent.eventBrokerResource.id: must not be blank", "mapToMessagingServiceEvent.eventBrokerResource.connections: must" + | ||
" not be empty")); |
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 path includes the method name too? Weird. There must be config that removes that part. Do we care though? Probably not.
@Override | ||
public void onFailure(Exception e, ScanCommandMessage message) { | ||
log.debug("Requires implementation"); | ||
} |
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.
That's coming up next? Can we potentially hit this after the PR is merged? Seems more like a warning at least.
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.
Approved with a question comment.
private String id; | ||
private String brokerType; |
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 was this removed?
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.
This is not needed. We use ResourceConfigurationType
enum instead
What is the purpose of this change?
Asks of https://sol-jira.atlassian.net/browse/DATAGO-75198 (EMA side of things)
How was this change implemented?
Java code change
How was this change tested?
Is there anything the reviewers should focus on/be aware of?