Community
Participate
Working Groups
Build Identifier: 3.6.1/STS 2.5.1 [2011-01-07 12:00:13.624] TCP Connection(2)-127.0.0.1 <ME0003I> Dump 'serviceability/dump/2011-01-07-12-00-077' generated [2011-01-07 12:00:13.629] TCP Connection(2)-127.0.0.1 <DE0002E> Installation of par 'greenpages-solution' version '0.0.0' failed. java.lang.UnsupportedOperationException: Cannot open an input stream for '/opt/java/OSGi/virgo-web-server-2.1.0.RELEASE/work/org.ecli pse.virgo.kernel.deployer_2.1.0.RELEASE/staging/greenpages-s olution-0/bundle/greenpages-solution-0-greenpages.db-solutio n/0.0.0/greenpages.db-solution.jar/META-INF/MANIFEST.MF' as it does not exist Reproducible: Always
The publisher is not populating the stage folder with files for any kind of artifacts (Dynamic web project, Eclipse RT bundle, etc)
This issue is related to https://bugs.eclipse.org/bugs/show_bug.cgi?id=219332 VirgoServerBehaviour.getPublishedResourceDelta(IModule[] module) calls org.eclipse.wst.server.core.internal.Server.getPublishedResourceDelta(IModule[] module) calls ... PublishHelper.safeRename(File from, File to, int retrys) from.renameTo(to) fails In Linux one cannot renameTo() across file systems. This behavior is different than the Unix "mv" command. When crossing file systems mv does a copy and delete. Moving the Virgo server on the same partition like the workspace did solve the issue. I believe the solution would be to have the "stage" folder inside the .metadata folder (as well as the "work" folder).
Thanks for the extra info. The plan is to address tooling bugs once the donation to Eclipse is complete (which is progressing well).
Mike, we're looking to address a more general issue and you could help with that since you've got something broken. :) See bug 373684-- What we want to find out is whether a full clean (Right-click Server in Servers view, select "Clean...") *does* successfully deploy all of the artifacts. Could you confirm that for us? At least it would provide a work-around. (And then I promise that we'll look at this issue too!) thanks, Miles
Glyn, with respect to the bug itself, this doesn't seem to be an issue that tooling can address directly. The issue seems to be with WTP being unable to handle the synchronization across partitions. The reporters suggestion to move these directories into .metadata (to force things on to the same partition?) would seem to require significant changes in the way the runtime directory structure is setup. Or am I misunderstanding something here?
(In reply to comment #5) > Glyn, with respect to the bug itself, this doesn't seem to be an issue that > tooling can address directly. The issue seems to be with WTP being unable to > handle the synchronization across partitions. The reporters suggestion to move > these directories into .metadata (to force things on to the same partition?) > would seem to require significant changes in the way the runtime directory > structure is setup. Or am I misunderstanding something here? Moving the stage directory into .metadata would not impact the runtime as the stage directory is used by the Virgo IDE tooling and the runtime does not know about it explicitly. However, moving the work directory into .metadata would require a change in the runtime and I don't particularly want to add this complexity. The whole issue seems to be that a file rename is being used to move a file and this doesn't work on Linux when the source and target are on distinct filesystems. Perhaps it would be better to fix that root problem, e.g. by catching the exception and then doing a copy+delete?
