2016-11-16 1 views
0

Wir haben einen SOAP-Webdienst, den wir von JBoss EAP 5.1 auf 6.4.7 migrieren, und einer der Webdienste gibt absolut zurück nichts als 200 (in JBoss 5). Wenn wir zu 6 migriert haben, funktioniert es immer noch und gibt nichts zurück, sondern gibt stattdessen eine 202 zurück, und das wird Clients brechen. Wir haben keine Kontrolle über Kunden. Ich versuchte einen SOAPHandler bei der close-Methode, aber es tut nichts, da es nicht einmal aufgerufen wird, da meine Vermutung ist, dass, da keine SOAP-Nachricht zurückkommt, nichts den Handler auslöst.JBoss 6 EAP - überschreibt den HTTP-Antwortstatuscode in einem SOAP-Dienst, der eine leere Antwort von 202 an 200 zurücksendet

Ich habe auch versucht, den Kontext direkt in der Web-Methode und Modif zugreifen, aber es hat nichts getan.

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

Ich konnte nichts in der Bedienungsanleitung finden.

Jede Richtung wird sehr geschätzt.

Hier ist, wie der Hafen und seine Umsetzung wie folgt aussehen:

Hier ist, wie der Hafen und seine Umsetzung Kopf wie folgt aussehen:

@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 { 
... 

} 

Antwort

0

Falls jemand wird diese nützlich finden. Hier ist die Lösung;

Apache CXF verwendet standardmäßig asynchrone Anfragen und selbst wenn die Annotation @OneWay fehlt, verhält es sich immer noch so wie es war, wenn es dort war.

Also, um zu deaktivieren, dass ein Abfangjäger wie unten erstellt werden muss:

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); 
    } 
} 

Und in WebService-Klasse (mit Anmerkungen versehen mit @WebService) genannt, wie unten:

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