Jens, What do the J2EE specs say about the classpath that app servers provide to deployed applications that use EARS? Are the EAR files guaranteed to be in the classpath, or is it just the jars contained within the EAR?
I use WAR files for deploying web applications, and I know that discovery works fine if I put the SP files in a place that is known to be available to my deployed application's classloader. So, for example, I can put the files here: <context-path>/WEB-INF/classes/META-INF/service/foo.bar.provider or here: <context-path>/WEB-INF/lib/inside-some-jarfile.jar/META-INF/service/foo.bar. provider I would not expect it to work if I put the provider file in the top of the war file itself: <context-path>/META-INF/service/foo.bar.provider.sure.to.go.unnoticed -----Original Message----- From: Jens Schumann [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 25, 2003 10:44 AM To: [EMAIL PROTECTED] Subject: Re: what version of commons-discovery is being used in the latest version? On 3/25/03 07:16 PM [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > Hi Tom, > > I didn't write it, but here's my explanation: > > > 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. > If axis plugability relies on this mechanism I doubt it will work on most application servers, since lookup of those filenames fails (see BUG 17347). Jens
