By the way
in CXF 2.7.15 JSONProvider does not escape '/' by default, not actually
sure why it was escaping them, should be just "application/json" instead
of "application/\json", etc
Thanks, Sergey
On 05/03/15 10:50, Sergey Beryozkin wrote:
Hi Mandy
On 04/03/15 22:18, Mandy Warren wrote:
Thanks Sergey - if I do a GET on the href I get "BadRequest" as the
WADLGenerator is expecting XML. If in future we can inline JSON
schemas this problem goes away so less of an issue.
HTTP Accept needs to be set to application/json for retrieving the
schema linked from a top level WADL in JSON document
Also, I couldn't manage to get @XMLName to affect the generated WADL -
looking through the WADLGenerator code it looks like this is only used
if XML mime type is specified:-
if (isJson) {
sb.append("
element=\"").append(theActualType.getSimpleName()).append("\"");
} else if (qnameResolver != null
&& (linkAnyMediaTypeToXmlSchema ||
mt.getSubtype().contains("xml"))
&& jaxbTypes.contains(theActualType)) {
generateQName(sb, qnameResolver, clsMap,
theActualType, isCollection,
getBodyAnnotations(ori, inbound));
}
Sorry, I just got confused myself :-), so yes the actual type simple
name is used.
However I'm happy to stick to using @ElementClass to link the
request/response to a class represented by the json schema as this
works well. In fact looks like the WadlGenerator using the simple name
of the request/response class anyhow to link the "element" if
@ElementClass is not specified so that's good enough:-
{"@name":"PUT","request":{"representation":{"@element":"Book","@mediaType":"application\/json"}},"response":{"@status":"204"}}]}
Hope I've understood everything correctly!
I've just checked, @ElementClass is checked for calculating the name
too, if it is not an explicit collection, just above the code you pasted
above. So it should work, does it not for you ?
Thanks, Sergey
Thanks
Mandy
Sent from a mobile device
On 4 Mar 2015, at 12:27, Sergey Beryozkin <[email protected]> wrote:
Hi Mandy
Please see comments below
On 03/03/15 23:43, Mandy Warren wrote:
Hi Sergey,
Thanks for the fast reply! So I've tried the
linkAnyMediaTypeToXmlSchema and that worked fine but we are trying
to move away from XSDs to Json Schema so am very supportive of the
jira you raised!
I tried the externalLinks property and it now shows an @href link
but I'd really like to see it inline.
Right. If you GET on that href link then you should get the schema
displayed. Using links to schemas is OK, from the client processing
perspective, one would read WADL and then extract a schema...
Inlining a JSON schema inside "grammars" is a possibility too.
The closest thing I came to what I wanted was using:
@Description(docuri="classpath:/json.schema")
which generated the schema inline under "doc" but at the method
level - really I want to see the schemas attached to the request /
response as they will each use different schema. It's almost like I
need a variation on the @ElementClass where I could specify the json
schema for request & response.
That would unlikely to work - the schema data, if any, needs to go
inside the "grammars" section. JSON schema would contain all the
elements, and then a given request or response representation will
link to it via the "element" attribute. This is usually done
automatically with XML schemas, for JSON schema one needs to use a
CXF annotation @XMLName:
@XMLName(value = "{Chapter"), similar to
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=rt/rs/description/src/test/java/org/apache/cxf/jaxrs/model/wadl/Chapter.java;h=15b71970b3d5ed9aa580bf2387b2f36682fff6e9;hb=HEAD#l32
@XMLName is not a good name when dealing with JSON schemas though
:-). I'll probably extend WADLGenerator a bit to use a given bean
class's simple name to link if it is a json format and no @XMLName is
set
Great news you support Swagger - I'll trying playing with that too.
Freeman started it and Andriy Redko did more work on it. It does
require use of Swagger annotations which is probably not a big deal.
Not all users like its dependency on Scala. We might consider
offering some Java based tooling support for it but it is a longer
term option.
I'll also hassle SmartBear about support in SoapUI as your blog
suggests!
Sounds good :-). Note that WADL in JSON is an experiment. However
WADL spec is a fine effort. And the practice has shown that sometimes
the specifications are evolved further not by the committee :-), so I
guess if there will be some community demand for WADL in JSON then
someone like SoapUI just might want to go ahead and do support it at
their end. Which might convince Oracle to do some effort and evolve
WADL a bit further. I think WADL has had a bit of bad luck due to the
fact it came at the moment when some people were saying we don't need
a description language for REST. And now we do have several options
but also a fragmented RS description language space :-)
Thanks, Sergey
On 3 Mar 2015, at 22:19, Sergey Beryozkin wrote:
Hi Mandy
Thanks for experimenting,
"schemaLocations" points to resources which are assumed to be XML
schemas and these schemas are read as XML. I've actually created a
JIRA few days ago to support inlining JSON schemas but for now
schemaLocations is assumed to point to XML schemas only.
Use an "externalLinks" property, see
https://git-wip-us.apache.org/repos/asf?p=cxf.git;a=blob;f=rt/rs/description/src/test/java/org/apache/cxf/jaxrs/model/wadl/WadlGeneratorJsonTest.java;h=cf368062059d21624cab45bd7614c6789c02f41e;hb=HEAD
Another option is to use WADL XML as usual but set a
'linkAnyMediaTypeToXmlSchema' property, so you'd see
representations of type JSON linked to XML schema elements - which
is semantically not correct but can give a good idea to users what
properties a JSON request or response may have...
We have also started supporting Swagger - which can be good for
describing JSON only services
Cheers, Sergey
On 03/03/15 21:48, Mandy Warren wrote:
Hi,
I recently read Sergey's blog
(http://sberyozkin.blogspot.co.uk/2011/10/describing-json-services-in-wadl.html
) about support for JSON Wadls and managed to view a wadl in JSON
but am still struggling to link the JSON schema to the wadl. My
spring config looks as follows:-
<bean id="wadlGenerator"
class="org.apache.cxf.jaxrs.model.wadl.WadlGenerator">
<property name="schemaLocations">
<list>
<value>classpath:/json.schema</value>
</list>
</property>
<property name="ignoreMessageWriters" value="false"/>
<property name="useJaxbContextForQnames" value="false"/>
</bean>
<bean id="jsonProvider"
class="org.apache.cxf.jaxrs.provider.json.JSONProvider">
</bean>
<jaxrs:server name="testResource" address="/v1/">
<jaxrs:serviceBeans>
<bean class="mandy.TestResourceV01" />
</jaxrs:serviceBeans>
<jaxrs:providers>
<ref bean="jsonProvider" />
<ref bean="wadlGenerator" />
</jaxrs:providers>
</jaxrs:server>
</beans>
When I try & access the wadl I get this error:
21:23:47.048 Could not determine bean name for instance of class
org.apache.cxf.bus.managers.ServerRegistryImpl.
com.ctc.wstx.exc.WstxUnexpectedCharException: Unexpected character
'{' (code 123) in prolog; expected '<'
at [row,col {unknown-source}]: [1,1]
at
com.ctc.wstx.sr.StreamScanner.throwUnexpectedChar(StreamScanner.java:647)
at
com.ctc.wstx.sr.BasicStreamReader.nextFromProlog(BasicStreamReader.java:2054)
at
com.ctc.wstx.sr.BasicStreamReader.next(BasicStreamReader.java:1131)
at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:1353)
at
org.apache.cxf.staxutils.StaxUtils.readDocElements(StaxUtils.java:1247)
at
org.apache.cxf.staxutils.StaxUtils.read(StaxUtils.java:1174)
at
org.apache.cxf.staxutils.StaxUtils.read(StaxUtils.java:1163)
at
org.apache.cxf.staxutils.StaxUtils.read(StaxUtils.java:1109)
at
org.apache.cxf.jaxrs.ext.xml.XMLSource.setBuffering(XMLSource.java:75)
at
org.apache.cxf.jaxrs.model.wadl.WadlGenerator.loadSchemasIntoCache(WadlGenerator.java:1770)
at
org.apache.cxf.jaxrs.model.wadl.WadlGenerator.setSchemaLocations(WadlGenerator.java:1752)
Any idea what I am missing?
Many thanks
Mandy
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
--
Sergey Beryozkin
Talend Community Coders
http://coders.talend.com/
Blog: http://sberyozkin.blogspot.com
