May 2016 - jboss-jira - Jboss List Archives

[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)

8 years, 1 month

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)

8 years, 1 month

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)

8 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: ----------------------------------------------- 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)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-526) Basic authentication is now required to perform an authorization check before flagging authentication as successful.

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-526: ------------------------------------ Summary: Basic authentication is now required to perform an authorization check before flagging authentication as successful. Key: ELY-526 URL: https://issues.jboss.org/browse/ELY-526 Project: WildFly Elytron Issue Type: Enhancement Components: HTTP Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 1.1.0.Beta6 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6587) Admin console: log categories filter

by Vsevolod Golovanov (JIRA)

Vsevolod Golovanov created WFLY-6587: ---------------------------------------- Summary: Admin console: log categories filter Key: WFLY-6587 URL: https://issues.jboss.org/browse/WFLY-6587 Project: WildFly Issue Type: Feature Request Affects Versions: 10.0.0.Final Reporter: Vsevolod Golovanov Assignee: Jason Greene Wildfly 8's admin console allowed filtering log categories in the logging subsystem configuration, there was a filter text input field. It was pretty useful as there could be a lot of log categories, and the category table was paginated with only 8 entries on each page. Wildfly 10's admin console misses the filter function and paginates with 5 entries per page. Please bring the filter back, and maybe show more entries per page (10?). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6586) Odd package security/subsystem/src/main/java/org/jboss/as/security/org/jboss/as/security/lru

by Chao Wang (JIRA)

Chao Wang created WFLY-6586: ------------------------------- Summary: Odd package security/subsystem/src/main/java/org/jboss/as/security/org/jboss/as/security/lru Key: WFLY-6586 URL: https://issues.jboss.org/browse/WFLY-6586 Project: WildFly Issue Type: Bug Components: Security Reporter: Chao Wang Assignee: Chao Wang Priority: Minor Fix For: 10.0.0.Final package name in source https://github.com/wildfly/wildfly/tree/master/security/subsystem/src/mai... is odd. There is redundant org/jboss/as/security/ -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6585) IIOP bean lookup fails after transaction timeout happens

by Ondřej Chaloupka (JIRA)

Ondřej Chaloupka created WFLY-6585: -------------------------------------- Summary: IIOP bean lookup fails after transaction timeout happens Key: WFLY-6585 URL: https://issues.jboss.org/browse/WFLY-6585 Project: WildFly Issue Type: Bug Components: IIOP Reporter: Ondřej Chaloupka Assignee: Tomasz Adamski IIOP lookup call for a bean could fails when transaction timeout happens on the lookuped bean. The exception is {{javax.naming.NameNotFoundException: null}} [1] My feeling is that the issue has something to do with transaction timeout when JTS/iiop lookup is used. My experience is that the same type of testcase passes when JTA/ejb remoting is used. What I can say I think that lookup fails on server at time when 'get_txcontext' is used. I mean that is what could be seen from server.log file [2] (attached). [1] {code} javax.naming.NameNotFoundException: null at org.omg.CosNaming.NamingContextPackage.NotFoundHelper.read(NotFoundHelper.java:72) at org.omg.CosNaming._NamingContextStub.resolve(_NamingContextStub.java:251) at com.sun.jndi.cosnaming.CNCtx.callResolve(CNCtx.java:486) at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:539) at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:517) at javax.naming.InitialContext.lookup(InitialContext.java:417) at org.jboss.as.test.integration.transactions.TransactionTestLookupUtil.lookupIIOP(TransactionTestLookupUtil.java:77) at org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.lookupStateful(IIOPTimeoutTestCase.java:176) at org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful(IIOPTimeoutTestCase.java:157) {code} [2] 2016-04-27 19:38:09,297 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionClientRequestInterceptorImpl::send_request ( get_txcontext ) nodeId=1 requestId=64 2016-04-27 19:38:09,297 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( get_txcontext ) nodeId=1 requestId=70 2016-04-27 19:38:09,297 TRACE [org.wildfly.iiop.openjdk] (p: default-threadpool; w: Idle) Intercepting receive_request_service_contexts, operation: get_txcontext 2016-04-27 19:38:09,300 TRACE [org.wildfly.iiop.openjdk] (p: default-threadpool; w: Idle) send_exception: get_txcontext 2016-04-27 19:38:09,300 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::send_exception ( get_txcontext ) nodeId=1 requestId=70 2016-04-27 19:38:09,300 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::suspendContext ( get_txcontext ) nodeId=1 requestId=70 2016-04-27 19:38:09,303 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionClientRequestInterceptorImpl::receive_exception ( get_txcontext ) nodeId=1 requestId=64 2016-04-27 19:38:09,305 TRACE [org.wildfly.iiop.openjdk] (p: default-threadpool; w: Idle) send_exception: resolve 2016-04-27 19:38:09,305 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::send_exception ( resolve ) nodeId=1 requestId=69 2016-04-27 19:38:09,305 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::suspendContext ( resolve ) nodeId=1 requestId=69 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-6585) IIOP bean lookup fails after transaction timeout happens

by Ondřej Chaloupka (JIRA)

