You are viewing a plain text version of this content. The canonical link for it is here.
Posted to java-user@axis.apache.org by de...@areujoking.com on 2005/04/06 07:46:42 UTC

Configuring an independent Axis client

Hi All,

This question seems to continue the fine tradition of confusion over
configuring an Axis client's properties.

The situation is that I am writing a client that can be provided to people
to use in their applications. This client essentially consumes a web
service that I publish so that they can be serviced by it. The client uses
Axis and does authentication of identities and encryption of data using
SSL (JSSE).

I know that I can use AxisProperties to change the behaviour of the
client, such as:

AxisProperties.setProperty("axis.socketSecureFactory",
"test.AXISSocketFactory");

to change the socket factory that the client uses to create SSL
connections, but this approach is still isn't targeted enough.

The problem is that my client software cannot make any assumptions about
where it is getting called from. It can be in its own JVM (the easiest
case), or it can be deployed in an app server as part of another app. If
that other app also uses Axis, a problem arises. By setting
AxisProperties.setProperty(foo, bar) I am setting foo = bar for any Axis
implementation running in the classloader I am part of (this information
coming from the AxisProperties JavaDoc page).

This means that System.setProperty(), AxisProperties.setProperty() and any
java -Dblah won't work - they're all too heavy handed (not targeted
enough)

So my question is, is there a way to even further narrow the effect of an
Axis client configuration to my client alone. Or is my only hope to
confine my client to its own classloader? (tried this and ran into
problems with calling the instantiated class from the main app's
classloader - ClassCastExceptions - naturally)

I seem to have read everything I can find on the topic, but nobody seems
to have addressed this finely grained configuration requirement yet. There
must be a way to do this, I'm just not having much luck finding it.

Thanks,
Deakin.