February 2018 - jboss-jira - Jboss List Archives

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

by Chad Poe (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2275?page=com.atlassian.jira.plugi... ] Chad Poe commented on DROOLS-2275: ---------------------------------- Is there any update on this issue? I had looked threw previously closed tickets and couldn't seem to find a duplicate. > 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, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2252) Allow passing arguments when using custom IP address supplier

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/JGRP-2252?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec updated JGRP-2252: -------------------------------------- Description: When investigating x-site replication for one of more public clouds, we discover that it would be useful to have a Custom IP supplier that allows passing arguments into the supplier instance. An example could look like the following: {{external_addr="custom:org.bla.Blah;args:LoadBalancerServiceName"}} One might use the following demo for testing: https://github.com/infinispan-demos/JDG-x-site-replication-demo was: When investigating x-site replication for one of more public clouds, we discover that it would be useful to have a Custom IP supplier that allows passing arguments into the supplier instance. An example could look like the following: {{external_addr="custom:org.bla.Blah;args:LoadBalancerServiceName"}} > Allow passing arguments when using custom IP address supplier > ------------------------------------------------------------- > > Key: JGRP-2252 > URL: https://issues.jboss.org/browse/JGRP-2252 > Project: JGroups > Issue Type: Task > Affects Versions: 4.0.10 > Environment: Kubernetes and OpenShift > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > > When investigating x-site replication for one of more public clouds, we discover that it would be useful to have a Custom IP supplier that allows passing arguments into the supplier instance. > An example could look like the following: {{external_addr="custom:org.bla.Blah;args:LoadBalancerServiceName"}} > One might use the following demo for testing: https://github.com/infinispan-demos/JDG-x-site-replication-demo -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2252) Allow passing arguments when using custom IP address supplier

by Sebastian Łaskawiec (JIRA)

Sebastian Łaskawiec created JGRP-2252: ----------------------------------------- Summary: Allow passing arguments when using custom IP address supplier Key: JGRP-2252 URL: https://issues.jboss.org/browse/JGRP-2252 Project: JGroups Issue Type: Task Affects Versions: 4.0.10 Environment: Kubernetes and OpenShift Reporter: Sebastian Łaskawiec Assignee: Bela Ban When investigating x-site replication for one of more public clouds, we discover that it would be useful to have a Custom IP supplier that allows passing arguments into the supplier instance. An example could look like the following: {{external_addr="custom:org.bla.Blah;args:LoadBalancerServiceName"}} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2252) Allow passing arguments when using custom IP address supplier

by Sebastian Łaskawiec (JIRA)

