Reading the RFC [1] I see the following defined for the http.service.endpoint:
"A String+ value of Http Service endpoints provided as URLs e.g. http://192.168.1.10:8080/ or relative paths, e.g. /myapp/. Relative paths maybe used if the scheme and authority parts of the URLs are not known such as in a bridged Http Service implementation. If the Http Service is serving the root context and neither scheme nor authority is known, the value of the property is "/". Each entry must end with a slash." It goes on further to state: "The port and address information may not always be available to the Http Service implementation, particularly in a bridged implementation. In such cases the osgi.http.endpoint attribute may be absent." If ServletRegistration is not available in a <3.0 container could we just not set this service property in such an environment? Tom [1] https://github.com/osgi/design/tree/master/rfcs/rfc0189 From: Raymond Auge <[email protected]> To: Equinox development mailing list <[email protected]>, Date: 03/26/2014 09:51 AM Subject: [equinox-dev] [http-service] servlet compatibility Sent by: [email protected] Hey all, I have a conundrum. While trying to retain backward compatibility, I'm encountering an initial difficulty. In order to calculate the values for `http.service.endpoint` I need to get all the mappings of the proxy servlet. However, the only "spec" way of doing that is by calling: String servletName = config.getServletName(); ServletRegistration servletRegistration = hostServletContext.getServletRegistration(servletName); Collection<String> mappings = servletRegistration.getMappings(); However, while I can proxy the hostServletContext and avoid the "no such method" issue for `getServletRegistration`, the return type is the real problem. In fact, if we can't calculate the proxy servlet mappings this way, we can't advance without at least one endpoint value since this is required. How should we deal with that scenario? 1) fail without mercy? 2) expect some user value (init-param or config) we'll retrieve (which might be wrong) If we do 1) we might as well just call the new method and fail in Servlet <3.0 containers If we do 2) we allow a http-service which can potentially return inaccurate endpoint info. -- Raymond Augé (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) _______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
<<inline: graycol.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
