> That is a root resource, right ? So I was thinking about doing some kind > of dynamic binding I guess, when we have a subresource instance returned > ? So basically, instead of providing a hint to Guice by having a no-op > method, pre-process a returned subresource instance by injecting all > JAX-RS contexts if needed, sorry, I may have missed the point by now :-) Yes, I think there was a slight misunderstanding. Both statements are Guice idioms and they belong to Guice module classses - see [1] and [2], not to Jax-Rs resources.
I think it might be useful to divide discussing this into two things: - implementation independent API that will let one express his CDI needs (@Context, ResourceContext and a custom annotation to allow interception of noop methods belong here), - implementations of this API, I guess there would be different ones for e.g. Guice or Spring (what I was writing above pertains mostly to Guice-specific implementation). Staying in the topic of Guice implementation pre- (I'd name it post-) processing returned instance isn't really needed IMO. I think Guice is in itself expressive enough to allow all kinds of injections - both of Jax-Rs context and custom dependencies. Best regards, Jakub Bocheński [1]ttp://code.google.com/p/google-guice/wiki/ProvidesMethods [2]http://code.google.com/p/google-guice/wiki/LinkedBindings On Fri, Oct 19, 2012 at 2:39 PM, Sergey Beryozkin-5 [via CXF] <[email protected]> wrote: > > On 19/10/12 13:31, Jakub Bochenski wrote: > >> Hi, >> >> >>> You should be able to find it at the the users list visible from JAX-RS >>> 2.0 / JSR339 java project >> thanks >> >>> I just wonder, now that you've mentioned asm, should we just implement >>> an asm or cglib interceptor which will do the injection and let the >>> application code return a live instance ? >> I'm not sure what you mean exactly by "letting the application code >> return a live instance". >> Currently I have implemented an AopAlliance interceptor, which is >> similiar to asm, only easier (but I couldn't get it to work on >> abstract methods) - see [1]. It defers to Guice injector, then in >> Guice configuration you can either do sth. like: >> >> bind(MyResource.class).to(MyResourceImpl.class); >> >> as well as: >> >> @Provides >> MyResource provideResourceImplementation(@Named("property") String >> conf){ >> return new MyResourceImpl(conf. new Date()); >> } > > That is a root resource, right ? So I was thinking about doing some kind > of dynamic binding I guess, when we have a subresource instance returned > ? So basically, instead of providing a hint to Guice by having a no-op > method, pre-process a returned subresource instance by injecting all > JAX-RS contexts if needed, sorry, I may have missed the point by now :-) > > Cheers, Sergey > > >> >> Best regards, >> Jakub Bocheński >> >> >> [1]http://code.google.com/p/guice-cxf/source/browse/src/main/java/com/google/code/inject/jaxrs/internal/SubresourceInterceptor.java >> >> On Fri, Oct 19, 2012 at 2:19 PM, Sergey Beryozkin-5 [via CXF] >> <[hidden email]> wrote: >>> >>> Hi >>> On 19/10/12 13:02, Jakub Bochenski wrote: >>>> Hi, >>>> >>>>> Yes, to be honest I'm not exactly comfortable with this style and I did >>>>> express the concerns, but there were some convincing feedback regarding >>>>> supporting the implicit injection into EJB-like subresources, etc >>>> Is this publicly available? It would be an interesting read. I did a >>>> quick >>>> google for jax-rs ResourceContext, but all I found was a JIRA page. >>>> >>> >>> You should be able to find it at the the users list visible from JAX-RS >>> 2.0 / JSR339 java project >>> >>>>> Absolutely - this is one more option for users to choose from. >>>>> Similarly >>>>> to me having the reservations about the spec approach, there were the >>>>> concerns about this style is that it is still a no-op method - but >>>>> given >>>>> that it is consistent with the way Spring lookups may work, I'm fine >>>>> with supporting this option too >>>> Given some more effort it's also possible to support purely abstract >>>> methods (from interface or abstract class) by using e.g. asm library. >>>> >>>> Another feature it does not cover is injecting JAX-RS objects into >>>> regular >>>> Java classes, like the example of BookTitleResolver at the bottom of >>>> http://code.google.com/p/guice-cxf/. >>>> >>> >>> I just wonder, now that you've mentioned asm, should we just implement >>> an asm or cglib interceptor which will do the injection and let the >>> application code return a live instance ? >>> >>>>> Then keeping it all on the exchange would be the simplest option >>>> OK I was a bit concerned about possible overhead (for other code >>>> accessing >>>> it) of putting too many objects directly into Exchange object, but I >>>> it's >>>> probably negligible. >>>> >>> Yes, should be negligible >>> >>> Cheers, Sergey >>> >>>> Best regards, >>>> Jakub Bocheński >>>> >>>> >>>> On Fri, Oct 19, 2012 at 1:44 PM, Sergey Beryozkin-5 [via CXF]< >>>> [hidden email]> wrote: >>>> >>>>> Hi >>>>> On 19/10/12 12:37, Jakub Bochenski wrote: >>>>> >>>>>> Hi Sergey, >>>>>> >>>>>>> It does look like ResourceContext (visible starting from CXF 2.7.0) >>>>>>> may >>>>>>> fit nicely into the way you manage the injection of JAX-RS contexts >>>>> into >>>>>>> subresources, ResourceContext can provide a subresource instance or >>>>>>> class to initialize >>>>>> Implementing this with Guice seems easy, but if I understand correctly >>>>> you >>>>>> still have to manually call resourceContext.getResource(), even if you >>>>>> don't have to manually inject dependencies. >>>>>> >>>>> >>>>> Yes, to be honest I'm not exactly comfortable with this style and I did >>>>> express the concerns, but there were some convincing feedback regarding >>>>> supporting the implicit injection into EJB-like subresources, etc >>>>> >>>>>> I think my way still has merit, since it lets you write no method >>>>>> implementation and instead just annotate the method - the resource >>>>>> type >>>>> is >>>>>> defined by return type (then you can use an interface and bind a >>>>> concrete >>>>>> type to it using Guice modules). >>>>>> >>>>> Absolutely - this is one more option for users to choose from. >>>>> Similarly >>>>> to me having the reservations about the spec approach, there were the >>>>> concerns about this style is that it is still a no-op method - but >>>>> given >>>>> that it is consistent with the way Spring lookups may work, I'm fine >>>>> with supporting this option too >>>>> >>>>>>> "putting a new Map inside Exchange for those objects" sounds like the >>>>>>> simplest approach - can you explain why it is needed, is that for >>>>>>> supporting a case where we have a no-op method returning subresource >>>>> class >>>>>> ? >>>>>> >>>>>> To implement a custom scope in Guice you need to have some kind of >>>>>> cache >>>>>> for objects that share a scope. In the case of guice-servlet they use >>>>>> HttpServletRequest attributes to store objects (see [1] starting from >>>>> line >>>>>> 112), I figured that Exchange is the closest thing (well Message is >>>>> closer, >>>>>> but I wanted the scope to cover both in and out processing). >>>>>> >>>>> Then keeping it all on the exchange would be the simplest option >>>>> Cheers, Sergey >>>>> >>>>>> Best regards, >>>>>> Jakub Bocheński >>>>>> >>>>>> [1] >>>>>> >>>>> >>>>> http://code.google.com/p/google-guice/source/browse/extensions/servlet/src/com/google/inject/servlet/ServletScopes.java >>>>>> >>>>>> On Fri, Oct 19, 2012 at 1:21 PM, Sergey Beryozkin-5 [via CXF]< >>>>>> [hidden email]<http://user/SendEmail.jtp?type=node&node=5717002&i=0>> >>>>> wrote: >>>>>> >>>>>>> Hi Jakub >>>>>>> >>>>>>> Good to hear the project is alive :-) >>>>>>> >>>>>>> On 19/10/12 12:06, Jakub Bochenski wrote: >>>>>>>> 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. >>>>>>> >>>>>>> It does look like ResourceContext (visible starting from CXF 2.7.0) >>>>>>> may >>>>>>> fit nicely into the way you manage the injection of JAX-RS contexts >>>>> into >>>>>>> subresources, ResourceContext can provide a subresource instance or >>>>>>> class to initialize >>>>>>> >>>>>>>> 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 :)) >>>>>>> +1 :-) >>>>>>>> >>>>>>>> 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. >>>>>>>> >>>>>>> It is used by a single thread >>>>>>> >>>>>>>> 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. >>>>>>> >>>>>>> "putting a new Map inside Exchange for those objects" sounds like the >>>>>>> simplest approach - can you explain why it is needed, is that for >>>>>>> supporting a case where we have a no-op method returning subresource >>>>> class >>>>>>> ? >>>>>>> >>>>>>> Cheers, Sergey >>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Jakub Bocheński >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Oct 19, 2012 at 11:01 AM, Sergey Beryozkin-5 [via CXF]< >>>>>>>> [hidden >>>>>>>> email]<http://user/SendEmail.jtp?type=node&node=5716997&i=0>> >>>>>>> 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: >>>>>>>>> >>>>>>>>> >>>>>>> >>>>>>>>> . >>>>>>>>> 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. >>>>>>> >>>>>>> >>>>>>> ------------------------------ >>>>>>> If you reply to this email, your message will be added to the >>>>> discussion >>>>>>> below: >>>>>>> >>>>>>> >>>>> >>>>>>> . >>>>>>> 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-tp5635498p5716999.html >>>>> >>>>>> Sent from the cxf-user mailing list archive at Nabble.com. >>>>> >>>>> >>>>> >>>>> >>>>> ------------------------------ >>>>> If you reply to this email, your message will be added to the >>>>> discussion >>>>> below: >>>>> >>>>> >>> >>>>> . >>>>> >>>>> 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-tp5635498p5717003.html >>> >>>> Sent from the cxf-user mailing list archive at Nabble.com. >>> >>> >>> >>> ________________________________ >>> If you reply to this email, your message will be added to the discussion >>> below: >>> >>> http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5717004.html >>> To unsubscribe from CXF + Guice Integration, click here. >>> NAML >> >> >> >> >> -- >> View this message in context: >> http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5717006.html > >> Sent from the cxf-user mailing list archive at Nabble.com. > > > > > ________________________________ > If you reply to this email, your message will be added to the discussion > below: > http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5717008.html > To unsubscribe from CXF + Guice Integration, click here. > NAML -- View this message in context: http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5717009.html Sent from the cxf-user mailing list archive at Nabble.com.
