RE: what version of commons-discovery is being used in the latest version?

[Richard Sitze <rs...@us.ibm.com>]

Sorry, coming in late on this conversation...  If you require *more* 
dynamic behaviour that offered by straight discovery, go browse through 
the EngineConfigurationFactoryFinder for an example of one strategy.

<ras>

*******************************************
Richard A. Sitze
IBM WebSphere WebServices Development




Tom Jordahl <to...@macromedia.com>
03/25/2003 12:31 PM
Please respond to axis-dev
 
        To:     "'axis-dev@ws.apache.org'" <ax...@ws.apache.org>
        cc: 
        Subject:        RE: what version of commons-discovery is being 
used in the latest       version?



Thanks Eric for a pretty clear description of what is going on.

I did, in fact, figure most of that out on my own yesterday.  In 
particular, the "how" of discovery is detailed in the integration.html 
file in the Axis documentation.  It was a good check of my understanding 
to read your write up however.  Thanks again.

One thing that occurs to me about this particular plug point is that the 
TCPFactory doesn't pass the protocol to the replacement TCP.  What I mean 
by this is that the *defaults* differ based on protocol, but my 
replacement class has to handle both cases.  This is a bummer.  It would 
be better if the TCP constructor was passed this argument, but of course 
that would break the API.

By the way, the reason I am overriding this class is to support 
per-request proxy configuration.  I now have this working, complete with 
the Service Provider file, so I am happy.

--
Tom Jordahl
Macromedia Server Development

-----Original Message-----
From: Eric.D.Friedman@WellsFargo.COM 
[mailto:Eric.D.Friedman@WellsFargo.COM] 
Sent: Tuesday, March 25, 2003 1:17 PM
To: axis-dev@ws.apache.org
Subject: RE: what version of commons-discovery is being used in the latest 
version?

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:tomj@macromedia.com]
Sent: Tuesday, March 25, 2003 6:37 AM
To: 'axis-dev@ws.apache.org'
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:sanjiva@watson.ibm.com] 
Sent: Tuesday, March 25, 2003 8:38 AM
To: axis-dev@ws.apache.org
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" <sa...@watson.ibm.com>
To: <ax...@ws.apache.org>
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: <Er...@WellsFargo.COM>
> To: <ax...@ws.apache.org>
> 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