Hi Sergey, Ive finally settled for a yet different way of implementing guice support -- by the way of wrapping ServiceInvokerInterceptor and using a ThreadLocal.
I've also implemented a custom request scope for guice, you might want to check the examples on project page. I'm now trying to get myself to write proper unit tests and submit a patch to CXF (I know this is supposed to be the other way around but writing tests is boring :)) I was trying to follow the guice-servlet implementation of request scope, but I have two questions about implementation. Do I need to synchronize access to the Exchange object of a request? I don't think it's normally needed, but I might not be aware of some uses. Do you have an opinon about where to store the request-scoped objects? I'm currently storing the Exchange object in a ThreadLocal, and add injected objects to it's map, but there can be several alternate setups, e.g. putting a new Map inside Exchange for those objects or storing all objects directly in a Map in ThreadLocal. Best regards, Jakub Bocheński On Fri, Oct 19, 2012 at 11:01 AM, Sergey Beryozkin-5 [via CXF] < [email protected]> wrote: > Hi Jakub > > Have you had some time recently to work with the project ? > FYI, JAX-RS 2.0 introduces > > > http://jax-rs-spec.java.net/nonav/2.0-SNAPSHOT/apidocs/javax/ws/rs/container/ResourceContext.html > > I haven't typed and code for it, but I can imagine GuiceResourceContext > being introduced > > Cheers, Sergey > > On 30/04/12 18:54, Jakub Bochenski wrote: > > > Hi Sergey, > > I was actually on holidays so I didn't mind the delay. > > Taking your anwser into account I will try to do it by injecting > > context instances into those subresources that are provided by Guice. > > Will you acept a patch to trunk refactoring the JaxRsInvoker, so that > > the conditions for injection can be overridden without copy-pasting > > code? > > > > I have also taken a closer look at Guice scopes API and I think it > > will actually be rather simple to inject Guice-managed objects with > > context dependencies. > > While most of the time you would probably be better off just declaring > > them in the resource objects and passing them explicitly via method > > calls, there are a couple of use cases where this might become useful. > > One example I can think of is the Accept-Language header. > > So later I plan to make the valid-for-singletons context objects and > > some per-request objects (at first probably path and header params, as > > I don't think doing that to query/form params would make sense) > > available in Guice. > > > > Best regards, > > Jakub Bocheński > > > > > > On Wed, Apr 25, 2012 at 1:37 PM, Sergey Beryozkin-5 [via CXF] > > <[hidden email] <http://user/SendEmail.jtp?type=node&node=5716988&i=0>> > wrote: > >> Hi Jakub > >> > >> Sorry for a delay, > >> > >> On 19/04/12 13:53, Jakub Bochenski wrote: > >> > >>> Sorry, I accidentally sent the email before I finished writing. > >>> > >>> > >>> As for manually creating/ injecting subresources you would have to > >>> inject guice providers for them (code bloat) plus you are never sure > >>> that the creator didn't forget to call all the needed setters. > >>> > >>> Compare my previous example to: > >>> @Path("foo"); > >>> abstract class ResourceA { > >>> final Provider<ResourceB> guiceProvider; > >>> > >>> ResourceA(Provider<ResourceB> guiceProvider){ > >>> this.guiceProvider = guiceProvider; > >>> } > >>> > >>> @Path("bar") > >>> ResourceB getSubResource(){ > >>> ResourceB resource = provider.get(); > >>> resource.setLanguage(this.lang); > >>> resource.setSometing(this.aa); > >>> return resource; > >>> } > >>> } > >>> > >>> This does the same but IMHO is much less clear. > >> Agreed. I think subresource handlers will not always be injected and > >> often will be created based on some application-specific logic, > example, > >> say an OSGI Service gets registered and it gets recognized as a valid > >> handler, etc... > >> > >>> > >>> So do you think implementing this by modifying the aforementioned > >>> block in JaxRsInvoker to inject if resource is a root resource *or* is > >>> "guice lookup" resource would be a good approach? > >>> > >> As far as managing the injection of contexts into subresource handlers > >> which are themselves injected or managed by proxies using a 'lookup' > >> method seems like the only reasonable approach to me. > >> > >> Thanks, Sergey > >> > >>> Best regards, > >>> Jakub Bochenski > >>> > >>> 2012/4/19 Jakub Bocheński<[hidden email]>: > >>>> Hi Sergey, > >>>> the abstract qualifier is a design decision really - I prefer it > that > >>>> way, because you are more sure then that the developer wanted the > >>>> method to be implemented by the runtime. Also if you need to create > >>>> the class manually you can always implement it inline (I think its > >>>> actually beneficial, because testing code stays in test classes). > >>>> Still I think it's quite a minor detail that can be implemeted either > >>>> way is found more suitable in the end. > >>>> > >>>> As for manually creating/ injecting subresources you would have to > >>>> inject guice providers for them (code bloat) plus you are never sure > >>>> that the creator didn't forget to call all the needed setters. > >>>> > >>>> Compare my previous example to: > >>>> @Path("foo"); > >>>> abstract class ResourceA { > >>>> > >>>> final Provider<ResourceB> guiceProvider; > >>>> > >>>> ResourceA(Provider<ResourceB> guiceProvider){ > >>>> this.guiceProvider = guiceProvider; > >>>> } > >>>> > >>>> @Path("bar") > >>>> ResourceB getSubResource(){ > >>>> > >>>> } > >>>> } > >>>> > >>>> > >>>> Jakub Bocheński > >>>> > >>>> > >>>> > >>>> On Thu, Apr 19, 2012 at 2:08 PM, Sergey Beryozkin-5 [via CXF] > >>>> <[hidden email]> wrote: > >>>>> Hi Jakub > >>>>> On 19/04/12 12:50, Jakub Bochenski wrote: > >>>>> > >>>>>> Hi Sergey, > >>>>>> sorry - apparently I wasn't clear enough last time. > >>>>>> I understand your concerns, but what I'd like to support is this: > >>>>>> > >>>>>> @Path("foo"); > >>>>>> abstract class ResourceA { > >>>>>> > >>>>>> @Path("bar") > >>>>>> abstract ResourceB getSubResource(); > >>>>>> } > >>>>>> > >>>>>> Now the runtime would implement the method using the bytecode > >>>>>> generation (thats what I meant by refering to Spring lookup-method > >>>>>> injection), so it will have control over the resource lifecycle. > >>>>>> The implementation would simply request an appropriate CXF > >>>>>> ResourceProvider from Guice and would be able to do all the > >>>>>> neccessary management. > >>>>>> > >>>>> I understand now, thanks, I'm not entirely sure I'd want to code my > root > >>>>> resource class with 'abstract' qualifiers though, I see that in > Spring > >>>>> the lookup methods can be concrete, no-ops really. I mean I'm not > sure > >>>>> why would I not want to simply add setters on the subresource > handlers > >>>>> to manually pass the contexts from the root resource to the > >>>>> subresources... That said, if Guice could help with the proper > >>>>> injection, then why not :-) > >>>>> > >>>>> Cheers, Sergey > >>>>> > >>>>>> > >>>>>> Best regards, > >>>>>> Jakub Bocheński > >>>>>> > >>>>>> > >>>>>> > >>>>>> On Thu, Apr 19, 2012 at 1:27 PM, Sergey Beryozkin-5 [via CXF] > >>>>>> <[hidden email]> wrote: > >>>>>>> Hi Jakub > >>>>>>> On 16/04/12 17:41, Jakub Bochenski wrote: > >>>>>>> > >>>>>>>> Hi Sergey, > >>>>>>>> thanks for the clarification on the subresource injection > issue. > >>>>>>>> > >>>>>>>> However I understand what you mean I think this considerably > limits > >>>>>>>> usefulness of subresources. > >>>>>>>> For example in the application I'm working on now I only use root > >>>>>>>> resources because I can't be bothered to manually inject @Context > and > >>>>>>>> @PathParam dependencies. > >>>>>>>> > >>>>>>>> Too illustrate what I mean consider this two cases: > >>>>>>>> > >>>>>>>> // Case 1 > >>>>>>>> @Path("foo"); > >>>>>>>> class ResourceA { > >>>>>>>> > >>>>>>>> @Path("bar") > >>>>>>>> ResourceB getSubResource(); > >>>>>>>> } > >>>>>>>> > >>>>>>> > >>>>>>> Let me add a sub-case :-) > >>>>>>> Case 1.1 > >>>>>>> @Path("foo"); > >>>>>>> class ResourceA { > >>>>>>> > >>>>>>> private ResourceB resourceB = new ResourceB(); > >>>>>>> > >>>>>>> @Path("bar") > >>>>>>> ResourceB getSubResource() { > >>>>>>> return resourceB; > >>>>>>> } > >>>>>>> } > >>>>>>> > >>>>>>> Case 1.1 > >>>>>>> @Path("foo"); > >>>>>>> class ResourceA { > >>>>>>> > >>>>>>> @Path("bar") > >>>>>>> ResourceB getSubResource() { > >>>>>>> return new ResourceB(); > >>>>>>> } > >>>>>>> } > >>>>>>> > >>>>>>> How will the runtime know that ResourceB is thread-safe ? When the > >>>>>>> runtime injects into root resources it knows in advance about the > >>>>>>> life-cycle of the root resource, it will inject a thread-safe > proxy > >>>>>>> into > >>>>>>> singletons, plain instances into per-request root resources. > >>>>>>> > >>>>>>> It can not know the way the root resource is managing the > >>>>>>> sub-resources, > >>>>>>> they can be added dynamically, it's impossible to predict, right ? > >>>>>>> > >>>>>>>> // Case 2 > >>>>>>>> @Path("foo"); > >>>>>>>> class ResourceA { > >>>>>>>> > >>>>>>>> } > >>>>>>>> @Path("foo/bar") > >>>>>>>> class ResourceB { > >>>>>>>> } > >>>>>>>> > >>>>>>>> Both Case 1 and 2 look the same to the end-client, however in > Case 1 > >>>>>>>> you have to manually create and inject ResourceB. In Case 2 > ResourceB > >>>>>>>> is managed by CXF, but the parent-child structure is not visible > in > >>>>>>>> the source code. > >>>>>>>> > >>>>>>>> Can we have something that would work like Case 2 but look more > like > >>>>>>>> Case 1 in the source (i.e. the parent-child relation would be > >>>>>>>> explicit)? > >>>>>>>> I'm thinking about implementing something similar to Spring's > >>>>>>>> "lookup-method" injection. A resource class would have an > abstract > >>>>>>>> sub-resource locator method that would be implemented by Guice > thus > >>>>>>>> allowing Guice/CXF to control the lifecycle. > >>>>>>>> > >>>>>>>> As for implementation on CXF side I think it could be as simple > as > >>>>>>>> commenting out the "if (cri.isRoot())" on line 129 of > JaxRsInvoker. > >>>>>>>> (Of course I'm not suggesting this as a productive solution, just > >>>>>>>> pointing out it's not hard to do in principle). > >>>>>>>> Do you think such a feature would be useful? > >>>>>>>> > >>>>>>>> As for JAX-RS 2.0 spec a cursory reading unfortunately didn't > result > >>>>>>>> in any useful insights. > >>>>>>>> > >>>>>>> Please see my example above on why I'm not sure it can work, what > do > >>>>>>> you > >>>>>>> think ? > >>>>>>> > >>>>>>> Cheers, Sergey > >>>>>>> > >>>>>>>> Best regards, > >>>>>>>> Jakub Bocheński > >>>>>>>> > >>>>>>>> > >>>>>>>> On Fri, Apr 13, 2012 at 5:37 PM, Sergey Beryozkin-5 [via CXF] > >>>>>>>> <[hidden email]> wrote: > >>>>>>>>> Hi, > >>>>>>>>> On 13/04/12 14:11, Jakub Bochenski wrote: > >>>>>>>>>> Hi Sergey, > >>>>>>>>>> > >>>>>>>>>>> I read somewhere JSR-299 reuses some parts of JSR-330, with > some > >>>>>>>>>>> JSR-330 > >>>>>>>>>>> annotations being the same in JSR-299, but most likely I > misread > >>>>>>>>>>> it, > >>>>>>>>>>> need to catch up, may be Bill would comment :-) > >>>>>>>>>>> > >>>>>>>>>> Having a JSR-330 implementation makes implementing JSR-299 > easier, > >>>>>>>>>> but > >>>>>>>>>> I think that's all. > >>>>>>>>>> > >>>>>>>>> OK > >>>>>>>>> > >>>>>>>>>>>> I'd like to ask you to take a look at the configuration > >>>>>>>>>>>> possibilities > >>>>>>>>>>>> available - I've done what I needed for my project, so > validating > >>>>>>>>>>>> this > >>>>>>>>>>>> against other use cases or use styles would be a very good > thing. > >>>>>>>>>>>> Apart from obvious things (missing JAXRSServerFactoryBean > >>>>>>>>>>>> properties > >>>>>>>>>>>> like interceptors), do you think this DSL lacks something? > >>>>>>>>>>>> > >>>>>>>>>>>> I would also appreciate any coments on the syntax - I think > it's > >>>>>>>>>>>> pretty clear and concise now, but maybe there is a better way > to > >>>>>>>>>>>> name > >>>>>>>>>>>> the methods etc. > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Sure I will try to look into is asap, though some delay will > be > >>>>>>>>>>> there. > >>>>>>>>>>> If someone else has the experience with Guice then please > >>>>>>>>>>> contribute > >>>>>>>>>>> the > >>>>>>>>>>> comments too > >>>>>>>>>>> > >>>>>>>>>> Thanks, although I'm even more interested in CXF-centric look > than > >>>>>>>>>> Guice-centric if you know what I mean. > >>>>>>>>>> > >>>>>>>>>>> Please keep enhancing it, I guess we can drop the module to > >>>>>>>>>>> rt/rs/extensions/guice or /jsr330 at some stage > >>>>>>>>>>> > >>>>>>>>>> Yup, I planned to bring this to a more mature state while on > google > >>>>>>>>>> code, then when I have something that can be called 1.0 version > >>>>>>>>>> merge > >>>>>>>>>> it into CXF. > >>>>>>>>>> > >>>>>>>>>> This means providing the beforementioned support for missing > config > >>>>>>>>>> options plus full support for Guice scopes. > >>>>>>>>>> > >>>>>>>>>> One extra feature I'd be interested in implementing is support > for > >>>>>>>>>> subresource injection. > >>>>>>>>>> As far as I know you have to create and "inject" subresource > >>>>>>>>>> classes > >>>>>>>>>> manually right now. > >>>>>>>>>> Before going into this further I'd like to ask you: is it so > >>>>>>>>>> because > >>>>>>>>>> it's a gap in JAX-RS 1.0 spec or is there some good reason CXF > does > >>>>>>>>>> not inject @Context dependecies into subresources? > >>>>>>>>>> > >>>>>>>>> JAX-RS 1.1 might be mentioning it explicitly, can't recall right > >>>>>>>>> now, > >>>>>>>>> but the reason this is not required is that the lifecycle of > >>>>>>>>> subresources is generally managed at the application level. They > >>>>>>>>> could > >>>>>>>>> be singletons or created on every request or only when no > suitable > >>>>>>>>> handler is available, you never know and hence the runtime does > not > >>>>>>>>> know > >>>>>>>>> too what to inject. If subresource locator is returning an > interface > >>>>>>>>> or > >>>>>>>>> even Object then the decision to inject can only be done at the > >>>>>>>>> invocation time which is a problem too... > >>>>>>>>> > >>>>>>>>>> Finally I plan to read up the JAX-RS 2.0 spec - this might > provide > >>>>>>>>>> some insight, since it's purpose is to "path" JSR-311 with > JSR-330. > >>>>>>>>>> > >>>>>>>>> Please do, it's still the work in progress, working out the > >>>>>>>>> relationship, but keeping an eye on the progress would > definitely be > >>>>>>>>> a > >>>>>>>>> good idea > >>>>>>>>> > >>>>>>>>> Cheers, Sergey > >>>>>>>>> > >>>>>>>>>> Best regards, > >>>>>>>>>> Jakub Bochenski > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Thanks, Sergey > >>>>>>>>>>> > >>>>>>>>>>>> Best regards, > >>>>>>>>>>>> Jakub Bocheński > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On Thu, Apr 12, 2012 at 10:50 PM, Sergey Beryozkin-5 [via > CXF] > >>>>>>>>>>>> <[hidden email]> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>> Hi Jakub > >>>>>>>>>>>>> > >>>>>>>>>>>>> On 12/04/12 13:27, Jakub Bochenski wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> I've started a little project on google code - basically a > EDSL > >>>>>>>>>>>>>> for > >>>>>>>>>>>>>> configuring CXF Guice-style. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> The instances are created (and injected) by Guice and a > custom > >>>>>>>>>>>>>> ResourceProvider is used to plug them into CXF (which let's > you > >>>>>>>>>>>>>> use > >>>>>>>>>>>>>> all > >>>>>>>>>>>>>> injection points except constructor). > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> If you are interested see the details here: > >>>>>>>>>>>>>> http://code.google.com/p/guice-cxf/ > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Any suggestions will be appreciated. > >>>>>>>>>>>>>> The project has a working version although not all CXF > features > >>>>>>>>>>>>>> are > >>>>>>>>>>>>>> configurable now. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thank you for this effort > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> I would be very happy if the CXF team would be interested > in > >>>>>>>>>>>>>> integrating > >>>>>>>>>>>>>> it > >>>>>>>>>>>>>> into the core project - please let me know if you do. > >>>>>>>>>>>>>> > >>>>>>>>>>>>> I think the Guice integration can be a good feature to have. > >>>>>>>>>>>>> Let me ask one question: > >>>>>>>>>>>>> > >>>>>>>>>>>>> What is the relationship between JSR-299, JSR-330, and Guice > ? > >>>>>>>>>>>>> Would having the Guice integration let CXF claim it supports > >>>>>>>>>>>>> JSR-330 > >>>>>>>>>>>>> or > >>>>>>>>>>>>> JSR-299 or both :-) ? > >>>>>>>>>>>>> > >>>>>>>>>>>>> Thanks, Sergey > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5716988.html > To unsubscribe from CXF + Guice Integration, click > here<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5635498&code=a3ViYS5ib2NoZW5za2lAZ21haWwuY29tfDU2MzU0OTh8MTAyOTgwODU3MA==> > . > NAML<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5716995.html Sent from the cxf-user mailing list archive at Nabble.com.
