Hi Jakub
FYI, starting from CXF 2.7.2 the injection of JAX-RS contexts and
parameters into subresource will work if the existing CXF property
"staticSubresourceResolution" is enabled, I did it while working on
implementing JAX-RS 2.0 ResourceContext.
I did not want to make it a default, so the users who may be concerned
about it will simply not enable "staticSubresourceResolution", but I
guess that those who will not see ResourceContext managing their
subresource instances for the purpose of getting the contexts injected
will be fine with setting it on :-)
Cheers, Sergey
On 19/10/12 13:50, Jakub Bochenski wrote:
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
:-)
Yes, I think there was a slight misunderstanding. Both statements are
Guice idioms and they belong to Guice module classses - see [1] and
[2], not to Jax-Rs resources.
I think it might be useful to divide discussing this into two things:
- implementation independent API that will let one express his CDI
needs (@Context, ResourceContext and a custom annotation to allow
interception of noop methods belong here),
- implementations of this API, I guess there would be different ones
for e.g. Guice or Spring (what I was writing above pertains mostly to
Guice-specific implementation).
Staying in the topic of Guice implementation pre- (I'd name it post-)
processing returned instance isn't really needed IMO. I think Guice is
in itself expressive enough to allow all kinds of injections - both of
Jax-Rs context and custom dependencies.
Best regards,
Jakub Bocheński
[1]ttp://code.google.com/p/google-guice/wiki/ProvidesMethods
[2]http://code.google.com/p/google-guice/wiki/LinkedBindings
On Fri, Oct 19, 2012 at 2:39 PM, Sergey Beryozkin-5 [via CXF]
<[hidden email]<http://user/SendEmail.jtp?type=node&node=5720515&i=0>>
wrote:
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]
<[hidden email]> 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.
________________________________
If you reply to this email, your message will be added to the
discussion
below:
http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5717008.html
To unsubscribe from CXF + Guice Integration, click here.
NAML
--
View this message in context:
http://cxf.547215.n5.nabble.com/CXF-Guice-Integration-tp5635498p5717009.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-tp5635498p5720515.html
To unsubscribe from CXF + Guice Integration, click
here<http://cxf.547215.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5635498&code=a3ViYS5ib2NoZW5za2lAZ21haWwuY29tfDU2MzU0OTh8MTAyOTgwODU3MA==>
.
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>
