[JBoss JIRA] (DROOLS-974) Activation group doesn't work as expected
by Hanbing Luo (JIRA)
Hanbing Luo created DROOLS-974:
----------------------------------
Summary: Activation group doesn't work as expected
Key: DROOLS-974
URL: https://issues.jboss.org/browse/DROOLS-974
Project: Drools
Issue Type: Bug
Affects Versions: 6.3.0.Final, 6.2.0.Final
Environment: Mac OS X 10.8.3
jdk 1.7.0_60
Reporter: Hanbing Luo
Assignee: Mark Proctor
In some rare cases activation group doesn't work as expected. For example, two rules with same ruleflow-group and activation-group but different salience are both get fired if reuse kie session.
Some investigation notes to help address.
1) This issue never happen if use a new fresh kie session.
2) I also tried to write a drools style unit test (testActivationGroupIssue in ExecutionFlowControlTest.java) but can't reproduce this issue.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-5648) Access log message fails to be written to recreated access log on Windows
by Radim Hatlapatka (JIRA)
Radim Hatlapatka created WFLY-5648:
--------------------------------------
Summary: Access log message fails to be written to recreated access log on Windows
Key: WFLY-5648
URL: https://issues.jboss.org/browse/WFLY-5648
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Reporter: Radim Hatlapatka
Assignee: Stuart Douglas
Undertow fails to write to access-log when the access-log configuration was removed including the access-log file and then the configuration was recreated with [1]. Probably there remains some lock to old file preventing creation of the new one.
Steps to reproduce:
1) deploy some simple web application
2) define access-log => {{/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()}}
3) reload server
4) access the web application
5) see that the access was logged to access-log
6) remove the access-log => {{/subsystem=undertow/server=default-server/host=default-host/setting=access-log:remove()}}
7) reload the server
8) remove the access-log file
9) define again the access-log => {{/subsystem=undertow/server=default-server/host=default-host/setting=access-log:add()}}
10) access again the web application
11) check both server logs and access-log
[1]
{noformat}
05:49:51,448 ERROR [io.undertow] (default task-2) UT005016: Error writing access log: java.nio.file.AccessDeniedException: W:\workspace\eap-7x-undertow-integration-tests\d07ae7a0\manu-eap-1.1.13\out\UnzipEap_1\workspace\jboss-eap-7.0\standalone\log\access_log.log
at sun.nio.fs.WindowsException.translateToIOException(WindowsException.java:83)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:97)
at sun.nio.fs.WindowsException.rethrowAsIOException(WindowsException.java:102)
at sun.nio.fs.WindowsFileSystemProvider.newByteChannel(WindowsFileSystemProvider.java:230)
at java.nio.file.spi.FileSystemProvider.newOutputStream(FileSystemProvider.java:434)
at java.nio.file.Files.newOutputStream(Files.java:216)
at java.nio.file.Files.newBufferedWriter(Files.java:2860)
at io.undertow.server.handlers.accesslog.DefaultAccessLogReceiver.writeMessage(DefaultAccessLogReceiver.java:224)
at io.undertow.server.handlers.accesslog.DefaultAccessLogReceiver.run(DefaultAccessLogReceiver.java:180)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{noformat}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1107) DirectoryNotEmptyException on undeploy of ear
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1107?page=com.atlassian.jira.plugi... ]
ehsavoie Hugonnet commented on WFCORE-1107:
-------------------------------------------
Issue is due to the fact that we are trying to delete the 'hash path' and the forefather might be shared among contents.
> DirectoryNotEmptyException on undeploy of ear
> ---------------------------------------------
>
> Key: WFCORE-1107
> URL: https://issues.jboss.org/browse/WFCORE-1107
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: Oracle Solaris SPARC 10, Oracle JDK 1.8.0_45.
> Reporter: Frank Langelage
> Assignee: ehsavoie Hugonnet
>
> When undeploying my ear by removing the ear file from the standalone/deployments folder I sometimes see this exception at the end:
> 21.06. 16:49:25,674 INFO [org.jboss.as.server.deployment#stop] WFLYSRV0028: Stopped deployment maj2e-langfr-dev.ear (runtime-name: maj2e-langfr-dev.ear) in 3072ms
> 21.06. 16:49:26,034 ERROR [org.jboss.as.repository#removeContent] WFLYDR0010: Couldn't delete content /mbi/tools/jboss/10.0/standalone/data/content/30: java.nio.file.DirectoryNotEmptyException: /mbi/tools/jboss/10.0/standalone/data/content/30
> at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
> at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> at java.nio.file.Files.deleteIfExists(Files.java:1165)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:370)
> at org.jboss.as.server.deployment.DeploymentRemoveHandler$1$1.handleResult(DeploymentRemoveHandler.java:118)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1420)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1400)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1351)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1199)
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:956)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:904)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:620)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:373)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:349)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1201)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:223)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:747)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:741)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.controller.ModelControllerImpl$3$1.run(ModelControllerImpl.java:741)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 21.06. 16:49:26,174 INFO [org.jboss.as.repository#removeContent] WFLYDR0002: Content removed from location /mbi/tools/jboss/10.0/standalone/data/content/30/4fee5b5fa782d2a7f04723ccab3e12351d600b/content
> 21.06. 16:49:26,176 INFO [org.jboss.as.server#handleResult] WFLYSRV0009: Undeployed "maj2e-langfr-dev.ear" (runtime-name: "maj2e-langfr-dev.ear")
> The exception seems to be ignored. But the named folder and
> a file /mbi/tools/jboss/10.0/standalone/data/content/30/7cb1f70d08fb375010369eea154c5db479eaba/content are still there.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4205) Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
by David Edwards (JIRA)
[ https://issues.jboss.org/browse/WFLY-4205?page=com.atlassian.jira.plugin.... ]
David Edwards commented on WFLY-4205:
-------------------------------------
To follow up on my previous comment, I think there is still a problem with the @HandlesTypes scanning. In Wildfly 8.2.1, it won't find my SpringBootServletInitializer classes (which in turn extends WebApplicationInitializer) wherever I put them - in the EAR or WAR. In Wildfly 9.0.2, it only finds them if they are in the EAR lib folder. I think it should be looking in the full classpath for the WAR, which would include both locations.
Should I open a new ticket for this problem?
> Undertow not detecting @HandlesTypes If the implentation class is inside EAR/lib
> --------------------------------------------------------------------------------
>
> Key: WFLY-4205
> URL: https://issues.jboss.org/browse/WFLY-4205
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.2.0.Final
> Environment: Wildfly 8.2.0 Final, EAR Deployment, Spring MVC, Ubuntu 14.04
> Reporter: Nick .
> Assignee: Stuart Douglas
> Labels: EAR, servlet3.0, spring-mvc
> Fix For: 9.0.0.Beta1
>
>
> Hi,
> I have spring mvc enabled web apps (20+ web apps) packaged as an EAR deployment. All my spring mvc related jar's are in my EAR/lib, i'm using SpringServletContainerInitializer (implementation of ServletContainerInitializer ) code as follows
> {code}
> @HandlesTypes(WebApplicationInitializer.class)
> public class SpringServletContainerInitializer implements ServletContainerInitializer {
> @Override
> public void onStartup(Set<Class<?>> webAppInitializerClasses, ServletContext servletContext)
> throws ServletException {
> List<WebApplicationInitializer> initializers = new LinkedList<WebApplicationInitializer>();
> if (webAppInitializerClasses != null) {
> for (Class<?> waiClass : webAppInitializerClasses) {
> // Be defensive: Some servlet containers provide us with invalid classes,
> // no matter what @HandlesTypes says...
> if (!waiClass.isInterface() && !Modifier.isAbstract(waiClass.getModifiers()) &&
> WebApplicationInitializer.class.isAssignableFrom(waiClass)) {
> try {
> initializers.add((WebApplicationInitializer) waiClass.newInstance());
> }
> catch (Throwable ex) {
> throw new ServletException("Failed to instantiate WebApplicationInitializer class", ex);
> }
> }
> }
> }
> if (initializers.isEmpty()) {
> servletContext.log("No Spring WebApplicationInitializer types detected on classpath");
> return;
> }
> AnnotationAwareOrderComparator.sort(initializers);
> servletContext.log("Spring WebApplicationInitializers detected on classpath: " + initializers);
> for (WebApplicationInitializer initializer : initializers) {
> initializer.onStartup(servletContext);
> }
> }
> }
> {code}
> But the @HandlesTypes(WebApplicationInitializer.class) are not getting detected from the EAR/lib
> Even i have tried adding the extracted the SPI from spring-web jar and added inside my war's WEB-INF/lib as a jar
> WEB-INF/lib/web-init-spi.jar which contains
> META-INF/services/javax.servlet.ServletContainerIntializer file with org.springframework.web.SpringServletContainerInitializer as an entry. This time its detecting SpringServletContainerInitializer but not detecting what defined in @HandlesTypes
> Its only working If i package all those spring mvc jars inside WEB-INF/lib then everything started working.
> I have no idea this is how the servlet specification works or its a wildfly issue but i see it as a problem for those who depends on Wildfly or similar EE Servers with an EAR deployment structure.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4338) JConsole script builds wrong path
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4338?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-4338:
-----------------------------------
Priority: Major (was: Trivial)
> JConsole script builds wrong path
> ---------------------------------
>
> Key: WFLY-4338
> URL: https://issues.jboss.org/browse/WFLY-4338
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Affects Versions: 8.2.0.Final
> Environment: Linux (Ubuntu 14.10) and Mac OS X Yosemite (10.10.2)
> Reporter: André Lemos
> Labels: bash, jconsole, wildfly
> Attachments: jconsole.patch
>
>
> The path built by the jconsole.sh script is incorrect, and as a result, when calling {{service:jmx:http-remoting-jmx://{insert server ip here}:9990}} is probably never recognized and the connection is never done.
> The path, under mac is:
> {{/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/bin/jconsole -J-Djava.class.path=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/lib/jconsole.jar:/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/lib/tools.jar:"/Users/user/Documents/playground/wild/wildfly-8.2.0.Final"/bin/client/jboss-cli-client.jar}}
> So, there are " on the path for the jboss-cli-client.jar. which breaks things. This problem happens with both Linux and Mac.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4338) JConsole script builds wrong path
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-4338?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-4338:
--------------------------------------
Assignee: Darran Lofthouse
> JConsole script builds wrong path
> ---------------------------------
>
> Key: WFLY-4338
> URL: https://issues.jboss.org/browse/WFLY-4338
> Project: WildFly
> Issue Type: Bug
> Components: JMX
> Affects Versions: 8.2.0.Final
> Environment: Linux (Ubuntu 14.10) and Mac OS X Yosemite (10.10.2)
> Reporter: André Lemos
> Assignee: Darran Lofthouse
> Labels: bash, jconsole, wildfly
> Attachments: jconsole.patch
>
>
> The path built by the jconsole.sh script is incorrect, and as a result, when calling {{service:jmx:http-remoting-jmx://{insert server ip here}:9990}} is probably never recognized and the connection is never done.
> The path, under mac is:
> {{/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/bin/jconsole -J-Djava.class.path=/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/lib/jconsole.jar:/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/lib/tools.jar:"/Users/user/Documents/playground/wild/wildfly-8.2.0.Final"/bin/client/jboss-cli-client.jar}}
> So, there are " on the path for the jboss-cli-client.jar. which breaks things. This problem happens with both Linux and Mac.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JBVFS-202) Invalid Local file header in ZIP file
by Martin Both (JIRA)
[ https://issues.jboss.org/browse/JBVFS-202?page=com.atlassian.jira.plugin.... ]
Martin Both updated JBVFS-202:
------------------------------
Description:
I'm try to use the Embeddable EJBContainer of JBoss EAP 6.4.
I get a ZipException: invalid CEN header (bad signature)
JBoss writes an invalid Zip- file in
JBossEAP6.4\standalone\data\content\58\a481cdfbe31a8ad823b6708f17151589954ac6/content
The reason is, that the zip file content contains a Local file header with no size for the file data. No Zip-Tool can unzip that and even JBoss cannot read that again.
Compare the method bufferLocalFileHeader() with the method bufferNextCentralFileHeader() of class org.jboss.vfs,VirtualJarFileInputStream.
The one wirtes file sizes the other one not. If you would read the file format specification of zip files than you would know that after the LocallFileHeader the file data is written. Without knowledge of the compressed size it is not possible to read that.
Deployment with Embeddable EJBContainer does not work for me due to this bug.
Trace:
2015-11-09 11:16:02,392 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.4.0.GA (AS 7.5.0.Final-redhat-21) wurde gestartet in 2502ms - 168 von 205 Diensten gestartet (61 Services sind "lazy", passiv oder werden bei Bedarf geladen)
2015-11-09 11:16:03,094 INFO [org.jboss.as.repository] (pool-4-thread-1) JBAS014900: Content an Speicherort C:\Users\A300859\workspaces\ProKom2.0_trunk\Servers\JBossEAP6.4\standalone\data\content\58\a481cdfbe31a8ad823b6708f17151589954ac6\content hinzugefügt
2015-11-09 11:16:03,120 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starte Deployment von "classes" (runtime-name: "classes")
2015-11-09 11:16:03,159 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit.classes.STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit.classes.STRUCTURE: JBAS018733: Verarbeitung von Phase STRUCTURE von deployment "classes" fehlgeschlagen
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Einhängen des Deployment-Contents fehlgeschlagen
at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:97) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
... 5 more
Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)
at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.8.0_60]
at java.util.zip.ZipFile.<init>(ZipFile.java:219) [rt.jar:1.8.0_60]
at java.util.zip.ZipFile.<init>(ZipFile.java:149) [rt.jar:1.8.0_60]
at java.util.jar.JarFile.<init>(JarFile.java:166) [rt.jar:1.8.0_60]
at java.util.jar.JarFile.<init>(JarFile.java:130) [rt.jar:1.8.0_60]
at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:90) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:77) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
at org.jboss.vfs.VFS.mountZip(VFS.java:386) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
at org.jboss.vfs.VFS.mountZip(VFS.java:410) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
at org.jboss.as.server.deployment.DeploymentMountProvider$Factory$ServerDeploymentRepositoryImpl.mountDeploymentContent(DeploymentMountProvider.java:105) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:93) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
... 6 more
2015-11-09 11:16:03,161 ERROR [org.jboss.as.controller.management-operation] (pool-4-thread-1) JBAS014612: Operation ("deploy") fehlgeschlagen - Adresse: ([("deployment" => "classes")]) - Fehlerbeschreibung: {"JBAS014671: Fehlgeschlagene Dienste" => {"jboss.deployment.unit.classes.STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.classes.STRUCTURE: JBAS018733: Verarbeitung von Phase STRUCTURE von deployment \"classes\" fehlgeschlagen
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Einhängen des Deployment-Contents fehlgeschlagen
Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)"}}
2015-11-09 11:16:03,163 ERROR [org.jboss.as.server] (pool-4-thread-1) JBAS015870: Deploy von Deployment "classes" wurde mit folgender Fehlermeldung zurückgesetzt:
{"JBAS014671: Fehlgeschlagene Dienste" => {"jboss.deployment.unit.classes.STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.classes.STRUCTURE: JBAS018733: Verarbeitung von Phase STRUCTURE von deployment \"classes\" fehlgeschlagen
Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Einhängen des Deployment-Contents fehlgeschlagen
Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)"}}
2015-11-09 11:16:03,165 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Deployment von classes in (runtime-name: "classes") 2ms gestoppt
2015-11-09 11:16:03,166 INFO [org.jboss.as.controller] (pool-4-thread-1) JBAS014774: Dienst-Statusbericht
JBAS014777: Dienste, deren Start fehlgeschlagen ist: service jboss.deployment.unit.classes.STRUCTURE
was:
I'm try to use the Embeddable EJBContainer of JBoss EAP 6.4.
I get a ZipException: invalid CEN header (bad signature)
JBoss writes an invalid Zip- file in
JBossEAP6.4\standalone\data\content\58\a481cdfbe31a8ad823b6708f17151589954ac6/content
The reason is, that the zip file content contains a Local file header with no size for the file data. No Zip-Tool can unzip that and even JBoss cannot read that again.
Compare the method bufferLocalFileHeader() with the method bufferNextCentralFileHeader() of class org.jboss.vfs,VirtualJarFileInputStream.
The one wirtes file sizes the other one not. If you would read the file format specification of zip files than you would know that after the LocallFileHeader the file data is written. Without knowledge of the compressed size it is not possible to read that.
Deployment with Embeddable EJBContainer does not work for me due to this bug.
> Invalid Local file header in ZIP file
> -------------------------------------
>
> Key: JBVFS-202
> URL: https://issues.jboss.org/browse/JBVFS-202
> Project: JBoss VFS
> Issue Type: Bug
> Reporter: Martin Both
> Assignee: Tomaz Cerar
>
> I'm try to use the Embeddable EJBContainer of JBoss EAP 6.4.
> I get a ZipException: invalid CEN header (bad signature)
> JBoss writes an invalid Zip- file in
> JBossEAP6.4\standalone\data\content\58\a481cdfbe31a8ad823b6708f17151589954ac6/content
> The reason is, that the zip file content contains a Local file header with no size for the file data. No Zip-Tool can unzip that and even JBoss cannot read that again.
> Compare the method bufferLocalFileHeader() with the method bufferNextCentralFileHeader() of class org.jboss.vfs,VirtualJarFileInputStream.
> The one wirtes file sizes the other one not. If you would read the file format specification of zip files than you would know that after the LocallFileHeader the file data is written. Without knowledge of the compressed size it is not possible to read that.
> Deployment with Embeddable EJBContainer does not work for me due to this bug.
> Trace:
> 2015-11-09 11:16:02,392 INFO [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss EAP 6.4.0.GA (AS 7.5.0.Final-redhat-21) wurde gestartet in 2502ms - 168 von 205 Diensten gestartet (61 Services sind "lazy", passiv oder werden bei Bedarf geladen)
> 2015-11-09 11:16:03,094 INFO [org.jboss.as.repository] (pool-4-thread-1) JBAS014900: Content an Speicherort C:\Users\A300859\workspaces\ProKom2.0_trunk\Servers\JBossEAP6.4\standalone\data\content\58\a481cdfbe31a8ad823b6708f17151589954ac6\content hinzugefügt
> 2015-11-09 11:16:03,120 INFO [org.jboss.as.server.deployment] (MSC service thread 1-5) JBAS015876: Starte Deployment von "classes" (runtime-name: "classes")
> 2015-11-09 11:16:03,159 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.deployment.unit.classes.STRUCTURE: org.jboss.msc.service.StartException in service jboss.deployment.unit.classes.STRUCTURE: JBAS018733: Verarbeitung von Phase STRUCTURE von deployment "classes" fehlgeschlagen
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:166) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1980) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1913) [jboss-msc-1.1.5.Final-redhat-1.jar:1.1.5.Final-redhat-1]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_60]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_60]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_60]
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Einhängen des Deployment-Contents fehlgeschlagen
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:97) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 5 more
> Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)
> at java.util.zip.ZipFile.open(Native Method) [rt.jar:1.8.0_60]
> at java.util.zip.ZipFile.<init>(ZipFile.java:219) [rt.jar:1.8.0_60]
> at java.util.zip.ZipFile.<init>(ZipFile.java:149) [rt.jar:1.8.0_60]
> at java.util.jar.JarFile.<init>(JarFile.java:166) [rt.jar:1.8.0_60]
> at java.util.jar.JarFile.<init>(JarFile.java:130) [rt.jar:1.8.0_60]
> at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:90) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.spi.JavaZipFileSystem.<init>(JavaZipFileSystem.java:77) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.VFS.mountZip(VFS.java:386) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.vfs.VFS.mountZip(VFS.java:410) [jboss-vfs-3.2.9.Final-redhat-1.jar:3.2.9.Final-redhat-1]
> at org.jboss.as.server.deployment.DeploymentMountProvider$Factory$ServerDeploymentRepositoryImpl.mountDeploymentContent(DeploymentMountProvider.java:105) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> at org.jboss.as.server.deployment.module.DeploymentRootMountProcessor.deploy(DeploymentRootMountProcessor.java:93) [jboss-as-server-7.5.0.Final-redhat-21.jar:7.5.0.Final-redhat-21]
> ... 6 more
> 2015-11-09 11:16:03,161 ERROR [org.jboss.as.controller.management-operation] (pool-4-thread-1) JBAS014612: Operation ("deploy") fehlgeschlagen - Adresse: ([("deployment" => "classes")]) - Fehlerbeschreibung: {"JBAS014671: Fehlgeschlagene Dienste" => {"jboss.deployment.unit.classes.STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.classes.STRUCTURE: JBAS018733: Verarbeitung von Phase STRUCTURE von deployment \"classes\" fehlgeschlagen
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Einhängen des Deployment-Contents fehlgeschlagen
> Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)"}}
> 2015-11-09 11:16:03,163 ERROR [org.jboss.as.server] (pool-4-thread-1) JBAS015870: Deploy von Deployment "classes" wurde mit folgender Fehlermeldung zurückgesetzt:
> {"JBAS014671: Fehlgeschlagene Dienste" => {"jboss.deployment.unit.classes.STRUCTURE" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.classes.STRUCTURE: JBAS018733: Verarbeitung von Phase STRUCTURE von deployment \"classes\" fehlgeschlagen
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018740: Einhängen des Deployment-Contents fehlgeschlagen
> Caused by: java.util.zip.ZipException: invalid CEN header (bad signature)"}}
> 2015-11-09 11:16:03,165 INFO [org.jboss.as.server.deployment] (MSC service thread 1-4) JBAS015877: Deployment von classes in (runtime-name: "classes") 2ms gestoppt
> 2015-11-09 11:16:03,166 INFO [org.jboss.as.controller] (pool-4-thread-1) JBAS014774: Dienst-Statusbericht
> JBAS014777: Dienste, deren Start fehlgeschlagen ist: service jboss.deployment.unit.classes.STRUCTURE
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (JBVFS-202) Invalid Local file header in ZIP file
by Martin Both (JIRA)
[ https://issues.jboss.org/browse/JBVFS-202?page=com.atlassian.jira.plugin.... ]
Martin Both updated JBVFS-202:
------------------------------
Description:
I'm try to use the Embeddable EJBContainer of JBoss EAP 6.4.
I get a ZipException: invalid CEN header (bad signature)
JBoss writes an invalid Zip- file in
JBossEAP6.4\standalone\data\content\58\a481cdfbe31a8ad823b6708f17151589954ac6/content
The reason is, that the zip file content contains a Local file header with no size for the file data. No Zip-Tool can unzip that and even JBoss cannot read that again.
Compare the method bufferLocalFileHeader() with the method bufferNextCentralFileHeader() of class org.jboss.vfs,VirtualJarFileInputStream.
The one wirtes file sizes the other one not. If you would read the file format specification of zip files than you would know that after the LocallFileHeader the file data is written. Without knowledge of the compressed size it is not possible to read that.
Deployment with Embeddable EJBContainer does not work for me due to this bug.
> Invalid Local file header in ZIP file
> -------------------------------------
>
> Key: JBVFS-202
> URL: https://issues.jboss.org/browse/JBVFS-202
> Project: JBoss VFS
> Issue Type: Bug
> Reporter: Martin Both
> Assignee: Tomaz Cerar
>
> I'm try to use the Embeddable EJBContainer of JBoss EAP 6.4.
> I get a ZipException: invalid CEN header (bad signature)
> JBoss writes an invalid Zip- file in
> JBossEAP6.4\standalone\data\content\58\a481cdfbe31a8ad823b6708f17151589954ac6/content
> The reason is, that the zip file content contains a Local file header with no size for the file data. No Zip-Tool can unzip that and even JBoss cannot read that again.
> Compare the method bufferLocalFileHeader() with the method bufferNextCentralFileHeader() of class org.jboss.vfs,VirtualJarFileInputStream.
> The one wirtes file sizes the other one not. If you would read the file format specification of zip files than you would know that after the LocallFileHeader the file data is written. Without knowledge of the compressed size it is not possible to read that.
> Deployment with Embeddable EJBContainer does not work for me due to this bug.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months