It's not strange at all. The java2ws command takes a classpath
argument to which you have to supply the precise list of jars and
directories that are in the classpath of your live application. This
indicates that you aren't giving the command line the same classpath.
On Tue, Dec 2, 2008 at 2:18 PM, hakan eryargi <[EMAIL PROTECTED]> wrote:
> if you are asking if my classes are loaded from same location, yes i'm
> sure. i know such things happen all the time but i'm pretty
> experienced with java
>
> but, if you are asking for the environment (other libraries) it's
> another story. this application runs a ibm filenet client and hence
> includes lots of websphere jars. some of them conflict with cxf jars.
> i cleaned up the classpath as far as i can. at least my app starts up
> and runs now without exceptions
>
> but to be sure, i ran Java2WS within my application with same
> arguments and it created a correct wsdl file. quite strange isnt't it
> ? below is the code piece. attached are java2ws output and auto
> generated wsdl files
>
> String[] args = new String[] {
> "-verbose", "-wsdl",
> "-d", "C:\\raft",
> "-frontend", "jaxws",
> "-databinding", "jaxb",
> "-servicename", "TellcomWebService",
> "-address",
> "http://10.0.0.10:8080/TellcomWeb/TellcomWebService";,
> "ebit.tellcom.service.web.TellcomWebService"
> };
> JavaToWS.main(args);
>
> regards,
> r a f t
>
> On Tue, Dec 2, 2008 at 8:33 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:
>> You don't have any endpoint features (such as data binding
>> customizations) that would explain a discrepancy.
>>
>> So I'm left wondering if you are perfectly sure that the classpath is
>> the same in the two cases.
>>
>>
>> On Tue, Dec 2, 2008 at 1:26 PM, raft <[EMAIL PROTECTED]> wrote:
>>>
>>> hi,
>>>
>>> i'm not sure i correctly understand the notion here. what exacty do you mean
>>> by service factory options/settings ? are they the one defined at endpoint ?
>>> my endpoint definition, interface and implementation is below. once again if
>>> required i can send my data types too
>>>
>>> <jaxws:endpoint
>>> id="tellcomWebService"
>>> implementor="#webService"
>>> address="/TellcomWebService" >
>>>
>>> <jaxws:features>
>>> <bean class="org.apache.cxf.feature.LoggingFeature"/>
>>> </jaxws:features>
>>>
>>> <jaxws:properties>
>>> <entry key="schema-validation-enabled" value="false"
>>> />
>>> </jaxws:properties>
>>>
>>> </jaxws:endpoint>
>>>
>>> this is my endpoint interface:
>>>
>>> @WebService(targetNamespace = TellcomWebService.NAME_SPACE)
>>> public interface TellcomWebService {
>>> public static final String NAME_SPACE =
>>> "http://web.service.tellcom.ebit.aas/";;
>>>
>>> /** returns a list of documents for given musteriNo */
>>> public DocumentListDto getDocuments(@WebParam(name="musteriNo")
>>> String
>>> musteriNo) throws Exception;
>>>
>>> // just for testing
>>> public String echo(String message) throws Exception;
>>> }
>>>
>>> and this is the implementation, in a different package:
>>>
>>> @WebService(name="TellcomWebService",
>>> endpointInterface =
>>> "ebit.tellcom.service.web.TellcomWebService",
>>> targetNamespace = TellcomWebService.NAME_SPACE )
>>> public class TellcomWebServiceImpl implements TellcomWebService {
>>>
>>> // methods are omited
>>> }
>>>
>>> r a f t
>>>
>>>
>>> Hakan,
>>>
>>> The ?wsdl generator is 'configured' by the sum of all your @nnotations
>>> plus whatever options you supply to the service factory. Generally, a
>>> discrepancy of this kind results from service factory options, since
>>> the @nnotations are equally visible to the tools and the dynamic
>>> runtime.
>>>
>>> Have you posted your service endpoint configuration?
>>>
>>> --benson
>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/configuring-the-WSDL-generator-at-serviceUrl-wsdl-tp20703988p20798085.html
>>> Sent from the cxf-user mailing list archive at Nabble.com.
>>>
>>>
>>
>
