trocdombasc4 Upgrade Tool Dashboard
|
Issue | Comment | Resolution | Owner | |
---|---|---|---|---|
1. Domain.xml incompatibility : The introduction of mandatory attributes in the cluster elements has made the domain with sun-domain-1_1.dtd incompatible with a runtime that referes to sun-domain-1_3.dtd.Please refer to [ HERE | domainxmlchange] to get details of the problem elements | Working with Kedar to see if the element/attributes can be IMPLIED. Kedar's Comments: Just talked to Shreedhar. Get in touch with him for getting the exact values for heartbeat-enabled and heartbeat-port for existing clusters. | *RESOLVED*. Upgrade tool would add the necessary values using transform/new domain | Shreedhar/Shalini |
2. Node Agent synchronization : After upgrading the DAS to 9.1 , when we try and start the node-agent with the upgraded domain, the node-agent startup fails. Note that the node-agent has a domain.xml that corresponds to the sun-domain-1_1.dtd | Working with Nandini to resolve the issue. Most likely linked to 1 | *NOT RESOLVED* | Nandini | |
3. Redeployment of Applications : It is not clear if the runtime code generated for deployed applicationbythe 8.x runtime would work out of the box in 9.1 . It is stated that there is no mandate for the runtime code generation to be backward compatible. This necessiates the redeployment of application deployed in a 8.x domain when the domain is being upgraded. Kedar's Comment: Can you tell me which applications you are worried about? Also, have you tried this and found it to be a problem? PS : This applied to all applications that generate artifacts. It's Tony's and Jerome's contention that there is no mandate that code generated by the 8.x runtime should work as it is in the 9.1 installation. We need to get an answer from the deployment team on this | Need to resolve the impact of using the generated code from 8.x runtime. Kedar: We need to write down all the cases where specific code is generated. See UpgradeToolAndCodeGenerationForDeployedApplications. | *NOT RESOLVED* | All | |
4. Removal of com_sun_web_ui module : In 9.1 the com_sun_web_ui module has been removed, hence when we copy the 8.x domain, to work with 9.x domain it does not find it in $
Unknown macro: {com.sun.aas.installRoot}
/lib/install/applications and hence the domain cannot startup. Kedar's Comment: I am worried about this. Actually, we should make this work, IMO. It is not very clear to me – what admin GUI application upgrading user should see – the good old one or the new JSF based one? Let's discuss this. |
We need to remove the element corresponding to this web module using transformation | *RESOLVED* | Prasad | |
5. Enhancements to Inline Upgrade : Inline upgrade currently supports only the basic upgrade scenarios. It does not handle certificate migration. We can either go with the stand that we would only support the basic upgrade scenarios through the start domain command and the user would need to invoke asupgrade directly for certificate migration. Alternately, we can make the inline upgrade process full featured by adding support for certificate migration. Kedar: I think I am missing something. But didn't we decide that this won't be a problem for 8.x PE to 9.1PE/EE because for the former, the master password can safely be assumed to be changeit. For 8.x EE to 9.1 upgrade, I thought we should just copy the database. | Need Kedar's consent for adding certificate migation option for inline upgrade. This would entail prompting the user to check if he would want to migrate certificates and if yes, he would need to be prompted for the the jks password. Prasad: The bigger question that we need to answer here is : Do we need to give the user an option to migrate certificates or not , while using in-line upgrade ? We do provide the option to do so while using asupgrade. | *RESOLVED* | Satish/Prasad/Kedar | |
6. Option to turn off inline upgrade for better performance : Since StartDomainCommand.java currently checks if the specified domain needs to be upgraded each time the start-domain command is invoked, this could have an impact on the performance. We have introduced a new system property in StartDomainCommand to turn off the inline upgrade feature (and hence this check). The feature can be disabled by setting the 'com.sun.aas.EnableAutoUpgrade' property to 'n'. This check has, however, existed for a while (from 9.0?) and we do not have any statistical data on the exact performance impact as a consequence of this check. | Discussed this with Kedar on 12/12/06. | BUG ID 6509158 | Kedar/Jane | |
7. Upgrade tool Approach : Discussion regarding the approach that Upgrade tool must take. | Working with Kedar to resolve the issue. Most likely linked to 1 and 3 | Kedar/Prasad/Shalini |