December 2015 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-5778) org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type HttpServletRequest with qualifiers @Default

by triumf Yang (JIRA)

triumf Yang created WFLY-5778: --------------------------------- Summary: org.jboss.weld.exceptions.DeploymentException: WELD-001409: Ambiguous dependencies for type HttpServletRequest with qualifiers @Default Key: WFLY-5778 URL: https://issues.jboss.org/browse/WFLY-5778 Project: WildFly Issue Type: Bug Components: CDI / Weld Affects Versions: 9.0.2.Final Reporter: triumf Yang Assignee: Stuart Douglas Priority: Blocker -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-950) Embedded server started non-modular use first passed --jboss-home value only

by Ken Wills (JIRA)

[ https://issues.jboss.org/browse/WFCORE-950?page=com.atlassian.jira.plugin... ] Ken Wills commented on WFCORE-950: ---------------------------------- Note as part of this, a couple of other issues surfaced: - Restarting with a new --jboss-home continued to reference some files / directories in the previous running instance's --jboss-home (Should be fixed in this change). - The initial boot.log is always the one that continues to receive logging. (Fix in progress). - ModuleLoader: once loaded with getBootModuleLoader() continue to reference the initial modules directory. > Embedded server started non-modular use first passed --jboss-home value only > ---------------------------------------------------------------------------- > > Key: WFCORE-950 > URL: https://issues.jboss.org/browse/WFCORE-950 > Project: WildFly Core > Issue Type: Bug > Components: Domain Management > Affects Versions: 2.0.0.Beta4 > Reporter: Petr Kremensky > Assignee: Ken Wills > Fix For: 3.0.0.Alpha1 > > > First value passed as --jboss-home to embed server instance (must be an existing directory) is always used for modules lookup and server standard paths setup within single CLI session. > # Use wrong directory on first try, use correct directory on second try, embedded instance still tries to boot from wrong directory > {noformat}$ pwd > /home/pkremens/workspace/jboss-eap-7.0/bin/client > $ java -jar jboss-cli-client.jar > [disconnected /] embed-server --jboss-home=/home/pkremens/workspace/jboss-eap-7.0/bin > Cannot start embedded server: WFLYEMB0014: Cannot load module org.jboss.vfs from: local module loader @500e80c2 (finder: local module finder @75670fc4 (roots: /home/pkremens/workspace/jboss-eap-7.0/bin/modules)): org.jboss.vfs:main > # server still tries to use /home/pkremens/workspace/jboss-eap-7.0/bin > [disconnected /] embed-server --jboss-home=/home/pkremens/workspace/jboss-eap-7.0 > Cannot start embedded server: WFLYEMB0014: Cannot load module org.jboss.vfs from: local module loader @500e80c2 (finder: local module finder @75670fc4 (roots: /home/pkremens/workspace/jboss-eap-7.0/bin/modules)): org.jboss.vfs:main > {noformat} > # Try to manage multiple EAP distros > {noformat} > /home/pkremens/workspace2 > ├── eap1 > │ └── jboss-eap-7.0 > └── eap2 > └── jboss-eap-7.0 > $ java -jar jboss-cli-client.jar > [disconnected /] embed-server --jboss-home=/home/pkremens/workspace2/eap1/jboss-eap-7.0 --server-config=eap1.xml --empty-config > [standalone@embedded /] stop-embedded-server > [disconnected /] embed-server --jboss-home=/home/pkremens/workspace2/eap2/jboss-eap-7.0 --server-config=eap2.xml --empty-config > # jboss.server.*.dir point to eap1, but should point to eap2 > [standalone@embedded /] /path=*:read-attribute(name=path) > ... > "address" => [("path" => "jboss.server.log.dir")], > "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0 > "address" => [("path" => "jboss.server.data.dir")], > "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/data" > "address" => [("path" => "jboss.server.base.dir")], > "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone" > "address" => [("path" => "jboss.server.config.dir")], > "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/configuration" > "address" => [("path" => "jboss.server.temp.dir")], > "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/tmp" > "address" => [("path" => "jboss.controller.temp.dir")], > "result" => "/home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/tmp" > "address" => [("path" => "jboss.home.dir")], > "result" => "/home/pkremens/workspace2/eap2/jboss-eap-7.0" > ... > # Both configuration files were created in eap1 directory > $ find /home/pkremens/workspace2 | grep eap[12].xml > /home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/configuration/eap2.xml > /home/pkremens/workspace2/eap1/jboss-eap-7.0/standalone/configuration/eap1.xml > {noformat} -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-999) Replace mockito-all with mockito-core

by Petr Široký (JIRA)

Petr Široký created DROOLS-999: ---------------------------------- Summary: Replace mockito-all with mockito-core Key: DROOLS-999 URL: https://issues.jboss.org/browse/DROOLS-999 Project: Drools Issue Type: Enhancement Reporter: Petr Široký Assignee: Petr Široký {{mockito-all}} is uberjar and disrupts Maven dependency management. It needs to be replaced by {{mockito-core}}. Following IP BOM versions will also ban {{mockito-all}} so the build will start failing. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5777) NPE when forming jgroups cluster

by Thiago Presa (JIRA)

Thiago Presa created WFLY-5777: ---------------------------------- Summary: NPE when forming jgroups cluster Key: WFLY-5777 URL: https://issues.jboss.org/browse/WFLY-5777 Project: WildFly Issue Type: Bug Components: Clustering Affects Versions: 10.0.0.CR4, 9.0.1.Final Reporter: Thiago Presa Assignee: Paul Ferraro I just got this NPE when deploying a new application on my Wildfly 10 CR4 domain cluster. JGRP000027: failed passing message up: java.lang.RuntimeException: java.lang.NullPointerException at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:689) at org.jgroups.JChannel.up(JChannel.java:738) at org.jgroups.stack.ProtocolStack.up(ProtocolStack.java:1029) at org.jgroups.protocols.FORK.up(FORK.java:133) at org.jgroups.protocols.FRAG2.up(FRAG2.java:165) at org.jgroups.protocols.FlowControl.up(FlowControl.java:394) at org.jgroups.protocols.pbcast.GMS.installView(GMS.java:735) at org.jgroups.protocols.pbcast.ParticipantGmsImpl.handleViewChange(ParticipantGmsImpl.java:140) at org.jgroups.protocols.pbcast.GMS.up(GMS.java:925) at org.jgroups.stack.Protocol.up(Protocol.java:412) at org.jgroups.protocols.pbcast.STABLE.up(STABLE.java:294) at org.jgroups.protocols.UNICAST3.up(UNICAST3.java:474) at org.jgroups.protocols.pbcast.NAKACK2.deliverBatch(NAKACK2.java:982) at org.jgroups.protocols.pbcast.NAKACK2.removeAndPassUp(NAKACK2.java:912) at org.jgroups.protocols.pbcast.NAKACK2.handleMessage(NAKACK2.java:846) at org.jgroups.protocols.pbcast.NAKACK2.up(NAKACK2.java:618) at org.jgroups.protocols.VERIFY_SUSPECT.up(VERIFY_SUSPECT.java:155) at org.jgroups.protocols.FD.up(FD.java:260) at org.jgroups.protocols.FD_SOCK.up(FD_SOCK.java:310) at org.jgroups.protocols.MERGE3.up(MERGE3.java:285) at org.jgroups.protocols.Discovery.up(Discovery.java:295) at org.jgroups.protocols.TP.passMessageUp(TP.java:1577) at org.jgroups.protocols.TP$MyHandler.run(TP.java:1796) 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) Caused by: java.lang.NullPointerException at org.wildfly.clustering.server.group.ChannelNodeFactory.createNode(ChannelNodeFactory.java:55) at org.wildfly.clustering.server.group.ChannelNodeFactory.createNode(ChannelNodeFactory.java:40) at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.getNodes(ChannelCommandDispatcherFactory.java:207) at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.getNodes(ChannelCommandDispatcherFactory.java:201) at org.wildfly.clustering.server.dispatcher.ChannelCommandDispatcherFactory.viewAccepted(ChannelCommandDispatcherFactory.java:216) at org.jgroups.blocks.MessageDispatcher.handleUpEvent(MessageDispatcher.java:605) at org.jgroups.blocks.MessageDispatcher$ProtocolAdapter.up(MessageDispatcher.java:686) ... 25 more I have already stumbled upon this issue in Wildfly 9: https://developer.jboss.org/thread/265607 -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-989) Saving/Restoring drools session prevents timer-related rules from firing

by David Weir (JIRA)

[ https://issues.jboss.org/browse/DROOLS-989?page=com.atlassian.jira.plugin... ] David Weir updated DROOLS-989: ------------------------------ Attachment: DroolsTimerTest.java Version without dependence on Stringify classes > Saving/Restoring drools session prevents timer-related rules from firing > ------------------------------------------------------------------------ > > Key: DROOLS-989 > URL: https://issues.jboss.org/browse/DROOLS-989 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: David Weir > Assignee: Mario Fusco > Priority: Blocker > Attachments: DroolsTimerTest.java, DroolsTimerTest.java, DroolsTimerTest.java, DroolsTimerTest.java > > > Attached test case shows a timer-base rule firing. Then the session is saved and restored per the manual. When the trigger is inserted again, the rule does not fire. > This is killing my system whenever I have to restart and restore the current sessions. > The workaround is to create the session again from scratch -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-989) Saving/Restoring drools session prevents timer-related rules from firing

by David Weir (JIRA)

[ https://issues.jboss.org/browse/DROOLS-989?page=com.atlassian.jira.plugin... ] David Weir updated DROOLS-989: ------------------------------ Attachment: DroolsTimerTest.java Updated to show fail properly when test runs. > Saving/Restoring drools session prevents timer-related rules from firing > ------------------------------------------------------------------------ > > Key: DROOLS-989 > URL: https://issues.jboss.org/browse/DROOLS-989 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: David Weir > Assignee: Mario Fusco > Priority: Blocker > Attachments: DroolsTimerTest.java, DroolsTimerTest.java, DroolsTimerTest.java > > > Attached test case shows a timer-base rule firing. Then the session is saved and restored per the manual. When the trigger is inserted again, the rule does not fire. > This is killing my system whenever I have to restart and restore the current sessions. > The workaround is to create the session again from scratch -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-989) Saving/Restoring drools session prevents timer-related rules from firing

by David Weir (JIRA)

[ https://issues.jboss.org/browse/DROOLS-989?page=com.atlassian.jira.plugin... ] David Weir commented on DROOLS-989: ----------------------------------- I modified the test to call a static function which will set a global variable to true when the timed rule fires The test sets the variable false, runs an iteration of the timer test and the rule fires (variable is set to true). Session is saved, variable set to false again and an iteration of the timer test run again and the test fails (variable is not set to true). > Saving/Restoring drools session prevents timer-related rules from firing > ------------------------------------------------------------------------ > > Key: DROOLS-989 > URL: https://issues.jboss.org/browse/DROOLS-989 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: David Weir > Assignee: Mario Fusco > Priority: Blocker > Attachments: DroolsTimerTest.java, DroolsTimerTest.java, DroolsTimerTest.java > > > Attached test case shows a timer-base rule firing. Then the session is saved and restored per the manual. When the trigger is inserted again, the rule does not fire. > This is killing my system whenever I have to restart and restore the current sessions. > The workaround is to create the session again from scratch -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-989) Saving/Restoring drools session prevents timer-related rules from firing

by David Weir (JIRA)

[ https://issues.jboss.org/browse/DROOLS-989?page=com.atlassian.jira.plugin... ] David Weir reopened DROOLS-989: ------------------------------- Able to reproduce against 6.3.0-Final. > Saving/Restoring drools session prevents timer-related rules from firing > ------------------------------------------------------------------------ > > Key: DROOLS-989 > URL: https://issues.jboss.org/browse/DROOLS-989 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.3.0.Final > Reporter: David Weir > Assignee: Mario Fusco > Priority: Blocker > Attachments: DroolsTimerTest.java, DroolsTimerTest.java, DroolsTimerTest.java > > > Attached test case shows a timer-base rule firing. Then the session is saved and restored per the manual. When the trigger is inserted again, the rule does not fire. > This is killing my system whenever I have to restart and restore the current sessions. > The workaround is to create the session again from scratch -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5776) Make use of the principals to roles map as defined within web deployments.

by Darran Lofthouse (JIRA)

Darran Lofthouse created WFLY-5776: -------------------------------------- Summary: Make use of the principals to roles map as defined within web deployments. Key: WFLY-5776 URL: https://issues.jboss.org/browse/WFLY-5776 Project: WildFly Issue Type: Task Components: Web (Undertow) Reporter: Darran Lofthouse Assignee: Darran Lofthouse Fix For: 11.0.0.Alpha1 Will follow up on this one after the authentication is handled. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

10 years, 7 months

1
0
0 / 0

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

by Christian Spurk (JIRA)

Christian Spurk created DROOLS-998: -------------------------------------- Summary: 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 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, 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 2015