Mailing-List: contact issues-help@cxf.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cxf.apache.org
Date: Fri, 27 Jan 2012 01:12:39 +0000 (UTC)
From: "Daniel Kulp (Resolved) (JIRA)" <jira@apache.org>
To: issues@cxf.apache.org
Message-ID: 
 <1585331629.83614.1327626759252.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <1023543305.81824.1327595078515.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Resolved] (CXF-4066) AbstractTransportFactory registers
 itself as extension, before being fully initialized
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/CXF-4066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Daniel Kulp resolved CXF-4066.
------------------------------

       Resolution: Fixed
    Fix Version/s: 2.5.3
                   2.4.7
    
> AbstractTransportFactory registers itself as extension, before being fully initialized
> --------------------------------------------------------------------------------------
>
>                 Key: CXF-4066
>                 URL: https://issues.apache.org/jira/browse/CXF-4066
>             Project: CXF
>          Issue Type: Bug
>    Affects Versions: 2.4.5, 2.5.2
>            Reporter: Vitaliy Garnashevich
>            Assignee: Daniel Kulp
>             Fix For: 2.4.7, 2.5.3
>
>
> AbstractTransportFactory calls register() at the end of its constructor, to register itself as a DestinationFactory and/or as a ConduitInitiator. Classes that extend AbstractTransportFactory (e.g. HTTPTransportFactory), and which call super's constructor, have no way to properly initialize, before being exposed as an extension. Such classes must call super() constructor, before initializing their fields.
> This could lead to concurrency issues, when such object is used as an extension, before being fully initialized. Here is a stack trace of such problem:
> java.lang.NullPointerException
>         at org.apache.cxf.transport.http.HTTPTransportFactory.getDestination(HTTPTransportFactory.java:261)
>         at org.apache.cxf.binding.soap.SoapTransportFactory.getDestination(SoapTransportFactory.java:134)
>         at org.apache.cxf.endpoint.ServerImpl.initDestination(ServerImpl.java:93)
>         at org.apache.cxf.endpoint.ServerImpl.<init>(ServerImpl.java:72)
>         at org.apache.cxf.frontend.ServerFactoryBean.create(ServerFactoryBean.java:158)
>         at org.apache.cxf.dosgi.dsw.handlers.PojoConfigurationTypeHandler.createServer(PojoConfigurationTypeHandler.java:143)
>         at org.apache.cxf.dosgi.dsw.hooks.ServiceHookUtils.createServer(ServiceHookUtils.java:86)
>         at org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.createServer(CxfPublishHook.java:106)
>         at org.apache.cxf.dosgi.dsw.hooks.CxfPublishHook.publishEndpoint(CxfPublishHook.java:80)
>         at org.apache.cxf.dosgi.dsw.Activator$1.run(Activator.java:164)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
>         at java.lang.Thread.run(Thread.java:662)
> Here, the HTTPTransportFactory.getDestination() method, implementing DestinationFactory interface, is called before HTTPTransportFactory's "registry" field is assigned by constructor.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira