Maillot 2 filtre utilise le Conteneur Contexte de Demande à Demande du Client Filtre

J'ai un Maillot 2 Service Web que sur réception d'une demande, fait une autre demande à un autre service web dans le but de former la réponse pour la demande initiale. Ainsi, lorsque le client "A" fait une demande à mon web service "B", "B" fait une demande de "C" dans le cadre de la formation de la réponse à la "Une".

A->B->C

Je veux implémenter un filtre pour un Maillot 2 service web qui fait essentiellement:

  • Client "A" envoie une requête qui contient un en-tête comme
    "Mon en-Tête:tout d'abord"
  • Quand mon web service "B", puis fait une demande d'un client "C", il devrait
    ajouter à cet en-tête, de sorte qu'il envoie une requête à cet en-tête
    "Mon en-Tête:d'abord,deuxième".

Je veux mettre en œuvre ce qu'un filtre de sorte que l'ensemble de mes ressources n'ont pas à reproduire la logique de l'ajout de l'entête de la requête.

Cependant, en Jersey 2, vous obtenez ces 4 filtres:

  • ContainerRequestFilter - Filtre/modifier les demandes entrantes
  • ContainerResponseFilter - Filtre/modifier sortant réponses
  • ClientRequestFilter - Filtre/modifier des requêtes sortantes
  • ClientResponseFilter - Filtre/modifier entrant réponses

Maillot 2 filtre utilise le Conteneur Contexte de Demande à Demande du Client Filtre

J'ai besoin d'utiliser l'en-tête d'une requête entrante, le modifier, l'utiliser ensuite une demande sortante, donc en gros j'ai besoin de quelque chose qui est à la fois un ContainerRequestFilter et un ClientRequestFilter. Je ne pense pas que la mise en œuvre à la fois dans le même filtre de travail, que vous ne savez pas qui Demande du Client, des cartes qui Récipient Demande, ou pensez-vous?

Qu'entendez-vous par "quand mon web service, puis fait une demande d'un client"? Habituellement,un service web crée une réponse à une demande de client.
Fait de la question un peu plus clair maintenant

