January 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2275) Null pointer exception when calling updateToVersion with existing data in a stateful KieSession

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2275?page=com.atlassian.jira.plugi... ] Edson Tirelli commented on DROOLS-2275: --------------------------------------- [~mfusco] isn't this the same you fixed a few weeks ago? > Null pointer exception when calling updateToVersion with existing data in a stateful KieSession > ----------------------------------------------------------------------------------------------- > > Key: DROOLS-2275 > URL: https://issues.jboss.org/browse/DROOLS-2275 > Project: Drools > Issue Type: Bug > Environment: Wildfly 8.2.1, Standalone > Reporter: Chad Poe > Assignee: Mario Fusco > Attachments: org.drools.test.beta-memory.zip > > > This error was first discovered in a proprietary application that is running in wildfly 8.2.1. Up until now I was unable to reproduce outside of the mentioned environment. After narrowing down the exact conditions that cause the error to occur I was able to create a sample project that forces the issue to occur. Below is the stack trace: > Caused by: java.lang.NullPointerException > at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:93) > at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:88) > at org.drools.core.reteoo.SingleObjectSinkAdapter.staticDoLinkRiaNode(SingleObjectSinkAdapter.java:111) > at org.drools.core.reteoo.SingleObjectSinkAdapter.doLinkRiaNode(SingleObjectSinkAdapter.java:93) > at org.drools.core.reteoo.RiaPathMemory.doLinkRule(RiaPathMemory.java:52) > at org.drools.core.reteoo.PathMemory.linkSegment(PathMemory.java:103) > at org.drools.core.reteoo.SegmentMemory.notifyRuleLinkSegment(SegmentMemory.java:192) > at org.drools.core.phreak.AddRemoveRule.addNewPaths(AddRemoveRule.java:452) > at org.drools.core.phreak.AddRemoveRule.addRule(AddRemoveRule.java:123) > at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:189) > at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133) > at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110) > at org.drools.core.impl.KnowledgeBaseImpl.internalAddRule(KnowledgeBaseImpl.java:1530) > at org.drools.core.impl.KnowledgeBaseImpl.lambda$addRules$4(KnowledgeBaseImpl.java:1523) > at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734) > at org.drools.core.impl.KnowledgeBaseImpl.addRules(KnowledgeBaseImpl.java:1521) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRete(KnowledgeBuilderImpl.java:1010) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRules(KnowledgeBuilderImpl.java:2524) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2450) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:109) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:99) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.rebuildAll(KieContainerImpl.java:473) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateKBase(KieContainerImpl.java:309) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.lambda$update$0(KieContainerImpl.java:260) > at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:260) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:199) > at org.drools.test.KieRuntimeManager.buildOnKfs(KieRuntimeManager.java:202) > at org.drools.test.KieRuntimeManager.loadRule(KieRuntimeManager.java:147) > at org.drools.test.DroolsReasonerContainer.loadRule(DroolsReasonerContainer.java:22) > at org.drools.test.App.main(App.java:22) > ... 6 more -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2275) Null pointer exception when calling updateToVersion with existing data in a stateful KieSession

