...and you can also change the output directory using the -d option, so
playing with the options, you should be able to have two web service
clients in the same project using the same generated entity classes,
assuming that the generated entity classes are exactly the same for the
same entities.
On 02.08.2011 20:15, Kutsal Kaan Bilgin wrote:
I haven't done code-first development with CXF yet, but, assuming
you're using CXF's wsdl2java for client generation, you should be able
to override/change the package name and ignore the namespaces in the
wsdl through the -p
commandhttp://cxf.apache.org/docs/wsdl-to-java.html(actually you can
do a namespace-to-package mapping for multiple namespaces) - but then
again I would expect the CXF runtime to declare the same namespace for
the same entities even when they're used in two separate web service
implementations.
On 02.08.2011 19:56, Liter András (SCTR) wrote:
Hello Kutsal,
Well I have a bottom-up approach and I use stateless EJB
implementations in JBossAS 6. I use JAX-WS annotations to define the
web service interface. And here comes my problem: At the
implementation/server side, I have business logic with a set of
business objects (entities), and WSDLs(I would like to define more
webservices) are generated by CXF runtime during deployment. So far I
didnt find the place where to tell CXF/JBoss (?) that I would like to
have my entities in a separate XSD schema and have my WSDLs
referencing to the same (and unique) type xsd file. Now the default
WSDL generation puts the schema information into the WSDL, so thats
why I have my types duplicated and with different namespaces on the
generated client stubs (maybe I should just use one namespace for
both services :s )
And maybe from here this is a JBoss-specific question...
-----Original Message-----
From: Kutsal Kaan Bilgin [mailto:[email protected]]
Sent: Tuesday, August 02, 2011 6:34 PM
To: [email protected]
Subject: Re: Client stub generation question
Hi Liter,
I could not understand how/where you define your entities - if you
define them in separate xsd files instead of the wsdl definition, you
should be able to use the same entities in all service/client
implementations. But if you define the same entities in separate
namespaces in each wsdl, which implies redundancy, then you'll have
same entities in different namespaces and different packages. It
would be good practice to keep all your entity definitions in one
place and import them in the wsdl files as necessary. As far as I
understood, your solution would be better organization. I can be more
helpful through more detailed explanation of your approach.
Regards,
Kutsal
On 02.08.2011 12:40, Liter András (SCTR) wrote:
Dear user support,
I have a question about generating webservice client code with
wsdl2java.
In my scenario I have more WSDLs, which work on the same set of
entities on the server side. When I generate the client code for these
WSDLs I have the same entities multiple times in different packages
according to the namespaces of my webservices. Since I want to use
more services on the client side, I bump into the problem of these
multiple entities, and therefore after every interface change I have
to refactor the generated client code to work with a simple set of
generated entities/business objects (I move them to a different
package, delete the duplicates and refactor the other classes to use
the moved entities).
I hope my I declared my problem clearly. Do you know some workaround
to avoid this refactoring overhead? Maybe some parameter for
wsdl2java? Or some kind of other approach?
Thanks in advance!
Best regards,
*Liter András
*IT szakértő
E-mail: [email protected]<mailto:[email protected]>
Mobil: +36-20-515-0556
Leírás: Description: Description: Description: Grepton-logo2010
*GREPTON Informatikai Zrt.**
*H-1116 Budapest, Kondorfa u. 10.
Tel.: +36-1-204-7730
Fax: +36-1-204-7731
www.grepton.hu<http://www.grepton.hu/>
*Gondoljon környezetére, mielőtt kinyomtatja! *
Ezen üzenet és annak bármely csatolt anyaga bizalmas, jogi védelem
alatt áll, a nyilvános közléstől védett. Kérjük látogassa meg
honlapunk Adatvédelmi nyilatkozatmenüpontját a levéllel kapcsolatos
további információért.
