cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Shaw, Richard A" <richard.s...@atkinsglobal.com>
Subject RE: loadAndRegister transport factories
Date Fri, 22 Sep 2006 01:29:17 GMT
A stack trace would not help. What happens is that my transport is added to the list deferred
extensions, and is then never loaded and registered.

When the code searches the conduit factory it isn't there because it wasn't loaded so I get
an exception. The problem had happened long before.

Richard Shaw

¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤

Richard Shaw  
Technical Design Authority - Information Solutions Consultancy  
Intelligent Transport Systems 

Atkins Highways and Transportation 
Woodcote Grove, Ashley Road, Epsom, Surrey, KT18 5BW

Tel: +44 (0) 1372 756407 
Fax: +44 (0) 1372 740055
Mob: 07740 817586 
E-mail: richard.shaw@atkinsglobal.com

www.atkinsglobal.com/its

-----Original Message-----
From: James Mao [mailto:james.mao@iona.com] 
Sent: 21 September 2006 09:04
To: cxf-dev@incubator.apache.org
Subject: Re: loadAndRegister transport factories


> Below is my wsdl. What I can't work out is how does it decide from the WSDL which bit
defines the transport. Is it the first item inside the service/port section ? In which case
the namespace is "ftp" and it matches my bus-extension.
>
>   
yes, it's the ftp namespace, seems the wsdl def,and your bus-extension use the same transport
namespace, should load the ftptransportfactory. 
strange.
> I made everything work by adding the binding namespaces to my tranport in bus-extensions,
just like the http transport does. But this can't be correct because it implies that if a
new binding is created then it must be added to the transports bus-extensions file - which
is add unnecessary coupling.
>
>   
you mean when you add the namespace  http://cxf.apache.org/bindings/xformat

and then your demo works with xml/ftp? or you just test the server, can the whole demo works
as you expected?

The binding is loaded by the BindingTYPE annotation in your impl class, and the transport
is loaded by the ***:address namespace.

Do you have exception stacktrace, or log may help to find the postion.

My pc broken, so i can check the code today. i'll check it later.

