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 <tjwat...@us.ibm.com> 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 <raymond.a...@liferay.com> > To: Equinox development mailing list <equinox-dev@eclipse.org>, > Date: 03/26/2014 09:51 AM > Subject: [equinox-dev] [http-service] servlet compatibility > Sent by: equinox-dev-boun...@eclipse.org > ------------------------------ > > > > 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 > equinox-dev@eclipse.org > https://dev.eclipse.org/mailman/listinfo/equinox-dev > > > _______________________________________________ > equinox-dev mailing list > equinox-dev@eclipse.org > 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)
<<inline: graycol.gif>>
_______________________________________________ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
