On Fri, Oct 19, 2012 at 12:50 PM, Martin Schayna <[email protected]> wrote:
> For those who are interested: finally I found the reason and it is > surprisingly magical! > > Jersey server version 1.x has its own internal (and very limited) DI > framework for instantiation resource controllers and injection some > specific stuff. But for real use it is better to use Guice via jersey-guice > contrib package. Both DI frameworks coexists on very magical base -- > controllers may use Guicey @Inject injection and also Jersey @Context > injection. If any controller has constructor with @Inject annotation, then > Guice instantiate it, in other case Jersey DI does it. Those created by > Jersey DI could not be intercepted by Guice, exactly how it is specified in > Guice documentation. > > Naturally, I have both types of controllers ;-) > > Maybe it helps someone. > > Again I have to repeat: it would be nice to see some warnings in > console when Guice cannot instrument interceptors and should be because > matchers in bindInterceptor(...) say yes. > Guice can't easily do this because Guice isn't creating these classes. What might make more sense is to be aware of when jersey instantiates a class for you if you're expecting all classes to be instantiated through Guice. > > > On Friday, October 19, 2012 6:02:31 PM UTC+2, Martin Schayna wrote: >> >> Mea culpa! >> >> Actually, I cannot confirm my report, I refactored code many times... and >> now interception methods with annotated arguments works well. Sorry. >> >> But in cases specified in >> documentation<http://code.google.com/p/google-guice/wiki/AOP#Limitations> >> would >> be nice to see some warnings from Guice in console... >> >> Thanks, and sorry again. >> >> >> On Friday, October 19, 2012 4:04:25 PM UTC+2, Martin Schayna wrote: >>> >>> Hi, >>> >>> I have app based on Jersey REST server and now I'm trying to use >>> guice-persist. I could not use guice-persist as is, but I borrow some >>> thoughts, esp. transaction control via @Transactional annotation and method >>> interceptor. But I found some glitches, which are guice specific. >>> >>> This method is OK and method interceptor is invoked: >>> >>> @Transactional >>> @Path("/ok") >>> *public* String ok() { ... } >>> >>> >>> but for this one interceptor is not invoked: >>> >>> @Transactional >>> @Path("/fail/{id}") >>> *public* String fail(@PathParam("id") String id) { ... } >>> >>> >>> So annotatated arguments prevents method intercepting. When I annotate >>> arguments in interface and than implement this interface (which is >>> thankfully supported in Jersey), it works. I think that this limitation is >>> not specified in docu http://code.google.com/p/**google-guice/wiki/AOP#* >>> *Limitations<http://code.google.com/p/google-guice/wiki/AOP#Limitations> >>> >>> Can I see warnings or so for methods which Guice should intercept (i.e. >>> matches binding matchers) and could not due limitations? It seems like >>> lotery to me... >>> >>> Thank you! >>> >>> -- > You received this message because you are subscribed to the Google Groups > "google-guice" group. > To view this discussion on the web visit > https://groups.google.com/d/msg/google-guice/-/PvhO5V_XnBwJ. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-guice?hl=en. > -- You received this message because you are subscribed to the Google Groups "google-guice" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-guice?hl=en.
