Community
Participate
Working Groups
Restart server (i.e. non-clean start) and we see messages like this: [2010-10-25 17:10:43.238] fs-watcher <HD0001I> Hot deployer processing 'INITIAL' event for file 'org.eclipse.virgo.apps.splash-2.1.0.RC1-incubation.war'. [2010-10-25 17:10:43.238] fs-watcher <HD0005I> Hot deploy not performed because file 'org.eclipse.virgo.apps.splash-2.1.0.RC1-incubation.war' is already deployed. because splash is in pickup but was recovered. If the same server is then shutdown and started from STS (deploying nothing new) we see the following errors in the console: [2010-10-25 17:01:23.554] fs-watcher <HD0001I> Hot deployer processing 'INITIAL' event for file 'org.eclipse.virgo.apps.splash-2.1.0.RC1-incubation.war'. [2010-10-25 17:01:23.695] fs-watcher <HD0002E> Hot deploy failed for file 'org.eclipse.virgo.apps.splash-2.1.0.RC1-incubation.war'. org.eclipse.virgo.kernel.deployer.core.DeploymentException: The artifact bundle 'org.eclipse.virgo.apps.splash' version '2.1.0.RC1-incubation' in scope 'null' at URI 'file:/C:/virgo-web-server-2.1.0.RC1-incubation/pickup/org.eclipse.virgo.apps.splash-2.1.0.RC1-incubation.war' cannot be stored in the runtime artifact model as it clashes with the artifact bundle 'org.eclipse.virgo.apps.splash' version '2.1.0.RC1-incubation' in scope 'null' which is already present. at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:146) at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.install(PipelinedApplicationDeployer.java:123) at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.deploy(PipelinedApplicationDeployer.java:190) at org.eclipse.virgo.kernel.deployer.hot.HotDeploymentFileSystemListener.deploy(HotDeploymentFileSystemListener.java:174) at org.eclipse.virgo.kernel.deployer.hot.HotDeploymentFileSystemListener.deployIfNotDeployed(HotDeploymentFileSystemListener.java:186) at org.eclipse.virgo.kernel.deployer.hot.HotDeploymentFileSystemListener.onChange(HotDeploymentFileSystemListener.java:87) at org.eclipse.virgo.util.io.FileSystemChecker.notifyListeners(FileSystemChecker.java:245) at org.eclipse.virgo.util.io.FileSystemChecker.check(FileSystemChecker.java:166) at org.eclipse.virgo.kernel.deployer.hot.WatchTask.run(WatchTask.java:58) at java.lang.Thread.run(Thread.java:662) Caused by: org.eclipse.virgo.kernel.deployer.model.DuplicateFileNameException: The artifact bundle 'org.eclipse.virgo.apps.splash' version '2.1.0.RC1-incubation' in scope 'null' at URI 'file:/C:/virgo-web-server-2.1.0.RC1-incubation/pickup/org.eclipse.virgo.apps.splash-2.1.0.RC1-incubation.war' cannot be stored in the runtime artifact model as it clashes with the artifact bundle 'org.eclipse.virgo.apps.splash' version '2.1.0.RC1-incubation' in scope 'null' which is already present. at org.eclipse.virgo.kernel.deployer.model.internal.StandardRuntimeArtifactModel.checkFileName(StandardRuntimeArtifactModel.java:94) at org.eclipse.virgo.kernel.deployer.model.internal.StandardRuntimeArtifactModel.add(StandardRuntimeArtifactModel.java:72) at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.addTreeToModel(PipelinedApplicationDeployer.java:240) at org.eclipse.virgo.kernel.deployer.core.internal.PipelinedApplicationDeployer.doInstall(PipelinedApplicationDeployer.java:144) ... 9 common frames omitted I see this on Windows. Recreate: Installing Virgo Web Server and start it. Shutdown the server. Install STS, define a Virgo Web Server server, and start it from STS. Expected behaviour, should see the same 'already deployed' messages.
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.
