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.
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). >"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). 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] < [email protected]> 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: > > http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5716997.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-tp5635498p5716999.html Sent from the cxf-user mailing list archive at Nabble.com.
