June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-6510) HHH-10679: Subselect not used when batch loading by id

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6510?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-6510. ------------------------------ Release Notes Text: Closing as a duplicate of issue HHH-10679 Resolution: Duplicate Issue > HHH-10679: Subselect not used when batch loading by id > ------------------------------------------------------ > > Key: WFLY-6510 > URL: https://issues.jboss.org/browse/WFLY-6510 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Stephen Fikes > Assignee: Scott Marlow > > Subselect not used when batch loading by id -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-551) Add the ability to specify a one-time password or pass phrase via AuthenticationConfiguration

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-551?page=com.atlassian.jira.plugin.sy... ] Farah Juma updated ELY-551: --------------------------- Summary: Add the ability to specify a one-time password or pass phrase via AuthenticationConfiguration (was: Add the ability to specify a one-time password or pass phrase to AuthenticationConfiguration) > Add the ability to specify a one-time password or pass phrase via AuthenticationConfiguration > --------------------------------------------------------------------------------------------- > > Key: ELY-551 > URL: https://issues.jboss.org/browse/ELY-551 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Authentication Client > Reporter: Farah Juma > Assignee: Farah Juma > > This is needed for the OTP SASL mechanism. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6510) HHH-10679: Subselect not used when batch loading by id

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-6510?page=com.atlassian.jira.plugin.... ] Scott Marlow commented on WFLY-6510: ------------------------------------ Closed as a duplicate of issue HHH-10679 > HHH-10679: Subselect not used when batch loading by id > ------------------------------------------------------ > > Key: WFLY-6510 > URL: https://issues.jboss.org/browse/WFLY-6510 > Project: WildFly > Issue Type: Bug > Components: JPA / Hibernate > Affects Versions: 10.0.0.Final > Reporter: Stephen Fikes > Assignee: Scott Marlow > > Subselect not used when batch loading by id -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-535) Add the ability to handle password updates and resets for the OTP SASL mechanism

by Farah Juma (JIRA)

