| Summary: | Restarting server from STS does not recognise recovered deployments from pickup | ||
|---|---|---|---|
| Product: | [RT] Virgo | Reporter: | Steve Powell <zteve.powell> |
| Component: | runtime | Assignee: | Glyn Normington <glyn.normington> |
| Status: | CLOSED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | eclipse, glyn.normington, jsharier |
| Version: | 2.1.0.RC1-incubation | ||
| Target Milestone: | 3.7.0.M01 | ||
| Hardware: | PC | ||
| OS: | Windows All | ||
| Whiteboard: | |||
|
Description
Steve Powell
This error only occurs on Windows, can not recreate on Mac. Fixed by ensuring that checks by the HotDeployer for an already installed application always us the canonical URI of the file for comparisons. (In reply to comment #2) > Fixed by ensuring that checks by the HotDeployer for an already installed > application always us the canonical URI of the file for comparisons. Hi, I'm seeing this error when running Virgo 3.5.0.RELEASE in STS-2.9.2.RELEASE. How can I fix the error? Thanks Sounds like the bug may have come back, so best to re-open. The kernel code in StandardRuntimeArtifactModel canonicalises the URI passed in to get(URI) and in the precondition check (looking for duplicates) in add(URI, InstallArtifact), but then add goes on to use the non-canonical to add the artefact to its Map<URI, InstallArtifact>. The proposed fix is to canonicalise the URI input to add and use the canonical form for the rest of the method, thus ensuring that the canonical form is added to the map. Fixed in kernel commit 2ef25cfe47ff7421d1612086e455b0079da792b8. The proposed fix in kernel caused a regression in the web layer tests. Reverted the commit to avoid holding up M05. The symptoms of the problem in the web layer were that this.appDeployer.isDeployed(uri) - returned false with app still deployed and this.deployer.getDeploymentIdentity(getDefinitiveUri(sourceArtefact)) - returned null with app still deployed. The failing test case on web was -Dtestcase=org.eclipse.virgo.web.test.WarDirectoryDeploymentTests The problem was that File.toURI gives a file: URI with a trailing slash when a directory exists, but without the trailing slash if the purported "directory" does not exist. So deleting a directory from pickup closely followed by checking to see if the directory is deployed would generate the wrong URI and fail to find the directory is in fact still deployed. The fix (and a test to check the fix) are in kernel commit 67e08ddff2e5ca713543e1eccd61bcab5cc06e80 which is currently on the branch 328630-canonical-uris. I do not intend to rush this fix into 3.6.0 since one attempt already broke a milestone build, there is validation on Windows to do, and I would like this fix to bed in for a while before exposing it. The current behaviour, although wrong is simply an annoyance as the duplicate deployment exceptions stop the state from being corrupted in any way. After another Windows specific change and making the URI canonicalisation robust by re-throwing exceptions, I tested that the change fixes this bug and merged the branch into master for 3.7. |