.. at least I can't think of one? - Ray
On Wed, Mar 26, 2014 at 11:31 AM, Raymond Auge <[email protected]>wrote: > I'm not sure we can because there will be no way to construct a context > Path for new ServletContexts which are not mapped to the default path. > > > On Wed, Mar 26, 2014 at 11:21 AM, Thomas Watson <[email protected]>wrote: > >> 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 >> >> [image: Inactive hide details for Raymond Auge ---03/26/2014 09:51:19 >> AM---Hey all, I have a conundrum.]Raymond Auge ---03/26/2014 09:51:19 >> AM---Hey all, I have a conundrum. >> >> 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é* <http://www.liferay.com/web/raymond.auge/profile> >> (@rotty3000) >> Senior Software Architect >> *Liferay, Inc.* <http://www.liferay.com/> (@Liferay) >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> >> _______________________________________________ >> equinox-dev mailing list >> [email protected] >> https://dev.eclipse.org/mailman/listinfo/equinox-dev >> >> > > > -- > *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> > (@rotty3000) > Senior Software Architect > *Liferay, Inc.* <http://www.liferay.com> (@Liferay) > > -- *Raymond Augé* <http://www.liferay.com/web/raymond.auge/profile> (@rotty3000) Senior Software Architect *Liferay, Inc.* <http://www.liferay.com> (@Liferay)
<<inline: graycol.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