[ https://issues.jboss.org/browse/ELY-535?page=com.atlassian.jira.plugin.sy... ] Farah Juma updated ELY-535: --------------------------- Summary: Add the ability to handle password updates and resets for the OTP SASL mechanism (was: Make use of realm events to handle password updates and resets for the OTP SASL mechanism) > Add the ability to handle password updates and resets for the OTP SASL mechanism > -------------------------------------------------------------------------------- > > Key: ELY-535 > URL: https://issues.jboss.org/browse/ELY-535 > Project: WildFly Elytron > Issue Type: Feature Request > Components: SASL > Reporter: Farah Juma > Assignee: Farah Juma > > For the OTP SASL mechanism, the stored credential needs to be updated once a guess has been verified. In the standard case, this involves updating the stored hash based on the guess and decrementing the sequence number by 1. The OTP SASL mechanism also supports OTP sequence resets, where a user provides both a guess and a new OTP password with new parameters. If verification of the guess succeeds, then the stored credential is updated based on the new password and new parameters. However, if verification of the guess succeeds but the new password/parameters are invalid, then the stored hash is updated based on the guess and the sequence number is decremented by 1, as in the non-reset case (note that SASL auth fails in this case though). > PR #277 [adds handling|https://github.com/kabir/wildfly-elytron/blob/otp-test/src/main/...] for a {{CredentialUpdateCallback}} in {{ServerAuthenticationContext}}. This is used to handle both the OTP sequence reset case as well as the non-reset case. Instead of manipulating the realm identity directly in the SAC callback handler, we should be able to make use of [realm events|https://github.com/wildfly-security/wildfly-elytron/pull/295] so that the realm itself can handle OTP updates and resets. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-563) Clean up SSLExplorer

by David Lloyd (JIRA)

David Lloyd created ELY-563: ------------------------------- Summary: Clean up SSLExplorer Key: ELY-563 URL: https://issues.jboss.org/browse/ELY-563 Project: WildFly Elytron Issue Type: Task Components: SSL Reporter: David Lloyd Priority: Minor The code in SSLExplorer works but it's pretty ugly and could be cleaned up to be marginally more efficient and neater. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-562) Add cipher suite information to SSLConnectionInformation

by David Lloyd (JIRA)

David Lloyd created ELY-562: ------------------------------- Summary: Add cipher suite information to SSLConnectionInformation Key: ELY-562 URL: https://issues.jboss.org/browse/ELY-562 Project: WildFly Elytron Issue Type: Feature Request Components: SSL Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.1.0.Beta6 Add cipher suites to the SSL context selection process. This may help with HTTP/2.0 in the future, among other things. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1155) ClassCastException after deserialization of kiebase

by Mariano Nicolas De Maio (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1155?page=com.atlassian.jira.plugi... ] Mariano Nicolas De Maio commented on DROOLS-1155: ------------------------------------------------- Stack trace obtained after serialized kie base is deserialized, a KieSession is created, and used exactly the same way as before: testSerializedKbase(org.drools.issue.test.RuleEngineTest) Time elapsed: 7.548 sec <<< ERROR! java.lang.RuntimeException: inMonthDayInterval($evalTime, 9, 1, 4, 1) : java.lang.ClassCastException: org.drools.core.reteoo.InitialFactImpl cannot be cast to org.drools.issue.trait.EvalTime at org.drools.core.rule.EvalCondition.isAllowed(EvalCondition.java:123) at org.drools.core.phreak.PhreakEvalNode.doLeftInserts(PhreakEvalNode.java:70) at org.drools.core.phreak.PhreakEvalNode.doNode(PhreakEvalNode.java:54) at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:349) at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:301) at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:136) at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:94) at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:73) at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:1007) at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1350) at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1288) at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1333) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1324) at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1305) at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:111) at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:36) at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:136) at org.drools.core.command.runtime.BatchExecutionCommandImpl.execute(BatchExecutionCommandImpl.java:51) at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:220) at org.drools.issue.test.RuleEngineTest.executeRules(RuleEngineTest.java:120) at org.drools.issue.test.RuleEngineTest.testSerializedKbase(RuleEngineTest.java:93) 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 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) at org.junit.runners.ParentRunner.run(ParentRunner.java:309) at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:252) at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:141) at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:112) 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 org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:189) at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:165) at org.apache.maven.surefire.booter.ProviderFactory.invokeProvider(ProviderFactory.java:85) at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:115) at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:75) Caused by: java.lang.ClassCastException: org.drools.core.reteoo.InitialFactImpl cannot be cast to org.drools.issue.trait.EvalTime at org.drools.base.org.drools.issue.trait.EvalTime1463823265$getEvalTime.getValue(Unknown Source) at org.drools.core.base.ClassFieldReader.getValue(ClassFieldReader.java:91) at org.drools.core.rule.Declaration.getValue(Declaration.java:214) at org.drools.core.base.mvel.MVELCompilationUnit.updateFactory(MVELCompilationUnit.java:389) at org.drools.core.base.mvel.MVELCompilationUnit.updateFactory(MVELCompilationUnit.java:333) at org.drools.core.base.mvel.MVELEvalExpression.evaluate(MVELEvalExpression.java:88) at org.drools.core.rule.EvalCondition.isAllowed(EvalCondition.java:118) ... 50 more > ClassCastException after deserialization of kiebase > --------------------------------------------------- > > Key: DROOLS-1155 > URL: https://issues.jboss.org/browse/DROOLS-1155 > Project: Drools > Issue Type: Bug > Affects Versions: 6.3.0.Final, 7.0.0.Beta1 > Reporter: Mariano Nicolas De Maio > Assignee: Mario Fusco > Attachments: issue-repro.tar.gz > > > After the fix for issue DROOLS-1123, I was able to follow deserialize the kie base correctly. However, after deserialization, the kie sessions do not behave in the same way. The attached project has a reproduction case for the difference in behavior -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6666) clustering-web-infinispan: infinite recursion in session activation code

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-6666?page=com.atlassian.jira.plugin.... ] Paul Ferraro closed WFLY-6666. ------------------------------ Resolution: Out of Date The 9.x branch is no longer active. > clustering-web-infinispan: infinite recursion in session activation code > ------------------------------------------------------------------------ > > Key: WFLY-6666 > URL: https://issues.jboss.org/browse/WFLY-6666 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 9.0.2.Final > Reporter: Kamil Podlešák > Assignee: Paul Ferraro > Attachments: stacktrace, stacktrace2 > > > When unmarshalling of session throws one of the expected exception (ClassNotFoundException, InvalidClassException, InvalidObjectException), it is handled by attempt to remote this session from cache (CoarseSessionFactory.findValue). This attempt, however, ends up in the same method, tries to unmarshall the session, catches the exception.... until it reaches stack limit and throws StackOverflowError. > As an added injury, each exception is logged with full stack, which is getting longer and longer. Total log size is approximately 40MB per request, so it usually quite quickly disappears by log rotation. > Version 10.0.0 is OK (the code is completely different and does not have this problem). > See also: WFLY-6665 (similar, but not exactly the same bug). -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1197) concurrency issue when having multiple kie containers

