Re: [equinox-dev] [http-service] servlet compatibility
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 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); CollectionString 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 equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [http-service] servlet compatibility
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); CollectionString 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
Re: [equinox-dev] [http-service] servlet compatibility
.. at least I can't think of one? - Ray On Wed, Mar 26, 2014 at 11:31 AM, Raymond Auge raymond.a...@liferay.comwrote: 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.comwrote: 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); CollectionString 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) -- *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
Re: [equinox-dev] [http-service] servlet compatibility
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 raymond.a...@liferay.comwrote: .. at least I can't think of one? - Ray On Wed, Mar 26, 2014 at 11:31 AM, Raymond Auge raymond.a...@liferay.comwrote: 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.comwrote: 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); CollectionString 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) -- *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 equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [http-service] servlet compatibility
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 From: Raymond Auge raymond.a...@liferay.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 03/26/2014 11:00 AM Subject:Re: [equinox-dev] [http-service] servlet compatibility Sent by:equinox-dev-boun...@eclipse.org 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 raymond.a...@liferay.com wrote: .. at least I can't think of one? - Ray On Wed, Mar 26, 2014 at 11:31 AM, Raymond Auge raymond.a...@liferay.com 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 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 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); CollectionString 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 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é (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) -- Raymond Augé (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) -- Raymond Augé (@rotty3000) Senior Software Architect Liferay, Inc. (@Liferay) ___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev inline: graycol.gif___ equinox-dev mailing list equinox-dev@eclipse.org https://dev.eclipse.org/mailman/listinfo/equinox-dev
Re: [equinox-dev] [http-service] servlet compatibility
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 tjwat...@us.ibm.com 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 raymond.a...@liferay.com To: Equinox development mailing list equinox-dev@eclipse.org, Date: 03/26/2014 11:00 AM Subject: Re: [equinox-dev] [http-service] servlet compatibility Sent by: equinox-dev-boun...@eclipse.org -- 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 *raymond.a...@liferay.com*raymond.a...@liferay.com wrote: .. at least I can't think of one? - Ray On Wed, Mar 26, 2014 at 11:31 AM, Raymond Auge *raymond.a...@liferay.com* raymond.a...@liferay.com 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 *tjwat...@us.ibm.com* 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/* 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 *raymond.a...@liferay.com*raymond.a...@liferay.com To: Equinox development mailing list *equinox-dev@eclipse.org*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*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); CollectionString 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