> <?xml version="1.0" encoding="UTF-8"?> <!--WSDL file template--> 
> <!--Created by IONA Artix Designer--> <definitions name="ftptest.wsdl"
> 	targetNamespace="http://www.atkinsglobal.com/mosaic/ftptransport"
> 	xmlns="http://schemas.xmlsoap.org/wsdl/" 
> 	xmlns:http="http://schemas.xmlsoap.org/wsdl/http/"
> 	xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" 
> 	xmlns:tns="http://www.atkinsglobal.com/mosaic/ftptransport"
> 	xmlns:wsdl="http://schemas.xmlsoap.org/wsdl/" 
> 	xmlns:x1="http://www.atkinsglobal.com/mosaic/ftptransport/types"
> 	xmlns:xformat="http://cxf.apache.org/bindings/xformat"
> 	xmlns:ftp="http://cxf.apache.org/transports/ftp"
> 	xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> 	<types>
> 		<schema attributeFormDefault="unqualified" elementFormDefault="qualified"
> 			targetNamespace="http://www.atkinsglobal.com/mosaic/ftptransport/types" 
> 			xmlns="http://www.w3.org/2001/XMLSchema"
> 			xmlns:x1="http://www.atkinsglobal.com/mosaic/ftptransport/types" 
> 			xmlns:xs="http://www.w3.org/2001/XMLSchema">
>
> 			<element name="LoadTestData">
> 				<complexType></complexType>
> 			</element>
>
> 			<element name="TestData">
> 				<complexType>
> 					<sequence>
> 						<element name="sample" maxOccurs="unbounded">
> 							<complexType>
> 								<sequence>
> 									<element name="a" type="xsd:string" />
> 									<element name="b" type="xsd:string" />
> 									<element name="c" type="xsd:string" />
> 								</sequence>
> 							</complexType>
> 						</element>
> 					</sequence>
> 				</complexType>
> 			</element>
>
> 			<element name="TestDataFaultResponse">
> 				<complexType>
> 					<sequence>
> 						<element name="faultInfo" type="xsd:string" />
> 					</sequence>
> 				</complexType>
> 			</element>
>
> 		</schema>
> 	</types>
>
> 	<wsdl:message name="LoadTestData">
> 		<wsdl:part name="LoadTestData" element="x1:LoadTestData"></wsdl:part>
> 	</wsdl:message>
> 	<wsdl:message name="TestData">
> 		<wsdl:part name="TestData" element="x1:TestData"></wsdl:part>
> 	</wsdl:message>
> 	<wsdl:message name="TestDataFault">
> 		<wsdl:part name="TestDataFault" element="x1:TestDataFaultResponse"></wsdl:part>
> 	</wsdl:message>
> 	<portType name="LoadTestDataI">
> 		<operation name="LoadTestData">
> 			<input message="tns:LoadTestData" name="LoadTestData" />
> 			<output message="tns:TestData" name="TestData" />
> 			<fault message="tns:TestDataFault" name="TestDataFault" />
> 		</operation>
> 	</portType>
>
> 	<binding name="LoadTestDataISOAPBinding" type="tns:LoadTestDataI">
> 		<xformat:binding/>
> 		<operation name="LoadTestData">
> 			<ftp:address location="file:///D:/cxf-deployment/workspace/FTPTransport/test/test.xml"
/>
> 			<input name="LoadTestData"></input>
> 			<output name="TestData"></output>
> 			<fault name="TestDataFault"></fault>
> 		</operation>
> 	</binding>
>
> 	<service name="LoadTestDataService">
> 		<port binding="tns:LoadTestDataISOAPBinding" name="LoadTestDataPort">
> 			<ftp:address location="file:///D:/cxf-deployment/workspace/FTPTransport/test/fail.xml"
/>
> 		</port>
> 	</service>
> </definitions>
>
>
> Richard Shaw
>
> ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤
>
> Richard Shaw
> Technical Design Authority - Information Solutions Consultancy 
> Intelligent Transport Systems
>
> Atkins Highways and Transportation
> Woodcote Grove, Ashley Road, Epsom, Surrey, KT18 5BW
>
> Tel: +44 (0) 1372 756407
> Fax: +44 (0) 1372 740055
> Mob: 07740 817586
> E-mail: richard.shaw@atkinsglobal.com
>
> www.atkinsglobal.com/its
>
> -----Original Message-----
> From: James Mao [mailto:james.mao@iona.com]
> Sent: 21 September 2006 04:49
> To: cxf-dev@incubator.apache.org
> Subject: Re: loadAndRegister transport factories
>
> I guess you already enabled the transport factory to allow inject the resource, if so
it should allow your to load your transport plugin, just specify the transport uri into the
bus-extension.
>
> And the rt should looking for the addresss uri in your wsdl as the transport id, i guess
the address uri in your wsdl is different from the one you specified in bus-extension.
>
> You just gave the snippet of the bus-extension. can you also gave the snippet of your
wsdl:service. that might help to find the problem.
>
> Cheers,
> James.
>
> Shaw, Richard A 写道:
>   
>> Why are the transport factory extensions loaded using the binding namespaces ?
>>
>> My transport extension has the following bus-extensions.xml file -
>>
>> <?xml version="1.0" encoding="UTF-8"?>
>>
>> <extensions xmlns="http://cxf.apache.org/bus/extension">
>>
>>     <extension class="org.apache.cxf.transport.ftp.FTPTransportFactory" deferred="true">
>>         <namespace>http://cxf.apache.org/transports/ftp</namespace>
>>     </extension>
>> </extensions>
>>
>>
>> And it never gets loaded. If I add binding namespace that I'm using then it gets
loaded. I'm using xformat binding at the moment.
>>
>>
>>
>> Richard Shaw
>>
>> ¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤º°`°º¤ø¤º°`°º¤ø,¸¸,ø¤
>>
>> Richard Shaw
>> Technical Design Authority - Information Solutions Consultancy 
>> Intelligent Transport Systems
>>
>> Atkins Highways and Transportation
>> Woodcote Grove, Ashley Road, Epsom, Surrey, KT18 5BW
>>
>> Tel: +44 (0) 1372 756407
>> Fax: +44 (0) 1372 740055
>> Mob: 07740 817586
>> E-mail: richard.shaw@atkinsglobal.com
>>
>> www.atkinsglobal.com/its
>>
>> -----Original Message-----
>> From: Liu, Jervis [mailto:jliu@iona.com]
>> Sent: 20 September 2006 08:01
>> To: cxf-dev@incubator.apache.org
>> Subject: RE: tooling and service model
>>
>>
>>
>>   
>>     
>>> -----Original Message-----
>>> From: Dan Diephouse [mailto:dan@envoisolutions.com]
>>> Sent: Wednesday, September 20, 2006 1:00 PM
>>> To: cxf-dev@incubator.apache.org
>>> Subject: Re: tooling and service model
>>>
>>>
>>> James Mao wrote:
>>>
>>>     
>>>       
>>>> Hi Dan,
>>>>
>>>>       
>>>>         
>>>>> I would like to start a set of parallel tool modules. Say create a 
>>>>> directory called tools2 and get things working there. Once we're 
>>>>> ready we can work on switching the whole build to the new tools.
>>>>>         
>>>>>           
>>>> The tools2 will include all the functions in cxf tools?
>>>>       
>>>>         
>>> And more :-)
>>>
>>>     
>>>       
>>>> and how long will it take? 
>>>>       
>>>>         
>>> Depends on how fast we can type :-)
>>>
>>>     
>>>       
>>>> and when we say switching you mean include porting all the
>>>>       
>>>>         
>>> unit tests
>>>     
>>>       
>>>> and system tests to the tools2? and also make demos work properly.
>>>> So, your goal is to replace cxf tools with tools2?
>>>>       
>>>>         
>>> Yes, yes, yes.
>>>
>>>     
>>>       
>>>> or let user choose which one they want to use?
>>>>       
>>>>         
>>> No.
>>>
>>>     
>>>       
>>>> But i really have a question why we need to create another
>>>>       
>>>>         
>>> tools when
>>>     
>>>       
>>>> the current tools works perfectly fine?
>>>>       
>>>>         
>>> Because they don't work fine. I believe we had this discussion 
>>> before...
>>> Please see the previous threads on tooling.
>>>
>>>     
>>>       
>> I do remember we had some discussions before regarding CXF tooling, but as far as
I can recall, I do not think we are anywhere close to reach a conclusion that CXF tools need
to be totally rewritten. 
>>
>>
>>   
>>     
>>> If you want to try to refactor the current tools in place, I suppose 
>>> we could try that. But its a pretty drastic change, so I don't 
>>> really see a step-wise process to do it. I think it would be better 
>>> to just write a second set of tools, then when they're ready switch 
>>> everythign over and delete the old tools.
>>>
>>>     
>>>       
>> Refactoring current tooling or writing a brand-new one are both ok as the ultimate
goal is to have a better tooling. But it would appear to be too early to tore down everything
we already have and invent the wheel from scratch before we can answer questions below:
>>
>> 1. Identify exact problems in our current tooling, and what problems can be resolved
through refactoring and what problems can not be resolved elegantly as it is due to core architecture.

