cxf-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sergey Beryozkin <sberyoz...@gmail.com>
Subject Re: CXF + Guice Integration
Date Wed, 25 Apr 2012 11:36:12 GMT
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<kuba.bochenski@gmail.com>:
>> 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-tp5635498p5651662.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

Mime
View raw message