[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
[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
[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
[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
[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
[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