Thank you for your response @sharif
Just want to clear things up that I am trying to customize openmrs-enterprise, version
And I want to remove openmrs as a contextPath. as you mentioned messages.properties files used to contain message constants only. there are no relation of contextPath with messages.properties.
It would be so grateful to help/suggestions
Hi @narukumar ,
did you find any solution removing the openmrs from the url?
/openmrs context path is so engrained into the web app (here for instance), modules, UI frameworks, frontend configs, … etc that the easier way to do this would be through tinkering with a web server to operate a substitution in the URLs.
Easier, but not easy. Surely there’s plenty of resources online as to how to do this kind of stuff with Apache, Nginx… etc.
OpenMRS itself does not offer any mechanism to do this natively, I guess that is the short answer.
Hi @mksd, thanks for the reply. I have managed to hide the context path “/openmrs” following some instructionsusing tomcat. The installation finished successfully but the login page does not appear normally:
I have no idea what the problem is because i’m sure the /openmrs has not been hard coded across the application.
@marafa it could very well be hardcoded in some places, this is why you probably cannot rely on just configuring Tomcat IMO (but I may be wrong).
Or if it isn’t hardcoded, it may have to be configured in multiple places.
What I meant earlier is to have a plain old web server (Apache, Nginx, …) sitting in front of Tomcat and that would translate all requests to become those expected by Tomcat. For example:
- The client would make a request at
- The facade web server would translate this into
- Tomcat may redirect, with the login for instance to
- The facade web server would ensure that this translated back to
/acme/referenceapplication/home.page for the sake of the client.
I am basically suggesting to add a piece of infrastructure to do a search & replace of “
/openmrs” in the URLs.
Not sure if others ever gave this much thoughts? @mksrom @achachiez @ibacher?
Ok i see what you mean now. i will have a try.
I’ve had some success with just renaming the WAR to something else, e.g.
acme.war. Most of the actively maintained modules don’t make hard-coded assumptions about having the context of
/openmrs/, but I do think that it would require a serious reworking of things to ensure everything works with no URL context (i.e. as
Note that @mksd’s solution is quite clever, but you’ll likely still need to expose the
/openmrs/ endpoint through your proxy because while Apache or Nginx can rewrite URLs and certain headers, it’s hard to configure them to properly re-write message bodies so, e.g., the REST and FHIR APIs are likely to still return links to
/openmrs in the JSON or XML body.
To be honest i quit trying at the moment. After installing the apache server and by using url rewriting i manage to get rid of the /openmrs. in other words, if type lets say localhost/login.htm it takes me to localhost/openmrs/login.htm without showing the /openmrs/ but for some reason i’m still having the same outcome as the previous picture and i don’t really understand why since it’s just hiding the /openmrs.
I think one of the problems is that most of the files needed for the application to run are not in the context path /openmrs but rather in the openmrs folder where the modules are.
At the moment my url is in this form : Appname.domain.local/openmrs
As I said before
That’s because of how that kind of proxying works. For instance, if you have a reverse proxy setup to forward
/openmrs/login.htm, then the OpenMRS server still sees the
/openmrs part as the context path, so the server will still return links to resources from the
/openmrs/ context (i.e., the CSS files, JS, etc.). Hence why you get completely unstyled content.
What you’d have to do is have a rule forwarding
/openmrs and a rule exposing
/openmrs so that those resources are loaded properly.
Again, if you just rename the OMRS WAR to
acme.war, and deploy that to your servlet container, than requests to
/acme should generally do the right thing.