Mailing-List: contact dev-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Received-SPF: pass (nike.apache.org: local policy)
From: Seumas Soltysik <SSOLTYSI@progress.com>
To: "dev@cxf.apache.org" <dev@cxf.apache.org>
Date: Mon, 15 Nov 2010 11:57:24 -0500
Subject: Issue with SoapTransportFactory
Thread-Topic: Issue with SoapTransportFactory
Thread-Index: AQHLhOYslO4mAbxWc0O7GuNO8GCAnA==
Message-ID: 
 <ABBE4269CA3ED642B3BC060956A29D0F01125D75A6@PSCMAIL02.bedford.progress.com>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0

SoapTransportFactory extends AbstractTransportFactory which contains a prot=
ected Bus data member. However, SoapTransportFactory has its own private Bu=
s data member and does not make use of the Bus data member inherited from A=
bstractTransportFactory. Why is this? Is this done on purpose or is this an=
 oversight?

public class SoapTransportFactory extends AbstractTransportFactory implemen=
ts DestinationFactory,
    WSDLEndpointFactory, ConduitInitiator {   =20
    private Bus bus;
}

public abstract class AbstractTransportFactory {
    protected Bus bus;
}

In a testcase that I am developing this has led to problems. If I initializ=
e an instance of SoapTransportFactory using the cxf-extension-soap.xml conf=
iguration,  setTransportIDs() is called on the base class AbstractTransport=
Factory which ultimately calls register() which registers the transport IDs=
 with the bus:

    public final void register() {
        if (null =3D=3D bus) {
            return;
        }
        if (this instanceof DestinationFactory) {
            DestinationFactoryManager dfm =3D bus.getExtension(DestinationF=
actoryManager.class);
            if (null !=3D dfm && getTransportIds() !=3D null) {
                for (String ns : getTransportIds()) {
                    dfm.registerDestinationFactory(ns, (DestinationFactory)=
this);
                }
            }
        }

However, because AbstractTransportFactory has its own Bus instance, which i=
s not initialized and therefore null, the transport IDs are never registere=
d with the Bus instance that is visible to the SoapTransportFactory. I thin=
k this issue has been disguised by the fact that usually SoapTransportFacto=
ry is not initialized without initializing other transport factories which =
do the right thing registering namespaces with the Bus.