[
https://issues.apache.org/jira/browse/STANBOL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128453#comment-13128453
]
Olivier Grisel commented on STANBOL-352:
----------------------------------------
How do you plan to handle the life-cycle of the instances of the root
resources? Do you plan to make all the root resources singletons (looked up as
OSGi services)? If so, I think that would require to make all those classes
thread-safe => that might have a very negative impact on the performance
(concurrency) if we have to protect some method used at rendering time by
synchronized keywords.
I really like the fact that JAX-RS resources are by default individual
instances in separate request contexts: that make it very to write simple code
that scales well without having to deal with request concurrency issues. If we
switch to singletons for the root resources the code will be more tricky and
maybe harder to handle concurrency efficiently.
Also if you want to separate the HTML UI + doc from the actual service
implementation, do you think it's possible to register two resources on the
same URL path and manage the rooting from one resources to another using the
HTTP verbs (GET / POST/ ...) and content type negotiation?
I.e.: how to make it possible to have:
GET /engines with "Accept: text/html" return the HTML form for testing and
documentation
POST /engines with "Accept: application/rdf+xml" actually call the service and
return the results as RDF.
If we want to remove Freemarker as a mandatory dependency for the service
resource part while making it easy to deploy it in the default launchers: we
need to have all the web-services automatically documented and testable using
HTML forms by default.
Alternatively one could try to have simple base JAX-RS component that only
implements the service part and derived classes that add the Freemarker
dependent HTML UI and related methods. I don't know who JAX-RS annotations work
in case of derived classes.
> 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
