Extracting existing JMESPath runtime to a separate class #5155
Conversation
…used by waiters and other components
|
| @@ -104,7 +104,8 @@ private static void configurePackageName(Metadata metadata, | |||
| .withPaginatorsPackageName(namingStrategy.getPaginatorsPackageName(service)) | |||
| .withWaitersPackageName(namingStrategy.getWaitersPackageName(service)) | |||
| .withEndpointRulesPackageName(namingStrategy.getEndpointRulesPackageName(service)) | |||
| .withAuthSchemePackageName(namingStrategy.getAuthSchemePackageName(service)); | |||
| .withAuthSchemePackageName(namingStrategy.getAuthSchemePackageName(service)) | |||
| .withJPathPackageName(namingStrategy.getJPathPackageName(service)); | |||
There was a problem hiding this comment.
Should we use the full name JmesPath to be more clear?
There was a problem hiding this comment.
I explicitly avoided JmesPath since there has been a lot of discussion around minified versions, not calling that subset JmesPath etc. However, after working with the implementation in Java SDK that distinction has faded - I think the subset will be handled at a model level instead. So if consensus is JmesPath I'm fine with that.
| import software.amazon.awssdk.utils.IoUtils; | ||
|
|
||
| public final class JPathRuntimeGeneratorTask extends BaseGeneratorTasks { | ||
| public static final String RUNTIME_CLASS_NAME = "JPathRuntime"; |
There was a problem hiding this comment.
Same here, JmesPathRuntime?
| import software.amazon.awssdk.utils.ToString; | ||
|
|
||
| @SdkInternalApi | ||
| public final class JPathRuntime { |
There was a problem hiding this comment.
Are there any changes between JmesPathRuntime and WaitersRuntime? If so, could you show me the diff?
There was a problem hiding this comment.
No, there are no changes in this PR
| @@ -57,6 +59,9 @@ protected List<GeneratorTask> createTasks() throws Exception { | |||
| tasks.add(generateDefaultProvider()); | |||
| tasks.add(new RulesEngineRuntimeGeneratorTask(generatorTaskParams)); | |||
| } | |||
| if (shouldGenerateJPathRuntime()) { | |||
There was a problem hiding this comment.
What are the demerits of always loading the JMESPathRuntime class? Additionally, for waiters, what if we create a class that extends JMESPathRuntime and adds methods only specific to waiters?"
There was a problem hiding this comment.
The demerits of always loading JMESPathRuntime is that there are almost 400 services but only 80 of them use waiters.
I don't think the approach of adding methods that are only used in waiters is worth it, because it's just a few hundred lines. It's better to keep the language intact and it will be hard to keep track of different subsets used for different purposes.
cenedhryn
merged commit 0323b8f
into
feature/StringArrayEndpointParams
that can be used by waiters and other components
Motivation and Context
The new operation context params for auth and endpoint params require the usage of a subset of JMESPath in order to specify a value or set of values in the request.
We already have a JMESPath parser at the codegen level, and a Java class that represents a JMESPath expression in the
WaitersRuntime.javaclass that's copied to services during codegen. This PR extracts that into a separate runtime.Modifications
WaitersRuntime.javacustomization.configcontains an eligible endpoint parameter (part of this feature in previous PR)Considerations