May 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (ELY-532) Enhance the properties security realm to support reloading.

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-532?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-532. ---------------------------------- Resolution: Out of Date The realm implementation does already support this - it just needs to be exposed in the subsystem. > Enhance the properties security realm to support reloading. > ----------------------------------------------------------- > > Key: ELY-532 > URL: https://issues.jboss.org/browse/ELY-532 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Realms > Reporter: Darran Lofthouse > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta6 > > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-533) Deprecate all legacy code

by Darran Lofthouse (JIRA)

Darran Lofthouse created ELY-533: ------------------------------------ Summary: Deprecate all legacy code Key: ELY-533 URL: https://issues.jboss.org/browse/ELY-533 Project: WildFly Elytron Issue Type: Task Components: API / SPI Reporter: Darran Lofthouse Priority: Critical Fix For: 1.1.0.CR1 In a few places we have legacy behaviour within the project to assist migration from previous JBoss / WildFly releases - this code should be flagged as deprecated to encourage minimal use. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1178) NPE removing a not initialized rule in stream mode

by Anton Giertli (JIRA)

Anton Giertli created DROOLS-1178: ------------------------------------- Summary: NPE removing a not initialized rule in stream mode Key: DROOLS-1178 URL: https://issues.jboss.org/browse/DROOLS-1178 Project: Drools Issue Type: Bug Reporter: Anton Giertli Assignee: Mario Fusco In Stream mode a path memory can have a RuleAgendaItem even if the path has been never totally linked and then it misses the first segment memory. When an incremental compilation tries to remove the rule for that path the following exception is thrown: {code} java.lang.NullPointerException at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:70) at org.drools.core.phreak.AddRemoveRule.flushStagedTuples(AddRemoveRule.java:547) at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:178) at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:185) at org.drools.core.reteoo.ReteooBuilder.removeRules(ReteooBuilder.java:170) at org.drools.core.impl.KnowledgeBaseImpl.internalRemoveRule(KnowledgeBaseImpl.java:1685) at org.drools.core.impl.KnowledgeBaseImpl.access$200(KnowledgeBaseImpl.java:117) at org.drools.core.impl.KnowledgeBaseImpl$3.run(KnowledgeBaseImpl.java:1658) at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:720) at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1655) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.preProcessRules(KnowledgeBuilderImpl.java:1155) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:1106) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:989) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildRules(CompositeKnowledgeBuilderImpl.java:260) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:121) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:105) at org.drools.compiler.kie.builder.impl.KieContainerImpl.rebuildAll(KieContainerImpl.java:386) at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateKBase(KieContainerImpl.java:241) at org.drools.compiler.kie.builder.impl.KieContainerImpl.access$000(KieContainerImpl.java:80) at org.drools.compiler.kie.builder.impl.KieContainerImpl$1.run(KieContainerImpl.java:186) at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:720) at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:183) at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:130) at org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest.testRemoveRuleWithNonInitializedPath(IncrementalCompilationTest.java:2832) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1177) NPE removing a not initialized rule in stream mode

by Mario Fusco (JIRA)

