Yes, they're different. I forget the details but I believe they operate more at
the protocol level vs. CDI interceptors that operate at the method level. It's
not unlike JAX-WS that has
handlers/filters/interceptors/whatever-you-want-to-call-them that operate at the
protocol level and the message level. So, depending on what you're trying to
do, a different kind of "interceptor" might be appropriate.
Antonio Goncalves wrote on 12/05/2012 10:40 PM:
> 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
> <mailto: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
> <mailto: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>