So I'm left trying to understand whether it is Liferay that is modifying URLs or the way Errai behaves when hosted as a portlet?
When Errai is deployed in a non-portlet based env everything works .. does that mean that all paths it uses include the context of the app .. e.g. /stockdemo/in.1234-5678.erraiBus and when deployed in a portlet it serves up paths without the context (i.e. the root context) e.g. /in.1234-5678.erraiBus
.. or does it mean that Liferay is manipulating the URLs?
David Grigglestone wrote:
So I'm left trying to understand whether it is Liferay that is modifying URLs or the way Errai behaves when hosted as a portlet?
When Errai is deployed in a non-portlet based env everything works .. does that mean that all paths it uses include the context of the app .. e.g. /stockdemo/in.1234-5678.erraiBus and when deployed in a portlet it serves up paths without the context (i.e. the root context) e.g. /in.1234-5678.erraiBus
.. or does it mean that Liferay is manipulating the URLs?
That's a very interesting question. If Liferay is somehow manipulating the URLs being sent to the clients, or Liferay (or JSR-168 portlet containers in general) have a way of tricking separately deployed webapps that their context path is just "/" then that would explain the problems you've run up against.
Unfortunately, I don't know enough about portlets to answer that one off the top of my head. But fortunately, I heard back yesterday on my query as to where the portlet specification went. They've fixed the download link at http://download.oracle.com/otndocs/jcp/PORTLET_1.0-FR-SPEC-G-F/
I've got my copy now. I'll read through it and see if I can find anything that would hurt the workings of Errai.
-Jonathan