Hi Vijay,
Thanks for the response.
I have seen your tech tip and benefited from it.
My first reluctant attempt with code-first approach turned out to be a
good experience. Except for a few things, in general it looks good. One
concern is that in order to generate client artefacts service has to be
deployed. In overcome this issue I am thinking of using "wsgen" after
"apt" to generate wsdl then use that wsdl to generate client artefacts.
The reason I wanted to go for contract first is because the application
we are developing is the entity who define the service interface (so in
web services it is wsdl) despite being the consumer of the services.
Ours is an application which collates information from similar
applications used in a particular business domain. Any company involved
in this business can collaborate with us, provided they expose the
services through web service which conforms to our wsdl. In this way our
service invocation code will remain same and can use a common service
locator, just a matter of changing address (hostname and port).
You might be wondering why I am interested in both service and client
deployment/code generation activities. Because one of the participating
enterprise app servers happened to be ours.
What I would like to do is: (We are using maven build system)
Interface subproject (say interface.jar) : input artefact wsdl file. All
data binding class files are generated through wsimport.
Service subproject (wsservice.jar): input artefact is Impl file. Service
related artefacts generated by using wsdl file and data binding classes
in the interface.jar
Client subproject (wsclient.jar) : no input artefact. All classes
required in the client side will be generated by using the wsdl in
interface.jar. Data binding classes need not be generated, since it is
already there in interface.jar
This way interface.jar will be used both in the server side and client
side.
Is it possible to generate only the data binding class files using
wsimport?
I guess in order to achieve the above, I have to do filtering when
packaging the artefacts into the jar.
Vijesh
-----Original Message-----
From: Vijay Ramachandran [mailto:Vijay.Ramachandran_at_Sun.COM]
Sent: 16 October 2006 22:01
To: users_at_jax-ws.dev.java.net
Subject: Re: Contract First approach in JAX-WS 2.0
BTW, for more information on moving your JAXWS-RI specific service to a
portable one, refer to this :
http://java.sun.com/developer/EJTechTips/2006/tt0429.html#1
Hope this helps
Vijay
Vijay Ramachandran wrote:
>
>> I used JAX-WS 2.1 RI for Contract-First approach and it worked
>> beautifully. This being non portable makes it less attractive. BTW,
>> can I use this in production environment? If so, how much/what
changes
>> should I have to do to make it portable later?
>
> JAXWS2.1 will be available as part of GlassFish-V2 from build 24
onwards.
>
>> I understand that portable JAX-WS can be developed/deployed in
>> Glassfish. But it seems to be in favour of Code-First approach.
>>
>
> That is not true - GlassFish treats both the same way.
>
>> Probably a foolish attempt:
>> The same war created from JAX-WS RI is deployed in Glassfish after
>> removing sun-jaxw.xml and web.xml (don't know this is a proper way,
>> just an attempt). The server is not recognising the included wsdl,
>> instead it is looking for one with the name MyClassImplService.wsdl
>> (MyClassImpl being the endpoint implementation) !!!. I.e. as if the
>> deployed war for code-first approach!!!
>>
>
> This is because your service does not conform to JSR109 standard. Of
> course, a JAXWS2.1-RI based service (with the sun-jaxws.xml) will work
> as is on GF -but as far as GF is concerned, this is just a web app and
> this service is not portable across JavaEE platforms. So you should
> either use the same WAR that worked in stand alone JAXWS2.1RI or
> develop a proper 109-based service.
>
>> What could've went wrong?
>>
>> Also I don't find any example/article about using contract-first
>> approach in glassfish. I have a feeling that contract-first (top
>> down) is not recommended in EE5 (or at least in Glassfish).
>>
>
> That is not true - GF does not differentiate between the two
>
> Vijay
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
> For additional commands, e-mail: users-help_at_jax-ws.dev.java.net
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_jax-ws.dev.java.net
For additional commands, e-mail: users-help_at_jax-ws.dev.java.net