June 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1388) Drools Sample.drl broken with Eclipse Neon

by Nicolas Heron (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1388?page=com.atlassian.jira.plugi... ] Nicolas Heron commented on DROOLS-1388: --------------------------------------- Can you close that jira as you found the problem ? Hope the book helps regards > Drools Sample.drl broken with Eclipse Neon > ------------------------------------------ > > Key: DROOLS-1388 > URL: https://issues.jboss.org/browse/DROOLS-1388 > Project: Drools > Issue Type: Bug > Components: eclipse plugin > Affects Versions: 6.5.0.Final > Reporter: Vincenzo D'Amore > Assignee: Robert (Bob) Brodt > > Unable to complete the example presented in the documentation "[Installing Drools Tooling|https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/installing_drools_tooling.html]" > Trying to run DroolsTest.java sample I get the following errors: > {code:java} > java.lang.RuntimeException: Error while creating KieBase[Message [id=1, level=ERROR, path=Sample.drl, line=15, column=0 > text=Rule Compilation error Only a type can be imported. com.sample.DroolsTest.Message resolves to a package > Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package > KnowledgeHelper cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > java.lang.Exception cannot be resolved to a type > org.kie.api.runtime.rule.RuleContext cannot be resolved to a type], Message [id=2, level=ERROR, path=Sample.drl, line=5, column=0 > text=Rule Compilation error Only a type can be imported. com.sample.DroolsTest.Message resolves to a package > Only a type can be imported. org.drools.core.spi.KnowledgeHelper resolves to a package > KnowledgeHelper cannot be resolved to a type > com.sample.DroolsTest.Message cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > org.kie.api.runtime.rule.FactHandle cannot be resolved to a type > java.lang.Exception cannot be resolved to a type > org.kie.api.runtime.rule.RuleContext cannot be resolved to a type > Message.GOODBYE cannot be resolved to a type > org.drools.core.util.bitmask.AllSetBitMask cannot be resolved to a type > com.sample.DroolsTest.Message cannot be resolved to a type]] > at org.drools.compiler.kie.builder.impl.KieContainerImpl.getKieBase(KieContainerImpl.java:450) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:604) > at org.drools.compiler.kie.builder.impl.KieContainerImpl.newKieSession(KieContainerImpl.java:575) > at com.sample.DroolsTest.main(DroolsTest.java:17) > {code} > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (DROOLS-1590) The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final

by Nicolas Heron (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1590?page=com.atlassian.jira.plugi... ] Nicolas Heron commented on DROOLS-1590: --------------------------------------- Hi, In version 6.5 the logging with the callbak is a little different. So the rule logging is done after the rule flow group logging is done. It is annoying but there is no bug. see "The Rule xxx can be fired in agenda " => it means it is done during the agenda of the rule-flow group I will try to update the gitbook Hope the book helps you ! Regards Nicolas > The behavior of rule flow is different in drools 6.4.0 Final and 6.5.0 Final > ---------------------------------------------------------------------------- > > Key: DROOLS-1590 > URL: https://issues.jboss.org/browse/DROOLS-1590 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.5.0.Final > Reporter: GaoShengwei GaoShengwei > Assignee: Mario Fusco > Attachments: BaiduHi_2017-5-31_18-1-18.png, BaiduHi_2017-5-31_18-2-54.png > > > I am using drools 6.5.0 Final. When I run sample code of section "starting a ruleflow from a rule" in documentation (https://nheron.gitbooks.io/droolsonboarding/content/gettingStarted/lesson...), the output sequence is different from the screenshot. > But when I switched to drools version to 6.4.0 Final, the output sequence was extactly same with screenshot. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1215) Elytron sasl-authentication-factory does not offer mechanisms in configured order

by Ondrej Lukas (JIRA)

