Dear Shing wai chan:
Cc:Hong Zhang:
Thanks for your suggestions. I have some questions about it:
> Probably once Shingwai checks in fix for 18866, this issue will be
> mostly fixed too.
1. Today I have found Shingwai has fixed the issue 18866, but I think
there's also some other issues haven't been fixed.
What Shingwai has fixed is only related to the applications deployed on the
server. It doesn't work when applications deployed on the cluster. For
example:
(1) Create a cluster and instance called cluster001 and instance001.
(2) Start the cluster001.
(3) Deploy test_sample1 on the cluster001 and the context root value is
test_sample1.
(4) Deploy test_sample2 on the cluster001 and the context root value is
test_sample1 too.
(5) The test_sample2 can be deployed successfully with the warming messages
suggest the user the context root is duplicated.
About the above operation, I don't think it's a good idea to permit the
application deployed successfully on the same cluster with some warming
messages. I think these applications with same context root shouldn't be
deployed on the same cluster and should tell the user error message just as
the applications deployed on the server.
> 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.
2. The issue GLASSFISH-18861 hasn't fixed yet.
Thanks for your suggestions. The basic logical about this issue is as
follows:
a. When we update the context root through GUI or command, the set method in
SetCommand will be executed first.
b. Then the HK2 module will update the context root value in domain.xml.
c. After the context root value in domain.xml has been updated, there's no
rollback operations about the same context root value in domain.xml but
output the error messages in server.log so that the context root is
duplicated.
Above all, the first idea come to my mind is that I should prevent the
update operation about the domain.xml in SetCommand. But it's not a good
idea because I have something specific(the context root).
I think we should create a rollback method if the context root in domain.xml
is duplicated.
--Best Regards
--Jeremy Lv
-----Original Message-----
From: Shing Wai Chan [mailto:shing.wai.chan_at_oracle.com]
Sent: Tuesday, July 24, 2012 1:08 AM
To: dev_at_glassfish.java.net
Cc: Hong Zhang
Subject: Re: About GLASSFISH-18861
On 7/23/12 8:00 AM, Hong Zhang wrote:
> 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.
I will checkin the fix once the svn is opened.
Shing Wai Chan
>
> 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
>>
>>