by Viacheslav Krot (JIRA)

Viacheslav Krot created DROOLS-1197: --------------------------------------- Summary: concurrency issue when having multiple kie containers Key: DROOLS-1197 URL: https://issues.jboss.org/browse/DROOLS-1197 Project: Drools Issue Type: Bug Components: core engine Affects Versions: 6.4.0.Final Reporter: Viacheslav Krot Assignee: Mario Fusco It seems there is some bug related to concurrency when creating multiple kie containers in different threads. Here is a test, that runs two threads, each has a loop creating a new kie container and running rule with stateless session. I expect this usecase to work, but it fails eventually - at some point in time kie container has loaded rules other than expected. Is the test wrong or is there is a bug? {{noformat}} import static org.hamcrest.Matchers.hasSize; import static org.junit.Assert.assertThat; import java.util.ArrayList; import java.util.Arrays; import java.util.List; import java.util.concurrent.CompletableFuture; import org.junit.Test; import org.kie.api.KieServices; import org.kie.api.builder.KieBuilder; import org.kie.api.builder.KieFileSystem; import org.kie.api.builder.Message; import org.kie.api.io.KieResources; import org.kie.api.io.Resource; import org.kie.api.runtime.KieContainer; public class ConcurrencyTest { KieContainer createContainer(String rule) { KieServices kieServices = KieServices.Factory.get(); KieResources kieResources = kieServices.getResources(); KieFileSystem kieFileSystem = kieServices.newKieFileSystem(); Resource resource = kieResources.newByteArrayResource(rule.getBytes()); kieFileSystem.write("src/main/resources/rule.drl", resource); KieBuilder kb = kieServices.newKieBuilder(kieFileSystem).buildAll(); if (kb.getResults().hasMessages(Message.Level.ERROR)) { throw new RuntimeException("Build Errors:\n" + kb.getResults().toString()); } return kieServices.newKieContainer(kb.getKieModule().getReleaseId()); } String returns1 = "import java.util.List;\n" + "\n" + "rule \"rule1\"\n" + "\tdialect \"mvel\"\n" + "\twhen\n" + "\t\tres : List( )\n" + "\tthen\n" + " res.add(\"1\");\n" + "end"; String returns2 = "import java.util.List;\n" + "\n" + "rule \"rule1\"\n" + "\tdialect \"mvel\"\n" + "\twhen\n" + "\t\tres : List( )\n" + "\tthen\n" + " res.add(\"1\");\n" + " res.add(\"2\");\n" + "end"; @Test public void test() throws Exception { CompletableFuture<?> f1 = CompletableFuture.runAsync(() -> { for (int i = 0; i < 100; i++) { List<String> res1 = new ArrayList<>(); createContainer(returns1).newStatelessKieSession().execute(Arrays.asList(res1)); assertThat(res1, hasSize(1)); } }); CompletableFuture<?> f2 = CompletableFuture.runAsync(() -> { for (int i = 0; i < 100; i++) { List<String> res2 = new ArrayList<>(); createContainer(returns2).newStatelessKieSession().execute(Arrays.asList(res2)); assertThat(res2, hasSize(2)); } }); f1.get(); f2.get(); } } {{noformat}} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

[JBoss JIRA] (ELY-561) Add ALPN information to SSLConnectionInformation

by David Lloyd (JIRA)

David Lloyd created ELY-561: ------------------------------- Summary: Add ALPN information to SSLConnectionInformation Key: ELY-561 URL: https://issues.jboss.org/browse/ELY-561 Project: WildFly Elytron Issue Type: Feature Request Components: SSL Reporter: David Lloyd Assignee: David Lloyd Fix For: 1.1.0.Beta6 ALPN information is part of the selection criteria. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 4 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira June 2016