ardielle/ardielle-tools

ardielle-tools's Issues

Generating TypeScript

Have you already considered code generation for TypeScript? If that happened, I thought it would be a piece that would lead to a runtime for TypeScript or JavaScript.

gRPC interop

It would be very nice to have interop with gRPC - import & export from proto3 descriptions of types and RPC.

go model codegen produces unexpected behavior for enums

The generated SymbolSet() method on enums returns an array of the symbol names, indexed starting at 1 (the 0'th entry is the empty string). Should just be the set, without that empty string.

This may imply that the enum values should start at 0, not 1.

This would be an incompatible change.

client go-generator should allow adding custom headers to outgoing requests

Currently, the generator for client.go writes code that initializes outgoing HTTP headers to an empty map, and adds only what it needs internally for its specific purposes (e.g. Credentials header/value and If-None-Match ETag type headers)

It would be good to allow custom headers to be added to each client on a per-request basis.

Recursively typed struct fields must be optional

Otherwise an infinite structure will be described.

i.e. this is invalid:

type Node Struct {
  Node left;
  String value;
  Node right;
}

but this is valid:

type Node Struct {
  Node left (optional);
  String value;
  Node right (optional);
}

java client - expose close method for Client

generated java client class does not expose a close method for javax.ws.rs.client object it creates.

support http status code 429 (rfc6585)

we want to add some rate limiting support into our server and return the expected 429 status code. currently rdl generator does not support this code as one of the expected exceptions.

go-client generates invalid Go code for scalar return types

i.e. Bool, String, return types, it tried to return nil, not the zero value of the data, in error returns.

try this:

resource Bool GET "/" { }

The generated go client code doesn't compile:
"...cannot use nil as type bool in return argument"

unable to alias bytes

$ cat x.rdl
type Content Bytes;

type Foo Struct {
	Content Bar;
}

resource Foo GET "/" {
}
$ rdl -ps generate go-model x.rdl
$ go build
./x_schema.go:16: undefined: rdl.NewBytesTypeBuilder

[markdown generator] wrong anchor.

please refer to a simple rdl and the generated markdown https://gist.github.com/geekybaiyi/1a1b214ea6403e6c6981c81b898ff2e0

Under Types -> Users, it refers to the type User. However it links to the anchor on the Resource that returns User, not link to the User type.
However wouldn't it makes more sense to link to the User type in this context ?

Go: Bad codegen when using colliding method + type APIs

Use case:

I had a resource resource Foo GET /bar/baz. I also want resource Foo Get /something/else (for backwards compatibility).

To do that I name one of the resources different from the generated name. Problem is that schema stills has 2 variables named mGetFoo and does not compile. The member variables in the schema should be named using the resource name if available and not always use the generated name.

Comments in markdown syntax

Is it possible to support all standard markdown syntax in the comments ?
so when we generate the RDLs to markdown, those comments and formats can be preserved.
For example: listing, tables.

thanks!

java client - clash with Entity name if rdl includes Entity

our server rdl already includes a struct called Entity. When the client code is generated, the javax.ws.rs.client.Entity clashes with our Entity object. We'd like to update the code generated to use:

    Response response = invocationBuilder.post(javax.ws.rs.client.Entity.entity(detail, "application/json"));

instead of just Entity.entity.

Array<Float32> resolves to List<float> in java causing "Type argument cannot be of primitive type" error

ex:
rdl definistion:

type values Array<Float32> 

can only resolve to  

public List<float> values 

instead of   

public List<Float> values

which will have error of  "Type argument cannot be of primitive type" in java
Please help resolve this issue.

Thanks,
Liang

Bad codegen for HEAD verb

Given the following resource definition, the code generated for the Go client does not compile and the code generated for the server returns a message body.

//
// Determines whether record exists for a given ID.
//
resource Any HEAD "/status/{id}" {
  Int64 id;
  expected OK; // Matching entry found
  exceptions {
    ResourceError NOT_FOUND; // No entry found
  }
}

The generated server code can be forced to return no message body if the expected result is changed to NO_CONTENT. However the client code still does not compile in this case. The only way to get generated code with behavior similar to that expected with the HEAD verb is to change the verb to GET and the expected result to NO_CONTENT.

rdl-gen-swagger: Optional field should not put into required list

main.go:297
if f.Optional {
required = append(required, string(f.Name))
}

should be !fOptional.

java client - code is not generated correctly if we have out parameter in rdl

We have the following resource in our server:

resource SignedDomains GET "/sys/modified_domains?domain={domain}&metaonly={metaOnly}" {
DomainName domain (optional); //filter the domain list only to the specified name
String metaOnly (optional); // valid values are "true" or "false"
String matchingTag (header="If-None-Match"); //Retrieved from the previous request, this timestamp specifies to the server to return any domains modified since this time
String tag (header="ETag", out); //The current latest modification timestamp is returned in this header
authenticate;
expected OK, NOT_MODIFIED;
exceptions {
ResourceError NOT_FOUND;
ResourceError FORBIDDEN;
ResourceError UNAUTHORIZED;
}
}

The client api generated for this resource is:

public SignedDomains getSignedDomains(String domain, String metaOnly, String matchingTag);

There is no interface to access the tag field.

Support mutually recursive types

Self-recursion works.

$ rdl version
rdl 1.4.7 
$ cat x.rdl
type Node Struct {
    Node left;
    Node right;
}
$ rdl -ps generate json x.rdl 
{
    "name": "x",
    "types": [
        {
            "StructTypeDef": {
                "type": "Struct",
                "name": "Node",
                "fields": [
                    {
                        "name": "left",
                        "type": "Node"
                    },
                    {
                        "name": "right",
                        "type": "Node"
                    }
                ]
            }
        }
    ]
}

However, mutual recursion doesn't

$ cat x.rdl
type Node Struct {
    Node left;
    Node right;
    Tree tree;
}

type Tree Struct {
    Node root;
}
$ rdl -ps generate json x.rdl 
*** Error (x.rdl, line 4): No such type: Tree
  1 type Node Struct {
  2     Node left;
  3     Node right;
  4     Tree tree;
  5 }
  6 
  7 type Tree Struct {
  8     Node root;
  9 }
 10 

Markdown & swagger generator are not in release packages

We are generating our documents using rdl. However, markdown and swagger generator plugin are not in release packages. There's only rdl itself in the packages.

It would be nice if you can help us putting them into release packages. We really need them.

Thank you.

java server generated exception code has undefined behavior

The list of exceptions stored in the rdl resource object is stored in a map. When the code is generated, due to map iterator's undefined order behavior, it always ends up using a different order for case statements. This of course is tagged as a change so it must be reviewed and committed to git. It makes code review somewhat confusing since the reviewer is not sure why the exceptions are kept moving around: e.g.:

https://gist.github.com/havetisyan/e42b0a41dc2027bde939a9184fcb0441

The code generator must have a defined behavior such that if I generate the code multiple times with the same rdl file, it must generate the same code every time.

While we can store the exceptions in a map, before generating the code, we can put the exceptions in a sorted list thus generating the same switch block every time.

print the name of queryparam on validation failure

I'm getting an error trying to generate the server bindings:

RDL error: queryparam must either be optional or have a default value

• but it does not say which queryparam is causing problems, which would help to troubleshoot.

(I also then figured out that the failure was caused by misspelled 'optional' - had 'optinal' instead; should the compiler indicate that it is an unknown option?)

Can basePath be a standard of rdl format?

HI, we are using rdl as our framework implementation.
Some users want the feature of basePath to be a part of rdl, so they can set path for each rdl file.

We know there are parameter "-b" in the generator of client & server, but it is not enough for us.
Can basePath be a field in generated json file?
We want it to be like what swagger supported. http://swagger.io/specification/

It will do us a big favor.
Thank you.

Use of JsonSerialize.Inclusion.NON_DEFAULT in java model classes ends up generating "empty" output

When generating java model classes, the generator uses the following annotation:

@JsonSerialize(include = JsonSerialize.Inclusion.NON_DEFAULT)

In Athenz, we have a class called Access which has a single boolean field granted which returns whether the authorization check is successful or failed:
{"granted":true} or {"granted":false"}

However, with the use of @JsonSerialize(include = JsonSerialize.Inclusion.NON_DEFAULT) annotation, Jackson library skips the default value of false for the granted attribute and generates the json object as {} which is invalid. The client was expecting to see the "granted" attribute in response with the false value.

The model generator must provide the option to use different annotations which generate the expected output: e.g.:

@JsonSerialize(include = JsonSerialize.Inclusion.ALWAYS)

Errant * in generated client code when NO_CONTENT or NOT_MODIFIED responses are specified

The result won't compile.

java client - option to specify our own client name

Our service is called ZMS in our RDL, so the rdl generates a class called ZMSClient. However, we'd like to extend this class and provide additional helper methods to our users but we still want to call our class ZMSClient. We'd like to have the option to specify an alternate class name when generating the client class name.

Generated go code for rdl with more than one enums with same value is unusable

Following is the example where I have 2 enums myEnumA and myEnumB defined in the same .rdl file and the code for types in the schema is generated.

$ cat example.rdl
namespace example;

type myEnumA Enum { ALL, ENUM_A_VALUE1 }
type myEnumB Enum { ALL, ENUM_B_VALUE2 }

$ rdl generate java-model example.rdl
$ rdl generate go-model example.rdl

Java files created for EnumA and EnumB are
$ ls src/main/java/example/MyEnum*
src/main/java/example/MyEnumA.java src/main/java/example/MyEnumB.java

Java generated code has no issue, works fine for me.

Go file created
$ ls example_model.go
example_model.go

//
// myEnumA -
//
type MyEnumA int

//
// MyEnumA constants
//
const (
        _ MyEnumA = iota
        ALL
        ENUM_A_VALUE1
)

var namesMyEnumA = []string{
        ALL:           "ALL",
        ENUM_A_VALUE1: "ENUM_A_VALUE1",
}

//
// myEnumB -
//
type MyEnumB int

//
// MyEnumB constants
//
const (
        _ MyEnumB = iota
        ALL
        ENUM_B_VALUE2
)

var namesMyEnumB = []string{
        ALL:           "ALL",
        ENUM_B_VALUE2: "ENUM_B_VALUE2",
}

---

Since ALL is redeclared in the block using this model gives me the error

./example_model.go:109: ALL redeclared in this block
	previous declaration at ./example_model.go:25

java server @Path annotation assumes root servlet support

When generating a resources for my service called zms, the @path annotation generated in the resource files is:

@path("/zms/v1")

This works well if the servlet I generate is set as the default servlet since I want to support my service with endpoints like: http://myhost:4443/zms/v1 but it doesn't work when I have multiple rdl generated servlets that I want to deploy within the same container e.g.:

http://myhost:4443/zms/v1 (zms.war)
http://myhost:4443/ums/v1 (ums.war)

The java server generator should have an option to generate the Path with (default option) or without the service name in the path.

java client - incorrect code generated to match exceptions

When the RDL includes exceptions for different http status code, the tool generates the following code:

    String status = Response.Status.fromStatusCode(code).toString();
    if (status.equals("OK")) {
        return response.readEntity(Template.class);
    } else if (status.equals("BAD_REQUEST")) {
        throw new ResourceException(code, response.readEntity(ResourceError.class));
    } else if (status.equals("NOT_FOUND")) {
        throw new ResourceException(code, response.readEntity(ResourceError.class));

However, Resource.Status.fromStatusCode(code).toString() never returns such strings as "BAD_REQUEST" or "NOT_FOUND". According to jersey code, those values would be: "Bad Request", or "Not Found".

Wouldn't it be better to handle the status codes directly as integers as oppose to converting to string and comparing them?

Please add YAML serialization tags for Go objects generated from the model

To be compliant with the requirements for gopkg.in/yaml.v2

As far as I can tell you just need to duplicate the JSON tags, substituting "yaml" for "json".

Please add example support

hi,

can RDL support examples for fields, requests and responses? similar to what Sagger provides http://swagger.io/docs/specification/adding-examples/
Maybe also allow users to provide a short description/comments on the examples.

thx!

java client - ability to set our own HostnameVerifier

We need to have the capability to set the HostnameVerifier for the ClientBuilder class:

hostnameVerifier(HostnameVerifier verifier)
Set the hostname verifier to be used by the client to verify the endpoint's hostname against it's identification information.

java client - does not pass authentication details

While the caller can specify the credentials header and value fields, the generated code is missing the actual:

    invocationBuilder.header(credsHeader, credsToken);

call to include those details for any request that requires either authentication or authorization.

java client - no autogenerate header for some of the files

ResourceError.java and ResourceException.java files do not include a header that the file is auto-generated by rdl.

I also would like the text to include that the file is auto-generated and should not be modified.

Schema does not allow type aliasing to Any

IMO, the following should be allowed but isn't. I'm not deriving but aliasing. If I replace Any with String, for example, the schema generation works.

$ cat x.rdl 
type Foo Any;
type X Struct {
   Any y;
}
type Y Struct {
   Foo y;
}
$ rdl -ps generate json x.rdl 
*** Error (x.rdl, line 1): Cannot derive from this type: Any
  1 type Foo Any;
  2 type X Struct {
  3    Any y;
  4 }
  5 type Y Struct {
  6    Foo y;
  7 }
  8 
  9 
 10 

java client - ability to set timeouts for client

the generated client does not provide a method to call the setProperty method for the javax.ws.rs.client Invocation.Builder that we can use to set the read/connect timeouts for the client.

resource "name" attribute is ignored in code generation

For example:

type Foo Struct {
String bar;
}
resource Foo GET "/one/{id}" {
String id
}
resource Foo GET "/two/{id}" (name=GetFooAlternate) {
String id
}

does not generate valid code (in Go, in particular) because both resources get the same GetFoo method name.

Other-than-string query parameters generates invalid server code

i.e. this rdl:

resource Bool GET "/foo?status={buildStatus}" {
Bool buildStatus (default=false)
}

generates code that doesn't compile:
...multiple-value rdl.BoolParam() in single-value context

Schema generator generates bad alias definition for a struct alias

$ cat x.rdl

type S1 string (pattern=".*");
type S2 S1;

type Base Struct { 
    String bar; 
}
type Foo Base;

$ rdl version
rdl 1.4.7 

$ rdl -ps generate json x.rdl 
{
    "name": "x",
    "types": [
        {
            "StringTypeDef": {
                "type": "String",
                "name": "S1",
                "pattern": ".*"
            }
        },
        {
            "AliasTypeDef": {
                "type": "S1",
                "name": "S2"
            }
        },
        {
            "StructTypeDef": {
                "type": "Struct",
                "name": "Base",
                "fields": [
                    {
                        "name": "bar",
                        "type": "String"
                    }
                ]
            }
        },
        {
            "AliasTypeDef": {
                "type": "Struct",
                "name": "Foo"
            }
        }
    ]
}

The alias type S2 correctly references S1 in its defintion but Foo refers to Struct rather than Base.

generated go client does not return http request status if response is not Json

As part of this commit: #96 (e2ddb49#diff-b6ebcf939863983eb4d9dfc8f325ee64) the go client generation replaced:

json.Unmarshal(contentBytes, &errobj)
if errobj.Code == 0 {
	errobj.Code = resp.StatusCode
}

with the following code:

err = json.Unmarshal(contentBytes, &errobj)
if err != nil {
	return nil, "", err
}
if errobj.Code == 0 {
	errobj.Code = resp.StatusCode
}

So if the server returns unexpected code such as 500, 503, etc, without any json object then the client fails to Unmarshal the data since it's not json. Before we would correctly ignore the message and return the status code in the errobj but now we get an err from the Unmarshal call and return that the caller and thus the client does not know why the request was rejected.

Comment issue with enum

rdl version
rdl 1.4.12

Wondering if there's a parsing bug in the enum parser.
In the first example, the comments are properly attributed to the constants.
In the second example, the comment associations seems different. See the JSON.

type Works enum {
    INCOMPLETE, // The campaign needs more information before it can be READY.

    READY, // The campaign is ready to be ACTIVE before the acquire start period.

    ACTIVE, // Time is within either the acquire or redeem period.

    STANDBY, // Time is after the acquire start time but not currently within either the acquire or redeem period.

    FINISHED // Time is after redeemable period
}
{type=Enum, name=Works, annotations={x_included_from=DataObject.rdli}, elements=[{"symbol":"INCOMPLETE","comment":"The campaign needs more information before it can be READY."},{"symbol":"READY","comment":"The campaign is ready to be ACTIVE before the acquire start period."},{"symbol":"ACTIVE","comment":"Time is within either the acquire or redeem period."},{"symbol":"STANDBY","comment":"Time is after the acquire start time but not currently within either the acquire or redeem period."},{"symbol":"FINISHED","comment":"Time is after redeemable period"}]}


type NoWorks enum {
    // The campaign needs more information before it can be READY.
    INCOMPLETE,

    // The campaign is ready to be ACTIVE before the acquire start period.
    READY,

    // Time is within either the acquire or redeem period.
    ACTIVE,

    // Time is after the acquire start time but not currently within either the acquire or redeem period.
    STANDBY,

    // Time is after redeemable period
    FINISHED
}

{type=Enum, name=NoWorks, comment=The campaign needs more information before it can be READY., annotations={x_included_from=DataObject.rdli}, elements=[{"symbol":"INCOMPLETE","comment":"The campaign is ready to be ACTIVE before the acquire start period."},{"symbol":"READY","comment":"Time is within either the acquire or redeem period."},{"symbol":"ACTIVE","comment":"Time is after the acquire start time but not currently within either the acquire or redeem period."},{"symbol":"STANDBY","comment":"Time is after redeemable period"},{"symbol":"FINISHED"}]}

Embedding a Go type generated by RDL into another Go type that is hand-written causes panics in JSON serialization

Test case: https://gist.github.com/gotwarlost/6cf38fc5f554ff1ec06aa4b045912060

produces:

$ rdl-bug
2017/05/12 16:13:19 {
    "id": "me",
    "name": "Krishnan",
    "Title": "Mr."
}
panic: runtime error: invalid memory address or nil pointer dereference [recovered]
	panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x129f754]

...

java client - incorrect code generated for NO_CONTENT or NOT_MODIFIED status codes

When the RDL has:
expected NO_CONTENT;
then the java client code is generated as follows:
if (status.equals("NO_CONTENT")) {
return response.readEntity(Role.class);
}

which is incorrect since there is no data to read.

Similary, when the RDL has:
expected OK, NOT_MODIFIED;
then the java client code is generated as follows:
if (status.equals("OK") || status.equals("NOT_MODIFIED")) {
return response.readEntity(SignedDomains.class);

which is incorrect for the NOT_MODIFIED case since there is no data to read.

RDL cheerfully tolerates duplicate fields in a struct

$ cat x.rdl
type Contact Struct {
    String name;
    String name;
}

$ rdl version
rdl 1.4.7 

$ rdl -ps generate json x.rdl
{
    "name": "x",
    "types": [
        {
            "StructTypeDef": {
                "type": "Struct",
                "name": "Contact",
                "fields": [
                    {
                        "name": "name",
                        "type": "String"
                    },
                    {
                        "name": "name",
                        "type": "String"
                    }
                ]
            }
        }
    ]
}

Note that this check needs to also be made when flattening fields so that duplication is caught between base and inherited types.

@Produces application/json annotation on OPTIONS methods incompatible with latest Firefox CORS requests

We're using OPTIONS http method for CORS requests. RDL generates the following resource for the command:

@OPTIONS
@Path("/user/{userName}/token")    
@Produces(MediaType.APPLICATION_JSON)
public UserToken optionsUserToken(...)

The latest Firefox when issuing the command, uses the following value for Accept header:

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

When processing this, jetty uses it's OPTIONS handler since text/html is of higher quality and does not call our method.

Since there is body currently defined to be generated for OPTIONS method, the rdl generator should not include the @produces(MediaType.APPLICATION_JSON) annotation.

Request Object form for Client and Handler w/ support for context

Make a variant of the Go code generator which generates signatures of the form:

Verb(context, RequestArgumentStruct) (ResponseStruct, error)
(no response object)
Verb(context, RequestArgumentStruct) error

Where all arguments are fields on the request struct.

This would enable the Client and server Handler forms to be merged, possibly eliminate the rdl.Context in favor of the the Go context (with helpers to read/write the RDL-specific attributes), and mean that adding new optional parameters does not change the signature of handlers and clients.