May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6588) Allow configuration of rebalanceConnections activation config property in pooled-connection-factory

by Miroslav Novak (JIRA)

[ https://issues.jboss.org/browse/WFLY-6588?page=com.atlassian.jira.plugin.... ] Miroslav Novak moved JBEAP-4537 to WFLY-6588: --------------------------------------------- Project: WildFly (was: JBoss Enterprise Application Platform) Key: WFLY-6588 (was: JBEAP-4537) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: JMS (was: JMS) Target Release: (was: 7.backlog.GA) Affects Version/s: 10.0.0.Final (was: 7.0.0.CR2) > Allow configuration of rebalanceConnections activation config property in pooled-connection-factory > --------------------------------------------------------------------------------------------------- > > Key: WFLY-6588 > URL: https://issues.jboss.org/browse/WFLY-6588 > Project: WildFly > Issue Type: Feature Request > Components: JMS > Affects Versions: 10.0.0.Final > Reporter: Miroslav Novak > Assignee: Jeff Mesnil > Priority: Critical > > For inbound connections we allow to configure activation config property {{rebalanceConnections}} for MDBs which allows to rebalance inbound connection in runtime when underlying Artemis cluster topology changes. > Purpose of this RFE is to add it to configuration of inbound connections in pooled-connection-factory so it does not have to be specified in every MDB. Default should be set to false. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ELY-527) Handling of SSLSessionAuthorizationCallback is missing a call to authorize()

by David Lloyd (JIRA)

[ https://issues.jboss.org/browse/ELY-527?page=com.atlassian.jira.plugin.sy... ] David Lloyd commented on ELY-527: --------------------------------- SSL session authorization is already an authorization (like AnonymousAuthorizationCallback) so a redundant authorize should not be necessary. That said if we're dropping this class in favor of proper scope auth, we'd need to go back to using AuthorizeCallback again. > Handling of SSLSessionAuthorizationCallback is missing a call to authorize() > ---------------------------------------------------------------------------- > > Key: ELY-527 > URL: https://issues.jboss.org/browse/ELY-527 > Project: WildFly Elytron > Issue Type: Bug > Components: SSL > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta6 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (ELY-527) Handling of SSLSessionAuthorizationCallback is missing a call to authorize()

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-527: ------------------------------------ Summary: Handling of SSLSessionAuthorizationCallback is missing a call to authorize() Key: ELY-527 URL: https://issues.jboss.org/browse/ELY-527 Project: WildFly Elytron Issue Type: Bug Components: SSL Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta6 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6163) Remove org.apache.santuario.xmlsec dependency from org.jboss.as.webservices.server.integration module

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6163?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6163: ----------------------------------------------- Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1311733|https://bugzilla.redhat.com/show_bug.cgi?id=1311733] from ON_QA to VERIFIED > Remove org.apache.santuario.xmlsec dependency from org.jboss.as.webservices.server.integration module > ----------------------------------------------------------------------------------------------------- > > Key: WFLY-6163 > URL: https://issues.jboss.org/browse/WFLY-6163 > Project: WildFly > Issue Type: Task > Reporter: Alessio Soldano > Assignee: Alessio Soldano > Fix For: 10.1.0.Final > > > We can remove org.apache.santuario.xmlsec dependency from org.jboss.as.webservices.server.integration module as Santuario is not needed directly from JBossWS (it's directly used by WSS4J and CXF though). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

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 commented on WFCORE-761: ------------------------------------------------ Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1147352|https://bugzilla.redhat.com/show_bug.cgi?id=1147352] from ON_QA to VERIFIED > 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)

9 years, 12 months

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 commented on WFCORE-547: ------------------------------------------------ Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1147352|https://bugzilla.redhat.com/show_bug.cgi?id=1147352] from ON_QA to VERIFIED > 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)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBJCA-1317) Log jndi-name in console log to identify datasource with wrong credentials if security-domain is used

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBJCA-1317?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on JBJCA-1317: ------------------------------------------------ Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1315439|https://bugzilla.redhat.com/show_bug.cgi?id=1315439] from ON_QA to VERIFIED > Log jndi-name in console log to identify datasource with wrong credentials if security-domain is used > ----------------------------------------------------------------------------------------------------- > > Key: JBJCA-1317 > URL: https://issues.jboss.org/browse/JBJCA-1317 > Project: IronJacamar > Issue Type: Task > Components: Core, Deployer > Reporter: Lin Gao > Assignee: Lin Gao > Priority: Minor > Fix For: WildFly/IronJacamar 1.3.4.Final, 1.0.37.Final, 1.2.8.Final > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6104) Too many invocations to a remote EJB from multiple threads cause infinite wait

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFLY-6104?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on WFLY-6104: ----------------------------------------------- Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1302181|https://bugzilla.redhat.com/show_bug.cgi?id=1302181] from ON_QA to VERIFIED > Too many invocations to a remote EJB from multiple threads cause infinite wait > ------------------------------------------------------------------------------ > > Key: WFLY-6104 > URL: https://issues.jboss.org/browse/WFLY-6104 > Project: WildFly > Issue Type: Bug > Components: Remoting > Affects Versions: 10.0.0.Final > Reporter: Tomas Hofman > Assignee: Tomas Hofman > > https://bugzilla.redhat.com/show_bug.cgi?id=1302181 > While a thread (1) of EJB client invokes a remote EJB which needs long > processing time and wait for the response, if the other threads complete > more than 65536 invocations to the remote EJB, EJBCLIENT000011 message like > below occurs in EJB client side and the waiting thread (1) falls into > infinite wait for the response. > INFO: EJBCLIENT000011: Discarding result for invocation id 0 since no > waiting context found > All invocations should successfully complete regardless of the number of > invocations. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

1
0
0 / 0

[JBoss JIRA] (JBEE-161) BeanELResolver does not support methods that use varargs

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JBEE-161?page=com.atlassian.jira.plugin.s... ] RH Bugzilla Integration commented on JBEE-161: ---------------------------------------------- Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1292891|https://bugzilla.redhat.com/show_bug.cgi?id=1292891] from ON_QA to VERIFIED > BeanELResolver does not support methods that use varargs > -------------------------------------------------------- > > Key: JBEE-161 > URL: https://issues.jboss.org/browse/JBEE-161 > Project: JBoss JavaEE Spec APIs > Issue Type: Bug > Components: jboss-el-api > Environment: jboss-el-api_2.2_spec-1.0.4.Final-redhat-1 > Reporter: Ingo Weiss > Assignee: Scott Marlow > Labels: el > Fix For: jboss-el-api_3.0_spec-1.0.6.Final > > Attachments: beanELResolver4VarArgs.zip > > > When passing BeanELResolver a method that uses varargs, BeanELResolver throws the following exception: > {code} > java.lang.IllegalArgumentException: wrong number of arguments > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:497) > at javax.el.BeanELResolver.invokeMethod(BeanELResolver.java:834) > at javax.el.BeanELResolver.invoke(BeanELResolver.java:527) > at org.apache.el.parser.AstValue.getValue(AstValue.java:156) > at BeanELResolverTest.readExpressionValue(BeanELResolverTest.java:32) > at BeanELResolverTest.testMethodWithFixArgumentList(BeanELResolverTest.java:21) > {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 12 months

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: ----------------------------------------------- Peter Mackay <pmackay(a)redhat.com> changed the Status of [bug 1309174|https://bugzilla.redhat.com/show_bug.cgi?id=1309174] from ON_QA to VERIFIED > 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)

9 years, 12 months

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 May 2016