custom transport hard-coding issue?

[Maenner Philipp <ph...@siemens.at>]

Hi, 
Just started using Axis like 4 weeks ago and I must say that I'm amazed how
well this engine works.
I am working on implementing a custom transport handler for Axis and I
started testing
and modifying the really well documented TCP transport sample code from the
axis src distribution.
My problem is that I see no way to deploy a custom transport protocol
handler *only*  by using WSDD in Axis.
I see this as a major drawback, but it will take a few lines to explain why
I feel this way:

Generally when handling some custom transport protocol on the client side,
there are two things to do:
1. registering the custom protocol itself by deploying a sub-class of
Transport
2. deploying a pivot handler for this protocol which is used for
sending/receiving the data. 

step1 is done by adding the following lines to the application code: 
Call.addTransportPackage("<transport package name>");
Call.setTransportForProtocol("<protocol name>","<exact transport class
name>");

step2 is done programatically roughly by the following code:
EngineConfiguration defaultConfig = 
EngineConfigurationFactoryFinder.newFactory().getClientEngineConfig();
SimpleProvider config = new SimpleProvider(defaultConfig);
SimpleTargetedChain c = new SimpleTargetedChain(new <protocol handler
class>);
config.deployTransport("<protocol name>", c);
Service service = new Service(config);

Even better, step 2 can be done in WSDD instead of in SRC by using the
following syntax for deployment:
<transport name="<protocol-name>" pivot="<exact sender class name>" />

I see it as a big limitation that there is no way to translate the code in
step1 to WSDD,
as in step2. It means that for every client application that shall support a
custom protocol, 
I'd have to go and modify it's source-code by adding (at least) these two
lines.
Expressing step2 in WSDD is great, but that doesn't really save me much when
I still have to
register the Transport class (step1) first by hard-coding it into the app.
This really reduces maintainability when it comes to using custom transport
handlers.

A good example of why this is annoying is in
samples.transport.tcp.AdminClient. 
Correct me if I'm wrong, but it seems like this class only exists because
there is no way to express 
in WSDD that a TCPTransport should be loaded and registered when tcp:// is
used in the Endpoint Address.
So, so the original AdminClient had to be sub-classed as a work-around.
Just imagine that for each custom transport protocol you implement, you'd
have to write your own little
AdminClient class only to even be able to list the deployed services on an
Axis Server.....

I also see this as a design issue in that you'd have to know in advance
which custom underyling protocol you want to 
support when writing any Axis client code, which in turn isn't really what I
call transport-independent.

I digged through the transport-specific source code of Axis and unless I
missed something there is no
way of circumventing this as of now. However I am confident it must be
possible to extend Axis in a way
that supports complete transport-independency regarding the client
application code.

Any thoughts on that issue are appreciated.
I hope that you understand my concerns, if something is unclear feel free to
ask me anything you like.

Regards,
Philipp Maenner

PS: Should I post this on the dev list?