Spring Integration prend en charge la communication TCP / IP, et TcpIn / OutboundGateway et ʻIn / OutboundChannelAdapter sont préparés comme fenêtres de communication, et chacun est associé à ConnectionFactory. Lorsque la communication est requise, le contact Gateway ou ʻAdapter crée une instance TcpConnection à partir de ConnectionFactory et communique.
Si vous souhaitez insérer un traitement tel que la sortie du journal lors de la communication, spécifiez la classe TcpConnectionInterceptorFactory qui renvoie une instance de la classe qui hérite de TcpConnectionInterceptorSupport dans la propriété ʻInterceptorFactoryChain de ConnectionFactory`. Voici un exemple de mise en œuvre.
Classe qui hérite de TcpConnectionInterceptorSupport
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;
import org.springframework.context.ApplicationEventPublisher;
import org.springframework.integration.ip.tcp.connection.TcpConnectionInterceptorSupport;
import org.springframework.messaging.Message;
public class SimpleInterceptor extends TcpConnectionInterceptorSupport {
private static final Logger logger = LoggerFactory.getLogger(SimpleInterceptor.class);
public SimpleInterceptor(ApplicationEventPublisher publisher) {
super(publisher);
}
@Override
public void send(Message<?> message) throws Exception {
//Insérer le traitement de la sortie du journal avant d'envoyer un message
logger.debug("send message via interceptor");
super.send(message);
}
}
Renvoie une instance d'une classe qui hérite de TcpConnectionInterceptorSupport TcpConnectionInterceptorFactory
import org.springframework.context.support.ApplicationObjectSupport;
import org.springframework.integration.ip.tcp.connection.TcpConnectionInterceptorFactory;
import org.springframework.integration.ip.tcp.connection.TcpConnectionInterceptorSupport;
public class SimpleInterceptorFactory extends ApplicationObjectSupport implements TcpConnectionInterceptorFactory {
public SimpleInterceptorFactory() {
}
@Override
public TcpConnectionInterceptorSupport getInterceptor() {
return new SimpleInterceptor(getApplicationContext());
}
}
fichier de définition de bean
<int-ip:tcp-connection-factory id="client1"
type="client" host="localhost" port="${availableServerSocket1}"
single-use="true" interceptor-factory-chain="interceptorFactoryChain" />
<bean id="interceptorFactoryChain"
class="org.springframework.integration.ip.tcp.connection.TcpConnectionInterceptorFactoryChain">
<property name="interceptors">
<array>
<bean
class="com.neriudon.example.tcp.interceptor.SimpleInterceptorFactory" />
</array>
</property>
</bean>
TcpConnectionOpenEvent est émis lorsque ConnectionFactory génère TcpConnection et que la connexion est établie au niveau Socket, mais si l'intercepteur est défini dans ConnectionFactory, la propriété connectionfactoryname est initialement définie. Il reste la valeur «inconnue».
Voici une comparaison des résultats de sortie du journal lorsque l'intercepteur est défini et lorsqu'il ne l'est pas.
Lorsqu'un intercepteur est défini
11:58:32.397 [main] DEBUG com.neriudon.example.tcp.listener.TcpConnectionEventsListener - ★OPEN★ TcpConnectionOpenEvent [source=SimpleInterceptor:null], [factory=unknown, connectionId=localhost:50001:58459:aa1f25b0-570e-4631-8477-33a19f1bb6ba] **OPENED**
Si aucun intercepteur n'est défini
11:58:32.434 [main] DEBUG com.neriudon.example.tcp.listener.TcpConnectionEventsListener - ★OPEN★ TcpConnectionOpenEvent [source=TcpNetConnection:localhost:50002:58460:a92051dd-9003-4563-be59-3675dee3112d], [factory=client2, connectionId=localhost:50002:58460:a92051dd-9003-4563-be59-3675dee3112d] **OPENED**
C'est parce qu'il n'y a pas de processus pour définir ConnectionFactoryName dans la classe TcpConnectionInterceptorSupport. Cependant, puisque les informations de ConnectionFactory sont possédées par TcpConnection qui communique réellement, si TcpConnectionInterceptorSupport renvoieConnectionFactoryName de TcpConnection lors du retour deConnectionFactoryName: ok_hand:. Pour plus de détails, veuillez consulter le lien PR ci-dessous.
Au fait, les autres TcpConnectionEvents ne sont pas un problème car ils ont été conçus à l'origine pour que TcpConnectionInterceptorSupport appelle le traitement de TcpConnection.
Presque aucun: stuck_out_tongue_winking_eye:.
TcpConnectionInterceptorSupport a été incorporé dans master en mars 2016, et aucun bogue n'a été signalé depuis, et TcpConnectionOpenEvent lui-même est la [Documentation] de Spring Integration (https://docs.spring.io). /spring-integration/docs/4.3.13.RELEASE/reference/html/ip.html#tcp-events) est également écrit de manière superficielle, donc ce problème ne devrait pas avoir un impact sérieux sur le projet.
Je ne sais pas quand il sera publié, mais pour autant que je puisse voir dans JIRA, il sera corrigé dans les versions 5.0.1, 4.3.14 suivantes. Depuis le 15 janvier 2018, PR a été publié et sera bientôt fusionné.
C'est parce que j'ai posé des questions à ce sujet dans stackoverflow: stuck_out_tongue_closed_eyes:.
Dans le projet Spring Integration, il est de règle de poser des questions sur l'utilisation et les spécifications par débordement de pile avec la balise spring-integration. Je ne pouvais pas dire s'il s'agissait d'un bogue ou d'une spécification, j'ai donc créé un exemple d'application et présenté les conditions et les journaux qui se produiraient. Répondit que c'était un bug.
Cependant, je suis désolé de ne pas avoir pu signaler le bogue à OSS pour la première fois car la personne à l'intérieur avait soumis un vote à JIRA pendant que j'attendais: confondu:.
1/30 postscript: Incorporer ce correctif 4.3.14.RELEASE et 5.0.1.RELEASE : //github.com/spring-projects/spring-integration/releases/tag/v5.0.1.RELEASE) a été publié: v:.