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());
}
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]
<[email protected]> 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.
