April 2017 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1506) drools-docs improvements: file structure, dead images, etc

by Geoffrey De Smet (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1506?page=com.atlassian.jira.plugi... ] Geoffrey De Smet reassigned DROOLS-1506: ---------------------------------------- Assignee: (was: Edson Tirelli) > drools-docs improvements: file structure, dead images, etc > ---------------------------------------------------------- > > Key: DROOLS-1506 > URL: https://issues.jboss.org/browse/DROOLS-1506 > Project: Drools > Issue Type: Task > Components: docs > Affects Versions: 7.0.0.Beta8 > Reporter: Geoffrey De Smet > > See latest docs here from jenkins: > https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-docs/lastSucc... > - 4 mentions of KnowledgeSession should be replaced by KieSession. Same for KnowledgeBase, etc. > Do a find in single_html output for regex "Knowledge\w". > - Chapter 3 Compatibility matrix is 4 lines, should be a nested section in another chapter > - Dead images. > - Dead sections? > - Images in differently named directory than their section adoc. > For example: images in directory GettingInvolved in shared-kie-docs > - Release notes should not reuse images from rest of docs, > because those images get updated over time > and release notes should not change retroactively automatically. > Copy-paste those images in the release notes directories to reuse them. > - Every section header needs an anchorId. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-1055) Missing privileged section in Elytron FileSystemRealm

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-1055?page=com.atlassian.jira.plugin.s... ] Jan Kalina reassigned ELY-1055: ------------------------------- Assignee: Jan Kalina (was: Darran Lofthouse) > Missing privileged section in Elytron FileSystemRealm > ----------------------------------------------------- > > Key: ELY-1055 > URL: https://issues.jboss.org/browse/ELY-1055 > Project: WildFly Elytron > Issue Type: Bug > Reporter: Josef Cacek > Assignee: Jan Kalina > Priority: Blocker > > Calling Elytron {{SecurityDomain.authenticate()}} method results in {{AccessControlException}} (missing {{FilePermission}}) when Elytron {{FileSystemSecurityRealm}} is used for the domain and server runs with security manager enabled. > This file permission check must not be propagated to the calling user. The only permissions required for him/her should be the {{ElytronPermission}} ones. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8427) Unignore XADatasourceCapacityPoliciesTestCase

by Martin Simka (JIRA)

