OK, I guess we can make it work.
FYI, I'm signing off shortly and will be back next Tue only; there are
many open issues to deal with so there might be a slight delay in
addressing the new enhancement requests :-), but I'm positive we can do
something about it.
Thanks, Sergey
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
