Hello, thank you for fixing it!. I will try it as soon as possible!
----- Mensaje original ----- De: "Sergey Beryozkin" <[email protected]> Para: [email protected] Enviados: Jueves, 19 de Abril 2012 23:56:33 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) 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 -- Ismael Hasan Information Retrieval Lab. Centro de Investigación en Tecnoloxías da Información e as Comunicacións. Universidade da Coruña. http://www.irlab.org 981 167000 Ext. 5521
