April 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1111) Listeners registration on stateless session is not thread safe

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1111?page=com.atlassian.jira.plugi... ] Mario Fusco closed DROOLS-1111. ------------------------------- Fix Version/s: 6.4.0.Final 7.0.0.Final Resolution: Done Fixed by https://github.com/droolsjbpm/drools/commit/01b8fc535 > Listeners registration on stateless session is not thread safe > -------------------------------------------------------------- > > Key: DROOLS-1111 > URL: https://issues.jboss.org/browse/DROOLS-1111 > Project: Drools > Issue Type: Bug > Reporter: Mario Fusco > Assignee: Mario Fusco > Fix For: 6.4.0.Final, 7.0.0.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-547) Unable to overlay resource in subunit/zip/jar file

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-547?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-547: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1147352, https://bugzilla.redhat.com/show_bug.cgi?id=1323240 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1147352) > Unable to overlay resource in subunit/zip/jar file > -------------------------------------------------- > > Key: WFCORE-547 > URL: https://issues.jboss.org/browse/WFCORE-547 > Project: WildFly Core > Issue Type: Bug > Components: Server > Affects Versions: 1.0.0.Alpha18 > Reporter: Bartosz Baranowski > Assignee: Stuart Douglas > Fix For: 1.0.0.Beta1 > > > It is possible to overlay resource directly in deployed jar, however, same resource can not be properly overlayed if said jar is deployed as part of ear ( possibly war as well ). > Example: > jar (xxx.jar): > /org/test/ejb/EJBImpl.class > /org/test/ejb/resourceToOverlya.txt > ear(yyy.ear) - war seems to be the subject of this as well > /xxx.jar > Overlay #1( over jar) > overlay target: xxx.jar/org/test/ejb/resourceToOverlya.txt > Result: proper deployment(EJB is deployed), resource has been overlayed > Overlay #2( over jar inside ear ) > overlay target: org/test/ejb/resourceToOverlya.txt > Result: bad deployment, no EJB deployed, overlay target has been overlayed > Reason of such outcome is that VFS.exists() does not recognize JavaZipFileSystem$ZipNode/Entry as zipped archive and does not dive into children. > So what happens in here is as follows. When EAR is deployed OverlayProcessor kicks in at: > https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... > For this example ear/jar pair, first pair of values: > mountPoint: /content/yyy.ear/xxx.jar/org/test/ejb/resourceToOverlya.txt > parent: /content/yyy.ear/xxx.jar/org/test/ejb > Outcome of exists() call == false, should be true. > this will iterate up to parent == /content/yyy.ear/xxx.jar > At this point, 'createParents' contain some entries and > https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/... > will create tmp/virtual mounts for: > - /content/yyy.ear/xxx.jar/org/test/ejb > - /content/yyy.ear/xxx.jar/org/test > - /content/yyy.ear/xxx.jar/org > What it will essentially do is create overlay for whole 'org' package! The VirtualFile.getChildren() will return tmp mounted VirtualFile for 'org' entry: https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/... > There is part of code which should remove 'submount' if there is directory entry: https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/... however ( if I remember correctly) 'org' tmp mount ends up twice in 'submounts' > When VirtualFile.getChildren is called for 'this' == /content/yyy.ear/xxx.jar ( in this case it is properly removed) and when 'this' == /content/yyy.ear/xxx.jar/org - in which case it derails getChildren and diverts into tmp mount. > Now about https://github.com/jbossas/jboss-vfs/blob/master/src/main/java/org/jboss/... > What happens here, for ear deployment - it dives recursively into 'find' until 'target' is equal to '/content/yyy.ear/xxx.jar' at this target.getParent() == 'mountPoint' == '/content/yyy.ear'. > At this point 'find' will get result ZipNode == /content/yyy.ear and fetch child 'xxx.jar' and pop back up one notch in the call stack. However the 'xxx.jar' entry does not have any children, hence there is no way to fetch next child in line 'org'. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-761) Not possible to overlay non existing file in WAR

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-761?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration updated WFCORE-761: ------------------------------------------- Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1147352, https://bugzilla.redhat.com/show_bug.cgi?id=1287732, https://bugzilla.redhat.com/show_bug.cgi?id=1323240 (was: https://bugzilla.redhat.com/show_bug.cgi?id=1147352, https://bugzilla.redhat.com/show_bug.cgi?id=1287732) > Not possible to overlay non existing file in WAR > ------------------------------------------------ > > Key: WFCORE-761 > URL: https://issues.jboss.org/browse/WFCORE-761 > Project: WildFly Core > Issue Type: Bug > Components: Server > Reporter: Bartosz Baranowski > Assignee: Dimitris Andreadis > Priority: Critical > > It is either bug in how deployments are treated or how overlay/vfs work. > Steps to reproduce: > 1. deploy undexploded war with jar inside > 2. add overlay that will add non existing file in jar > Result: exception: > Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: JBAS018776: Failed to get content for deployment overlay WEB-INF/lib/overlayed.jar//META-INF/x/file.txt at WEB-INF/lib/overlayed.jar//META-INF/x/file.txt > Caused by: java.io.FileNotFoundException: /content/shell.war/WEB-INF/lib/overlayed.jar/META-INF/x/file.txt"}} > at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:67) > at org.jboss.as.test.integration.management.ManagementOperations.executeOperation(ManagementOperations.java:37) > at org.jboss.as.test.integration.deployment.deploymentoverlay.jar.OverlayUtils.setupOverlay(OverlayUtils.java:76) > at org.jboss.as.test.integration.deployment.deploymentoverlay.war.OverlayNonExistingResourceTestCase.testOverlay(OverlayNonExistingResourceTestCase.java:67) > Expectation: > should work. It actually does work, if war is really exploded or > 'if(exploded)' part in overlay is removed from overlay processor and everything is handled via: https://github.com/stuartwdouglas/wildfly-core/blob/a75af9118c4062fafb899... -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1459) Starting server that has port clash with existing running server returns 'Success', then fails

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1459?page=com.atlassian.jira.plugi... ] Ken Wills commented on WFCORE-1459: ----------------------------------- Possibly other (older) ticket exists for tightening up how this is working. > Starting server that has port clash with existing running server returns 'Success', then fails > ---------------------------------------------------------------------------------------------- > > Key: WFCORE-1459 > URL: https://issues.jboss.org/browse/WFCORE-1459 > Project: WildFly Core > Issue Type: Bug > Reporter: Ken Wills > Assignee: Ken Wills > > The reproducer is: given a vanilla wildfly, add server-test with port-offset=0. Use CLI to start, it reports result" => "STARTED", but the server fails with "BindException: Address already in use" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-1459) Starting server that has port clash with existing running server returns 'Success', then fails