[ https://issues.jboss.org/browse/JGRP-2252?page=com.atlassian.jira.plugin.... ] Sebastian Łaskawiec reassigned JGRP-2252: ----------------------------------------- Assignee: Sebastian Łaskawiec (was: Bela Ban) > Allow passing arguments when using custom IP address supplier > ------------------------------------------------------------- > > Key: JGRP-2252 > URL: https://issues.jboss.org/browse/JGRP-2252 > Project: JGroups > Issue Type: Task > Affects Versions: 4.0.10 > Environment: Kubernetes and OpenShift > Reporter: Sebastian Łaskawiec > Assignee: Sebastian Łaskawiec > > When investigating x-site replication for one of more public clouds, we discover that it would be useful to have a Custom IP supplier that allows passing arguments into the supplier instance. > An example could look like the following: {{external_addr="custom:org.bla.Blah;args:LoadBalancerServiceName"}} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2321) Fix drg scopes test in TCK

by Fedor Gavrilov (JIRA)

Fedor Gavrilov created DROOLS-2321: -------------------------------------- Summary: Fix drg scopes test in TCK Key: DROOLS-2321 URL: https://issues.jboss.org/browse/DROOLS-2321 Project: Drools Issue Type: Bug Reporter: Fedor Gavrilov Assignee: Fedor Gavrilov Currently 0034-drg-scopes dmn file in TCK is incorrect and does not pass verification -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-3606) Java 9 compiler create a covariant issue for ZipCompletionScanner

by ehsavoie Hugonnet (JIRA)

ehsavoie Hugonnet created WFCORE-3606: ----------------------------------------- Summary: Java 9 compiler create a covariant issue for ZipCompletionScanner Key: WFCORE-3606 URL: https://issues.jboss.org/browse/WFCORE-3606 Project: WildFly Core Issue Type: Bug Components: Deployment Scanner Affects Versions: 4.0.0.Alpha10 Reporter: ehsavoie Hugonnet Assignee: ehsavoie Hugonnet Compiling on Java 9 and running the code in full whith Java 8 will raise the exception : java.lang.NoSuchMethodError: java.nio.ByteBuffer.clear()Ljava/nio/ByteBuffer -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1082) Documentation is missing in elytron-1_0.xsd

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1082?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1082: ---------------------------------- Fix Version/s: 1.3.0.CR1 > Documentation is missing in elytron-1_0.xsd > ------------------------------------------- > > Key: ELY-1082 > URL: https://issues.jboss.org/browse/ELY-1082 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta34 > Reporter: Ondrej Lukas > Assignee: Ilia Vassilev > Priority: Critical > Fix For: 1.3.0.CR1 > > > XSD file {{elytron-1_0.xsd}} [1] includes almost no documentation. If this XSD is included in server distribution (as {{docs/schema/elytron-1_0.xsd}}) then it affects user experience. > [1] https://github.com/wildfly-security/wildfly-elytron/blob/master/src/main/... -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-816) Support for masked passwords in client XML config

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-816?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-816: --------------------------------- Fix Version/s: 1.3.0.CR1 > Support for masked passwords in client XML config > ------------------------------------------------- > > Key: ELY-816 > URL: https://issues.jboss.org/browse/ELY-816 > Project: WildFly Elytron > Issue Type: Task > Reporter: David Lloyd > Priority: Critical > Fix For: 1.3.0.CR1 > > > We need a way to support masked passwords in the auth configuration file, either as: > * A dedicated masked-password-type XML type > * Adding necessary fields to hashed-password-type > * Adding a modular crypt format > Needs to be supported anywhere passwords are allowed. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-787) SASL mechanisms are not IANA registered and specifications are not provided

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-787?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse updated ELY-787: --------------------------------- Fix Version/s: 1.3.0.CR1 > SASL mechanisms are not IANA registered and specifications are not provided > --------------------------------------------------------------------------- > > Key: ELY-787 > URL: https://issues.jboss.org/browse/ELY-787 > Project: WildFly Elytron > Issue Type: Task > Reporter: Josef Cacek > Priority: Critical > Labels: sasl > Fix For: 1.3.0.CR1 > > > Elytron comes with set of SASL mechanisms (as requested by EAP7-530), but they don't fit SASL requirements. > New mechanisms has to be registered by IANA as requested by [SASL RFC 4422 section 5|https://tools.ietf.org/html/rfc4422#section-5] and Java [SaslClientFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] and [SaslServerFactory|http://docs.oracle.com/javase/8/docs/api/javax/security...] contracts. > Current list of mechanisms provided by Elytron, which are not IANA registered: > * DIGEST-SHA > * DIGEST-SHA-256 > * DIGEST-SHA-512 > * JBOSS-LOCAL-USER > *Suggestion for improvement:* > Provide specifications for the new mechanisms and register the names by IANA (see [section 7 in RFC-4422|https://tools.ietf.org/html/rfc4422#section-7]). -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 months

1
0
0 / 0

[JBoss JIRA] (ELY-1177) Using rewrite-user-name-regex element in Elytron client configuration file causes NPE

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-1177?page=com.atlassian.jira.plugin.s... ] Darran Lofthouse updated ELY-1177: ---------------------------------- Fix Version/s: 1.1.0.Beta46 > Using rewrite-user-name-regex element in Elytron client configuration file causes NPE > ------------------------------------------------------------------------------------- > > Key: ELY-1177 > URL: https://issues.jboss.org/browse/ELY-1177 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta42 > Reporter: Ondrej Lukas > Assignee: Ingo Weiss > Priority: Blocker > Fix For: 1.1.0.Beta46 > > > When element {{rewrite-user-name-regex}} is used in Elytron client configuration file then NullPointerException is thrown during authentication. > Stack trace of thrown NPE: > {code} > java.lang.NullPointerException > org.wildfly.security.auth.client.AuthenticationConfiguration.rewriteUser(AuthenticationConfiguration.java:492) > org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$14(ElytronXmlParser.java:605) > org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$27(ElytronXmlParser.java:832) > org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$27(ElytronXmlParser.java:832) > org.wildfly.security.auth.client.ElytronXmlParser.lambda$andThenOp$27(ElytronXmlParser.java:832) > org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationConfigurationType$25(ElytronXmlParser.java:704) > org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseAuthenticationRuleType$7(ElytronXmlParser.java:513) > org.wildfly.security.auth.client.ElytronXmlParser.lambda$parseRulesType$8(ElytronXmlParser.java:537) > org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientType(ElytronXmlParser.java:308) > org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:180) > org.wildfly.security.auth.client.ElytronXmlParser.parseAuthenticationClientConfiguration(ElytronXmlParser.java:141) > com.redhat.eap.qe.elytron.authnctx.WildflyConfigXmlServlet.parseAndCreateAuthenticationClientConfiguration(WildflyConfigXmlServlet.java:120) > com.redhat.eap.qe.elytron.authnctx.WildflyConfigXmlServlet.doGet(WildflyConfigXmlServlet.java:95) > javax.servlet.http.HttpServlet.service(HttpServlet.java:687) > javax.servlet.http.HttpServlet.service(HttpServlet.java:790) > io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85) > io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62) > io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36) > org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131) > io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46) > io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64) > io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60) > io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77) > io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50) > io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68) > io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43) > io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292) > io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81) > io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138) > io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135) > io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48) > io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43) > org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105) > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1704) > io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272) > io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81) > io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104) > io.undertow.server.Connectors.executeRootHandler(Connectors.java:211) > io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:809) > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 2 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 February 2018