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 Thu, 19 Apr 2012 12:46:56 GMT
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]
<ml-node+s547215n5651560h39@n5.nabble.com> 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
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> View this message in context:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5635498.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-tp5635498p5636772.html
>>>>>>>>> To unsubscribe from CXF + Guice Integration, click here.
>>>>>>>>> NAML
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> View this message in context:
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5637048.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-tp5635498p5638198.html
>>>>>>> To unsubscribe from CXF + Guice Integration, click here.
>>>>>>> NAML
>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>>
>>>>>>
>>>>>> http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5638240.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-tp5635498p5638695.html
>>>>> To unsubscribe from CXF + Guice Integration, click here.
>>>>> NAML
>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>>
>>>> http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5644367.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-tp5635498p5651492.html
>>> To unsubscribe from CXF + Guice Integration, click here.
>>> NAML
>>
>>
>> --
>> View this message in context:
>> http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5651535.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-tp5635498p5651560.html
> To unsubscribe from CXF + Guice Integration, click here.
> NAML


--
View this message in context: http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5651650.html
Sent from the cxf-user mailing list archive at Nabble.com.

Mime
View raw message