[
https://issues.apache.org/jira/browse/STANBOL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13136943#comment-13136943
]
Olivier Grisel edited comment on STANBOL-352 at 10/27/11 3:15 PM:
------------------------------------------------------------------
Let me summarize here an off-list discussion between Reto, Rupert and I:
1- Short term action: remove the dependency on the Jersey-specific Viewable
interface / MessageBodyWriter by writing a minimalist Stanbol-specific
replacement that binds the Freemarker template rendering directly by only using
the JAX-RS public API (no implementation specific classes).
Then check that this allows a deployment of the Stanbol JAX-RS resources on a
Apache Wink server to validate the approach.
2- Long term action: rethink the OSGi service lookup model from JAX-RS
resources:
- Personally I would rather avoid having the root resources registered as OSGi
singletons to keep the ability to precompute request specific datastructures in
the constructor of the resource in a concurrent-safe manner (since by default
JAX-RS uses one instance per-request for easy request isolation and
thread-safety).
- Rupert had started implementating a Service tracker-based JAX-RS
implementation we might want to investigate further.
- Reto opposed to that design that we would not be able to leverage the
fine-grained filtering and cardinality management of the OSGi Declarative
Services and the powerful DI of SCR annotations (JAX-RS @Context lookup is much
cruder). But do we really need powerful OSGi DS lookups in JAX-RS resources?
New use cases provided by the LMF integration might help clarify the impact of
the design choices for the second point. Anyway when we start thinking about
that second point we should open a dedicated JIRA issue.
was (Author: ogrisel):
Let me summarize here an off-list discussion between Reto, Rupert and I:
1- Short term action: remove the dependency on the Jersey-specific Viewable
interface / MessageBodyWriter by writing a minimalist Stanbol-specific
replacement that binds the Freemarker template rendering directly by only using
the JAX-RS public API (no implementation specific classes).
Then check that this allows a deployment of the Stanbol JAX-RS resources on a
Apache Wink server to validate the approach.
2- Long term action: rethink the OSGi service lookup model from JAX-RS
resources:
- Personally I would rather avoid having the root resources registered as OSGi
singletons to keep the ability to precompute request specific datastructures in
the constructor of the resource in a concurrent-safe manner (since by default
JAX-RS uses one instance per-request for easy request isolation and
thread-safety).
- Rupert had started implementating a Service tracker-based JAX-RS
implementation we might want to investigate further.
- Reto opposed to that design that we would not be able to leverage the
fine-grained filtering and cardinality management of the OSGi Declarative
Services and the powerful DI of SCR annotations (JAX-RS @Context lookup is much
cruder). But do we really need powerful OSGi DS lookups in JAX-RS resources?
New use cases provided by the LMV integration might help clarify the impact of
the design choices for the second point. Anyway when we start thinking about
that second point we should open a dedicated JIRA issue.
> make stanbol web services (root resource classes) more portable
> ---------------------------------------------------------------
>
> Key: STANBOL-352
> URL: https://issues.apache.org/jira/browse/STANBOL-352
> Project: Stanbol
> Issue Type: Improvement
> Reporter: Reto Bachmann-Gmür
>
> Despite using the jax-rs (jsr 311) standard stanbol web components aren't
> very portable. The components depend on jersey mostly for producing html
> representation (using freemarker) furthermore they user the ServletContext to
> access osgi services (while this should work with other servlet based jax-rs
> implementation the standard osgi/osgi-ds mechanism should be used). There are
> also some apparent jersey dependencies that in fact aren't, for instance
> org.apache.stanbol.entityhub.jersey.utils.JerseyUtils doesn't depend on
> jersey.
> To improve portability I suggest to:
> - let all root resources be osgi-ds components and have their dependencies
> injected
> And either:
> - extract Viewable and the respective MessageBodyWriter from Jersey to a
> separate bundle so that they can be used on any compliant jax-rs
> implementation
> - separate rest interfaces that do not need rendering from the ui produced
> using freemarker. This would allow to at least run the REST-endpoint for
> machines on other platform.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
