• Post Reply Bookmark Topic Watch Topic
  • New Topic

Packaging Service Interface and Exception of WSDL with External Customized JAXB Binding  RSS feed

 
Favil Von
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi,

I'm trying to customize package swhere the service interface and the exceptions of WSDL are generated under using an external JAXB binding document. I'm doing this via wsimport 2.2.4 (and 2.1), but regardless of my binding, it places them in the (reversed) default namespace of WSDL. However, using a customized JAXB binding file(s), the schemas (XSD's) do get placed in the correct packages. Here are my WSDL and external JAXB binding file:

(As I said, the schema bindings work, but the service and exception binding in the WSDL do not)


And the WSDL:



This would place the XSD types that are imported/included in the WSDL under "my.namespace.mytype" and "my.namespace.myothertype" accordingly. However, the exception (ServiceFault) and the service interface (and the implementation respectively) are generated under "namespace.my" (the WSDL's reversed default namespace) rather than "com.myservice.service" and "com.myservice.exception".

I am running the wsimport with the following (all the files are in the same directory: WSDL, XSD's, and JAXB binding documents; MyService.wsdl, MyType.xsd, MyOtherType.xsd, MyFault.xsd (which contains schema for the fault details), MyBinding.xml, ServiceFaultBinding.xml (a binding to place MyFault.xsd type in its own package, which, like other XSD's, do get placed in the correct package)):


 
g tsuji
Ranch Hand
Posts: 697
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
JAX-WS customization uses jaxws:bindings as container and as the root element. You should replace the root.

by
 
Favil Von
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Thank you g tsuji.

I tried your suggestion to replace the root element with jaxws:bindings, however, I am not clear what needs to be changed in the content of the binding document. Are you saying that all the "jaxb:bindings" must now be converted to "jaxws:bindings" (beside the root element)?

I tried many combinations, but none seems to work. They either totally ignore the desired package structure or throw an error during parsing. Here are the things I have tried based on your comment:

1A) Replaced the root element to reflect "jaxws" namespace
1B) Kept all the "schemaBindings" as "jaxb" (with proper namespace as attribute when required)
1C) Only the bindings for the service interface and exception are handled via "<jaxws:bindings>" (as before)

This causes all the packages indicated in the binding file to be ignored (even the schemas where used to work).


2A) Replaced the root element with "jaxws" namespace
2B) Replaced every "jaxb" in the binding file with "jaxws"

This causes the following error:

parsing WSDL...


[ERROR] invalid extension element: "jaxws:package" (in namespace "http://java.sun.com/xml/ns/jaxws")


Failed to parse the WSDL.



Now, if I replace lines 20 and 26 to use "<jaxb:package>" instead of "<jaxws:package>" (with jaxb namespace indicated in "<jaxws:bindings>"), I can by pass the error message, but the packages indicated in the binding file are ignored and default in each schema and WSDL are honored.
 
g tsuji
Ranch Hand
Posts: 697
3
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I do not quite get the detail of what you describe in your followup post. I guess that is always good to learn from the trial and error. It makes much sense for yourself and it is hard for some other to follow... I can re-read many times of it if you insist that would help.

I use a simpler posting of the problem from your first post.

If you want to customize wsdl proper you can use an external customization file to do that. For the schema part, you've to have jaxb:bindings instead. In case without import or include, all the schema(s) are inline, a single external customization file may be quite doable. But with schema import and include, at present, one would have to use a dedicated jaxb customization file for that purpose. Maybe one day a jaxws:bindings root would be able to consolide the two kinds of bindings including schemas import and include. But, at present, it seems not be the case.

Bref, return to the original question. Apart from the imported schema customization, you can do this. The major point is that you can customize the targetNamespace completely with jaxws:package. But if you want to even customize wsdl:service or wsdl:operation etc, those are not what jaxws:package would be used for. It is instead the jaxws:class is meant for. Let's call it jaxws_customization.xml.

Now for import schema customization, you make out a jaxb customization. Let's call it jaxb_customization.xml for instance. That you can use what you've succeeded file or something similar to this.

Now you can do the wsimport with two entries -b.

As this writeup becomes quite long, I may lose track myself what I've written. I do not exclude some typos or inconsistent slipped into it. But on the bigger picture of customization, that is the idea.
 
Favil Von
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
g tsuji wrote:
I use a simpler posting of the problem from your first post.

If you want to customize wsdl proper you can use an external customization file to do that. For the schema part, you've to have jaxb:bindings instead. In case without import or include, all the schema(s) are inline, a single external customization file may be quite doable. But with schema import and include, at present, one would have to use a dedicated jaxb customization file for that purpose. Maybe one day a jaxws:bindings root would be able to consolide the two kinds of bindings including schemas import and include. But, at present, it seems not be the case.


Excellent! Thank you.

So, the trick was to have jaxws in its own binding document, and the schema(s) in its own (jaxb). And also, to set the natural package of the WSDL's targetNamespace first, then set the class names.

Now, the only issue that I have left is that the service implementation sub class does not get generated with the following:



This creates a client (extends Service) rather than the service implementations (portType is for the service interface). What node (or option) should I pick for the subs?
 
g tsuji
Ranch Hand
Posts: 697
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
And also, to set the natural package of the WSDL's targetNamespace first, then set the class names.

There is no a priori sequential dependency. You could have set them quite independently and/or left them to their default naming.

This creates a client (extends Service) rather than the service implementations (portType is for the service interface). What node (or option) should I pick for the subs?

Is this not doing what you meant to obtain where the name customized to anything you like and obviously not deliberately to create any collision?
 
Favil Von
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
This creates a client (extends Service) rather than the service implementations (portType is for the service interface). What node (or option) should I pick for the subs?
Is this not doing what you meant to obtain where the name customized to anything you like and obviously not deliberately to create any collision?

That would change the name of the service interface, and binding the following (note "wsdl:service"),


merely changes the name of the "client proxy" (annotated with @WebServiceClient(...)). I need wsimport to generate the "service implementation" with subs contracted from the service interface (not the client code). Is there something I am doing wrong that the service interface "implementation" is not being generated?
 
g tsuji
Ranch Hand
Posts: 697
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Have you checked out the -keep option?
 
Favil Von
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
g tsuji wrote:Have you checked out the -keep option?

I thought -keep flag creates portable client artifacts! In either case, -keep option doesn't generate the implementation class when I try it.
 
g tsuji
Ranch Hand
Posts: 697
3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
With keep, you'll see that it generates the needed interfaces (.java), and just like any other code generation in axis or .net or else, wsimport and wsdl won't possibly know the business logic and you've to code their implementation where the business logic goes into. Does it sound logic and reasonable?
 
Favil Von
Greenhorn
Posts: 13
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
g tsuji wrote:With keep, you'll see that it generates the needed interfaces (.java), and just like any other code generation in axis or .net or else, wsimport and wsdl won't possibly know the business logic and you've to code their implementation where the business logic goes into. Does it sound logic and reasonable?

I see. I was under the impression that wsimport would generate the implementation and operation "subs" the least (i.e. empty bodies -- some Eclipse tools, like Rational Application Developer do generate such class through web service wizard of some sort). Thanks for clarification.

P.S. Another issue that I ran into is that, with JAXB 2.1 (this problem has been resolved in JAXB 2.2.x apparently), it cannot generate the exception class, if it has been indicated for several of operations in the interface (portType), i.e. assuming all operations advertise that each throws a single type exception. But then again, this is something that can only be remedied by upgrading.

Thanks for your help.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!