[
https://issues.apache.org/jira/browse/SLING-2192?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14735074#comment-14735074
]
Clinton H Goudie-Nice edited comment on SLING-2192 at 9/8/15 4:21 PM:
----------------------------------------------------------------------
As I've been looking at this patch, I've been thinking of a few problems.
1) The @Service(Object.class) and @Property(name="javax.ws.rs", boolValue=true)
IMO, this feels a bit of a hack.
2) The shared container provides some potentially undesirable behavior.
If I have two different bundles, each providing some Resources and each
providing some Providers, one bundle's providers can be used by another bundle.
For example, I have two resources that produce text/html, bundle A provides a
MessageBodyWriter for text/html, and bundle B does not. Is it intentional that
bundle B can use the writer from bundle A if bundle A is started and active?
Should bundle B provide it's own implementation? What happens if they both
provide writers for text/html.
If two bundles have overlapping Resources, what would the intended behavior be?
I can't clearly figure it out.
If bundle A provides an exception mapper, say for a resource not found, and it
is evaluated first, would it fall through to bundle B? Should it?
3) Adding the @Service annotation indicates a singleton class, but this is
contrary to JaxRS, where a resource is only a singleton if it's annotated with
@Singleton
Additionally, I don't see support for a non-singleton class.
4) I'm not a big fan of the servlet listening on any specific URI. I think it
is indicative of non-sling like behavior, and results in difficulty figuring
out who is handling which URIs. If my bundle listens on /, provides an
exception mapper for resource not found, who's resource mapper is more
important? Mine or slings?
As I've been thinking about the problem space, I've been thinking of a solution
that looks like this:
A) A specific sling node, in the tree, that defines all attributes of a jax-rs
container. This includes, a list of resources, providers, exception mappers,
features, etc..
B) The jaxrs container is life-cycled with the bundle that it refers to, so if
that bundle is offline, so is the container.
C) The sling uri to the container is the root context of the bridge between
sling and jaxrs.
This resolves (1) as the resources, providers, etc are explicitly defined in
the sling node.
This resolves (2) as each container is isolated from each other container.
This resolves (3) as the container itself builds the classes referred to and
can maintain it's own isolation and lifecycle.
This resolves (4) as you must define a sling path to a given set of resources.
From there the tree to the individual resources is obscured, but the root
context is not obscured.
Thoughts?
was (Author: cgoudie):
As I've been looking at this patch, I've been thinking of a few problems.
1) The @Service(Object.class) and @Property(name="javax.ws.rs", boolValue=true)
IMO, this feels a bit of a hack.
2) The shared container provides some potentially undesirable behavior.
If I have two different bundles, each providing some Resources and each
providing some Providers, one bundle's providers can be used by another bundle.
For example, I have two resources that produce text/html, bundle A provides a
MessageBodyWriter for text/html, and bundle B does not. Is it intentional that
bundle B can use the writer from bundle A if bundle A is started and active?
Should bundle B provide it's own implementation? What happens if they both
provide writers for text/html.
If two bundles have overlapping Resources, what would the intended behavior be?
I can't clearly figure it out.
If bundle A provides an exception mapper, say for a resource not found, and it
is evaluated first, would it fall through to bundle B? Should it?
3) Adding the @Service annotation indicates a singleton class, but this is
contrary to JaxRS, where a resource is only a singleton if it's annotated with
@Singleton
4) I'm not a big fan of the servlet listening on any specific URI. I think it
is indicative of non-sling like behavior, and results in difficulty figuring
out who is handling which URIs. If my bundle listens on /, provides an
exception mapper for resource not found, who's resource mapper is more
important? Mine or slings?
As I've been thinking about the problem space, I've been thinking of a solution
that looks like this:
A) A specific sling node, in the tree, that defines all attributes of a jax-rs
container. This includes, a list of resources, providers, exception mappers,
features, etc..
B) The jaxrs container is life-cycled with the bundle that it refers to, so if
that bundle is offline, so is the container.
C) The sling uri to the container is the root context of the bridge between
sling and jaxrs.
This resolves (1) as the resources, providers, etc are explicitly defined in
the sling node.
This resolves (2) as each container is isolated from each other container.
This resolves (3) as the container itself builds the classes referred to and
can maintain it's own isolation and lifecycle.
This resolves (4) as you must define a sling path to a given set of resources.
From there the tree to the individual resources is obscured, but the root
context is not obscured.
Thoughts?
> Support JAX-RS resource classes
> -------------------------------
>
> Key: SLING-2192
> URL: https://issues.apache.org/jira/browse/SLING-2192
> Project: Sling
> Issue Type: New Feature
> Reporter: Reto Gmür
> Attachments: SLING-2192-20110310.patch, SLING-2192-20111004.patch,
> SLING-2192-20111013.patch, SLING-2192-new-jax-rs-bundle.patch,
> SLING-2192-new-jax-rs-bundle.patch,
> SLING-2192-with-sling-style-style-registration.patch,
> SLING-2192-with-tests.patch, jaxrs-in-contrib.patch, slingr-on-wink-osgi.patch
>
>
> It should be possible to register jax resource classes and providers as
> services. As they don't implement a specific interface services that expose
> java.lang.Object should be considered as javx-rs services iff they have the
> service property "javax.ws.rs" set to true.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
