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]
<[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.


--
Sergey Beryozkin

Talend Community Coders
http://coders.talend.com/

Blog: http://sberyozkin.blogspot.com

Reply via email to