Craig McClanahan wrote:
> Jan Luehe wrote:
>
In the latter part of this note I have tried to understand
and answer Craig's question, and to clarify why I had previously asked
(actually advised) that we move away from deploy a module, and then make
it the default, to deploy a module as the default; without having to
change any internal non-default representation of context-path within
the archive.
I accept that Jan would like to focus on improving the implementation of
the existing functionality, so I have divided my questions and comments.
Is the configuration of a default-web-module alligned with our ability
to deploy modules/apps to virtual servers/hosts and are there any
incompatabilities betwee the default-web-module facility and the
synchronization system?
I ask these questions because I recall looking at this in the past, and
I seem to recall that we had some questions about allignment with
synchronization and (un)deployment.
>> Hi Ron,
>>
>> Ron Monzillo wrote On 09/06/06 10:00,:
>>
>>> Jan Luehe wrote:
>>>
>>>>
>>>> I never said I've replaced the internal mapping from "/123" to "/". ;-)
>>>>
>>>> When you declare "123" as your default-web-module, the proposed
>>>> change has the
>>>> mapper map any requests that can't be mapped to any of the deployed
>>>> contexts to
>>>> "/123", but it does not "replace" anything.
>>>>
>>>> You can't just switch back and forth between "/" and "/123", which
>>>> you would do
>>>> if you replaced "/123" with "/".
>>>>
>>>> Some internals (such as the per-context jacc policies) rely on the
>>>> context path
>>>> that was used (and visible) during deployment. They expect a context
>>>> path to
>>>> remain in effect until they've received a corresponding undeploy
>>>> event for that
>>>> context path.
>>>>
>>> AYK, jacc doesn't say anything about default web apps, but when a
>>> policy decision is performed, we need to identify the
>>> application/policy context in which the decision is to be being
>>> performed. when someone accesses a default web module by way of an
>>> unmapped context root, then I would prefer that the application
>>> context be that of the default web module (i.e. /) - and that a
>>> default policy be applied, and that the default policy be defined as
>>> part of defining the app as the default web app; but I think you are
>>> pointing out that the policy of the default app is stored such that
>>> it can only be found based on its app specific context identifer.
>>
>>
>>
>> Right, for the particular case where a webapp (deployed at "/123")
>> has been promoted to a default webapp by virtue of being referenced
>> by the virtual server's default-web-module attribute. In this case,
>> the policy
>> decisions to be performed on requests for "/" and "/123" should be
>> identical.
>>
> Is that also true for security manager settings?
>
not sure if you are asking:
1. if the security manager could be in a different on/off state for the
/123 context vs the default context (as we have previously discussed a
multiplexing securitymanager which would be in different states for
different policy context/modules), or
2. if it should be possible to have different policy apply to requests
mapped to the default; vs requests made with the context path of the
default app (e.g. /123).
note that servlet security constraints are checked independent of the
on/off state of the securitymanager (e.g. by interacting directly with
java.secuirty.policy). But, AYK, other access decisions, such as
checking a FileIOPermission would not be made when the securitymanger is
off.
In our deploy then set as default-web-module admin model, to get to the
point where there are not 2 separate sets of policy files (including
aliasing within the files system) would require that the context path
must always be the same independent of the request is specific to the
app, or defaults.
Since the policy is written to the file system at deployment and before
the app is made the default, the policy context id of use to the policy
subsystem would feature the app specific context id (e.g. /123).
ALternatively it could be renamed, aliased, or copied when the app was
made the default.
IMV once an app is made the default, its app specific context is
superfluous and it would be wise to ensure that our system need not
depend on it; that is why I would prefer that it be possible to deploy a
module as the default, thout changing the context-path value
within the war. IOW, the module would not be deployed with an app
specific context path (e.g. /123), and its policy context id, would
be that of the default context path.
Ron
> Craig
>
>>>
>>> would it be possible to explicitly deploy an app as the default,
>>> without changing its status after the fact.
>>
>>
>>
>> Yes, you can do that, by deploying the webapp to "".
>>
>>
>> Jan
>>
>>> A new default could implicitly override an existing default, and a
>>> default app would not have a specific (e.g. "123") context root.
>>>
>>> Ron
>>>
>>>> Assume a default-web-module "123" with a context root of "/123" and
>>>> a resource "/test".
>>>> When receiving a request for "/test", the proposed change will make
>>>> it *appear* to the
>>>> container as if the request had been for "/123/test", so any
>>>> security decisions or other
>>>> kinds of decisions can continue to be based on the "/123" context
>>>> root that was
>>>> "advertised" during the deployment of "123".
>>>>
>>>>
>>>> Jan
>>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: dev-help_at_glassfish.dev.java.net
>