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();
}
// 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.
Best regards,
Jakub Bocheński
On Fri, Apr 13, 2012 at 5:37 PM, Sergey Beryozkin-5 [via CXF]
<[email protected]> 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.
