I am planning to build a collection of applications as individual components.
How can I promote one of these components to take the ownership of the ROOT
mount point ("/")? The options I see are:
copy all subscreen defnitions of the ROOT component into webroot.xml
Host the "ROOT" component on a different host / port.
Both these approaches are not ideal Does there exist a 3rd approach, where we
can just configure one component to take the ownership of the ROOT mount
point? Rest of the applications including tools would be accessed normally,
because their url namespaces are anyway different (/apps/).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The root screen location is configured in the moqui-conf XML file. You can
have multiple roots for different host names and such. Here is the
configuration of the moqui.org site (and other sites I host on the same
server):
<webapp-list><webappname="webroot"https-enabled="false"><root-screenhost=".*moqui.org"location="component://mysites/screen/moqui.org.xml"/><root-screenhost=".*hemagenesis.com"location="component://mysites/screen/hemagenesis.com.xml"/><root-screenhost=".*dejc.com"location="component://mysites/screen/dejc.com.xml"/><!-- the default... --><root-screenhost=".*"location="component://mysites/screen/moqui.org.xml"/></webapp></webapp-list>
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The rationale behind this need is - I have a set of applications, each of
which are modeled as moqui components. One of these components is a customer
facing website, where URL simplicity, SEO etc., dictate that the component
name should not be included in the url. To achieve this, we need to point
the rootscreen of webroot to customer-facing-website component location.
However, if we do this, we lose the original webroot configuration due to
which, apps/tools will have to be configured again. Also, there will be
problems with resource (css, js) locations for apps/tools.
I am wondering if I am not looking at the problem in the right perspective
(moqui-wise)! It would be great if it can be confirmed that this kind of
configuration is indeed possible in the current version. Then, I can dig into
the configurations in more detail to figure out the correct configuration.
But, if it becomes clear that this is not possible, then I will figure out a
different way of laying out the components.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Basically, if you want to control the root of the application you'll need to
create your own root screen and resources under it, or modify the default one
that comes with the sample Moqui runtime directory.
BTW, the runtime directory is not really considered part of the framework, it
is outside the war file in the binary distribution and is meant to be
modified, or thrown out with something else totally custom substituted. It can
be added to the war file for easy deployment, but isn't really part of the
framework.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thank you for clarifying the approach. It makes sense.
But, one little thing that is still burried in the binary distribution is
web.xml. Due to this, the webapp should always be named as "webroot" unless,
we want to rebuild moqui from source after editing web.xml.
Were there any use cases you had in mind where you had multiple <webroot>_s
under <webapp-list>. I am not able to visualize, how we can enable more than
one webapp in a single instance of moqui, because web.xml allows for only one
value for _moqui-name context parameter.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As for the multiple webapp elements under webapp-list, that is to support
multiple Java Servlet webapps or WAR files pointing to the same runtime
directory. With the Java Servlet API and architecture, I don't think there is
any other way you can do it... that's a servet and web thing, not a Moqui
thing.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am planning to build a collection of applications as individual components.
How can I promote one of these components to take the ownership of the ROOT
mount point ("/")? The options I see are:
Both these approaches are not ideal Does there exist a 3rd approach, where we
can just configure one component to take the ownership of the ROOT mount
point? Rest of the applications including tools would be accessed normally,
because their url namespaces are anyway different (/apps/).
The root screen location is configured in the moqui-conf XML file. You can
have multiple roots for different host names and such. Here is the
configuration of the moqui.org site (and other sites I host on the same
server):
This part I understand.
But, I am looking at hosting them on the same host, which means, host=".*"
for all the components.
If the host is the same, then the only way I can access the component screens
is by prefixing the component name. For example:
Instead, can we configure component1 to be accessed via urls
The rationale behind this need is - I have a set of applications, each of
which are modeled as moqui components. One of these components is a customer
facing website, where URL simplicity, SEO etc., dictate that the component
name should not be included in the url. To achieve this, we need to point
the rootscreen of webroot to customer-facing-website component location.
However, if we do this, we lose the original webroot configuration due to
which, apps/tools will have to be configured again. Also, there will be
problems with resource (css, js) locations for apps/tools.
I am wondering if I am not looking at the problem in the right perspective
(moqui-wise)! It would be great if it can be confirmed that this kind of
configuration is indeed possible in the current version. Then, I can dig into
the configurations in more detail to figure out the correct configuration.
But, if it becomes clear that this is not possible, then I will figure out a
different way of laying out the components.
Basically, if you want to control the root of the application you'll need to
create your own root screen and resources under it, or modify the default one
that comes with the sample Moqui runtime directory.
BTW, the runtime directory is not really considered part of the framework, it
is outside the war file in the binary distribution and is meant to be
modified, or thrown out with something else totally custom substituted. It can
be added to the war file for easy deployment, but isn't really part of the
framework.
Thank you for clarifying the approach. It makes sense.
But, one little thing that is still burried in the binary distribution is
web.xml. Due to this, the webapp should always be named as "webroot" unless,
we want to rebuild moqui from source after editing web.xml.
Were there any use cases you had in mind where you had multiple <webroot>_s
under <webapp-list>. I am not able to visualize, how we can enable more than
one webapp in a single instance of moqui, because web.xml allows for only one
value for _moqui-name context parameter.
What you write is correct.
How else could it possibly work, BTW?
As for the multiple webapp elements under webapp-list, that is to support
multiple Java Servlet webapps or WAR files pointing to the same runtime
directory. With the Java Servlet API and architecture, I don't think there is
any other way you can do it... that's a servet and web thing, not a Moqui
thing.