2014-01-28 2 views
4

Я хотел бы добавить компонент службы buisiness в дополнительный ресурс, который определен в выделенном классе и доставлен локатором вспомогательных ресурсов.Джерси: Как ввести EJB в дополнительный ресурс?

Некоторые примеры кода:

  1. Корневой ресурс

    @RequestScoped 
    @Path("service") 
    public class MyResource { 
    
        @Context 
        ResourceContext resourceContext; 
    
        // Sub resource locator 
        @Path("subservice") 
        public MySubResource locateToSubResource() { 
         // I don't want to create it myself. 
         return resourceContext.getResource(MySubResource.class); 
        } 
    } 
    
  2. Соответствующий югу ресурс

    @RequestScoped 
    public class MySubResource { 
    
        // Note that businessBean itself consists of 
        // multiple ejbs that also need to be injected so that it can do its job! 
        @Inject 
        private BusinessBean businessBean; 
    
        @GET 
        @Produces(MediaType.TEXT_PLAIN) 
        public String get() { 
         return businessBean.doStuff(); 
        } 
    } 
    

Джерси не CDI позволяют вызывать зависимости. .. Обратите внимание, что ресурсы являются управляемыми объектами. В противном случае даже невозможно было бы добавить компонент в корневой ресурс (here I'm pushing my other questions' view count to get more opinions ;-))!

Я попробовал все, что я могу думать, но он просто не будет работать ...

В настоящее время я использую библиотеки, которые поставляются вместе с GlassFish 4.

И конечно, спасибо заранее (почти забыл)!

ответ

7

Хорошо, я понял.

Это действительно глупо. Иногда вам приходится откатываться полностью.

Должно быть, что-то не так с моей первоначальной попыткой (опечатка, что-то вышло ... я не могу воспроизвести ее, что бы там ни было).

Я слегка изменил корневой ресурс сверху:

@RequestScoped 
@Path("service") 
public class MyResource { 

    @Inject MySubResource mySubResource; 

    // Sub resource locator 
    @Path("subservice") 
    public MySubResource locateToSubResource() { 
     return mySubResource; 
    } 
} 

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

Я думаю, что это как всегда - лишение сна позволяет людям превращаться в идиотов.

+0

Это, наконец, тоже помогло мне, но у меня есть вопрос: действительно ли требуется '@ RequestScoped' в корневом классе ресурсов? Это также работает для меня без этого, и я думал, что вам не нужен компонент CDI для ввода другого, но он также работает с классами ресурсов JAX-RS (например)? –

+0

На самом деле кажется, что даже один из них не должен использовать явный '@ RequestScoped' на вспомогательном ресурсе, потому что согласно [this] (http://stackoverflow.com/questions/10293510/what-is-the- default-scope-of-a-named-cdi-bean/10293686 # 10293686) ответ, область по умолчанию должна быть такой же, как класс, который получает инъекцию? На самом деле, я тоже могу оставить эту аннотацию. –

2

Я решил вот так.

public SubResource subResource() { 
    return CDI.current().select(SubResource.class).get(); 
} 
+2

Hmn, возможно, существуют определенные варианты использования, когда это применимо/приемлемо, но любая возможная ошибка проявляется только до фактического выполнения * во время выполнения *, правильно? Если вы вместо этого используете декларативный '@ Inject'-way, у провайдера инъекций есть как минимум возможность жаловаться * во время развертывания *. С другой стороны, ваш ответ показывает хорошо известную программную альтернативу, которая делает ее полезной. –

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