Hi all,
I am a bit concern with JAX-RS and interceptors though. It looks like
JAX-RS 2.0 has interceptors... but totally different from CDI and Java EE.
They even have a kind of interceptor binding called NameBinding (
http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/NameBinding.html).
In the Matrix it shows that JAX-RS allows CDI interceptors. Are JAX-RS
interceptors any differ from CDI ones ?
Antonio
On Thu, Dec 6, 2012 at 6:49 AM, Markus Eisele <myfear_at_web.de> wrote:
> Clean and simple +1 from me!
>
> Thank you!
> - M
>
> On 5 December 2012 18:37, Pete Muir <pmuir_at_bleepbleep.org.uk> wrote:
> > We support taking this approach :-)
> >
> > On 4 Dec 2012, at 22:10, Linda DeMichiel wrote:
> >
> >>
> >> We're now at the point where we'd like to resolve the open issues
> >> around improving managed bean alignment in Java EE 7. We'd like
> >> to start with the issue of injection and interceptors.
> >>
> >> First, some background information that is relevant here....
> >>
> >> We have noticed (and confirmed) that the steps outlined in the Java EE
> >> spec section EE.5.24 for performing injection of non-contextual managed
> >> classes using the CDI SPIs are incorrect.
> >>
> >> The correct sequence of steps is the following. These conform to the
> >> recommendations of the Weld project and to what was actually done in the
> >> Java EE 6 reference implementation. (See
> http://www.seamframework.org/Documentation/HowDoIDoNoncontextualInjectionForAThirdpartyFramework
> ).
> >>
> >> I therefore plan to amend section 5.24 as follows to reflect this:
> >>
> >> "....In supporting such injection points, the container must behave
> >> as if it carried out the following steps, involving the use of the
> >> CDI SPI.
> >>
> >> 1. Obtain a BeanManager instance.
> >>
> >> 2. Create an AnnotatedType instance for the component into which
> >> injection is to occur.
> >>
> >> 3. Create an InjectionTarget instance for the annotated type.
> >>
> >> 4. Create a CreationalContext, passing in null to the BeanManager
> >> createCreationalContext method.
> >>
> >> 5. Instantiate the component by calling the InjectionTarget produce
> method.
> >>
> >> 6. Inject the component instance by calling the InjectionTarget inject
> >> method on the instance.
> >>
> >> 7. Invoke the PostConstruct callback, if any, by calling the
> >> InjectionTarget postConstruct method on the instance."
> >>
> >>
> >> There are a couple of things to note with regard to the use of these
> >> CDI SPIs:
> >>
> >> In step 4, passing null to the createCreationalContext method causes
> >> the created instances to be non-contextual.
> >>
> >> In step 5, instantiating the objects by means of the produce method
> >> causes them to be wrapped with interceptors and decorators, and also
> >> causes the constructor annotated @Inject to be invoked, if it exists.
> >>
> >>
> >> While this approach has been followed by the RI all along, there was
> >> a bug in the Weld implementation that has caused the interceptors
> >> and decorators to be inactive. See
> https://issues.jboss.org/browse/WELD-1049.
> >> That bug has since been fixed.
> >>
> >> To return to the main point -- which is the pending issue of managed
> >> bean alignment -- the consequence of all of this is that we already
> >> have interceptors and decorators, as well as constructor injection
> >> support for all classes in Table EE.5-1 (with the exception of the
> >> application client classes). While we could of course choose to do
> >> otherwise, we believe that this is the right thing to do, as well as
> >> the most consistent approach. The attached matrix, "matrix 7",
> >> illustrates this.
> >>
> >> Finally, in our earlier discussion on managed bean alignment, we had
> >> also raised the issue as to whether these classes should be contextual
> >> objects. Note that as non-contextual objects, they cannot have
> >> producers or observer methods. While it is possible to inject
> >> instances of these classes into other classes, those instances would
> >> not be managed by the container and would be treated as dependent
> >> objects by CDI.
> >>
> >> In the future we could consider turning our non-contextual objects
> >> into contextual objects by defining the scope that they belong to.
> >> That might involve defining new scopes that match the lifecycles that
> >> the containers are currently managing themselves.
> >>
> >> Please let us know your opinions on these issues.
> >>
> >>
> >> thanks,
> >>
> >> -Linda
> >>
> >>
> >>
> >>
> >>
> >>
> >
> >
> >
>
--
Antonio Goncalves
Software architect and Java Champion
Web site <http://www.antoniogoncalves.org> |
Twitter<http://twitter.com/agoncal>|
LinkedIn <http://www.linkedin.com/in/agoncal> | Paris
JUG<http://www.parisjug.org> |
Devoxx France <http://www.devoxx.fr>