June 2016 - jboss-jira - Jboss List Archives

[JBoss JIRA] (DROOLS-1186) Setting the planning variable nullable in nurserostering examples causes Drools NPE

by Jiri Locker (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1186?page=com.atlassian.jira.plugi... ] Jiri Locker updated DROOLS-1186: -------------------------------- Comment: was deleted (was: A comment with security level 'JBoss Employee' was removed.) > Setting the planning variable nullable in nurserostering examples causes Drools NPE > ----------------------------------------------------------------------------------- > > Key: DROOLS-1186 > URL: https://issues.jboss.org/browse/DROOLS-1186 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.2.0.Final, 6.3.0.Final > Environment: Windows 7 x 64, JDK 8u66, IDE netbeans 8.0.1. > Reporter: Julio Bellon Aguilera > Assignee: Mario Fusco > Priority: Critical > Fix For: 7.0.0.Beta1 > > Attachments: PLANNER_488.patch > > > If you set the planning variable to "nullable=true", firstable, causes a IllegalStateException. > fixed that, causes the first NPE, and fixed that, causes other NPE unfixed: > Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: > Caused by: java.lang.NullPointerException > at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:778) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1186) Setting the planning variable nullable in nurserostering examples causes Drools NPE

by Jiri Locker (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1186?page=com.atlassian.jira.plugi... ] Jiri Locker updated DROOLS-1186: -------------------------------- Comment: was deleted (was: A comment with security level 'JBoss Employee' was removed.) > Setting the planning variable nullable in nurserostering examples causes Drools NPE > ----------------------------------------------------------------------------------- > > Key: DROOLS-1186 > URL: https://issues.jboss.org/browse/DROOLS-1186 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.2.0.Final, 6.3.0.Final > Environment: Windows 7 x 64, JDK 8u66, IDE netbeans 8.0.1. > Reporter: Julio Bellon Aguilera > Assignee: Mario Fusco > Priority: Critical > Fix For: 7.0.0.Beta1 > > Attachments: PLANNER_488.patch > > > If you set the planning variable to "nullable=true", firstable, causes a IllegalStateException. > fixed that, causes the first NPE, and fixed that, causes other NPE unfixed: > Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: > Caused by: java.lang.NullPointerException > at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:778) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1186) Setting the planning variable nullable in nurserostering examples causes Drools NPE

by Jiri Locker (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1186?page=com.atlassian.jira.plugi... ] Jiri Locker updated DROOLS-1186: -------------------------------- Comment: was deleted (was: A comment with security level 'JBoss Employee' was removed.) > Setting the planning variable nullable in nurserostering examples causes Drools NPE > ----------------------------------------------------------------------------------- > > Key: DROOLS-1186 > URL: https://issues.jboss.org/browse/DROOLS-1186 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.2.0.Final, 6.3.0.Final > Environment: Windows 7 x 64, JDK 8u66, IDE netbeans 8.0.1. > Reporter: Julio Bellon Aguilera > Assignee: Mario Fusco > Priority: Critical > Fix For: 7.0.0.Beta1 > > Attachments: PLANNER_488.patch > > > If you set the planning variable to "nullable=true", firstable, causes a IllegalStateException. > fixed that, causes the first NPE, and fixed that, causes other NPE unfixed: > Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: > Caused by: java.lang.NullPointerException > at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:778) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (DROOLS-1186) Setting the planning variable nullable in nurserostering examples causes Drools NPE

by Jiri Locker (JIRA)

