Hi, Hong:
There’s one more tip I want to mention, I think we should define the property “EE” instead of “doCluster” for the target "depl-order" in the ear/earwithall2/build.xml. It will make the changes more simplistic. Please consider about this patch.
Thanks
Jeremy Lv
From: lvsongping [mailto:lvsongping_at_cn.fujitsu.com]
Sent: Wednesday, December 18, 2013 11:15 AM
To: dev_at_glassfish.java.net
Subject: RE: Fwd: [Review Request][Deployment tests] About GLASSFISH-20894
Hi, Hong:
Ok, you are right. I haven’t noticed that property before. That would be great. Here’s attached the new patch.
Thanks
Jeremy Lv
From: Hong Zhang [mailto:hong.hz.zhang_at_oracle.com]
Sent: Wednesday, December 18, 2013 11:00 AM
To: dev_at_glassfish.java.net
Subject: Re: Fwd: [Review Request][Deployment tests] About GLASSFISH-20894
Hi, Jeremy
I see. We already have a property "doInstance" defined in common.xml (right before property "doCluster" is defined). Can we just use that in the deploy-order tests?
Thanks,
- Hong
12/17/2013 9:37 PM, lvsongping wrote:
Hi, Hong:
The property of "runTag" is used to judge whether we need to execute deploy-order when run the deployment tests on EE w/ remote instance. I have changed the name to “doServer” and reattached the new patch again as the previous property name is not obviously.
BTW, I have just ran all of the tests on my local platform and passed as expected:
1). FOR RUNNING THE DEPLOYMENT TESTS ON EE w/ DAS : PASSED
2). FOR RUNNING THE DEPLOYMENT TESTS ON EE w/ remote instance: PASSED
3). FOR RUNNING THE DEPLOYMENT TESTS ON EE w/ cluster and remote instance : PASSED
Thanks
Jeremy Lv
From: Hong Zhang [mailto:hong.hz.zhang_at_oracle.com]
Sent: Wednesday, December 18, 2013 12:14 AM
To: dev_at_glassfish.java.net
Subject: Re: Fwd: [Review Request][Deployment tests] About GLASSFISH-20894
Hi, Jeremy
Thanks for submitting the patch for this! The changes look mostly fine to me, but I am not sure what the purpose of the property "runTag" is. Can you explain what it does?
Thanks,
- Hong
On 12/17/2013 5:21 AM, lvsongping wrote:
Hi, Hong:
Thanks for your patient reply. I have reattached a new patch to fix the failure to the situation for running the deployment tests on EE w/ remote instance. Now it won’t delete the default domain(domain1), you will still locate the glassfish-acc.xml to the default domain1.
Thanks
Regards
Jeremy Lv
From: Hong Zhang [ <mailto:hong.hz.zhang_at_oracle.com> mailto:hong.hz.zhang_at_oracle.com]
Sent: Tuesday, December 17, 2013 10:42 AM
To: <mailto:dev_at_glassfish.java.net> dev_at_glassfish.java.net
Subject: Re: Fwd: [Review Request][Deployment tests] About GLASSFISH-20894
Hi, Jeremy
Thanks for looking further into this. Please see my comments in line:
From: "lvsongping" <lvsongping_at_cn.fujitsu.com>
Date: December 16, 2013, 3:26:24 AM EST
To: <dev_at_glassfish.java.net>
Subject: RE: [Review Request][Deployment tests] About GLASSFISH-20894
Reply-To: dev_at_glassfish.java.net
Hi, Hong:
Sorry to reply this email later, I just back to my office today so I haven’t notice the mail you reply me last week.
This might be the remote instance particular tests, if you tried to run the hadson job as the following steps, I think the tests will be failed:
export DEPL_TARGET=SERVER
bash -x appserv-tests/devtests/deployment/hudson.sh
if you set the DEPL_TARGET=CLUSTER. All of the tests cases will be passed as expected
Is that necessary to fix the failure when it is test the remote instance(export DEPL_TARGET=SERVER)? If we can ignore the tests for the remote instance, I think it is fine to remain the original test suite.
It's not critical if the CLUSTER target can be run successfully. However it will be nice to get it work also if you have time to look at it after you finish your more important work.
But there’s another issue I want to mention, if we don’t use the default domain1, why we still use the file in the default domain(domain1)? I think we should locate the glassfish-acc.xml when run the tests in different domains.
It's probably to simplify the build set up so more code sharing can happen between different running modes. The glassfish-acc.xml file will be the exact same here as both domains are created from the same server installation.
Thanks,
- Hong
From: Hong Zhang [ <mailto:hong.hz.zhang_at_oracle.com> mailto:hong.hz.zhang_at_oracle.com]
Sent: Wednesday, December 11, 2013 9:56 AM
To: <mailto:dev_at_glassfish.java.net> dev_at_glassfish.java.net
Subject: Re: [Review Request][Deployment tests] About GLASSFISH-20894
Hi, Jeremy
Please see my comments in line:
On 12/10/2013 8:02 PM, lvsongping wrote:
Hi, Hong:
That’s strange. If you trying to run the EE devtests as the steps written in the appserv-test/devtests/deployment/README.EE, some tests will be failed. The detailed steps will be as follows:
[FOR RUNNING THE DEPLOYMENT TESTS ON EE w/ remote instance:]
1. Checkout the deployment test suite to the local disk.
2. Set(export) DEPL_TARGET=SERVER
3. Ant all-ee
[FOR RUNNING THE DEPLOYMENT TESTS ON EE w/ cluster and remote instance :]
1. Checkout the deployment test suite to the local disk.
2. Set(export) DEPL_TARGET=CLUSTER
3. Ant all-ee
I have ran the test suite on the windows ,Ubuntu and mac os, the process will be suspend during the process of running the devtest suite. I found it is because the following code segment caused the issue:
<target name="restart.server">
<echo message="Restarting server..."/>
<exec executable="${ASADMIN}" failonerror="true">
<arg line="stop-domain"/>
</exec>
<antcall target="start-process">
<param name="line" value="start-domain --user ${admin.user} --passwordfile ${passwordFile}"/>
</antcall>
</target>
It will restart the domain during the process of running the devtests, when we ran the ee tests it will create another domain called depltest-domain, so there will be two domain at the same directory at the same time, so it will be suspended here during the process of running the test suite.
I see. The above target was added in v4 for testing the deployment order feature which should probably only be run for PE mode. You can try to add a condition to this target to make it only run in PE mode to see if it helps. In EE mode, we should only have one domain running depltest-domain.
So I tried to remove the default domain called domain1 when running the ee tests, it is failed in some appclient tests as it can’t find out the glassfish-acc.xml as I have already deleted the default domain at the first time, so I need relocate the position of the glassfish-acc.xml when running the ee tests instead use the default glassfish-acc.xml which located in the default domain.
IMHO, if we use the other domain, why we still use the file in the default domain(domain1)? This is the reason why I relocate the glassfish-acc.xml when run the tests in different domains.
I will trying to run the Hudson on my local platform to check whether all of the tests can be passed on my platform.
Thanks. I am curious on why the hudson tests would still pass..
- Hong
Thanks a lot!
Jeremy Lv
From: Hong Zhang [ <mailto:hong.hz.zhang_at_oracle.com> mailto:hong.hz.zhang_at_oracle.com]
Sent: Tuesday, December 10, 2013 10:16 PM
To: lvsongping
Cc: <mailto:dev_at_glassfish.java.net> dev_at_glassfish.java.net
Subject: Re: [Review Request][Deployment tests] About GLASSFISH-20894
Hi, Jeremy
Thanks for looking into this. I did not realize you meant running EE tests as it is would fail today. I thought you meant it would fail with your changes trying to mavenize it. We have a hudson job (unfortunately it's an internal hudson job so you will not be able to view it) for running deployment dev tests in cluster mode, and the job status shows success for the recent builds (the latest run was on yesterday).
I copied the command line that executes this hudson job and you can simulate it to compare with the difference of your local run:
wget --no-check-certificate -O appserv-tests/config.properties
http://java.net/projects/glassfish/sources/svn/content/trunk/v2/appserv-tests/config.properties
DEPL_TARGET=CLUSTER
export DEPL_TARGET
bash -x appserv-tests/devtests/deployment/hudson.sh
One difference I can think of is the hudson job always start from scratch, checking out a new appserv-tests workspace and run from there. And it might do some cleaning after the run. So some of the changes you submitted (to clean before run) might be good changes to add, but I am not sure if your other changes (especially client related) are needed such as providing the glassfish-acc.xml explicitly, I think that should be the default when none is specified. Make sure you have the latest changes for the top level appserv-tests config files such as appserv-tests/config, I think the files there already sets the glassfish-acc.xml as default.
Thanks,
- Hong
On 12/10/2013 12:56 AM, lvsongping wrote:
Hi, Hong:
Cc: dev list:
As we have talked before we should fix deployment devtest suite so that both the pe related devtest and ee related devtest can be passed before mavenize all of the useful devtest suite. Now I have fixed devtest suite related to the deployment component and all of the tests can be passed after applying the patches I have attached, please help me to review my patch whether it is fine for me to check in.
The related issue I have created in the jira is <
https://java.net/jira/browse/GLASSFISH-20894>
https://java.net/jira/browse/GLASSFISH-20894 .
Best Regards
Jeremy Lv
--------------------------------------------------
Lv Songping
Software Division II
Development Department I
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
ADDR.: No.6 Wenzhu Road, Software Avenue,
Nanjing, 210012, China
TEL : +86+25-86630566-9327
COINS: 7998-9327
FAX : +86+25-83317685
MAIL : <mailto:lvsongping_at_cn.fujitsu.com> lvsongping_at_cn.fujitsu.com
BLOG : <
https://www.java.net/author/jeremy-lv>
https://www.java.net//author/jeremy-lv