>>
>> I just went through our mailing list and found following tooling relevant discussions,
do let me know if I am missing anything.
>>
>> a. CXF tools need to support WSDL2.0
>> b. CXF tools need to support SOAP1.2
>> c. We need to reuse Service Model in tools, this will bring us WSDL2.0 and SOPA1.2.
There were some discussions around how to do this. One proposed approach is moving Service
Model as a top level module, one is using Service Model as a plug-in. To me, they are implementation
details and we shall be able to figure out which way is more appropriate when we are doing
this work. 
>> d. Support multiple databindings and multiple front-end profiles generations. With
the code merged from XFire code base, the current CXF tools should have this capability in
place already. 
>>
>> Based on this observation, I feel a refactoring is a more practical approach, doing
(a)(b)(c) should be a one week work. At the same time, I have to say some interfaces in our
current tools are a bit confusing, for example, the ToolsContainer interface. This makes new
developers hard to following the tooling architecture in order to do their contributions.
I suggest we do another refactoring on this after getting service Model done. But overall,
I do not see any critical problems that can not resolved through refactorings based on the
information I have right now. 
>>
>> 2. If we are to write a new tool from scratch, what are the feature list we have
in mind, and how long do we expect to reach this feature list. 
>>
>> To be honest, I do not really think writing a new tool and make it has all features
we already have is that simple. For example, current wsdl2java give us following options:
>>
>> Usage : wsdl2java -p <[wsdl namespace =]Package Name>* -b
>> <binding-name>* -d <output-directory> -compile -classdir <comp
>> ile-classes-directory> -impl -server -client -all -ant -nexclude 
>> ile-classes-directory> <schema namespace [= java packagename]>* -exsh 
>> ile-classes-directory> <enable
>> extended soap header message binding (true, false)> -dns <Default 
>> value is true> -dex <Default value is true> -validate -h -v -verbose 
>> -quiet <wsdlurl>
>>
>> In my experience, a good tool can not turn out in weeks or even in months(presume
it already has a good architecture core), it is a time consuming work, it needs daily and
sometimes tedious work to add features, fix bugs and tune around based on users/customers'
input and real use cases.  Looking at the type test, interop test and the set of system tests
(which are based various bugs discovered by ourselves and customers/users), you will probably
feel our current tools are gradually reaching a mature status. I am pretty sure writing sth
from scratch can always bring better architecture as we can learn a lot from past, but what
is cost? How long do we expect the new tool can reach a same mature status?
>>
>>
>>
>>   
>>     
>>>>> I'm in the midst of refactoring this now. I probably won't get the 
>>>>> code in until tomorrow though. I'll try to explain once I get it 
>>>>> finished :-)
>>>>>
>>>>>         
>>>>>           
>>>> Cool, just make sure all the system tests and demos working
>>>>       
>>>>         
>>> properly.
>>>
>>> I don't usually test demos when I do commits. That would really slow 
>>> down the development process. If there is something in the demos 
>>> that isn't covered in the tests, you should add it.
>>>
>>> - Dan
>>>
>>> --
>>> Dan Diephouse
>>> (616) 971-2053
>>> Envoi Solutions LLC
>>> http://netzooid.com
>>>
>>>
>>>     
>>>       
>> This message has been scanned for viruses by MailControl - (see
>> http://bluepages.wsatkins.co.uk/?4318150)
>>
>>
>> This email and any attached files are confidential and copyright protected. If you
are not the addressee, any dissemination of this communication is strictly prohibited. Unless
otherwise expressly agreed in writing, nothing stated in this communication shall be legally
binding.
>>
>>   
>>     
>
>   

Mime
View raw message