Ondrej Lukas created ELY-1215: --------------------------------- Summary: Elytron sasl-authentication-factory does not offer mechanisms in configured order Key: ELY-1215 URL: https://issues.jboss.org/browse/ELY-1215 Project: WildFly Elytron Issue Type: Bug Reporter: Ondrej Lukas Assignee: Darran Lofthouse Priority: Critical Attachments: wireshark.png Application server does not offer SASL mechanisms in order defined in Elytron sasl-authentication-factory. See Steps to Reproduce for more details. Screenshot from wireshark 'follow TCP stream' is attached. {{JBOSS-LOCAL-USER}} is offered before {{DIGEST-MD5}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1215) Elytron sasl-authentication-factory does not offer mechanisms in configured order

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-1215?page=com.atlassian.jira.plugin.s... ] Ondrej Lukas updated ELY-1215: ------------------------------ Attachment: wireshark.png > Elytron sasl-authentication-factory does not offer mechanisms in configured order > --------------------------------------------------------------------------------- > > Key: ELY-1215 > URL: https://issues.jboss.org/browse/ELY-1215 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta47 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Attachments: wireshark.png > > > Application server does not offer SASL mechanisms in order defined in Elytron sasl-authentication-factory. See Steps to Reproduce for more details. > Screenshot from wireshark 'follow TCP stream' is attached. {{JBOSS-LOCAL-USER}} is offered before {{DIGEST-MD5}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (ELY-1215) Elytron sasl-authentication-factory does not offer mechanisms in configured order

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/ELY-1215?page=com.atlassian.jira.plugin.s... ] Ondrej Lukas updated ELY-1215: ------------------------------ Affects Version/s: 1.1.0.Beta47 > Elytron sasl-authentication-factory does not offer mechanisms in configured order > --------------------------------------------------------------------------------- > > Key: ELY-1215 > URL: https://issues.jboss.org/browse/ELY-1215 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta47 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Critical > Attachments: wireshark.png > > > Application server does not offer SASL mechanisms in order defined in Elytron sasl-authentication-factory. See Steps to Reproduce for more details. > Screenshot from wireshark 'follow TCP stream' is attached. {{JBOSS-LOCAL-USER}} is offered before {{DIGEST-MD5}}. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING attempts to delete row too late

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.... ] Radoslav Husar commented on WFLY-8488: -------------------------------------- [~meetoblivion] The configuration is wrong. You need to use data-source="..." to establish model dependency. Here is an example configuration: {code:xml} <subsystem xmlns="urn:jboss:domain:jgroups:4.1"> <channels default="ee"> <channel name="ee" stack="tcp"/> </channels> <stacks> <stack name="tcp"> <transport type="TCP" socket-binding="jgroups-tcp"/> <jdbc-protocol type="JDBC_PING" data-source="ExampleDS"/> <protocol type="MERGE3"/> <protocol type="FD_SOCK"/> <protocol type="FD_ALL"/> <protocol type="VERIFY_SUSPECT"/> <protocol type="pbcast.NAKACK2"/> <protocol type="UNICAST3"/> <protocol type="pbcast.STABLE"/> <protocol type="pbcast.GMS"/> <protocol type="MFC"/> <protocol type="FRAG2"/> </stack> </stacks> </subsystem> {code} I cannot reproduce the CLI issue with nightly build not 11.0.0.Alpha1. The expected output is: {noformat} [standalone@localhost:9990 /] /subsystem=jgroups/stack=tcp/protocol=JDBC_PING:add(data-source=ExampleDS,add-index=0 { "outcome" => "success", "response-headers" => { "operation-requires-reload" => true, "process-state" => "reload-required" } } [standalone@localhost:9990 /] :reload { "outcome" => "success", "result" => undefined } {noformat} > Usage of JGroups JDBC_PING attempts to delete row too late > ---------------------------------------------------------- > > Key: WFLY-8488 > URL: https://issues.jboss.org/browse/WFLY-8488 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: John Ament > Assignee: Paul Ferraro > > I was recently working on spinning up a Keycloak cluster. We're deployed to AWS, can't leverage UDP and wanted to have a discovery mechanism that was easy to use, so tried out JDBC_PING. While I got the cluster running, when shutting down a node I would receive an exception on the console when attempting to remove the node from the cluster. It attempts to do a delete on the row in the database after the DataSource has been shut down. > In my setup, I'm pointing JGroups at the same DataSource as Keycloak, I'm not using the properties approach. I can switch to the properties approach, but I would prefer a single pool rather than multiple connections. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2896) Revisit CLI Ctrl-C handling

by Jean-Francois Denise (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2896?page=com.atlassian.jira.plugi... ] Jean-Francois Denise updated WFCORE-2896: ----------------------------------------- Description: Ctrl-C typed in the CLI behaviour: - If auto-connect is enabled (-c option). If prompt occurs for credentials, typing Ctrl-C should exit the CLI process - As soon as we have reached the CLI prompt, any prompting is bound to a command execution (eg: connect, reload, ...), in that case Ctrl-C shouldn't exit the process. It should interrupt the command - Ctrl-C typed for long running command should only interrupt the command. - Ctrl-C typed when pausing long output should only interrupt output pause. was: Ctrl-C typed-in in the CLI behaviour: - If auto-connect is enabled (-c option). If prompt occurs for credentials, typing Ctrl-C should exit the CLI process - As soon as we have reached the CLI prompt, any prompting is bound to a command execution (eg: connect, reload, ...), in that case Ctrl-C shouldn't exit the process. It should interrupt the command - Ctrl-C typed for long running command should only interrupt the command. - Ctrl-C typed when pausing long output should only interrupt output pause. > Revisit CLI Ctrl-C handling > --------------------------- > > Key: WFCORE-2896 > URL: https://issues.jboss.org/browse/WFCORE-2896 > Project: WildFly Core > Issue Type: Enhancement > Components: CLI > Reporter: Jean-Francois Denise > Assignee: Jean-Francois Denise > > Ctrl-C typed in the CLI behaviour: > - If auto-connect is enabled (-c option). If prompt occurs for credentials, typing Ctrl-C should exit the CLI process > - As soon as we have reached the CLI prompt, any prompting is bound to a command execution (eg: connect, reload, ...), in that case Ctrl-C shouldn't exit the process. It should interrupt the command > - Ctrl-C typed for long running command should only interrupt the command. > - Ctrl-C typed when pausing long output should only interrupt output pause. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2896) Revisit CLI Ctrl-C handling

by Jean-Francois Denise (JIRA)

Jean-Francois Denise created WFCORE-2896: -------------------------------------------- Summary: Revisit CLI Ctrl-C handling Key: WFCORE-2896 URL: https://issues.jboss.org/browse/WFCORE-2896 Project: WildFly Core Issue Type: Enhancement Components: CLI Reporter: Jean-Francois Denise Assignee: Jean-Francois Denise Ctrl-C typed-in in the CLI behaviour: - If auto-connect is enabled (-c option). If prompt occurs for credentials, typing Ctrl-C should exit the CLI process - As soon as we have reached the CLI prompt, any prompting is bound to a command execution (eg: connect, reload, ...), in that case Ctrl-C shouldn't exit the process. It should interrupt the command - Ctrl-C typed for long running command should only interrupt the command. - Ctrl-C typed when pausing long output should only interrupt output pause. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFCORE-2732) Elytron - it should also be possible to store OTP algorithm on security realm level

by Yeray Borges (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2732?page=com.atlassian.jira.plugi... ] Yeray Borges reassigned WFCORE-2732: ------------------------------------ Assignee: Yeray Borges (was: Darran Lofthouse) > Elytron - it should also be possible to store OTP algorithm on security realm level > ----------------------------------------------------------------------------------- > > Key: WFCORE-2732 > URL: https://issues.jboss.org/browse/WFCORE-2732 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Josef Cacek > Assignee: Yeray Borges > Priority: Critical > > It should be possible to store OTP algorithm name on security realm level too. > Using of the OTP SASL mechanism requires modifiable realm and currently only ldap-realm integration is finished. > The ldap-realm now requires to store the algorithm name into an LDAP attribute together with the rest of OTP configuration (seed, hash, sequence), but this can be limiting (or space vasting) when the algorithm is the same for all users in the realm. There should be a possibility to configure the OTP algorithm name also on the realm level and share it for users. Make it an alternative for {{ldap-realm.identity-mapping.otp-credential-mapper.algorithm-from}} configuration. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

1
0
0 / 0

[JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING attempts to delete row too late

by Stian Thorgersen (JIRA)

[ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.... ] Stian Thorgersen commented on WFLY-8488: ---------------------------------------- Does this mean JDBC_PING is not working at all on WildFly 11 Alpha? If so should this not be fixed before WildFly 11 Final is released? > Usage of JGroups JDBC_PING attempts to delete row too late > ---------------------------------------------------------- > > Key: WFLY-8488 > URL: https://issues.jboss.org/browse/WFLY-8488 > Project: WildFly > Issue Type: Bug > Components: Clustering > Affects Versions: 10.1.0.Final > Reporter: John Ament > Assignee: Paul Ferraro > > I was recently working on spinning up a Keycloak cluster. We're deployed to AWS, can't leverage UDP and wanted to have a discovery mechanism that was easy to use, so tried out JDBC_PING. While I got the cluster running, when shutting down a node I would receive an exception on the console when attempting to remove the node from the cluster. It attempts to do a delete on the row in the database after the DataSource has been shut down. > In my setup, I'm pointing JGroups at the same DataSource as Keycloak, I'm not using the properties approach. I can switch to the properties approach, but I would prefer a single pool rather than multiple connections. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 1 month

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 June 2017