...
List NON-SUN Third Party Software Product involved ( eg Oracle RDMS ) : Oracle11g
Hardware Platform: Sun Fire V890
OS and Kernel Version: Solaris : uname -a <br>
Sinus tapptx01 5.10 Generic_118833-03 sun4u spark SUNW,Sun-Fire-V890
Patch Level:
Solaris : showrev -p (collected and will be sent thru' E-mail after receiving the mail from the case/ Service Request owner)
Description of issue: Problems in redeployment of new version of Toplink Essential WAR File.
Frequency of issue occurs: Whenever we try to redeploy new version of Toplink Essential WAR File.
When was the problem first noticed: on 1st June 2008 at 15.55 Local Time.
Recently Changed Variables: OS Kernel Patch upgrade. But the problem was observed even before OS Kernel Patch upgrade.
Copy and paste error messages from server log outputs, if Any :
Error: The attempt to save your application for admission information has failed. Please retry. It it fails a second time, please contact the Help Desk.
Steps to Reproduce Issue:
For domain1 (problem domain):
1). Deploy the test application to root-context / on virtual server test using GUI
2). Redeploy the app using GUI
3). Fails
4). Un-deploy using GUI
5). Deploy app again to root-context / on virtual server test using GUI
6). Works
7). Un-deploy using GUI.
8). Deploy to root-context / without selecting a virtual server using GUI
9). Fails
***************
For dev (newly created domain for the same SJSAS install):-
1). Deploy the test application to root-context / no virtual server selected using GUI
2). Redeploy the app using GUI
3). Pass
4). Un-deploy the app using GUI
5). Deploy app again to root-context / on virtual server selected using GUI
6). Works
7). Un-deploy the app using GUI
8). Deploy to root-context / selecting default "server" virtual server using GUI
9). Pass
Attached the word document with screen-shots explaining about the steps described above.
The result is that it works for the domain that has no virtual servers configured and not for the domain that does have virtual servers.
The only real difference in the domain.xml files for the two domains is the configuration of a virtual server in domain1. Also domain1 makes use of an IP address for the http and iiop listeners, e.g. address="x.x.x.x" instead of address="0.0.0.0" for the dev domain.
{code:xml}
<virtual-server hosts="applyonline-dev "
http-listeners="http-listener-1,http-listener-2" id="applyonline-dev"
log-file="${com.sun.aas.instanceRoot}/logs/server.log" state="on">
<property name="sso-enabled" value="false"/>
<property name="docroot"
value="${com.sun.aas.instanceRoot}/docroot"/>
<property name="accesslog"
value="${com.sun.aas.instanceRoot}/logs/access"/>
</virtual-server>
{code}
{code:xml}
<virtual-server hosts="onlinehelp-dev "
http-listeners="http-listener-1,http-listener-2" id="onlinehelp-dev"
log-file="${com.sun.aas.instanceRoot}/logs/server.log" state="on">
<property name="sso-enabled" value="false"/>
<property name="docroot"
value="${com.sun.aas.instanceRoot}/docroot"/>
<property name="accesslog"
value="${com.sun.aas.instanceRoot}/logs/access"/>
</virtual-server>
{code}
Basically, both of these log files have the logging level set to FINE for the PERSISTENCE and UTILS. The two test cases executed include the following steps:
gls_server.log_2008-06-17_dev - Log file for a newly created domain in the same SJSAS instance.
gls_server.log_2008-06-17_domain1 - Log file for the domain in the instance that is causing the problem.
However, this works fine if I use asadmin CLI:
Initial deploy (contextroot provided):
asadmin deploy --host applyonline-dev --port 4848 --user admin --passwordfile pw.txt --virtualservers applyonline-dev --contextroot / ProgEnrol-war-2.0.3-SNAPSHOT.war
Redeploy:
asadmin deploy --host applyonline-dev --port 4848 --user admin --passwordfile pw.txt --virtualservers applyonline-dev --force=true ProgEnrol-war-2.0.3-SNAPSHOT.war
=========
As of now, I believe we have two work-arounds available for 9.1 U1:
1. Use the CLI with an explicit virtual server argument.
2. Use the GUI to first do an explicit "Undeploy" and then a new "Deploy". As part of the "Deploy" operation ensure that a single virtual server is explicitly specified.