I think I got confused here to think that you added a staticSubresourceResolution property to a ResourceContext, whereas you meant the already existing property JaxRsServerFactoryBean right?
I'll have to clean-up my project and bring it up to speed with 2.7 during the coming holidays, so expect to hear from me soon :) Best regards, Jakub Bocheński On Fri, Dec 21, 2012 at 3:56 PM, Jakub Bocheński <[email protected]>wrote: > 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-tp5635498p5720681.html Sent from the cxf-user mailing list archive at Nabble.com.
