You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@stanbol.apache.org by "Reto Bachmann-Gmür (Created JIRA)" <ji...@apache.org> on 2011/10/16 18:58:12 UTC
[jira] [Created] (STANBOL-352) make stanbol web services (root
resource classes) more portable
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
[jira] [Commented] (STANBOL-352) make stanbol web services (root
resource classes) more portable
Posted by "Olivier Grisel (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STANBOL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13136943#comment-13136943 ]
Olivier Grisel commented on STANBOL-352:
----------------------------------------
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
[jira] [Commented] (STANBOL-352) make stanbol web services (root
resource classes) more portable
Posted by "Reto Bachmann-Gmür (Commented JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STANBOL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128914#comment-13128914 ]
Reto Bachmann-Gmür commented on STANBOL-352:
--------------------------------------------
The root resources I have looked at were all thread-safe insofar as the resource methods do not modify the state of the instance, so here using a singleton actually has a positive impact on performance. Do you have example for root-resource classes you believe would become more complex?
As for the separation of the html ui I think there is one design issue that in stanbol often the resource method cares about content negotiation, imho the resource method should be be agnostic on how the entity is serialized, this should be the business of the MessageBodyWriter. It is not possible (according to the jax-rs spec) for two classes to handle different verbs for the same uri-path.
Inheritance works with the jax-rs annotation so having subclasses providing freemarker based UI would be a solution. But I think the best solution would be to make the freemarker support independent on jersey jax-rs implementation, we can use classes (like MessageBodyWriters) from jersey as long as they run on any spec compliant jax-rs implementation.
> 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
[jira] [Commented] (STANBOL-352) make stanbol web services (root
resource classes) more portable
Posted by "Olivier Grisel (Commented) (JIRA)" <ji...@apache.org>.
[ 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
[jira] [Commented] (STANBOL-352) make stanbol web services (root
resource classes) more portable
Posted by "Reto Bachmann-Gmür (Commented JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STANBOL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13128450#comment-13128450 ]
Reto Bachmann-Gmür commented on STANBOL-352:
--------------------------------------------
Using freemarker without jersey specific classes: http://stackoverflow.com/questions/3377822/using-jax-rs-jersey-with-freemarker-templates
> 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
[jira] [Commented] (STANBOL-352) make stanbol web services (root
resource classes) more portable
Posted by "Rupert Westenthaler (Commented) (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STANBOL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129469#comment-13129469 ]
Rupert Westenthaler commented on STANBOL-352:
---------------------------------------------
Reto, how can the MessageBodyWriter deal with content negotiation? it gets only the response headers and can not know about the Accept header parse with the request? The same would be true for Accept-Encoding and Accept-Charset.
The only way I see to process this kind of information is within the jax-rs resource or do I miss an important part of the spec.
> 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
[jira] [Commented] (STANBOL-352) make stanbol web services (root
resource classes) more portable
Posted by "Reto Bachmann-Gmür (Commented JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STANBOL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13129948#comment-13129948 ]
Reto Bachmann-Gmür commented on STANBOL-352:
--------------------------------------------
Rupert, it could know of the request header by having them injected as field with @Context (which would be a proxyto the values pertinent to the current request). But what I actually meant if having multiple MBW for the various content types. E.g. the resource method returns an instance of Person and we have two classes extending MessageBodyWriter<Person> one producing PDF and the other producing HTML.
> 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
[jira] [Commented] (STANBOL-352) make stanbol web services (root
resource classes) more portable
Posted by "Reto Bachmann-Gmür (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STANBOL-352?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13506615#comment-13506615 ]
Reto Bachmann-Gmür commented on STANBOL-352:
--------------------------------------------
Part of it done by STANBOL-750 and by STANBOL-822. Service vs. webfragment issue not yet addressed.
> 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
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Issue Comment Edited] (STANBOL-352) make stanbol web
services (root resource classes) more portable
Posted by "Olivier Grisel (Issue Comment Edited) (JIRA)" <ji...@apache.org>.
[ 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