[ https://issues.jboss.org/browse/WFLY-6585?page=com.atlassian.jira.plugin.... ] Ondřej Chaloupka updated WFLY-6585: ----------------------------------- Affects Version/s: 10.0.0.Final > IIOP bean lookup fails after transaction timeout happens > -------------------------------------------------------- > > Key: WFLY-6585 > URL: https://issues.jboss.org/browse/WFLY-6585 > Project: WildFly > Issue Type: Bug > Components: IIOP > Affects Versions: 10.0.0.Final > Reporter: Ondřej Chaloupka > Assignee: Tomasz Adamski > > IIOP lookup call for a bean could fails when transaction timeout happens on the lookuped bean. The exception is {{javax.naming.NameNotFoundException: null}} [1] > My feeling is that the issue has something to do with transaction timeout when JTS/iiop lookup is used. My experience is that the same type of testcase passes when JTA/ejb remoting is used. > What I can say I think that lookup fails on server at time when 'get_txcontext' is used. I mean that is what could be seen from server.log file [2] (attached). > [1] > {code} > javax.naming.NameNotFoundException: null > at org.omg.CosNaming.NamingContextPackage.NotFoundHelper.read(NotFoundHelper.java:72) > at org.omg.CosNaming._NamingContextStub.resolve(_NamingContextStub.java:251) > at com.sun.jndi.cosnaming.CNCtx.callResolve(CNCtx.java:486) > at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:539) > at com.sun.jndi.cosnaming.CNCtx.lookup(CNCtx.java:517) > at javax.naming.InitialContext.lookup(InitialContext.java:417) > at org.jboss.as.test.integration.transactions.TransactionTestLookupUtil.lookupIIOP(TransactionTestLookupUtil.java:77) > at org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.lookupStateful(IIOPTimeoutTestCase.java:176) > at org.jboss.as.test.iiop.transaction.timeout.IIOPTimeoutTestCase.timeoutStateful(IIOPTimeoutTestCase.java:157) > {code} > [2] > 2016-04-27 19:38:09,297 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionClientRequestInterceptorImpl::send_request ( get_txcontext ) nodeId=1 requestId=64 > 2016-04-27 19:38:09,297 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::receive_request_service_contexts ( get_txcontext ) nodeId=1 requestId=70 > 2016-04-27 19:38:09,297 TRACE [org.wildfly.iiop.openjdk] (p: default-threadpool; w: Idle) Intercepting receive_request_service_contexts, operation: get_txcontext > 2016-04-27 19:38:09,300 TRACE [org.wildfly.iiop.openjdk] (p: default-threadpool; w: Idle) send_exception: get_txcontext > 2016-04-27 19:38:09,300 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::send_exception ( get_txcontext ) nodeId=1 requestId=70 > 2016-04-27 19:38:09,300 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::suspendContext ( get_txcontext ) nodeId=1 requestId=70 > 2016-04-27 19:38:09,303 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionClientRequestInterceptorImpl::receive_exception ( get_txcontext ) nodeId=1 requestId=64 > 2016-04-27 19:38:09,305 TRACE [org.wildfly.iiop.openjdk] (p: default-threadpool; w: Idle) send_exception: resolve > 2016-04-27 19:38:09,305 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::send_exception ( resolve ) nodeId=1 requestId=69 > 2016-04-27 19:38:09,305 TRACE [com.arjuna.ats.jts] (p: default-threadpool; w: Idle) InterpositionServerRequestInterceptorImpl::suspendContext ( resolve ) nodeId=1 requestId=69 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1166) ClassNotFoundException for the drools function when large number of valuations

by Matteo Mortari (JIRA)

Matteo Mortari created DROOLS-1166: -------------------------------------- Summary: ClassNotFoundException for the drools function when large number of valuations Key: DROOLS-1166 URL: https://issues.jboss.org/browse/DROOLS-1166 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.4.0.Final Reporter: Matteo Mortari Assignee: Mario Fusco Priority: Minor Attachments: 20160505.testjitfunction.zip Hello, for a large number of evaluations a {{ClassNotFoundException}} is thrown missing to find appropriate class for the drools function defined. In the attached reproducer, a for loop inserts a given number of facts into the session; for a small number of facts, no error is thrown. For example given {code} for (int i=0; i<20; i++) { session.insert("Ciao "+i); session.fireAllRules(); } {code} all is fine. When running with say: {code} for (int i=0; i<150; i++) { session.insert("Ciao "+i); session.fireAllRules(); } {code} then throws, snippet: {code} java.lang.NoClassDefFoundError: com/acme/testjitfunction/EntryKey$1 at com.acme.testjitfunction.EntryKey.entryKey(EntryKey.java:51) at ConditionEvaluator1fae754676b54e869aa5b558ba2d7991.evaluate(Unknown Source) at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:258) at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:214) at org.drools.core.phreak.PhreakAccumulateNode.evaluateResultConstraints(PhreakAccumulateNode.java:696) at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:114) at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:534) [...] Caused by: java.lang.ClassNotFoundException: com.acme.testjitfunction.EntryKey$1 at java.lang.ClassLoader.findClass(ClassLoader.java:530) at java.lang.ClassLoader.loadClass(ClassLoader.java:424) at org.drools.core.common.ProjectClassLoader$DefaultInternalTypesClassLoader.loadType(ProjectClassLoader.java:393) at org.drools.core.common.ProjectClassLoader$DefaultInternalTypesClassLoader.loadClass(ProjectClassLoader.java:380) at java.lang.ClassLoader.loadClass(ClassLoader.java:357) ... 44 more {code} I'm also wondering if maybe this is not the best possible way to "backport" lambdas as a drool function; in case a more proper way to implement them as a drool function is possible, kindly let me know. Can you kindly advise, please? Thank you very much Ciao MM -- This message was sent by Atlassian JIRA (v6.4.11#64026)

8 years, 1 month

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira May 2016