by Ken Wills (JIRA)

Ken Wills created WFCORE-1459: --------------------------------- Summary: Starting server that has port clash with existing running server returns 'Success', then fails Key: WFCORE-1459 URL: https://issues.jboss.org/browse/WFCORE-1459 Project: WildFly Core Issue Type: Bug Reporter: Ken Wills Assignee: Ken Wills The reproducer is: given a vanilla wildfly, add server-test with port-offset=0. Use CLI to start, it reports result" => "STARTED", but the server fails with "BindException: Address already in use" -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-1066) Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING)

by Jason Greene (JIRA)

[ https://issues.jboss.org/browse/WFLY-1066?page=com.atlassian.jira.plugin.... ] Jason Greene reassigned WFLY-1066: ---------------------------------- Assignee: Jason Greene (was: Sebastian Łaskawiec) > Automatic configuration of 'Initial_hosts' for a cluster using JGroups TCP-stack in domain mode (aka DOMAIN_PING) > ----------------------------------------------------------------------------------------------------------------- > > Key: WFLY-1066 > URL: https://issues.jboss.org/browse/WFLY-1066 > Project: WildFly > Issue Type: Feature Request > Components: Domain Management > Environment: Server running in Domain mode > Reporter: Wolf-Dieter Fink > Assignee: Jason Greene > Priority: Minor > Labels: clustering, domain, jgroups > > It is complicated to keep the subsystem JGroups in sync if the tcp-stack is used in domain mode. > All new servers that join/leave a clustered server group (configuration) must be added or removed by hand for the jgroup configuration. > The domain server will receive the information if a host-controller enrol and register server to a clustered server-group. > So the configuration of the initial_hosts can be done automatically to avoid old entries which cause unnecessary checks and ensure that all active servers are known. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6117) Modify javax.transaction.api to exclude the .xa subpackage

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6117?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6117: ----------------------------------------------- Brad Maxwell <bmaxwell(a)redhat.com> changed the Status of [bug 1309174|https://bugzilla.redhat.com/show_bug.cgi?id=1309174] from ASSIGNED to POST > Modify javax.transaction.api to exclude the .xa subpackage > ---------------------------------------------------------- > > Key: WFLY-6117 > URL: https://issues.jboss.org/browse/WFLY-6117 > Project: WildFly > Issue Type: Task > Reporter: David Lloyd > Assignee: David Lloyd > Fix For: 10.1.0.Final > > > Simultaneously with the core upgrade which includes WFCORE-1357, update the module definition for {{javax.transaction.api}} to exclude the {{javax/transaction/xa}} package from the artifact, instead re-exporting it from the JDK. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-101) Exception transformation

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-101?page=com.atlassian.jira.plugi... ] David Lloyd commented on LOGTOOL-101: ------------------------------------- Overloading is less good though because then I have to do this: {code} if (ex instanceof BindException) { throw x.bindFailed(addr, (BindException) ex); } else { throw x.bindFailed(addr, ex); } {code} or: {code} try { // ... } catch (BindException e) { throw x.bindFailed(e); } catch (IOException e) { throw x.bindFailed(e); } {code} Not the end of the world, but not ideal either. > Exception transformation > ------------------------ > > Key: LOGTOOL-101 > URL: https://issues.jboss.org/browse/LOGTOOL-101 > Project: Log Tool > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: James Perkins > > I'd like to be able to transform an exception message. What this means is, create a new exception, embed its message in my message, and copy its stack trace to mine. > Something like this: > {code} > @Message(id = 1234, "Binding to %s failed") > IOException bindFailed(SocketAddress bindAddress, @TransformException IOException cause) > {code} > This would yield a message like: "Binding to 1.2.3.4/1234 failed: Address already in use". Note the addition of the ": " and the source string. > Note that I can almost do this now, except that there's no way to copy the exception stack: > {code} > @Message(id = 1234, "Binding to %s failed: %s") > IOException bindFailed(SocketAddress bindAddress, IOException cause) > {code} > An alternative approach is to add an annotation for copying the stack trace: > {code} > @Message(id = 1234, "Binding to %s failed") > IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom IOException cause) > {code} > Note that in this case the original exception message is lost. The next variant would preserve the message: > {code} > @Message(id = 1234, "Binding to %s failed: %s") > IOException bindFailed(SocketAddress bindAddress, IOException cause, @CopyStackFrom IOException cause2) > {code} > And now to eliminate the duplication: > {code} > @Message(id = 1234, "Binding to %s failed: %s") > IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom @Pos(2) IOException cause) > {code} > Note that I don't recall if @Pos is 1- or 0-based, so I guessed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (LOGTOOL-101) Exception transformation

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/LOGTOOL-101?page=com.atlassian.jira.plugi... ] David Lloyd commented on LOGTOOL-101: ------------------------------------- Failing that (cloning), an alternative is to allow overloading: {code} @Message(id = 1234, "Binding to %s failed: %s") IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom @Pos(2) IOException cause) BindException bindFailed(SocketAddress bindAddress, @CopyStackFrom @Pos(2) BindException cause) {code} Which I think is allowed today (right?). > Exception transformation > ------------------------ > > Key: LOGTOOL-101 > URL: https://issues.jboss.org/browse/LOGTOOL-101 > Project: Log Tool > Issue Type: Feature Request > Reporter: David Lloyd > Assignee: James Perkins > > I'd like to be able to transform an exception message. What this means is, create a new exception, embed its message in my message, and copy its stack trace to mine. > Something like this: > {code} > @Message(id = 1234, "Binding to %s failed") > IOException bindFailed(SocketAddress bindAddress, @TransformException IOException cause) > {code} > This would yield a message like: "Binding to 1.2.3.4/1234 failed: Address already in use". Note the addition of the ": " and the source string. > Note that I can almost do this now, except that there's no way to copy the exception stack: > {code} > @Message(id = 1234, "Binding to %s failed: %s") > IOException bindFailed(SocketAddress bindAddress, IOException cause) > {code} > An alternative approach is to add an annotation for copying the stack trace: > {code} > @Message(id = 1234, "Binding to %s failed") > IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom IOException cause) > {code} > Note that in this case the original exception message is lost. The next variant would preserve the message: > {code} > @Message(id = 1234, "Binding to %s failed: %s") > IOException bindFailed(SocketAddress bindAddress, IOException cause, @CopyStackFrom IOException cause2) > {code} > And now to eliminate the duplication: > {code} > @Message(id = 1234, "Binding to %s failed: %s") > IOException bindFailed(SocketAddress bindAddress, @CopyStackFrom @Pos(2) IOException cause) > {code} > Note that I don't recall if @Pos is 1- or 0-based, so I guessed. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1111) Listeners registration on stateless session is not thread safe

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1111: ----------------------------------- Summary: Listeners registration on stateless session is not thread safe Key: DROOLS-1111 URL: https://issues.jboss.org/browse/DROOLS-1111 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2016