Hi Sergey, thanks for the info. Can you explain how is this related to setting the staticSubresourceResolution property on JaxRsServerFactoryBean? Is this a replacement or another way to set the same thing?
Best regards, Jakub Bocheński On Wed, Dec 19, 2012 at 6:20 PM, Sergey Beryozkin-5 [via CXF] < [email protected]> wrote: > Hi Jakub > > FYI, starting from CXF 2.7.2 the injection of JAX-RS contexts and > parameters into subresource will work if the existing CXF property > "staticSubresourceResolution" is enabled, I did it while working on > implementing JAX-RS 2.0 ResourceContext. > > I did not want to make it a default, so the users who may be concerned > about it will simply not enable "staticSubresourceResolution", but I > guess that those who will not see ResourceContext managing their > subresource instances for the purpose of getting the contexts injected > will be fine with setting it on :-) > > Cheers, Sergey > > On 19/10/12 13:50, Jakub Bochenski wrote: > > >> 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] > > <[hidden email] <http://user/SendEmail.jtp?type=node&node=5720515&i=0>> > 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. > > > -- > Sergey Beryozkin > > Talend Community Coders > http://coders.talend.com/ > > Blog: http://sberyozkin.blogspot.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-tp5635498p5720515.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-tp5635498p5720680.html Sent from the cxf-user mailing list archive at Nabble.com.
