From ropalka at redhat.com Tue Jan 5 18:32:55 2016 From: ropalka at redhat.com (Richard Opalka) Date: Wed, 6 Jan 2016 00:32:55 +0100 Subject: [wildfly-dev] Do we support overlay for files in jar of war of ear? In-Reply-To: References: Message-ID: <568C52A7.401@redhat.com> Hi Lin, our current 'Overlay feature" implementation is quite limited to be honest. It is not possible to introduce new files inside jar inside war that is in ear. The only exception is if war is exploded inside ear. Further more it is not possible to overlay static content inside wars (although Wildfly documentation for overlays feature promises that). The reason is every war is exploded to temporary location during the deploy process and org.wildfly.extension.undertow.deployment.ServletResourceManager obtains physical location of that exploded archive and passes it to FileResourceManager / PathResourceManager in its constructor. This at first sight innocent hack bypasses all VFS modifications. So although you would mount war static files properly via overlays, those overlays will be completely ignored. The only exception are deployment descriptors, which are processed during the deployment phase. Note: Don't get confused with overlays in ServletResourceManager. Those are Undertow specific and have nothing to do with WildfFly deployment overlays. In order to fix your concrete problem (i.e. adding new file inside jar in war in ear) I'd guess fixing just DeploymentOverlay processors will be insufficient. With high probability you'll need to revisit also WarDeploymentStructureProcessor. Good news is 'Wildfly Deployment Overlays' should work without any limitations in upcomming Wildfly 11. There's a PR eliminating Wildfly dependency on JBoss VFS: https://github.com/wildfly/wildfly-core/pull/1261 The PR incorporates 'Deployment Overlay' complete rewrite with no limitations current implementation has. On 12/23/2015 05:17 PM, Lin Gao wrote: > Hi, > > I am working on https://issues.jboss.org/browse/WFCORE-761 for a > while, and I am stuck in the case of overlaying files in jar of war of > ear. > > I want to know that do we support overlay for files in jar of war > of ear? like: xx.ear/yy.war/zz.jar/META-INF/config.properties > > DeploymentOverlayDeploymentUnitProcessor.java[1] and > DeferredDeploymentOverlayDeploymentUnitProcessor.java[2] are classes > to handle the deployment overlay, but in this case, the jar of war of > ear does not get mounted yet, which leads > to DeferredDeploymentOverlayDeploymentUnitProcessor.handleEntryWithFileParent() > method is called, which just prints the error message. > > The way to fix it maybe mount the jar(VFS.mountZip) beforehand, but > it is specific to the case of ear/war/jar, and these 2 classes are > more generic(they are in wildfly-core, no ee nor undertow extension), > so where this can be fixed? > > [1] > https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeploymentOverlayDeploymentUnitProcessor.java > [2] > https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeferredDeploymentOverlayDeploymentUnitProcessor.java > > Best Regards > -- > Lin Gao > JBoss Software Engineer > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Richard Opalka Principal Software Engineer JBoss by Red Hat Mobile: +420 731 186 942 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160106/6bec6b90/attachment.html From lgao at redhat.com Wed Jan 6 01:19:34 2016 From: lgao at redhat.com (Lin Gao) Date: Wed, 6 Jan 2016 01:19:34 -0500 (EST) Subject: [wildfly-dev] Do we support overlay for files in jar of war of ear? In-Reply-To: <568C52A7.401@redhat.com> References: <568C52A7.401@redhat.com> Message-ID: <505168911.5516148.1452061174053.JavaMail.zimbra@redhat.com> Hi Richard, Thank you for the reply. :-) > our current 'Overlay feature" implementation is quite limited to be honest. > It is not possible to introduce new files inside jar inside war that is in > ear. > The only exception is if war is exploded inside ear. I don't think there is any difference on exploded or not of war from structure POV(in case of war inside ear), EarStructureProcessor[1] will explode the war if the war is a file inside ear, and will copy it to temporary directory if it is a directory inside ear. > Further more it is not possible to overlay static content inside wars > (although Wildfly documentation for overlays feature promises that). > The reason is every war is exploded to temporary location during > the deploy process and > > org.wildfly.extension.undertow.deployment.ServletResourceManager > > obtains physical location of that exploded archive and passes it to > FileResourceManager / PathResourceManager in its constructor. > > This at first sight innocent hack bypasses all VFS modifications. > So although you would mount war static files properly via overlays, > those overlays will be completely ignored. > The only exception are deployment descriptors, > which are processed during the deployment phase. > > Note: Don't get confused with overlays in ServletResourceManager. > Those are Undertow specific and have nothing to do with WildfFly deployment > overlays. Actually it can overlay static content within WAR, the DeploymentOverlayDeploymentUnitProcessor[2] will replace the file in the exploded temporary directory with the content user wants to overlay. > In order to fix your concrete problem (i.e. adding new file inside > jar in war in ear) I'd guess fixing just DeploymentOverlay processors will be > insufficient. > With high probability you'll need to revisit also > WarDeploymentStructureProcessor. Yeah, I thought it too, but it will require WarStructureDeploymentProcessor to access its parent DeploymentUnit's attachment for deferred overlays, even deferred after DeferredDeploymentOverlayDeploymentUnitProcessor for the top level EAR deployment, I don't know whether it is correct way to do this. :-) > Good news is 'Wildfly Deployment Overlays' should work without any > limitations in > upcomming Wildfly 11. There's a PR eliminating Wildfly dependency on JBoss > VFS: > > https://github.com/wildfly/wildfly-core/pull/1261 > > The PR incorporates 'Deployment Overlay' complete rewrite with no limitations > current implementation has. Hope it can resolve all overlay related issues. :-) Since the PR to remove VFS is up, I think my PRs[3] won't get merged any way. But 2 downstream product issues[4] depend on this, so I will keep the my PRs open, if we can leave the overlay for files in jar of war inside ear, could you please review the PRs in [3] to see whether it is OK? Thanks!~ :-) [1] https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/structure/EarStructureProcessor.java#L271 [2] https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeploymentOverlayDeploymentUnitProcessor.java#L111-L112 [3] https://github.com/wildfly/wildfly-core/pull/1332 and https://github.com/wildfly/wildfly/pull/8528 [4] https://bugzilla.redhat.com/show_bug.cgi?id=1147352 and https://issues.jboss.org/browse/JBEAP-2491 Best Regards -- Lin Gao JBoss Software Engineer > On 12/23/2015 05:17 PM, Lin Gao wrote: > > > > Hi, > > I am working on https://issues.jboss.org/browse/WFCORE-761 for a while, and I > am stuck in the case of overlaying files in jar of war of ear. > > I want to know that do we support overlay for files in jar of war of ear? > like: xx.ear/yy.war/zz.jar/META-INF/config.properties > > DeploymentOverlayDeploymentUnitProcessor.java[1] and > DeferredDeploymentOverlayDeploymentUnitProcessor.java[2] are classes to > handle the deployment overlay, but in this case, the jar of war of ear does > not get mounted yet, which leads to > DeferredDeploymentOverlayDeploymentUnitProcessor.handleEntryWithFileParent() > method is called, which just prints the error message. > > The way to fix it maybe mount the jar(VFS.mountZip) beforehand, but it is > specific to the case of ear/war/jar, and these 2 classes are more > generic(they are in wildfly-core, no ee nor undertow extension), so where > this can be fixed? > > [1] > https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeploymentOverlayDeploymentUnitProcessor.java > [2] > https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeferredDeploymentOverlayDeploymentUnitProcessor.java > > Best Regards > -- > Lin Gao > JBoss Software Engineer > > > > _______________________________________________ > wildfly-dev mailing list wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Richard Opalka > Principal Software Engineer > JBoss by Red Hat > Mobile: +420 731 186 942 > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From ropalka at redhat.com Wed Jan 6 17:21:39 2016 From: ropalka at redhat.com (Richard Opalka) Date: Wed, 6 Jan 2016 23:21:39 +0100 Subject: [wildfly-dev] Do we support overlay for files in jar of war of ear? In-Reply-To: <505168911.5516148.1452061174053.JavaMail.zimbra@redhat.com> References: <568C52A7.401@redhat.com> <505168911.5516148.1452061174053.JavaMail.zimbra@redhat.com> Message-ID: <568D9373.6040207@redhat.com> Hi Lin, On 01/06/2016 07:19 AM, Lin Gao wrote: > Hi Richard, > > Thank you for the reply. :-) > >> our current 'Overlay feature" implementation is quite limited to be honest. >> It is not possible to introduce new files inside jar inside war that is in >> ear. >> The only exception is if war is exploded inside ear. > I don't think there is any difference on exploded or not of war from structure > POV(in case of war inside ear), EarStructureProcessor[1] will explode the war if > the war is a file inside ear, and will copy it to temporary directory if it is a > directory inside ear. There is a difference if war is packaged or exploded in ear from overlays implementation point of view. And I was talking about current overlay implementation. What it does and what it doesn't. Attached is a simple example you can use to reproduce the problem on Wildfly master: * foo.ear //contains packaged app.war inside * mixed1-foo.ear //contains exploded app.war inside * index.html // overlayed index.html * overlay.jsp // overlay for non existing JSP file Execute the following commands in jboss-cli.sh: Let's do working example first: # deploying mixed1-foo.ear plus overlays [standalone at localhost:9990 /] deploy /manual-overlay-tests/original-archives/mixed1-foo.ear [standalone at localhost:9990 /] deployment-overlay add --name=staticContentOverlay --content=/app.war/overlay.jsp=/manual-overlay-tests/overlays/overlay.jsp,/app.war/index.html=/manual-overlay-tests/overlays/index.html --deployments=*ear --redeploy-affected and open new browser window for URL http://localhost:8080/app You will see overlayed index.html. Further more overlay.jsp link will work. # remove overlay and mixed1-foo.ear deployment [standalone at localhost:9990 /] deployment-overlay remove --name=staticContentOverlay --redeploy-affected [standalone at localhost:9990 /] undeploy mixed1-foo.ear And second one, not working example: # deploying foo.ear plus overlays [standalone at localhost:9990 /] deploy /manual-overlay-tests/original-archives/foo.ear [standalone at localhost:9990 /] deployment-overlay add --name=staticContentOverlay --content=/app.war/overlay.jsp=/manual-overlay-tests/overlays/overlay.jsp,/app.war/index.html=/manual-overlay-tests/overlays/index.html --deployments=*ear --redeploy-affected and open new browser window for url http://localhost:8080/app (be aware of browser caches). You will see original index.html. And overlay.jsp link is will be unfunctional. # remove overlay and foo.ear deployment [standalone at localhost:9990 /] deployment-overlay remove --name=staticContentOverlay --redeploy-affected [standalone at localhost:9990 /] undeploy foo.ear >> Further more it is not possible to overlay static content inside wars >> (although Wildfly documentation for overlays feature promises that). >> The reason is every war is exploded to temporary location during >> the deploy process and >> >> org.wildfly.extension.undertow.deployment.ServletResourceManager >> >> obtains physical location of that exploded archive and passes it to >> FileResourceManager / PathResourceManager in its constructor. >> >> This at first sight innocent hack bypasses all VFS modifications. >> So although you would mount war static files properly via overlays, >> those overlays will be completely ignored. >> The only exception are deployment descriptors, >> which are processed during the deployment phase. >> >> Note: Don't get confused with overlays in ServletResourceManager. >> Those are Undertow specific and have nothing to do with WildfFly deployment >> overlays. > Actually it can overlay static content within WAR, the DeploymentOverlayDeploymentUnitProcessor[2] > will replace the file in the exploded temporary directory with the content user wants to overlay. Yes, but it will work only for exploded wars in ears, see example above. Not for packaged wars. >> In order to fix your concrete problem (i.e. adding new file inside >> jar in war in ear) I'd guess fixing just DeploymentOverlay processors will be >> insufficient. >> With high probability you'll need to revisit also >> WarDeploymentStructureProcessor. > Yeah, I thought it too, but it will require WarStructureDeploymentProcessor to access its parent > DeploymentUnit's attachment for deferred overlays, even deferred after > DeferredDeploymentOverlayDeploymentUnitProcessor for the top level EAR deployment, I don't > know whether it is correct way to do this. :-) This wouldn't be proper way to fix it because DeferredDeploymentOverlayDeploymentUnitProcessor must be the last STRUCTURE processor in the chain. There's deploymentUnit.getAttachment(Attachments.DEPLOYMENT_OVERLAY_LOCATIONS) available for your convenience. You can use it in EAR or WAR structure processors. > >> Good news is 'Wildfly Deployment Overlays' should work without any >> limitations in >> upcomming Wildfly 11. There's a PR eliminating Wildfly dependency on JBoss >> VFS: >> >> https://github.com/wildfly/wildfly-core/pull/1261 >> >> The PR incorporates 'Deployment Overlay' complete rewrite with no limitations >> current implementation has. > Hope it can resolve all overlay related issues. :-) Definitely, because of new simplified overlays rewrite. > > Since the PR to remove VFS is up, I think my PRs[3] won't get merged any way. I reviewed both PRs. The one providing test cases should be merged to Wildfly master because of the enhanced test coverage. The second introducing the wars hot fix looks good to me as well. Anyway there are many other overlay issues still remaining :( > > But 2 downstream product issues[4] depend on this, so I will keep the my PRs open, > if we can leave the overlay for files in jar of war inside ear, could you please > review the PRs in [3] to see whether it is OK? Thanks!~ :-) PRs reviewed, I'm fine with them. > > [1] https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/structure/EarStructureProcessor.java#L271 > [2] https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeploymentOverlayDeploymentUnitProcessor.java#L111-L112 > [3] https://github.com/wildfly/wildfly-core/pull/1332 and https://github.com/wildfly/wildfly/pull/8528 > [4] https://bugzilla.redhat.com/show_bug.cgi?id=1147352 and https://issues.jboss.org/browse/JBEAP-2491 > > Best Regards > -- > Lin Gao > JBoss Software Engineer > > >> On 12/23/2015 05:17 PM, Lin Gao wrote: >> >> >> >> Hi, >> >> I am working on https://issues.jboss.org/browse/WFCORE-761 for a while, and I >> am stuck in the case of overlaying files in jar of war of ear. >> >> I want to know that do we support overlay for files in jar of war of ear? >> like: xx.ear/yy.war/zz.jar/META-INF/config.properties >> >> DeploymentOverlayDeploymentUnitProcessor.java[1] and >> DeferredDeploymentOverlayDeploymentUnitProcessor.java[2] are classes to >> handle the deployment overlay, but in this case, the jar of war of ear does >> not get mounted yet, which leads to >> DeferredDeploymentOverlayDeploymentUnitProcessor.handleEntryWithFileParent() >> method is called, which just prints the error message. >> >> The way to fix it maybe mount the jar(VFS.mountZip) beforehand, but it is >> specific to the case of ear/war/jar, and these 2 classes are more >> generic(they are in wildfly-core, no ee nor undertow extension), so where >> this can be fixed? >> >> [1] >> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeploymentOverlayDeploymentUnitProcessor.java >> [2] >> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeferredDeploymentOverlayDeploymentUnitProcessor.java >> >> Best Regards >> -- >> Lin Gao >> JBoss Software Engineer >> >> >> >> _______________________________________________ >> wildfly-dev mailing list wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> -- >> Richard Opalka >> Principal Software Engineer >> JBoss by Red Hat >> Mobile: +420 731 186 942 >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Richard Opalka Principal Software Engineer JBoss by Red Hat Mobile: +420 731 186 942 -------------- next part -------------- A non-text attachment was scrubbed... Name: foo.ear Type: application/octet-stream Size: 5410 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160106/afe8cc47/attachment-0002.obj -------------- next part -------------- A non-text attachment was scrubbed... Name: mixed1-foo.ear Type: application/octet-stream Size: 6674 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160106/afe8cc47/attachment-0003.obj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160106/afe8cc47/attachment-0002.html -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160106/afe8cc47/attachment-0003.html From lgao at redhat.com Thu Jan 7 02:57:18 2016 From: lgao at redhat.com (Lin Gao) Date: Thu, 7 Jan 2016 02:57:18 -0500 (EST) Subject: [wildfly-dev] Do we support overlay for files in jar of war of ear? In-Reply-To: <568D9373.6040207@redhat.com> References: <568C52A7.401@redhat.com> <505168911.5516148.1452061174053.JavaMail.zimbra@redhat.com> <568D9373.6040207@redhat.com> Message-ID: <1352472194.6105764.1452153438770.JavaMail.zimbra@redhat.com> Hi Richard, > >> our current 'Overlay feature" implementation is quite limited to be > >> honest. > >> It is not possible to introduce new files inside jar inside war that is in > >> ear. > >> The only exception is if war is exploded inside ear. > > I don't think there is any difference on exploded or not of war from > > structure > > POV(in case of war inside ear), EarStructureProcessor[1] will explode the > > war if > > the war is a file inside ear, and will copy it to temporary directory if it > > is a > > directory inside ear. > There is a difference if war is packaged or exploded in ear from > overlays implementation point of view. > And I was talking about current overlay implementation. What it does and > what it doesn't. Ah, yes, I see your point now. :-) I tested overlay static files for packaged war inside ear, it worked because I used the one with the hot fix applied. :-) > Attached is a simple example you can use to reproduce the problem on > Wildfly master: > > * foo.ear //contains packaged app.war inside > * mixed1-foo.ear //contains exploded app.war inside > * index.html // overlayed index.html > * overlay.jsp // overlay for non existing JSP file > > Execute the following commands in jboss-cli.sh: > > Let's do working example first: > > # deploying mixed1-foo.ear plus overlays > [standalone at localhost:9990 /] deploy > /manual-overlay-tests/original-archives/mixed1-foo.ear > [standalone at localhost:9990 /] deployment-overlay add > --name=staticContentOverlay > --content=/app.war/overlay.jsp=/manual-overlay-tests/overlays/overlay.jsp,/app.war/index.html=/manual-overlay-tests/overlays/index.html > --deployments=*ear --redeploy-affected > > and open new browser window for URL http://localhost:8080/app > You will see overlayed index.html. Further more overlay.jsp link will work. > > # remove overlay and mixed1-foo.ear deployment > [standalone at localhost:9990 /] deployment-overlay remove > --name=staticContentOverlay --redeploy-affected > [standalone at localhost:9990 /] undeploy mixed1-foo.ear > > And second one, not working example: > > # deploying foo.ear plus overlays > [standalone at localhost:9990 /] deploy > /manual-overlay-tests/original-archives/foo.ear > [standalone at localhost:9990 /] deployment-overlay add > --name=staticContentOverlay > --content=/app.war/overlay.jsp=/manual-overlay-tests/overlays/overlay.jsp,/app.war/index.html=/manual-overlay-tests/overlays/index.html > --deployments=*ear --redeploy-affected > > and open new browser window for url http://localhost:8080/app (be aware > of browser caches). > You will see original index.html. And overlay.jsp link is will be > unfunctional. > > # remove overlay and foo.ear deployment > [standalone at localhost:9990 /] deployment-overlay remove > --name=staticContentOverlay --redeploy-affected > [standalone at localhost:9990 /] undeploy foo.ear I can reproduce the issue using your example on wildfly master, and with my hot fix applied, it works well. :-) > >> Further more it is not possible to overlay static content inside wars > >> (although Wildfly documentation for overlays feature promises that). > >> The reason is every war is exploded to temporary location during > >> the deploy process and > >> > >> org.wildfly.extension.undertow.deployment.ServletResourceManager > >> > >> obtains physical location of that exploded archive and passes it to > >> FileResourceManager / PathResourceManager in its constructor. > >> > >> This at first sight innocent hack bypasses all VFS modifications. > >> So although you would mount war static files properly via overlays, > >> those overlays will be completely ignored. > >> The only exception are deployment descriptors, > >> which are processed during the deployment phase. > >> > >> Note: Don't get confused with overlays in ServletResourceManager. > >> Those are Undertow specific and have nothing to do with WildfFly > >> deployment > >> overlays. > > Actually it can overlay static content within WAR, the > > DeploymentOverlayDeploymentUnitProcessor[2] > > will replace the file in the exploded temporary directory with the content > > user wants to overlay. > > Yes, but it will work only for exploded wars in ears, see example above. > Not for packaged wars. > > >> In order to fix your concrete problem (i.e. adding new file inside > >> jar in war in ear) I'd guess fixing just DeploymentOverlay processors will > >> be > >> insufficient. > >> With high probability you'll need to revisit also > >> WarDeploymentStructureProcessor. > > Yeah, I thought it too, but it will require > > WarStructureDeploymentProcessor to access its parent > > DeploymentUnit's attachment for deferred overlays, even deferred after > > DeferredDeploymentOverlayDeploymentUnitProcessor for the top level EAR > > deployment, I don't > > know whether it is correct way to do this. :-) > This wouldn't be proper way to fix it because > DeferredDeploymentOverlayDeploymentUnitProcessor > must be the last STRUCTURE processor in the chain. > There's > deploymentUnit.getAttachment(Attachments.DEPLOYMENT_OVERLAY_LOCATIONS) > available > for your convenience. You can use it in EAR or WAR structure processors. > > > >> Good news is 'Wildfly Deployment Overlays' should work without any > >> limitations in > >> upcomming Wildfly 11. There's a PR eliminating Wildfly dependency on JBoss > >> VFS: > >> > >> https://github.com/wildfly/wildfly-core/pull/1261 > >> > >> The PR incorporates 'Deployment Overlay' complete rewrite with no > >> limitations > >> current implementation has. > > Hope it can resolve all overlay related issues. :-) > Definitely, because of new simplified overlays rewrite. > > > > Since the PR to remove VFS is up, I think my PRs[3] won't get merged any > > way. > I reviewed both PRs. The one providing test cases should be merged to > Wildfly master > because of the enhanced test coverage. The second introducing the wars > hot fix > looks good to me as well. Anyway there are many other overlay issues > still remaining :( Thank you for the review. :-) I sent another PRs to downstream product repos. > > > > But 2 downstream product issues[4] depend on this, so I will keep the my > > PRs open, > > if we can leave the overlay for files in jar of war inside ear, could you > > please > > review the PRs in [3] to see whether it is OK? Thanks!~ :-) > PRs reviewed, I'm fine with them. Thanks again!~ Best Regards -- Lin Gao Software Engineer JBoss by Red Hat > > [1] > > https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/structure/EarStructureProcessor.java#L271 > > [2] > > https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeploymentOverlayDeploymentUnitProcessor.java#L111-L112 > > [3] https://github.com/wildfly/wildfly-core/pull/1332 and > > https://github.com/wildfly/wildfly/pull/8528 > > [4] https://bugzilla.redhat.com/show_bug.cgi?id=1147352 and > > https://issues.jboss.org/browse/JBEAP-2491 > > > > Best Regards > > -- > > Lin Gao > > JBoss Software Engineer > > > > > >> On 12/23/2015 05:17 PM, Lin Gao wrote: > >> > >> > >> > >> Hi, > >> > >> I am working on https://issues.jboss.org/browse/WFCORE-761 for a while, > >> and I > >> am stuck in the case of overlaying files in jar of war of ear. > >> > >> I want to know that do we support overlay for files in jar of war of ear? > >> like: xx.ear/yy.war/zz.jar/META-INF/config.properties > >> > >> DeploymentOverlayDeploymentUnitProcessor.java[1] and > >> DeferredDeploymentOverlayDeploymentUnitProcessor.java[2] are classes to > >> handle the deployment overlay, but in this case, the jar of war of ear > >> does > >> not get mounted yet, which leads to > >> DeferredDeploymentOverlayDeploymentUnitProcessor.handleEntryWithFileParent() > >> method is called, which just prints the error message. > >> > >> The way to fix it maybe mount the jar(VFS.mountZip) beforehand, but it is > >> specific to the case of ear/war/jar, and these 2 classes are more > >> generic(they are in wildfly-core, no ee nor undertow extension), so where > >> this can be fixed? > >> > >> [1] > >> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeploymentOverlayDeploymentUnitProcessor.java > >> [2] > >> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeferredDeploymentOverlayDeploymentUnitProcessor.java > >> > >> Best Regards > >> -- > >> Lin Gao > >> JBoss Software Engineer > >> > >> > >> > >> _______________________________________________ > >> wildfly-dev mailing list wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > >> > >> -- > >> Richard Opalka > >> Principal Software Engineer > >> JBoss by Red Hat > >> Mobile: +420 731 186 942 > >> > >> _______________________________________________ > >> wildfly-dev mailing list > >> wildfly-dev at lists.jboss.org > >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Richard Opalka > Principal Software Engineer > JBoss by Red Hat > Mobile: +420 731 186 942 > > From ropalka at redhat.com Thu Jan 7 04:28:33 2016 From: ropalka at redhat.com (Richard Opalka) Date: Thu, 7 Jan 2016 10:28:33 +0100 Subject: [wildfly-dev] Do we support overlay for files in jar of war of ear? In-Reply-To: <1352472194.6105764.1452153438770.JavaMail.zimbra@redhat.com> References: <568C52A7.401@redhat.com> <505168911.5516148.1452061174053.JavaMail.zimbra@redhat.com> <568D9373.6040207@redhat.com> <1352472194.6105764.1452153438770.JavaMail.zimbra@redhat.com> Message-ID: <568E2FC1.5030109@redhat.com> Hi Lin, On 01/07/2016 08:57 AM, Lin Gao wrote: > Hi Richard, > >>>> our current 'Overlay feature" implementation is quite limited to be >>>> honest. >>>> It is not possible to introduce new files inside jar inside war that is in >>>> ear. >>>> The only exception is if war is exploded inside ear. >>> I don't think there is any difference on exploded or not of war from >>> structure >>> POV(in case of war inside ear), EarStructureProcessor[1] will explode the >>> war if >>> the war is a file inside ear, and will copy it to temporary directory if it >>> is a >>> directory inside ear. >> There is a difference if war is packaged or exploded in ear from >> overlays implementation point of view. >> And I was talking about current overlay implementation. What it does and >> what it doesn't. > Ah, yes, I see your point now. :-) > > I tested overlay static files for packaged war inside ear, it worked because I > used the one with the hot fix applied. :-) I thought so. > >> Attached is a simple example you can use to reproduce the problem on >> Wildfly master: >> >> * foo.ear //contains packaged app.war inside >> * mixed1-foo.ear //contains exploded app.war inside >> * index.html // overlayed index.html >> * overlay.jsp // overlay for non existing JSP file >> >> Execute the following commands in jboss-cli.sh: >> >> Let's do working example first: >> >> # deploying mixed1-foo.ear plus overlays >> [standalone at localhost:9990 /] deploy >> /manual-overlay-tests/original-archives/mixed1-foo.ear >> [standalone at localhost:9990 /] deployment-overlay add >> --name=staticContentOverlay >> --content=/app.war/overlay.jsp=/manual-overlay-tests/overlays/overlay.jsp,/app.war/index.html=/manual-overlay-tests/overlays/index.html >> --deployments=*ear --redeploy-affected >> >> and open new browser window for URL http://localhost:8080/app >> You will see overlayed index.html. Further more overlay.jsp link will work. >> >> # remove overlay and mixed1-foo.ear deployment >> [standalone at localhost:9990 /] deployment-overlay remove >> --name=staticContentOverlay --redeploy-affected >> [standalone at localhost:9990 /] undeploy mixed1-foo.ear >> >> And second one, not working example: >> >> # deploying foo.ear plus overlays >> [standalone at localhost:9990 /] deploy >> /manual-overlay-tests/original-archives/foo.ear >> [standalone at localhost:9990 /] deployment-overlay add >> --name=staticContentOverlay >> --content=/app.war/overlay.jsp=/manual-overlay-tests/overlays/overlay.jsp,/app.war/index.html=/manual-overlay-tests/overlays/index.html >> --deployments=*ear --redeploy-affected >> >> and open new browser window for url http://localhost:8080/app (be aware >> of browser caches). >> You will see original index.html. And overlay.jsp link is will be >> unfunctional. >> >> # remove overlay and foo.ear deployment >> [standalone at localhost:9990 /] deployment-overlay remove >> --name=staticContentOverlay --redeploy-affected >> [standalone at localhost:9990 /] undeploy foo.ear > I can reproduce the issue using your example on wildfly master, and with my hot fix applied, it works well. :-) > >>>> Further more it is not possible to overlay static content inside wars >>>> (although Wildfly documentation for overlays feature promises that). >>>> The reason is every war is exploded to temporary location during >>>> the deploy process and >>>> >>>> org.wildfly.extension.undertow.deployment.ServletResourceManager >>>> >>>> obtains physical location of that exploded archive and passes it to >>>> FileResourceManager / PathResourceManager in its constructor. >>>> >>>> This at first sight innocent hack bypasses all VFS modifications. >>>> So although you would mount war static files properly via overlays, >>>> those overlays will be completely ignored. >>>> The only exception are deployment descriptors, >>>> which are processed during the deployment phase. >>>> >>>> Note: Don't get confused with overlays in ServletResourceManager. >>>> Those are Undertow specific and have nothing to do with WildfFly >>>> deployment >>>> overlays. >>> Actually it can overlay static content within WAR, the >>> DeploymentOverlayDeploymentUnitProcessor[2] >>> will replace the file in the exploded temporary directory with the content >>> user wants to overlay. >> Yes, but it will work only for exploded wars in ears, see example above. >> Not for packaged wars. >> >>>> In order to fix your concrete problem (i.e. adding new file inside >>>> jar in war in ear) I'd guess fixing just DeploymentOverlay processors will >>>> be >>>> insufficient. >>>> With high probability you'll need to revisit also >>>> WarDeploymentStructureProcessor. >>> Yeah, I thought it too, but it will require >>> WarStructureDeploymentProcessor to access its parent >>> DeploymentUnit's attachment for deferred overlays, even deferred after >>> DeferredDeploymentOverlayDeploymentUnitProcessor for the top level EAR >>> deployment, I don't >>> know whether it is correct way to do this. :-) >> This wouldn't be proper way to fix it because >> DeferredDeploymentOverlayDeploymentUnitProcessor >> must be the last STRUCTURE processor in the chain. >> There's >> deploymentUnit.getAttachment(Attachments.DEPLOYMENT_OVERLAY_LOCATIONS) >> available >> for your convenience. You can use it in EAR or WAR structure processors. >>>> Good news is 'Wildfly Deployment Overlays' should work without any >>>> limitations in >>>> upcomming Wildfly 11. There's a PR eliminating Wildfly dependency on JBoss >>>> VFS: >>>> >>>> https://github.com/wildfly/wildfly-core/pull/1261 >>>> >>>> The PR incorporates 'Deployment Overlay' complete rewrite with no >>>> limitations >>>> current implementation has. >>> Hope it can resolve all overlay related issues. :-) >> Definitely, because of new simplified overlays rewrite. >>> Since the PR to remove VFS is up, I think my PRs[3] won't get merged any >>> way. >> I reviewed both PRs. The one providing test cases should be merged to >> Wildfly master >> because of the enhanced test coverage. The second introducing the wars >> hot fix >> looks good to me as well. Anyway there are many other overlay issues >> still remaining :( > Thank you for the review. :-) I sent another PRs to downstream product repos. > >>> But 2 downstream product issues[4] depend on this, so I will keep the my >>> PRs open, >>> if we can leave the overlay for files in jar of war inside ear, could you >>> please >>> review the PRs in [3] to see whether it is OK? Thanks!~ :-) >> PRs reviewed, I'm fine with them. > Thanks again!~ You are welcome Lin. > > Best Regards > -- > Lin Gao > Software Engineer > JBoss by Red Hat > > >>> [1] >>> https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/structure/EarStructureProcessor.java#L271 >>> [2] >>> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeploymentOverlayDeploymentUnitProcessor.java#L111-L112 >>> [3] https://github.com/wildfly/wildfly-core/pull/1332 and >>> https://github.com/wildfly/wildfly/pull/8528 >>> [4] https://bugzilla.redhat.com/show_bug.cgi?id=1147352 and >>> https://issues.jboss.org/browse/JBEAP-2491 >>> >>> Best Regards >>> -- >>> Lin Gao >>> JBoss Software Engineer >>> >>> >>>> On 12/23/2015 05:17 PM, Lin Gao wrote: >>>> >>>> >>>> >>>> Hi, >>>> >>>> I am working on https://issues.jboss.org/browse/WFCORE-761 for a while, >>>> and I >>>> am stuck in the case of overlaying files in jar of war of ear. >>>> >>>> I want to know that do we support overlay for files in jar of war of ear? >>>> like: xx.ear/yy.war/zz.jar/META-INF/config.properties >>>> >>>> DeploymentOverlayDeploymentUnitProcessor.java[1] and >>>> DeferredDeploymentOverlayDeploymentUnitProcessor.java[2] are classes to >>>> handle the deployment overlay, but in this case, the jar of war of ear >>>> does >>>> not get mounted yet, which leads to >>>> DeferredDeploymentOverlayDeploymentUnitProcessor.handleEntryWithFileParent() >>>> method is called, which just prints the error message. >>>> >>>> The way to fix it maybe mount the jar(VFS.mountZip) beforehand, but it is >>>> specific to the case of ear/war/jar, and these 2 classes are more >>>> generic(they are in wildfly-core, no ee nor undertow extension), so where >>>> this can be fixed? >>>> >>>> [1] >>>> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeploymentOverlayDeploymentUnitProcessor.java >>>> [2] >>>> https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/DeferredDeploymentOverlayDeploymentUnitProcessor.java >>>> >>>> Best Regards >>>> -- >>>> Lin Gao >>>> JBoss Software Engineer >>>> >>>> >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >>>> >>>> -- >>>> Richard Opalka >>>> Principal Software Engineer >>>> JBoss by Red Hat >>>> Mobile: +420 731 186 942 >>>> >>>> _______________________________________________ >>>> wildfly-dev mailing list >>>> wildfly-dev at lists.jboss.org >>>> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> -- >> Richard Opalka >> Principal Software Engineer >> JBoss by Red Hat >> Mobile: +420 731 186 942 >> >> -- Richard Opalka Principal Software Engineer JBoss by Red Hat Mobile: +420 731 186 942 From rory.odonnell at oracle.com Fri Jan 15 05:47:39 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 15 Jan 2016 10:47:39 +0000 Subject: [wildfly-dev] Early Access builds of JDK 8u76 b02, JDK 9 build b100 & build b99 for JDK 9 with Project Jigsaw are available on java.net Message-ID: <5698CE4B.2030300@oracle.com> Hi Jason/Tomaz, Early Access b02 for JDK 8u76 is available on java.net, summary of changes are listed here . Early Access b100 for JDK 9 is available on java.net, summary of changes are listed here . Early Access b99 for JDK 9 with Project Jigsaw is available on java.net, summary of changes are listed here . Dalibor and I will be at FOSDEM '16, Brussels 30 & 31 January, link to our presentation here. Let us know if you will be there, hopefully we can meet up ! Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160115/80290eea/attachment.html From tcerar at redhat.com Fri Jan 15 11:54:55 2016 From: tcerar at redhat.com (Tomaz Cerar) Date: Fri, 15 Jan 2016 17:54:55 +0100 Subject: [wildfly-dev] Early Access builds of JDK 8u76 b02, JDK 9 build b100 & build b99 for JDK 9 with Project Jigsaw are available on java.net In-Reply-To: <5698CE4B.2030300@oracle.com> References: <5698CE4B.2030300@oracle.com> Message-ID: Hey Rory, I've some more tests of WildFly on jdk9 build 100, currently from custom branch, as we are still waiting for new release of plexus-archiver containing https://github.com/codehaus-plexus/plexus-archiver/pull/12 It looks like our code works fine, after some small changes to address also jvm version detection we had. There was some small issue related to changes in JDK's logging but we managed to fix already in recent build. I will be at FOSDEM, so we sure should meet up. cheers, tomaz On Fri, Jan 15, 2016 at 11:47 AM, Rory O'Donnell wrote: > > Hi Jason/Tomaz, > > Early Access b02 for JDK 8u76 is > available on java.net, summary of changes are listed here > . > > Early Access b100 for JDK 9 is > available on java.net, summary of changes are listed here > . > > Early Access b99 for JDK 9 with Project > Jigsaw is available on java.net, summary of changes are listed here > . > > Dalibor and I will be at FOSDEM '16, Brussels 30 & 31 January, link to our > presentation here. > > Let us know if you will be there, hopefully we can meet up ! > > Rgds,Rory > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160115/8cc5dd07/attachment-0001.html From rory.odonnell at oracle.com Fri Jan 15 12:01:23 2016 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Fri, 15 Jan 2016 17:01:23 +0000 Subject: [wildfly-dev] Early Access builds of JDK 8u76 b02, JDK 9 build b100 & build b99 for JDK 9 with Project Jigsaw are available on java.net In-Reply-To: References: <5698CE4B.2030300@oracle.com> Message-ID: <569925E3.9040600@oracle.com> Hi Tomaz, Thanks for the update, see you at FOSDEM! Rgds,Rory On 15/01/2016 16:54, Tomaz Cerar wrote: > Hey Rory, > > I've some more tests of WildFly on jdk9 build 100, currently from > custom branch, > as we are still waiting for new release of plexus-archiver containing > https://github.com/codehaus-plexus/plexus-archiver/pull/12 > > It looks like our code works fine, after some small changes to address > also jvm version detection we had. > There was some small issue related to changes in JDK's logging but we > managed to fix already in recent build. > > > I will be at FOSDEM, so we sure should meet up. > > cheers, > tomaz > > On Fri, Jan 15, 2016 at 11:47 AM, Rory O'Donnell > > wrote: > > > Hi Jason/Tomaz, > > Early Access b02 for JDK > 8u76 is available on java.net , summary of > changes are listed here > . > > Early Access b100 for JDK 9 is > available on java.net , summary of changes are > listed here . > > Early Access b99 for JDK 9 with > Project Jigsaw is available on java.net , summary > of changes are listed here > . > > Dalibor and I will be at FOSDEM '16, Brussels 30 & 31 January, > link to our presentation here. > > Let us know if you will be there, hopefully we can meet up ! > > Rgds,Rory > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160115/36aa7ea0/attachment.html From mmusgrov at redhat.com Wed Jan 20 11:07:58 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Wed, 20 Jan 2016 16:07:58 +0000 Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar Message-ID: The narayana jts jar has dependencies on internal jdk orb classes. We test that it can work with the openjdk-orb by adding the openjdk-orb jar to the bootclasspath. However, jdeps -jdkinternals reports that we depend on internal JDK APIs. Is it the case that we cannot avoid this warning but that we are safe provided at runtime we use the classes in the openjdk-orb jar? A follow up question is, if we add javax.orb.api as module dependency (in our wildfly transactions subsystem) then at runtime will we be using the classes provided by openjdk-orb? Thanks, Mike -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/874bd788/attachment.html From jason.greene at redhat.com Wed Jan 20 11:13:04 2016 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 20 Jan 2016 10:13:04 -0600 Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar In-Reply-To: References: Message-ID: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> We probably should rename the packages to avoid confusion. What do you think Tomasz? > On Jan 20, 2016, at 10:07 AM, Michael Musgrove wrote: > > The narayana jts jar has dependencies on internal jdk orb classes. We test that it can work with the openjdk-orb by adding the openjdk-orb jar to the bootclasspath. However, jdeps -jdkinternals reports that we depend on internal JDK APIs. Is it the case that we cannot avoid this warning but that we are safe provided at runtime we use the classes in the openjdk-orb jar? > > A follow up question is, if we add javax.orb.api as module dependency (in our wildfly transactions subsystem) then at runtime will we be using the classes provided by openjdk-orb? > > Thanks, > Mike > > -- > Michael Musgrove > Transactions Team > e: mmusgrov at redhat.com > t: +44 191 243 0870 > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > (US), Charles Peters (US) > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/abf845a5/attachment.html From tadamski at redhat.com Wed Jan 20 11:45:32 2016 From: tadamski at redhat.com (Tomasz Adamski) Date: Wed, 20 Jan 2016 11:45:32 -0500 (EST) Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar In-Reply-To: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> References: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> Message-ID: <883523971.10066138.1453308332564.JavaMail.zimbra@redhat.com> > A follow up question is, if we add javax.orb.api as module dependency (in > our wildfly transactions subsystem) then at runtime will we be using the > classes provided by openjdk-orb? If we use openjdk-orb in jboss-modules environment we are sure that openjdk-orb is used as orb classes are not exported as system packages. > Is it the case that we cannot avoid this warning but > that we are safe provided at runtime we use the classes in the openjdk-orb > jar? In standalone scenario it should work correctly too. I will look wheter the error is caused by jdeps tool behaviour or do we indeed have some unwanted runtime references to JDK. > We probably should rename the packages to avoid confusion. What do you think > Tomasz? This can be done but I see one problem: openjdk-orb is a hg repository and we have possibility to synchronize it with JDK head if there are some changes in ORB code. I would have to script it somehow to preserve such possibility. But I agree that it will be nice to do. -- Tomasz Adamski Software Engineer JBoss by Red Hat ----- Oryginalna wiadomo?? ----- > Od: "Jason Greene" > Do: "Michael Musgrove" > DW: "WildFly Dev" , "Tomasz Adamski" > Wys?ane: ?roda, 20 stycze? 2016 17:13:04 > Temat: Re: [wildfly-dev] How to avoid depending on corba classes in rt.jar > > We probably should rename the packages to avoid confusion. What do you think > Tomasz? > > > > On Jan 20, 2016, at 10:07 AM, Michael Musgrove wrote: > > > > The narayana jts jar has dependencies on internal jdk orb classes. We test > > that it can work with the openjdk-orb by adding the openjdk-orb jar to the > > bootclasspath. However, jdeps -jdkinternals reports that we depend on > > internal JDK APIs. Is it the case that we cannot avoid this warning but > > that we are safe provided at runtime we use the classes in the openjdk-orb > > jar? > > > > A follow up question is, if we add javax.orb.api as module dependency (in > > our wildfly transactions subsystem) then at runtime will we be using the > > classes provided by openjdk-orb? > > > > Thanks, > > Mike > > > > -- > > Michael Musgrove > > Transactions Team > > e: mmusgrov at redhat.com > > t: +44 191 243 0870 > > > > Registered in England and Wales under Company Registration No. 03798903 > > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > > (US), Charles Peters (US) > > > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > > O'Neill(Ireland) > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > From darkness.renann at gmail.com Wed Jan 20 11:57:05 2016 From: darkness.renann at gmail.com (Renann Prado) Date: Wed, 20 Jan 2016 14:57:05 -0200 Subject: [wildfly-dev] Is there a wildfly-user list? Message-ID: Hello. I took a look at the below link and couldn't find the wildfly-user list. https://lists.jboss.org/mailman/listinfo/ Looking at the jboss-user list, it doesn't to be too much of active. https://lists.jboss.org/mailman/listinfo/jboss-user So I was wondering if there is a better place to ask things other than the wildfly forum. I know this is off-topic, sorry about that. Renann Prado -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/dd01c533/attachment-0001.html From mmusgrov at redhat.com Wed Jan 20 12:01:26 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Wed, 20 Jan 2016 17:01:26 +0000 Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar In-Reply-To: <883523971.10066138.1453308332564.JavaMail.zimbra@redhat.com> References: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> <883523971.10066138.1453308332564.JavaMail.zimbra@redhat.com> Message-ID: On Wed, Jan 20, 2016 at 4:45 PM, Tomasz Adamski wrote: > > A follow up question is, if we add javax.orb.api as module dependency (in > > our wildfly transactions subsystem) then at runtime will we be using the > > classes provided by openjdk-orb? > > If we use openjdk-orb in jboss-modules environment we are sure that > openjdk-orb is used as orb classes are not exported as system packages. > Okay so we are covered in wildfly and EAP which is good to know. > > > Is it the case that we cannot avoid this warning but > > that we are safe provided at runtime we use the classes in the > openjdk-orb > > jar? > > In standalone scenario it should work correctly too. I will look wheter > the error is caused by jdeps tool behaviour or do we indeed have some > unwanted runtime references to JDK. > In a standalone scenario we are not using modules so the JVM would use rt.jar unless the user updates the bootclasspath. I do not see how it would be possible to avoid the jdeps warnings. > > > We probably should rename the packages to avoid confusion. What do you > think > > Tomasz? > > This can be done but I see one problem: openjdk-orb is a hg repository and > we have possibility to synchronize it with JDK head if there are some > changes in ORB code. I would have to script it somehow to preserve such > possibility. But I agree that it will be nice to do. > I agree it would be nice (but I guess not a must have). Mike > > -- > Tomasz Adamski > Software Engineer > JBoss by Red Hat > > ----- Oryginalna wiadomo?? ----- > > Od: "Jason Greene" > > Do: "Michael Musgrove" > > DW: "WildFly Dev" , "Tomasz Adamski" < > tadamski at redhat.com> > > Wys?ane: ?roda, 20 stycze? 2016 17:13:04 > > Temat: Re: [wildfly-dev] How to avoid depending on corba classes in > rt.jar > > > > We probably should rename the packages to avoid confusion. What do you > think > > Tomasz? > > > > > > > On Jan 20, 2016, at 10:07 AM, Michael Musgrove > wrote: > > > > > > The narayana jts jar has dependencies on internal jdk orb classes. We > test > > > that it can work with the openjdk-orb by adding the openjdk-orb jar to > the > > > bootclasspath. However, jdeps -jdkinternals reports that we depend on > > > internal JDK APIs. Is it the case that we cannot avoid this warning but > > > that we are safe provided at runtime we use the classes in the > openjdk-orb > > > jar? > > > > > > A follow up question is, if we add javax.orb.api as module dependency > (in > > > our wildfly transactions subsystem) then at runtime will we be using > the > > > classes provided by openjdk-orb? > > > > > > Thanks, > > > Mike > > > > > > -- > > > Michael Musgrove > > > Transactions Team > > > e: mmusgrov at redhat.com > > > t: +44 191 243 0870 > > > > > > Registered in England and Wales under Company Registration No. 03798903 > > > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > > > (US), Charles Peters (US) > > > > > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > > > O'Neill(Ireland) > > > _______________________________________________ > > > wildfly-dev mailing list > > > wildfly-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > > Jason T. Greene > > WildFly Lead / JBoss EAP Platform Architect > > JBoss, a division of Red Hat > > > > > -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/5ac30082/attachment.html From jason.greene at redhat.com Wed Jan 20 12:06:36 2016 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 20 Jan 2016 11:06:36 -0600 Subject: [wildfly-dev] Where the @#$%! is WildFly 10 Final? Message-ID: <9048DEBD-3A57-400F-8904-5F07F0ECAF33@redhat.com> Sorry for the delay. We are down to two blockers that we are sorting out: 1. https://issues.jboss.org/browse/WFLY-5480 2. https://issues.jboss.org/browse/WFCORE-1277 -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From mmusgrov at redhat.com Wed Jan 20 12:09:18 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Wed, 20 Jan 2016 17:09:18 +0000 Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar In-Reply-To: References: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> <883523971.10066138.1453308332564.JavaMail.zimbra@redhat.com> Message-ID: On Wed, Jan 20, 2016 at 5:01 PM, Michael Musgrove wrote: > > > On Wed, Jan 20, 2016 at 4:45 PM, Tomasz Adamski > wrote: > >> > A follow up question is, if we add javax.orb.api as module dependency >> (in >> > our wildfly transactions subsystem) then at runtime will we be using the >> > classes provided by openjdk-orb? >> >> If we use openjdk-orb in jboss-modules environment we are sure that >> openjdk-orb is used as orb classes are not exported as system packages. >> > > Okay so we are covered in wildfly and EAP which is good to know. > > >> >> > Is it the case that we cannot avoid this warning but >> > that we are safe provided at runtime we use the classes in the >> openjdk-orb >> > jar? >> >> In standalone scenario it should work correctly too. I will look wheter >> the error is caused by jdeps tool behaviour or do we indeed have some >> unwanted runtime references to JDK. >> > > In a standalone scenario we are not using modules so the JVM would use > rt.jar unless the user updates the bootclasspath. I do not see how it would > be possible to avoid the jdeps warnings. > > >> >> > We probably should rename the packages to avoid confusion. What do you >> think >> > Tomasz? >> >> This can be done but I see one problem: openjdk-orb is a hg repository >> and we have possibility to synchronize it with JDK head if there are some >> changes in ORB code. I would have to script it somehow to preserve such >> possibility. But I agree that it will be nice to do. >> > > I agree it would be nice (but I guess not a must have). > On second thoughts, for standalone usage it is a pain to have to tell the user that he must start the JVM with -Xbootclasspath/p:${openjdk-orb.jar} which might be a barrier to adoption for some users. Mike > > Mike > >> >> -- >> Tomasz Adamski >> Software Engineer >> JBoss by Red Hat >> >> ----- Oryginalna wiadomo?? ----- >> > Od: "Jason Greene" >> > Do: "Michael Musgrove" >> > DW: "WildFly Dev" , "Tomasz Adamski" < >> tadamski at redhat.com> >> > Wys?ane: ?roda, 20 stycze? 2016 17:13:04 >> > Temat: Re: [wildfly-dev] How to avoid depending on corba classes in >> rt.jar >> > >> > We probably should rename the packages to avoid confusion. What do you >> think >> > Tomasz? >> > >> > >> > > On Jan 20, 2016, at 10:07 AM, Michael Musgrove >> wrote: >> > > >> > > The narayana jts jar has dependencies on internal jdk orb classes. We >> test >> > > that it can work with the openjdk-orb by adding the openjdk-orb jar >> to the >> > > bootclasspath. However, jdeps -jdkinternals reports that we depend on >> > > internal JDK APIs. Is it the case that we cannot avoid this warning >> but >> > > that we are safe provided at runtime we use the classes in the >> openjdk-orb >> > > jar? >> > > >> > > A follow up question is, if we add javax.orb.api as module dependency >> (in >> > > our wildfly transactions subsystem) then at runtime will we be using >> the >> > > classes provided by openjdk-orb? >> > > >> > > Thanks, >> > > Mike >> > > >> > > -- >> > > Michael Musgrove >> > > Transactions Team >> > > e: mmusgrov at redhat.com >> > > t: +44 191 243 0870 >> > > >> > > Registered in England and Wales under Company Registration No. >> 03798903 >> > > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson >> > > (US), Charles Peters (US) >> > > >> > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), >> Michael >> > > O'Neill(Ireland) >> > > _______________________________________________ >> > > wildfly-dev mailing list >> > > wildfly-dev at lists.jboss.org >> > > https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > >> > -- >> > Jason T. Greene >> > WildFly Lead / JBoss EAP Platform Architect >> > JBoss, a division of Red Hat >> > >> > >> > > > > -- > Michael Musgrove > Transactions Team > e: mmusgrov at redhat.com > t: +44 191 243 0870 > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > (US), Charles Peters (US) > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > O'Neill(Ireland) > -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/fb23ff89/attachment-0001.html From tadamski at redhat.com Wed Jan 20 12:12:00 2016 From: tadamski at redhat.com (Tomasz Adamski) Date: Wed, 20 Jan 2016 12:12:00 -0500 (EST) Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar In-Reply-To: References: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> <883523971.10066138.1453308332564.JavaMail.zimbra@redhat.com> Message-ID: <1414180705.10099113.1453309920063.JavaMail.zimbra@redhat.com> > In a standalone scenario we are not using modules so the JVM would use > rt.jar unless the user updates the bootclasspath. I do not see how it would > be possible to avoid the jdeps warnings. True, my mistake. I thought about a scenario in which despite using xbootclasspath we have some orb dependencies to JDK, but this obviously can only be tested on runtime which is not what jdeps does. -- Tomasz Adamski Software Engineer JBoss by Red Hat ----- Oryginalna wiadomo?? ----- > Od: "Michael Musgrove" > Do: "Tomasz Adamski" > DW: "Jason Greene" , "WildFly Dev" > Wys?ane: ?roda, 20 stycze? 2016 18:01:26 > Temat: Re: [wildfly-dev] How to avoid depending on corba classes in rt.jar > > On Wed, Jan 20, 2016 at 4:45 PM, Tomasz Adamski wrote: > > > > A follow up question is, if we add javax.orb.api as module dependency (in > > > our wildfly transactions subsystem) then at runtime will we be using the > > > classes provided by openjdk-orb? > > > > If we use openjdk-orb in jboss-modules environment we are sure that > > openjdk-orb is used as orb classes are not exported as system packages. > > > > Okay so we are covered in wildfly and EAP which is good to know. > > > > > > > Is it the case that we cannot avoid this warning but > > > that we are safe provided at runtime we use the classes in the > > openjdk-orb > > > jar? > > > > In standalone scenario it should work correctly too. I will look wheter > > the error is caused by jdeps tool behaviour or do we indeed have some > > unwanted runtime references to JDK. > > > > In a standalone scenario we are not using modules so the JVM would use > rt.jar unless the user updates the bootclasspath. I do not see how it would > be possible to avoid the jdeps warnings. > > > > > > > We probably should rename the packages to avoid confusion. What do you > > think > > > Tomasz? > > > > This can be done but I see one problem: openjdk-orb is a hg repository and > > we have possibility to synchronize it with JDK head if there are some > > changes in ORB code. I would have to script it somehow to preserve such > > possibility. But I agree that it will be nice to do. > > > > I agree it would be nice (but I guess not a must have). > > Mike > > > > > -- > > Tomasz Adamski > > Software Engineer > > JBoss by Red Hat > > > > ----- Oryginalna wiadomo?? ----- > > > Od: "Jason Greene" > > > Do: "Michael Musgrove" > > > DW: "WildFly Dev" , "Tomasz Adamski" < > > tadamski at redhat.com> > > > Wys?ane: ?roda, 20 stycze? 2016 17:13:04 > > > Temat: Re: [wildfly-dev] How to avoid depending on corba classes in > > rt.jar > > > > > > We probably should rename the packages to avoid confusion. What do you > > think > > > Tomasz? > > > > > > > > > > On Jan 20, 2016, at 10:07 AM, Michael Musgrove > > wrote: > > > > > > > > The narayana jts jar has dependencies on internal jdk orb classes. We > > test > > > > that it can work with the openjdk-orb by adding the openjdk-orb jar to > > the > > > > bootclasspath. However, jdeps -jdkinternals reports that we depend on > > > > internal JDK APIs. Is it the case that we cannot avoid this warning but > > > > that we are safe provided at runtime we use the classes in the > > openjdk-orb > > > > jar? > > > > > > > > A follow up question is, if we add javax.orb.api as module dependency > > (in > > > > our wildfly transactions subsystem) then at runtime will we be using > > the > > > > classes provided by openjdk-orb? > > > > > > > > Thanks, > > > > Mike > > > > > > > > -- > > > > Michael Musgrove > > > > Transactions Team > > > > e: mmusgrov at redhat.com > > > > t: +44 191 243 0870 > > > > > > > > Registered in England and Wales under Company Registration No. 03798903 > > > > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > > > > (US), Charles Peters (US) > > > > > > > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > > > > O'Neill(Ireland) > > > > _______________________________________________ > > > > wildfly-dev mailing list > > > > wildfly-dev at lists.jboss.org > > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > -- > > > Jason T. Greene > > > WildFly Lead / JBoss EAP Platform Architect > > > JBoss, a division of Red Hat > > > > > > > > > > > > -- > Michael Musgrove > Transactions Team > e: mmusgrov at redhat.com > t: +44 191 243 0870 > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > (US), Charles Peters (US) > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > O'Neill(Ireland) > From rodrigo.lira at tjpr.jus.br Wed Jan 20 12:12:13 2016 From: rodrigo.lira at tjpr.jus.br (Rodrigo Lira) Date: Wed, 20 Jan 2016 15:12:13 -0200 Subject: [wildfly-dev] Remote JMX access in Wildfly 8.2.1 Message-ID: <569FBFED.5010508@tjpr.jus.br> Hi, After install WildFly in standalone mode I can access JMX with JConsole using the address service:jmx:http-remoting-jmx://host:9990, but when I install in domain mode only the domain controller is accessible, I can't connect in host slaves. How do I enable JMX in host slaves? -- Thanks, Rodrigo Lira From tomaz.cerar at gmail.com Wed Jan 20 12:28:07 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Wed, 20 Jan 2016 18:28:07 +0100 Subject: [wildfly-dev] Is there a wildfly-user list? In-Reply-To: References: Message-ID: we don't have wildfly-user mailing list but do have community forums instead. you can find them at: https://developer.jboss.org/en/wildfly -- tomaz On Wed, Jan 20, 2016 at 5:57 PM, Renann Prado wrote: > Hello. > > I took a look at the below link and couldn't find the wildfly-user list. > > https://lists.jboss.org/mailman/listinfo/ > > Looking at the jboss-user list, it doesn't to be too much of active. > > https://lists.jboss.org/mailman/listinfo/jboss-user > > So I was wondering if there is a better place to ask things other than the > wildfly forum. > > I know this is off-topic, sorry about that. > > > Renann Prado > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/0b78981c/attachment.html From jason.greene at redhat.com Wed Jan 20 12:37:28 2016 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 20 Jan 2016 11:37:28 -0600 Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar In-Reply-To: <1414180705.10099113.1453309920063.JavaMail.zimbra@redhat.com> References: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> <883523971.10066138.1453308332564.JavaMail.zimbra@redhat.com> <1414180705.10099113.1453309920063.JavaMail.zimbra@redhat.com> Message-ID: <000CC760-7802-4D57-8DFC-04F8D25E9B18@redhat.com> > On Jan 20, 2016, at 11:12 AM, Tomasz Adamski wrote: > >> In a standalone scenario we are not using modules so the JVM would use >> rt.jar unless the user updates the bootclasspath. I do not see how it would >> be possible to avoid the jdeps warnings. > > True, my mistake. I thought about a scenario in which despite using xbootclasspath we have some orb dependencies to JDK, but this obviously can only be tested on runtime which is not what jdeps does. While some thought on the feasibility of package renaming is progressing, I have an semi-important tangent (more to say in a subsequent follow-up). At one point we had a long term goal, or perhaps ?hope? is more precise, that we would one day just be able to use the ORB in the JVM without shipping a downstream variant. That may very well become a possibility with virtually all known non-Oracle JVMs utilizing the openjdk lib, and thus the same impl. I take this means that Naryana requires references to non org.omg APIs, and thus if we remove them, this goal would no longer be possible. Note that with Java 9 internal APIs, I can pretty much guarantee that we are going to have to use whatever override flag they add for running WildFly/EAP, and certainly many other mainstream Java systems. We rely on those APIs, and there hasn?t been adequate replacement. I wonder if the linkage you refer to here doesn?t also fit this category. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat From pbenedict at apache.org Wed Jan 20 12:41:29 2016 From: pbenedict at apache.org (Paul Benedict) Date: Wed, 20 Jan 2016 11:41:29 -0600 Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar In-Reply-To: <000CC760-7802-4D57-8DFC-04F8D25E9B18@redhat.com> References: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> <883523971.10066138.1453308332564.JavaMail.zimbra@redhat.com> <1414180705.10099113.1453309920063.JavaMail.zimbra@redhat.com> <000CC760-7802-4D57-8DFC-04F8D25E9B18@redhat.com> Message-ID: Jason, have you considered reaching out to Oracle (or have already) to discuss what internal APIs have no public replacement? They are very receptive to that kind of feedback. Cheers, Paul On Wed, Jan 20, 2016 at 11:37 AM, Jason Greene wrote: > > > On Jan 20, 2016, at 11:12 AM, Tomasz Adamski > wrote: > > > >> In a standalone scenario we are not using modules so the JVM would use > >> rt.jar unless the user updates the bootclasspath. I do not see how it > would > >> be possible to avoid the jdeps warnings. > > > > True, my mistake. I thought about a scenario in which despite using > xbootclasspath we have some orb dependencies to JDK, but this obviously can > only be tested on runtime which is not what jdeps does. > > While some thought on the feasibility of package renaming is progressing, > I have an semi-important tangent (more to say in a subsequent follow-up). > At one point we had a long term goal, or perhaps ?hope? is more precise, > that we would one day just be able to use the ORB in the JVM without > shipping a downstream variant. That may very well become a possibility with > virtually all known non-Oracle JVMs utilizing the openjdk lib, and thus the > same impl. > > I take this means that Naryana requires references to non org.omg APIs, > and thus if we remove them, this goal would no longer be possible. > > Note that with Java 9 internal APIs, I can pretty much guarantee that we > are going to have to use whatever override flag they add for running > WildFly/EAP, and certainly many other mainstream Java systems. We rely on > those APIs, and there hasn?t been adequate replacement. I wonder if the > linkage you refer to here doesn?t also fit this category. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/1bf7d323/attachment.html From filippespolti at gmail.com Wed Jan 20 12:41:59 2016 From: filippespolti at gmail.com (Filippe spolti) Date: Wed, 20 Jan 2016 15:41:59 -0200 Subject: [wildfly-dev] Remote JMX access in Wildfly 8.2.1 In-Reply-To: <569FBFED.5010508@tjpr.jus.br> References: <569FBFED.5010508@tjpr.jus.br> Message-ID: <569FC6E7.9000309@gmail.com> This is switched on by default in standalone mode and accessible over port 9990 but in domain mode is switched off so needs to be enabled - in domain mode the port will be the port of the Remoting connector for the WildFly 8 instance to be monitored. the jmx subsystem should looks like: Then use the server's http port to access the jmx. On 01/20/2016 03:12 PM, Rodrigo Lira wrote: > Hi, > > After install WildFly in standalone mode I can access JMX with JConsole using the address service:jmx:http-remoting-jmx://host:9990, but when I install in domain mode only the domain controller is accessible, I can't connect in host slaves. How do I enable JMX in host slaves? > > -- Regards, --Filippe -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/17eb5a09/attachment-0001.html From mmusgrov at redhat.com Wed Jan 20 12:56:19 2016 From: mmusgrov at redhat.com (Michael Musgrove) Date: Wed, 20 Jan 2016 17:56:19 +0000 Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar In-Reply-To: <000CC760-7802-4D57-8DFC-04F8D25E9B18@redhat.com> References: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> <883523971.10066138.1453308332564.JavaMail.zimbra@redhat.com> <1414180705.10099113.1453309920063.JavaMail.zimbra@redhat.com> <000CC760-7802-4D57-8DFC-04F8D25E9B18@redhat.com> Message-ID: On Wed, Jan 20, 2016 at 5:37 PM, Jason Greene wrote: > > > On Jan 20, 2016, at 11:12 AM, Tomasz Adamski > wrote: > > > >> In a standalone scenario we are not using modules so the JVM would use > >> rt.jar unless the user updates the bootclasspath. I do not see how it > would > >> be possible to avoid the jdeps warnings. > > > > True, my mistake. I thought about a scenario in which despite using > xbootclasspath we have some orb dependencies to JDK, but this obviously can > only be tested on runtime which is not what jdeps does. > > While some thought on the feasibility of package renaming is progressing, > I have an semi-important tangent (more to say in a subsequent follow-up). > At one point we had a long term goal, or perhaps ?hope? is more precise, > that we would one day just be able to use the ORB in the JVM without > shipping a downstream variant. That may very well become a possibility with > virtually all known non-Oracle JVMs utilizing the openjdk lib, and thus the > same impl. > > I take this means that Naryana requires references to non org.omg APIs, > and thus if we remove them, this goal would no longer be possible. > We only access internal APIs in one place where we need to embed recovery information inside the (OTS) RecoveryCoordinator IOR. It is not clear to me how much rearchitecting would be required to come up with a different mechanism but I will think about it. We are also investigating how to provide a JTS implementation without an ORB (https://issues.jboss.org/browse/JBTM-2103). If we can make progress on that task then achieving your goal would still be feasible. Mike > > Note that with Java 9 internal APIs, I can pretty much guarantee that we > are going to have to use whatever override flag they add for running > WildFly/EAP, and certainly many other mainstream Java systems. We rely on > those APIs, and there hasn?t been adequate replacement. I wonder if the > linkage you refer to here doesn?t also fit this category. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > -- Michael Musgrove Transactions Team e: mmusgrov at redhat.com t: +44 191 243 0870 Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson (US), Charles Peters (US) Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/2370cd28/attachment.html From jason.greene at redhat.com Wed Jan 20 13:15:08 2016 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 20 Jan 2016 12:15:08 -0600 Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar In-Reply-To: References: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> <883523971.10066138.1453308332564.JavaMail.zimbra@redhat.com> <1414180705.10099113.1453309920063.JavaMail.zimbra@redhat.com> <000CC760-7802-4D57-8DFC-04F8D25E9B18@redhat.com> Message-ID: <877B7249-FB91-4C04-BA78-F2BB056F588F@redhat.com> Hi Paul, Yes we have had a few discussions about some of our usage with the Oracle JVM QE group. We have also provided some feedback at the JCP level. To give one example, if you want to provide an alternative serialization mechanism (e.g. to customize the protocol for various reasons such as performance, modularity, security), yet still support the Java serialization API/contract, you have to be able to instantiate empty uninitialized classes. This is something that Java serialization implementation itself can?t work without, but the Java language is not intended to allow you to do. So the common solution that many projects do to achieve this, is to either use reflection internals or the Unsafe. Other examples typically involve the latter (e.g. custom concurrency prims) So naturally there has been resistance to expose hooks such as this, which is why I predict they won?t be there in Java 9. I would love to be proven wrong though :) > On Jan 20, 2016, at 11:41 AM, Paul Benedict wrote: > > Jason, have you considered reaching out to Oracle (or have already) to discuss what internal APIs have no public replacement? They are very receptive to that kind of feedback. > > Cheers, > Paul > > On Wed, Jan 20, 2016 at 11:37 AM, Jason Greene > wrote: > > > On Jan 20, 2016, at 11:12 AM, Tomasz Adamski > wrote: > > > >> In a standalone scenario we are not using modules so the JVM would use > >> rt.jar unless the user updates the bootclasspath. I do not see how it would > >> be possible to avoid the jdeps warnings. > > > > True, my mistake. I thought about a scenario in which despite using xbootclasspath we have some orb dependencies to JDK, but this obviously can only be tested on runtime which is not what jdeps does. > > While some thought on the feasibility of package renaming is progressing, I have an semi-important tangent (more to say in a subsequent follow-up). At one point we had a long term goal, or perhaps ?hope? is more precise, that we would one day just be able to use the ORB in the JVM without shipping a downstream variant. That may very well become a possibility with virtually all known non-Oracle JVMs utilizing the openjdk lib, and thus the same impl. > > I take this means that Naryana requires references to non org.omg APIs, and thus if we remove them, this goal would no longer be possible. > > Note that with Java 9 internal APIs, I can pretty much guarantee that we are going to have to use whatever override flag they add for running WildFly/EAP, and certainly many other mainstream Java systems. We rely on those APIs, and there hasn?t been adequate replacement. I wonder if the linkage you refer to here doesn?t also fit this category. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/5feb877b/attachment.html From jason.greene at redhat.com Wed Jan 20 13:21:28 2016 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 20 Jan 2016 12:21:28 -0600 Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar In-Reply-To: <877B7249-FB91-4C04-BA78-F2BB056F588F@redhat.com> References: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> <883523971.10066138.1453308332564.JavaMail.zimbra@redhat.com> <1414180705.10099113.1453309920063.JavaMail.zimbra@redhat.com> <000CC760-7802-4D57-8DFC-04F8D25E9B18@redhat.com> <877B7249-FB91-4C04-BA78-F2BB056F588F@redhat.com> Message-ID: <53C18935-FBBB-4D41-A7A9-094719325AA4@redhat.com> > On Jan 20, 2016, at 12:15 PM, Jason Greene wrote: > > Hi Paul, > > Yes we have had a few discussions about some of our usage with the Oracle JVM QE group. We have also provided some feedback at the JCP level. > > To give one example, if you want to provide an alternative serialization mechanism (e.g. to customize the protocol for various reasons such as performance, modularity, security), yet still support the Java serialization API/contract, you have to be able to instantiate empty uninitialized classes. This is something that Java serialization implementation itself can?t work without, but the Java language is not intended to allow you to do. So the common solution that many projects do to achieve this, is to either use reflection internals or the Unsafe. Other examples typically involve the latter (e.g. custom concurrency prims) > > So naturally there has been resistance to expose hooks such as this, which is why I predict they won?t be there in Java 9. I would love to be proven wrong though :) Just to clarify, I predict they won?t be part of a public javax.xxx API. They will still be internally available since Java itself needs them (as do we). There has been mention of a flag to prevent removing visibility of these classes, as otherwise compatibility will most certainly be broken. That is what I expect we will require. That said, we should remove every occurrence that we don?t truly need. > >> On Jan 20, 2016, at 11:41 AM, Paul Benedict > wrote: >> >> Jason, have you considered reaching out to Oracle (or have already) to discuss what internal APIs have no public replacement? They are very receptive to that kind of feedback. >> >> Cheers, >> Paul >> >> On Wed, Jan 20, 2016 at 11:37 AM, Jason Greene > wrote: >> >> > On Jan 20, 2016, at 11:12 AM, Tomasz Adamski > wrote: >> > >> >> In a standalone scenario we are not using modules so the JVM would use >> >> rt.jar unless the user updates the bootclasspath. I do not see how it would >> >> be possible to avoid the jdeps warnings. >> > >> > True, my mistake. I thought about a scenario in which despite using xbootclasspath we have some orb dependencies to JDK, but this obviously can only be tested on runtime which is not what jdeps does. >> >> While some thought on the feasibility of package renaming is progressing, I have an semi-important tangent (more to say in a subsequent follow-up). At one point we had a long term goal, or perhaps ?hope? is more precise, that we would one day just be able to use the ORB in the JVM without shipping a downstream variant. That may very well become a possibility with virtually all known non-Oracle JVMs utilizing the openjdk lib, and thus the same impl. >> >> I take this means that Naryana requires references to non org.omg APIs, and thus if we remove them, this goal would no longer be possible. >> >> Note that with Java 9 internal APIs, I can pretty much guarantee that we are going to have to use whatever override flag they add for running WildFly/EAP, and certainly many other mainstream Java systems. We rely on those APIs, and there hasn?t been adequate replacement. I wonder if the linkage you refer to here doesn?t also fit this category. >> >> -- >> Jason T. Greene >> WildFly Lead / JBoss EAP Platform Architect >> JBoss, a division of Red Hat >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/7c29bb00/attachment-0001.html From jason.greene at redhat.com Wed Jan 20 13:30:54 2016 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 20 Jan 2016 12:30:54 -0600 Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar In-Reply-To: References: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> <883523971.10066138.1453308332564.JavaMail.zimbra@redhat.com> <1414180705.10099113.1453309920063.JavaMail.zimbra@redhat.com> <000CC760-7802-4D57-8DFC-04F8D25E9B18@redhat.com> Message-ID: <66B3B770-B968-4554-873D-F75E7B7A9A18@redhat.com> > On Jan 20, 2016, at 11:56 AM, Michael Musgrove wrote: > > > > On Wed, Jan 20, 2016 at 5:37 PM, Jason Greene > wrote: > > > On Jan 20, 2016, at 11:12 AM, Tomasz Adamski > wrote: > > > >> In a standalone scenario we are not using modules so the JVM would use > >> rt.jar unless the user updates the bootclasspath. I do not see how it would > >> be possible to avoid the jdeps warnings. > > > > True, my mistake. I thought about a scenario in which despite using xbootclasspath we have some orb dependencies to JDK, but this obviously can only be tested on runtime which is not what jdeps does. > > While some thought on the feasibility of package renaming is progressing, I have an semi-important tangent (more to say in a subsequent follow-up). At one point we had a long term goal, or perhaps ?hope? is more precise, that we would one day just be able to use the ORB in the JVM without shipping a downstream variant. That may very well become a possibility with virtually all known non-Oracle JVMs utilizing the openjdk lib, and thus the same impl. > > I take this means that Naryana requires references to non org.omg APIs, and thus if we remove them, this goal would no longer be possible. > > We only access internal APIs in one place where we need to embed recovery information inside the (OTS) RecoveryCoordinator IOR. It is not clear to me how much rearchitecting would be required to come up with a different mechanism but I will think about it. Ah yes. > > We are also investigating how to provide a JTS implementation without an ORB (https://issues.jboss.org/browse/JBTM-2103 ). If we can make progress on that task then achieving your goal would still be feasible. Well, to be honest, even the word ?hope? might have been too strong. It?s more like ?pipe-dream?. There is still a lot of advantages with having our own downstream, we can patch issues that haven?t been fixed in the official JDK release stream, for example. > > Mike > > > Note that with Java 9 internal APIs, I can pretty much guarantee that we are going to have to use whatever override flag they add for running WildFly/EAP, and certainly many other mainstream Java systems. We rely on those APIs, and there hasn?t been adequate replacement. I wonder if the linkage you refer to here doesn?t also fit this category. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > > > > -- > Michael Musgrove > Transactions Team > e: mmusgrov at redhat.com > t: +44 191 243 0870 > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > (US), Charles Peters (US) > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael O'Neill(Ireland) -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/68403a79/attachment.html From jason.greene at redhat.com Wed Jan 20 13:37:29 2016 From: jason.greene at redhat.com (Jason Greene) Date: Wed, 20 Jan 2016 12:37:29 -0600 Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar In-Reply-To: References: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> <883523971.10066138.1453308332564.JavaMail.zimbra@redhat.com> Message-ID: <6422D4E1-208E-4278-8399-22584517896C@redhat.com> > On Jan 20, 2016, at 11:09 AM, Michael Musgrove wrote: > > I agree it would be nice (but I guess not a must have). > > On second thoughts, for standalone usage it is a pain to have to tell the user that he must start the JVM with -Xbootclasspath/p:${openjdk-orb.jar} which might be a barrier to adoption for some users. Ok so revisiting this again. It looks like we have to replace the org.omg APIs because they hard code ORB impl classes, so even if we renamed the packages, we still would need either endorsed or Xbootclasspath to be used by the user for non-modular standalone bootstrapping. -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/8d5ec071/attachment.html From tadamski at redhat.com Wed Jan 20 14:18:12 2016 From: tadamski at redhat.com (Tomasz Adamski) Date: Wed, 20 Jan 2016 14:18:12 -0500 (EST) Subject: [wildfly-dev] How to avoid depending on corba classes in rt.jar In-Reply-To: <6422D4E1-208E-4278-8399-22584517896C@redhat.com> References: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1@redhat.com> <883523971.10066138.1453308332564.JavaMail.zimbra@redhat.com> <6422D4E1-208E-4278-8399-22584517896C@redhat.com> Message-ID: <141897904.10227601.1453317492412.JavaMail.zimbra@redhat.com> So in the end I have doubts wheter the rename should be performed as the initial problem won't be solved and additional configuration will be necessary anyway... -- Tomasz Adamski Software Engineer JBoss by Red Hat ----- Oryginalna wiadomo?? ----- > Od: "Jason Greene" > Do: "Michael Musgrove" > DW: "Tomasz Adamski" , "WildFly Dev" > Wys?ane: ?roda, 20 stycze? 2016 19:37:29 > Temat: Re: [wildfly-dev] How to avoid depending on corba classes in rt.jar > > > > On Jan 20, 2016, at 11:09 AM, Michael Musgrove wrote: > > > > I agree it would be nice (but I guess not a must have). > > > > On second thoughts, for standalone usage it is a pain to have to tell the > > user that he must start the JVM with -Xbootclasspath/p:${openjdk-orb.jar} > > which might be a barrier to adoption for some users. > > Ok so revisiting this again. It looks like we have to replace the org.omg > APIs because they hard code ORB impl classes, so even if we renamed the > packages, we still would need either endorsed or Xbootclasspath to be used > by the user for non-modular standalone bootstrapping. > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > From shivu483 at gmail.com Thu Jan 21 06:29:25 2016 From: shivu483 at gmail.com (shivu shiva shivraj) Date: Thu, 21 Jan 2016 16:59:25 +0530 Subject: [wildfly-dev] wildfly-dev Digest, Vol 34, Issue 3 In-Reply-To: References: Message-ID: hi im new to wildfly jboss server plz tell me any resource is there to understand the wildfly server...full On Wed, Jan 20, 2016 at 10:27 PM, wrote: > Send wildfly-dev mailing list submissions to > wildfly-dev at lists.jboss.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.jboss.org/mailman/listinfo/wildfly-dev > or, via email, send a message with subject or body 'help' to > wildfly-dev-request at lists.jboss.org > > You can reach the person managing the list at > wildfly-dev-owner at lists.jboss.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of wildfly-dev digest..." > > > Today's Topics: > > 1. Re: Early Access builds of JDK 8u76 b02, JDK 9 build b100 & > build b99 for JDK 9 with Project Jigsaw are available on java.net > (Rory O'Donnell) > 2. How to avoid depending on corba classes in rt.jar > (Michael Musgrove) > 3. Re: How to avoid depending on corba classes in rt.jar > (Jason Greene) > 4. Re: How to avoid depending on corba classes in rt.jar > (Tomasz Adamski) > 5. Is there a wildfly-user list? (Renann Prado) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Fri, 15 Jan 2016 17:01:23 +0000 > From: "Rory O'Donnell" > Subject: Re: [wildfly-dev] Early Access builds of JDK 8u76 b02, JDK 9 > build b100 & build b99 for JDK 9 with Project Jigsaw are available > on > java.net > To: Tomaz Cerar > Cc: Balchandra Vaidya , > rory.odonnell at oracle.com, Muneer Kolarkunnu > , Dalibor Topic > , "wildfly-dev at lists.jboss.org" > > Message-ID: <569925E3.9040600 at oracle.com> > Content-Type: text/plain; charset="utf-8" > > Hi Tomaz, > > Thanks for the update, see you at FOSDEM! > > Rgds,Rory > > On 15/01/2016 16:54, Tomaz Cerar wrote: > > Hey Rory, > > > > I've some more tests of WildFly on jdk9 build 100, currently from > > custom branch, > > as we are still waiting for new release of plexus-archiver containing > > https://github.com/codehaus-plexus/plexus-archiver/pull/12 > > > > It looks like our code works fine, after some small changes to address > > also jvm version detection we had. > > There was some small issue related to changes in JDK's logging but we > > managed to fix already in recent build. > > > > > > I will be at FOSDEM, so we sure should meet up. > > > > cheers, > > tomaz > > > > On Fri, Jan 15, 2016 at 11:47 AM, Rory O'Donnell > > > wrote: > > > > > > Hi Jason/Tomaz, > > > > Early Access b02 for JDK > > 8u76 is available on java.net , summary of > > changes are listed here > > . > > > > Early Access b100 for JDK 9 is > > available on java.net , summary of changes are > > listed here . > > > > Early Access b99 for JDK 9 with > > Project Jigsaw is available on java.net , summary > > of changes are listed here > > > . > > > > Dalibor and I will be at FOSDEM '16, Brussels 30 & 31 January, > > link to our presentation here. > > > > Let us know if you will be there, hopefully we can meet up ! > > > > Rgds,Rory > > > > -- > > Rgds,Rory O'Donnell > > Quality Engineering Manager > > Oracle EMEA , Dublin, Ireland > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160115/36aa7ea0/attachment-0001.html > > ------------------------------ > > Message: 2 > Date: Wed, 20 Jan 2016 16:07:58 +0000 > From: Michael Musgrove > Subject: [wildfly-dev] How to avoid depending on corba classes in > rt.jar > To: wildfly-dev at lists.jboss.org > Message-ID: > DTTMDOorS9VBVJnQ at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > The narayana jts jar has dependencies on internal jdk orb classes. We test > that it can work with the openjdk-orb by adding the openjdk-orb jar to the > bootclasspath. However, jdeps -jdkinternals reports that we depend on > internal JDK APIs. Is it the case that we cannot avoid this warning but > that we are safe provided at runtime we use the classes in the openjdk-orb > jar? > > A follow up question is, if we add javax.orb.api as module dependency (in > our wildfly transactions subsystem) then at runtime will we be using the > classes provided by openjdk-orb? > > Thanks, > Mike > > -- > Michael Musgrove > Transactions Team > e: mmusgrov at redhat.com > t: +44 191 243 0870 > > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > (US), Charles Peters (US) > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > O'Neill(Ireland) > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/874bd788/attachment-0001.html > > ------------------------------ > > Message: 3 > Date: Wed, 20 Jan 2016 10:13:04 -0600 > From: Jason Greene > Subject: Re: [wildfly-dev] How to avoid depending on corba classes in > rt.jar > To: Michael Musgrove > Cc: WildFly Dev > Message-ID: <4AE627DB-58D2-4D8C-B4DA-1FD7D580EEA1 at redhat.com> > Content-Type: text/plain; charset="us-ascii" > > We probably should rename the packages to avoid confusion. What do you > think Tomasz? > > > > On Jan 20, 2016, at 10:07 AM, Michael Musgrove > wrote: > > > > The narayana jts jar has dependencies on internal jdk orb classes. We > test that it can work with the openjdk-orb by adding the openjdk-orb jar to > the bootclasspath. However, jdeps -jdkinternals reports that we depend on > internal JDK APIs. Is it the case that we cannot avoid this warning but > that we are safe provided at runtime we use the classes in the openjdk-orb > jar? > > > > A follow up question is, if we add javax.orb.api as module dependency > (in our wildfly transactions subsystem) then at runtime will we be using > the classes provided by openjdk-orb? > > > > Thanks, > > Mike > > > > -- > > Michael Musgrove > > Transactions Team > > e: mmusgrov at redhat.com > > t: +44 191 243 0870 > > > > Registered in England and Wales under Company Registration No. 03798903 > > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > > (US), Charles Peters (US) > > > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > O'Neill(Ireland) > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- > Jason T. Greene > WildFly Lead / JBoss EAP Platform Architect > JBoss, a division of Red Hat > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/abf845a5/attachment-0001.html > > ------------------------------ > > Message: 4 > Date: Wed, 20 Jan 2016 11:45:32 -0500 (EST) > From: Tomasz Adamski > Subject: Re: [wildfly-dev] How to avoid depending on corba classes in > rt.jar > To: Jason Greene , Michael Musgrove > > Cc: WildFly Dev > Message-ID: > <883523971.10066138.1453308332564.JavaMail.zimbra at redhat.com> > Content-Type: text/plain; charset=utf-8 > > > A follow up question is, if we add javax.orb.api as module dependency (in > > our wildfly transactions subsystem) then at runtime will we be using the > > classes provided by openjdk-orb? > > If we use openjdk-orb in jboss-modules environment we are sure that > openjdk-orb is used as orb classes are not exported as system packages. > > > Is it the case that we cannot avoid this warning but > > that we are safe provided at runtime we use the classes in the > openjdk-orb > > jar? > > In standalone scenario it should work correctly too. I will look wheter > the error is caused by jdeps tool behaviour or do we indeed have some > unwanted runtime references to JDK. > > > We probably should rename the packages to avoid confusion. What do you > think > > Tomasz? > > This can be done but I see one problem: openjdk-orb is a hg repository and > we have possibility to synchronize it with JDK head if there are some > changes in ORB code. I would have to script it somehow to preserve such > possibility. But I agree that it will be nice to do. > > -- > Tomasz Adamski > Software Engineer > JBoss by Red Hat > > ----- Oryginalna wiadomo?? ----- > > Od: "Jason Greene" > > Do: "Michael Musgrove" > > DW: "WildFly Dev" , "Tomasz Adamski" < > tadamski at redhat.com> > > Wys?ane: ?roda, 20 stycze? 2016 17:13:04 > > Temat: Re: [wildfly-dev] How to avoid depending on corba classes in > rt.jar > > > > We probably should rename the packages to avoid confusion. What do you > think > > Tomasz? > > > > > > > On Jan 20, 2016, at 10:07 AM, Michael Musgrove > wrote: > > > > > > The narayana jts jar has dependencies on internal jdk orb classes. We > test > > > that it can work with the openjdk-orb by adding the openjdk-orb jar to > the > > > bootclasspath. However, jdeps -jdkinternals reports that we depend on > > > internal JDK APIs. Is it the case that we cannot avoid this warning but > > > that we are safe provided at runtime we use the classes in the > openjdk-orb > > > jar? > > > > > > A follow up question is, if we add javax.orb.api as module dependency > (in > > > our wildfly transactions subsystem) then at runtime will we be using > the > > > classes provided by openjdk-orb? > > > > > > Thanks, > > > Mike > > > > > > -- > > > Michael Musgrove > > > Transactions Team > > > e: mmusgrov at redhat.com > > > t: +44 191 243 0870 > > > > > > Registered in England and Wales under Company Registration No. 03798903 > > > Directors: Michael Cunningham (US), Paul Hickey (Ireland), Matt Parson > > > (US), Charles Peters (US) > > > > > > Michael Cunningham (US), Charles Peters (US), Matt Parson (US), Michael > > > O'Neill(Ireland) > > > _______________________________________________ > > > wildfly-dev mailing list > > > wildfly-dev at lists.jboss.org > > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > > Jason T. Greene > > WildFly Lead / JBoss EAP Platform Architect > > JBoss, a division of Red Hat > > > > > > > > ------------------------------ > > Message: 5 > Date: Wed, 20 Jan 2016 14:57:05 -0200 > From: Renann Prado > Subject: [wildfly-dev] Is there a wildfly-user list? > To: wildfly-dev at lists.jboss.org > Message-ID: > ARGS-2F4Vg2A-RsmdZM-Vnd5OU_K3zKU61EhwRA_3w at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hello. > > I took a look at the below link and couldn't find the wildfly-user list. > > https://lists.jboss.org/mailman/listinfo/ > > Looking at the jboss-user list, it doesn't to be too much of active. > > https://lists.jboss.org/mailman/listinfo/jboss-user > > So I was wondering if there is a better place to ask things other than the > wildfly forum. > > I know this is off-topic, sorry about that. > > > Renann Prado > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160120/dd01c533/attachment.html > > ------------------------------ > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > End of wildfly-dev Digest, Vol 34, Issue 3 > ****************************************** > -- shivraj -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160121/7fed44f0/attachment-0001.html From rodrigo.lira at tjpr.jus.br Thu Jan 21 11:59:47 2016 From: rodrigo.lira at tjpr.jus.br (Rodrigo Lira) Date: Thu, 21 Jan 2016 14:59:47 -0200 Subject: [wildfly-dev] Remote JMX access in Wildfly 8.2.1 In-Reply-To: <569FC6E7.9000309@gmail.com> References: <569FBFED.5010508@tjpr.jus.br> <569FC6E7.9000309@gmail.com> Message-ID: <56A10E83.6080509@tjpr.jus.br> Filippe, I added the option you said and reload the servers: /profile=full/subsystem=jmx/remoting-connector=jmx:add(use-management-endpoint=false) The options expose-resolved-model and expose-expression-model are default. However, I still can't connect to slave host. The only connection that works in slave is when I connect on port 9999 with address "service:jmx:remoting-jmx:host:9999", but the "jboss.as.*" MBeans aren't showed. I tried addresses "service:jmx:remoting-jmx:host:8080" and "service:jmx:http-remoting-jmx:host:8080" and nothing. I thought could be the user authentication, so I create the same user in mgmt-users.properties and application-users.properties but didn't work. Did I do anything wrong? Thanks, Rodrigo On 20-01-2016 15:41, Filippe spolti wrote: > This is switched on by default in standalone mode and accessible over > port 9990 but in domain mode is switched off so needs to be enabled - > in domain mode the port will be the port of the Remoting connector for > the WildFly 8 instance to be monitored. > > the jmx subsystem should looks like: > > > > > > > > Then use the server's http port to access the jmx. > > > > On 01/20/2016 03:12 PM, Rodrigo Lira wrote: >> Hi, >> >> After install WildFly in standalone mode I can access JMX with JConsole using the address service:jmx:http-remoting-jmx://host:9990, but when I install in domain mode only the domain controller is accessible, I can't connect in host slaves. How do I enable JMX in host slaves? >> >> > > -- > Regards, > --Filippe > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -- _______________________________________________ | Rodrigo Daniel C. Lira | Analista de Sistemas - Tribunal de Justi?a/PR | rodrigo.lira at tjpr.jus.br - (41) 3250-6344 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160121/52e1bb3f/attachment.html From kabir.khan at jboss.com Fri Jan 22 16:32:41 2016 From: kabir.khan at jboss.com (Kabir Khan) Date: Fri, 22 Jan 2016 21:32:41 +0000 Subject: [wildfly-dev] Remote JMX access in Wildfly 8.2.1 In-Reply-To: <56A10E83.6080509@tjpr.jus.br> References: <569FBFED.5010508@tjpr.jus.br> <569FC6E7.9000309@gmail.com> <56A10E83.6080509@tjpr.jus.br> Message-ID: <8458A524-4311-4E95-8E80-D11CE5F65C12@jboss.com> Please use the forums for user questions. However, subsystems from the elements are only installed on the host's servers, and not on the host controller itself. In WildFly 10 (and maybe in 9) we have host controller subsystems, where some (but not all) subsystems can be installed in host.xml. JMX is one of the ones which can be installed on the host controller, but it will only give you a read-only view of jmx. > On 21 Jan 2016, at 16:59, Rodrigo Lira wrote: > > Filippe, > > I added the option you said and reload the servers: > > /profile=full/subsystem=jmx/remoting-connector=jmx:add(use-management-endpoint=false) > > The options expose-resolved-model and expose-expression-model are default. However, I still can't connect to slave host. The only connection that works in slave is when I connect on port 9999 with address "service:jmx:remoting-jmx:host:9999", but the "jboss.as.*" MBeans aren't showed. > > I tried addresses "service:jmx:remoting-jmx:host:8080" and "service:jmx:http-remoting-jmx:host:8080" and nothing. > I thought could be the user authentication, so I create the same user in mgmt-users.properties and application-users.properties but didn't work. > > Did I do anything wrong? > > Thanks, > > Rodrigo > > > On 20-01-2016 15:41, Filippe spolti wrote: >> This is switched on by default in standalone mode and accessible over port 9990 but in domain mode is switched off so needs to be enabled - in domain mode the port will be the port of the Remoting connector for the WildFly 8 instance to be monitored. >> >> the jmx subsystem should looks like: >> >> >> >> >> >> >> >> Then use the server's http port to access the jmx. >> >> >> >> On 01/20/2016 03:12 PM, Rodrigo Lira wrote: >>> Hi, >>> >>> After install WildFly in standalone mode I can access JMX with JConsole using the address service:jmx:http-remoting-jmx://host:9990, but when I install in domain mode only the domain controller is accessible, I can't connect in host slaves. How do I enable JMX in host slaves? >>> >>> >>> >> >> -- >> Regards, >> --Filippe >> >> >> >> _______________________________________________ >> wildfly-dev mailing list >> >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > -- > _______________________________________________ > | Rodrigo Daniel C. Lira > | Analista de Sistemas - Tribunal de Justi?a/PR > | rodrigo.lira at tjpr.jus.br - (41) 3250-6344 > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev From brian.stansberry at redhat.com Wed Jan 27 17:55:45 2016 From: brian.stansberry at redhat.com (Brian Stansberry) Date: Wed, 27 Jan 2016 16:55:45 -0600 Subject: [wildfly-dev] Timeout errors in JCA bits in testsuite Message-ID: <56A94AF1.7040501@redhat.com> In the last day I've seen 3 different CI runs fail due to various JCA related tests in testsuite/basic not completing. Does anyone have any idea what might be causing this? The ones I noticed were all PR tests of changes in core. It's hard to imagine the PRs themselves were relevant. They do test a snapshot of core though, so it's possible some change in core is relevant, in addition to the simpler scenario of some issue in full. 1) Just now: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildTypeId=WildFlyCore_PullRequest_WildFlyCoreFullIntegration&buildId=87619 [22:05:58][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase [22:06:00][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 2.084 sec - in org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase [22:06:00][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase [22:06:02][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.598 sec - in org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase [22:06:02][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase [22:30:48][org.wildfly:wildfly-ts-integ-basic] [22:30:48][org.wildfly:wildfly-ts-integ-basic] Results : [22:30:48][org.wildfly:wildfly-ts-integ-basic] [22:30:48][org.wildfly:wildfly-ts-integ-basic] Tests run: 8, Failures: 0, Errors: 0, Skipped: 0 [22:30:48][org.wildfly:wildfly-ts-integ-basic] [22:30:48][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a timeout or other error in the fork 2) Yesterday: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=87585&tab=buildResultsDiv&buildTypeId=WF_WildFlyCoreIntegrationExperiments [14:48:42][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.beanvalidation.PositiveValidationTestCase [14:48:43][org.wildfly:wildfly-ts-integ-basic] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.669 sec - in org.jboss.as.test.integration.jca.beanvalidation.PositiveValidationTestCase [14:48:43][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.capacitypolicies.DatasourceCapacityPoliciesTestCase [14:48:44][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.98 sec - in org.jboss.as.test.integration.jca.capacitypolicies.DatasourceCapacityPoliciesTestCase [14:48:44][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.capacitypolicies.ResourceAdapterCapacityPoliciesTestCase [14:48:44][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.766 sec - in org.jboss.as.test.integration.jca.capacitypolicies.ResourceAdapterCapacityPoliciesTestCase [14:48:44][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.capacitypolicies.XADatasourceCapacityPoliciesTestCase [14:48:45][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.718 sec - in org.jboss.as.test.integration.jca.capacitypolicies.XADatasourceCapacityPoliciesTestCase [14:48:45][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase [14:48:51][org.wildfly:wildfly-ts-integ-basic] Tests run: 6, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 5.881 sec - in org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase [14:48:51][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase [15:07:51][org.wildfly:wildfly-ts-integ-basic] [15:07:51][org.wildfly:wildfly-ts-integ-basic] Results : [15:07:51][org.wildfly:wildfly-ts-integ-basic] [15:07:51][org.wildfly:wildfly-ts-integ-basic] Tests run: 761, Failures: 0, Errors: 0, Skipped: 12 [15:07:51][org.wildfly:wildfly-ts-integ-basic] [15:07:51][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a timeout or other error in the fork 3) Yesterday: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=87425&tab=buildResultsDiv&buildTypeId=WF_WildFlyCoreIntegrationExperiments [01:38:34][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase [01:38:36][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.583 sec - in org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase [01:38:36][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase [01:38:37][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.215 sec - in org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase [01:38:37][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase [01:38:38][org.wildfly:wildfly-ts-integ-basic] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.23 sec - in org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase [01:38:38][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase [01:38:40][org.wildfly:wildfly-ts-integ-basic] Tests run: 2, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.086 sec - in org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase [01:38:40][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.moduledeployment.MultiActivationFlatTestCase [01:38:41][org.wildfly:wildfly-ts-integ-basic] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.165 sec - in org.jboss.as.test.integration.jca.moduledeployment.MultiActivationFlatTestCase [01:38:41][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.moduledeployment.MultiActivationJarTestCase [01:38:42][org.wildfly:wildfly-ts-integ-basic] Tests run: 7, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.111 sec - in org.jboss.as.test.integration.jca.moduledeployment.MultiActivationJarTestCase [01:38:42][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationFlatTestCase [01:38:43][org.wildfly:wildfly-ts-integ-basic] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.694 sec - in org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationFlatTestCase [01:38:43][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationJarTestCase [01:38:45][org.wildfly:wildfly-ts-integ-basic] Tests run: 5, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 1.24 sec - in org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationJarTestCase [01:38:45][org.wildfly:wildfly-ts-integ-basic] Running org.jboss.as.test.integration.jca.moduledeployment.PartialObjectActivationFlatTestCase [02:03:26][org.wildfly:wildfly-ts-integ-basic] [02:03:26][org.wildfly:wildfly-ts-integ-basic] Results : [02:03:26][org.wildfly:wildfly-ts-integ-basic] [02:03:26][org.wildfly:wildfly-ts-integ-basic] Tests run: 36, Failures: 0, Errors: 0, Skipped: 0 [02:03:26][org.wildfly:wildfly-ts-integ-basic] [02:03:26][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a timeout or other error in the fork -- Brian Stansberry Senior Principal Software Engineer JBoss by Red Hat From eduardo.santanadasilva at gmail.com Wed Jan 27 21:24:17 2016 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Thu, 28 Jan 2016 00:24:17 -0200 Subject: [wildfly-dev] Timeout errors in JCA bits in testsuite In-Reply-To: <56A94AF1.7040501@redhat.com> References: <56A94AF1.7040501@redhat.com> Message-ID: Seems that this is related to maven, probably something its taking more time than due. https://maven.apache.org/surefire/maven-failsafe-plugin/examples/shutdown.html 2016-01-27 20:55 GMT-02:00 Brian Stansberry : > In the last day I've seen 3 different CI runs fail due to various JCA > related tests in testsuite/basic not completing. Does anyone have any > idea what might be causing this? > > The ones I noticed were all PR tests of changes in core. It's hard to > imagine the PRs themselves were relevant. They do test a snapshot of > core though, so it's possible some change in core is relevant, in > addition to the simpler scenario of some issue in full. > > 1) Just now: > > > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildTypeId=WildFlyCore_PullRequest_WildFlyCoreFullIntegration&buildId=87619 > > [22:05:58][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase > [22:06:00][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 2.084 sec - in > org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase > [22:06:00][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase > [22:06:02][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.598 sec - in > org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase > [22:06:02][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase > [22:30:48][org.wildfly:wildfly-ts-integ-basic] > [22:30:48][org.wildfly:wildfly-ts-integ-basic] Results : > [22:30:48][org.wildfly:wildfly-ts-integ-basic] > [22:30:48][org.wildfly:wildfly-ts-integ-basic] Tests run: 8, Failures: > 0, Errors: 0, Skipped: 0 > [22:30:48][org.wildfly:wildfly-ts-integ-basic] > [22:30:48][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a > timeout or other error in the fork > > 2) Yesterday: > > > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=87585&tab=buildResultsDiv&buildTypeId=WF_WildFlyCoreIntegrationExperiments > > [14:48:42][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.beanvalidation.PositiveValidationTestCase > [14:48:43][org.wildfly:wildfly-ts-integ-basic] Tests run: 3, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 0.669 sec - in > org.jboss.as.test.integration.jca.beanvalidation.PositiveValidationTestCase > [14:48:43][org.wildfly:wildfly-ts-integ-basic] Running > > org.jboss.as.test.integration.jca.capacitypolicies.DatasourceCapacityPoliciesTestCase > [14:48:44][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 0.98 sec - in > > org.jboss.as.test.integration.jca.capacitypolicies.DatasourceCapacityPoliciesTestCase > [14:48:44][org.wildfly:wildfly-ts-integ-basic] Running > > org.jboss.as.test.integration.jca.capacitypolicies.ResourceAdapterCapacityPoliciesTestCase > [14:48:44][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 0.766 sec - in > > org.jboss.as.test.integration.jca.capacitypolicies.ResourceAdapterCapacityPoliciesTestCase > [14:48:44][org.wildfly:wildfly-ts-integ-basic] Running > > org.jboss.as.test.integration.jca.capacitypolicies.XADatasourceCapacityPoliciesTestCase > [14:48:45][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 0.718 sec - in > > org.jboss.as.test.integration.jca.capacitypolicies.XADatasourceCapacityPoliciesTestCase > [14:48:45][org.wildfly:wildfly-ts-integ-basic] Running > > org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase > [14:48:51][org.wildfly:wildfly-ts-integ-basic] Tests run: 6, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 5.881 sec - in > > org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase > [14:48:51][org.wildfly:wildfly-ts-integ-basic] Running > > org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase > [15:07:51][org.wildfly:wildfly-ts-integ-basic] > [15:07:51][org.wildfly:wildfly-ts-integ-basic] Results : > [15:07:51][org.wildfly:wildfly-ts-integ-basic] > [15:07:51][org.wildfly:wildfly-ts-integ-basic] Tests run: 761, Failures: > 0, Errors: 0, Skipped: 12 > [15:07:51][org.wildfly:wildfly-ts-integ-basic] > [15:07:51][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a > timeout or other error in the fork > > 3) Yesterday: > > > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=87425&tab=buildResultsDiv&buildTypeId=WF_WildFlyCoreIntegrationExperiments > > [01:38:34][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase > [01:38:36][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.583 sec - in > org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase > [01:38:36][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase > [01:38:37][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.215 sec - in > org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase > [01:38:37][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase > [01:38:38][org.wildfly:wildfly-ts-integ-basic] Tests run: 2, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.23 sec - in > org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase > [01:38:38][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase > [01:38:40][org.wildfly:wildfly-ts-integ-basic] Tests run: 2, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.086 sec - in > org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase > [01:38:40][org.wildfly:wildfly-ts-integ-basic] Running > > org.jboss.as.test.integration.jca.moduledeployment.MultiActivationFlatTestCase > [01:38:41][org.wildfly:wildfly-ts-integ-basic] Tests run: 7, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.165 sec - in > > org.jboss.as.test.integration.jca.moduledeployment.MultiActivationFlatTestCase > [01:38:41][org.wildfly:wildfly-ts-integ-basic] Running > > org.jboss.as.test.integration.jca.moduledeployment.MultiActivationJarTestCase > [01:38:42][org.wildfly:wildfly-ts-integ-basic] Tests run: 7, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.111 sec - in > > org.jboss.as.test.integration.jca.moduledeployment.MultiActivationJarTestCase > [01:38:42][org.wildfly:wildfly-ts-integ-basic] Running > > org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationFlatTestCase > [01:38:43][org.wildfly:wildfly-ts-integ-basic] Tests run: 5, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.694 sec - in > > org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationFlatTestCase > [01:38:43][org.wildfly:wildfly-ts-integ-basic] Running > > org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationJarTestCase > [01:38:45][org.wildfly:wildfly-ts-integ-basic] Tests run: 5, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.24 sec - in > > org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationJarTestCase > [01:38:45][org.wildfly:wildfly-ts-integ-basic] Running > > org.jboss.as.test.integration.jca.moduledeployment.PartialObjectActivationFlatTestCase > [02:03:26][org.wildfly:wildfly-ts-integ-basic] > [02:03:26][org.wildfly:wildfly-ts-integ-basic] Results : > [02:03:26][org.wildfly:wildfly-ts-integ-basic] > [02:03:26][org.wildfly:wildfly-ts-integ-basic] Tests run: 36, Failures: > 0, Errors: 0, Skipped: 0 > [02:03:26][org.wildfly:wildfly-ts-integ-basic] > [02:03:26][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a > timeout or other error in the fork > > -- > Brian Stansberry > Senior Principal Software Engineer > JBoss by Red Hat > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160128/d87a05e2/attachment-0001.html From cdewolf at redhat.com Thu Jan 28 03:58:30 2016 From: cdewolf at redhat.com (Carlo de Wolf) Date: Thu, 28 Jan 2016 09:58:30 +0100 Subject: [wildfly-dev] Timeout errors in JCA bits in testsuite In-Reply-To: <56A94AF1.7040501@redhat.com> References: <56A94AF1.7040501@redhat.com> Message-ID: <56A9D836.8040202@redhat.com> There should be no SNAPSHOT dependencies in any CI build. While it does build core beforehand, it might get overwritten by another CI run. //[org.wildfly.core:wildfly-core-parent] /[INFO] Installing /opt/buildAgent/work/db872761b443af46/core/pom.xml to /store/repository/org/wildfly/core/wildfly-core-parent/2.0.8.Final-SNAPSHOT/wildfly-core-parent-2.0.8.Final-SNAPSHOT.pom / Would it be possible to use timed snapshots instead? Carlo On 01/27/2016 11:55 PM, Brian Stansberry wrote: > In the last day I've seen 3 different CI runs fail due to various JCA > related tests in testsuite/basic not completing. Does anyone have any > idea what might be causing this? > > The ones I noticed were all PR tests of changes in core. It's hard to > imagine the PRs themselves were relevant. They do test a snapshot of > core though, so it's possible some change in core is relevant, in > addition to the simpler scenario of some issue in full. > > 1) Just now: > > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildTypeId=WildFlyCore_PullRequest_WildFlyCoreFullIntegration&buildId=87619 > > [22:05:58][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase > [22:06:00][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 2.084 sec - in > org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase > [22:06:00][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase > [22:06:02][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.598 sec - in > org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase > [22:06:02][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase > [22:30:48][org.wildfly:wildfly-ts-integ-basic] > [22:30:48][org.wildfly:wildfly-ts-integ-basic] Results : > [22:30:48][org.wildfly:wildfly-ts-integ-basic] > [22:30:48][org.wildfly:wildfly-ts-integ-basic] Tests run: 8, Failures: > 0, Errors: 0, Skipped: 0 > [22:30:48][org.wildfly:wildfly-ts-integ-basic] > [22:30:48][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a > timeout or other error in the fork > > 2) Yesterday: > > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=87585&tab=buildResultsDiv&buildTypeId=WF_WildFlyCoreIntegrationExperiments > > [14:48:42][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.beanvalidation.PositiveValidationTestCase > [14:48:43][org.wildfly:wildfly-ts-integ-basic] Tests run: 3, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 0.669 sec - in > org.jboss.as.test.integration.jca.beanvalidation.PositiveValidationTestCase > [14:48:43][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.capacitypolicies.DatasourceCapacityPoliciesTestCase > [14:48:44][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 0.98 sec - in > org.jboss.as.test.integration.jca.capacitypolicies.DatasourceCapacityPoliciesTestCase > [14:48:44][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.capacitypolicies.ResourceAdapterCapacityPoliciesTestCase > [14:48:44][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 0.766 sec - in > org.jboss.as.test.integration.jca.capacitypolicies.ResourceAdapterCapacityPoliciesTestCase > [14:48:44][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.capacitypolicies.XADatasourceCapacityPoliciesTestCase > [14:48:45][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 0.718 sec - in > org.jboss.as.test.integration.jca.capacitypolicies.XADatasourceCapacityPoliciesTestCase > [14:48:45][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase > [14:48:51][org.wildfly:wildfly-ts-integ-basic] Tests run: 6, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 5.881 sec - in > org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase > [14:48:51][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase > [15:07:51][org.wildfly:wildfly-ts-integ-basic] > [15:07:51][org.wildfly:wildfly-ts-integ-basic] Results : > [15:07:51][org.wildfly:wildfly-ts-integ-basic] > [15:07:51][org.wildfly:wildfly-ts-integ-basic] Tests run: 761, Failures: > 0, Errors: 0, Skipped: 12 > [15:07:51][org.wildfly:wildfly-ts-integ-basic] > [15:07:51][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a > timeout or other error in the fork > > 3) Yesterday: > > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=87425&tab=buildResultsDiv&buildTypeId=WF_WildFlyCoreIntegrationExperiments > > [01:38:34][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase > [01:38:36][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.583 sec - in > org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase > [01:38:36][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase > [01:38:37][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.215 sec - in > org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase > [01:38:37][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase > [01:38:38][org.wildfly:wildfly-ts-integ-basic] Tests run: 2, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.23 sec - in > org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase > [01:38:38][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase > [01:38:40][org.wildfly:wildfly-ts-integ-basic] Tests run: 2, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.086 sec - in > org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase > [01:38:40][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.MultiActivationFlatTestCase > [01:38:41][org.wildfly:wildfly-ts-integ-basic] Tests run: 7, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.165 sec - in > org.jboss.as.test.integration.jca.moduledeployment.MultiActivationFlatTestCase > [01:38:41][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.MultiActivationJarTestCase > [01:38:42][org.wildfly:wildfly-ts-integ-basic] Tests run: 7, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.111 sec - in > org.jboss.as.test.integration.jca.moduledeployment.MultiActivationJarTestCase > [01:38:42][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationFlatTestCase > [01:38:43][org.wildfly:wildfly-ts-integ-basic] Tests run: 5, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.694 sec - in > org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationFlatTestCase > [01:38:43][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationJarTestCase > [01:38:45][org.wildfly:wildfly-ts-integ-basic] Tests run: 5, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.24 sec - in > org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationJarTestCase > [01:38:45][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.PartialObjectActivationFlatTestCase > [02:03:26][org.wildfly:wildfly-ts-integ-basic] > [02:03:26][org.wildfly:wildfly-ts-integ-basic] Results : > [02:03:26][org.wildfly:wildfly-ts-integ-basic] > [02:03:26][org.wildfly:wildfly-ts-integ-basic] Tests run: 36, Failures: > 0, Errors: 0, Skipped: 0 > [02:03:26][org.wildfly:wildfly-ts-integ-basic] > [02:03:26][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a > timeout or other error in the fork > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160128/b1066e64/attachment.html From stuart.w.douglas at gmail.com Thu Jan 28 04:32:49 2016 From: stuart.w.douglas at gmail.com (Stuart Douglas) Date: Thu, 28 Jan 2016 09:32:49 +0000 Subject: [wildfly-dev] Timeout errors in JCA bits in testsuite In-Reply-To: <56A9D836.8040202@redhat.com> References: <56A94AF1.7040501@redhat.com> <56A9D836.8040202@redhat.com> Message-ID: The whole point of these builds is that it first builds a snapshot of core, then builds full using this snapshot. This verfies that changes in core have not broken anything in full. Stuart On Thu, 28 Jan 2016 at 19:58 Carlo de Wolf wrote: > There should be no SNAPSHOT dependencies in any CI build. While it does > build core beforehand, it might get overwritten by another CI run. > > *[org.wildfly.core:wildfly-core-parent] [INFO] Installing > /opt/buildAgent/work/db872761b443af46/core/pom.xml to > /store/repository/org/wildfly/core/wildfly-core-parent/2.0.8.Final-SNAPSHOT/wildfly-core-parent-2.0.8.Final-SNAPSHOT.pom > * > Would it be possible to use timed snapshots instead? > > > Carlo > > > On 01/27/2016 11:55 PM, Brian Stansberry wrote: > > In the last day I've seen 3 different CI runs fail due to various JCA > related tests in testsuite/basic not completing. Does anyone have any > idea what might be causing this? > > The ones I noticed were all PR tests of changes in core. It's hard to > imagine the PRs themselves were relevant. They do test a snapshot of > core though, so it's possible some change in core is relevant, in > addition to the simpler scenario of some issue in full. > > 1) Just now: > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildTypeId=WildFlyCore_PullRequest_WildFlyCoreFullIntegration&buildId=87619 > > [22:05:58][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase > [22:06:00][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 2.084 sec - in > org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase > [22:06:00][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase > [22:06:02][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.598 sec - in > org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase > [22:06:02][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase > [22:30:48][org.wildfly:wildfly-ts-integ-basic] > [22:30:48][org.wildfly:wildfly-ts-integ-basic] Results : > [22:30:48][org.wildfly:wildfly-ts-integ-basic] > [22:30:48][org.wildfly:wildfly-ts-integ-basic] Tests run: 8, Failures: > 0, Errors: 0, Skipped: 0 > [22:30:48][org.wildfly:wildfly-ts-integ-basic] > [22:30:48][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a > timeout or other error in the fork > > 2) Yesterday: > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=87585&tab=buildResultsDiv&buildTypeId=WF_WildFlyCoreIntegrationExperiments > > [14:48:42][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.beanvalidation.PositiveValidationTestCase > [14:48:43][org.wildfly:wildfly-ts-integ-basic] Tests run: 3, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 0.669 sec - in > org.jboss.as.test.integration.jca.beanvalidation.PositiveValidationTestCase > [14:48:43][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.capacitypolicies.DatasourceCapacityPoliciesTestCase > [14:48:44][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 0.98 sec - in > org.jboss.as.test.integration.jca.capacitypolicies.DatasourceCapacityPoliciesTestCase > [14:48:44][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.capacitypolicies.ResourceAdapterCapacityPoliciesTestCase > [14:48:44][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 0.766 sec - in > org.jboss.as.test.integration.jca.capacitypolicies.ResourceAdapterCapacityPoliciesTestCase > [14:48:44][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.capacitypolicies.XADatasourceCapacityPoliciesTestCase > [14:48:45][org.wildfly:wildfly-ts-integ-basic] Tests run: 1, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 0.718 sec - in > org.jboss.as.test.integration.jca.capacitypolicies.XADatasourceCapacityPoliciesTestCase > [14:48:45][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase > [14:48:51][org.wildfly:wildfly-ts-integ-basic] Tests run: 6, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 5.881 sec - in > org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestCase > [14:48:51][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase > [15:07:51][org.wildfly:wildfly-ts-integ-basic] > [15:07:51][org.wildfly:wildfly-ts-integ-basic] Results : > [15:07:51][org.wildfly:wildfly-ts-integ-basic] > [15:07:51][org.wildfly:wildfly-ts-integ-basic] Tests run: 761, Failures: > 0, Errors: 0, Skipped: 12 > [15:07:51][org.wildfly:wildfly-ts-integ-basic] > [15:07:51][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a > timeout or other error in the fork > > 3) Yesterday: > http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=87425&tab=buildResultsDiv&buildTypeId=WF_WildFlyCoreIntegrationExperiments > > [01:38:34][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase > [01:38:36][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.583 sec - in > org.jboss.as.test.integration.jca.moduledeployment.BasicFlatTestCase > [01:38:36][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase > [01:38:37][org.wildfly:wildfly-ts-integ-basic] Tests run: 4, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.215 sec - in > org.jboss.as.test.integration.jca.moduledeployment.BasicJarTestCase > [01:38:37][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase > [01:38:38][org.wildfly:wildfly-ts-integ-basic] Tests run: 2, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.23 sec - in > org.jboss.as.test.integration.jca.moduledeployment.InflowFlatTestCase > [01:38:38][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase > [01:38:40][org.wildfly:wildfly-ts-integ-basic] Tests run: 2, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.086 sec - in > org.jboss.as.test.integration.jca.moduledeployment.InflowJarTestCase > [01:38:40][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.MultiActivationFlatTestCase > [01:38:41][org.wildfly:wildfly-ts-integ-basic] Tests run: 7, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.165 sec - in > org.jboss.as.test.integration.jca.moduledeployment.MultiActivationFlatTestCase > [01:38:41][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.MultiActivationJarTestCase > [01:38:42][org.wildfly:wildfly-ts-integ-basic] Tests run: 7, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.111 sec - in > org.jboss.as.test.integration.jca.moduledeployment.MultiActivationJarTestCase > [01:38:42][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationFlatTestCase > [01:38:43][org.wildfly:wildfly-ts-integ-basic] Tests run: 5, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.694 sec - in > org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationFlatTestCase > [01:38:43][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationJarTestCase > [01:38:45][org.wildfly:wildfly-ts-integ-basic] Tests run: 5, Failures: > 0, Errors: 0, Skipped: 0, Time elapsed: 1.24 sec - in > org.jboss.as.test.integration.jca.moduledeployment.MultiObjectActivationJarTestCase > [01:38:45][org.wildfly:wildfly-ts-integ-basic] Running > org.jboss.as.test.integration.jca.moduledeployment.PartialObjectActivationFlatTestCase > [02:03:26][org.wildfly:wildfly-ts-integ-basic] > [02:03:26][org.wildfly:wildfly-ts-integ-basic] Results : > [02:03:26][org.wildfly:wildfly-ts-integ-basic] > [02:03:26][org.wildfly:wildfly-ts-integ-basic] Tests run: 36, Failures: > 0, Errors: 0, Skipped: 0 > [02:03:26][org.wildfly:wildfly-ts-integ-basic] > [02:03:26][org.wildfly:wildfly-ts-integ-basic] [ERROR] There was a > timeout or other error in the fork > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160128/0ae6ec07/attachment-0001.html From thofman at redhat.com Thu Jan 28 06:10:36 2016 From: thofman at redhat.com (Tomas Hofman) Date: Thu, 28 Jan 2016 12:10:36 +0100 Subject: [wildfly-dev] Proposal: Option to disable FileAuditLogHandler log rotation Message-ID: <56A9F72C.6070505@redhat.com> Hello, currently FileAuditLogHandler rotates audit-log.log file during every start up (or reload) and there is no option to turn this behavior off. This clashes with users who want to use f.i. logrotate to perform log rotation [1]. Apart from FileAuditLogHandler, there are also PeriodicRotatingFileAuditLogHandler and SizeRotatingFileAuditLogHandler available, which perform the log rotation on regular interval resp. file size basis. I would like to introduce an attribute "rotate-at-startup" into FileAuditLogHandler definition which would allow to disable this behavior, so the log file would be appended instead of rotated. Is that a bad idea for some reason? [1] https://bugzilla.redhat.com/show_bug.cgi?id=1301554 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160128/a18fff2c/attachment.html From tomaz.cerar at gmail.com Thu Jan 28 06:54:30 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 28 Jan 2016 12:54:30 +0100 Subject: [wildfly-dev] Timeout errors in JCA bits in testsuite In-Reply-To: <56A9D836.8040202@redhat.com> References: <56A94AF1.7040501@redhat.com> <56A9D836.8040202@redhat.com> Message-ID: On Thu, Jan 28, 2016 at 9:58 AM, Carlo de Wolf wrote: > There should be no SNAPSHOT dependencies in any CI build. While it does > build core beforehand, it might get overwritten by another CI run. > > *[org.wildfly.core:wildfly-core-parent] [INFO] Installing > /opt/buildAgent/work/db872761b443af46/core/pom.xml to > /store/repository/org/wildfly/core/wildfly-core-parent/2.0.8.Final-SNAPSHOT/wildfly-core-parent-2.0.8.Final-SNAPSHOT.pom > * > Would it be possible to use timed snapshots instead? > As Stuart said, whole point of this builds is to have snapshot builds. Same build agent first builds core (clean install) and than builds full with -Dversion.wildfly.core= snapshot used here are only build agent local, not publish on some outside nexus repository. -- tomaz -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160128/e88a3a4f/attachment.html From tomaz.cerar at gmail.com Thu Jan 28 06:55:02 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 28 Jan 2016 12:55:02 +0100 Subject: [wildfly-dev] Timeout errors in JCA bits in testsuite In-Reply-To: References: <56A94AF1.7040501@redhat.com> Message-ID: On Thu, Jan 28, 2016 at 3:24 AM, Eduardo Sant?Ana da Silva < eduardo.santanadasilva at gmail.com> wrote: > Seems that this is related to maven, probably something its taking more > time than due. > > > https://maven.apache.org/surefire/maven-failsafe-plugin/examples/shutdown.html > yes those test hang, so after a certain time CI kills the job. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160128/709f73dd/attachment.html From eduardo.santanadasilva at gmail.com Thu Jan 28 07:37:05 2016 From: eduardo.santanadasilva at gmail.com (=?UTF-8?Q?Eduardo_Sant=C2=B4Ana_da_Silva?=) Date: Thu, 28 Jan 2016 10:37:05 -0200 Subject: [wildfly-dev] Timeout errors in JCA bits in testsuite In-Reply-To: References: <56A94AF1.7040501@redhat.com> <56A9D836.8040202@redhat.com> Message-ID: I faced a similar problem recently. About this issue, my doubt is that if there is no nexus repository operation, and the build is done sequentially, first core (installing locally), after that the wildfly entire build, how this timeout is occurring? Seems that this could be a common problem if the maven is executing in parallel and those intermittent problems can occur due synchronization issues. To resolve my problem I first resolve the dependencies recently installed on local repository through: mvn dependency:build-classpath --- eduardo 2016-01-28 9:54 GMT-02:00 Toma? Cerar : > > On Thu, Jan 28, 2016 at 9:58 AM, Carlo de Wolf wrote: > >> There should be no SNAPSHOT dependencies in any CI build. While it does >> build core beforehand, it might get overwritten by another CI run. >> >> *[org.wildfly.core:wildfly-core-parent] [INFO] Installing >> /opt/buildAgent/work/db872761b443af46/core/pom.xml to >> /store/repository/org/wildfly/core/wildfly-core-parent/2.0.8.Final-SNAPSHOT/wildfly-core-parent-2.0.8.Final-SNAPSHOT.pom >> * >> Would it be possible to use timed snapshots instead? >> > > > As Stuart said, whole point of this builds is to have snapshot builds. > Same build agent first builds core (clean install) and than builds full > with -Dversion.wildfly.core= > > snapshot used here are only build agent local, not publish on some outside > nexus repository. > > -- > tomaz > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -- __________________________ Eduardo Sant'Ana da Silva - Dr. Pesquisador / Consultor de TI -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160128/6627ac88/attachment.html From jason.greene at redhat.com Thu Jan 28 08:12:27 2016 From: jason.greene at redhat.com (Jason T. Greene) Date: Thu, 28 Jan 2016 08:12:27 -0500 (EST) Subject: [wildfly-dev] Timeout errors in JCA bits in testsuite In-Reply-To: References: <56A94AF1.7040501@redhat.com> <56A9D836.8040202@redhat.com> Message-ID: <1EE1A051-ACCF-4834-8DF1-9DF50ED72BA0@redhat.com> It happens when a test hangs. So we have to get stack traces of the process when this occurs to even know where to being to look. > On Jan 28, 2016, at 6:38 AM, Eduardo Sant?Ana da Silva wrote: > > I faced a similar problem recently. > About this issue, my doubt is that if there is no nexus repository operation, and the build is done sequentially, first core (installing locally), after that the wildfly entire build, how this timeout is occurring? > > Seems that this could be a common problem if the maven is executing in parallel and those intermittent problems can occur due synchronization issues. > > To resolve my problem I first resolve the dependencies recently installed on local repository through: mvn dependency:build-classpath > > --- > eduardo > > 2016-01-28 9:54 GMT-02:00 Toma? Cerar : >> >>> On Thu, Jan 28, 2016 at 9:58 AM, Carlo de Wolf wrote: >>> There should be no SNAPSHOT dependencies in any CI build. While it does build core beforehand, it might get overwritten by another CI run. >>> [org.wildfly.core:wildfly-core-parent] [INFO] Installing /opt/buildAgent/work/db872761b443af46/core/pom.xml to /store/repository/org/wildfly/core/wildfly-core-parent/2.0.8.Final-SNAPSHOT/wildfly-core-parent-2.0.8.Final-SNAPSHOT.pom >>> >>> Would it be possible to use timed snapshots instead? >> >> >> As Stuart said, whole point of this builds is to have snapshot builds. >> Same build agent first builds core (clean install) and than builds full >> with -Dversion.wildfly.core= >> >> snapshot used here are only build agent local, not publish on some outside nexus repository. >> >> -- >> tomaz >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > -- > __________________________ > Eduardo Sant'Ana da Silva - Dr. > Pesquisador / Consultor de TI > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160128/2a30ee4f/attachment-0001.html From tomaz.cerar at gmail.com Thu Jan 28 11:26:00 2016 From: tomaz.cerar at gmail.com (=?UTF-8?B?VG9tYcW+IENlcmFy?=) Date: Thu, 28 Jan 2016 17:26:00 +0100 Subject: [wildfly-dev] Timeout errors in JCA bits in testsuite In-Reply-To: <1EE1A051-ACCF-4834-8DF1-9DF50ED72BA0@redhat.com> References: <56A94AF1.7040501@redhat.com> <56A9D836.8040202@redhat.com> <1EE1A051-ACCF-4834-8DF1-9DF50ED72BA0@redhat.com> Message-ID: it just hanged again, this is the thread dump http://fpaste.org/315834/53998306/raw/ On Thu, Jan 28, 2016 at 2:12 PM, Jason T. Greene wrote: > It happens when a test hangs. So we have to get stack traces of the > process when this occurs to even know where to being to look. > > On Jan 28, 2016, at 6:38 AM, Eduardo Sant?Ana da Silva < > eduardo.santanadasilva at gmail.com> wrote: > > I faced a similar problem recently. > About this issue, my doubt is that if there is no nexus repository > operation, and the build is done sequentially, first core (installing > locally), after that the wildfly entire build, how this timeout is > occurring? > > Seems that this could be a common problem if the maven is executing in > parallel and those intermittent problems can occur due synchronization > issues. > > To resolve my problem I first resolve the dependencies recently installed > on local repository through: mvn dependency:build-classpath > > --- > eduardo > > 2016-01-28 9:54 GMT-02:00 Toma? Cerar : > >> >> On Thu, Jan 28, 2016 at 9:58 AM, Carlo de Wolf >> wrote: >> >>> There should be no SNAPSHOT dependencies in any CI build. While it does >>> build core beforehand, it might get overwritten by another CI run. >>> >>> *[org.wildfly.core:wildfly-core-parent] [INFO] Installing >>> /opt/buildAgent/work/db872761b443af46/core/pom.xml to >>> /store/repository/org/wildfly/core/wildfly-core-parent/2.0.8.Final-SNAPSHOT/wildfly-core-parent-2.0.8.Final-SNAPSHOT.pom >>> * >>> Would it be possible to use timed snapshots instead? >>> >> >> >> As Stuart said, whole point of this builds is to have snapshot builds. >> Same build agent first builds core (clean install) and than builds full >> with -Dversion.wildfly.core= >> >> snapshot used here are only build agent local, not publish on some >> outside nexus repository. >> >> -- >> tomaz >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> > > > > -- > __________________________ > Eduardo Sant'Ana da Silva - Dr. > Pesquisador / Consultor de TI > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160128/9de60b6b/attachment.html From jason.greene at redhat.com Thu Jan 28 11:35:05 2016 From: jason.greene at redhat.com (Jason Greene) Date: Thu, 28 Jan 2016 10:35:05 -0600 Subject: [wildfly-dev] Timeout errors in JCA bits in testsuite In-Reply-To: References: <56A94AF1.7040501@redhat.com> <56A9D836.8040202@redhat.com> <1EE1A051-ACCF-4834-8DF1-9DF50ED72BA0@redhat.com> Message-ID: Thats the server VM which seems in normal condition. Here is the surefire VM that is hanging: http://fpaste.org/315840/98783145/ Relevant section is: "main" #1 prio=5 os_prio=0 tid=0xf6606c00 nid=0x4066 in Object.wait() [0xf6752000] java.lang.Thread.State: WAITING (on object monitor) at java.lang.Object.wait(Native Method) at java.lang.Object.wait(Object.java:502) at org.xnio.AbstractIoFuture.await(AbstractIoFuture.java:71) - locked <0xe0081818> (a java.lang.Object) at org.xnio.AbstractIoFuture.get(AbstractIoFuture.java:167) - locked <0xe0081818> (a java.lang.Object) at org.jboss.as.protocol.mgmt.FutureManagementChannel.openChannel(FutureManagementChannel.java:154) at org.jboss.as.protocol.mgmt.ManagementClientChannelStrategy$Establishing.openChannel(ManagementClientChannelStrategy.java:150) at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.connectionOpened(FutureManagementChannel.java:223) at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:79) - locked <0xe007d870> (a org.jboss.as.protocol.ProtocolConnectionManager) at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:212) at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:146) - locked <0xe005a3d0> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient) at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:65) at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:147) at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:122) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:263) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:168) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:147) at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:75) at org.jboss.as.test.shared.ServerReload.waitForLiveServerToReload(ServerReload.java:104) at org.jboss.as.test.shared.ServerReload.executeReloadAndWaitForCompletion(ServerReload.java:72) at org.jboss.as.test.shared.ServerReload.executeReloadAndWaitForCompletion(ServerReload.java:59) at org.jboss.as.test.integration.management.jca.DsMgmtTestBase.reload(DsMgmtTestBase.java:56) at org.jboss.as.test.integration.jca.datasource.DatasourceXaEnableAttributeTestCase.createDataSource(DatasourceXaEnableAttributeTestCase.java:59) at org.jboss.as.test.integration.jca.datasource.DatasourceEnableAttributeTestBase.enableLater(DatasourceEnableAttributeTestBase.java:79) > On Jan 28, 2016, at 10:26 AM, Toma? Cerar wrote: > > it just hanged again, > this is the thread dump http://fpaste.org/315834/53998306/raw/ > > On Thu, Jan 28, 2016 at 2:12 PM, Jason T. Greene > wrote: > It happens when a test hangs. So we have to get stack traces of the process when this occurs to even know where to being to look. > > On Jan 28, 2016, at 6:38 AM, Eduardo Sant?Ana da Silva > wrote: > >> I faced a similar problem recently. >> About this issue, my doubt is that if there is no nexus repository operation, and the build is done sequentially, first core (installing locally), after that the wildfly entire build, how this timeout is occurring? >> >> Seems that this could be a common problem if the maven is executing in parallel and those intermittent problems can occur due synchronization issues. >> >> To resolve my problem I first resolve the dependencies recently installed on local repository through: mvn dependency:build-classpath >> >> --- >> eduardo >> >> 2016-01-28 9:54 GMT-02:00 Toma? Cerar >: >> >> On Thu, Jan 28, 2016 at 9:58 AM, Carlo de Wolf > wrote: >> There should be no SNAPSHOT dependencies in any CI build. While it does build core beforehand, it might get overwritten by another CI run. >> [org.wildfly.core:wildfly-core-parent] [INFO] Installing /opt/buildAgent/work/db872761b443af46/core/pom.xml to /store/repository/org/wildfly/core/wildfly-core-parent/2.0.8.Final-SNAPSHOT/wildfly-core-parent-2.0.8.Final-SNAPSHOT.pom >> >> Would it be possible to use timed snapshots instead? >> >> >> As Stuart said, whole point of this builds is to have snapshot builds. >> Same build agent first builds core (clean install) and than builds full >> with -Dversion.wildfly.core= >> >> snapshot used here are only build agent local, not publish on some outside nexus repository. >> >> -- >> tomaz >> >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> >> >> -- >> __________________________ >> Eduardo Sant'Ana da Silva - Dr. >> Pesquisador / Consultor de TI >> >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev -- Jason T. Greene WildFly Lead / JBoss EAP Platform Architect JBoss, a division of Red Hat -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160128/0dd20d65/attachment-0001.html From ppalaga at redhat.com Thu Jan 28 11:56:44 2016 From: ppalaga at redhat.com (Peter Palaga) Date: Thu, 28 Jan 2016 17:56:44 +0100 Subject: [wildfly-dev] jboss-common-beans not synced to Maven Central In-Reply-To: <567428B3.6010109@redhat.com> References: <567403C8.4060701@redhat.com> <567428B3.6010109@redhat.com> Message-ID: <56AA484C.7090005@redhat.com> Status update: jboss-common-beans are in Central [1] now. It turned out to be some config problem between Central and JBoss repos. Solved via help at jboss.org and David Hladky (thanks!) -- P [1] http://repo1.maven.org/maven2/org/jboss/common/jboss-common-beans/ On 2015-12-18 16:39, Peter Palaga wrote: > Hi Bob, inline... > > On 2015-12-18 15:31, Bob McWhirter wrote: >> There?s quite a few WF dependencies not in central. >> >> There?s a variety of -jbossorg-1 dependencies we?ve had to fork for one >> reason or another. > > jboss-common-beans is not a fork. > >> Plus a handful of dependencies that?ve never sync?d to central for one >> reason or another. > > Could please somebody name the reason(s) relevant for jboss-common-beans? > >> Unfortunately you need to use repository.jboss.org >> . > > I do not think we have to. Either the sync can be turned on or we just > copy the PropertiesValueResolver. > > -- P > >> *sigh* >> >> -Bob >> >> On Fri, Dec 18, 2015 at 8:02 AM, Peter Palaga > > wrote: >> >> Hi Carlo, >> >> should not jboss-common-beans [1][2] be synced to Maven Central [3][4]? >> >> We use PropertiesValueResolver in Hawkular and try to be buildable with >> Maven Central only. >> >> WildFly depends on it too [5] and because WF is synced to Central, all >> its deps should be synced too. >> >> [1] https://github.com/jboss/jboss-common-beans/commits/master >> [2] >> http://origin-repository.jboss.org/nexus/content/repositories/public/org/jboss/common/jboss-common-beans/ >> >> [3] >> http://search.maven.org/#search%7Cga%7C1%7Cg%3A%22org.jboss.common%22%20AND%20a%3A%22jboss-common-beans%22 >> [4] http://repo1.maven.org/maven2/org/jboss/common >> >> [5] https://github.com/wildfly/wildfly/blob/master/pojo/pom.xml#L58 >> >> Thanks, >> >> Peter >> _______________________________________________ >> wildfly-dev mailing list >> wildfly-dev at lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/wildfly-dev >> >> > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From dcominottim at gmail.com Thu Jan 28 20:58:18 2016 From: dcominottim at gmail.com (Danilo Cominotti Marques) Date: Thu, 28 Jan 2016 23:58:18 -0200 Subject: [wildfly-dev] Blockers for WildFly 10 Final Message-ID: Hello there, I have seen the e-mail that listed the following issues as blockers for WildFly 10 Final, 1. https://issues.jboss.org/browse/WFLY-5480 2. https://issues.jboss.org/browse/WFCORE-1277 but I would clearly add the following one to that list, 3. https://issues.jboss.org/browse/HAL-1030 because my company certainly wouldn't deploy WildFly 10 Final before this issue is solved. Any chances of having somebody look into it before the final release? Thanks. Danilo Cominotti Marques -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160128/5e4861ca/attachment.html From darkness.renann at gmail.com Thu Jan 28 21:07:19 2016 From: darkness.renann at gmail.com (Renann Prado) Date: Fri, 29 Jan 2016 00:07:19 -0200 Subject: [wildfly-dev] Blockers for WildFly 10 Final In-Reply-To: References: Message-ID: I'm pretty sure I reported same issue as yours. See: https://issues.jboss.org/browse/WFLY-6015 Seems to be fixed, but it's not clear to me whether it will be part of Wildfly 10 Final or not. However you can easily work around: just add the datasource with with your driver && config and DO NOT CLICK IN TEST CONNECTION, then while EDITING the datasource you can test the connection as many times as you want. I did that in Wildfly 10.0.0.CR5 and it worked just fine. I wouldn't call that a blocker as there are couple of ways to create a datasource. Hope it helps. Renann Prado On Thu, Jan 28, 2016 at 11:58 PM, Danilo Cominotti Marques < dcominottim at gmail.com> wrote: > Hello there, > > I have seen the e-mail that listed the following issues as blockers for WildFly 10 Final, > > 1. https://issues.jboss.org/browse/WFLY-5480 > 2. https://issues.jboss.org/browse/WFCORE-1277 > > but I would clearly add the following one to that list, > > 3. https://issues.jboss.org/browse/HAL-1030 > > because my company certainly wouldn't deploy WildFly 10 Final before this issue is solved. > > Any chances of having somebody look into it before the final release? > > Thanks. > > Danilo Cominotti Marques > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160129/99fe5e50/attachment.html From cdewolf at redhat.com Fri Jan 29 03:02:47 2016 From: cdewolf at redhat.com (Carlo de Wolf) Date: Fri, 29 Jan 2016 09:02:47 +0100 Subject: [wildfly-dev] Timeout errors in JCA bits in testsuite In-Reply-To: References: <56A94AF1.7040501@redhat.com> <56A9D836.8040202@redhat.com> Message-ID: <56AB1CA7.4080907@redhat.com> I'm not saying, do not use snapshots. I'm saying do not use SNAPSHOT. :-) Clearly the path is a shared one, so the build must use timed snapshots or risk interference. Carlo On 01/28/2016 12:54 PM, Toma? Cerar wrote: > > On Thu, Jan 28, 2016 at 9:58 AM, Carlo de Wolf > wrote: > > There should be no SNAPSHOT dependencies in any CI build. While it > does build core beforehand, it might get overwritten by another CI > run. > //[org.wildfly.core:wildfly-core-parent] /[INFO] Installing > /opt/buildAgent/work/db872761b443af46/core/pom.xml to > /store/repository/org/wildfly/core/wildfly-core-parent/2.0.8.Final-SNAPSHOT/wildfly-core-parent-2.0.8.Final-SNAPSHOT.pom > / > Would it be possible to use timed snapshots instead? > > > > As Stuart said, whole point of this builds is to have snapshot builds. > Same build agent first builds core (clean install) and than builds full > with -Dversion.wildfly.core= > > snapshot used here are only build agent local, not publish on some > outside nexus repository. > > -- > tomaz > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160129/1f82be07/attachment.html From hbraun at redhat.com Fri Jan 29 03:06:27 2016 From: hbraun at redhat.com (Heiko Braun) Date: Fri, 29 Jan 2016 09:06:27 +0100 Subject: [wildfly-dev] Blockers for WildFly 10 Final In-Reply-To: References: Message-ID: Thanks, we are aware of that problem and it has already been addresses in the latest release: https://issues.jboss.org/browse/HAL-1039 I?ve therefore marked the issue you?d refer to as a duplicate. Regards, Heiko > On 29 Jan 2016, at 02:58, Danilo Cominotti Marques wrote: > > Hello there, > > I have seen the e-mail that listed the following issues as blockers for WildFly 10 Final, > > 1. https://issues.jboss.org/browse/WFLY-5480 > 2. https://issues.jboss.org/browse/WFCORE-1277 > > but I would clearly add the following one to that list, > > 3. https://issues.jboss.org/browse/HAL-1030 > > because my company certainly wouldn't deploy WildFly 10 Final before this issue is solved. > > Any chances of having somebody look into it before the final release? > > Thanks. > > Danilo Cominotti Marques > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160129/03dff4de/attachment-0001.html From darran.lofthouse at jboss.com Fri Jan 29 04:19:48 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 29 Jan 2016 09:19:48 +0000 Subject: [wildfly-dev] Timeout errors in JCA bits in testsuite In-Reply-To: <56AB1CA7.4080907@redhat.com> References: <56A94AF1.7040501@redhat.com> <56A9D836.8040202@redhat.com> <56AB1CA7.4080907@redhat.com> Message-ID: <56AB2EB4.7080201@jboss.com> Every single PR build we execute risks interference. Without running every PR again after every merge every single PR is a race condition hoping to avoid conflicting merges. On 29/01/16 08:02, Carlo de Wolf wrote: > I'm not saying, do not use snapshots. I'm saying do not use SNAPSHOT. :-) > > Clearly the path is a shared one, so the build must use timed snapshots > or risk interference. > > Carlo > > On 01/28/2016 12:54 PM, Toma? Cerar wrote: >> >> On Thu, Jan 28, 2016 at 9:58 AM, Carlo de Wolf > > wrote: >> >> There should be no SNAPSHOT dependencies in any CI build. While it >> does build core beforehand, it might get overwritten by another CI >> run. >> //[org.wildfly.core:wildfly-core-parent] /[INFO] Installing >> /opt/buildAgent/work/db872761b443af46/core/pom.xml to >> /store/repository/org/wildfly/core/wildfly-core-parent/2.0.8.Final-SNAPSHOT/wildfly-core-parent-2.0.8.Final-SNAPSHOT.pom >> / >> Would it be possible to use timed snapshots instead? >> >> >> >> As Stuart said, whole point of this builds is to have snapshot builds. >> Same build agent first builds core (clean install) and than builds full >> with -Dversion.wildfly.core= >> >> snapshot used here are only build agent local, not publish on some >> outside nexus repository. >> >> -- >> tomaz >> > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From darran.lofthouse at jboss.com Fri Jan 29 04:22:00 2016 From: darran.lofthouse at jboss.com (Darran Lofthouse) Date: Fri, 29 Jan 2016 09:22:00 +0000 Subject: [wildfly-dev] Blockers for WildFly 10 Final In-Reply-To: References: Message-ID: <56AB2F38.3030300@jboss.com> On 29/01/16 02:07, Renann Prado wrote: > I'm pretty sure I reported same issue as yours. > > See: > https://issues.jboss.org/browse/WFLY-6015 > > Seems to be fixed, but it's not clear to me whether it will be part of > Wildfly 10 Final or not. Apart from the occasional mistake in Jira if the status is 'Resolved' the 'Fix Version/s' field shows the release the fix is or will be included in. > However you can easily work around: just add the datasource with with > your driver && config and DO NOT CLICK IN TEST CONNECTION, then while > EDITING the datasource you can test the connection as many times as you > want. I did that in Wildfly 10.0.0.CR5 and it worked just fine. > > I wouldn't call that a blocker as there are couple of ways to create a > datasource. > > Hope it helps. > > Renann Prado > > On Thu, Jan 28, 2016 at 11:58 PM, Danilo Cominotti Marques > > wrote: > > Hello there, > > I have seen the e-mail that listed the following issues as blockers > for WildFly 10 Final, > > 1. https://issues.jboss.org/browse/WFLY-5480 > 2. https://issues.jboss.org/browse/WFCORE-1277 > > but I would clearly add the following one to that list, > > 3. https://issues.jboss.org/browse/HAL-1030 > > because my company certainly wouldn't deploy WildFly 10 Final before > this issue is solved. > > Any chances of having somebody look into it before the final release? > > Thanks. > > Danilo Cominotti Marques > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > From david.lloyd at redhat.com Fri Jan 29 10:47:38 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 29 Jan 2016 09:47:38 -0600 Subject: [wildfly-dev] The EJB client and remote JTA transaction propagation Message-ID: <56AB899A.1050000@redhat.com> As you may know, WildFly supports a feature wherein an EJB client which is invoking an EJB on a remote server has the option to propagate its local transaction to the remote server, treating the remote server as a subordinate and coordinating the transaction's two-phase commit among the resultant graph of servers. This feature has always been limited in that, when enabled, transactions are always propagated, regardless of the peer EJB's transaction policy, or of whether the peer even has a transaction manager. So, for the invocation rework which I anticipate will be included in WildFly 11, I've introduced a new client-side annotation intended to be associated with the EJB interface which informs the client library what to do for transaction propagation for that interface. In addition, I intend to configuration strategies which will allow the default mode to be specified in various ways (per-thread, globally, and by target interface/method all come to mind), for cases where the EJB's remote interface cannot be easily modified for some reason. I expect to also broaden these configuration strategies to apply to all client-side EJB interface/methods configuration items [3]. The first part of this change is the addition of a new annotation called @ClientTransaction [1], which accepts as a value an enum called ClientTransactionPolicy [2]. The latter specifies whether a local transaction is required or forbidden for the method or interface, and also specifies whether the transaction is propagated or not propagated. I've added copious amounts of JavaDoc in order to establish exactly what the behavior of each mode is, as well as to specify how each mode interacts with the various modules that are configured via the standard javax.ejb.TransactionAttributeType enum. [1] https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java [2] https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java [2] (raw) https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java [3] for a list, see: https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation -- - DML From tom.jenkinson at redhat.com Fri Jan 29 11:42:53 2016 From: tom.jenkinson at redhat.com (Tom Jenkinson) Date: Fri, 29 Jan 2016 16:42:53 +0000 Subject: [wildfly-dev] The EJB client and remote JTA transaction propagation In-Reply-To: <56AB899A.1050000@redhat.com> References: <56AB899A.1050000@redhat.com> Message-ID: One option that I would favour is to go down the JTS route where the subordinate calls back on the parent to tell it to register it in the transaction. This could be a new JBoss Remoting API that I can invoke from Narayana. The call would not necessarily be a remote call, it would invoke back into the JBR transport to tell it that when it returns to the parent it needs to enlist (or not). On 29 January 2016 at 15:47, David M. Lloyd wrote: > As you may know, WildFly supports a feature wherein an EJB client which > is invoking an EJB on a remote server has the option to propagate its > local transaction to the remote server, treating the remote server as a > subordinate and coordinating the transaction's two-phase commit among > the resultant graph of servers. This feature has always been limited in > that, when enabled, transactions are always propagated, regardless of > the peer EJB's transaction policy, or of whether the peer even has a > transaction manager. > > So, for the invocation rework which I anticipate will be included in > WildFly 11, I've introduced a new client-side annotation intended to be > associated with the EJB interface which informs the client library what > to do for transaction propagation for that interface. In addition, I > intend to configuration strategies which will allow the default mode to > be specified in various ways (per-thread, globally, and by target > interface/method all come to mind), for cases where the EJB's remote > interface cannot be easily modified for some reason. I expect to also > broaden these configuration strategies to apply to all client-side EJB > interface/methods configuration items [3]. > > The first part of this change is the addition of a new annotation called > @ClientTransaction [1], which accepts as a value an enum called > ClientTransactionPolicy [2]. The latter specifies whether a local > transaction is required or forbidden for the method or interface, and > also specifies whether the transaction is propagated or not propagated. > > I've added copious amounts of JavaDoc in order to establish exactly what > the behavior of each mode is, as well as to specify how each mode > interacts with the various modules that are configured via the standard > javax.ejb.TransactionAttributeType enum. > > [1] > > https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java > [2] > > https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java > [2] (raw) > > https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java > [3] for a list, see: > > https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160129/b3915314/attachment.html From david.lloyd at redhat.com Fri Jan 29 13:27:16 2016 From: david.lloyd at redhat.com (David M. Lloyd) Date: Fri, 29 Jan 2016 12:27:16 -0600 Subject: [wildfly-dev] The EJB client and remote JTA transaction propagation In-Reply-To: References: <56AB899A.1050000@redhat.com> Message-ID: <56ABAF04.2070305@redhat.com> That's an interesting idea. So in effect, the remote EJB would tell the caller "you sent me a transaction ID, but in the end, I didn't use it"? I would need to think about how this might work in the presence of multiple concurrent invocations on the same transaction. Either way though, I think it would still be beneficial for clients to be able to explicitly annotate a client method (or otherwise establish a policy) such that it causes transactions to be propagated (or not), or to enforce transaction-related preconditions. The interceptor that implements this feature doesn't actually have protocol awareness: it just examines the current environment, and decides whether to attach the transaction to the invocation context. On 1/29/16 10:42 AM, Tom Jenkinson wrote: > One option that I would favour is to go down the JTS route where the > subordinate calls back on the parent to tell it to register it in the > transaction. This could be a new JBoss Remoting API that I can invoke > from Narayana. The call would not necessarily be a remote call, it would > invoke back into the JBR transport to tell it that when it returns to > the parent it needs to enlist (or not). > > On 29 January 2016 at 15:47, David M. Lloyd > wrote: > > As you may know, WildFly supports a feature wherein an EJB client which > is invoking an EJB on a remote server has the option to propagate its > local transaction to the remote server, treating the remote server as a > subordinate and coordinating the transaction's two-phase commit among > the resultant graph of servers. This feature has always been limited in > that, when enabled, transactions are always propagated, regardless of > the peer EJB's transaction policy, or of whether the peer even has a > transaction manager. > > So, for the invocation rework which I anticipate will be included in > WildFly 11, I've introduced a new client-side annotation intended to be > associated with the EJB interface which informs the client library what > to do for transaction propagation for that interface. In addition, I > intend to configuration strategies which will allow the default mode to > be specified in various ways (per-thread, globally, and by target > interface/method all come to mind), for cases where the EJB's remote > interface cannot be easily modified for some reason. I expect to also > broaden these configuration strategies to apply to all client-side EJB > interface/methods configuration items [3]. > > The first part of this change is the addition of a new annotation called > @ClientTransaction [1], which accepts as a value an enum called > ClientTransactionPolicy [2]. The latter specifies whether a local > transaction is required or forbidden for the method or interface, and > also specifies whether the transaction is propagated or not propagated. > > I've added copious amounts of JavaDoc in order to establish exactly what > the behavior of each mode is, as well as to specify how each mode > interacts with the various modules that are configured via the standard > javax.ejb.TransactionAttributeType enum. > > [1] > https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransaction.java > [2] > https://github.com/jbossas/jboss-ejb-client/blob/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java > [2] (raw) > https://raw.githubusercontent.com/jbossas/jboss-ejb-client/master/src/main/java/org/jboss/ejb/client/annotation/ClientTransactionPolicy.java > [3] for a list, see: > https://github.com/jbossas/jboss-ejb-client/tree/master/src/main/java/org/jboss/ejb/client/annotation > > -- > - DML > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > -- - DML From kap4020 at gmail.com Fri Jan 29 18:13:54 2016 From: kap4020 at gmail.com (Karl Pietrzak) Date: Fri, 29 Jan 2016 18:13:54 -0500 Subject: [wildfly-dev] where to find source for jboss-cli.sh --gui? Message-ID: I'm thinking about writing a Hawtio / Jolokia plugin for the CLI, and I'm wondering if anyone could point me to the source code the CLI GUI, i.e., jboss-cli.sh --gui. Thank you! -- Karl -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160129/b9fba66d/attachment-0001.html From filippespolti at gmail.com Fri Jan 29 18:22:04 2016 From: filippespolti at gmail.com (Spolti) Date: Fri, 29 Jan 2016 21:22:04 -0200 Subject: [wildfly-dev] where to find source for jboss-cli.sh --gui? In-Reply-To: References: Message-ID: Hi, i believe you will find all you need here: https://github.com/wildfly/wildfly-core/tree/master/cli/src/main/java/org/jboss/as/cli On Jan 29, 2016 9:14 PM, "Karl Pietrzak" wrote: > I'm thinking about writing a Hawtio / Jolokia > plugin for the CLI, and I'm wondering if anyone > could point me to the source code the CLI GUI, i.e., jboss-cli.sh --gui. > > Thank you! > > -- > Karl > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160129/0d9b19b0/attachment.html From darkness.renann at gmail.com Sat Jan 30 11:34:38 2016 From: darkness.renann at gmail.com (Renann Prado) Date: Sat, 30 Jan 2016 14:34:38 -0200 Subject: [wildfly-dev] Is the BOM for 10.0.0.Final available already? Message-ID: I tried to use org.wildfly.bom jboss-javaee-7.0-wildfly 10.0.0.Final pom import But couldn't. Renann Prado -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160130/6aa403e6/attachment.html From darkness.renann at gmail.com Sat Jan 30 16:46:39 2016 From: darkness.renann at gmail.com (Renann Prado) Date: Sat, 30 Jan 2016 19:46:39 -0200 Subject: [wildfly-dev] Blockers for WildFly 10 Final In-Reply-To: <56AB2F38.3030300@jboss.com> References: <56AB2F38.3030300@jboss.com> Message-ID: I've just downloaded Wildfly 10.0.0.Final and it's still not working 100%. 1 - Fill all the fields, but put some wrong information like password, ip, whatever 2 - Get to the last screen where you can test the connection 3 - Test the connection (and fails) 4 - Go back, fix the connection info with right information 5 - Test connection and still fails (it's using old credentials) Btw I was also able to see org.jboss.msc.service.DuplicateServiceException when I was testing, though I don't have clear steps how to reproduce. I don't believe the problem is in the web UI. Another minor issue is that when it fails to test, most of the times (if not always), regardless of the type of error I get in the server, in web UI I always get same generic error message: 19:41:01,345 ERROR [org.jboss.as.controller.management-operation] (management task-5) WFLYCTL0013: Operation ("test-connection-in-pool") failed - address: ([ ("subsystem" => "datasources"), ("data-source" => "MySqlDS") ]) - failure description: "WFLYJCA0040: failed to invoke operation: WFLYJCA0047: Connection is not valid" And when I went to look in the server log: Caused by: java.sql.SQLInvalidAuthorizationSpecException: Could not connect: Access denied for user 'admin'@'192.168.0.107' (using password: YES) at org.mariadb.jdbc.internal.util.ExceptionMapper.get(ExceptionMapper.java:121) at org.mariadb.jdbc.internal.util.ExceptionMapper.throwException(ExceptionMapper.java:69) at org.mariadb.jdbc.Driver.connect(Driver.java:110) at org.jboss.jca.adapters.jdbc.local.LocalManagedConnectionFactory.createLocalManagedConnection(LocalManagedConnectionFactory.java:319) ... 31 more It would be nice to propagete the correct error to the web UI. Thanks Renann Prado On Fri, Jan 29, 2016 at 7:22 AM, Darran Lofthouse < darran.lofthouse at jboss.com> wrote: > > > On 29/01/16 02:07, Renann Prado wrote: > > I'm pretty sure I reported same issue as yours. > > > > See: > > https://issues.jboss.org/browse/WFLY-6015 > > > > Seems to be fixed, but it's not clear to me whether it will be part of > > Wildfly 10 Final or not. > > Apart from the occasional mistake in Jira if the status is 'Resolved' > the 'Fix Version/s' field shows the release the fix is or will be > included in. > > > However you can easily work around: just add the datasource with with > > your driver && config and DO NOT CLICK IN TEST CONNECTION, then while > > EDITING the datasource you can test the connection as many times as you > > want. I did that in Wildfly 10.0.0.CR5 and it worked just fine. > > > > I wouldn't call that a blocker as there are couple of ways to create a > > datasource. > > > > Hope it helps. > > > > Renann Prado > > > > On Thu, Jan 28, 2016 at 11:58 PM, Danilo Cominotti Marques > > > wrote: > > > > Hello there, > > > > I have seen the e-mail that listed the following issues as blockers > > for WildFly 10 Final, > > > > 1. https://issues.jboss.org/browse/WFLY-5480 > > 2. https://issues.jboss.org/browse/WFCORE-1277 > > > > but I would clearly add the following one to that list, > > > > 3. https://issues.jboss.org/browse/HAL-1030 > > > > because my company certainly wouldn't deploy WildFly 10 Final before > > this issue is solved. > > > > Any chances of having somebody look into it before the final release? > > > > Thanks. > > > > Danilo Cominotti Marques > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > > > > > > > > _______________________________________________ > > wildfly-dev mailing list > > wildfly-dev at lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/wildfly-dev > > > _______________________________________________ > wildfly-dev mailing list > wildfly-dev at lists.jboss.org > https://lists.jboss.org/mailman/listinfo/wildfly-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160130/de0d46ba/attachment.html From tomaz.cerar at gmail.com Sun Jan 31 06:14:46 2016 From: tomaz.cerar at gmail.com (tomaz.cerar at gmail.com) Date: Sun, 31 Jan 2016 12:14:46 +0100 Subject: [wildfly-dev] Is the BOM for 10.0.0.Final available already? In-Reply-To: References: Message-ID: <56adeca6.29cec20a.ceebf.ffff9dd6@mx.google.com> Not at the moment. It will be tagged and released tomorrow. In mean time you can use 10.0.0.CR5 version of bom, which is pretty much the same. Also please note that artifact id is different. For reference please see https://github.com/wildfly/boms/blob/master/README.md Sorry for inconvinience. -- Tomaz Sent from phone From: Renann Prado Sent: sobota, 30. januar 2016 17:36 To: wildfly-dev at lists.jboss.org Subject: [wildfly-dev] Is the BOM for 10.0.0.Final available already? I tried to use ? ? ? ? ? ? ? ? org.wildfly.bom ? ? ? ? ? ? ? ? jboss-javaee-7.0-wildfly ? ? ? ? ? ? ? ? 10.0.0.Final ? ? ? ? ? ? ? ? pom ? ? ? ? ? ? ? ? import But couldn't. Renann Prado -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160131/ee8bd60a/attachment-0001.html From pierrick.hymbert at gmail.com Sun Jan 31 06:59:57 2016 From: pierrick.hymbert at gmail.com (Pierrick HYMBERT) Date: Sun, 31 Jan 2016 14:59:57 +0300 Subject: [wildfly-dev] Wildfly 10.0.0.Final and Infinispan subsystem model 4.0 - Got a local cache despite it is configured as distributed Message-ID: Dear Wildfly dev team, I am blocked to deploy a test app that use a distributed infinispan cache within 2 domain nodes and a cache entry producer deployed as clustered singleton service. Your feedback/advise are really appreciated! Cache definition: Sample code: @Resource(lookup = "java:jboss/infinispan/container/my-cache-container") private EmbeddedCacheManager cacheContainer; private Cache myAppCache; @PostConstruct public void startNotClustered() throws NamingException { this.myAppCache = this.cacheContainer.getCache("myAppCache"); ... } ... @Schedule(hour = "*", minute = "*", second = "*") public void consume() { logger.info("Cache size on node {} = {}", System.getProperty("jboss.node.name"), myAppCache.size()); } Server one sample logs: 2016-01-31 14:52:03,789 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 1) Produce new cache entry 1454241123789 on node master:server-one 2016-01-31 14:52:04,005 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 2) Cache size on node master:server-one = 35 2016-01-31 14:52:04,796 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 3) Produce new cache entry 1454241124796 on node master:server-one 2016-01-31 14:52:05,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 4) Cache size on node master:server-one = 36 2016-01-31 14:52:05,801 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Produce new cache entry 1454241125801 on node master:server-one 2016-01-31 14:52:06,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 6) Cache size on node master:server-one = 37 2016-01-31 14:52:06,807 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) Produce new cache entry 1454241126807 on node master:server-one 2016-01-31 14:52:07,005 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 8) Cache size on node master:server-one = 38 2016-01-31 14:52:07,813 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 9) Produce new cache entry 1454241127813 on node master:server-one 2016-01-31 14:52:08,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 10) Cache size on node master:server-one = 39 2016-01-31 14:52:08,817 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 1) Produce new cache entry 1454241128817 on node master:server-one 2016-01-31 14:52:09,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 2) *Cache size on node master:server-one = 40* Server two logs: 2016-01-31 14:51:56,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 4) Cache size on node master:server-two = 0 2016-01-31 14:51:57,008 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Cache size on node master:server-two = 0 2016-01-31 14:51:58,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 6) Cache size on node master:server-two = 0 2016-01-31 14:51:59,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) Cache size on node master:server-two = 0 2016-01-31 14:52:00,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 8) Cache size on node master:server-two = 0 2016-01-31 14:52:01,008 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 9) Cache size on node master:server-two = 0 2016-01-31 14:52:02,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 10) Cache size on node master:server-two = 0 2016-01-31 14:52:03,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 1) Cache size on node master:server-two = 0 2016-01-31 14:52:04,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 2) Cache size on node master:server-two = 0 2016-01-31 14:52:05,008 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 3) Cache size on node master:server-two = 0 2016-01-31 14:52:06,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 4) Cache size on node master:server-two = 0 2016-01-31 14:52:07,006 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 5) Cache size on node master:server-two = 0 2016-01-31 14:52:08,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 6) Cache size on node master:server-two = 0 2016-01-31 14:52:09,007 INFO [org.hypik.test.jboss.eap7.server.TestService] (EJB default - 7) *Cache size on node master:server-two = 0* I have attached all necessary info to investigate, but I am not sure attachement is allowed, so you can see source and logs here: https://www.dropbox.com/s/l1uhmfg5tkjkikw/infinispan-issue-wildfly-10.0.0.zip?dl=0 ? ????????? / Cordialement / Best regards, *Pierrick **HYMBERT* *pierrick.hymbert at gmail.com * *(+7)916.301-89-13 / (+33)6.87-52-91-37* *+Pierrick / **Skype / **LinkedIn * -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160131/bb167e64/attachment-0001.html -------------- next part -------------- A non-text attachment was scrubbed... Name: infinispan-issue-wildfly-10.0.0.zip Type: application/zip Size: 64502 bytes Desc: not available Url : http://lists.jboss.org/pipermail/wildfly-dev/attachments/20160131/bb167e64/attachment-0001.zip