Hi Francesco
thanks for the super-quick check,
On 05/11/13 15:45, Francesco Chicchiriccò wrote:
On 05/11/2013 15:29, Sergey Beryozkin wrote:
Hi Francesco,
I think it should be fixed now, by default, in cases like yours, all
elements generated from classes listed in XmlSeeAlso will have a
substitutionGroup added pointing to a head element representing the
abstract element derived from XmlType.
Note, this won't work if the abstract type also has XmlRootElement.
It also can be disabled, given that CXF can be configured to return
the base types with xsi:type, which is an alternative to the
substitution groups.
I'm not sure though why you do not have anything at all generated in
the grammar in your case, I checked SchemaController and I do not even
see JAX-RS annotations there, where are they picked up from ? May be
it will just work for you from the rebuilt CXF 2.7.8-SNAPSHOT ?
Hi Sergey,
I confirm that the fix for CXF-5355 works in my case; the two methods
referenced below now are generated in WADL respectively as
<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
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 ?
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
Thanks, Sergey
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