OriginalL'auteur oggmonster | 2014-07-28

  1. 4

    J'ai trouvé une belle façon de faire qui n'utilise pas ThreadLocal pour communiquer entre les ContainerRequestFilter et la ClientRequestFilter, que vous ne pouvez pas supposer que le client demande faite en réponse à un conteneur demande d'être sur le même thread.

    La façon dont j'ai obtenu c'est par la définition d'une propriété dans le ContainerRequestConext objet dans le ContainerRequestFilter. Je peux alors passer le ContainerRequestContext objet (que ce soit explicitement ou par l'injection de dépendance) dans mon ClientRequestFilter. Si vous utiliser l'injection de dépendance (si vous utilisez Jersey 2, alors vous êtes probablement en utilisant HK2), puis tout cela peut être réalisé sans modification de votre niveau de ressources de la logique.

    Ont un ContainerRequestFilter comme ceci:

    public class RequestIdContainerFilter implements ContainerRequestFilter {

@Override
public void filter(ContainerRequestContext containerRequestContext) throws IOException {
    containerRequestContext.setProperty("property-name", "any-object-you-like");
}

    Et un ClientRequestFilter qui prend un ContainerRequestContext dans son constructeur:

    public class RequestIdClientRequestFilter implements ClientRequestFilter {

    private ContainerRequestContext containerRequestContext;

    public RequestIdClientRequestFilter(ContainerRequestContext containerRequestContext) {
        this.containerRequestContext = containerRequestContext;
    }

    @Override
    public void filter(ClientRequestContext clientRequestContext) throws IOException {
        String value = containerRequestContext.getProperty("property-name");
        clientRequestContext.getHeaders().putSingle("MyHeader", value);
    }
}

    Alors c'est juste une affaire de lier tout cela ensemble. Vous aurez besoin d'une usine à créer tout Client ou WebTarget que vous avez besoin de:

    public class MyWebTargetFactory implements Factory<WebTarget> {

    @Context
    private ContainerRequestContext containerRequestContext;

    @Inject
    public MyWebTargetFactory(ContainerRequestContext containerRequestContext) {
        this.containerRequestContext = containerRequestContext;
    }

    @Override
    public WebTarget provide() {
        Client client = ClientBuilder.newClient();
        client.register(new RequestIdClientRequestFilter(containerRequestContext));
        return client.target("path/to/api");
    }

    @Override
    public void dispose(WebTarget target) {

    }
}

    Puis enregistrer le filtre et de lier votre usine sur votre application principale ResourceConfig:

    public class MyApplication extends ResourceConfig {

    public MyApplication() {
        register(RequestIdContainerFilter.class);
        register(new AbstractBinder() {
            @Override
            protected void configure() {
                bindFactory(MyWebTargetFactory.class).to(WebTarget.class);
            }
        }
    }
}
    Je voudrais faire exactement cela. La seule question que je me pose est - ce que vous appelez .register() dans la dernière étape? Merci!
    J'ai fixé ma réponse pour le rendre clair maintenant
    Selon la façon dont vous souhaitez gérer la logique que vous faites dans la ContainerRequestFilter, vous pouvez les supprimer entièrement, car à partir de l'injection de ContainerRequestContext vous pouvez obtenir l'original de la demande (y compris les en-têtes, etc.). J'utilise cette astuce pour mettre en œuvre un client qui passe automatiquement par les en-têtes de la requête à nouveau HTTP appels.

    OriginalL'auteur oggmonster

  2. 3

    Un récipient de filtre peut mettre en œuvre à la fois, ContainerRequestFilter et ContainerResponseFilter dans une seule classe. Le même est vrai pour des filtres de client, ClientRequestFilter et ClientResponseFilter peut à la fois être mis en œuvre dans un seul filtre de mise en œuvre.

    Mais vous ne pouvez pas mélanger autant que je sache. Au lieu de cela, vous pouvez avoir deux filtres séparés qui communiquent les uns avec les autres en utilisant par exemple ThreadLocal modèle:

    //Container filter that stores the request context in a ThreadLocal variable
public class MyContainerRequestFilter implements ContainerRequestFilter, ContainerResponseFilter {
    public static final ThreadLocal<ContainerRequestContext> requestContextHolder;

    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        requestContextHolder.set(requestContext);
    }

    @Override
    public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) throws IOException {
        //clean up after request
        requestContextHolder.remove();
    }
}

//Client request filter that uses the info from MyContainerRequestFilter
public class MyClientRequestFilter implements ClientRequestFilter {
    @Override
    public void filter(ClientRequestContext requestContext) throws IOException {
        ContainerRequestContext containerRequestContext =
            MyContainerRequestFilter.requestContextHolder.get();
        if (containerRequestContext != null) {
            //TODO: use info from containerRequestContext to modify client request
        }
    }
}
    Donc la durée de vie d'un filtre est par demande?
    Non, normalement il y a une instance par le filtre et de l'application. Mais qui n'a pas d'importance ici que chaque demande est liée à un fil. Ainsi, le ThreadLocal variable assure que les demandes parallèles ne pas mélanger leurs statique titulaire de contenu.
    Hmm penser à cela, je ne pense pas que cela fonctionnera, car si j'ai une autre méthode ou de la ressource qui ne font pas d'appel du client, le ThreadLocal objet ne sont pas nettoyés.
    Non, ce n'est pas vrai. ThreadLocal obtient nettoyé de toute façon dans la deuxième méthode de filtrage, qui appartient à ContainerResponseFilter, c'est à dire qu'il sera appelé APRÈS la demande (A -> B), peu importe si B -> C se passe ou pas.

    OriginalL'auteur isnot2bad