[jbosstools-issues] [JBoss JIRA] Commented: (JBIDE-7199) Seam 2.2.1CR1 + JBDS4M2 + AS6M5 = SHA1 digest error for jdtCompilerAdapter.jar
Rob Stryker (JIRA)
jira-events at lists.jboss.org
Wed Dec 1 11:23:05 EST 2010
[ https://jira.jboss.org/browse/JBIDE-7199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12566581#comment-12566581 ]
Rob Stryker commented on JBIDE-7199:
------------------------------------
I've replicated it again, and the jar is completely corrupt and will not open. But... this is extremely extremely interesting.
Let me summarize my findings. The jdtCompilerAdapter.jar is inside the web-inf/lib/core.jar file, sitting inside. In the workspace, when I browse to this jar, it is about 12-13kb in size, and it opens fine.
The version sitting in the tmp/vfs folder inside jboss is only 8kb, and is 100% corrupt. I cannot even open it to browse the files. And so, I figure, what's the deal here? What's going wrong? I then check the actual deployed war file, and expand it's stuff and extract it piece by piece, and I can browse all parts of it. 100% all parts. My results are showing:
(discovered and isolated) workspace jdtCompilerAdapter.jar 12919 size, openable, timestamps, etc
(found from tmp folder) jboss "TMP FOLDER" jdtCompilerAdapter.jar 8246 size, NOT openable, completely corrupt
jboss DEPLOYMENT (inside war) jdtCompilerAdapter.jar 12911 size, openable, timestamps normal etc
So... the timestamps are all the same but there's a 9 byte difference (?!?!)
I then do the following to compare contents and timestamps:
unzip -l workspaceVersion.jar | sort > out1
unzip -l deploymentVersion.jar | sort > out2
diff out1 out2
There is *no* difference, WHEN the zip order is sorted. However, just doing raw unzip -l, you can see the ORDER of the files is very different. If the key is so sensitive as to be affected by the order of the files inside the zip, we may have no choice at all except to not use truezip for this. I really have no idea what to do. The fact is the contents and the timestamp are virtually identical, but the order of the resources is not.
Max, I would *LOVE* to hear your thoughts on this.
> Seam 2.2.1CR1 + JBDS4M2 + AS6M5 = SHA1 digest error for jdtCompilerAdapter.jar
> ------------------------------------------------------------------------------
>
> Key: JBIDE-7199
> URL: https://jira.jboss.org/browse/JBIDE-7199
> Project: Tools (JBoss Tools)
> Issue Type: Bug
> Components: JBossAS
> Affects Versions: 3.2.0.M2
> Environment: Win 7 Java 1.6 32-bit
> Reporter: Burr Sutter
> Assignee: Rob Stryker
> Priority: Blocker
> Fix For: 3.2.0.Beta2
>
> Attachments: boot.log, boot.log, server.log, server.log
>
>
> New Seam Web Project - using Seam 2.2.1CR1 to target JBoss AS6 M5, it fails on deployment.
> 10:06:23,314 ERROR [org.jboss.kernel.plugins.dependency.AbstractKernelController] Error installing to Real: name=vfs:///D:/servers/jboss-6.0.0.20100911-M5/server/default/deploy/SeamWebProject1.war state=PreReal mode=Manual requiredState=Real: org.jboss.deployers.spi.DeploymentException: Failed to create web module
> at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:461) [:6.0.0.20100911-M5]
> at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:106) [:6.0.0.20100911-M5]
> at org.jboss.deployers.spi.deployer.helpers.AbstractSimpleRealDeployer.internalDeploy(AbstractSimpleRealDeployer.java:62) [:2.2.0.Alpha7]
> at org.jboss.deployers.spi.deployer.helpers.AbstractRealDeployer.deploy(AbstractRealDeployer.java:55) [:2.2.0.Alpha7]
> at org.jboss.deployers.plugins.deployers.DeployerWrapper.deploy(DeployerWrapper.java:179) [:2.2.0.Alpha7]
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doDeploy(DeployersImpl.java:1832) [:2.2.0.Alpha7]
> at org.jboss.deployers.plugins.deployers.DeployersImpl.doInstallParentFirst(DeployersImpl.java:1550) [:2.2.0.Alpha7]
> at org.jboss.deployers.plugins.deployers.DeployersImpl.install(DeployersImpl.java:1491) [:2.2.0.Alpha7]
> at org.jboss.dependency.plugins.AbstractControllerContext.install(AbstractControllerContext.java:379) [jboss-dependency.jar:2.2.0.Alpha10]
> at org.jboss.dependency.plugins.AbstractController.install(AbstractController.java:2044) [jboss-dependency.jar:2.2.0.Alpha10]
> at org.jboss.dependency.plugins.AbstractController.incrementState(AbstractController.java:1083) [jboss-dependency.jar:2.2.0.Alpha10]
> at org.jboss.dependency.plugins.AbstractController.executeOrIncrementStateDirectly(AbstractController.java:1322) [jboss-dependency.jar:2.2.0.Alpha10]
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1246) [jboss-dependency.jar:2.2.0.Alpha10]
> at org.jboss.dependency.plugins.AbstractController.resolveContexts(AbstractController.java:1139) [jboss-dependency.jar:2.2.0.Alpha10]
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:939) [jboss-dependency.jar:2.2.0.Alpha10]
> at org.jboss.dependency.plugins.AbstractController.change(AbstractController.java:654) [jboss-dependency.jar:2.2.0.Alpha10]
> at org.jboss.deployers.plugins.deployers.DeployersImpl.change(DeployersImpl.java:1983) [:2.2.0.Alpha7]
> at org.jboss.deployers.plugins.deployers.DeployersImpl.process(DeployersImpl.java:1076) [:2.2.0.Alpha7]
> at org.jboss.deployers.plugins.main.MainDeployerImpl.process(MainDeployerImpl.java:679) [:2.2.0.Alpha7]
> at org.jboss.system.server.profileservice.deployers.MainDeployerPlugin.process(MainDeployerPlugin.java:106) [:6.0.0.20100911-M5]
> at org.jboss.profileservice.dependency.ProfileControllerContext$DelegateDeployer.process(ProfileControllerContext.java:130) [:0.1.0.Alpha1]
> at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.deploy(HDScanner.java:240) [:0.1.0.Alpha1]
> at org.jboss.profileservice.deployment.hotdeploy.HDScanner$HDScanAction.complete(HDScanner.java:192) [:0.1.0.Alpha1]
> at org.jboss.profileservice.management.TwoPCActionWrapper.doComplete(TwoPCActionWrapper.java:59) [:0.1.0.Alpha1]
> at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.complete(AbstractTwoPhaseModificationAction.java:74) [:0.1.0.Alpha1]
> at org.jboss.profileservice.management.actions.AbstractTwoPhaseModificationAction.prepare(AbstractTwoPhaseModificationAction.java:94) [:0.1.0.Alpha1]
> at org.jboss.profileservice.management.ModificationSession.prepare(ModificationSession.java:87) [:0.1.0.Alpha1]
> at org.jboss.profileservice.management.AbstractActionController.internalPerfom(AbstractActionController.java:234) [:0.1.0.Alpha1]
> at org.jboss.profileservice.management.AbstractActionController.performWrite(AbstractActionController.java:213) [:0.1.0.Alpha1]
> at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:150) [:0.1.0.Alpha1]
> at org.jboss.profileservice.management.AbstractActionController.perform(AbstractActionController.java:135) [:0.1.0.Alpha1]
> at org.jboss.profileservice.deployment.hotdeploy.HDScanner.scan(HDScanner.java:146) [:0.1.0.Alpha1]
> at org.jboss.profileservice.deployment.hotdeploy.HDScanner.run(HDScanner.java:90) [:0.1.0.Alpha1]
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_20]
> at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_20]
> at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_20]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_20]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) [:1.6.0_20]
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) [:1.6.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_20]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_20]
> at java.lang.Thread.run(Thread.java:619) [:1.6.0_20]
> Caused by: java.lang.SecurityException: SHA1 digest error for jdtCompilerAdapter.jar
> at sun.security.util.ManifestEntryVerifier.verify(ManifestEntryVerifier.java:192) [:1.6.0_20]
> at java.util.jar.JarVerifier.processEntry(JarVerifier.java:212) [:1.6.0_20]
> at java.util.jar.JarVerifier.update(JarVerifier.java:199) [:1.6.0_20]
> at java.util.jar.JarVerifier$VerifierStream.read(JarVerifier.java:449) [:1.6.0_20]
> at java.io.InputStream.read(InputStream.java:85) [:1.6.0_20]
> at org.jboss.vfs.VFSUtils.copyStream(VFSUtils.java:439) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.VFSUtils.copyStreamAndClose(VFSUtils.java:398) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.VFSUtils.copyStreamAndClose(VFSUtils.java:383) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.spi.JavaZipFileSystem.getFile(JavaZipFileSystem.java:157) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.VirtualFile.getPhysicalFile(VirtualFile.java:261) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.web.deployers.AbstractWarDeployer$1.visit(AbstractWarDeployer.java:795) [:6.0.0.20100911-M5]
> at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:407) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:409) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.vfs.VirtualFile.visit(VirtualFile.java:395) [jboss-vfs.jar:3.0.0.CR5]
> at org.jboss.web.deployers.AbstractWarDeployer.getExplodedWarUrl(AbstractWarDeployer.java:808) [:6.0.0.20100911-M5]
> at org.jboss.web.deployers.AbstractWarDeployer.deploy(AbstractWarDeployer.java:374) [:6.0.0.20100911-M5]
> ... 41 more
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
More information about the jbosstools-issues
mailing list