[
https://issues.apache.org/jira/browse/KNOX-670?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15142070#comment-15142070
]
Kevin Minder edited comment on KNOX-670 at 2/11/16 3:01 PM:
------------------------------------------------------------
For the next phase I'm considering allowing the mixing of <service> and
<application> within a single topology as suggested by [~lmccay].
I originally restricted this because I was trying to solve the "single
application topology" problem that arose with admin and knoxsso.
I was also trying to avoid potential confusion between applications and
services binding to the same paths.
In addition, I want to ensure that an application could easily be made
accessible at the root context of a topology.
To illustrate, it should be possible to access to an application
(conf/applications/sample.war) at the root of topology file (e.g.
conf/topologies/sandbox.xml) as https://localhost:8443/gateway/sandbox.
To support all of these use cases I'm considering adding a <context> (or
possibly <url> or <path>) to <application> in the next iteration.
The example below shows how an conf/topologies/sandbox.xml topology file might
look:
{code:xml}
<topology>
<application>
<name>sample</name>
<context>example</context>
</application>
</topology>
{code}
If this were topology file conf/topologies/sandbox.xml then this will result in
the application conf/applications/sample.war being available at
https://localhost:8443/gateway/sandbox/example.
This could also be specified using a leading / as <context>/example</context>
with the same result.
In addition, specifying a blank or / for <context> could make the application
available at the of the topology.
This would result in the application being avialable at
https://localhost:8443/gateway/sandbox as shown below.
{code:xml}
<topology>
<application>
<name>sample</name>
<context>/</context>
</application>
</topology>
{code}
This will result in the conf/applications/sample.war being available at
https://localhost:8443/gateway/sandbox
There will need to be validation done to ensure that no two <context> settings
within a given topology have the same value.
In addition, I do not believe that a blank or / context should be allowed in a
topology that also contains services as this may cause unexpected path binding
results.
It may even be required to force topologies with a root application to contain
only that single application and no services.
Unfortunatly the serlvet container's path matching rules are first match not
best match based.
A more complex topology conf/topologies/sandbox.xml might look like this:
{code:xml}
<topology>
<gateway>
<!-- Shiro authentication provider configuration -->
</gateway>
<application>
<name>idp</name> <!-- conf/applications/idp.war (Shibboleth)-->
<context>/sso</context> <!-- https://localhost:8443/gateway/sandbox/sso
-->
</application>
<application>
<name>knoxlogin</name> <!-- conf/applications/knoxlogin (i.e.
directory) -->
<context>/login</context> <!--
https://localhost:8443/gateway/sandbox/login -->
</application>
<application>
<name>testpage</name> <!-- conf/applications/testpage.war -->
<!-- https://localhost:8443/gateway/sandbox/testpage -->
</application>
<service>
<role>WEBHDFS</role>
<url>...</url>
</service>
</topology>
{code}
Note that if <context> is not present, as with the testpage example above, then
the context defaults to name.
I have also given consideration to making <name> optional in which case it will
default to the name of the topology making simply <application/> possible.
If this existed in conf/topologies/sample.xml it would effectivly represent
what is shown below and make conf/applications/sample.war accessible at
https://localhost:8443/gateway/sample
{code:xml}
<application>
<name>sample</name>
<context>/</context>
</application>
{code}
was (Author: kminder):
For the next phase I'm considering allowing the mixing of <service> and
<application> within a topology as requested by [~lmccay]. I originally
restricted this because I was trying to solve the "single application topology"
and avoid potential confusion between applications and services trying to bind
to the same paths. I particular I want to ensure that a testapp.war
application can easily be made accessible from a topology file
conf/topologies/sample.xml at https://localhost:8443/gateway/sample without any
confusion. For the next phase I'm considering adding a <context> to
<application>.
{code}
<topology>
<application>
<name>testapp</name>
<context>example</context>
</application>
</topology>
{code}
This will result in the sample.war being available at
https://localhost:8443/gateway/sample/example. This could also be specified as
<context>/example</context>. However specifying a blank or / context will make
the application available at the root.
{code:xml}
<topology>
<application>
<name>testapp</name>
<context>/</context>
</application>
</topology>
{code}
This will result in the sample.war being available at
https://localhost:8443/gateway/sample
There will of course need to be validation done to ensure that no two <context>
settings within a given topology have the same value. In addition I do not
believe that a blank or root context should be allowed in a topology with mixed
services and applications.
So a more complex topology conf/topologies/sandbox.xml might now look like this:
{code:xml}
<topology>
<gateway>
...
</gateway>
<application>
<name>idp</name> <!-- conf/applications/idp.war (Shibboleth)-->
<context>/sso</context> <!-- https://localhost:8443/gateway/sandbox/sso
-->
</application>
<application>
<name>knoxlogin</name> <!-- conf/applications/knoxlogin.war -->
<context>/login</context> <!--
https://localhost:8443/gateway/sandbox/login -->
</application>
<application>
<name>testpage</name> <!-- conf/applications/testpage.war -->
<!-- https://localhost:8443/gateway/sandbox/testpage -->
</application>
<service>
<role>WEBHDFS</role>
<url>...</url>
</service>
</topology>
{code}
Note that if <context> is not present as with the testpage example then the
context defaults to name.
> Knox Should be able to Host Simple Web Apps
> -------------------------------------------
>
> Key: KNOX-670
> URL: https://issues.apache.org/jira/browse/KNOX-670
> Project: Apache Knox
> Issue Type: Bug
> Components: Server
> Reporter: Larry McCay
> Assignee: Kevin Minder
> Fix For: 0.9.0
>
> Attachments: KNOX-670_001.patch, KNOX-670_002.patch
>
>
> I think that we need the ability to serve up arbitrary web app resources.
> Given a conf/applications along side conf/topologies, we should be able to
> spin up a simple application that can be used as a central login facility
> with KnoxSSO, a management UI or any number of simple applications.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
