yes, as you said when i run java2ws inside my application it has the
same classpath with my application. we agree on this. what i'm saying
is, running java2ws this way produces the same result with running it
standalone (as ant task). this means with same classpath java2ws
generates correct wsdl but ?wsdl generator does not. and this means i
dont have a classpath issue, right ?

below is the classpath i used with my ant task.

                        <pathelement location="${lib}/aopalliance-1.0.jar" />
                        <pathelement 
location="${lib}/commons-logging-1.1.1.jar" />
                        <pathelement location="${lib}/log4j.jar" />
                        <pathelement location="${lib}/cxf-2.1.3.jar" />
                        <pathelement location="${lib}/FastInfoset-1.2.2.jar" />
                        <pathelement 
location="${lib}/geronimo-activation_1.1_spec-1.0.2.jar" />
                        <pathelement 
location="${lib}/geronimo-annotation_1.0_spec-1.1.1.jar" />
                        <pathelement 
location="${lib}/geronimo-javamail_1.4_spec-1.3.jar" />
                        <pathelement 
location="${lib}/geronimo-jaxws_2.1_spec-1.0.jar" />
                        <pathelement 
location="${lib}/geronimo-servlet_2.5_spec-1.2.jar" />
                        <pathelement 
location="${lib}/geronimo-stax-api_1.0_spec-1.0.1.jar" />
                        <pathelement 
location="${lib}/geronimo-ws-metadata_2.0_spec-1.1.2.jar" />
                        <pathelement location="${lib}/jaxb-api-2.1.jar" />
                        <pathelement location="${lib}/jaxb-impl-2.1.7.jar" />
                        <pathelement location="${lib}/neethi-2.0.4.jar" />
                        <pathelement location="${lib}/saaj-api-1.3.jar" />
                        <pathelement location="${lib}/saaj-impl-1.3.2.jar" />
                        <pathelement location="${lib}/spring-beans-2.0.8.jar" />
                        <pathelement location="${lib}/spring-context-2.0.8.jar" 
/>
                        <pathelement location="${lib}/spring-core-2.0.8.jar" />
                        <pathelement location="${lib}/spring-web-2.0.8.jar" />
                        <pathelement location="${lib}/wsdl4j-1.6.2.jar" />
                        <pathelement location="${lib}/wstx-asl-3.2.6.jar" />
                        <pathelement location="${lib}/xml-resolver-1.2.jar" />
                        <pathelement location="${lib}/XmlSchema-1.4.2.jar" />

On Tue, Dec 2, 2008 at 10:08 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:
> I'm saying, with all due respect, that I think that you've got a
> problem with classpath.
>
> When you run the Java2WS code from inside your application, you have
> the same classpath as your application.
>
> When you run it from command line, I think that you don't.
>
> When you run java2ws from command line, what are you supplying to the
> '-cp' command-line argument?
>
> http://cwiki.apache.org/CXF20DOC/java-to-ws.html
>
> On Tue, Dec 2, 2008 at 2:52 PM, hakan eryargi <[EMAIL PROTECTED]> wrote:
>> actually i didnt understand what you mean. i run java2ws within my
>> application which means it uses same classpath as my application. and
>> with that same classpath java2ws creates a correct wsdl but ?wsdl does
>> not.
>>
>> On Tue, Dec 2, 2008 at 9:41 PM, Benson Margulies <[EMAIL PROTECTED]> wrote:
>>> 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.
>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>

Reply via email to