January 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFCORE-1335) Allow disabling audit log rotation

by Tomas Hofman (JIRA)

Tomas Hofman created WFCORE-1335: ------------------------------------ Summary: Allow disabling audit log rotation Key: WFCORE-1335 URL: https://issues.jboss.org/browse/WFCORE-1335 Project: WildFly Core Issue Type: Bug Components: Logging Affects Versions: 2.0.7.Final Reporter: Tomas Hofman Assignee: Tomas Hofman https://bugzilla.redhat.com/show_bug.cgi?id=1301554 org.jboss.as.controller.audit.FileAuditLogHandler always rotates audit-log.log at startup/reload. An option to disable log rotation is necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1334) Allow disabling audit log rotation

by Tomas Hofman (JIRA)

Tomas Hofman created WFCORE-1334: ------------------------------------ Summary: Allow disabling audit log rotation Key: WFCORE-1334 URL: https://issues.jboss.org/browse/WFCORE-1334 Project: WildFly Core Issue Type: Bug Components: Logging Affects Versions: 2.0.7.Final Reporter: Tomas Hofman Assignee: Tomas Hofman https://bugzilla.redhat.com/show_bug.cgi?id=1301554 org.jboss.as.controller.audit.FileAuditLogHandler always rotates audit-log.log at startup/reload. An option to disable log rotation is necessary. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1202) LDAP authentication/authorization fails due to making unneeded role lookup requests

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1202?page=com.atlassian.jira.plugi... ] RH Bugzilla Integration commented on WFCORE-1202: ------------------------------------------------- Ivo Studensky <istudens(a)redhat.com> changed the Status of [bug 1301732|https://bugzilla.redhat.com/show_bug.cgi?id=1301732] from NEW to ASSIGNED > LDAP authentication/authorization fails due to making unneeded role lookup requests > ----------------------------------------------------------------------------------- > > Key: WFCORE-1202 > URL: https://issues.jboss.org/browse/WFCORE-1202 > Project: WildFly Core > Issue Type: Bug > Components: Security > Reporter: Brad Maxwell > Assignee: Derek Horton > Fix For: 2.0.5.CR1 > > > LDAP authentication/authorization fails due to making unneeded role lookup requests -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1008) KieServer to update container for SNAPSHOT kjar

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugi... ] Mario Fusco commented on DROOLS-1008: ------------------------------------- I am not sure of what you're asking here. I guess you're talking about the maven default behaviour of only fetching SNAPSHOTS once per day, but if this is the case I think you can configure maven to enforce of checking SNAPSHOTs at each request. Please let me know if this is case or try to better clarify this ticket. > KieServer to update container for SNAPSHOT kjar > ----------------------------------------------- > > Key: DROOLS-1008 > URL: https://issues.jboss.org/browse/DROOLS-1008 > Project: Drools > Issue Type: Feature Request > Components: kie server > Affects Versions: 6.2.0.Final, 6.3.0.Final > Reporter: Andrew Collins > Assignee: Mario Fusco > Attachments: snapshot_kjar_reproducer.patch > > > When a kjar is a snapshot version, kie-server will not react to new snapshot versions deployed to a remote artifact repository. The remote artifact repository is only queried the first time after JVM startup. Updating a KieContainer to a newer snapshot version is only possible through use of the KieScanner, which will both fetch the new artifact from the remote repository, and reload the kmodule in the KieServer JVM. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6076) CLI deployment of WAR exploded JSF2.2 applications fails with exceptions

by Miroslav Pavleski (JIRA)

Miroslav Pavleski created WFLY-6076: --------------------------------------- Summary: CLI deployment of WAR exploded JSF2.2 applications fails with exceptions Key: WFLY-6076 URL: https://issues.jboss.org/browse/WFLY-6076 Project: WildFly Issue Type: Bug Components: JSF Affects Versions: 10.0.0.CR5 Reporter: Miroslav Pavleski Assignee: Farah Juma Attachments: cli.log, console.log In 9.0.2 FINAL and prior (8.1, 8.2) deploying an exploded WAR using the CLI was working fine. This kind of deployment has benefits during development as the static resources are updated on-save. The problem occurs probably due JSF initialization, see the attachments. Deployment using mvn wildfly:deploy works fine. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-987) Errors in Phreak under heavy and multi threaded load

by Mario Fusco (JIRA)

