Petr Dolezal created OLINGO-282:
-----------------------------------
Summary: Service root might not be determined correctly when
@ApplicationPath is applied
Key: OLINGO-282
URL: https://issues.apache.org/jira/browse/OLINGO-282
Project: Olingo
Issue Type: Question
Components: odata2-core
Affects Versions: V2 1.3.0
Environment: Jetty web container embedded in Equinox OSGi container,
using CXF 3.0.0.milestone2 as JAX-RS implementation
Reporter: Petr Dolezal
Priority: Minor
Service root is not determined correctly when the appropriate ODataApplication
is annotated with @ApplicationPath annotation. I'm not entirely sure if it is a
bug in Olingo or in CXF which is used in my environment as the JAX-RS
implementation.
Anyway, the result of this situation is that the generated links to entities
are not correct; let's have our case as the example:
- the servlet runs at http://www.my-company.example/restful/
- the ODataApplication is annotated with @ApplicationPath("/sessioning")
- our entity set is accessible at
http://www.my-company.example/restful/sessioning/Sessions, hence a particular
entity 'id' is available at
http://www.my-company.example/restful/sessioning/Sessions('id')
- however, the result contains:
{"__metadata":{"id":"http://www.my-company.example/restful/Sessions('id')","uri":"http://www.my-company.example/restful/Sessions('id')"...
Note the difference in the paths, the "uri" and "id" fields omit the
"/sessioning" part which is the part provided via the annotation. The same
omission occurs in the metadata for the service (service root is also
truncated).
Due to our not-so-often environment (Jetty embedded in OSGi) we had to use the
annotation and employ yet other settings to make CXF work at all (more details
can be found in this dicussion: [
http://mail-archives.apache.org/mod_mbox/cxf-users/201404.mbox/%3c75ae60817a4e3d45a321599e7562b4b716f94...@defthw99ez1msx.ww931.my-it-solutions.net%3E
]).
To recap, here are some of the important parts of our sources:
// Our ODataApplication class
@ApplicationPath("/sessioning")
public class SessionODataApplication extends AbstractODataApplication {
...
}
// Our ODataSingleProcessor
public final class SessionODataSingleProcessor extends ODataSingleProcessor {
...
public ODataResponse readEntity(GetEntityUriInfo uriInfo, String
contentType) throws ODataException {
...
final URI serviceRoot = getContext().getPathInfo().getServiceRoot(); //
Here we get the path without the "/sessioning" part
final EntityProviderWriteProperties writer =
EntityProviderWriteProperties.serviceRoot(serviceRoot).build();
return EntityProvider.writeEntry(contentType, entitySet, data, writer);
}
...
}
// Our web.xml
<web-app … >
....
<servlet>
<servlet-name>ODataServicesHostServlet</servlet-name>
<servlet-class>org.apache.cxf.jaxrs.servlet.CXFNonSpringJaxrsServlet</servlet-class>
<init-param>
<!-- CXF extension: multiple JAX-RS applications for a servlet -->
<param-name>javax.ws.rs.Application</param-name>
<param-value>
net.atos.dirx.access.net.rest.services.authz.RequestODataApplication,
net.atos.dirx.access.net.rest.services.session.SessionODataApplication
</param-value>
</init-param>
<init-param>
<!--
CXF specific: force using @ApplicationPath, necessary with
multiple applications (otherwise mapping is used only, and
it must be unique)
-->
<param-name>jaxrs.application.address.ignore</param-name>
<param-value>false</param-value>
</init-param>
</servlet>
<servlet-mapping>
<servlet-name>ODataServicesHostServlet</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>
</web-app>
// For completeness, system property
org.apache.cxf.osgi.http.transport.disable=true
According to me the most suspicious point is RestUtil.buildODataPathInfo(), but
I'm not sure how exactly the JAX-RS application can learn the base URI and how
the service root should be determined according to the all specifications.
While CXF manages the routing to the right application now, it might not
provide entirely correct information of the base URI for the JAX-RS application
- there is still an open ticket for CXF related to the mapping problem [
https://issues.apache.org/jira/browse/CXF-5702 ]. Could it be the cause?
--
This message was sent by Atlassian JIRA
(v6.2#6252)
