JSR-330 - watpliwosci

Witam,
Wlasnie dowiedzialem sie o istnieniu standardu JSR-330, czyli adnotacji @Inject oraz @named. Mam kilka prostych pytan.

Rozumiem, ze to proba ustandaryzowania i uproszczenia skladni dla dependency injection w Java EE.

1. Czy adnotacje te moga w kazdym przypadku z powodzeniem zastapic adnotacje @ejb?

2. Jezeli dobrze rozumiem moge tego uzywac do ManagedBeanow, bez przechodzenia na CDI?

(wspolna jest tylko ustandaryzowana skladnia tak jak w artykule):
http://comdynamics.net/blog/89/jsf2-with-spring3-and-jsr-330

Co wiecej, moje beany springowe to zrozumieja i tez beda uzywac tej skladni: Spring wspiera ten standard.

3. Czy w mavenie scope "provided" dla pakietu bedzie ok, czy tez powinienem uzywac compile jesli mam serwer aplikacji z kontenerem EJB jak Glassfish (imo provided powinno styknac skoro jest to ustandaryzowane).

4. Czy tworzac nowy projekt czysto Springowy jest jakis powod, aby uzywac JSR-330 skoro rownie dobrze moge uzywac standardowych springowych adnotacji (@Repository, @Service, @Component)? Jak cos jest do wszystkiego nie zawsze znaczy, ze jest lepsze..

Pozdrawiam,

ad 4. Używanie standardowych adnotacji pozwala na odcięcie się od springa. Jak będziesz chciał przejść na przykład na Guice, CDI czy inne Pico nie będziesz musiał grzebać w kodzie (zbyt dużo).
ad 3. Powinno wystarczyć, ale musisz sprawdzić czy serwer zawiera odpowiednie paczki.
ad 2. Tak. Spring rozumie co się do niego mówi za pomocą tych adnotacji, choć ścieżka ich przetwarzania może być trochę inna niż standardowych springowych adnotacji i tym samym może okazać się, że działa to trochę wolniej/inaczej niż goły spring.
ad 1. Nie. @Inject nie wspiera np. przeszukiwania JNDI z poziomu adnotacji. @ejb ma parametr lookup, który to umożliwia. Trzeba zatem dopisać odpowiedniego providera, który na podstawie @named spróbuje wyszukać odpowiednią usługę. To samo tyczy się poszukiwania implementacji beana via beanName czy beanInterface.

Dzięki za pomoc. Wnioskuje wiec, ze JSR-330 nie jest tez substytutem dla @Resurce z tego samego powodu, dla ktorego nie jest dla @ejb.

Akurat do @Resource jest mu znacznie bliżej lecz nie można powiedzieć, że każde @Resource da się zastąpić @Inject. Choć nie spotkałem się z sytuacją gdy kombinacja @Inject, @named i providera nie dała by rady.