[ https://issues.jboss.org/browse/DROOLS-987?page=com.atlassian.jira.plugin... ] Mario Fusco commented on DROOLS-987: ------------------------------------ Marco, I'm giving a second look at this and in reality what is reentrant is this line in the DefaultSignalManager org.jbpm.process.instance.event.DefaultSignalManager.signalEvent(DefaultSignalManager.java:74) I suspect this is wrong anyway even if I cannot be sure that this is also causing the reported error. > Errors in Phreak under heavy and multi threaded load > ----------------------------------------------------- > > Key: DROOLS-987 > URL: https://issues.jboss.org/browse/DROOLS-987 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: linux > Java 7 > kernel 3.16 > Reporter: Jose Cavieres > Assignee: Marco Rietveld > Attachments: jbpm-bussinesruletask-concurrent-6-3-NEW.tgz, jbpm-bussinesruletask-concurrent-6-3.tgz > > > Several threads are started, each one starts 1 jbpm process containing rule(s) task(s). > If the threads are few, everything works fine. Under heavy load nullPointerExceptions are thown most of the time, less frequently fireAllRules never ends and CPU remains at 100%. > Aparently the setFocus method used by rule tasks is related to the problem. > The most comon error is: > Caused by: java.lang.NullPointerException > at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141) > at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteSegmentMemory(LeftInputAdapterNode.java:295) > at org.drools.core.reteoo.LeftInputAdapterNode.doDeleteObject(LeftInputAdapterNode.java:266) > at org.drools.core.reteoo.LeftInputAdapterNode.retractLeftTuple(LeftInputAdapterNode.java:361) > at org.drools.core.reteoo.ObjectTypeNode.doRetractObject(ObjectTypeNode.java:334) > at org.drools.core.reteoo.ObjectTypeNode.retractObject(ObjectTypeNode.java:317) > at org.drools.core.reteoo.EntryPointNode.propagateRetract(EntryPointNode.java:358) > at org.drools.core.phreak.PropagationEntry$Delete.execute(PropagationEntry.java:172) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96) > at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:69) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.flushPropagations(StatefulKnowledgeSessionImpl.java:1993) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-998) NullPointerException at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141)

by RH Bugzilla Integration (JIRA)

[ https://issues.jboss.org/browse/DROOLS-998?page=com.atlassian.jira.plugin... ] RH Bugzilla Integration commented on DROOLS-998: ------------------------------------------------ Mario Fusco <mfusco(a)redhat.com> changed the Status of [bug 1302141|https://bugzilla.redhat.com/show_bug.cgi?id=1302141] from ASSIGNED to MODIFIED > NullPointerException at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141) > --------------------------------------------------------------------------------------------------------- > > Key: DROOLS-998 > URL: https://issues.jboss.org/browse/DROOLS-998 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Environment: OpenJDK Runtime Environment (IcedTea 2.6.3) (7u91-2.6.3-0ubuntu0.14.04.1) > Reporter: Christian Spurk > Assignee: Mario Fusco > Fix For: 6.4.0.CR1 > > > The following {{NullPointerException}} occurs for the following rule: > {code} > Exception in thread "main" java.lang.NullPointerException > at org.drools.core.common.LeftTupleSetsImpl.removeInsert(LeftTupleSetsImpl.java:141) > at org.drools.core.common.LeftTupleSetsImpl.addDelete(LeftTupleSetsImpl.java:80) > at org.drools.core.phreak.PhreakAccumulateNode.doLeftDeletes(PhreakAccumulateNode.java:603) > at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:65) > at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:565) > at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:536) > at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:372) > at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:332) > at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:166) > at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:123) > at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:194) > at org.drools.core.phreak.RuleExecutor.fire(RuleExecutor.java:142) > at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:74) > at org.drools.core.common.DefaultAgenda.fireNextItem(DefaultAgenda.java:978) > at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1292) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1294) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1281) > at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1260) > at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:109) > at org.drools.core.command.runtime.rule.FireAllRulesCommand.execute(FireAllRulesCommand.java:34) > at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:292) > at Test.main(Test.java:13) > {code} > {code} > rule "test" > when > not( String() ) > accumulate( > Long(); > sum(1) > ) > ( Boolean() or not( Float() ) ) > then > insert(new String()); > end > {code} > (Please ignore the nonsensical rule; I simply couldn't reproduce this issue in any better way without providing you my larger system where the (more complex) rule makes more sense.) > I'm using a default KIE configuration to load the rule: > {{kmodule.xml}}: > {code} > <?xml version="1.0" encoding="UTF-8"?> > <kmodule xmlns="http://jboss.org/kie/6.0.0/kmodule" /> > {code} > {{Test.java}}: > {code} > import org.kie.api.KieBase; > import org.kie.api.KieServices; > import org.kie.api.runtime.StatelessKieSession; > import org.kie.internal.command.CommandFactory; > public class Test { > public static void main(String[] args) { > KieBase kieBase = KieServices.Factory.get().getKieClasspathContainer() > .getKieBase(); > StatelessKieSession session = kieBase.newStatelessKieSession(); > session.execute(CommandFactory.newFireAllRules()); > } > } > {code} > This issue might be related with DROOLS-987. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6072) channel.receiveMessage(this); should not be called till all message data is read

by Stuart Douglas (JIRA)

[ https://issues.jboss.org/browse/WFLY-6072?page=com.atlassian.jira.plugin.... ] Stuart Douglas resolved WFLY-6072. ---------------------------------- Resolution: Rejected > channel.receiveMessage(this); should not be called till all message data is read > -------------------------------------------------------------------------------- > > Key: WFLY-6072 > URL: https://issues.jboss.org/browse/WFLY-6072 > Project: WildFly > Issue Type: Bug > Components: EJB > Reporter: Stuart Douglas > Assignee: Stuart Douglas > -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2007) Adapt code to use new Java 8 features

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2007?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2007: -------------------------------- Thanks for the advice, Johno! I'll re-check where I'm using for loops... > Adapt code to use new Java 8 features > ------------------------------------- > > Key: JGRP-2007 > URL: https://issues.jboss.org/browse/JGRP-2007 > Project: JGroups > Issue Type: Task > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 4.0 > > > E.g replace loops for forEach() etc -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 3 months

1
0
0 / 0

[JBoss JIRA] (WFLY-6074) Undertow migration operation does not translate access log patterns

by Stuart Douglas (JIRA)

Stuart Douglas created WFLY-6074: ------------------------------------ Summary: Undertow migration operation does not translate access log patterns Key: WFLY-6074 URL: https://issues.jboss.org/browse/WFLY-6074 Project: WildFly Issue Type: Bug Components: Web (Undertow) Reporter: Stuart Douglas Assignee: Stuart Douglas -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 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 January 2016