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 Fri, 19 Oct 2012 12:38:51 GMT

On 19/10/12 13:31, Jakub Bochenski wrote:
> Hi,
>
>
>> You should be able to find it at the the users list visible from JAX-RS
>> 2.0 / JSR339 java project
> thanks
>
>> I just wonder, now that you've mentioned asm, should we just implement
>> an asm or cglib interceptor which will do the injection and let the
>> application code return a live instance ?
> I'm not sure what you mean exactly by "letting the application code
> return a live instance".
> Currently I have implemented an AopAlliance interceptor, which is
> similiar to asm, only easier (but I couldn't get it to work on
> abstract methods) - see [1]. It defers to Guice injector, then in
> Guice configuration you can either do sth. like:
>
>     bind(MyResource.class).to(MyResourceImpl.class);
>
> as well as:
>
>     @Provides
>     MyResource provideResourceImplementation(@Named("property") String conf){
>         return new MyResourceImpl(conf. new Date());
>     }

That is a root resource, right ? So I was thinking about doing some kind 
of dynamic binding I guess, when we have a subresource instance returned 
? So basically, instead of providing a hint to Guice by having a no-op 
method,  pre-process a returned subresource instance by injecting all 
JAX-RS contexts if needed, sorry, I may have missed the point by now :-)

Cheers, Sergey


>
> Best regards,
> Jakub Bocheński
>
> [1]http://code.google.com/p/guice-cxf/source/browse/src/main/java/com/google/code/inject/jaxrs/internal/SubresourceInterceptor.java
>
> On Fri, Oct 19, 2012 at 2:19 PM, Sergey Beryozkin-5 [via CXF]
> <ml-node+s547215n5717004h3@n5.nabble.com>  wrote:
>>
>> Hi
>> On 19/10/12 13:02, Jakub Bochenski wrote:
>>> 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.
>>>
>>
>> You should be able to find it at the the users list visible from JAX-RS
>> 2.0 / JSR339 java project
>>
>>>> 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/.
>>>
>>
>> I just wonder, now that you've mentioned asm, should we just implement
>> an asm or cglib interceptor which will do the injection and let the
>> application code return a live instance ?
>>
>>>> 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.
>>>
>> Yes, should be negligible
>>
>> Cheers, Sergey
>>
>>> Best regards,
>>> Jakub Bocheński
>>>
>>>
>>> On Fri, Oct 19, 2012 at 1:44 PM, Sergey Beryozkin-5 [via CXF]<
>>> [hidden email]>   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:
>>>>
>>>>
>>
>>>> .
>>>> 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.
>>
>>
>>
>> ________________________________
>> If you reply to this email, your message will be added to the discussion below:
>> http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5717004.html
>> To unsubscribe from CXF + Guice Integration, click here.
>> NAML
>
>
>
>
> --
> View this message in context: http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5717006.html
> Sent from the cxf-user mailing list archive at Nabble.com.



Mime
View raw message