2017-01-13 5 views
1

Резервуары джерси построены на момент запуска приложения. Следовательно, его зависимости (Cipher s в этом случае) вводятся из области запроса.Как использовать объекты RequestScoped в перехватчике однопользовательского трикотажа?

Проблема в том, что шифры stateful, поэтому их следует вводить в область запроса. Как это сделать ?

@Provider 
@Priority(Priorities.ENTITY_CODER + 1) 
public class CryptInterceptor implements ReaderInterceptor, WriterInterceptor { 

    @Inject @Named("ENC_CIPHER") 
    private Cipher encryptionCipher; 
    @Inject @Named("DEC_CIPHER") 
    private Cipher decryptionCipher; 

    @Override 
    public Object aroundReadFrom(ReaderInterceptorContext context) throws IOException, WebApplicationException { 
     InputStream inputStream = context.getInputStream(); 
     CipherInputStream cipherInputStream = new CipherInputStream(inputStream, decryptionCipher); 
     context.setInputStream(cipherInputStream); 
     return context.proceed(); 
    } 

    @Override 
    public void aroundWriteTo(WriterInterceptorContext context) throws IOException, WebApplicationException { 
     OutputStream outputStream = context.getOutputStream(); 
     CipherOutputStream cipherOutputStream = new CipherOutputStream(outputStream, encryptionCipher); 
     context.setOutputStream(cipherOutputStream); 
     context.proceed(); 
    } 
} 

Ожидая новый Cipher для каждого нового запроса, как их инжекции в RequestScope -

public class BootstrapBinder extends AbstractBinder { 
    @Override 
    protected void configure() { 
    bindFactory(EncCipherFactory.class).to(Cipher.class).named("ENC_CIPHER").in(RequestScoped.class); 
    bindFactory(DecCipherFactory.class).to(Cipher.class).named("DEC_CIPHER").in(RequestScoped.class); 
    } 
} 

Теперь, очевидно, hk2 (DI джерси) не может вводить объект RequestScoped внутри Singleton перехватчика. Это вызывает:

java.lang.IllegalStateException: Not inside a request scope. 

ответ

2

Необходимо проксировать службы. Если вы этого не сделаете, то Джерси попытается ввести фактический объект, и нет запроса при создании перехватчика. Что касается попытки сделать запрос перехватчика охваченным, я не знаю. Не уверен, что это возможно.

bindFactory(EncCipherFactory.class) 
     .proxy(true) 
     .proxyForSameScope(false) 
     .to(Cipher.class) 
     .named("ENC_CIPHER") 
     .in(RequestScoped.class); 

Сделайте то же самое с другим. Но имейте в виду, что это будет экземпляр прокси, когда вы обращаетесь к нему, а не к экземпляру шифрования.

Смотрите также:

+0

У меня было трудное время, когда я изучал прокси в джерси документации. Любой намек, что этот код делает за сценой? – Nilesh

+0

'proxy' вызывает создание динамического прокси. Поэтому каждый раз, когда вы получаете доступ к сервису, он будет прокси. «proxyForSameScope» просто говорит, что если родительский объект находится в той же области действия, то есть в области запроса, не делайте его прокси-сервером, просто используйте реальный объект. Например, теперь это будет прокси-объект, но если вы попытаетесь ввести его в класс ресурсов (который является областью запроса по умолчанию), это будет фактический экземпляр. –

+0

В этой статье я расскажу об этом подробнее. И есть также связанная статья в этой статье о динамических прокси. Это может быть хорошо прочитано, если вы хотите узнать, как прокси работают за кулисами. –

Смежные вопросы