Actually, merged it to 2.5.4-SNAPSHOT too, please check the snapshot dates against the revision dates (you can see them at CXF-4250), and then try the generator once the updates are in...

Cheers, Sergey
On 19/04/12 22:56, Sergey Beryozkin wrote:
Hi
On 16/04/12 22:04, Sergey Beryozkin wrote:
Hi
On 16/04/12 18:20, Ismael Hasan Romero wrote:
Hello,

First of all, thank you very much for your time.

np, it's useful to test the tool against the complex WADL documents
Since this is a free service I doubt they will be changing it soon,
however, I will suggest this to them.

This is one of the fixes I was refering to before: I downloaded the
file and manually built a wadl with only one resources element. Also,
I downloaded all of the referenced "xsd" files, and I compile the
service in local. If you want these files to do some tests I will
gladly send them to you, just let me know and I will attach them (or,
if you prefer, I can just send as text the modified wadl resources
section).

I reproduced the cast issue with the first 'resources' block. Not sure
yet what causes it, we will get to the bottom of it a bit later.


I've made some progress on this issue. The actual bug was fixed, there
was a problem processing root-level method declarations only.
One extra complexity there is that template parameters are actually
referring to the non-primitive types declared in the ops schema, which
are enums; that can be supported by JAX-RS so I updated the code to
handle it better.

Pointing the generator to the absolute WADL URI would also work OK.

The problem with the document is that it breaks one more limitation that
the WADL spec imposes, specifically, the method references, example
<method name="GET" href="#wpdGETPOST"/>

has the name attribute while the actual referenced method element has no
'name' attribute. This confuses the generator because method without
names are assumed to be subresource locators.

The right approach is to actually have one global WADL method per HTTP
method but reuse 'request' and 'response' element to minimize the
duplication. Try that please or simply have duplicate wpdGET & wpdPOST
just to get going

I've merged the updates to the trunk, will merge to 2.5.x tomorrow

Sergey

[1] https://issues.apache.org/jira/browse/CXF-4250



Cheers, Sergey

Best regards,
Ismael

----- Mensaje original -----
De: "Sergey Beryozkin"<[email protected]>
Para: [email protected]
Enviados: Lunes, 16 de Abril 2012 18:59:22
Asunto: Re: Cast exception when compiling REST EPO web services
(com.sun.org.apache.xerces.internal.dom.DocumentImpl cannot be cast to
org.w3c.dom.Element)

OK, it appears the WADL is invalid, it has multiple 'resources'
container elements but according to
http://www.w3.org/Submission/wadl/wadl.xsd

there has to be only a single one.
Can they have a single 'resources' with other ones collapsed into it as
child resource elements ?

Cheers, Sergey


On 16/04/12 17:51, Sergey Beryozkin wrote:
Hi

Please see comments below:

On 16/04/12 09:13, Ismael Hasan Romero wrote:
Hello,

I am trying to compile the REST services from EPO using the
"wadl2java" command line utility (they can be found at
http://www.epo.org/searching/free/ops.html) .

I've downloaded this WADL document and going to experiment with it


After several fixes in the description files I finally got a cast
error from DocumentImpl to Node. This is the first time I compile a
rest web service, so I am a bit lost and I don't know where this error
may come from, so any help will be appreciated.


The options I am using are the following:
./wadl2java -V -wadlns http://ops.epo.org -p eposervices -d eporest/
-compile -classdir /tmp/eporest file:///tmp/ops.apache.wadl


The full trace of the error is the following:

WADLToJava Error: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DocumentImpl cannot be cast to
org.w3c.dom.Element

org.apache.cxf.tools.common.ToolException:
java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DocumentImpl cannot be cast to
org.w3c.dom.Element
at
org.apache.cxf.tools.wadlto.jaxrs.JAXRSContainer.execute(JAXRSContainer.java:84)



at
org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:103)



at org.apache.cxf.tools.wadlto.WADLToJava.run(WADLToJava.java:65)
at org.apache.cxf.tools.wadlto.WADLToJava.run(WADLToJava.java:57)
at org.apache.cxf.tools.wadlto.WADLToJava.main(WADLToJava.java:99)
Caused by: java.lang.ClassCastException:
com.sun.org.apache.xerces.internal.dom.DocumentImpl cannot be cast to
org.w3c.dom.Element
at
org.apache.cxf.jaxrs.ext.codegen.SourceGenerator.writeResourceMethod(SourceGenerator.java:651)



at
org.apache.cxf.jaxrs.ext.codegen.SourceGenerator.writeMethods(SourceGenerator.java:524)



at
org.apache.cxf.jaxrs.ext.codegen.SourceGenerator.writeResourceClass(SourceGenerator.java:428)



at
org.apache.cxf.jaxrs.ext.codegen.SourceGenerator.generateResourceClasses(SourceGenerator.java:255)



at
org.apache.cxf.jaxrs.ext.codegen.SourceGenerator.generateSource(SourceGenerator.java:222)



at
org.apache.cxf.tools.wadlto.jaxrs.JAXRSContainer.processWadl(JAXRSContainer.java:153)



at
org.apache.cxf.tools.wadlto.jaxrs.JAXRSContainer.execute(JAXRSContainer.java:67)



at
org.apache.cxf.tools.wadlto.jaxrs.JAXRSContainer.execute(JAXRSContainer.java:76)



... 4 more



I managed to get past this issue, the code generator needs a couple of
fixes to be able to better handle documents/schemas available at remote
locations, ex, the schema reference is "/2.6.2/schema/ops.xsd", same
for
the base resource, but that is a minor issue, I'm seeing a long list of
types being generated:

INFO: Created classes: org.epo.register.Absno,
org.epo.register.Accepted, org.epo.register.ActionDate,
org.epo.register.Addition, org.epo.register.AdditionalInfo,

.....................

org.epo.exchange.UnlinkedIndexingCodeType, org.epo.exchange.UrlType,
org.epo.exchange.UsRightsType, org.epo.exchange.VidType

and then

java.lang.IllegalStateException: WADL resources element is missing
at
org.apache.cxf.tools.wadlto.jaxrs.SourceGenerator.generateResourceClasses(SourceGenerator.java:244)




though I set the wadlns to "http://wadl.dev.java.net/2009/02";.

Looking into it though it will take me few days to sort it out as I'm
traveling during the next 2 days

Cheers, Sergey

















--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Reply via email to