[JBoss JIRA] (JGRP-1902) Simplify failure detection and merge timeout configuration
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1902?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1902:
--------------------------------
Re failure detection protocols: I updated the relevant sections in the manual and added example
Re MERGE3: even with {{max_interval}} being {{5000}}, INFO messages can get dropped, so there is no guarantee that a merge ensues after {{check_interval}} (5000 * 1.6 = 8000) ms
Re FD: the cost of detecting failure of adjacent members is well documented, but I made this even clearer in the manual now.
> Simplify failure detection and merge timeout configuration
> ----------------------------------------------------------
>
> Key: JGRP-1902
> URL: https://issues.jboss.org/browse/JGRP-1902
> Project: JGroups
> Issue Type: Enhancement
> Affects Versions: 3.6
> Reporter: Dan Berindei
> Assignee: Bela Ban
> Priority: Minor
> Fix For: 3.6.2, 4.0
>
>
> FD/FD_ALL/FD_ALL2/FD_SOCK javadoc doesn't give any guidance as to how long it would take to detect a leaving member. MERGE2/MERGE3 javadoc also doesn't say how much it would take to detect that the network has healed.
> For an example of how misleading the current settings can be, I have seen MERGE3 take more than 20s to merge two partitions with min_interval=1000 and max_interval=5000. FD also detects a leaver after {{timeout * max_tries}} in the best case, and twice that if 2 consecutive nodes (in the members list) leave at the same time.
> The maximum time it takes to detect a leaver is of particular interest to Infinispan users, because Infinispan is supposed to protect against nodes leaving. But if the users don't configure a high enough RPC timeout in Infinispan, we don't get to detect the node leaving.
> Ideally, the user should be able to specify a maximum detection time, and the protocol should adjust the existing settings to meet that (most of the time).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFCORE-547) Unable to overlay resource in subunit/zip resource
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-547?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski updated WFCORE-547:
--------------------------------------
Summary: Unable to overlay resource in subunit/zip resource (was: Unable to overlay resource in subunit)
> Unable to overlay resource in subunit/zip resource
> --------------------------------------------------
>
> 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
>
> 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.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFCORE-547) Unable to overlay resource in subunit/zip/jar file
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-547?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski updated WFCORE-547:
--------------------------------------
Summary: Unable to overlay resource in subunit/zip/jar file (was: Unable to overlay resource in subunit/zip resource)
> 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
>
> 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.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFCORE-547) Unable to overlay resource in subunit
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-547?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski updated WFCORE-547:
--------------------------------------
Description:
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'.
was:
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 the whole operation will result always 'false' for any path, causing error described as root of this JIRA.
> Unable to overlay resource in subunit
> -------------------------------------
>
> 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
>
> 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.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFCORE-547) Unable to overlay resource in subunit
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-547?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski reassigned WFCORE-547:
-----------------------------------------
Assignee: Stuart Douglas (was: Bartosz Baranowski)
> Unable to overlay resource in subunit
> -------------------------------------
>
> 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
>
> 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 the whole operation will result always 'false' for any path, causing error described as root of this JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFCORE-547) Unable to overlay resource in subunit
by Bartosz Baranowski (JIRA)
Bartosz Baranowski created WFCORE-547:
-----------------------------------------
Summary: Unable to overlay resource in subunit
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: Jason Greene
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 the whole operation will result always 'false' for any path, causing error described as root of this JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFCORE-547) Unable to overlay resource in subunit
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/WFCORE-547?page=com.atlassian.jira.plugin... ]
Bartosz Baranowski reassigned WFCORE-547:
-----------------------------------------
Assignee: Bartosz Baranowski (was: Jason Greene)
> Unable to overlay resource in subunit
> -------------------------------------
>
> 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: Bartosz Baranowski
>
> 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 the whole operation will result always 'false' for any path, causing error described as root of this JIRA.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4354) EJBs can't inherit a JDK8 default method
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-4354?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf commented on WFLY-4354:
-------------------------------------
The check should be:
{code:Method.java}
public boolean isDefault() {
// Default methods are public non-abstract instance methods
// declared in an interface.
return ((getModifiers() & (Modifier.ABSTRACT | Modifier.PUBLIC | Modifier.STATIC)) ==
Modifier.PUBLIC) && getDeclaringClass().isInterface();
}
{code}
I wonder whether we should have a pluggable SPI for Java 8 features.
> EJBs can't inherit a JDK8 default method
> ----------------------------------------
>
> Key: WFLY-4354
> URL: https://issues.jboss.org/browse/WFLY-4354
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Jan Martiska
> Assignee: David Lloyd
> Attachments: defaultmethodejb.jar
>
>
> If an EJB bean inherits a default method from an interface and doesn't override it, attempt to call this method fails with:
> {noformat}
> org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
> {noformat}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months
[JBoss JIRA] (WFLY-4331) EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
by Carlo de Wolf (JIRA)
[ https://issues.jboss.org/browse/WFLY-4331?page=com.atlassian.jira.plugin.... ]
Carlo de Wolf reassigned WFLY-4331:
-----------------------------------
Assignee: Brad Maxwell (was: David Lloyd)
> EJB Asynchronous pass POJO by reference leading to ClassCastException errors in remote invocations
> --------------------------------------------------------------------------------------------------
>
> Key: WFLY-4331
> URL: https://issues.jboss.org/browse/WFLY-4331
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Brad Maxwell
> Assignee: Brad Maxwell
> Fix For: 9.0.0.Beta1
>
>
> When invoking EJB asynchronous in different deployments and returning a POJO object, which will be retrieved using future.get, we have ClassCastException error.
> {code}
> 12:53:50,147 ERROR [io.undertow.request] (default task-2) UT005023: Exception handling request to /testejb-web/async: java.lang.ClassCastException: rh.test.ReturnObject cannot be cast to rh.test.ReturnObject
> at rh.test.AsyncServlet.doGet(AsyncServlet.java:29) [classes:]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:687) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:56) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:45) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:61) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:70) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:259) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:246) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:75) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:165) [undertow-servlet-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:197) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:737) [undertow-core-1.1.0.Beta7.jar:1.1.0.Beta7]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_51]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_51]
> at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_51]
> {code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 5 months