by Edson Tirelli (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2275?page=com.atlassian.jira.plugi... ] Edson Tirelli reassigned DROOLS-2275: ------------------------------------- Assignee: Mario Fusco (was: Edson Tirelli) > Null pointer exception when calling updateToVersion with existing data in a stateful KieSession > ----------------------------------------------------------------------------------------------- > > Key: DROOLS-2275 > URL: https://issues.jboss.org/browse/DROOLS-2275 > Project: Drools > Issue Type: Bug > Environment: Wildfly 8.2.1, Standalone > Reporter: Chad Poe > Assignee: Mario Fusco > Attachments: org.drools.test.beta-memory.zip > > > This error was first discovered in a proprietary application that is running in wildfly 8.2.1. Up until now I was unable to reproduce outside of the mentioned environment. After narrowing down the exact conditions that cause the error to occur I was able to create a sample project that forces the issue to occur. Below is the stack trace: > Caused by: java.lang.NullPointerException > at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:93) > at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:88) > at org.drools.core.reteoo.SingleObjectSinkAdapter.staticDoLinkRiaNode(SingleObjectSinkAdapter.java:111) > at org.drools.core.reteoo.SingleObjectSinkAdapter.doLinkRiaNode(SingleObjectSinkAdapter.java:93) > at org.drools.core.reteoo.RiaPathMemory.doLinkRule(RiaPathMemory.java:52) > at org.drools.core.reteoo.PathMemory.linkSegment(PathMemory.java:103) > at org.drools.core.reteoo.SegmentMemory.notifyRuleLinkSegment(SegmentMemory.java:192) > at org.drools.core.phreak.AddRemoveRule.addNewPaths(AddRemoveRule.java:452) > at org.drools.core.phreak.AddRemoveRule.addRule(AddRemoveRule.java:123) > at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:189) > at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133) > at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110) > at org.drools.core.impl.KnowledgeBaseImpl.internalAddRule(KnowledgeBaseImpl.java:1530) > at org.drools.core.impl.KnowledgeBaseImpl.lambda$addRules$4(KnowledgeBaseImpl.java:1523) > at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734) > at org.drools.core.impl.KnowledgeBaseImpl.addRules(KnowledgeBaseImpl.java:1521) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRete(KnowledgeBuilderImpl.java:1010) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRules(KnowledgeBuilderImpl.java:2524) > at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2450) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:109) > at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:99) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.rebuildAll(KieContainerImpl.java:473) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateKBase(KieContainerImpl.java:309) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.lambda$update$0(KieContainerImpl.java:260) > at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:260) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:199) > at org.drools.test.KieRuntimeManager.buildOnKfs(KieRuntimeManager.java:202) > at org.drools.test.KieRuntimeManager.loadRule(KieRuntimeManager.java:147) > at org.drools.test.DroolsReasonerContainer.loadRule(DroolsReasonerContainer.java:22) > at org.drools.test.App.main(App.java:22) > ... 6 more -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-9647) allow property name to be specified in PersistenceUnit/PersistenceContext unitName

by Scott Marlow (JIRA)

