[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)
9 years, 12 months
[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)
9 years, 12 months
[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)
9 years, 12 months
[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)
9 years, 12 months
[JBoss JIRA] (DROOLS-1165) Syntax error on Java EE for 6.4.0.Final (6.3.0.Final worked fine)
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1165?page=com.atlassian.jira.plugi... ]
Mario Fusco resolved DROOLS-1165.
---------------------------------
Resolution: Rejected
This is a known issue caused by the fact that the version of Wildfly you're using depends on ecj 4.3.1. On Drools 6.4.0 we enabled full support for Java 8 but this requires ecj 4.4.2. Unfortunately the ecj version embedded in Wildfly overrides the one imported by Drools. Occasionally (as probably in your case) ecj 4.3.1 when configured to use Java 8 syntax fails even if the block of code it's trying to compile doesn't contain any Java 8 specific statement.
There are 2 workarounds for this:
# upgrading to a newer Wildfly version (better choice)
# in case you're not using any Java 8 feature you can force ecj to a specific Java compilation level (overriding the JVM one) by setting the System property "drools.dialect.java.compiler.lnglevel" to the desired language level, for instance "1.7".
> Syntax error on Java EE for 6.4.0.Final (6.3.0.Final worked fine)
> -----------------------------------------------------------------
>
> Key: DROOLS-1165
> URL: https://issues.jboss.org/browse/DROOLS-1165
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.4.0.Final
> Environment: Java EE 7, Wildfly
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: 20160505.syntaxerroronjavaeefor640f.zip
>
>
> Hello, not sure if this is actually a Drools issue, or just some compiler error due to some other dependencies issue. Anyhow attached reproducer contains a DRL syntactically correct, parses correctly 6.4.0.Final when not on Java EE. When on Java EE instead, fails to parse lamenting syntax error, snippet:
> {code}
> [ function valueSizeGEofvalueSizeGEof (line:42): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:42): The import java.util.stream.Collectors.groupingBy cannot be resolved
> valueSizeGEof (line:44): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:44): The import com.acme.testaccumulatestreamonjavaee.MapOfList.mapOfList cannot be resolved
> valueSizeGEof (line:46): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:46): The import com.acme.testaccumulatestreamonjavaee.EntryKey.entryKey cannot be resolved
> valueSizeGEof (line:52): Syntax error, parameterized types are only available if source level is 1.5 or greater
> valueSizeGEof (line:53): Type mismatch: cannot convert from Integer to int
> valueSizeGEof (line:54): Syntax error, parameterized types are only available if source level is 1.5 or greater
> valueSizeGEof (line:55): Syntax error, annotations are only available if source level is 1.5 or greater
> valueSizeGEof (line:56): Syntax error, parameterized types are only available if source level is 1.5 or greater
> ]
> {code}
> Please notice if using 6.3.0.Final, on Java EE, is OK without errors.
> For the reproducer, maven {{clean test}} using profile {{wildfy82-embedded}}. I am using Arquillian to demonstrate the difference using version 6.3.0.Final Vs 6.4.0.Final.
> Can you kindly advise, please?
> Thank you
> Ciao
> MM
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months
[JBoss JIRA] (DROOLS-1165) Syntax error on Java EE for 6.4.0.Final (6.3.0.Final worked fine)
by Mario Fusco (JIRA)
[ https://issues.jboss.org/browse/DROOLS-1165?page=com.atlassian.jira.plugi... ]
Mario Fusco reassigned DROOLS-1165:
-----------------------------------
Assignee: Mario Fusco (was: Mark Proctor)
> Syntax error on Java EE for 6.4.0.Final (6.3.0.Final worked fine)
> -----------------------------------------------------------------
>
> Key: DROOLS-1165
> URL: https://issues.jboss.org/browse/DROOLS-1165
> Project: Drools
> Issue Type: Bug
> Affects Versions: 6.4.0.Final
> Environment: Java EE 7, Wildfly
> Reporter: Matteo Mortari
> Assignee: Mario Fusco
> Priority: Minor
> Attachments: 20160505.syntaxerroronjavaeefor640f.zip
>
>
> Hello, not sure if this is actually a Drools issue, or just some compiler error due to some other dependencies issue. Anyhow attached reproducer contains a DRL syntactically correct, parses correctly 6.4.0.Final when not on Java EE. When on Java EE instead, fails to parse lamenting syntax error, snippet:
> {code}
> [ function valueSizeGEofvalueSizeGEof (line:42): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:42): The import java.util.stream.Collectors.groupingBy cannot be resolved
> valueSizeGEof (line:44): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:44): The import com.acme.testaccumulatestreamonjavaee.MapOfList.mapOfList cannot be resolved
> valueSizeGEof (line:46): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:46): The import com.acme.testaccumulatestreamonjavaee.EntryKey.entryKey cannot be resolved
> valueSizeGEof (line:52): Syntax error, parameterized types are only available if source level is 1.5 or greater
> valueSizeGEof (line:53): Type mismatch: cannot convert from Integer to int
> valueSizeGEof (line:54): Syntax error, parameterized types are only available if source level is 1.5 or greater
> valueSizeGEof (line:55): Syntax error, annotations are only available if source level is 1.5 or greater
> valueSizeGEof (line:56): Syntax error, parameterized types are only available if source level is 1.5 or greater
> ]
> {code}
> Please notice if using 6.3.0.Final, on Java EE, is OK without errors.
> For the reproducer, maven {{clean test}} using profile {{wildfy82-embedded}}. I am using Arquillian to demonstrate the difference using version 6.3.0.Final Vs 6.4.0.Final.
> Can you kindly advise, please?
> Thank you
> Ciao
> MM
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 12 months