December 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-2170) Unhelful error message: "Unknown property" should not only mention the name of the property, but also the class on which it is expecting it (and the DRL line causing it)

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-2170?page=com.atlassian.jira.plugi... ] Geoffrey De Smet commented on DROOLS-2170: ------------------------------------------ Separate issue: I am especially a bit worried here because this happens when "typeDeclaration.isPropertyReactive()" == true, but optaplanner explicitely disables property reactive (for good reasons). > Unhelful error message: "Unknown property" should not only mention the name of the property, but also the class on which it is expecting it (and the DRL line causing it) > ------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-2170 > URL: https://issues.jboss.org/browse/DROOLS-2170 > Project: Drools > Issue Type: Enhancement > Components: core engine > Affects Versions: 7.5.0.Final > Reporter: Geoffrey De Smet > Assignee: Mario Fusco > > I have no idea which class file it's expecting the room property on in this error message. > I 'll need to look for a needle in a haystack: > {code} > Caused by: java.lang.RuntimeException: Unknown property: room > at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105) > at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97) > at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68) > at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545) > at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210) > at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197) > at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78) > at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37) > at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27) > at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124) > at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99) > at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74) > at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87) > at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167) > at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329) > at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324) > at javax.swing.SwingWorker$1.call(SwingWorker.java:295) > at java.util.concurrent.FutureTask.run(FutureTask.java:266) > at javax.swing.SwingWorker.run(SwingWorker.java:334) > at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) > at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) > at java.lang.Thread.run(Thread.java:745) > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-2170) Unhelful error message: "Unknown property" should not only mention the name of the property, but also the class on which it is expecting it (and the DRL line causing it)

by Geoffrey De Smet (JIRA)

Geoffrey De Smet created DROOLS-2170: ---------------------------------------- Summary: Unhelful error message: "Unknown property" should not only mention the name of the property, but also the class on which it is expecting it (and the DRL line causing it) Key: DROOLS-2170 URL: https://issues.jboss.org/browse/DROOLS-2170 Project: Drools Issue Type: Enhancement Components: core engine Affects Versions: 7.5.0.Final Reporter: Geoffrey De Smet Assignee: Mario Fusco I have no idea which class file it's expecting the room property on in this error message. I 'll need to look for a needle in a haystack: {code} Caused by: java.lang.RuntimeException: Unknown property: room at org.drools.core.reteoo.PropertySpecificUtil.setPropertyOnMask(PropertySpecificUtil.java:105) at org.drools.core.reteoo.PropertySpecificUtil.calculatePatternMask(PropertySpecificUtil.java:97) at org.drools.core.reteoo.PropertySpecificUtil.calculatePositiveMask(PropertySpecificUtil.java:68) at org.drools.core.common.NamedEntryPoint.update(NamedEntryPoint.java:327) at org.drools.core.impl.StatefulKnowledgeSessionImpl.update(StatefulKnowledgeSessionImpl.java:1545) at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.update(DroolsScoreDirector.java:210) at org.optaplanner.core.impl.score.director.drools.DroolsScoreDirector.afterVariableChanged(DroolsScoreDirector.java:197) at org.optaplanner.core.impl.heuristic.selector.move.generic.ChangeMove.doMoveOnGenuineVariables(ChangeMove.java:78) at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:37) at org.optaplanner.core.impl.heuristic.move.AbstractMove.doMove(AbstractMove.java:27) at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.doMove(ConstructionHeuristicDecider.java:124) at org.optaplanner.core.impl.constructionheuristic.decider.ConstructionHeuristicDecider.decideNextStep(ConstructionHeuristicDecider.java:99) at org.optaplanner.core.impl.constructionheuristic.DefaultConstructionHeuristicPhase.solve(DefaultConstructionHeuristicPhase.java:74) at org.optaplanner.core.impl.solver.AbstractSolver.runPhases(AbstractSolver.java:87) at org.optaplanner.core.impl.solver.DefaultSolver.solve(DefaultSolver.java:167) at org.optaplanner.examples.common.business.SolutionBusiness.solve(SolutionBusiness.java:329) at org.optaplanner.examples.common.swingui.SolverAndPersistenceFrame$SolveWorker.doInBackground(SolverAndPersistenceFrame.java:324) at javax.swing.SwingWorker$1.call(SwingWorker.java:295) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at javax.swing.SwingWorker.run(SwingWorker.java:334) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-609) Unguarded read in ElytronPolicyConfiguration

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.sy... ] Jan Kalina edited comment on ELY-609 at 12/8/17 10:18 AM: ---------------------------------------------------------- Not sure how do you mean "more than one lock", as all in ElytronPolicyConfiguration is synchronized against "this", -but the problem I see is, even when I add synchonized block around getters, the obtained Permissions object will not be immutable - user will be able to modify Permissions collection without any sychronization...- (edit, just looking, the Permissions object is synchonized) was (Author: honza889): Not sure how do you mean "more than one lock", as all in ElytronPolicyConfiguration is synchronized against "this", but the problem I see is, even when I add synchonized block around getters, the obtained Permissions object will not be immutable - user will be able to modify Permissions collection without any sychronization... > Unguarded read in ElytronPolicyConfiguration > -------------------------------------------- > > Key: ELY-609 > URL: https://issues.jboss.org/browse/ELY-609 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Labels: static_analysis > Fix For: 1.2.0.Beta12 > > > Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-609) Unguarded read in ElytronPolicyConfiguration

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.sy... ] Jan Kalina commented on ELY-609: -------------------------------- Not sure how do you mean "more than one lock", as all in ElytronPolicyConfiguration is synchronized against "this", but the problem I see is, even when I add synchonized block around getters, the obtained Permissions object will not be immutable - user will be able to modify Permissions collection without any sychronization... > Unguarded read in ElytronPolicyConfiguration > -------------------------------------------- > > Key: ELY-609 > URL: https://issues.jboss.org/browse/ELY-609 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Labels: static_analysis > Fix For: 1.2.0.Beta12 > > > Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-849) Rename setMechanismProperties to setSaslMechanismProperties

