On 7/25/12 1:17 AM, Lv Songping wrote:
> 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.
I have a discussion with Hong before my checkin.
There is a different between DAS and cluster in deployment side.
There are actually two "internal" phases in deployment: "deploy" and loading
For DAS, "deploy" and loading happens at the same time.
For cluster, "deploy" on DAS and loading on instance.
In this particular case, the failure is from loading.
In our current implementation, he deployment will not fail when the
loading is failed in a cluster.
This explains why the scenario.
Hong, any further comments?
Shing Wai Chan
>
>> 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
>>>
>>>
>
>