cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jakub Bochenski <kuba.bochen...@gmail.com>
Subject Re: CXF + Guice Integration
Date Fri, 19 Oct 2012 11:06:26 GMT
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.
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 :))

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.

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.

Best regards,
Jakub Bocheński


On Fri, Oct 19, 2012 at 11:01 AM, Sergey Beryozkin-5 [via CXF] <
ml-node+s547215n5716988h7@n5.nabble.com> 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:
>
> http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5716988.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-tp5635498p5716995.html
Sent from the cxf-user mailing list archive at Nabble.com.

Mime
View raw message