I have been working on a REST web service using Jersey for a few days now, and managed to have all CRUD operations working, with several exchange formats: XML, JSON, Google Protobuf.

However I am facing some issues related to automatically generated WADL and XSD.

----------

#Context

To define the objects exchanged in these three formats, I have followed a **&quot;contract-first&quot; approach**:

 - from a XSD I wrote, I generated my model classes using JAXB;
 - from an equivalent proto file I wrote, I generated the Google Protobuf classes (and internally have a way to convert these to the JAXB-generated objects, in order to have one unique model).

However, as I would like my users to be able to **generate their classes** too, I would like to share these schema files (.xsd and .proto) and have them **well integrated with the automatically generated WADL**.

For that purpose, thanks to [this][1] wiki page:

 - I have exposed the two files under
  - `/schema/schema.xsd`
  - `/schema/schema.proto`
 - I have added an application-grammar file:

        &lt;?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot; standalone=&quot;yes&quot;?&gt;
        &lt;grammars xmlns=&quot;http://wadl.dev.java.net/2009/02&quot; 
                  xmlns:xsd=&quot;http://www.w3.org/2001/XMLSchema&quot;
                  xmlns:xi=&quot;http://www.w3.org/1999/XML/xinclude&quot;&gt;
            &lt;include href=&quot;../schema/schema.xsd&quot; /&gt;
        &lt;/grammars&gt;

 - I have added a customized WADL generator:

         public class RichWadlGeneratorConfig extends WadlGeneratorConfig {
            @Override
            public List&lt;WadlGeneratorDescription&gt; configure() {
                return generator(WadlGeneratorApplicationDoc.class)
                    .prop(&quot;applicationDocsStream&quot;, &quot;application-doc.xml&quot;)
                    .generator(WadlGeneratorGrammarsSupport.class)
                    .prop(&quot;grammarsStream&quot;, &quot;application-grammars.xml&quot;)
                    .descriptions();
            }
         }

This way the below appears in the WADL, when I hit `/rest/application.wadl`:

    &lt;grammars&gt;
         &lt;include href=&quot;../schema/schema.xsd&quot;/&gt;
         &lt;include href=&quot;application.wadl/xsd0.xsd&quot;&gt;
              &lt;doc title=&quot;Generated&quot; xml:lang=&quot;en&quot;/&gt;
         &lt;/include&gt;
    &lt;/grammars&gt;

----------
 
#Problem

`/rest/application.wadl/xsd0.xsd` is automatically generated from my classes, but is quite **different** from what I initially had in `schema.xsd`.
In addition to that, calling a tool like `wadl2java` on this WADL fails miserably, presumably because

 - `/schema/schema.xsd`, and
 - `/rest/application.wadl/xsd0.xsd`

are now conflicting (two definitions for the same objects).

----------

#Questions

 1. Is there a way to disable the generation and diffusion of this automatically generated XSD? 
    (As I don&#39;t need it since I&#39;m following this &quot;contract-first&quot; approach)

 2. If not, is there a way to &quot;override&quot; its content with my manually written XSD when `/rest/application.wadl/xsd0.xsd` is hit?
    (I have googled around and found about WadlResource, to generate customized WADL, but found nothing about the XSD generation itself)

----------

Thanks in advance for your help!

M.

----------

#Edit

1) I raised the issue to the Jersey team and got a reply:
[http://java.net/projects/jersey/lists/users/archive/2012-06/message/8][2]

2) I raised a ticket (JERSEY-1230), according to Pavel&#39;s instructions.
I am currently following up to either submit a fix myself or get a fix from the Jersey team.


  [1]: https://wikis.oracle.com/display/Jersey/HowToConfigureExtendedWADL
  [2]: http://java.net/projects/jersey/lists/users/archive/2012-06/message/8

All Contract First Solutions on Gang of Coders

Total of 1 Contract First Solutions

Troubles with WADL / generated XSD using Jersey with a contract-first approach