Closed zero51 closed 7 years ago
Ditto additionalProperties
. It seems to be ignored, which is a shame...
@jstoiko: any guidance here? This and #126 are quite important to us. It's a great library, but there seems to be little activity. Is it still actively maintained?
@zero51: you raised some valid points. I should be able to get back to you by the end of the week with a solution to both issues.
Yes, this project is still actively maintained and a version with RAML 1.0 should be released soon. It's taking more time than expected to get it out and it's out of my control. Thanks for your patience.
Thanks @jstoiko. I'm using the raml1.0 branch at the moment, and most of it works fine.
Hang in there @zero51, still working on addressing this and #126. Not as trivial as I originally thought. Shouldn't be much longer though. The good news is we'll be able to include those changes in the new (pending) release.
Thanks for the update @jstoiko. Looking forward to playing with the new release...
@zero51: minProperties
, maxProperties
and additionalProperties
should work now. Can you give it a shot?
@jstoiko: minProperties
seems to work now, although additionalProperties
is still ignored. Also, I'm getting parse errors now on the RAML doc, even though Atom doesn't complain...
[xmldom error] element parse error: Error: invalid tagName:<resourcePathName
@#[line:1,col:17]
[xmldom warning] unclosed xml attribute
@#[line:1,col:18]
and
[xmldom error] element parse error: Error: invalid tagName:<resourcePathName
@#[line:1,col:14]
[xmldom warning] attribute "|" missed value!! "|" instead2!!
@#[line:1,col:15]
I have two resource types defined, which do make use of resourcePathName tags, but their implementation has not changed.
Removing all the resource-type descriptions silences all but two parse errors. There was nothing particularly special about them...
description: Where the <<resourcePathName | !singularize>> resource can be found
The line numbers in the parse errors don't ever seem to be anything other than 1, but the other two errors are a result of this line...
description: Base64 encoded version of <identifier>:<secret>, prefaced with 'Basic'
It seems that it no longer likes any angle brackets in descriptions.
Your issue seems related to what was reported here: https://github.com/mulesoft/osprey/issues/130.
Have you tried to parse your file using the parser directly? It seems like using the latest version might fix the issue you are reporting. If it does, then we should probably bump the version in Osprey. If it doesn't, then I suggest you file an issue here.
OK, will have a look. I guess the additionalProperties
issue still stands though?
I can't reproduce, i.e. additionalProperties
works for me. Can you share a RAML snippet here?
For this endpoint...
patch:
body:
type: object
properties:
first_name?: string
last_name?: string
additionalProperties: false
minProperties: 1
An empty body {}
correctly throws...
invalid json (minProperties, 1)
However, the following bodies are permitted: {"foo": "bar"}
and {"first_name": "Fred", "foo": "bar"}
.
You were right. Should be good now. Can you give it another try?
Sorry, same behaviour here.
you'll need to uninstall/reinstall all your dependencies specifically https://github.com/mulesoft-labs/osprey-method-handler
@jstoiko: Ah, I just uninstalled the core lib. All looks good now. Thanks!
BTW, just tried the RAML parser directly, and I get no errors. The warnings are still displayed by Osprey though.
that's odd. the version of the parser has just been bumped to 1.1.14 in Osprey which is the lastest release. did you uninstall and reinstall that dependency as well? can you check which version of the parser is installed?
├─┬ osprey-router@0.4.0
│ │ ├── array-flatten@2.1.1
│ │ ├── raml-path-match@2.0.0
│ │ └─┬ router@1.1.4 (git+https://github.com/blakeembrey/router.git#cfe18f9d59adca65c24c9c951ebd43e9bf07937e)
│ │ ├── array-flatten@2.0.0
│ │ ├── debug@2.2.0
│ │ └── setprototypeof@1.0.0
│ ├── passport-oauth2-client-password@0.1.2
│ ├─┬ raml-1-parser@1.1.14
when you're testing with the parser directly, are you using the development version or the same 1.1.14?
Same version, same RAML definition.
would you mind sharing you RAML?
Can I email it?
With the following RAML...
I would expect a request with blank body to fail, but it succeeds.