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

DATAGO-75198: Dynamic config for configpush #185

Merged

Conversation

rudraneel-chakraborty
Copy link
Contributor

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?

...

Comment on lines +100 to +103
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-validation</artifactId>
</dependency>
Copy link
Contributor Author

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.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Comment on lines 12 to 20
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;
Copy link
Contributor Author

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

Comment on lines +12 to +30
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;
}
}
Copy link
Contributor Author

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

Comment on lines 69 to 79
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);
}

Copy link
Contributor Author

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

Copy link
Contributor

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Done

Comment on lines +35 to 36
@Getter
private PersistentMessageReceiver persistentMessageReceiver;
Copy link
Contributor Author

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

Comment on lines +76 to +79
@Override
public void onFailure(Exception e, ScanCommandMessage message) {
log.debug("Requires implementation");
}
Copy link
Contributor Author

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.

Copy link
Collaborator

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.

Copy link
Contributor

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

@rudraneel-chakraborty rudraneel-chakraborty marked this pull request as ready for review June 20, 2024 00:13
Copy link
Collaborator

@CameronRushton CameronRushton left a 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

Comment on lines +39 to +40
@Test
void testMapToMessagingServiceEvent() {
Copy link
Collaborator

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

Comment on lines +104 to +106
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"));
Copy link
Collaborator

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.

Comment on lines +76 to +79
@Override
public void onFailure(Exception e, ScanCommandMessage message) {
log.debug("Requires implementation");
}
Copy link
Collaborator

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.

Copy link
Collaborator

@moodiRealist moodiRealist left a 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;
Copy link
Collaborator

Choose a reason for hiding this comment

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

why was this removed?

Copy link
Contributor Author

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

Copy link

SonarQube Quality Gate

Quality Gate failed

Failed condition 58.0% 58.0% Coverage on New Code (is less than 80%)

See analysis details on SonarQube

@rudraneel-chakraborty rudraneel-chakraborty merged commit 2ebd005 into main Jun 27, 2024
5 of 6 checks passed
@rudraneel-chakraborty rudraneel-chakraborty deleted the DATAGO-75198-configpush-with-dynamic-config branch June 27, 2024 14:00
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