Ask Questions and Find Answers
Important:
Ask is now read-only. You can review any existing questions and answers, but not add anything new.
But - don't panic! While ask is no more, we've replaced it with discuss - the new Liferay Discussion Forum! Read more here here or just visit the site here:
discuss.liferay.com
RE: Accessing Liferay Servlet On /pattern rather /o/pattern
Hi all,
I am re-engineering a servlet application to run as a series of DXP modules. One of the contraints is that the original servlet runs on /proxy pattern, i've implemented a dxp component class on the same pattern following this knowledgebase article (https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-1/servlets-in-a-module).
When i access localhost/o/proxy/v1/query/search i successfully access my servlet. My intention is to access this servlet on the pattern /proxy/v1/query/search. Is this possible to achieve within liferay or should i look to deploy a traditional servlet directly to tomcat ?
My component annotation is below:
@Component(
property = {
"osgi.http.whiteboard.context.path=/",
"osgi.http.whiteboard.servlet.pattern=/proxy/v1/query/search"
},
service = Servlet.class
)
Please let me know if there are any questions or if i can provide more information.
Regards,
John
I am re-engineering a servlet application to run as a series of DXP modules. One of the contraints is that the original servlet runs on /proxy pattern, i've implemented a dxp component class on the same pattern following this knowledgebase article (https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-1/servlets-in-a-module).
When i access localhost/o/proxy/v1/query/search i successfully access my servlet. My intention is to access this servlet on the pattern /proxy/v1/query/search. Is this possible to achieve within liferay or should i look to deploy a traditional servlet directly to tomcat ?
My component annotation is below:
@Component(
property = {
"osgi.http.whiteboard.context.path=/",
"osgi.http.whiteboard.servlet.pattern=/proxy/v1/query/search"
},
service = Servlet.class
)
Please let me know if there are any questions or if i can provide more information.
Regards,
John
John O'FlahertyHi all,OSGi components are resolved by the OSGi runtime - and as I understand, it doesn't handle arbitrary URLs, but those starting with /o/, thus you're stuck with this access pattern.
I am re-engineering a servlet application to run as a series of DXP modules. One of the contraints is that the original servlet runs on /proxy pattern, i've implemented a dxp component class on the same pattern following this knowledgebase article (https://dev.liferay.com/develop/tutorials/-/knowledge_base/7-1/servlets-in-a-module).
When i access localhost/o/proxy/v1/query/search i successfully access my servlet. My intention is to access this servlet on the pattern /proxy/v1/query/search. Is this possible to achieve within liferay or should i look to deploy a traditional servlet directly to tomcat ?
You might need to be able to work around this contraint with a reverse proxy or some URL rewriting, but honestly, I'd just change the path in the servlet. Configurable URLs or context paths aren't the worst in servlets. And as you configure the "servlet context" anyway, you might as well configure it as /o/pattern instead of /pattern.
There might be other ways around this, but allowing this blindly would quickly ambiguate the purpose of those URLs: E.g. you couldn't create a servlet under the paths /web/ or /group/ in Liferay, as those names are already taken. The same with arbitrary pagenames: example.com/web/guest/pattern will also be found as example.com/pattern. And there we are back at the reason why there's a reserved namespace.
Hi Olaf,
A third party js authentication library was looking for a particular folder structure which was the root of my problem. Following your update I removed this obstacle and was no longer contrained by this requirement. Thank you very much indeed as your update was very helpful and got me on the right track.
Thank you again,
Regards,
John
A third party js authentication library was looking for a particular folder structure which was the root of my problem. Following your update I removed this obstacle and was no longer contrained by this requirement. Thank you very much indeed as your update was very helpful and got me on the right track.
Thank you again,
Regards,
John
Copyright © 2025 Liferay, Inc
• Privacy Policy
Powered by Liferay™