by Martin Mazanek (JIRA)

[ https://issues.jboss.org/browse/ELY-849?page=com.atlassian.jira.plugin.sy... ] Martin Mazanek reassigned ELY-849: ---------------------------------- Assignee: Martin Mazanek > Rename setMechanismProperties to setSaslMechanismProperties > ----------------------------------------------------------- > > Key: ELY-849 > URL: https://issues.jboss.org/browse/ELY-849 > Project: WildFly Elytron > Issue Type: Enhancement > Components: Authentication Client > Reporter: Darran Lofthouse > Assignee: Martin Mazanek > Fix For: 1.2.0.Beta12 > > > If we later add HTTP mechanisms we have no way to differentiate between HTTP and SASL mechanism properties. > We could probably share properties and rely on protocol matching in the MatchRule but as a single AuthenticationConfiguration will support both HTTP and SASL I think independent properties will be required. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-609) Unguarded read in ElytronPolicyConfiguration

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-609?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-609: ------------------------------ Assignee: Jan Kalina > Unguarded read in ElytronPolicyConfiguration > -------------------------------------------- > > Key: ELY-609 > URL: https://issues.jboss.org/browse/ELY-609 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta7 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Labels: static_analysis > Fix For: 1.2.0.Beta12 > > > Access to fields {{uncheckedPermissions}}, {{excludedPermissions}} and {{rolePermissions}} in {{org.wildfly.security.authz.jacc.ElytronPolicyConfiguration}} is holded by lock. However lock is not used in their getter methods. Getters should be also handled by locks to avoid unguarded read of those fields. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (ELY-728) The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map.

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-728?page=com.atlassian.jira.plugin.sy... ] Jan Kalina updated ELY-728: --------------------------- Affects Version/s: 1.2.0.Beta10 > The map backing SimpleMapBackedSecurityRealm should be an identity map not a password map. > ------------------------------------------------------------------------------------------ > > Key: ELY-728 > URL: https://issues.jboss.org/browse/ELY-728 > Project: WildFly Elytron > Issue Type: Task > Components: API / SPI, Realms > Affects Versions: 1.2.0.Beta10 > Reporter: Darran Lofthouse > Assignee: Jan Kalina > Priority: Critical > Fix For: 1.2.0.Beta12 > > > This realm is useful in cases where we need an identity to exist where the mechanism has performed validation without requiring access to credentials. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2240) Log a warning if no binding port in TCP is provided

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2240?page=com.atlassian.jira.plugin.... ] Bela Ban closed JGRP-2240. -------------------------- Resolution: Rejected I checked and this sanity check is already in the code (but I forgot): {noformat} java.lang.IllegalArgumentException: bind_port cannot be set to 0, as no dynamic discovery protocol (e.g. MPING or TCPGOSSIP) has been detected. at org.jgroups.protocols.BasicTCP.init(BasicTCP.java:87) at org.jgroups.stack.ProtocolStack.initProtocolStack(ProtocolStack.java:837) at org.jgroups.stack.ProtocolStack.setup(ProtocolStack.java:476) at org.jgroups.JChannel.init(JChannel.java:992) at org.jgroups.JChannel.<init>(JChannel.java:148) at org.jgroups.JChannel.<init>(JChannel.java:130) at org.jgroups.demos.Draw.<init>(Draw.java:57) at org.jgroups.demos.Draw.main(Draw.java:156) {noformat} > Log a warning if no binding port in TCP is provided > --------------------------------------------------- > > Key: JGRP-2240 > URL: https://issues.jboss.org/browse/JGRP-2240 > Project: JGroups > Issue Type: Enhancement > Affects Versions: 4.0.9 > Reporter: andrea tarocchi > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0.10 > > > If a bind port is not defined and you don't bind (for some reason) to the default one, log a warning. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2241) Bundler using direct memory as buffer

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2241?page=com.atlassian.jira.plugin.... ] Bela Ban updated JGRP-2241: --------------------------- Description: The current bundler impls use a byte[] array in an output stream as buffer into which messages are written. If we instead used a direct byte buffer (off-heap), the JDK would not create an additional copy but simply pass the contents to the corresponding socket. This would reduce the memory allocation rate. Direct buffers can also be used on the receiver side, investigate. was: The current bundler impls use a byte[] array in an output stream as buffer into which messages are written. If we instead used a direct byte buffer (off-heap), the JDK would not create an additional copy but simply pass the contents to the corresponding socket. This would reduce the memory allocation rate. > Bundler using direct memory as buffer > ------------------------------------- > > Key: JGRP-2241 > URL: https://issues.jboss.org/browse/JGRP-2241 > Project: JGroups > Issue Type: Feature Request > Reporter: Bela Ban > Assignee: Bela Ban > Fix For: 4.0.10 > > > The current bundler impls use a byte[] array in an output stream as buffer into which messages are written. > If we instead used a direct byte buffer (off-heap), the JDK would not create an additional copy but simply pass the contents to the corresponding socket. This would reduce the memory allocation rate. > Direct buffers can also be used on the receiver side, investigate. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2241) Bundler using direct memory as buffer

by Bela Ban (JIRA)

Bela Ban created JGRP-2241: ------------------------------ Summary: Bundler using direct memory as buffer Key: JGRP-2241 URL: https://issues.jboss.org/browse/JGRP-2241 Project: JGroups Issue Type: Feature Request Reporter: Bela Ban Assignee: Bela Ban Fix For: 4.0.10 The current bundler impls use a byte[] array in an output stream as buffer into which messages are written. If we instead used a direct byte buffer (off-heap), the JDK would not create an additional copy but simply pass the contents to the corresponding socket. This would reduce the memory allocation rate. -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years, 7 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 December 2017