-
Notifications
You must be signed in to change notification settings - Fork 319
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
[DONOT MERGE] showing generated modules #1364
Conversation
<dependency> | ||
<groupId>com.google.cloud</groupId> | ||
<artifactId>google-cloud-language</artifactId> | ||
<version>2.4.1</version> |
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.
I would expect this version to be dependency managed by the parent that imports the libraries-bom
.
...rc/main/java/com/google/cloud/language/v1/spring/LanguageServiceSpringAutoConfiguration.java
Show resolved
Hide resolved
@EnableConfigurationProperties({LanguageServiceSpringProperties.class, GlobalProperties.class}) | ||
public class LanguageServiceSpringAutoConfiguration { | ||
private final LanguageServiceSpringProperties clientProperties; | ||
private final GlobalProperties globalProperties; |
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.
What are these global properties? I can't find this class.
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 class will be brought by #1308
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.
If we are going to have a handwritten shared class, it makes more sense for us to move away from the using the folder name generated
.
@Qualifier("defaultLanguageServiceTransportChannelProvider") | ||
TransportChannelProvider defaultTransportChannelProvider) | ||
throws IOException { | ||
LanguageServiceSettings.Builder clientSettingsBuilder = |
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 not make LanguageServiceSettings
its own bean so that it can be overwritten, and then have a separate simple method that takes in LanguageServiceSettings
and creates the LanguageServiceClient
?
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 a good idea. I'll add to our todo list.
LanguageServiceSettings.defaultHttpJsonTransportProviderBuilder().build()); | ||
LOGGER.info("Using HTTP transport channel"); | ||
} | ||
RetrySettings.Builder analyzeSentimentRetrySettingBuilder = |
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.
analyzeSentimentRetrySettings
could also be its own bean to allow customization. One thing to remember is that Spring Boot allows you to configure the app via properties, and also by overwriting beans. For the overwriting beans route, you want to make the beans as granular as possible, for maximum flexiblity.
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.
Are you suggesting to have an RetrySetting bean for each RPC? If it has additional benefit other than readability, I think we should do it too.
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. For example, it also allows you to use the same retry settings for all RPCs.
private String quotaProjectId; | ||
private Integer executorThreadCount; | ||
private boolean useRest = false; | ||
private Duration analyzeSentimentInitialRetryDelay; |
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.
As mentioned offline, a lot of duplication here can probably be avoided by creating an object for retry settings.
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.
A helper object sounds like a good idea.
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.
LGTM, although you were not planning to merge it in :)
private String quotaProjectId; | ||
private Integer executorThreadCount; | ||
private boolean useRest = false; | ||
private Duration analyzeSentimentInitialRetryDelay; |
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.
A helper object sounds like a good idea.
.setRetrySettings(classifyTextRetrySettingBuilder.build()); | ||
RetrySettings.Builder annotateTextRetrySettingBuilder = | ||
clientSettingsBuilder.annotateTextSettings().getRetrySettings().toBuilder(); | ||
if (this.clientProperties.getAnnotateTextInitialRetryDelay() != null) { |
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.
@meltsufin this is probably the type of code for which the duplication discussion came up.
IMHO, there are two reasons people read code: one is to modify the code, and the other is to troubleshoot. For the first one one (code modification), there is an obvious benefit to avoiding code duplication ("keeping it DRY") -- if one piece of duplicated code is changed and the other is not, it will lead to bugs. However, this scenario does not apply to autogenerated code, per @blakeli0 's point.
The second scenario -- troubleshooting -- actually benefits from this type of code duplication, as the users can identify the exact set of properties that caused them issues. If duplication were avoided, a loop is needed, so users will then need a conditional breakpoint, which is a bit harder.
"description": "Auto-configure Google Cloud language/LanguageService components.", | ||
"defaultValue": true | ||
} | ||
] |
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.
There are probably more options you'd want to enable IDE autocompletion for.
LOGGER.info( | ||
"Background executor thread count is " + this.clientProperties.getExecutorThreadCount()); | ||
} | ||
if (this.clientProperties.getUseRest()) { |
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.
I probably missed this earlier, we should use newHttpJsonBuilder
in here instead of only setting the transport, newHttpJsonBuilder
does a few other things like setting http specific headers. We can move this logic to the top of this method to something like
if (this.clientProperties.getUseRest()) {
clientSettingsBuilder = LanguageServiceSettings.newHttpJsonBuilder();
} else {
clientSettingsBuilder = LanguageServiceSettings.newBuilder();
}
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.
Thank you for catching this! Put together a quick PoC to note the changes needed, and will be updating the generator code correspondingly.
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.
Updated generator code in googleapis/sdk-platform-java#1227.
Please head over to #1449 for a newer version to review. Closing this one. |
This is a draft showing the generated modules language and vision.
global-autoconfig-properties
module pending on feat(autoconfig): autoconfig module #1308From live session:
- review folder/pom structure decisions: do not leak "generated" into maven coordinates Module name changes structure change #1394
spring-cloud-gcp-dependencies
, possibly as a separate BOM- Add Javadoc to each properties (so Spring can pick up as hints) @emmileaf in fix(spring): add javadoc comments for properties googleapis/sdk-platform-java#1171
- Change “@generated by (gapic-generator-java)” to something more Spring specific fix(spring): change @Generated description to spring specific. googleapis/sdk-platform-java#1103
- Revisit logging strategy in generated code @diegomarquezp
- RetrySetting object - refactored in fix(spring): refactor retry settings to service and method-level nested properties googleapis/sdk-platform-java#1143