[ https://issues.jboss.org/browse/DROOLS-1186?page=com.atlassian.jira.plugi... ] Jiri Locker updated DROOLS-1186: -------------------------------- Comment: was deleted (was: A comment with security level 'JBoss Employee' was removed.) > Setting the planning variable nullable in nurserostering examples causes Drools NPE > ----------------------------------------------------------------------------------- > > Key: DROOLS-1186 > URL: https://issues.jboss.org/browse/DROOLS-1186 > Project: Drools > Issue Type: Bug > Components: core engine > Affects Versions: 6.2.0.Final, 6.3.0.Final > Environment: Windows 7 x 64, JDK 8u66, IDE netbeans 8.0.1. > Reporter: Julio Bellon Aguilera > Assignee: Mario Fusco > Priority: Critical > Fix For: 7.0.0.Beta1 > > Attachments: PLANNER_488.patch > > > If you set the planning variable to "nullable=true", firstable, causes a IllegalStateException. > fixed that, causes the first NPE, and fixed that, causes other NPE unfixed: > Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: > Caused by: java.lang.NullPointerException > at org.drools.core.phreak.RuleNetworkEvaluator.deleteChildLeftTuple(RuleNetworkEvaluator.java:778) -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFCORE-1579) Perform check when changing 'path' attribute of 'deployment-scanner' instance

by Tomas Hofman (JIRA)

[ https://issues.jboss.org/browse/WFCORE-1579?page=com.atlassian.jira.plugi... ] Tomas Hofman moved JBEAP-4888 to WFCORE-1579: --------------------------------------------- Project: WildFly Core (was: JBoss Enterprise Application Platform) Key: WFCORE-1579 (was: JBEAP-4888) Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1) Component/s: Deployment Scanner (was: Deployment Scanner) Target Release: (was: 7.backlog.GA) Affects Version/s: 3.0.0.Alpha1 (was: 7.0.0.GA) > Perform check when changing 'path' attribute of 'deployment-scanner' instance > ----------------------------------------------------------------------------- > > Key: WFCORE-1579 > URL: https://issues.jboss.org/browse/WFCORE-1579 > Project: WildFly Core > Issue Type: Bug > Components: Deployment Scanner > Affects Versions: 3.0.0.Alpha1 > Reporter: Tomas Hofman > Assignee: Tomas Hofman > Priority: Minor > > When creating my own deployment-scanner, I have to provide {{path}} attribute where given value is checked whether it is a real directory on current filesystem. Although when I change value of this attribute in existing deployment-scanner instance, such check is not performed and I can provide non-existent directory. This leads to server crash after calling reload operation: > # start EAP7 server and connect to CLI > # create your own deployment-scanner instance pointing to existing directory > {code} > [standalone@localhost:9990 /] /subsystem=deployment-scanner/scanner=mysc:add(path=/home/jstourac/Downloads/jboss-eap-7.0/standalone/deployments) > {"outcome" => "success"} > {code} > # change path of deployment-scanner to some nonexisting directory > {code} > [standalone@localhost:9990 /] /subsystem=deployment-scanner/scanner=mysc:write-attribute(name=path,value=/nonexistent) > { > "outcome" => "success", > "response-headers" => { > "operation-requires-reload" => true, > "process-state" => "reload-required" > } > } > {code} > # perform reload operation > # server fails with following output in console.log > {code} > 15:29:08,039 INFO [org.jboss.as.server.deployment.scanner] (MSC service thread 1-5) WFLYDS0013: Started FileSystemDeploymentService for directory /home/jstourac/Downloads/jboss-eap-7.0/standalone/deployments > 15:29:29,068 INFO [org.jboss.as.connector.subsystems.datasources] (MSC service thread 1-3) WFLYJCA0010: Unbound data source [java:jboss/datasources/ExampleDS] > 15:29:29,070 INFO [org.wildfly.extension.undertow] (MSC service thread 1-8) WFLYUT0019: Host default-host stopping > 15:29:29,071 INFO [org.jboss.as.connector.deployers.jdbc] (MSC service thread 1-5) WFLYJCA0019: Stopped Driver service with driver-name = h2 > 15:29:29,073 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0008: Undertow HTTP listener default suspending > 15:29:29,075 INFO [org.wildfly.extension.undertow] (MSC service thread 1-4) WFLYUT0007: Undertow HTTP listener default stopped, was bound to 127.0.0.1:8080 > 15:29:29,076 INFO [org.wildfly.extension.undertow] (MSC service thread 1-2) WFLYUT0004: Undertow 1.3.21.Final-redhat-1 stopping > 15:29:29,081 INFO [org.jboss.as.mail.extension] (MSC service thread 1-2) WFLYMAIL0002: Unbound mail session [java:jboss/mail/Default] > 15:29:29,082 INFO [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 16ms > 15:29:29,083 INFO [org.jboss.as] (MSC service thread 1-8) WFLYSRV0049: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) starting > 15:29:29,135 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 13) WFLYCTL0013: Operation ("add") failed - address: ([ > ("subsystem" => "deployment-scanner"), > ("scanner" => "mysc") > ]): java.lang.IllegalArgumentException: WFLYDS0023: /nonexistent does not exist > at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.<init>(FileSystemDeploymentService.java:273) > at org.jboss.as.server.deployment.scanner.DeploymentScannerAdd.execute(DeploymentScannerAdd.java:124) > at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:890) > at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:659) > at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370) > at org.jboss.as.controller.ParallelBootOperationStepHandler$ParallelBootTask.run(ParallelBootOperationStepHandler.java:359) > 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) > at org.jboss.threads.JBossThread.run(JBossThread.java:320) > 15:29:29,139 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) "WFLYCTL0193: Failed executing subsystem deployment-scanner boot operations" > 15:29:29,140 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("parallel-subsystem-boot") failed - address: ([]) - failure description: "\"WFLYCTL0193: Failed executing subsystem deployment-scanner boot operations\"" > 15:29:29,141 FATAL [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0056: Server boot has failed in an unrecoverable manner; exiting. See previous messages for details. > 15:29:29,144 INFO [org.jboss.as.server] (Thread-2) WFLYSRV0220: Server shutdown has been requested. > 15:29:29,159 INFO [org.jboss.as] (MSC service thread 1-8) WFLYSRV0050: JBoss EAP 7.0.0.GA (WildFly Core 2.1.2.Final-redhat-1) stopped in 4ms > {code} > # one has to manually modify {{EAP_HOME/standalone/configuration/standalone.xml}} removing problematic deployment-scanner part to be able to start server again > It would be great if there is same check to {{path}} atribute performed when changing it in existing instance of deployment-scanner as what is performed during the adding a new instance of deployment-scanner. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5525) ANT task and libraries to precompile jsp files

by Ivo Hrádek (JIRA)

[ https://issues.jboss.org/browse/WFLY-5525?page=com.atlassian.jira.plugin.... ] Ivo Hrádek reassigned WFLY-5525: -------------------------------- Assignee: (was: Ivo Hrádek) > ANT task and libraries to precompile jsp files > ---------------------------------------------- > > Key: WFLY-5525 > URL: https://issues.jboss.org/browse/WFLY-5525 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Pradeep Pantula > Priority: Optional > Fix For: Awaiting Volunteers > > > We are migration our applications from Jboss7.1 to WildFly8.1 . For all purposes we pre-compile jsp files and deploy applications for performance. Can anyone provide me ant tasks and related libraries to pre-compile jsp files and deploy applications (.ear files) in WildFly8.1 > I tried with ecj and jastow libraries which are provided under io.undertow.jsp module. But that did not worked for me. > Can anyone let me know or give a way of how to achieve this. > Thanks in Advance, > Pradeep. P -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (WFLY-5525) ANT task and libraries to precompile jsp files

by Ivo Hrádek (JIRA)

[ https://issues.jboss.org/browse/WFLY-5525?page=com.atlassian.jira.plugin.... ] Ivo Hrádek reassigned WFLY-5525: -------------------------------- Assignee: Ivo Hrádek > ANT task and libraries to precompile jsp files > ---------------------------------------------- > > Key: WFLY-5525 > URL: https://issues.jboss.org/browse/WFLY-5525 > Project: WildFly > Issue Type: Task > Components: Web (Undertow) > Reporter: Pradeep Pantula > Assignee: Ivo Hrádek > Priority: Optional > Fix For: Awaiting Volunteers > > > We are migration our applications from Jboss7.1 to WildFly8.1 . For all purposes we pre-compile jsp files and deploy applications for performance. Can anyone provide me ant tasks and related libraries to pre-compile jsp files and deploy applications (.ear files) in WildFly8.1 > I tried with ecj and jastow libraries which are provided under io.undertow.jsp module. But that did not worked for me. > Can anyone let me know or give a way of how to achieve this. > Thanks in Advance, > Pradeep. P -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2076) TransferQueueBundler: bundler thread should remove chunks of messages

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2076?page=com.atlassian.jira.plugin.... ] Bela Ban resolved JGRP-2076. ---------------------------- Resolution: Done > TransferQueueBundler: bundler thread should remove chunks of messages > --------------------------------------------------------------------- > > Key: JGRP-2076 > URL: https://issues.jboss.org/browse/JGRP-2076 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.10, 4.0 > > > Currently, the bundler thread in TransferQueueBundler removes messages from the queue one by one: > {code:java} > while(null != (msg=queue.poll())) { > long size=msg.size(); > if(count + size >= transport.getMaxBundleSize()) > sendBundledMessages(); > addMessage(msg, size); > } > {code} > This is inefficient, as we need to acquire the lock on ArrayBlockingQueue every time. {{ArrayBlockingQueue.drainTo()}} should be used instead, to remove as many messages as are in the queue with one lock acquisition. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (ELY-454) Kerberos (GSS) Credential Store

by Darran Lofthouse (JIRA)

[ https://issues.jboss.org/browse/ELY-454?page=com.atlassian.jira.plugin.sy... ] Darran Lofthouse resolved ELY-454. ---------------------------------- Resolution: Rejected Our configuration is now detailed enough to include host and protocol information so this can be obtained from a SecurityFactory. > Kerberos (GSS) Credential Store > ------------------------------- > > Key: ELY-454 > URL: https://issues.jboss.org/browse/ELY-454 > Project: WildFly Elytron > Issue Type: Feature Request > Components: Credential Store > Reporter: David Lloyd > Assignee: Darran Lofthouse > Fix For: 1.1.0.Beta6 > > > We need a credential store for holding Kerberos GSS tokens. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 months

1
0
0 / 0

[JBoss JIRA] (JGRP-2076) TransferQueueBundler: bundler thread should remove chunks of messages

by Bela Ban (JIRA)

[ https://issues.jboss.org/browse/JGRP-2076?page=com.atlassian.jira.plugin.... ] Bela Ban commented on JGRP-2076: -------------------------------- A quick test with {{RoundTrip}} and 20 threads brought the round-trip time down from 205 us to 180 us. > TransferQueueBundler: bundler thread should remove chunks of messages > --------------------------------------------------------------------- > > Key: JGRP-2076 > URL: https://issues.jboss.org/browse/JGRP-2076 > Project: JGroups > Issue Type: Enhancement > Reporter: Bela Ban > Assignee: Bela Ban > Priority: Minor > Fix For: 3.6.10, 4.0 > > > Currently, the bundler thread in TransferQueueBundler removes messages from the queue one by one: > {code:java} > while(null != (msg=queue.poll())) { > long size=msg.size(); > if(count + size >= transport.getMaxBundleSize()) > sendBundledMessages(); > addMessage(msg, size); > } > {code} > This is inefficient, as we need to acquire the lock on ArrayBlockingQueue every time. {{ArrayBlockingQueue.drainTo()}} should be used instead, to remove as many messages as are in the queue with one lock acquisition. -- This message was sent by Atlassian JIRA (v6.4.11#64026)

9 years, 11 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 June 2016