On 05/11/2013 16:57, Sergey Beryozkin wrote:
Hi Francesco
thanks for the super-quick check,
Hi Sergey,
no problems, I am fully committed to Syncope trunk these days, so it was
as easy as rebuilding CXF and restarting Syncope ;-)
[...]
<method name="POST" id="create">
<request>
<representation mediaType="application/xml"
element="syncope1:abstractSchema"/>
<representation mediaType="application/json"
element="syncope1:abstractSchema"/>
</request>
<response>
<representation mediaType="application/xml"/>
<representation mediaType="application/json"/>
</response>
</method>
You can probably push down Produces from Class-level to only those
methods which do produce something, as in this case you have a
response with no entity returned, but WADL says as if some
representation is expected
Correct: most of such methods, however, actually return Response, and my
XSLTs put the corresponding @Description shown at the same place in the
resulting HTML, so I am quite fine like this.
and
<method name="GET" id="list">
<request/>
<response>
<representation mediaType="application/xml"
element="syncope1:abstractSchemas"/>
<representation mediaType="application/json"
element="syncope1:abstractSchemas"/>
</response>
</method>
which is I think the most I can get out, given other constraints.
What about the grammar, do you have elements with substitutionGroups
too ?
No.
FYI, the JAX-RS annotated service interface for Schema resources is
https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/services/SchemaService.java
OK
Thanks again for your work, now looking forward to CXF-5353 ;-)
Sure :-). Sorry if it won't make it into 2.7.8 though, but we are def
going to address it
No problems: our final target for Syncope 1.2.0 is CXF 3.0 (implementing
the final JAX-RS 2.0 specification, IIRC): if this specific feature will
be available sooner (say, in 2.7.9) we might consider backporting the
RESTful documentation to Syncope 1.1.X, but this is not the priority ATM.
Let me say once again that I've found the support here at CXF
unbelievable and that it made me appreciate even more the Apache way.
Regards.
On 23/10/13 15:07, Francesco Chicchiriccò wrote:
On 23/10/2013 15:55, Sergey Beryozkin wrote:
Hi,
On 23/10/13 13:23, Francesco Chicchiriccò wrote:
On 23/10/2013 14:17, Sergey Beryozkin wrote:
Hi Francesco
On 23/10/13 12:49, Francesco Chicchiriccò wrote:
Hi,
I have a couple of further questions about CXF and the WADL
generation.
1. Is it possible to obtain a WADL file from CXF offline, e.g.
without a
running JEE container?
Do you refer to the possibility of auto-generating WADL as part of
the
build process ? No, we can't do it yet.
So far I've been thinking that if a user does want to avoid the
auto-generation at runtime then a WADL document needs to be created
manually (to be linked later from jaxrs:server) and also
distributed
offline if needed.
Ok, thanks for your answer.
2. Are the following transformations (from service interface to
WADL)
the most we can obtain?
@POST
<T extends AbstractSchemaTO> Response
create(@PathParam("kind")
AttributableType attrType,
@PathParam("type") SchemaType schemaType, T
schemaTO);
becomes
<method name="POST" id="create">
<request>
<representation mediaType="application/octet-stream"/>
</request>
<response>
<representation mediaType="application/octet-stream"/>
</response>
</method>
As you can see there is no 'element' information into
request/representation; or
@GET
<T extends AbstractSchemaTO> List<T> list(
@PathParam("kind") AttributableType attrType,
@PathParam("type") SchemaType schemaType);
becomes
<method name="GET" id="list">
<request/>
<response>
<representation mediaType="application/octet-stream"/>
</response>
</method>
In this case there is no 'element' information into
response/representation.
this needs to be investigated; the immediate problem might be is
that
WADLGenerator also needs to be tuned a bit to properly manage all
those generic declarations; now, once we move beyond that, we can
probably get a schema generated now that we have @XmlType element
only
supported (assuming AbstractSchemaTO has @XmlType),
but that can actually produce a wrong document because the
generated
schema won't match the actual elements (subclasses of
AbstractSchemaTO).
I don't know, may be if AbstractSchemaTO will also have @XmlSeeAlso
listing the possible substitutions then we can generate the proper
schema element from AbstractSchemaTO only, needs to be explored.
https://issues.apache.org/jira/browse/CXF-5355
Thanks again.
As you can see [1], AbstractSchemaTO should already have all needed
annotations in place.
I wonder if it has a redundant XmlRootElement ? Not sure yet but it
might confuse WADLGenerator...
Just commented @XmlRootElement and restarted: same results...
FYI, I don't have any pending local change, hence you can find the
full
CXF configuration (including WADLGenerator) at [2]
Regards.
[1]
https://svn.apache.org/repos/asf/syncope/trunk/common/src/main/java/org/apache/syncope/common/to/AbstractSchemaTO.java
[2]
https://svn.apache.org/repos/asf/syncope/trunk/core/src/main/resources/restContext.xml
--
Francesco Chicchiriccò
ASF Member, Apache Syncope PMC chair, Apache Cocoon PMC Member
http://people.apache.org/~ilgrosso/