Hi Tom,

I didn't write it, but here's my explanation:

TransportClientProperties and other things like it in Axis use the JDK
"Service Provider discovery" mechanism that was introduced in java 1.3.

You can read about SPI discovery here:
http://java.sun.com/j2se/1.3/docs/guide/jar/jar.html#Service%20Provider

You can read about commons-discovery's implementation of this functionality
here:
http://jakarta.apache.org/commons/discovery/apidocs/org/apache/commons/disco
very/strategy/DefaultDiscoverStrategy.html

Basically the way it works is this:  axis has a number of subsystems that
can be replaced with plugins at deployment time.  A pluggable subsystem is
defined by a java interface -- the "service provider interface" -- and
concrete plugins implement that interface in order to become providers of
whatever service is at issue (in your case, TransportClientProperties).

Now those service provider implementations need a way of getting hooked into
the axis runtime, which is where discovery comes into play.   When the
runtime needs to find an implementation of a particular service, it uses
that service's factory to search for a suitable implementation.  In your
case, the factory that initiates the search is called
TransportClientPropertiesFactory (for the remainder of this note abbreviated
as TCPFactory), which is a fairly simple (read: straightforward) example of
the process -- in some cases, these factories implement more complex
strategies for determining whether a given implementation is OK for use in a
particular circumstance.

As you can see by reading TCPFactory, it maintains a cache of transport
protocols -> implementations.  It finds the implementations by doing a
discovery-based search that, if it finds no other implementations, falls
back on the Default{HTTP,HTTPS}TransportClientProperties implementations,
which are assumed to be always present.

So, if you wanted TCPFactory to use your implementation instead, you'd
implement the TransportClientProperties interface and then "register" it as
an SPI so that the discovery process will find it.  You'd register it by
creating a "provider configuration" file in the manner described in the
first link I listed above:  it goes in
META-INF/services/org.apache.axis.components.net.TransportClientProperties
and contains the name(s) of your class(es) that implement the SPI.

Hope this helps,
Eric

-----Original Message-----
From: Tom Jordahl [mailto:[EMAIL PROTECTED]
Sent: Tuesday, March 25, 2003 6:37 AM
To: '[EMAIL PROTECTED]'
Subject: RE: what version of commons-discovery is being used in the
latest version?



It would be great if anyone could understand how it works and what it does
in more than the abstract sense.  I've been hip deep in it for the past few
day trying to figure out how to override the TransportClientProperties
class.

I guess complex systems (J2EE servers) require complex solutions....
:-(

--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Sanjiva Weerawarana [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, March 25, 2003 8:38 AM
To: [EMAIL PROTECTED]
Subject: Re: what version of commons-discovery is being used in the latest
version?

Never mind .. I looked into it and found out. Looks like a good
idea ..

Sanjiva.

----- Original Message -----
From: "Sanjiva Weerawarana" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Tuesday, March 25, 2003 10:46 AM
Subject: Re: what version of commons-discovery is being used in the latest
version?


> Sorry for the dumb question, but what does commons-discovery do
> and what purpose does it serve for Axis?
>
> Sanjiva.
>
> ----- Original Message -----
> From: <[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]>
> Sent: Tuesday, March 25, 2003 1:55 AM
> Subject: what version of commons-discovery is being used in the latest
> version?
>
>
> > The version of commons-discovery.jar in the latest axis drops is
different
> > from the last version available from the jakarta website for the
discovery
> > project.  What version does axis currently require?
> >
> > Eric

Reply via email to