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.
>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/. >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. Best regards, Jakub Bocheński On Fri, Oct 19, 2012 at 1:44 PM, Sergey Beryozkin-5 [via CXF] < [email protected]> 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: > > http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5717002.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-tp5635498p5717003.html Sent from the cxf-user mailing list archive at Nabble.com.
