On 7/26/12 10:15 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?
>> No, I haven't looked into this since your fix. Jeremy could check the
>> current behavior if he has some cycles to look into this..
> Thanks for your reply, I have checked the latest glassfish after shingwai
> revised the issue of GLASSFISH-18866. Although the Webcontainer has an
> exception for duplicateContextRoot, I still have some questions about
> GLASSFISH-18866 while setting the context root of test_sample2 to be
> /test_sample1.
> (1).Both of the applications can't be accessed because of the context root
> conflicted.
> (2).test_sample2 can't be undeployed until you redeploy this application.
> (3).The context root of test_sample1 is same with test_sample2.
For issue 18866, I have checkout the latest workspace and try to the
following command:
asadmin deploy --contextroot test_sample1 test_sample1.war
asadmin deploy --contextroot test_sample1 test_sample2.war
I saw the following when deploying the second one:
remote failure: Error occurred during deployment: Exception while
loading the app : java.lang.Exception: WEB0113: Virtual server [server]
already has a web module [test_sample1] loaded at [/test_sample1];
therefore web module [test_sample2] cannot be loaded at this context
path on this virtual server. . Please see server.log for more details.
Command deploy failed.
The second war is not deployed in DAS case. I confirmed this as follows:
asadmin list-components
test_sample1 <web>
Command list-components executed successfully.
And I can access
http://localhost:8080/test_sample1 and get the result
for the test_sample1.war
For 18861, it is a different issue. It is about "setting" the same
context root for two different wars.
And I have already pointed out the issue in the jira.
Shing Wai Chan
>
> [My opinion]
> (1).I think the operation about setting the context root of test_sample2 to
> be /test_sample1 can't be successfully. Because after the operation, the
> test_sample1 can't be accessed and user must redeploy test_sapmle1 if he
> want to access the test_sample1.
> (2).After setting the context root of test_sample2 to be /test_sample1, I
> think it's not friendly to redeploy the test_sample2 if you want to undeploy
> Test_sample2.
>
> Above all, I think the issue of 18861 is still exists.
>
> --Best Regards
> --Jeremy Lv
>
>