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

java: Can't satisfy List<Object> parameters in Cfn*Props.Builder methods #2013

Closed
mbulman opened this issue Mar 14, 2019 · 1 comment · Fixed by aws/jsii#919
Closed

java: Can't satisfy List<Object> parameters in Cfn*Props.Builder methods #2013

mbulman opened this issue Mar 14, 2019 · 1 comment · Fixed by aws/jsii#919
Assignees
Labels
bug This issue is a bug. language/java Related to Java bindings

Comments

@mbulman
Copy link

mbulman commented Mar 14, 2019

When creating a Cfn*Props builder, methods that accept a List<Object> parameter don't seem to behave properly (or I'm doing something wrong).

As an example, when setting up an API Gateway Usage Plan, I want the resulting template to look something like:

UsagePlan:
    Type: AWS::ApiGateway::UsagePlan
    Properties:
        UsagePlanName: MyUsagePlan
        ApiStages:
            - Stage: Foo
              ApiId: Bar

The property I have trouble with is ApiStages, which is a list of objects (Maps, specifically). My first attempt was the following Java code:

Map<String, String> stage = ImmutableMap.of(
        "ApiId", "Foo"
        "Stage", "Bar");

ArrayList<Object> stages = new ArrayList<Object>();
stages.add(stage);

CfnUsagePlan usagePlan = new CfnUsagePlan(this, "UsagePlan", CfnUsagePlanProps.builder()
        .withUsagePlanName("MyUsagePlan")
        .withApiStages(stages)
        .build());

...but this yields:

UsagePlan:
    Type: AWS::ApiGateway::UsagePlan
    Properties:
        UsagePlanName: MyUsagePlan
        ApiStages:
            - {}

If I use addPropertyOverride instead, I am able to get the expected result:

Map<String, String> stage = ImmutableMap.of(
        "ApiId", "Foo"
        "Stage", "Bar");

ArrayList<Object> stages = new ArrayList<Object>();
stages.add(stage);

CfnUsagePlan usagePlan = new CfnUsagePlan(this, "UsagePlan", CfnUsagePlanProps.builder()
        .withUsagePlanName("MyUsagePlan")
        .build());
        
usagePlan.addPropertyOverride("ApiStages", stages);

I've seen this behavior on multiple Cfn*Props Builders that expect List types, so it isn't specific to CfnUsagePlan.

Let me know what other info or things I can do that would be helpful. Thanks

@SomayaB SomayaB added guidance Question that needs advice or information. @aws-cdk/aws-apigateway Related to Amazon API Gateway needs-triage This issue or PR still needs to be triaged. labels Sep 9, 2019
@nija-at
Copy link
Contributor

nija-at commented Sep 25, 2019

This is a bug on our side, specifically in jsii. It turns out jsii is not properly identifying the types of nested property bags and is silently ignoring them.

We've recently identified this from a similar Python issue. Here's the link to the JSII issue for more details and which will track to fix this - aws/jsii#822


Pasting a full CDK Java app where I was able to reproduce this bug -

package com.myorg;

import software.amazon.awscdk.core.App;
import software.amazon.awscdk.core.Stack;
import software.amazon.awscdk.services.apigateway.CfnUsagePlan;
import software.amazon.awscdk.services.apigateway.CfnUsagePlanProps;

import java.util.List;
import java.util.ArrayList;
import java.util.Map;
import java.util.HashMap;

public class HelloApp {
    public static void main(final String argv[]) {
        App app = new App();

        Map<String, String> stage = new HashMap<>();
        stage.put("key1", "value1");
        List<Object> stages = new ArrayList<>();
        stages.add(stage);
        Stack stack = new Stack(app, "mystack", null);
        CfnUsagePlanProps props = CfnUsagePlanProps.builder().usagePlanName("myusageplan").apiStages(stages).build();
        new CfnUsagePlan(stack, "myusageplan", props);

        // required until https://github.com/aws/jsii/issues/456 is resolved
        app.synth();
    }
}

@nija-at nija-at assigned RomainMuller and unassigned nija-at Sep 25, 2019
@nija-at nija-at added bug This issue is a bug. language/java Related to Java bindings and removed guidance Question that needs advice or information. @aws-cdk/aws-apigateway Related to Amazon API Gateway needs-triage This issue or PR still needs to be triaged. labels Sep 25, 2019
RomainMuller added a commit to aws/jsii that referenced this issue Oct 30, 2019
When deserializing structures in a Union context, the Kernel used to try
options in an arbitrary order (actually - the declaration order which
often is alphanumerically sorted). In addition, it would ignore any
additional property encountered silently.

In cases where several of the union's possibilities had overlapping
required properties, the first attempted option would succeed, even if a
subsequent option would have consumed more properties. A pathologic case
of this is when the first candidate is a type with only optional
properties; as such a type would *always* successfully deserialize
anything, possibly ignoring all properties.

In order to address this, the `structs` can now be passed into the
Kernel by wrapping the object in a decorator box:
```js
{
  "$jsii.struct": {
    "fqn": "fully.qualified.struct.TypeName",
    "data": {
      /* the actual data included in the struct instance */
    }
  }
}
```

This enables "native" languages to correctly communicate the intended
type to the Kernel, so it can make an appropriate deserialization
decision.

The encoding of structs from the Kernel to "native" languages has not
changed: those are still passed by-reference in order to maximize the
compatibility; and to avoid undeterministic behavior in case where union
of structs are returned.

Fixes #822
Fixes aws/aws-cdk#3917
Fixes aws/aws-cdk#2013
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug This issue is a bug. language/java Related to Java bindings
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants