2016-11-16 1 views
0

Nous avons un service Web SOAP que nous migrons de JBoss EAP 5.1 vers 6.4.7 et un des services Web retourne absolument rien que 200 (dans JBoss 5). Lorsque nous avons migré à 6, cela fonctionne toujours et ne renvoie rien mais renvoie un 202 à la place et cela va casser les clients. Nous n'avons aucun contrôle sur les clients. J'ai essayé un SOAPHandler à la méthode close mais il ne fait rien car il n'est même pas appelé car je suppose que puisqu'il n'y a pas de message SOAP retourné il n'y a rien qui déclenche le gestionnaire.JBoss 6 EAP - remplace le code d'état de réponse HTTP dans un service SOAP qui renvoie une réponse vide de 202 à 200

J'ai également essayé d'accéder au contexte directement dans la méthode web et modif mais cela n'a rien fait.

MessageContext ctx = wsContext.getMessageContext(); HttpServletResponse response = (HttpServletResponse) ctx.get (MessageContext.SERVLET_RESPONSE); response.setStatus (HttpServletResponse.SC_OK);

Je n'ai rien trouvé dans le manuel.

Toute direction est très appréciée.

Voici comment le port et sa mise en œuvre ressemblent:

Voici comment le port et la tête de mise en œuvre ressemblent:

@WebService(name = "ForecastServicePortType", targetNamespace = "http://www.company.com/forecastservice/wsdl") 
@SOAPBinding(parameterStyle = SOAPBinding.ParameterStyle.BARE) 
@XmlSeeAlso({ 
    ObjectFactory.class 
}) 
public interface ForecastServicePortType { 


    /** 
    * 
    * @param parameters 
    * @throws RemoteException 
    */ 
    @WebMethod(action = "http://www.company.com/forecast/sendForecast") 
    public void sendForecast(
     @WebParam(name = "SendForecast", targetNamespace = "http://www.company.com/forecastservice", partName = "parameters") 
     SendForecastType parameters) throws RemoteException; 

} 



@WebService(name = "ForecastServicePortTypeImpl", serviceName = "ForecastServicePortType", endpointInterface = "com.company.forecastservice.wsdl.ForecastServicePortType", wsdlLocation = "/WEB-INF/wsdl/ForecastServicePortType.wsdl") 
@HandlerChain(file = "/META-INF/handlers.xml") 
public class ForecastServicePortTypeImpl implements ForecastServicePortType { 
... 

} 

Répondre

0

Dans le cas où tout le monde trouvera cela utile. Voici la solution.

Apache CXF utilise par défaut des requêtes asynchrones et même si l'annotation @OneWay est manquante, il se comporte toujours comme s'il y était.

Ainsi, afin de désactiver qu'un intercepteur doit être créé comme ci-dessous:

import org.apache.commons.logging.Log; 
import org.apache.commons.logging.LogFactory; 
import org.apache.cxf.binding.soap.SoapMessage; 
import org.apache.cxf.binding.soap.interceptor.AbstractSoapInterceptor; 
import org.apache.cxf.interceptor.Fault; 
import org.apache.cxf.phase.Phase; 

import java.util.Arrays; 

public class DisableOneWayInterceptor extends AbstractSoapInterceptor { 
    private static final Log LOG = LogFactory.getLog(DisableOneWayInterceptor.class); 

    public DisableOneWayInterceptor(){ 
     super(Phase.PRE_LOGICAL); 
     addBefore(Arrays.asList(org.apache.cxf.interceptor.OneWayProcessorInterceptor.class.getName())); 
    } 

    @Override 
    public void handleMessage(SoapMessage soapMessage) throws Fault { 
     if(LOG.isDebugEnabled()) 
     LOG.debug("OneWay behavior disabled"); 

     soapMessage.getExchange().setOneWay(false); 
    } 
} 

Et appelé en classe WebService (annotée avec @WebService) comme ci-dessous:

@org.apache.cxf.interceptor.InInterceptors (interceptors = {"com.mycompany.interceptors.DisableOneWayInterceptor" })