jaxrs-whiteboard 1.0.4

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

jaxrs-whiteboard 1.0.4

Nhut Thai Le

Hello,

We have been using aries-jaxrs-whiteboard to run our REST api along with paxweb-extender-whiteboard for sometimes. Recently we upgraded aries-jaxrs-whiteboard from version 1.0.1 to 1.0.4 and noticed that some of our servlets/filters are not working anymore. Digging into the servlet registration process, I found that in the new aries-jaxrs-whiteboard, a cxf-servlet is registered with url pattern /* which makes this servlet handles any request that does not match the registered urlPattern without giving it a chance to match to filter pattern. Is this a bug or i need to add some configuration to prevent this cxf-servlet to handle unmatched request?
Attached is the screenshot showing the cxf-servlet being registered with /* pattern.

Thai Le

aries-jaxrs-whiteboard104.PNG (257K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jaxrs-whiteboard 1.0.4

Carlos Sierra Andrés-3

Hi Thai Le,

to match spec requirements the jaxrs whiteboard registers one ServletContextHelper per JAX-RS application (unless you use aries proprietary extensions to reuse pre existing servlet context helpers) and then deploys CXF servlet in it. The servlet context helper carries the properties from the application service so, if you need to deploy some filters to the applications ServletContextHelper you should be able to do so targeting the servlet context helper with the same osgi.jaxrs.name as your application.

CXF servlet is registered to serve all requests that arrive to the application's path because that path is supposed to belong to the REST application. This does not prevent any javax filters to be executed before the servlet. You should be able to register the filters to specific URL patterns or directly to the CXF servlet. These filters are going to execute before CXF servlet. So the servlet url pattern should not prevent any filters to be executed, if it did it would be a bug in the HTTP Whiteboard implementation.

Would this help?

Carlos.

El 23/4/19 a las 20:48, Nhut Thai Le escribió:

Hello,

We have been using aries-jaxrs-whiteboard to run our REST api along with paxweb-extender-whiteboard for sometimes. Recently we upgraded aries-jaxrs-whiteboard from version 1.0.1 to 1.0.4 and noticed that some of our servlets/filters are not working anymore. Digging into the servlet registration process, I found that in the new aries-jaxrs-whiteboard, a cxf-servlet is registered with url pattern /* which makes this servlet handles any request that does not match the registered urlPattern without giving it a chance to match to filter pattern. Is this a bug or i need to add some configuration to prevent this cxf-servlet to handle unmatched request?
Attached is the screenshot showing the cxf-servlet being registered with /* pattern.

Thai Le
Reply | Threaded
Open this post in threaded view
|

Re: jaxrs-whiteboard 1.0.4

Nhut Thai Le
Hi Carlos,

Thank you for your reply. I understand that cxf -servlet should only serve requests that match url patterns of the REST application, but what I am saying is that by upgrading aries-jaxrs-whiteboard to 1.0.4, I see cxf-servlet is registered to handle request for /* which i have no REST application that maps to. Here is the screenshot showing the new aries-jaxrs-whiteboard registers a ServletContextHelper with context.path=/ while the version 1.0.1 registers a ServletContextHelper with context.path="". 

I believe this is a bug in aries-jaxrs-whiteboard instead of paxweb so i opened a ticket https://issues.apache.org/jira/browse/ARIES-1912

If you still think it's paxweb issue, please let me know.

Thai

On Wed, Apr 24, 2019 at 3:00 AM Carlos Sierra Andrés <[hidden email]> wrote:

Hi Thai Le,

to match spec requirements the jaxrs whiteboard registers one ServletContextHelper per JAX-RS application (unless you use aries proprietary extensions to reuse pre existing servlet context helpers) and then deploys CXF servlet in it. The servlet context helper carries the properties from the application service so, if you need to deploy some filters to the applications ServletContextHelper you should be able to do so targeting the servlet context helper with the same osgi.jaxrs.name as your application.

CXF servlet is registered to serve all requests that arrive to the application's path because that path is supposed to belong to the REST application. This does not prevent any javax filters to be executed before the servlet. You should be able to register the filters to specific URL patterns or directly to the CXF servlet. These filters are going to execute before CXF servlet. So the servlet url pattern should not prevent any filters to be executed, if it did it would be a bug in the HTTP Whiteboard implementation.

Would this help?

Carlos.

El 23/4/19 a las 20:48, Nhut Thai Le escribió:

Hello,

We have been using aries-jaxrs-whiteboard to run our REST api along with paxweb-extender-whiteboard for sometimes. Recently we upgraded aries-jaxrs-whiteboard from version 1.0.1 to 1.0.4 and noticed that some of our servlets/filters are not working anymore. Digging into the servlet registration process, I found that in the new aries-jaxrs-whiteboard, a cxf-servlet is registered with url pattern /* which makes this servlet handles any request that does not match the registered urlPattern without giving it a chance to match to filter pattern. Is this a bug or i need to add some configuration to prevent this cxf-servlet to handle unmatched request?
Attached is the screenshot showing the cxf-servlet being registered with /* pattern.

Thai Le


--
Castor Technologies Inc
460 rue St-Catherine St Ouest, Suite 613 
Montréal, Québec H3B-1A7
(514) 360-7208 o
(514) 798-2044 f

CONFIDENTIALITY NOTICE: The information contained in this e-mail is confidential and may be proprietary information intended only for the use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any viewing, dissemination, distribution, disclosure, copy or use of the information contained in this e-mail message is strictly prohibited. If you have received and/or are viewing this e-mail in error, please immediately notify the sender by reply e-mail, and delete it from your system without reading, forwarding, copying or saving in any manner. Thank you.
AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est confidentiel, peut être protégé par le secret professionnel et est réservé à l'usage exclusif du destinataire. Toute autre personne est par les présentes avisée qu'il lui est strictement interdit de diffuser, distribuer ou reproduire ce message. Si vous avez reçu cette communication par erreur, veuillez la détruire immédiatement et en aviser l'expéditeur. Merci.

aries-jaxrs-whiteboard101vs104.PNG (311K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: jaxrs-whiteboard 1.0.4

Carlos Sierra Andrés-3

Hi Thai,

that servlet context helper might belong to the default application, as described here: https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#service.jaxrs.whiteboard

you can check if that is the case if the value of the property "osgi.jaxrs.name" is ".default". In the case of the aries implementation you change its path from the root to a different one. You have two ways of doing so, using configuration or publishing a new application with name ".default" and the desired "osgi.jaxrs.application.base", as stated here: https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#d0e133794.

If you choose to use configuration admin to configure the default whiteboard's default application you can create configuration with pid "org.apache.aries.jax.rs.whiteboard.default" and set the property "default.application.base" to the desired path and/or disable the default web by setting the property "default.web" to false.

I hope this helps.

Carlos.

El 24/4/19 a las 16:46, Nhut Thai Le escribió:
Hi Carlos,

Thank you for your reply. I understand that cxf -servlet should only serve requests that match url patterns of the REST application, but what I am saying is that by upgrading aries-jaxrs-whiteboard to 1.0.4, I see cxf-servlet is registered to handle request for /* which i have no REST application that maps to. Here is the screenshot showing the new aries-jaxrs-whiteboard registers a ServletContextHelper with context.path=/ while the version 1.0.1 registers a ServletContextHelper with context.path="". 

I believe this is a bug in aries-jaxrs-whiteboard instead of paxweb so i opened a ticket https://issues.apache.org/jira/browse/ARIES-1912

If you still think it's paxweb issue, please let me know.

Thai

On Wed, Apr 24, 2019 at 3:00 AM Carlos Sierra Andrés <[hidden email]> wrote:

Hi Thai Le,

to match spec requirements the jaxrs whiteboard registers one ServletContextHelper per JAX-RS application (unless you use aries proprietary extensions to reuse pre existing servlet context helpers) and then deploys CXF servlet in it. The servlet context helper carries the properties from the application service so, if you need to deploy some filters to the applications ServletContextHelper you should be able to do so targeting the servlet context helper with the same osgi.jaxrs.name as your application.

CXF servlet is registered to serve all requests that arrive to the application's path because that path is supposed to belong to the REST application. This does not prevent any javax filters to be executed before the servlet. You should be able to register the filters to specific URL patterns or directly to the CXF servlet. These filters are going to execute before CXF servlet. So the servlet url pattern should not prevent any filters to be executed, if it did it would be a bug in the HTTP Whiteboard implementation.

Would this help?

Carlos.

El 23/4/19 a las 20:48, Nhut Thai Le escribió:

Hello,

We have been using aries-jaxrs-whiteboard to run our REST api along with paxweb-extender-whiteboard for sometimes. Recently we upgraded aries-jaxrs-whiteboard from version 1.0.1 to 1.0.4 and noticed that some of our servlets/filters are not working anymore. Digging into the servlet registration process, I found that in the new aries-jaxrs-whiteboard, a cxf-servlet is registered with url pattern /* which makes this servlet handles any request that does not match the registered urlPattern without giving it a chance to match to filter pattern. Is this a bug or i need to add some configuration to prevent this cxf-servlet to handle unmatched request?
Attached is the screenshot showing the cxf-servlet being registered with /* pattern.

Thai Le


--
Castor Technologies Inc
460 rue St-Catherine St Ouest, Suite 613 
Montréal, Québec H3B-1A7
(514) 360-7208 o
(514) 798-2044 f

CONFIDENTIALITY NOTICE: The information contained in this e-mail is confidential and may be proprietary information intended only for the use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any viewing, dissemination, distribution, disclosure, copy or use of the information contained in this e-mail message is strictly prohibited. If you have received and/or are viewing this e-mail in error, please immediately notify the sender by reply e-mail, and delete it from your system without reading, forwarding, copying or saving in any manner. Thank you.
AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est confidentiel, peut être protégé par le secret professionnel et est réservé à l'usage exclusif du destinataire. Toute autre personne est par les présentes avisée qu'il lui est strictement interdit de diffuser, distribuer ou reproduire ce message. Si vous avez reçu cette communication par erreur, veuillez la détruire immédiatement et en aviser l'expéditeur. Merci.
Reply | Threaded
Open this post in threaded view
|

Re: jaxrs-whiteboard 1.0.4

Nhut Thai Le
Thanks Carlos, 

I'll try this out.

Thai

On Wed, Apr 24, 2019 at 12:47 PM Carlos Sierra Andrés <[hidden email]> wrote:

Hi Thai,

that servlet context helper might belong to the default application, as described here: https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#service.jaxrs.whiteboard

you can check if that is the case if the value of the property "osgi.jaxrs.name" is ".default". In the case of the aries implementation you change its path from the root to a different one. You have two ways of doing so, using configuration or publishing a new application with name ".default" and the desired "osgi.jaxrs.application.base", as stated here: https://osgi.org/specification/osgi.cmpn/7.0.0/service.jaxrs.html#d0e133794.

If you choose to use configuration admin to configure the default whiteboard's default application you can create configuration with pid "org.apache.aries.jax.rs.whiteboard.default" and set the property "default.application.base" to the desired path and/or disable the default web by setting the property "default.web" to false.

I hope this helps.

Carlos.

El 24/4/19 a las 16:46, Nhut Thai Le escribió:
Hi Carlos,

Thank you for your reply. I understand that cxf -servlet should only serve requests that match url patterns of the REST application, but what I am saying is that by upgrading aries-jaxrs-whiteboard to 1.0.4, I see cxf-servlet is registered to handle request for /* which i have no REST application that maps to. Here is the screenshot showing the new aries-jaxrs-whiteboard registers a ServletContextHelper with context.path=/ while the version 1.0.1 registers a ServletContextHelper with context.path="". 

I believe this is a bug in aries-jaxrs-whiteboard instead of paxweb so i opened a ticket https://issues.apache.org/jira/browse/ARIES-1912

If you still think it's paxweb issue, please let me know.

Thai

On Wed, Apr 24, 2019 at 3:00 AM Carlos Sierra Andrés <[hidden email]> wrote:

Hi Thai Le,

to match spec requirements the jaxrs whiteboard registers one ServletContextHelper per JAX-RS application (unless you use aries proprietary extensions to reuse pre existing servlet context helpers) and then deploys CXF servlet in it. The servlet context helper carries the properties from the application service so, if you need to deploy some filters to the applications ServletContextHelper you should be able to do so targeting the servlet context helper with the same osgi.jaxrs.name as your application.

CXF servlet is registered to serve all requests that arrive to the application's path because that path is supposed to belong to the REST application. This does not prevent any javax filters to be executed before the servlet. You should be able to register the filters to specific URL patterns or directly to the CXF servlet. These filters are going to execute before CXF servlet. So the servlet url pattern should not prevent any filters to be executed, if it did it would be a bug in the HTTP Whiteboard implementation.

Would this help?

Carlos.

El 23/4/19 a las 20:48, Nhut Thai Le escribió:

Hello,

We have been using aries-jaxrs-whiteboard to run our REST api along with paxweb-extender-whiteboard for sometimes. Recently we upgraded aries-jaxrs-whiteboard from version 1.0.1 to 1.0.4 and noticed that some of our servlets/filters are not working anymore. Digging into the servlet registration process, I found that in the new aries-jaxrs-whiteboard, a cxf-servlet is registered with url pattern /* which makes this servlet handles any request that does not match the registered urlPattern without giving it a chance to match to filter pattern. Is this a bug or i need to add some configuration to prevent this cxf-servlet to handle unmatched request?
Attached is the screenshot showing the cxf-servlet being registered with /* pattern.

Thai Le


--
Castor Technologies Inc
460 rue St-Catherine St Ouest, Suite 613 
Montréal, Québec H3B-1A7
(514) 360-7208 o
(514) 798-2044 f

CONFIDENTIALITY NOTICE: The information contained in this e-mail is confidential and may be proprietary information intended only for the use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any viewing, dissemination, distribution, disclosure, copy or use of the information contained in this e-mail message is strictly prohibited. If you have received and/or are viewing this e-mail in error, please immediately notify the sender by reply e-mail, and delete it from your system without reading, forwarding, copying or saving in any manner. Thank you.
AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est confidentiel, peut être protégé par le secret professionnel et est réservé à l'usage exclusif du destinataire. Toute autre personne est par les présentes avisée qu'il lui est strictement interdit de diffuser, distribuer ou reproduire ce message. Si vous avez reçu cette communication par erreur, veuillez la détruire immédiatement et en aviser l'expéditeur. Merci.


--
Castor Technologies Inc
460 rue St-Catherine St Ouest, Suite 613 
Montréal, Québec H3B-1A7
(514) 360-7208 o
(514) 798-2044 f

CONFIDENTIALITY NOTICE: The information contained in this e-mail is confidential and may be proprietary information intended only for the use of the individual or entity to whom it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any viewing, dissemination, distribution, disclosure, copy or use of the information contained in this e-mail message is strictly prohibited. If you have received and/or are viewing this e-mail in error, please immediately notify the sender by reply e-mail, and delete it from your system without reading, forwarding, copying or saving in any manner. Thank you.
AVIS DE CONFIDENTIALITE: L’information contenue dans ce message est confidentiel, peut être protégé par le secret professionnel et est réservé à l'usage exclusif du destinataire. Toute autre personne est par les présentes avisée qu'il lui est strictement interdit de diffuser, distribuer ou reproduire ce message. Si vous avez reçu cette communication par erreur, veuillez la détruire immédiatement et en aviser l'expéditeur. Merci.