You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cxf.apache.org by Lorenzo Bolzani <l....@gmail.com> on 2011/02/25 12:38:38 UTC

Java2WSDL with external schemas

Hi, I'm trying to generate a wsdl from an annotated Java class. Here is my
situation

- I have one maven project running java2wsdl. This works and generates one
wsdl file, 2 external schema files and client classes. This is a core
service and defines the common classes for the whole project.

Here is a method from this project

    @WebMethod(operationName = "updateDocument", action =
"urn:updateDocument")
    @WebResult(name = "return", targetNamespace = "
http://www.klever.it/kdv/registry/ws")
    Document updateDocument(
            @WebParam(name = "document", targetNamespace = "
http://www.klever.it/kdv/registry/ws") Document document)
            throws ServiceException;


- Then I have another maven project with another web service. This new web
service accepts as parameters the same classes defined in the first project.


Here is a sample method from the the second project

    @WebMethod(operationName = "conserve", action = "urn:conserve")
    @WebResult(name = "return", targetNamespace = "
http://www.klever.it/kdv/ldoc/ws")
    public ConserveResult conserve(
            @WebParam(name = "document", targetNamespace = "
http://www.klever.it/kdv/registry/ws") Document document,
            @WebParam(name = "parameters", targetNamespace = "
http://www.klever.it/kdv/ldoc/ws") Parameters parameters,
            @WebParam(name = "dataPackageId", targetNamespace = "
http://www.klever.it/kdv/ldoc/ws") Integer dataPackageId)
            throws LDocException { ... }

Here "http://www.klever.it/kdv/registry/ws" is the namespace of the first
project and the Document class is defined there, while "
http://www.klever.it/kdv/ldoc/ws" is for the second project.

When I run wsdl2java in the second project everything works, but I have
these two problems

1. the schemas for the classes from the first project are duplicated
(inlined in the wsdl)
2. all java classes from the first project are regenerated

What I'd like to have is not to generate the client java classes again and
not to have the schemas duplicated. Why this?

1. Because the types from the first project are referenced in a lot of other
projects and when this types change I have to rebuild all the others.
Missing this step does not produce any error but cause subtle bugs in
production
2. having this duplicated schema definition confuses some xml tools we are
using and the generated wsdl have to be "hand-fixed" every time, replacing
the type definitions with an xs:import.

I tried both with jax-ws annotations, with binding files and with schema
catalogs, but with no luck.

This is the maven config

            <plugin>
                <groupId>org.apache.cxf</groupId>
                <artifactId>cxf-java2ws-plugin</artifactId>
                <version>${cxf-version}</version>
                <dependencies>
                    <dependency>
                        <groupId>org.apache.cxf</groupId>
                        <artifactId>cxf-rt-frontend-jaxws</artifactId>
                        <version>${cxf-version}</version>
                    </dependency>
                    <dependency>
                        <groupId>org.apache.cxf</groupId>
                        <artifactId>cxf-rt-frontend-simple</artifactId>
                        <version>${cxf-version}</version>
                    </dependency>
                </dependencies>

                <executions>
                    <execution>
                        <id>1-process-classes</id>
                        <phase>process-classes</phase>
                        <configuration>

<className>it.klever.kdv.ldoc.LDocService</className>

<outputFile>${basedir}/src/main/java/wsdl/LDocService.wsdl
                            </outputFile>
                            <genWsdl>true</genWsdl>
                        </configuration>
                        <goals>
                            <goal>java2ws</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

            <plugin>
                <groupId>org.apache.cxf</groupId>
                <artifactId>cxf-codegen-plugin</artifactId>
                <version>${cxf-version}</version>
                <executions>
                    <execution>
                        <id>2-generate-sources</id>
                        <phase>process-classes</phase>
                        <configuration>

<sourceRoot>${basedir}/src/main/generated</sourceRoot>
                            <wsdlOptions>
                                <wsdlOption>

<wsdl>${basedir}/src/main/java/wsdl/LDocService.wsdl</wsdl>
                                    <extraargs>
                                        <extraarg>-client</extraarg>
                                        <extraarg>-catalog</extraarg>

<extraarg>${basedir}/src/main/java/wsdl/schema.cat</extraarg>

<extraarg>-xjc-b,${basedir}/src/main/java/wsdl/binding.xjb</extraarg>
                                    </extraargs>
                                </wsdlOption>
                            </wsdlOptions>
                        </configuration>
                        <goals>
                            <goal>wsdl2java</goal>
                        </goals>
                    </execution>
                </executions>
            </plugin>

In the binding.xjb files I found no useful attributes and I suspect the
binding phase happens after the wsdl generation (?). This is the catalog
content

PUBLIC "http://www.klever.it/kdv/registry/ws"
"/home/trz/progetti/KDV/trunk/klever/legaldoc/kdv-ldoc-ws/src/main/java/wsdl/DocumentManagementService_schema1.xsd"

PUBLIC "http://www.klever.it/kdv/registry"
"/home/trz/progetti/KDV/trunk/klever/legaldoc/kdv-ldoc-ws/src/main/java/wsdl/DocumentManagementService_schema2.xsd"


I enabled the catalog debugging, -Dxml.catalog.verbosity=999, but nothing is
logged, even if I write garbage into the file, but if the catalog file path
is wrong the builds complains.

Where should I look for to fix this? I'm even quite confused about which
project is doing what.

I realized right now, writing this email, that probably I should first work
on the first part of the process, java2ws,  and after on the wsdl2java. I'll
check this. Anyway any suggestion is appreciated.


Thanks in advance

Bye

Lorenzo

Re: Java2WSDL with external schemas

Posted by Daniel Kulp <dk...@apache.org>.
On Friday, May 06, 2011 10:02:54 AM MiTaes wrote:
> Hi Lorenzo,
> 
> did you ever get a response to your question ?
> 
> I have a similar issue where I let CXF generate Webservice from Java but
> want to include an additional unreferenced type or schema for use as soap
> header. Since I don't want to use the @WebParam approach I don't know how
> to include the header type generation into CXF endpoint generation ?!

If using JAXB, you can add @XmlSeeAlso annotations to the service to point at 
the header types.   Those would be picked up and added to the JAXB context for 
use in the schema generation.

Dan


> 
> Any help would be appreciated !
> 
> Regards,
> Michael
> 
> --
> View this message in context:
> http://cxf.547215.n5.nabble.com/Java2WSDL-with-external-schemas-tp3399971p
> 4376015.html Sent from the cxf-user mailing list archive at Nabble.com.

-- 
Daniel Kulp
dkulp@apache.org
http://dankulp.com/blog
Talend - http://www.talend.com

Re: Java2WSDL with external schemas

Posted by MiTaes <m....@googlemail.com>.
Hi Lorenzo,

did you ever get a response to your question ?

I have a similar issue where I let CXF generate Webservice from Java but
want to include an additional unreferenced type or schema for use as soap
header. Since I don't want to use the @WebParam approach I don't know how to
include the header type generation into CXF endpoint generation ?!

Any help would be appreciated !

Regards,
Michael

--
View this message in context: http://cxf.547215.n5.nabble.com/Java2WSDL-with-external-schemas-tp3399971p4376015.html
Sent from the cxf-user mailing list archive at Nabble.com.