[JBoss JIRA] (WFCORE-547) Unable to overlay resource in subunit/zip/jar file
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-547?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-547:
------------------------------------------------
Vladimir Dosoudil <dosoudil(a)redhat.com> changed the Status of [bug 1147352|https://bugzilla.redhat.com/show_bug.cgi?id=1147352] from MODIFIED to ON_QA
> Unable to overlay resource in subunit/zip/jar file
> --------------------------------------------------
>
> Key: WFCORE-547
> URL: https://issues.jboss.org/browse/WFCORE-547
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.0.0.Alpha18
> Reporter: Bartosz Baranowski
> Assignee: Stuart Douglas
> Fix For: 1.0.0.Beta1
>
>
> It is possible to overlay resource directly in deployed jar, however, same resource can not be properly overlayed if said jar is deployed as part of ear ( possibly war as well ).
> Example:
> jar (xxx.jar):
> /org/test/ejb/EJBImpl.class
> /org/test/ejb/resourceToOverlya.txt
> ear(yyy.ear) - war seems to be the subject of this as well
> /xxx.jar
> Overlay #1( over jar)
> overlay target: xxx.jar/org/test/ejb/resourceToOverlya.txt
> Result: proper deployment(EJB is deployed), resource has been overlayed
> Overlay #2( over jar inside ear )
> overlay target: org/test/ejb/resourceToOverlya.txt
> Result: bad deployment, no EJB deployed, overlay target has been overlayed
> Reason of such outcome is that VFS.exists() does not recognize JavaZipFileSystem$ZipNode/Entry as zipped archive and does not dive into children.
> So what happens in here is as follows. When EAR is deployed OverlayProcessor kicks in at:
> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
> For this example ear/jar pair, first pair of values:
> mountPoint: /content/yyy.ear/xxx.jar/org/test/ejb/resourceToOverlya.txt
> parent: /content/yyy.ear/xxx.jar/org/test/ejb
> Outcome of exists() call == false, should be true.
> this will iterate up to parent == /content/yyy.ear/xxx.jar
> At this point, 'createParents' contain some entries and
> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
> will create tmp/virtual mounts for:
> - /content/yyy.ear/xxx.jar/org/test/ejb
> - /content/yyy.ear/xxx.jar/org/test
> - /content/yyy.ear/xxx.jar/org
> What it will essentially do is create overlay for whole 'org' package! The VirtualFile.getChildren() will return tmp mounted VirtualFile for 'org' entry: https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/...
> There is part of code which should remove 'submount' if there is directory entry: https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/... however ( if I remember correctly) 'org' tmp mount ends up twice in 'submounts'
> When VirtualFile.getChildren is called for 'this' == /content/yyy.ear/xxx.jar ( in this case it is properly removed) and when 'this' == /content/yyy.ear/xxx.jar/org - in which case it derails getChildren and diverts into tmp mount.
> Now about https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/...
> What happens here, for ear deployment - it dives recursively into 'find' until 'target' is equal to '/content/yyy.ear/xxx.jar' at this target.getParent() == 'mountPoint' == '/content/yyy.ear'.
> At this point 'find' will get result ZipNode == /content/yyy.ear and fetch child 'xxx.jar' and pop back up one notch in the call stack. However the 'xxx.jar' entry does not have any children, hence there is no way to fetch next child in line 'org'.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6552) NPE when absolute ordering is used and a web fragment is missing
by Łukasz Rekucki (JIRA)
Łukasz Rekucki created WFLY-6552:
------------------------------------
Summary: NPE when absolute ordering is used and a web fragment is missing
Key: WFLY-6552
URL: https://issues.jboss.org/browse/WFLY-6552
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 10.0.0.Final
Reporter: Łukasz Rekucki
Assignee: Stuart Douglas
{code}
PARSE: WFLYSRV0153: Failed to process phase PARSE of deployment "****.war"
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:163) [wildfly-server-1.0.2.Final.jar:1.0.2.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881) [jboss-msc-1.2.6.Final.jar:1.2.6.Final]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) [rt.jar:1.8.0_66]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) [rt.jar:1.8.0_66]
at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_66]
Caused by: java.lang.IndexOutOfBoundsException: Index: 4, Size: 2
at java.util.LinkedList.checkPositionIndex(LinkedList.java:560) [rt.jar:1.8.0_66]
at java.util.LinkedList.addAll(LinkedList.java:406) [rt.jar:1.8.0_66]
at org.wildfly.extension.undertow.deployment.WarMetaDataProcessor.deploy(WarMetaDataProcessor.java:206)
at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:156) [wildfly-server-1.0.2.Final.jar:1.0.2.Final]
... 5 more
{code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFLY-6540) Batch thread pool keepAlive setting seems to be ignored
by Martin Kouba (JIRA)
[ https://issues.jboss.org/browse/WFLY-6540?page=com.atlassian.jira.plugin.... ]
Martin Kouba commented on WFLY-6540:
------------------------------------
bq. I've sent a PR to fix the bug in jboss-threads...
Thanks!
bq. This is fairly common behavior for thread pools...
Yes, but the thread pool used by batch subsystem is using a fixed number of threads, right?
bq. Maybe in some ways it doesn't make sense to allow the keep-alive timeout to be configured in unbounded queues...
Yes, this should be clarified. For me the {{UnboundedQueueThreadPoolService}} is a WFLY variant of {{java.util.concurrent.Executors.newFixedThreadPool(int)}}.
> Batch thread pool keepAlive setting seems to be ignored
> -------------------------------------------------------
>
> Key: WFLY-6540
> URL: https://issues.jboss.org/browse/WFLY-6540
> Project: WildFly
> Issue Type: Bug
> Components: Batch
> Affects Versions: 10.0.0.Final
> Reporter: Martin Kouba
> Assignee: James Perkins
>
> Maybe I'm missing something but although the default _keepAlive_ is set to 30 seconds, the threads seem to run indefinitely - see also steps to reproduce.
> Snippet from the default config file:
> {code}
> <thread-pool name="batch">
> <max-threads count="10"/>
> <keepalive-time time="30" unit="seconds"/>
> </thread-pool>
> {code}
> Anyway, the {{UnboundedQueueThreadPoolService}}, or the underlying {{JBossThreadPoolExecutor}} respectively, used by the Batch subsystem is using the same {{corePoolSize}} and {{maximumPoolSize}} and it seems the core threads are not allowed to time out, i.e. {{org.jboss.threads.JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} is not used.
> Moreover, a {{JBossThreadPoolExecutor.setAllowCoreThreadTimeout(boolean)}} invocation would probably result in an infinite loop:
> {code}
> public void setAllowCoreThreadTimeout(final boolean allow) {
> setAllowCoreThreadTimeout(allow);
> }
> {code}
> should be replaced with:
> {code}
> public void setAllowCoreThreadTimeout(final boolean allow) {
> allowCoreThreadTimeOut(allow);
> }
> {code}
> Given that {{JBossThreadPoolExecutor}} is used by more subsystems this issue may affect other subsystems as well.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2041) Getting Socketexception during cluster communication
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-2041?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-2041:
--------------------------------
https://developer.jboss.org/wiki/Support
> Getting Socketexception during cluster communication
> ----------------------------------------------------
>
> Key: JGRP-2041
> URL: https://issues.jboss.org/browse/JGRP-2041
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.5.2
> Environment: RHEL
> Reporter: Rohit Singh
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: jetty.log.D20160315.T074324.zip, jgroups_cluster.properties
>
>
> We faced issues during our cluster communication which is based on JGroup implementation.
> We got below errors in logs. JGroup does not even put full stacktrace of the SocketException.
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (JGRP-2041) Getting Socketexception during cluster communication
by Rohit Singh (JIRA)
[ https://issues.jboss.org/browse/JGRP-2041?page=com.atlassian.jira.plugin.... ]
Rohit Singh commented on JGRP-2041:
-----------------------------------
Hi Bela,
Do you need anything else to proceed on this issue ?
Can you please elaborate more on what you meant when you said "Also, I don't support older versions (such as 2.5.2) on a community basis." ?
Which version onwards you will be able to provide support ?
Whats the difference between normal support and what you mentioned as "on a community basis" ?
> Getting Socketexception during cluster communication
> ----------------------------------------------------
>
> Key: JGRP-2041
> URL: https://issues.jboss.org/browse/JGRP-2041
> Project: JGroups
> Issue Type: Bug
> Affects Versions: 2.5.2
> Environment: RHEL
> Reporter: Rohit Singh
> Assignee: Bela Ban
> Fix For: 4.0
>
> Attachments: jetty.log.D20160315.T074324.zip, jgroups_cluster.properties
>
>
> We faced issues during our cluster communication which is based on JGroup implementation.
> We got below errors in logs. JGroup does not even put full stacktrace of the SocketException.
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] ERROR org.jgroups.blocks.ConnectionTable - exception is java.net.SocketException: Socket closed
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
> [2016-03-15 08:00:29.523] ALL 000000000000 GLOBAL_SCOPE 202575944 [ConnectionTable.Connection.Sender local_addr=172.27.105.93:11060 [172.27.105.93:34535 - 172.27.105.94:11060]] DEBUG org.jgroups.blocks.ConnectionTable - ConnectionTable.Connection.Sender thread terminated
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-1502) RBAC: The two kinds of non-addressability
by Ladislav Thon (JIRA)
Ladislav Thon created WFCORE-1502:
-------------------------------------
Summary: RBAC: The two kinds of non-addressability
Key: WFCORE-1502
URL: https://issues.jboss.org/browse/WFCORE-1502
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 2.1.0.Final
Reporter: Ladislav Thon
Assignee: Brian Stansberry
Ever since we introduced RBAC in WildFly / EAP, we had this shortcut in place that we were documenting in EAP Release Notes:
bq. Some resources are non-addressable to server-group and host scoped roles in order to provide a simplified view of the management model to improve usability. This is distinct from resources that are non-addressable to protect sensitive data.
I think that this shortcut is in place mainly because HAL can't cope with addressable but non-readable resources, but there might be other reasons. In any case, I figured I should finally file an upstream JIRA so that I don't have to bug Brian all the time if this has changed :-)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-761) Not possible to overlay non existing file in WAR
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-761?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-761:
------------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1147352|https://bugzilla.redhat.com/show_bug.cgi?id=1147352] from POST to MODIFIED
> Not possible to overlay non existing file in WAR
> ------------------------------------------------
>
> Key: WFCORE-761
> URL: https://issues.jboss.org/browse/WFCORE-761
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Reporter: Bartosz Baranowski
> Assignee: Dimitris Andreadis
> Priority: Critical
>
> It is either bug in how deployments are treated or how overlay/vfs work.
> Steps to reproduce:
> 1. deploy undexploded war with jar inside
> 2. add overlay that will add non existing file in jar
> Result: exception:
> Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt
> Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}}
> at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67)
> at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37)
> at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76)
> at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67)
> Expectation:
> should work. It actually does work, if war is really exploded or
> 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899...
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years
[JBoss JIRA] (WFCORE-547) Unable to overlay resource in subunit/zip/jar file
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFCORE-547?page=com.atlassian.jira.plugin... ]
RH Bugzilla Integration commented on WFCORE-547:
------------------------------------------------
baranowb <bbaranow(a)redhat.com> changed the Status of [bug 1147352|https://bugzilla.redhat.com/show_bug.cgi?id=1147352] from POST to MODIFIED
> Unable to overlay resource in subunit/zip/jar file
> --------------------------------------------------
>
> Key: WFCORE-547
> URL: https://issues.jboss.org/browse/WFCORE-547
> Project: WildFly Core
> Issue Type: Bug
> Components: Server
> Affects Versions: 1.0.0.Alpha18
> Reporter: Bartosz Baranowski
> Assignee: Stuart Douglas
> Fix For: 1.0.0.Beta1
>
>
> It is possible to overlay resource directly in deployed jar, however, same resource can not be properly overlayed if said jar is deployed as part of ear ( possibly war as well ).
> Example:
> jar (xxx.jar):
> /org/test/ejb/EJBImpl.class
> /org/test/ejb/resourceToOverlya.txt
> ear(yyy.ear) - war seems to be the subject of this as well
> /xxx.jar
> Overlay #1( over jar)
> overlay target: xxx.jar/org/test/ejb/resourceToOverlya.txt
> Result: proper deployment(EJB is deployed), resource has been overlayed
> Overlay #2( over jar inside ear )
> overlay target: org/test/ejb/resourceToOverlya.txt
> Result: bad deployment, no EJB deployed, overlay target has been overlayed
> Reason of such outcome is that VFS.exists() does not recognize JavaZipFileSystem$ZipNode/Entry as zipped archive and does not dive into children.
> So what happens in here is as follows. When EAR is deployed OverlayProcessor kicks in at:
> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
> For this example ear/jar pair, first pair of values:
> mountPoint: /content/yyy.ear/xxx.jar/org/test/ejb/resourceToOverlya.txt
> parent: /content/yyy.ear/xxx.jar/org/test/ejb
> Outcome of exists() call == false, should be true.
> this will iterate up to parent == /content/yyy.ear/xxx.jar
> At this point, 'createParents' contain some entries and
> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/...
> will create tmp/virtual mounts for:
> - /content/yyy.ear/xxx.jar/org/test/ejb
> - /content/yyy.ear/xxx.jar/org/test
> - /content/yyy.ear/xxx.jar/org
> What it will essentially do is create overlay for whole 'org' package! The VirtualFile.getChildren() will return tmp mounted VirtualFile for 'org' entry: https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/...
> There is part of code which should remove 'submount' if there is directory entry: https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/... however ( if I remember correctly) 'org' tmp mount ends up twice in 'submounts'
> When VirtualFile.getChildren is called for 'this' == /content/yyy.ear/xxx.jar ( in this case it is properly removed) and when 'this' == /content/yyy.ear/xxx.jar/org - in which case it derails getChildren and diverts into tmp mount.
> Now about https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/...
> What happens here, for ear deployment - it dives recursively into 'find' until 'target' is equal to '/content/yyy.ear/xxx.jar' at this target.getParent() == 'mountPoint' == '/content/yyy.ear'.
> At this point 'find' will get result ZipNode == /content/yyy.ear and fetch child 'xxx.jar' and pop back up one notch in the call stack. However the 'xxx.jar' entry does not have any children, hence there is no way to fetch next child in line 'org'.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years