On 7/25/12 7:41 PM, Lv Songping wrote:
> Dear Shingwai, 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?
>> Yes, this was following the same model we used since v2 and earlier
>> releases, we only roll back deployment on DAS and don't roll back failed
>> loading on instances for various reasons. The user will be given a
>> warning message to tell them the application will not run properly in
>> instance in this case and they should fix their applications and then
>> redeploy.
> Thanks for your advices, I have two confused questions as follows.
> 1. Is that the current deployment issues about GLASSFISH-18866 is no need
> to be revised on the cluster?
> 2. The issue trac about GLASSFISH-18861 hasn't been resolved yet, I wonder
> to know whether the web team will investigate it and resolve it. If you are
> not convenient to investigate this issue, I'll investigate it instead.
The behavior for 18861 has been changed after my fix for 18866.
I have just updated the info in this bug.
WebContainer does throw exception in this case.
Hong,
Is the failure status propagated correctly?
Shing Wai Chan
>
> --Best Regards
> --Jeremy Lv
> -----Original Message-----
> From: Hong Zhang [mailto:hong.hz.zhang_at_oracle.com]
> Sent: Thursday, July 26, 2012 1:48 AM
> To: dev_at_glassfish.java.net
> Subject: Re: About GLASSFISH-18861
>
>
>
> On 7/25/2012 1:06 PM, Shing Wai Chan wrote:
>> 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?
> Yes, this was following the same model we used since v2 and earlier
> releases, we only roll back deployment on DAS and don't roll back failed
> loading on instances for various reasons. The user will be given a
> warning message to tell them the application will not run properly in
> instance in this case and they should fix their applications and then
> redeploy.
>
> - Hong
>>
>>
>>>> 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
>>>>>
>>>>>
>>>
>