Hi, Jeremy
Thanks for looking into the issue. A few comments:
1. The set command is a generic command and should not contain
anything specific (like context root).
2. Just checking the context root in domain.xml does not guarantee
it to be unique, as the context roots used in the ear application are
not in the domain.xml. And also the context root just needs to be unique
per virtualserver, so applications could use same context root if the
applications are loaded on different virtual servers. I had actually
discussed with Shingwai on whether we should do pre-validation for
context root, Shingwai mentioned it will be tricky to get this part of
check correct, so the current logic is done in web container when the
application is being loaded where all necessary information are available.
Probably once Shingwai checks in fix for 18866, this issue will be
mostly fixed too.
Thanks,
- Hong
On 7/23/2012 4:45 AM, Lv Songping wrote:
> Dear Hong Zhang
> Cc:glassfish admin team,Tom
>
> I have revised the issue(GLASSFISH-18861) about the " After setting
> context root of two wars which deployed on the server target with the same
> value,both of the two wars accessed failed " and reflected the modified
> files into https://github.com/LvSongping/GLASSFISH-18861 and please review
> it and give me some advices.
>
> I think it should be an admin-cli issue related to the set method in
> SetCommand.java, it set the new values into domain.xml file before check the
> situation whether the contextroot is already used by another applications on
> the same target. I have defined two method called isCtxRootexist and
> validateTargetDup to check whether the contextroot is already exists on the
> same target.
>
> The issue url is as follows:
> http://java.net/jira/browse/GLASSFISH-18861
>
> --Best Regards
> --Jeremy Lv
>
>