[ https://issues.jboss.org/browse/WFLY-9647?page=com.atlassian.jira.plugin.... ] Scott Marlow closed WFLY-9647. ------------------------------ > allow property name to be specified in PersistenceUnit/PersistenceContext unitName > ---------------------------------------------------------------------------------- > > Key: WFLY-9647 > URL: https://issues.jboss.org/browse/WFLY-9647 > Project: WildFly > Issue Type: Task > Components: JPA / Hibernate > Reporter: Scott Marlow > Assignee: Scott Marlow > Fix For: 12.0.0.Alpha1 > > > Add extension that allows system property substitution of unitName: > {code} > @PersistenceContext(unitName = “${test.case.persistence.context}") > private EntityManager entityManager; > @PersistenceUnit(unitName = “${test.case.persistence.context}") > private EntityManagerFactory entityManagerFactory; > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3550) Inefficient algorithm for converting JMX attribute names to native resource attribute names

by Brian Stansberry (JIRA)

Brian Stansberry created WFCORE-3550: ---------------------------------------- Summary: Inefficient algorithm for converting JMX attribute names to native resource attribute names Key: WFCORE-3550 URL: https://issues.jboss.org/browse/WFCORE-3550 Project: WildFly Core Issue Type: Bug Components: JMX Reporter: Brian Stansberry Assignee: Brian Stansberry ModelControllerMBeanHelper is taking an MRR, using it to create a DMR ModelNode description of the resource type, and then iterating over the attribute names in that description tree to try and match up with the requested JMX attribute name. That middle step of creating the DMR description is very expensive; it produces a very large node tree. It's not necessary; the MRR already can tell you the legal attribute names. I believe this is legacy cruft from the early AS 7 days when the MRR wasn't always reliable for all attribute names. But it's been reliable for a long time now. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-63) Pluggable nonce handling strategy

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-63?page=com.atlassian.jira.plugin.sys... ] Darran Lofthouse commented on ELY-63: ------------------------------------- I need to dig out some notes but we also had some ideas to optimise how nonce counts are monitored within the NonceManager to optimise them and minimise the re-issuing of nonces but that may be another issue. This was more about adding custom impls but maybe we should get our impl sorted first. > Pluggable nonce handling strategy > --------------------------------- > > Key: ELY-63 > URL: https://issues.jboss.org/browse/ELY-63 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta14 > > > Implement a pluggable nonce handling strategy. > At the very least we need to be able to switch to using a SecureRandom instead of Random. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest fails on IBM JDK

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.s... ] Jan Kalina commented on ELY-1295: --------------------------------- [~rhn-support-pnag], if you are going to document impossibility to use PKCS12 as credential store on IBM, maybe will be ELY-1427 better issue to reference. (This issue is more focused on the test of it.) > KeyStoreCredentialStoreTest fails on IBM JDK > -------------------------------------------- > > Key: ELY-1295 > URL: https://issues.jboss.org/browse/ELY-1295 > Project: WildFly Elytron > Issue Type: Bug > Components: Credential Store > Reporter: Peter Palaga > Assignee: Priyanka Nag > Priority: Critical > Labels: ibm-java > Fix For: 1.2.0.Beta12 > > > {code} > export JAVA_HOME=path/to/ibm/java8 > > $JAVA_HOME/bin/java -version > java version "1.8.0" > Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12)) > IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled) > J9VM - R28_Java8_SR3_20160915_0912_B318796 > JIT - tr.r14.java.green_20160818_122998 > GC - R28_Java8_SR3_20160915_0912_B318796_CMPRSS > J9CL - 20160915_318796) > JCL - 20160914_01 based on Oracle jdk8u101-b13 > > mvn clean test -Dtest=KeyStoreCredentialStoreTest > {code} > Expected: KeyStoreCredentialStoreTest should pass > Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws > {code} > java.lang.ClassNotFoundException: javax.crypto.JceSecurity > at java.lang.Class.forNameImpl(Native Method) > at java.lang.Class.forName(Class.java:278) > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89) > ... > {code} > because {{javax.crypto.JceSecurity}} does not exist in IBM JRE. > It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK. > But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception: > {code} > org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464) > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.lang.reflect.Method.invoke(Method.java:508) > at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274) > at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238) > at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161) > at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290) > at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242) > at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121) > Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available > at java.security.KeyStore.getEntry(KeyStore.java:1532) > at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462) > ... 10 more > Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available > ... 12 more > {code} > [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/7296... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-63) Pluggable nonce handling strategy

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-63?page=com.atlassian.jira.plugin.sys... ] Jan Kalina commented on ELY-63: ------------------------------- NonceManager currently use SecureRandom (hardcoded) - does this mean there should be plugable privateKey generator for NonceManager? Or bigger part of NonceManager should be replacable? > Pluggable nonce handling strategy > --------------------------------- > > Key: ELY-63 > URL: https://issues.jboss.org/browse/ELY-63 > Project: WildFly Elytron > Issue Type: Task > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta14 > > > Implement a pluggable nonce handling strategy. > At the very least we need to be able to switch to using a SecureRandom instead of Random. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-61) Ensure the requirements and options for each mechanism are described within the mechanism.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-61?page=com.atlassian.jira.plugin.sys... ] Jan Kalina commented on ELY-61: ------------------------------- Where it should be described? In javadoc of mechanism classes? Or is some documentation page? > Ensure the requirements and options for each mechanism are described within the mechanism. > ------------------------------------------------------------------------------------------ > > Key: ELY-61 > URL: https://issues.jboss.org/browse/ELY-61 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Mechanisms > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta14 > > > Everything from callback requirements, supported config options to System properties. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-61) Ensure the requirements and options for each mechanism are described within the mechanism.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-61?page=com.atlassian.jira.plugin.sys... ] Jan Kalina updated ELY-61: -------------------------- Component/s: Authentication Mechanisms > Ensure the requirements and options for each mechanism are described within the mechanism. > ------------------------------------------------------------------------------------------ > > Key: ELY-61 > URL: https://issues.jboss.org/browse/ELY-61 > Project: WildFly Elytron > Issue Type: Task > Components: Authentication Mechanisms > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta14 > > > Everything from callback requirements, supported config options to System properties. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-23) authPassword LDAP attribute - add support for RFC5803

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-23?page=com.atlassian.jira.plugin.sys... ] Jan Kalina updated ELY-23: -------------------------- Summary: authPassword LDAP attribute - add support for RFC5803 (was: Add support for RFC5803) > authPassword LDAP attribute - add support for RFC5803 > ----------------------------------------------------- > > Key: ELY-23 > URL: https://issues.jboss.org/browse/ELY-23 > Project: WildFly Elytron > Issue Type: Sub-task > Reporter: Darran Lofthouse > Fix For: 1.2.0.Beta14 > > > RFC5803 adds support for storing SCRAM secrets in the 'authPassword' attribute introduced by RFC3112 -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 3 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 January 2018