The problem is creating the context path without a request. The existing impl never needs to do that.
I'll try to work around it. - Ray On Wed, Mar 26, 2014 at 1:33 PM, Thomas Watson <[email protected]> wrote: > That is fine to start, but it would be good to do the right thing for >=3.0 > > That being said, it seems you are saying the current implementation of > HttpService is not handling this correctly for the ServletContext? It > would be good to start opening various bugs for these issues so we can > record the discussion there. > > Tom > > > > [image: Inactive hide details for Raymond Auge ---03/26/2014 11:00:10 > AM---I'll proceed for now under the assumption it's not set, and]Raymond > Auge ---03/26/2014 11:00:10 AM---I'll proceed for now under the assumption > it's not set, and see where I end up when we get to non-ro > > > From: Raymond Auge <[email protected]> > To: Equinox development mailing list <[email protected]>, > Date: 03/26/2014 11:00 AM > Subject: Re: [equinox-dev] [http-service] servlet compatibility > > Sent by: [email protected] > ------------------------------ > > > > I'll proceed for now under the assumption it's not set, and see where I > end up when we get to non-root context mapping. > > - Ray > > > On Wed, Mar 26, 2014 at 11:32 AM, Raymond Auge > <*[email protected]*<[email protected]>> > wrote: > > .. at least I can't think of one? > > - Ray > > > On Wed, Mar 26, 2014 at 11:31 AM, Raymond Auge < > *[email protected]* <[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]* <[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/* <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*<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]*<[email protected]> > > > To: Equinox development mailing list > <*[email protected]*<[email protected]>>, > > Date: 03/26/2014 09:51 AM > Subject: [equinox-dev] [http-service] servlet compatibility > Sent by: > *[email protected]*<[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]* <[email protected]> > *https://dev.eclipse.org/mailman/listinfo/equinox-dev*<https://dev.eclipse.org/mailman/listinfo/equinox-dev> > > > _______________________________________________ > equinox-dev mailing list > *[email protected]* <[email protected]> > *https://dev.eclipse.org/mailman/listinfo/equinox-dev*<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) > > > > > > -- > *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)
<<inline: graycol.gif>>
_______________________________________________ equinox-dev mailing list [email protected] https://dev.eclipse.org/mailman/listinfo/equinox-dev