Mario Fusco created DROOLS-1177: ----------------------------------- Summary: NPE removing a not initialized rule in stream mode Key: DROOLS-1177 URL: https://issues.jboss.org/browse/DROOLS-1177 Project: Drools Issue Type: Bug Reporter: Mario Fusco Assignee: Mario Fusco In Stream mode a path memory can have a RuleAgendaItem even if the path has been never totally linked and then it misses the first segment memory. When an incremental compilation tries to remove the rule for that path the following exception is thrown: {code} java.lang.NullPointerException at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:70) at org.drools.core.phreak.AddRemoveRule.flushStagedTuples(AddRemoveRule.java:547) at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:178) at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:185) at org.drools.core.reteoo.ReteooBuilder.removeRules(ReteooBuilder.java:170) at org.drools.core.impl.KnowledgeBaseImpl.internalRemoveRule(KnowledgeBaseImpl.java:1685) at org.drools.core.impl.KnowledgeBaseImpl.access$200(KnowledgeBaseImpl.java:117) at org.drools.core.impl.KnowledgeBaseImpl$3.run(KnowledgeBaseImpl.java:1658) at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:720) at org.drools.core.impl.KnowledgeBaseImpl.removeRule(KnowledgeBaseImpl.java:1655) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.preProcessRules(KnowledgeBuilderImpl.java:1155) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRules(KnowledgeBuilderImpl.java:1106) at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileAllRules(KnowledgeBuilderImpl.java:989) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildRules(CompositeKnowledgeBuilderImpl.java:260) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:121) at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:105) at org.drools.compiler.kie.builder.impl.KieContainerImpl.rebuildAll(KieContainerImpl.java:386) at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateKBase(KieContainerImpl.java:241) at org.drools.compiler.kie.builder.impl.KieContainerImpl.access$000(KieContainerImpl.java:80) at org.drools.compiler.kie.builder.impl.KieContainerImpl$1.run(KieContainerImpl.java:186) at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:720) at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:183) at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:130) at org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest.testRemoveRuleWithNonInitializedPath(IncrementalCompilationTest.java:2832) {code} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-1869) TP.registerProbeHandler not thread safe

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/JGRP-1869?page=com.atlassian.jira.plugin.... ] RH Bugzilla Integration commented on JGRP-1869: ----------------------------------------------- dereed(a)redhat.com changed the Status of [bug 1336088|https://bugzilla.redhat.com/show_bug.cgi?id=1336088] from NEW to MODIFIED > TP.registerProbeHandler not thread safe > --------------------------------------- > > Key: JGRP-1869 > URL: https://issues.jboss.org/browse/JGRP-1869 > Project: JGroups > Issue Type: Bug > Affects Versions: 3.2.12 > Reporter: Dennis Reed > Assignee: Bela Ban > Priority: Minor > Fix For: 3.5 > > > TP.registerProbeHandlers is not thread safe since it modifies preregistered_probe_handlers outside of any synchronization. > If a thread calls this method while another thread is inside startDiagnostics (which can happen easily with a shared transport), it can cause a NullPointerException when startDiagnostics is looping through preregistered_probe_handlers. > Access to preregistered_probe_handlers should be synchronized. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6611) undertow wrong log data emitted

by Darryl Miles (JIRA)

[ https://issues.jboss.org/browse/WFLY-6611?page=com.atlassian.jira.plugin.... ] Darryl Miles commented on WFLY-6611: ------------------------------------ https://github.com/wildfly/wildfly/blob/aaaeb2a13667353db2b6955b9bcdba434... Maybe need to get the real socketAddress not the binding configuration here ? Since the binding configuration is setup as per default: <socket-binding name="http" port="${jboss.http.port:8080}"/> I do not provide any property -Djboss.http.port only -Djboss.socket.binding.port-offset=42 > undertow wrong log data emitted > ------------------------------- > > Key: WFLY-6611 > URL: https://issues.jboss.org/browse/WFLY-6611 > Project: WildFly > Issue Type: Bug > Components: Web (Undertow) > Affects Versions: 10.0.0.Final > Environment: Windows JDK8 > Reporter: Darryl Miles > Assignee: Stuart Douglas > Priority: Minor > > 20:05:49,621 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.15.Final starting > 20:05:49,627 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.3.15.Final starting > ... > 20:05:50,075 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8122 > ... > 20:06:10,498 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTP listener default suspending > 20:06:10,499 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080 > 20:06:10,500 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.3.15.Final stopping > This is running an arquallian managed instance. > Notice on shutdown it emits port 8080 when there is nothing bound on that, it really is on port 8122 as shown in "netstat -p tcp -a -n | grep LISTEN" output. > So I guess there is a bug somewhere in the data it is using. > I am using -Djboss.socket.binding.port-offset=42 with a stock config for standalone-full.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6611) undertow wrong log data emitted

by Darryl Miles (JIRA)

Darryl Miles created WFLY-6611: ---------------------------------- Summary: undertow wrong log data emitted Key: WFLY-6611 URL: https://issues.jboss.org/browse/WFLY-6611 Project: WildFly Issue Type: Bug Components: Web (Undertow) Affects Versions: 10.0.0.Final Environment: Windows JDK8 Reporter: Darryl Miles Assignee: Stuart Douglas Priority: Minor 20:05:49,621 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0003: Undertow 1.3.15.Final starting 20:05:49,627 INFO [org.wildfly.extension.undertow] (ServerService Thread Pool -- 61) WFLYUT0003: Undertow 1.3.15.Final starting ... 20:05:50,075 INFO [org.wildfly.extension.undertow] (MSC service thread 1-5) WFLYUT0006: Undertow HTTP listener default listening on 127.0.0.1:8122 ... 20:06:10,498 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0008: Undertow HTTP listener default suspending 20:06:10,499 INFO [org.wildfly.extension.undertow] (MSC service thread 1-6) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080 20:06:10,500 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.3.15.Final stopping This is running an arquallian managed instance. Notice on shutdown it emits port 8080 when there is nothing bound on that, it really is on port 8122 as shown in "netstat -p tcp -a -n | grep LISTEN" output. So I guess there is a bug somewhere in the data it is using. I am using -Djboss.socket.binding.port-offset=42 with a stock config for standalone-full.xml -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1554) Building an attribute based on another attribute does not copy CapabilityReferenceRecorder

by Paul Ferraro (JIRA)

Paul Ferraro created WFCORE-1554: ------------------------------------ Summary: Building an attribute based on another attribute does not copy CapabilityReferenceRecorder Key: WFCORE-1554 URL: https://issues.jboss.org/browse/WFCORE-1554 Project: WildFly Core Issue Type: Bug Components: Domain Management Affects Versions: 2.2.0.CR2 Reporter: Paul Ferraro Assignee: Brian Stansberry AbstractAttributeDefinitionBuilder(final AttributeDefinition basis) seems to copy every field from the basis attribute, except the CapabilityReferenceRecorder. Looks like an oversight. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2063) JDBC_PING: allow supplying dataSource object directly (e.g. via after_creation_hook)

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2063?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2063: --------------------------- Fix Version/s: 3.6.10 4.0 > JDBC_PING: allow supplying dataSource object directly (e.g. via after_creation_hook) > ------------------------------------------------------------------------------------ > > Key: JGRP-2063 > URL: https://issues.jboss.org/browse/JGRP-2063 > Project: JGroups > Issue Type: Feature Request > Affects Versions: 3.6.9 > Reporter: Radoslav Husar > Assignee: Radoslav Husar > Fix For: 3.6.10, 4.0 > > > See WFLY-6599. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2062) TYPE_STRING does not handle unicode

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2062?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2062: --------------------------- Fix Version/s: 4.0 > TYPE_STRING does not handle unicode > ----------------------------------- > > Key: JGRP-2062 > URL: https://issues.jboss.org/browse/JGRP-2062 > Project: JGroups > Issue Type: Bug > Reporter: Cody Ebberson > Assignee: Bela Ban > Fix For: 4.0 > > > In several places throughout the org.jgroups.util.Util class, it is assumed that Strings are one byte per character. > For example, see objectToByteBuffer lines 561-567: > https://github.com/belaban/JGroups/blob/master/src/org/jgroups/util/Util.... > {{case TYPE_STRING: > String str=(String)obj; > int len=str.length(); > ByteBuffer retval=ByteBuffer.allocate(Global.BYTE_SIZE + len).put(TYPE_STRING); > for(int i=0; i < len; i++) > retval.put((byte)str.charAt(i)); > return retval.array();}} > This code will incorrectly encode any String with non ASCII encoding. > There are several options to fix. You could use str.getBytes(StandardCharsets.UTF_8) to get a proper byte encoding, or you could use the existing TYPE_SERIALIZABLE code path. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 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 May 2016