xebialabs-community/xld-deployed-artifact-steps-plugin

Deployment fails if files are present on the target folder that are also in the to be deployed artifact

jdewinne opened this issue · 11 comments

XLD version: 8.0.0 (also reproducible on 8.1.0)
How to reproduce:

  • Deploy a file.LargeFolder onto an overthere.Host
  • Login onto the remote host and change a file on the targetPath
  • Undeploy the deployed application and skip all the steps.
  • Deploy the file.LargeFolder again onto the overthere.Host

Log output:

Analyze.../tmp/demo
Step failed
java.security.AccessControlException: access denied ("java.io.FilePermission" "work/workdir-20180712T044403316.3330/artifact.2128/cloud-plugin-3.9.3.jar/META-INF/MANIFEST.MF" "read")
at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
at java.security.AccessController.checkPermission(AccessController.java:884)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
at java.io.FileInputStream.<init>(FileInputStream.java:127)
at com.xebialabs.overthere.local.LocalFile$1.<init>(LocalFile.java:201)
at com.xebialabs.overthere.local.LocalFile.getInputStream(LocalFile.java:201)
at com.xebialabs.overtherepy.FileWrapper$OverthereFileByteSource.openStream(FileWrapper.java:82)
at com.google.common.io.ByteSource.copyTo(ByteSource.java:247)
at com.google.common.io.ByteSource.hash(ByteSource.java:325)
at com.xebialabs.overtherepy.FileWrapper.getHashCode(FileWrapper.java:59)
at com.xebialabs.overtherepy.DirectoryChangeSet.lambda$process$2(DirectoryChangeSet.java:65)
at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1380)
at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
at java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:291)
at java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731)
at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)

Something has changed in XLD engine since 8.x ... I'm investigating ...

It seems that the security policy file is not correct for this case. I think that was tightened/added in 8.0.0

cat xl-deploy.policy

grant {
    permission java.security.AllPermission;
};

That's weird. That should indeed mean that all permissions are granted. Though the stacktrace claims otherwise.

is it because I'm using foreach() with parallelStream() ?

rightWrappedChanged.parallelStream().forEach(file -> file.getHashCode());

I have no idea, have you tried without parallel?

@hierynomus without parallelStream (parallelStream=false) it works .. any ideas why does it fail when I use parallel Streams ?

No, I actually have no idea... Might be something deep in the JVM then...

@jdewinne this commit exposes the options in the file.LargeFolder plugin : 036f089

@bmoussaud you want me to report this with the XLD core team, so they can have a look at it why parallelStream isn't working?