[ https://issues.jboss.org/browse/WFLY-8427?page=com.atlassian.jira.plugin.... ] Martin Simka reassigned WFLY-8427: ---------------------------------- Assignee: Martin Simka (was: Flavia Rainone) > Unignore XADatasourceCapacityPoliciesTestCase > --------------------------------------------- > > Key: WFLY-8427 > URL: https://issues.jboss.org/browse/WFLY-8427 > Project: WildFly > Issue Type: Bug > Reporter: Kabir Khan > Assignee: Martin Simka > > I am going to ignore this test, until the ironjacamar upgrade which fixes the following (from [~simkam]'s mail) > {quote} > I might be completely wrong, but it seems to me like race condition between PoolFiller and CapacityFiller in IronJacamar. > I think what happens is: > - Both add connections to pool in different threads > - PoolFiller creates connection, then checks pools size and because pool has already certain size, it doesn't add connection and instead it destroys connection which increases destroyedCount > see https://github.com/ironjacamar/ironjacamar/blob/1.4/core/src/main/java/or... > @Stefano, @Flavia could you please take a look? > I'm attaching logs with enabled TRACE on org.jboss.jca and jdbc.spy. > This might have been hidden until https://issues.jboss.org/browse/JBJCA-1330 was fixed in DR11. > {quote} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (ELY-987) Confusion in method with(AuthenticationContext other) in AuthenticationContext

by Jan Kalina (JIRA)

[ https://issues.jboss.org/browse/ELY-987?page=com.atlassian.jira.plugin.sy... ] Jan Kalina reassigned ELY-987: ------------------------------ Assignee: Jan Kalina (was: David Lloyd) > Confusion in method with(AuthenticationContext other) in AuthenticationContext > ------------------------------------------------------------------------------ > > Key: ELY-987 > URL: https://issues.jboss.org/browse/ELY-987 > Project: WildFly Elytron > Issue Type: Bug > Affects Versions: 1.1.0.Beta28 > Reporter: Ondrej Lukas > Assignee: Jan Kalina > Priority: Critical > > org.wildfly.security.auth.client.AuthenticationContext includes method {{AuthenticationContext with(AuthenticationContext other)}} which creates new AuthenticationContext which includes rules and configuration and SSL context of given AuthenticationContext other. > However, in case when {{with}} method is used with index and another AuthenticationContext, then it includes only rules and configuration (SSL context is not used). There is also method {{withSsl}} which includes rules and SSL context, but no configuration. > I see three problems here: > * there is different behavior between {{with(AuthenticationContext other)}} and {{with(int idx, AuthenticationContext other)}} - first includes also SSL context > * javadoc for with(AuthenticationContext other) does not describe that SSL context from given {{AuthenticationContext other}} is also used. > * there is not able to include both configuration and SSL context into any AuthenticationContext on some position based on index > I report this as critical because it is part of public API - it should stay backward compatible once it will be released. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1130) Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES

by Juan Carlos Garcia (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1130?page=com.atlassian.jira.plugi... ] Juan Carlos Garcia commented on DROOLS-1130: -------------------------------------------- [~littlemustard] one way we achieve that is to install a *DefaultAgendaEventListener* and then on the *afterMatchFired* call fireAllRules on the session when we detect there are still timerDeclarations at the *RuleTerminalNode*. Check the following code (hope this help): {code} _session.addEventListener(new DefaultAgendaEventListener() { @Override public void afterMatchFired(final AfterMatchFiredEvent event) { final RuleTerminalNodeLeftTuple match = (RuleTerminalNodeLeftTuple) event.getMatch(); final RuleTerminalNode sink = (RuleTerminalNode) match.getSink(); if (sink.getTimerDeclarations() != null && sink.getTimerDeclarations().length > 0) { threadPool.submit(new Runnable() { @Override public void run() { //no need to synchronize the session as of 6.3.0 is completely thread safe _session.fireAllRules(); } }); } } }); {code} > Using fireAllRules, Timed rules does not cascade rule execution after modifying a fact, event when Session conf is set to TimedRuleExectionOption.YES > ----------------------------------------------------------------------------------------------------------------------------------------------------- > > Key: DROOLS-1130 > URL: https://issues.jboss.org/browse/DROOLS-1130 > Project: Drools > Issue Type: Bug > Affects Versions: 6.3.0.Final > Reporter: Juan Carlos Garcia > Assignee: Mario Fusco > Attachments: timer-rule-bug.zip > > > I have a DRL file with 2 rules and the first rule has a timer of 3s, after this rule gets fired and a fact is modified, i expect a second rule to get activate and trigger but is not happening. Even though the documentation explicitly said in the 2.9.2 section of: > http://docs.jboss.org/drools/release/6.3.0.Final/drools-docs/html/ch02.ht... > _When the rule engine runs in passive mode (i.e.: using fireAllRules) by default it doesn't fire consequences of timed rules unless fireAllRules isn't invoked again. Now it is possible to change this default behavior by configuring the KieSession with a *TimedRuleExectionOption*_ > Please advise if i have misunderstood the expected behavior, attached is a demo project enclosing the mentioned rules and a testcase. > *DRL:* > {code} > import java.util.logging.Logger > import bug.timedrules.Table > rule "table with 1 player" > timer( int: 3s) > no-loop true > when > $table : Table( getCounter() == 1) > then > Logger.getLogger("timer.drl").info("triggered - counter is 1"); > modify($table){ > setCounter(2) > } > end > rule "Table upgrade to 2 player" > no-loop true > when > $table : Table( getCounter() == 2) > then > Logger.getLogger("timer.drl").info("triggered - counter is 2"); > modify($table){ > setCounter(3) > } > end > {code} > *java code:* > {code} > @Test > public void executeNewRuleAfterTimedRuleExecution() throws Exception { > KieBaseConfiguration config = KnowledgeBaseFactory.newKnowledgeBaseConfiguration(); > KieSessionConfiguration ksconf = KieServices.Factory.get().newKieSessionConfiguration(); > ksconf.setOption(TimedRuleExectionOption.YES); > config.setOption(EventProcessingOption.STREAM); > KnowledgeBase kbase = KnowledgeBaseFactory.newKnowledgeBase(config); > final KnowledgeBuilder kbuilder = KnowledgeBuilderFactory.newKnowledgeBuilder(); > kbuilder.add(ResourceFactory.newClassPathResource("bug/timer/timer.drl", BugTest.class), ResourceType.DRL); > if (kbuilder.hasErrors()) { > throw new IllegalStateException(kbuilder.getErrors().toString()); > } > kbase = KnowledgeBaseFactory.newKnowledgeBase(config); > kbase.addKnowledgePackages(kbuilder.getKnowledgePackages()); > final StatefulKnowledgeSession statefulKnowledgeSession = kbase.newStatefulKnowledgeSession(ksconf, null); > Table table = new Table(1234, 1); > statefulKnowledgeSession.insert(table); > statefulKnowledgeSession.fireAllRules(); > Thread.sleep(TimeUnit.SECONDS.toMillis(5)); > statefulKnowledgeSession.dispose(); > Assert.assertThat(table.getCounter(), CoreMatchers.is(3)); > } > {code} -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1515) Unable to install feature droolsjbpm-hibernate in Fuse

by Lubomir Terifaj (JIRA)

Lubomir Terifaj created DROOLS-1515: --------------------------------------- Summary: Unable to install feature droolsjbpm-hibernate in Fuse Key: DROOLS-1515 URL: https://issues.jboss.org/browse/DROOLS-1515 Project: Drools Issue Type: Bug Components: integration Affects Versions: 7.0.0.Beta8 Environment: JBOSS Fuse 6.2.1 JBOSS Fuse 6.3.0 Reporter: Lubomir Terifaj Assignee: Mario Fusco Installation of droolsjbpm-hibernate fails with error: Error executing command: Could not start bundle wrap:mvn:org.hibernate/hibernate-entitymanager/5.1.4.Final$overwrite=merge&DynamicImport-Package=* in feature(s) droolsjbpm-hibernate-5.1.4.Final: Unresolved constraint in bundle org.hibernate.entitymanager [309]: Unable to resolve 309.0: missing requirement [309.0] osgi.wiring.package; (&(osgi.wiring.package=javax.persistence)(version>=2.1.0)) -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-2615) Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration

by Ondrej Lukas (JIRA)

[ https://issues.jboss.org/browse/WFCORE-2615?page=com.atlassian.jira.plugi... ] Ondrej Lukas commented on WFCORE-2615: -------------------------------------- [~dmlloyd] Thanks for response. We see security risk here since attributes {{allow-sasl-mechanisms}} and {{allow-all-mechanisms}} can cause that user infers that all mechanisms are forbidden as default - based on principle of least privilege. We have some questions based on your feedback: * How is the "list of all known mechanisms" created? It is the list of mechanisms provided by server? Or it is hard coded somewhere in client? * We understand that allowing some mechanisms which are not supported by configuration can be useful for standalone clients (e.g. CLI can ask user for password), but is there any scenario when it is useful for authentication-configuration in Elytron subsystem? * Is there any way how to enforce usage of single concrete SASL mechanism? * What should be an order of tried SASL mechanism? Is it defined somewhere or is it random? Should SASL mechanisms from {{allow-sasl-mechanisms}} have higher priority then other known mechanisms? > Attribute allow-sasl-mechanisms is ignored in Elytron Authentication Configuration > ---------------------------------------------------------------------------------- > > Key: WFCORE-2615 > URL: https://issues.jboss.org/browse/WFCORE-2615 > Project: WildFly Core > Issue Type: Bug > Components: Security > Affects Versions: 3.0.0.Beta10 > Reporter: Ondrej Lukas > Assignee: Darran Lofthouse > Priority: Blocker > Attachments: dep.war, wireshark.pcapng > > > In case when attribute allow-sasl-mechanisms from Elytron Authentication Configuration includes some SASL mechanisms then this attribute (and mechanisms configured there) is not taken into account during choosing SASL mechanism. It means that client tries to use all of mechanisms allowed on server side even if client does not allow them. e.g. in case when server side allowed DIGEST-MD5 and JBOSS-LOCAL-USER and client side allows PLAIN, then it tries to use DIGEST-MD5 and JBOSS-LOCAL-USER mechanisms. > See log from wireshark in attachments. This is log for server configured through "Steps to Reproduce". > This happens also for using allow-sasl-mechanisms from wildfly config and also for programatically configured client. > We request blocker since it allows to use some SASL mechanisms even if they are not allowed on client side. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8519) Create HA Singleton Deployments Quickstart

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8519?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-8519: --------------------------------- Summary: Create HA Singleton Deployments Quickstart (was: Create HA Singleton Deployments quickstart) > Create HA Singleton Deployments Quickstart > ------------------------------------------ > > Key: WFLY-8519 > URL: https://issues.jboss.org/browse/WFLY-8519 > Project: WildFly > Issue Type: Task > Components: Clustering, Quickstarts > Reporter: Radoslav Husar > Assignee: Radoslav Husar > > This quickstart would be one of two quickstarts replacing the obsolete cluster-ha-singleton quickstart. -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8523) Create Clustering Command Dispatcher Quickstart

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8523?page=com.atlassian.jira.plugin.... ] Radoslav Husar reassigned WFLY-8523: ------------------------------------ Assignee: Radoslav Husar (was: Jason Greene) > Create Clustering Command Dispatcher Quickstart > ----------------------------------------------- > > Key: WFLY-8523 > URL: https://issues.jboss.org/browse/WFLY-8523 > Project: WildFly > Issue Type: Task > Reporter: Radoslav Husar > Assignee: Radoslav Husar > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-8523) Create Clustering Command Dispatcher Quickstart

by Radoslav Husar (JIRA)

[ https://issues.jboss.org/browse/WFLY-8523?page=com.atlassian.jira.plugin.... ] Radoslav Husar updated WFLY-8523: --------------------------------- Component/s: Clustering Quickstarts > Create Clustering Command Dispatcher Quickstart > ----------------------------------------------- > > Key: WFLY-8523 > URL: https://issues.jboss.org/browse/WFLY-8523 > Project: WildFly > Issue Type: Task > Components: Clustering, Quickstarts > Reporter: Radoslav Husar > Assignee: Radoslav Husar > -- This message was sent by Atlassian JIRA (v7.2.3#72005)

9 years, 3 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 April 2017