From issues at jboss.org  Mon Jan  1 10:48:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 1 Jan 2018 10:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3483) Deprecated
 PathAddress.navigate and remove,
 replace controller catches of NoSuchElementException with
 Resource.NoSuchResourceException
In-Reply-To: <JIRA.12726104.1514821655000@Atlassian.JIRA>
References: <JIRA.12726104.1514821655000@Atlassian.JIRA>
	<JIRA.12726104.1514821655746@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726104.1514821655000.18316.1514821680078@Atlassian.JIRA>

Brian Stansberry created WFCORE-3483:
----------------------------------------

             Summary: Deprecated PathAddress.navigate and remove, replace controller catches of NoSuchElementException with Resource.NoSuchResourceException
                 Key: WFCORE-3483
                 URL: https://issues.jboss.org/browse/WFCORE-3483
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor


The management layer has some old code that uses throwing or catching of NoSuchElementException as a way to represent that a resource doesn't exist. Clean this out so we can more easily move to a cleaner set of exceptions.

This work will consist of two aspects:

1) Code that's meant to catch Resource.NoSuchResourceException but instead catches its superclass NoSuchElementException will shift to catching the subclass. This will make the true intent of the code clearer.

2) The unused PathAddress.navigate and remove methods, which throw NoSuchElementException, will be deprecated. Using PathAddress to maneuver through a deep DMR node tree is not really how management works ever since we introduced the Resource class long long ago (hence these methods are unused.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  1 11:13:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 1 Jan 2018 11:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3483) Deprecate
 PathAddress.navigate and remove,
 replace controller catches of NoSuchElementException with
 Resource.NoSuchResourceException
In-Reply-To: <JIRA.12726104.1514821656000@Atlassian.JIRA>
References: <JIRA.12726104.1514821656000@Atlassian.JIRA>
	<JIRA.12726104.1514821656000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726104.1514821656000.18321.1514823180073@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3483:
-------------------------------------
    Summary: Deprecate PathAddress.navigate and remove, replace controller catches of NoSuchElementException with Resource.NoSuchResourceException  (was: Deprecated PathAddress.navigate and remove, replace controller catches of NoSuchElementException with Resource.NoSuchResourceException)


> Deprecate PathAddress.navigate and remove, replace controller catches of NoSuchElementException with Resource.NoSuchResourceException
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3483
>                 URL: https://issues.jboss.org/browse/WFCORE-3483
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> The management layer has some old code that uses throwing or catching of NoSuchElementException as a way to represent that a resource doesn't exist. Clean this out so we can more easily move to a cleaner set of exceptions.
> This work will consist of two aspects:
> 1) Code that's meant to catch Resource.NoSuchResourceException but instead catches its superclass NoSuchElementException will shift to catching the subclass. This will make the true intent of the code clearer.
> 2) The unused PathAddress.navigate and remove methods, which throw NoSuchElementException, will be deprecated. Using PathAddress to maneuver through a deep DMR node tree is not really how management works ever since we introduced the Resource class long long ago (hence these methods are unused.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  1 16:58:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 1 Jan 2018 16:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9643) Getting Internal server error
 on exception if the rest service content type is "application/xml"
In-Reply-To: <JIRA.12726085.1514643775000@Atlassian.JIRA>
References: <JIRA.12726085.1514643775000@Atlassian.JIRA>
	<JIRA.12726085.1514643775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726085.1514643775000.18329.1514843880383@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-9643:
------------------------------------

    Component/s: REST
                     (was: Application Client)
       Priority: Major  (was: Blocker)
       Assignee: Alessio Soldano  (was: Stuart Douglas)


> Getting Internal server error on exception if the rest service content type is "application/xml"
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9643
>                 URL: https://issues.jboss.org/browse/WFLY-9643
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>            Reporter: Gopal krishna
>            Assignee: Alessio Soldano
>
> We are getting Internal server error if any exception is thrown from spring interceptor  when rest API header is set as "application/xml". This works if the rest API header is set as "application/json".
> we didnt see this issue in jboss 7 and  WAS



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  1 17:03:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 1 Jan 2018 17:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9639) Messages are stuck in a Queue
 that is configured on HornetQ
In-Reply-To: <JIRA.12726006.1514054210000@Atlassian.JIRA>
References: <JIRA.12726006.1514054210000@Atlassian.JIRA>
	<JIRA.12726006.1514054210000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726006.1514054210000.18335.1514844180286@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9639?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-9639:
------------------------------------

    Component/s: JMS
                     (was: Application Client)
       Assignee: Jeff Mesnil  (was: Stuart Douglas)


> Messages are stuck in a Queue that is configured on HornetQ
> -----------------------------------------------------------
>
>                 Key: WFLY-9639
>                 URL: https://issues.jboss.org/browse/WFLY-9639
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 9.x.x TBD
>         Environment: RHEL 7.2, JDK 1.8_144
>            Reporter: Rajendra Mallampati
>            Assignee: Jeff Mesnil
>
> We use WildFly 9.0.2 for hosting our web application and it has both real time and batch processing components. One of the functions supported on the web includes uploading a file with a number of lines any where from 1 to 10K, If the file is valid (virus scan etc passed) it is parsed into that may messages and published to a queue. Each message will have two counters total number of messages that are published to the queue, and the message number. 
> The consuming side is implemented using Spring DefaultMessageListenerContainer (DMLC) with a concurrency of 50 and maxConcurrency of 75. The listeners that implement MessageListener interface are integrated into DMLC. sometimes, if the producing side published 100 messages the consuming side only receiving 98 (per say) and gets stuck because two more messages should be in the Queue. Those two messages are not delivered and don't know where they are going. We tried even persistent Queues and the result is same (getting stuck).
> This is happening in production and any insight into this issue is highly appreciated.
> Here are the software details:
> App server : Wildfly 9.0.2
> HornetQ : 2.4.7
> JDK : 1_8_144
> If you need additional details I will be very glad to provide.
> Thanks
> Rajendra



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  1 17:04:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 1 Jan 2018 17:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9636) EJB lookup over HTTP times
 out connection after 60 seconds
In-Reply-To: <JIRA.12725992.1513958595000@Atlassian.JIRA>
References: <JIRA.12725992.1513958595000@Atlassian.JIRA>
	<JIRA.12725992.1513958595000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725992.1513958595000.18338.1514844240149@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-9636:
------------------------------------

    Assignee: Stuart Douglas


> EJB lookup over HTTP times out connection after 60 seconds
> ----------------------------------------------------------
>
>                 Key: WFLY-9636
>                 URL: https://issues.jboss.org/browse/WFLY-9636
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, IO, Naming
>    Affects Versions: 11.0.0.Final
>         Environment: I work with https://developer.jboss.org/people/jaikiran on https://developer.jboss.org/thread/276635 so my Wildfly 11 environment has this fix in it.
>            Reporter: peter craddock
>            Assignee: Stuart Douglas
>
> The code examples and trace logging can be found here https://developer.jboss.org/thread/276840  
> I have work round the problem but was asked to raise it for further investigation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  1 17:12:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 1 Jan 2018 17:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9645) EJB lookup over HTTP times
 out connection after 60 seconds
In-Reply-To: <JIRA.12726106.1514844681000@Atlassian.JIRA>
References: <JIRA.12726106.1514844681000@Atlassian.JIRA>
	<JIRA.12726106.1514844681431@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726106.1514844681000.18341.1514844720246@Atlassian.JIRA>

Stuart Douglas created WFLY-9645:
------------------------------------

             Summary: EJB lookup over HTTP times out connection after 60 seconds
                 Key: WFLY-9645
                 URL: https://issues.jboss.org/browse/WFLY-9645
             Project: WildFly
          Issue Type: Bug
          Components: EJB, IO, Naming
    Affects Versions: 11.0.0.Final
         Environment: I work with https://developer.jboss.org/people/jaikiran on https://developer.jboss.org/thread/276635 so my Wildfly 11 environment has this fix in it.
            Reporter: peter craddock
            Assignee: Stuart Douglas


The code examples and trace logging can be found here https://developer.jboss.org/thread/276840  

I have work round the problem but was asked to raise it for further investigation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 02:30:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 02:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9646) Wsconsume is not able to
 generate jar file from wsdl
In-Reply-To: <JIRA.12726113.1514878188000@Atlassian.JIRA>
References: <JIRA.12726113.1514878188000@Atlassian.JIRA>
	<JIRA.12726113.1514878188038@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726113.1514878188000.18454.1514878200161@Atlassian.JIRA>

Marek Kopeck? created WFLY-9646:
-----------------------------------

             Summary: Wsconsume is not able to generate jar file from wsdl
                 Key: WFLY-9646
                 URL: https://issues.jboss.org/browse/WFLY-9646
             Project: WildFly
          Issue Type: Bug
          Components: Web Services
            Reporter: Marek Kopeck?
            Assignee: Alessio Soldano
            Priority: Blocker


*Description:*
Wsconsume is able to generate jar file from wsdl on WildFly 11. On WildFly master, wsconsume doesn't create any files in "out" folder. It leads to Exception from wsdl2java tool.

*Steps to reproduce:*
# cd $\{JBOSS_HOME\}/bin
# # download Echo1.wsdl, Echo1Service.wsdl and Echo1Service_schema1.xsd files, these files are attached to this jira
# mkdir out
# ./wsconsume.sh -j wsClientShort.jar -p org.jboss.test.script -o out Echo1Service.wsdl


*Actual results:*
{noformat}
[mkopecky at dhcp-10-40-4-226 bin]$ ./wsconsume.sh -j wsClientShort.jar -p org.jboss.test.script -o out Echo1Service.wsdl
Could not find log4j.properties or log4j.xml configuration, logging to console.

Loading FrontEnd jaxws ...
Loading DataBinding jaxb ...
wsdl2java -clientjar wsClientShort.jar -compile -exsh false -p org.jboss.test.script -d /home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583 -verbose -classdir /home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out -allowElementReferences file:/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/Echo1Service.wsdl
wsdl2java - Apache CXF 3.1.12

JBWS024002: Failed to invoke org.apache.cxf.tools.wsdlto.WSDLToJava
org.apache.cxf.tools.common.ToolException: java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583/org/jboss/test/script/package-info.java" "read")
	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:423)
	at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
	at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
	at org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:313)
	at org.jboss.ws.tools.cmd.WSConsume.importServices(WSConsume.java:298)
	at org.jboss.ws.tools.cmd.WSConsume.mainInternal(WSConsume.java:108)
	at org.jboss.ws.tools.cmd.WSConsume.main(WSConsume.java:96)
	at org.jboss.modules.Module.run(Module.java:344)
	at org.jboss.modules.Main.main(Main.java:525)
Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583/org/jboss/test/script/package-info.java" "read")
	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
	at java.security.AccessController.checkPermission(AccessController.java:884)
	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
	at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
	at java.io.File.isDirectory(File.java:844)
	at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:69)
	at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:64)
	at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromFiles(JavacFileManager.java:785)
	at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromStrings(JavacFileManager.java:185)
	at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:192)
	at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:141)
	at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:123)
	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:306)
	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:415)
	... 8 more
[mkopecky at dhcp-10-40-4-226 bin]$ ll out/
total 0
[mkopecky at dhcp-10-40-4-226 bin]$
{noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 02:31:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 02:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9646) Wsconsume is not able to
 generate jar file from wsdl
In-Reply-To: <JIRA.12726113.1514878188000@Atlassian.JIRA>
References: <JIRA.12726113.1514878188000@Atlassian.JIRA>
	<JIRA.12726113.1514878188000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726113.1514878188000.18462.1514878260291@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFLY-9646:
--------------------------------
    Component/s: Scripts


> Wsconsume is not able to generate jar file from wsdl
> ----------------------------------------------------
>
>                 Key: WFLY-9646
>                 URL: https://issues.jboss.org/browse/WFLY-9646
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts, Web Services
>            Reporter: Marek Kopeck?
>            Assignee: Alessio Soldano
>            Priority: Blocker
>
> *Description:*
> Wsconsume is able to generate jar file from wsdl on WildFly 11. On WildFly master, wsconsume doesn't create any files in "out" folder. It leads to Exception from wsdl2java tool.
> *Steps to reproduce:*
> # cd $\{JBOSS_HOME\}/bin
> # # download Echo1.wsdl, Echo1Service.wsdl and Echo1Service_schema1.xsd files, these files are attached to this jira
> # mkdir out
> # ./wsconsume.sh -j wsClientShort.jar -p org.jboss.test.script -o out Echo1Service.wsdl
> *Actual results:*
> {noformat}
> [mkopecky at dhcp-10-40-4-226 bin]$ ./wsconsume.sh -j wsClientShort.jar -p org.jboss.test.script -o out Echo1Service.wsdl
> Could not find log4j.properties or log4j.xml configuration, logging to console.
> Loading FrontEnd jaxws ...
> Loading DataBinding jaxb ...
> wsdl2java -clientjar wsClientShort.jar -compile -exsh false -p org.jboss.test.script -d /home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583 -verbose -classdir /home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out -allowElementReferences file:/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/Echo1Service.wsdl
> wsdl2java - Apache CXF 3.1.12
> JBWS024002: Failed to invoke org.apache.cxf.tools.wsdlto.WSDLToJava
> org.apache.cxf.tools.common.ToolException: java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583/org/jboss/test/script/package-info.java" "read")
> 	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:423)
> 	at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> 	at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> 	at org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:313)
> 	at org.jboss.ws.tools.cmd.WSConsume.importServices(WSConsume.java:298)
> 	at org.jboss.ws.tools.cmd.WSConsume.mainInternal(WSConsume.java:108)
> 	at org.jboss.ws.tools.cmd.WSConsume.main(WSConsume.java:96)
> 	at org.jboss.modules.Module.run(Module.java:344)
> 	at org.jboss.modules.Main.main(Main.java:525)
> Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583/org/jboss/test/script/package-info.java" "read")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> 	at java.security.AccessController.checkPermission(AccessController.java:884)
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> 	at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> 	at java.io.File.isDirectory(File.java:844)
> 	at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:69)
> 	at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:64)
> 	at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromFiles(JavacFileManager.java:785)
> 	at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromStrings(JavacFileManager.java:185)
> 	at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:192)
> 	at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:141)
> 	at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:123)
> 	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:306)
> 	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
> 	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:415)
> 	... 8 more
> [mkopecky at dhcp-10-40-4-226 bin]$ ll out/
> total 0
> [mkopecky at dhcp-10-40-4-226 bin]$
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 05:14:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 2 Jan 2018 05:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3484) Nonintuitive error message
 when for loop is used inside of if/try/batch constructs
In-Reply-To: <JIRA.12725648.1513696168000@Atlassian.JIRA>
References: <JIRA.12725648.1513696168000@Atlassian.JIRA>
	<JIRA.12725648.1513696168000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725648.1513696168000.19267.1514888040223@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise moved WFLY-9621 to WFCORE-3484:
----------------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-3484  (was: WFLY-9621)
          Component/s: CLI
                           (was: CLI)
    Affects Version/s: 4.0.0.Alpha5
                           (was: 11.0.0.Final)


> Nonintuitive error message when for loop is used inside of if/try/batch constructs
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-3484
>                 URL: https://issues.jboss.org/browse/WFCORE-3484
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Erich Duda
>            Assignee: Jean-Francois Denise
>
> CLI enables to use for loop construct for looping over commands or operations. See WFCORE-3236 for details. Because of design limitations of CLI, using of for loop is not supported inside of if, try, for and batch constructs. However if you try to do that, error message is not intuitive in all cases and it is difficult to find out why the code does not work.
> Let's see on real examples.
> {code:title=Using for inside if}
> [standalone at embedded /] if (outcome != success) of /system-property=test:read-resource
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone at embedded /] echo $propName
> Unrecognized variable propName
> {code}
> As you can see in the example, when you write aforementioned commands into the CLI, no error is thrown until you use the variable declared in the for construct. Additionally the error message is not saying anything about that using of "for" is not allowed inside of "if".
> {code:title=Using for inside try}
> [standalone at embedded /] try
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone at embedded /] echo $propName
> Unrecognized variable propName
> {code}
> The same applies here as for "if" case.
> {code:title=Using for inside batch}
> [standalone at embedded /] batch
> [standalone at embedded / #] for propName in :read-children-names(child-type=system-property)
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> {code}
> In the batch case, the error message is better (it says that command is not available), but still it is not clear why the command is not available.
> {code:title=Using for inside for}
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> for is not allowed while in for block
> {code}
> Using of nested for loops generates nice error message which clearly explains what is wrong. All other cases should throw similar error.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 06:16:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 06:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9643) Getting Internal server error
 on exception if the rest service content type is "application/xml"
In-Reply-To: <JIRA.12726085.1514643775000@Atlassian.JIRA>
References: <JIRA.12726085.1514643775000@Atlassian.JIRA>
	<JIRA.12726085.1514643775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726085.1514643775000.19588.1514891760389@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFLY-9643:
--------------------------------
    Steps to Reproduce: 
1) create a rest service 
{code:java}
@RestController
@RequestMapping({"security/testController"})
public class TestController
{
  @RequestMapping(value={"/applicationList"}, method={org.springframework.web.bind.annotation.RequestMethod.GET}, headers={"Accept=application/xml"} , produces=MediaType.APPLICATION_JSON_VALUE)
  public TreeDataProvider getListOfApplication()
  {
    return new TreeDataProvider();
  }
}
{code}
2) Create a Spring interceptor and throw an exception
3) create a spring exception handler to return exception as json


  was:
1) create a rest service 
@RestController
@RequestMapping({"security/testController"})
public class TestController
{
  @RequestMapping(value={"/applicationList"}, method={org.springframework.web.bind.annotation.RequestMethod.GET}, headers={"Accept=application/xml"} , produces=MediaType.APPLICATION_JSON_VALUE)
  public TreeDataProvider getListOfApplication()
  {
    return new TreeDataProvider();
  }
}
2) Create a Spring interceptor and throw an exception
3) create a spring exception handler to return exception as json




> Getting Internal server error on exception if the rest service content type is "application/xml"
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9643
>                 URL: https://issues.jboss.org/browse/WFLY-9643
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>            Reporter: Gopal krishna
>            Assignee: Alessio Soldano
>
> We are getting Internal server error if any exception is thrown from spring interceptor  when rest API header is set as "application/xml". This works if the rest API header is set as "application/json".
> we didnt see this issue in jboss 7 and  WAS



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 06:29:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 2 Jan 2018 06:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3484) Nonintuitive error message
 when for loop is used inside of if/try/batch constructs
In-Reply-To: <JIRA.12725648.1513696168000@Atlassian.JIRA>
References: <JIRA.12725648.1513696168000@Atlassian.JIRA>
	<JIRA.12725648.1513696168000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725648.1513696168000.19774.1514892540217@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508456#comment-13508456 ] 

Jean-Francois Denise commented on WFCORE-3484:
----------------------------------------------

You have revealed multiple issues there:
1) Variables can't be set and used inside if/try/for.
For example:
if (outcome != success) of /system-property=test:read-resource
set foo=bar
echo $foo

==> You will get an exception. This is the same exception that you are getting when echoing propName

2) There is no check when a redirection is already active and a new redirection is used:e.g.: try followed by if, if followed by if, ... The CLI accepts the new redirection silently.

3) Command name completion is not helpful, although a redirection is active (eg: if), other redirections are proposed (try, for).


> Nonintuitive error message when for loop is used inside of if/try/batch constructs
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-3484
>                 URL: https://issues.jboss.org/browse/WFCORE-3484
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Erich Duda
>            Assignee: Jean-Francois Denise
>
> CLI enables to use for loop construct for looping over commands or operations. See WFCORE-3236 for details. Because of design limitations of CLI, using of for loop is not supported inside of if, try, for and batch constructs. However if you try to do that, error message is not intuitive in all cases and it is difficult to find out why the code does not work.
> Let's see on real examples.
> {code:title=Using for inside if}
> [standalone at embedded /] if (outcome != success) of /system-property=test:read-resource
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone at embedded /] echo $propName
> Unrecognized variable propName
> {code}
> As you can see in the example, when you write aforementioned commands into the CLI, no error is thrown until you use the variable declared in the for construct. Additionally the error message is not saying anything about that using of "for" is not allowed inside of "if".
> {code:title=Using for inside try}
> [standalone at embedded /] try
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone at embedded /] echo $propName
> Unrecognized variable propName
> {code}
> The same applies here as for "if" case.
> {code:title=Using for inside batch}
> [standalone at embedded /] batch
> [standalone at embedded / #] for propName in :read-children-names(child-type=system-property)
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> {code}
> In the batch case, the error message is better (it says that command is not available), but still it is not clear why the command is not available.
> {code:title=Using for inside for}
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> for is not allowed while in for block
> {code}
> Using of nested for loops generates nice error message which clearly explains what is wrong. All other cases should throw similar error.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:07 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1946) DMN Editor
In-Reply-To: <JIRA.12696991.1497281558000@Atlassian.JIRA>
References: <JIRA.12696991.1497281558000@Atlassian.JIRA>
	<JIRA.12696991.1497281558000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696991.1497281558000.20270.1514898187683@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1946:
-----------------------------------
    Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52)


> DMN Editor
> ----------
>
>                 Key: DROOLS-1946
>                 URL: https://issues.jboss.org/browse/DROOLS-1946
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>              Labels: UX
>             Fix For: 7.6.0.Final
>
>
> Place holder for all DMN Editor related activities



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:10 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1825) [Guided Decision Table]
 Ability to change HIT policy in a decision table anytime
In-Reply-To: <JIRA.12697420.1497441043000@Atlassian.JIRA>
References: <JIRA.12697420.1497441043000@Atlassian.JIRA>
	<JIRA.12697420.1497441043000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12697420.1497441043000.20347.1514898190021@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1825:
-----------------------------------
    Sprint: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52)


> [Guided Decision Table] Ability to change HIT policy in a decision table anytime
> --------------------------------------------------------------------------------
>
>                 Key: DROOLS-1825
>                 URL: https://issues.jboss.org/browse/DROOLS-1825
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.1.0.Beta2
>            Reporter: Ivo Bek
>            Assignee: Toni Rikkola
>            Priority: Critical
>              Labels: UX
>         Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png, GDTAnalysis at 2x.png, GDTColumns at 2x.png
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy.
> Thus, it should be possible to change HIT policy in a decision table anytime.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:10 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1609) Augment FEEL AST node at
 compilation with return type
In-Reply-To: <JIRA.12696318.1496844128000@Atlassian.JIRA>
References: <JIRA.12696318.1496844128000@Atlassian.JIRA>
	<JIRA.12696318.1496844128000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696318.1496844128000.20354.1514898190269@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1609:
-----------------------------------
    Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52)


> Augment FEEL AST node at compilation with return type
> -----------------------------------------------------
>
>                 Key: DROOLS-1609
>                 URL: https://issues.jboss.org/browse/DROOLS-1609
>             Project: Drools
>          Issue Type: Enhancement
>          Components: dmn engine
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>            Priority: Minor
>
> This is needed so to be able to determine the result of a boxed function at compile time, in turn to be able at compile time to determine a valid compilation without error of a BKM for instance.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:10 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2175) [Guided Decision Table
 Graph] Refresh after removal of table
In-Reply-To: <JIRA.12711378.1505221805000@Atlassian.JIRA>
References: <JIRA.12711378.1505221805000@Atlassian.JIRA>
	<JIRA.12711378.1505221805000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12711378.1505221805000.20360.1514898190412@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2175?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2175:
-----------------------------------
    Sprint: 2017 Week 36-37, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 36-37, 2017 Week 49-50, 2017 Week 51-52)


> [Guided Decision Table Graph] Refresh after removal of table
> ------------------------------------------------------------
>
>                 Key: DROOLS-2175
>                 URL: https://issues.jboss.org/browse/DROOLS-2175
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.3.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>            Priority: Minor
>
> There are two problem after removal one of linked tables. For more details see Steps to Reproduce.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:10 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1959) [DMN Editor] Extend
 marshaller support for Expressions
In-Reply-To: <JIRA.12705255.1501234063000@Atlassian.JIRA>
References: <JIRA.12705255.1501234063000@Atlassian.JIRA>
	<JIRA.12705255.1501234063000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12705255.1501234063000.20365.1514898190564@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1959:
-----------------------------------
    Sprint: 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52)


> [DMN Editor] Extend marshaller support for Expressions
> ------------------------------------------------------
>
>                 Key: DROOLS-1959
>                 URL: https://issues.jboss.org/browse/DROOLS-1959
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>
> When UI support for DMN Expression is available, the marshaller shall be extended to support marshalling between DMN xml and the stunner representation of the expression.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:11 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1701) FEEL code generation and
	compilation
In-Reply-To: <JIRA.12707146.1502459679000@Atlassian.JIRA>
References: <JIRA.12707146.1502459679000@Atlassian.JIRA>
	<JIRA.12707146.1502459679000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12707146.1502459679000.20387.1514898191083@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1701:
-----------------------------------
    Sprint: 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52)


> FEEL code generation and compilation
> ------------------------------------
>
>                 Key: DROOLS-1701
>                 URL: https://issues.jboss.org/browse/DROOLS-1701
>             Project: Drools
>          Issue Type: Task
>          Components: dmn engine
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:11 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1795) [Guided Decision Table]
 Invalid error message when renaming bound variable name in conditional BRL
 column.
In-Reply-To: <JIRA.12712612.1505924833000@Atlassian.JIRA>
References: <JIRA.12712612.1505924833000@Atlassian.JIRA>
	<JIRA.12712612.1505924833000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712612.1505924833000.20410.1514898191653@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1795:
-----------------------------------
    Sprint: 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52)


> [Guided Decision Table] Invalid error message when renaming bound variable name in conditional BRL column.
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1795
>                 URL: https://issues.jboss.org/browse/DROOLS-1795
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.0.0.Final
>            Reporter: Mark Coble
>            Assignee: Mark Coble
>            Priority: Minor
>             Fix For: 7.0.0.Final
>
>         Attachments: guvnor-3507.png
>
>
> If a condition BRL column is added to a DT with bound variables that are used in an action column and that variable name is subsequently changed, the attached error message occurs when updating the action column with the new variable name.   In the attached message the original variable name is 'app'.  Hitting 'ok' returns you to the DT which has actually refactored the DT with the new variable name and validation is successful.  



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:12 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1767) FEEL: add compile-time
	cycle detection
In-Reply-To: <JIRA.12716806.1508243245000@Atlassian.JIRA>
References: <JIRA.12716806.1508243245000@Atlassian.JIRA>
	<JIRA.12716806.1508243245000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12716806.1508243245000.20432.1514898192221@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1767:
-----------------------------------
    Sprint: 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52)


> FEEL: add compile-time cycle detection 
> ---------------------------------------
>
>                 Key: DROOLS-1767
>                 URL: https://issues.jboss.org/browse/DROOLS-1767
>             Project: Drools
>          Issue Type: Enhancement
>          Components: dmn engine
>    Affects Versions: 7.4.1.Final
>            Reporter: Fedor Gavrilov
>            Assignee: Fedor Gavrilov
>            Priority: Minor
>
> Similar to what's done in https://issues.jboss.org/browse/DROOLS-1730 but during validation stage



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:12 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1770) More FEEL runtime cycle
	detection tests
In-Reply-To: <JIRA.12717263.1508421834000@Atlassian.JIRA>
References: <JIRA.12717263.1508421834000@Atlassian.JIRA>
	<JIRA.12717263.1508421834000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12717263.1508421834000.20441.1514898192425@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1770:
-----------------------------------
    Sprint: 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52)


> More FEEL runtime cycle detection tests
> ---------------------------------------
>
>                 Key: DROOLS-1770
>                 URL: https://issues.jboss.org/browse/DROOLS-1770
>             Project: Drools
>          Issue Type: Enhancement
>          Components: dmn engine
>    Affects Versions: 7.4.1.Final
>            Reporter: Fedor Gavrilov
>            Assignee: Fedor Gavrilov
>            Priority: Minor
>
> Runtime cycle detecton lacks tests for false positive, such as deadly diamond topology:
> A depends on B and C
> B and C depend on D



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:12 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2109) [XLS Decision Table] New
 Asset Dialogue misses descriptions
In-Reply-To: <JIRA.12719362.1509700869000@Atlassian.JIRA>
References: <JIRA.12719362.1509700869000@Atlassian.JIRA>
	<JIRA.12719362.1509700869000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719362.1509700869000.20444.1514898192508@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2109:
-----------------------------------
    Sprint: 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52)


> [XLS Decision Table] New Asset Dialogue misses descriptions
> -----------------------------------------------------------
>
>                 Key: DROOLS-2109
>                 URL: https://issues.jboss.org/browse/DROOLS-2109
>             Project: Drools
>          Issue Type: Bug
>          Components: XLS Decision Table Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>         Attachments: Screenshot from 2017-11-03 10-20-21.png
>
>
> The attached dialogue shows missing descriptions for table format and file selector.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:12 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2161) Recursive function
 definitions in context entries are raising compile time errors
In-Reply-To: <JIRA.12723195.1512187777000@Atlassian.JIRA>
References: <JIRA.12723195.1512187777000@Atlassian.JIRA>
	<JIRA.12723195.1512187777000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723195.1512187777000.20453.1514898192779@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2161?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2161:
-----------------------------------
    Sprint: 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 49-50, 2017 Week 51-52)


> Recursive function definitions in context entries are raising compile time errors
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-2161
>                 URL: https://issues.jboss.org/browse/DROOLS-2161
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>    Affects Versions: 7.4.1.Final
>            Reporter: Edson Tirelli
>            Assignee: Fedor Gavrilov
>         Attachments: ContextRecursion.dmn
>
>
> Recursive function definitions in contexts are raising compile time errors but are executing correctly.
> See attached model for example. Functions "f" and "h" raise compile time errors.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:12 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2149) Row and column can be added
 to read only table
In-Reply-To: <JIRA.12722092.1511432878000@Atlassian.JIRA>
References: <JIRA.12722092.1511432878000@Atlassian.JIRA>
	<JIRA.12722092.1511432878000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722092.1511432878000.20457.1514898192865@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2149?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2149:
-----------------------------------
    Sprint: 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 49-50, 2017 Week 51-52)


> Row and column can be added to read only table
> ----------------------------------------------
>
>                 Key: DROOLS-2149
>                 URL: https://issues.jboss.org/browse/DROOLS-2149
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.4.1.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>            Priority: Minor
>             Fix For: 7.6.0.Final
>
>
> The options for adding row or column into guided decision table are not disabled correctly in special case.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:13 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2181) Icons (Edit, Collapse,
 Delete etc) do not respond to mouse clicks
In-Reply-To: <JIRA.12725260.1513341217000@Atlassian.JIRA>
References: <JIRA.12725260.1513341217000@Atlassian.JIRA>
	<JIRA.12725260.1513341217000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725260.1513341217000.20476.1514898193338@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2181:
-----------------------------------
    Sprint: 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 49-50, 2017 Week 51-52)


> Icons (Edit, Collapse, Delete etc) do not respond to mouse clicks
> -----------------------------------------------------------------
>
>                 Key: DROOLS-2181
>                 URL: https://issues.jboss.org/browse/DROOLS-2181
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Tree Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> - Double-click on a node (object/action) to edit/delete/collapse.
> - Pop-up shows the icons/buttons.
> - Click on Edit/Delete/collapse icon. Icons are frozen.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:13 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2200) NPE when structured DT
 output field is null
In-Reply-To: <JIRA.12726073.1514468191000@Atlassian.JIRA>
References: <JIRA.12726073.1514468191000@Atlassian.JIRA>
	<JIRA.12726073.1514468191000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726073.1514468191000.20489.1514898193629@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2200?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2200:
-----------------------------------
    Sprint: 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 51-52)


> NPE when structured DT output field is null
> -------------------------------------------
>
>                 Key: DROOLS-2200
>                 URL: https://issues.jboss.org/browse/DROOLS-2200
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>         Attachments: image-2017-12-28-14-36-21-072.png
>
>
> When a DMN Decision Table output is structured, and one of the field of the output structure is assigned a null value, throws NPE
>  !image-2017-12-28-14-36-21-072.png|thumbnail! 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:03:13 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Tue, 2 Jan 2018 08:03:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2201) DMN runtime typecheck not
 managed for context and DT output
In-Reply-To: <JIRA.12726075.1514474021000@Atlassian.JIRA>
References: <JIRA.12726075.1514474021000@Atlassian.JIRA>
	<JIRA.12726075.1514474021000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726075.1514474021000.20492.1514898193695@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2201?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2201:
-----------------------------------
    Sprint: 2017 Week 51-52, 2018 Week 01-02  (was: 2017 Week 51-52)


> DMN runtime typecheck not managed for context and DT output
> -----------------------------------------------------------
>
>                 Key: DROOLS-2201
>                 URL: https://issues.jboss.org/browse/DROOLS-2201
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>         Attachments: screenshot-1.png, screenshot-2.png
>
>
> A Context result (last line)
> and
> A Decision Table output column
> are not obliging to the configuration for runtime typecheck.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:31:00 2018
From: issues at jboss.org (Katerina Novotna (JIRA))
Date: Tue, 2 Jan 2018 08:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9644) Wildfly 11 can't deploy
 simple REST web service because it can't find javax.ws.rs.core.Application
In-Reply-To: <JIRA.12726089.1514762045000@Atlassian.JIRA>
References: <JIRA.12726089.1514762045000@Atlassian.JIRA>
	<JIRA.12726089.1514762045000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726089.1514762045000.20622.1514899860616@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Katerina Novotna updated WFLY-9644:
-----------------------------------
    Attachment: test-app.zip


> Wildfly 11 can't deploy simple REST web service because it can't find javax.ws.rs.core.Application
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9644
>                 URL: https://issues.jboss.org/browse/WFLY-9644
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 11.0.0.Final
>         Environment: Ubuntu 16.04, JDK 1.8
>            Reporter: Dean Schulze
>            Assignee: Alessio Soldano
>         Attachments: test-app.zip
>
>
> Simple JAX-RS .war file with an Application .class file (extends javax.ws.rs.core.Application) and one resource .class file.  No web.xml file.  Deploying gives this error:
> Cannot upload deployment: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.pdfupload.POST_MODULE" => "WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"pdfupload\" Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYRS0006: Could not load JAX-RS Application class Caused by: java.lang.ClassNotFoundException: pdf.upload.server.PdfUploadApplication from [Module \"deployment.pdfupload\" from Service Module Loader]"}}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:33:00 2018
From: issues at jboss.org (Katerina Novotna (JIRA))
Date: Tue, 2 Jan 2018 08:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9644) Wildfly 11 can't deploy
 simple REST web service because it can't find javax.ws.rs.core.Application
In-Reply-To: <JIRA.12726089.1514762045000@Atlassian.JIRA>
References: <JIRA.12726089.1514762045000@Atlassian.JIRA>
	<JIRA.12726089.1514762045000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726089.1514762045000.20635.1514899980556@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508508#comment-13508508 ] 

Katerina Novotna commented on WFLY-9644:
----------------------------------------

I couldn't reproduce the issue. The deployment of the test application with empty subclass of javax.ws.rs.core.Application deploys without issues. Test app attached. 

> Wildfly 11 can't deploy simple REST web service because it can't find javax.ws.rs.core.Application
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9644
>                 URL: https://issues.jboss.org/browse/WFLY-9644
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 11.0.0.Final
>         Environment: Ubuntu 16.04, JDK 1.8
>            Reporter: Dean Schulze
>            Assignee: Alessio Soldano
>         Attachments: test-app.zip
>
>
> Simple JAX-RS .war file with an Application .class file (extends javax.ws.rs.core.Application) and one resource .class file.  No web.xml file.  Deploying gives this error:
> Cannot upload deployment: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.pdfupload.POST_MODULE" => "WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"pdfupload\" Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYRS0006: Could not load JAX-RS Application class Caused by: java.lang.ClassNotFoundException: pdf.upload.server.PdfUploadApplication from [Module \"deployment.pdfupload\" from Service Module Loader]"}}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 08:42:01 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2152) JDK9: Upgrade mockito,
 gwtmockito and powermock
In-Reply-To: <JIRA.12722193.1511467645000@Atlassian.JIRA>
References: <JIRA.12722193.1511467645000@Atlassian.JIRA>
	<JIRA.12722193.1511467645000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722193.1511467645000.20784.1514900521897@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2152?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-2152:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> JDK9: Upgrade mockito, gwtmockito and powermock
> -----------------------------------------------
>
>                 Key: DROOLS-2152
>                 URL: https://issues.jboss.org/browse/DROOLS-2152
>             Project: Drools
>          Issue Type: Component Upgrade
>          Components: build
>    Affects Versions: 7.4.1.Final
>            Reporter: Petr ?irok?
>
> Currently used versions of mockito (1.10.19), gwtmockito (1.1.6) and powermock (1.6.3) are _not_ compatible with Java 9. All of these need to upgraded, ideally all at once as they rely on each other and e.g. mockito 2.x does not work with powermock 1.x and vice versa.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:42:02 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:42:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2058) Remove hardcoded
 Thread.sleeps() in indexing tests
In-Reply-To: <JIRA.12615114.1460638315000@Atlassian.JIRA>
References: <JIRA.12615114.1460638315000@Atlassian.JIRA>
	<JIRA.12615114.1460638315000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12615114.1460638315000.20787.1514900522032@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-2058:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> Remove hardcoded Thread.sleeps() in indexing tests
> --------------------------------------------------
>
>                 Key: DROOLS-2058
>                 URL: https://issues.jboss.org/browse/DROOLS-2058
>             Project: Drools
>          Issue Type: Task
>          Components: Impact Analysis
>            Reporter: Petr ?irok?
>
> There are guvnor/kie-wb-common/drools-wb modules which contain hardcoded waits (Thread.sleeps()) to make sure the backend indexes the files. This needs to be removed and handled different without those waits.
> List of affected modules (will be updated over time):
> kie-wb-common-refactoring-backend
> Why we need to fix this?
> The tests take way too much time. It is great pain to run those tests locally as they spent most of the time just doing nothing and waiting.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:43:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1781) Investigate possible
 replacement of findbugs-maven-plugin with spotbugs-maven-plugin
In-Reply-To: <JIRA.12718339.1509028378000@Atlassian.JIRA>
References: <JIRA.12718339.1509028378000@Atlassian.JIRA>
	<JIRA.12718339.1509028378000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718339.1509028378000.20789.1514900580508@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1781?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1781:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> Investigate possible replacement of findbugs-maven-plugin with spotbugs-maven-plugin
> ------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1781
>                 URL: https://issues.jboss.org/browse/DROOLS-1781
>             Project: Drools
>          Issue Type: Task
>          Components: build
>    Affects Versions: 7.4.1.Final
>            Reporter: Petr ?irok?
>              Labels: java9
>
> SpotBugs is a successor of FingBugs and as such uses different groupId + artifactId for maven plugin. It should also be compatible with Java 9 (at least in the latest versions). We need to investigate it the switch is painless and if so, do it. Otherwise we need to figure out what the blockers are and slowly start to fix them as FindBugs itself won't bet any more updates it seems and so won't be Java 9 compatible.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:43:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1777) JDK9 and GWT: it should be
 possible to build workbench/appformer/errai with JDK 9 (even though target
 is JDK 8)
In-Reply-To: <JIRA.12718235.1509007190000@Atlassian.JIRA>
References: <JIRA.12718235.1509007190000@Atlassian.JIRA>
	<JIRA.12718235.1509007190000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718235.1509007190000.20792.1514900580602@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1777?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1777:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> JDK9 and GWT: it should be possible to build workbench/appformer/errai with JDK 9 (even though target is JDK 8)
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1777
>                 URL: https://issues.jboss.org/browse/DROOLS-1777
>             Project: Drools
>          Issue Type: Feature Request
>            Reporter: Geoffrey De Smet
>            Priority: Critical
>
> Petr will do initial experiment, reassign to probably Max to investigate further afterwards.
> *If GWT does not build on JDK 9, then the engines can't have module-info.java files without a lot of pain.*
> GWT 2.8.2 is suppose to support JDK 9 (thanks Tibor):
>   http://www.gwtproject.org/release-notes.html#Release_Notes_2_8_2http://www.gwtproject.org/release-notes.html#Release_Notes_2_8_2



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:43:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1449) Confusing error messages in
 certain combination of invalid type declerations/imports
In-Reply-To: <JIRA.12678520.1487854956000@Atlassian.JIRA>
References: <JIRA.12678520.1487854956000@Atlassian.JIRA>
	<JIRA.12678520.1487854956000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678520.1487854956000.20795.1514900580711@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1449:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> Confusing error messages in certain combination of invalid type declerations/imports
> ------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1449
>                 URL: https://issues.jboss.org/browse/DROOLS-1449
>             Project: Drools
>          Issue Type: Feature Request
>          Components: build, tools
>    Affects Versions: 6.5.0.Final
>            Reporter: Jappie Klooster
>            Priority: Minor
>
> The following drools will make the error handling flip:
> {code:drools}
> package dialogue;
> import java.util.Unkown
> declare DefaultReply
> 	symbol:Unkown
> end
> {code}
> Will result in:
> [ERROR] Failed to execute goal org.kie:kie-maven-plugin:6.5.0.Final:build (default-build) on project salve_drools: Execution default-build of goal org.kie:kie-maven-plugin:6.5.0.Final:build failed: A required class was missing while executing org.kie:kie-maven-plugin:6.5.0.Final:build: Ljava/util/Unkown;
> [ERROR] -----------------------------------------------------
> [ERROR] realm =    extension>org.kie:kie-maven-plugin:6.5.0.Final
> [ERROR] strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> [ERROR] urls[0] = file:/home/username/.m2/repository/org/kie/kie-maven-plugin/6.5.0.Final/kie-maven-plugin-6.5.0.Final.jar
> [ERROR] urls[1] = file:/home/username/.m2/repository/org/codehaus/plexus/plexus-utils/3.0.20/plexus-utils-3.0.20.jar
> [ERROR] urls[2] = file:/home/username/.m2/repository/org/eclipse/aether/aether-util/1.0.0.v20140518/aether-util-1.0.0.v20140518.jar
> [ERROR] urls[3] = file:/home/username/.m2/repository/javax/enterprise/cdi-api/1.0-SP4/cdi-api-1.0-SP4.jar
> [ERROR] urls[4] = file:/home/username/.m2/repository/org/jboss/spec/javax/interceptor/jboss-interceptors-api_1.1_spec/1.0.1.Final/jboss-interceptors-api_1.1_spec-1.0.1.Final.jar
> [ERROR] urls[5] = file:/home/username/.m2/repository/javax/annotation/jsr250-api/1.0/jsr250-api-1.0.jar
> [ERROR] urls[6] = file:/home/username/.m2/repository/org/sonatype/sisu/sisu-guice/3.2.3/sisu-guice-3.2.3-no_aop.jar
> [ERROR] urls[7] = file:/home/username/.m2/repository/aopalliance/aopalliance/1.0/aopalliance-1.0.jar
> [ERROR] urls[8] = file:/home/username/.m2/repository/com/google/guava/guava/13.0.1/guava-13.0.1.jar
> [ERROR] urls[9] = file:/home/username/.m2/repository/org/codehaus/plexus/plexus-interpolation/1.21/plexus-interpolation-1.21.jar
> [ERROR] urls[10] = file:/home/username/.m2/repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> [ERROR] urls[11] = file:/home/username/.m2/repository/org/sonatype/plexus/plexus-cipher/1.7/plexus-cipher-1.7.jar
> [ERROR] urls[12] = file:/home/username/.m2/repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> [ERROR] urls[13] = file:/home/username/.m2/repository/org/apache/xbean/xbean-reflect/3.4/xbean-reflect-3.4.jar
> [ERROR] urls[14] = file:/home/username/.m2/repository/log4j/log4j/1.2.17/log4j-1.2.17.jar
> [ERROR] urls[15] = file:/home/username/.m2/repository/commons-logging/commons-logging-api/1.1/commons-logging-api-1.1.jar
> [ERROR] urls[16] = file:/home/username/.m2/repository/com/google/collections/google-collections/1.0/google-collections-1.0.jar
> [ERROR] urls[17] = file:/home/username/.m2/repository/junit/junit/4.12/junit-4.12.jar
> [ERROR] urls[18] = file:/home/username/.m2/repository/org/hamcrest/hamcrest-core/1.3/hamcrest-core-1.3.jar
> [ERROR] urls[19] = file:/home/username/.m2/repository/com/google/protobuf/protobuf-java/2.6.0/protobuf-java-2.6.0.jar
> [ERROR] urls[20] = file:/home/username/.m2/repository/org/drools/drools-core/6.5.0.Final/drools-core-6.5.0.Final.jar
> [ERROR] urls[21] = file:/home/username/.m2/repository/org/mvel/mvel2/2.2.8.Final/mvel2-2.2.8.Final.jar
> [ERROR] urls[22] = file:/home/username/.m2/repository/commons-codec/commons-codec/1.4/commons-codec-1.4.jar
> [ERROR] urls[23] = file:/home/username/.m2/repository/org/drools/drools-compiler/6.5.0.Final/drools-compiler-6.5.0.Final.jar
> [ERROR] urls[24] = file:/home/username/.m2/repository/org/antlr/antlr-runtime/3.5/antlr-runtime-3.5.jar
> [ERROR] urls[25] = file:/home/username/.m2/repository/org/eclipse/jdt/core/compiler/ecj/4.4.2/ecj-4.4.2.jar
> [ERROR] urls[26] = file:/home/username/.m2/repository/com/thoughtworks/xstream/xstream/1.4.9/xstream-1.4.9.jar
> [ERROR] urls[27] = file:/home/username/.m2/repository/xmlpull/xmlpull/1.1.3.1/xmlpull-1.1.3.1.jar
> [ERROR] urls[28] = file:/home/username/.m2/repository/xpp3/xpp3_min/1.1.4c/xpp3_min-1.1.4c.jar
> [ERROR] urls[29] = file:/home/username/.m2/repository/org/kie/kie-api/6.5.0.Final/kie-api-6.5.0.Final.jar
> [ERROR] urls[30] = file:/home/username/.m2/repository/org/kie/kie-internal/6.5.0.Final/kie-internal-6.5.0.Final.jar
> [ERROR] urls[31] = file:/home/username/.m2/repository/org/drools/drools-decisiontables/6.5.0.Final/drools-decisiontables-6.5.0.Final.jar
> [ERROR] urls[32] = file:/home/username/.m2/repository/org/apache/poi/poi-ooxml/3.13/poi-ooxml-3.13.jar
> [ERROR] urls[33] = file:/home/username/.m2/repository/org/apache/poi/poi-ooxml-schemas/3.13/poi-ooxml-schemas-3.13.jar
> [ERROR] urls[34] = file:/home/username/.m2/repository/org/apache/xmlbeans/xmlbeans/2.3.0/xmlbeans-2.3.0.jar
> [ERROR] urls[35] = file:/home/username/.m2/repository/stax/stax-api/1.0.1/stax-api-1.0.1.jar
> [ERROR] urls[36] = file:/home/username/.m2/repository/org/apache/poi/poi/3.13/poi-3.13.jar
> [ERROR] urls[37] = file:/home/username/.m2/repository/org/drools/drools-templates/6.5.0.Final/drools-templates-6.5.0.Final.jar
> [ERROR] urls[38] = file:/home/username/.m2/repository/org/drools/drools-scorecards/6.5.0.Final/drools-scorecards-6.5.0.Final.jar
> [ERROR] urls[39] = file:/home/username/.m2/repository/org/drools/drools-pmml/6.5.0.Final/drools-pmml-6.5.0.Final.jar
> [ERROR] urls[40] = file:/home/username/.m2/repository/com/sun/xml/bind/jaxb-impl/2.2.11/jaxb-impl-2.2.11.jar
> [ERROR] urls[41] = file:/home/username/.m2/repository/com/sun/xml/bind/jaxb-core/2.2.11/jaxb-core-2.2.11.jar
> [ERROR] urls[42] = file:/home/username/.m2/repository/org/jbpm/jbpm-bpmn2/6.5.0.Final/jbpm-bpmn2-6.5.0.Final.jar
> [ERROR] urls[43] = file:/home/username/.m2/repository/org/jbpm/jbpm-flow-builder/6.5.0.Final/jbpm-flow-builder-6.5.0.Final.jar
> [ERROR] urls[44] = file:/home/username/.m2/repository/org/jbpm/jbpm-flow/6.5.0.Final/jbpm-flow-6.5.0.Final.jar
> [ERROR] urls[45] = file:/home/username/.m2/repository/joda-time/joda-time/1.6.2/joda-time-1.6.2.jar
> [ERROR] urls[46] = file:/home/username/.m2/repository/org/drools/drools-workbench-models-guided-dtable/6.5.0.Final/drools-workbench-models-guided-dtable-6.5.0.Final.jar
> [ERROR] urls[47] = file:/home/username/.m2/repository/org/drools/drools-workbench-models-datamodel-api/6.5.0.Final/drools-workbench-models-datamodel-api-6.5.0.Final.jar
> [ERROR] urls[48] = file:/home/username/.m2/repository/org/drools/drools-workbench-models-commons/6.5.0.Final/drools-workbench-models-commons-6.5.0.Final.jar
> [ERROR] urls[49] = file:/home/username/.m2/repository/org/apache/commons/commons-lang3/3.1/commons-lang3-3.1.jar
> [ERROR] urls[50] = file:/home/username/.m2/repository/org/drools/drools-workbench-models-guided-template/6.5.0.Final/drools-workbench-models-guided-template-6.5.0.Final.jar
> [ERROR] urls[51] = file:/home/username/.m2/repository/org/drools/drools-workbench-models-guided-scorecard/6.5.0.Final/drools-workbench-models-guided-scorecard-6.5.0.Final.jar
> [ERROR] urls[52] = file:/home/username/.m2/repository/org/slf4j/slf4j-simple/1.7.2/slf4j-simple-1.7.2.jar
> [ERROR] Number of foreign imports: 1
> [ERROR] import: Entry[import  from realm ClassRealm[maven.api, parent: null]]
> [ERROR] 
> [ERROR] -----------------------------------------------------: java.util.Unkown
> [ERROR] -> [Help 1]
> [ERROR] 
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR] 
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/PluginContainerException
> [ERROR] 
> [ERROR] After correcting the problems, you can resume the build with the command
> [ERROR]   mvn <goals> -rf :salve_drools
> ----
> If the type decleration does not use the symbol ie:
> {code:java}
> package dialogue;
> import java.util.Unkown
> declare DefaultReply
> 	symbol:String
> end
> {code}
> the error message becomes a lot better:
> [ERROR] Unable to build KieBaseModel:rules
> Error importing : 'java.util.Unkown'
> [ function parseUtteranceparseUtterance (line:-5): Only a type can be imported. java.util.Unkown resolves to a package
>  ]
> Rule Compilation error : [Rule name='Parse raw user utterence into parsed utterance (something we understand)']
>         dialogue/Rule_Parse_raw_user_utterence_into_parsed_utterance_$u40$something_we_understand$u41$1360960339.java (2:300) : Only a type can be imported. java.util.Unkown resolves to a package
>         dialogue/Rule_Parse_raw_user_utterence_into_parsed_utterance_$u40$something_we_understand$u41$1360960339.java (2:1068) : The import dialogue.ParseUtterance cannot be resolved
>         dialogue/Rule_Parse_raw_user_utterence_into_parsed_utterance_$u40$something_we_understand$u41$1360960339.java (8:1848) : The method parseUtterance(PatternDatabase, UnparsedUserUtterance, String) is undefined for the type Rule_Parse_raw_user_utterence_into_parsed_utterance_$u40$something_we_understand$u41$1360960339
> Rule Compilation error : [Rule name='Pick out the first symbol and insert it']
>         dialogue/Rule_Pick_out_the_first_symbol_and_insert_it851572034.java (2:300) : Only a type can be imported. java.util.Unkown resolves to a package
> _        [... other rules that fail (not sure if I can show them) .. ]_
> Error importing : 'dialogue.ParseUtterance.parseUtterance'
> [ERROR] Message [id=1, kieBase=rules, level=ERROR, path=model.drl, line=1, column=0
>    text=Error importing : 'java.util.Unkown']
> [ERROR] Message [id=2, kieBase=rules, level=ERROR, path=rules.drl, line=-5, column=0
>    text=[ function parseUtteranceparseUtterance (line:-5): Only a type can be imported. java.util.Unkown resolves to a package
>  ]]
> [ERROR] Message [id=3, kieBase=rules, level=ERROR, path=rules.drl, line=32, column=0
>    text=Rule Compilation error Only a type can be imported. java.util.Unkown resolves to a package
> The import dialogue.ParseUtterance cannot be resolved
> The method parseUtterance(PatternDatabase, UnparsedUserUtterance, String) is undefined for the type Rule_Parse_raw_user_utterence_into_parsed_utterance_$u40$something_we_understand$u41$1360960339]
> [ERROR] Message [id=4, kieBase=rules, level=ERROR, path=rules.drl, line=81, column=0
>    text=Rule Compilation error Only a type can be imported. java.util.Unkown resolves to a package
> The import dialogue.ParseUtterance cannot be resolved]
> [ERROR] Message [id=5, kieBase=rules, level=ERROR, path=rules.drl, line=7, column=0
>    text=Rule Compilation error Only a type can be imported. java.util.Unkown resolves to a package
> The import dialogue.ParseUtterance cannot be resolved
> The constructor DefaultReply(Symbol) is undefined]
> [ERROR] Message [id=6, kieBase=rules, level=ERROR, path=rules.drl, line=90, column=0
>    text=Rule Compilation error Only a type can be imported. java.util.Unkown resolves to a package
> The import dialogue.ParseUtterance cannot be resolved]
> [ERROR] Message [id=7, kieBase=rules, level=ERROR, path=rules.drl, line=72, column=0
>    text=Rule Compilation error Only a type can be imported. java.util.Unkown resolves to a package
> The import dialogue.ParseUtterance cannot be resolved
> The method randomLiteral(Random) is undefined for the type String]
> [ERROR] Message [id=8, kieBase=rules, level=ERROR, path=rules.drl, line=-1, column=0
>    text=Error importing : 'dialogue.ParseUtterance.parseUtterance']
> ----
> What I'm missing from the first case is the file name where the linking fails, and the line numbers where Unkown occurs. 
> It should also be much more obvious about what symbol can't be found.
> Dumping each jar that is used is not very helpful since most people will use maven. It should dump instead all the maven dependencies.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:43:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1393) Investigate why
 JpaOptLockPersistentStatefulSessionTest is failing with Hibernate 5
In-Reply-To: <JIRA.12669174.1483452990000@Atlassian.JIRA>
References: <JIRA.12669174.1483452990000@Atlassian.JIRA>
	<JIRA.12669174.1483452990000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12669174.1483452990000.20801.1514900580911@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1393?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1393:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> Investigate why JpaOptLockPersistentStatefulSessionTest is failing with Hibernate 5
> -----------------------------------------------------------------------------------
>
>                 Key: DROOLS-1393
>                 URL: https://issues.jboss.org/browse/DROOLS-1393
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>    Affects Versions: 7.0.0.Beta5
>            Reporter: Petr ?irok?
>
> After the upgrade of Hibernate from 4.x to 5.x, the test {{JpaOptLockPersistentStatefulSessionTest}} started to fail with {{org.h2.jdbc.JdbcSQLException: The object is already closed [90007-173]}}.
> We need to investigate this failure as it might be an actual bug.
> Full stacktrace:
> {code}
> 13:42:54.536 [Thread-5] WARN  o.d.persistence.PersistableRunner.rollbackTransaction:391 - Could not commit session
> java.lang.RuntimeException: Unable to commit transaction
> 	at org.drools.persistence.jta.JtaTransactionManager.commit(JtaTransactionManager.java:239) ~[classes/:na]
> 	at org.drools.persistence.PersistableRunner$TransactionInterceptor.execute(PersistableRunner.java:578) [classes/:na]
> 	at org.drools.persistence.PersistableRunner$TransactionInterceptor.execute(PersistableRunner.java:533) [classes/:na]
> 	at org.drools.core.command.impl.AbstractInterceptor.executeNext(AbstractInterceptor.java:39) [drools-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
> 	at org.drools.persistence.jpa.OptimisticLockRetryInterceptor.internalExecute(OptimisticLockRetryInterceptor.java:102) [classes/:na]
> 	at org.drools.persistence.jpa.OptimisticLockRetryInterceptor.execute(OptimisticLockRetryInterceptor.java:83) [classes/:na]
> 	at org.drools.persistence.jpa.OptimisticLockRetryInterceptor.execute(OptimisticLockRetryInterceptor.java:44) [classes/:na]
> 	at org.drools.persistence.PersistableRunner.execute(PersistableRunner.java:379) [classes/:na]
> 	at org.drools.persistence.PersistableRunner.execute(PersistableRunner.java:53) [classes/:na]
> 	at org.drools.core.runtime.InternalLocalRunner.execute(InternalLocalRunner.java:37) [drools-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
> 	at org.drools.core.runtime.InternalLocalRunner.execute(InternalLocalRunner.java:41) [drools-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
> 	at org.drools.core.command.impl.CommandBasedStatefulKnowledgeSession.setGlobal(CommandBasedStatefulKnowledgeSession.java:511) [drools-core-7.0.0-SNAPSHOT.jar:7.0.0-SNAPSHOT]
> 	at org.drools.persistence.session.JpaOptLockPersistentStatefulSessionTest$InsertAndFireThread.run(JpaOptLockPersistentStatefulSessionTest.java:128) [test-classes/:na]
> Caused by: bitronix.tm.internal.BitronixRollbackException: RuntimeException thrown during beforeCompletion cycle caused transaction rollback
> 	at bitronix.tm.BitronixTransaction.commit(BitronixTransaction.java:241) ~[btm-2.1.4.jar:2.1.4]
> 	at bitronix.tm.BitronixTransactionManager.commit(BitronixTransactionManager.java:143) ~[btm-2.1.4.jar:2.1.4]
> 	at org.drools.persistence.jta.JtaTransactionManager.commit(JtaTransactionManager.java:236) ~[classes/:na]
> 	... 12 common frames omitted
> Caused by: javax.persistence.PersistenceException: org.hibernate.exception.GenericJDBCException: could not update: [org.drools.persistence.info.SessionInfo#1]
> 	at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:147) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:155) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.internal.ExceptionConverterImpl.convert(ExceptionConverterImpl.java:162) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1434) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.internal.SessionImpl.managedFlush(SessionImpl.java:484) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.internal.SessionImpl.flushBeforeTransactionCompletion(SessionImpl.java:3190) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.internal.SessionImpl.beforeTransactionCompletion(SessionImpl.java:2404) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.engine.jdbc.internal.JdbcCoordinatorImpl.beforeTransactionCompletion(JdbcCoordinatorImpl.java:467) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.resource.transaction.backend.jta.internal.JtaTransactionCoordinatorImpl.beforeCompletion(JtaTransactionCoordinatorImpl.java:320) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.resource.transaction.backend.jta.internal.synchronization.SynchronizationCallbackCoordinatorNonTrackingImpl.beforeCompletion(SynchronizationCallbackCoordinatorNonTrackingImpl.java:47) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.resource.transaction.backend.jta.internal.synchronization.RegisteredSynchronization.beforeCompletion(RegisteredSynchronization.java:37) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at bitronix.tm.BitronixTransaction.fireBeforeCompletionEvent(BitronixTransaction.java:532) ~[btm-2.1.4.jar:2.1.4]
> 	at bitronix.tm.BitronixTransaction.commit(BitronixTransaction.java:235) ~[btm-2.1.4.jar:2.1.4]
> 	... 14 common frames omitted
> Caused by: org.hibernate.exception.GenericJDBCException: could not update: [org.drools.persistence.info.SessionInfo#1]
> 	at org.hibernate.exception.internal.StandardSQLExceptionConverter.convert(StandardSQLExceptionConverter.java:47) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.engine.jdbc.spi.SqlExceptionHelper.convert(SqlExceptionHelper.java:111) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3215) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.updateOrInsert(AbstractEntityPersister.java:3065) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3445) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.action.internal.EntityUpdateAction.execute(EntityUpdateAction.java:145) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:586) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.engine.spi.ActionQueue.executeActions(ActionQueue.java:460) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.event.internal.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:337) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.event.internal.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:39) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.internal.SessionImpl.doFlush(SessionImpl.java:1428) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	... 23 common frames omitted
> Caused by: org.h2.jdbc.JdbcSQLException: The object is already closed [90007-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331) ~[h2-1.3.173.jar:1.3.173]
> 	at org.h2.message.DbException.get(DbException.java:171) ~[h2-1.3.173.jar:1.3.173]
> 	at org.h2.message.DbException.get(DbException.java:148) ~[h2-1.3.173.jar:1.3.173]
> 	at org.h2.message.DbException.get(DbException.java:137) ~[h2-1.3.173.jar:1.3.173]
> 	at org.h2.jdbc.JdbcStatement.checkClosed(JdbcStatement.java:976) ~[h2-1.3.173.jar:1.3.173]
> 	at org.h2.jdbc.JdbcPreparedStatement.checkClosed(JdbcPreparedStatement.java:1574) ~[h2-1.3.173.jar:1.3.173]
> 	at org.h2.jdbc.JdbcStatement.checkClosed(JdbcStatement.java:952) ~[h2-1.3.173.jar:1.3.173]
> 	at org.h2.jdbc.JdbcPreparedStatement.setParameter(JdbcPreparedStatement.java:1334) ~[h2-1.3.173.jar:1.3.173]
> 	at org.h2.jdbc.JdbcPreparedStatement.setTimestamp(JdbcPreparedStatement.java:427) ~[h2-1.3.173.jar:1.3.173]
> 	at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) ~[na:na]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_112]
> 	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_112]
> 	at bitronix.tm.resource.jdbc.BaseProxyHandlerClass.invoke(BaseProxyHandlerClass.java:64) ~[btm-2.1.4.jar:2.1.4]
> 	at com.sun.proxy.$Proxy23.setTimestamp(Unknown Source) ~[na:na]
> 	at org.hibernate.type.descriptor.sql.TimestampTypeDescriptor$1.doBind(TimestampTypeDescriptor.java:56) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.type.descriptor.sql.BasicBinder.bind(BasicBinder.java:74) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:277) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.type.AbstractStandardBasicType.nullSafeSet(AbstractStandardBasicType.java:272) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.type.AbstractSingleColumnStandardBasicType.nullSafeSet(AbstractSingleColumnStandardBasicType.java:39) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.dehydrate(AbstractEntityPersister.java:2713) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	at org.hibernate.persister.entity.AbstractEntityPersister.update(AbstractEntityPersister.java:3142) ~[hibernate-core-5.2.6.Final.jar:5.2.6.Final]
> 	... 31 common frames omitted
> 	at org.drools.persistence.jta.JtaTransactionManager.commit(JtaTransactionManager.java:239)
> 	at org.drools.persistence.PersistableRunner$TransactionInterceptor.execute(PersistableRunner.java:578)
> 	at org.drools.persistence.PersistableRunner$TransactionInterceptor.execute(PersistableRunner.java:533)
> 	at org.drools.core.command.impl.AbstractInterceptor.executeNext(AbstractInterceptor.java:39)
> 	at org.drools.persistence.jpa.OptimisticLockRetryInterceptor.internalExecute(OptimisticLockRetryInterceptor.java:102)
> 	at org.drools.persistence.jpa.OptimisticLockRetryInterceptor.execute(OptimisticLockRetryInterceptor.java:83)
> 	at org.drools.persistence.jpa.OptimisticLockRetryInterceptor.execute(OptimisticLockRetryInterceptor.java:44)
> 	at org.drools.persistence.PersistableRunner.execute(PersistableRunner.java:379)
> 	at org.drools.persistence.PersistableRunner.execute(PersistableRunner.java:53)
> 	at org.drools.core.runtime.InternalLocalRunner.execute(InternalLocalRunner.java:37)
> 	at org.drools.core.runtime.InternalLocalRunner.execute(InternalLocalRunner.java:41)
> 	at org.drools.core.command.impl.CommandBasedStatefulKnowledgeSession.setGlobal(CommandBasedStatefulKnowledgeSession.java:511)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:43:01 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:43:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1380) Add JPA 2.1 support for
 kie-aries-blueprint
In-Reply-To: <JIRA.12667388.1481642978000@Atlassian.JIRA>
References: <JIRA.12667388.1481642978000@Atlassian.JIRA>
	<JIRA.12667388.1481642978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667388.1481642978000.20805.1514900581009@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1380:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> Add JPA 2.1 support for kie-aries-blueprint
> -------------------------------------------
>
>                 Key: DROOLS-1380
>                 URL: https://issues.jboss.org/browse/DROOLS-1380
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Petr ?irok?
>            Priority: Critical
>
> {{kie-aries-blueprint}} does not support JPA 2.1. It seems that even upstream Aries project does not yet support this as it still depending on 2.0 spec jars: https://github.com/apache/aries/blob/trunk/jpa/jpa-api/pom.xml#L41
> The corresponding test {{KieBlueprintjBPMPersistenceKarafIntegrationTest}} was @Ignored for now.
> We need to either drop support for persistence using Aries Blueprint or fix the integration.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:43:01 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:43:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1324) CNFE when stopping server
 with enabled scanner
In-Reply-To: <JIRA.12654096.1476173560000@Atlassian.JIRA>
References: <JIRA.12654096.1476173560000@Atlassian.JIRA>
	<JIRA.12654096.1476173560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654096.1476173560000.20809.1514900581127@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1324:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> CNFE when stopping server with enabled scanner
> ----------------------------------------------
>
>                 Key: DROOLS-1324
>                 URL: https://issues.jboss.org/browse/DROOLS-1324
>             Project: Drools
>          Issue Type: Bug
>          Components: kie server
>    Affects Versions: 6.5.0.CR2, 7.0.0.Beta2
>         Environment: Kie server 6.5.0-SNAPSHOT
>            Reporter: Karel Suta
>            Priority: Minor
>              Labels: reported-by-qe
>         Attachments: stacktrace-server.txt
>
>
> When I stop application server with Kie server containing container with started scanner, sometimes I get ClassNotFoundException, see attachment.
> This exception doesn't seem to have any affect on functionality, but still it should be resolved as it may hide some other problem.
> This exception occurs randomly, you may need to start/stop server several times to see it.
> Interesting is that class, which wasn't found by classloader, is actually present in Kie server in artefact sisu-guice-3.2.3-no_aop.jar.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:44:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1217) JDK 9 on drools with
 module-info: prove that drools-core and drools-compiler works in a 100%
 module-info.java environment (take them out of the "special" module)
In-Reply-To: <JIRA.12634667.1466667110000@Atlassian.JIRA>
References: <JIRA.12634667.1466667110000@Atlassian.JIRA>
	<JIRA.12634667.1466667110000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12634667.1466667110000.20812.1514900640918@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1217:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> JDK 9 on drools with module-info: prove that drools-core and drools-compiler works in a 100% module-info.java environment (take them out of the "special" module)
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1217
>                 URL: https://issues.jboss.org/browse/DROOLS-1217
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>
> So far all our OpenJDK 9 tests put drools-core and drools-core in the "special" module. That's basically the anti-module for backwards compatibility. As soon as users start using module-info.java files themselves, there will be a big pressure for us to be a proper module, so to have our own module-info.java's. Because of our extended used of reflection, we need to validate this works long before OpenJDK 9 goes final, so we can still feed it back.
> Reqs:
>     Add module-info.java to core and examples jar. Compile and run with both jars on the modulepath (instead of in the special classpath module).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:44:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1213) Make it build & work on JDK9
In-Reply-To: <JIRA.12633678.1466426243000@Atlassian.JIRA>
References: <JIRA.12633678.1466426243000@Atlassian.JIRA>
	<JIRA.12633678.1466426243000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12633678.1466426243000.20814.1514900640996@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1213:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> Make it build & work on JDK9
> ----------------------------
>
>                 Key: DROOLS-1213
>                 URL: https://issues.jboss.org/browse/DROOLS-1213
>             Project: Drools
>          Issue Type: Task
>            Reporter: Petr ?irok?
>
> Parent task to track all JDK9 related work in KIE (Drools/OptaPlanner/jBPM).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:44:01 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:44:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1121) Run tests with different
 supported databases
In-Reply-To: <JIRA.12615009.1460628307000@Atlassian.JIRA>
References: <JIRA.12615009.1460628307000@Atlassian.JIRA>
	<JIRA.12615009.1460628307000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12615009.1460628307000.20827.1514900641321@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1121?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1121:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> Run tests with different supported databases
> --------------------------------------------
>
>                 Key: DROOLS-1121
>                 URL: https://issues.jboss.org/browse/DROOLS-1121
>             Project: Drools
>          Issue Type: Task
>            Reporter: Petr ?irok?
>
> Currently we only run tests with embedded H2 database, which is often not enough, because different databases do slightly different things and thus even if the code works on H2, it does not mean it will work on all supported databases.
> We need to look into testing with multiple databases, preferably using Docker containers as that way we can make sure the databases are always in a clean state (as opposed to using shared DB instances).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:44:01 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:44:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1118) Build: enforce banning of
 dependencies that only have a GPL and/or AGPL license
In-Reply-To: <JIRA.12614641.1460471928000@Atlassian.JIRA>
References: <JIRA.12614641.1460471928000@Atlassian.JIRA>
	<JIRA.12614641.1460471928000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12614641.1460471928000.20833.1514900641446@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1118?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1118:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> Build: enforce banning of dependencies that only have a GPL and/or AGPL license
> -------------------------------------------------------------------------------
>
>                 Key: DROOLS-1118
>                 URL: https://issues.jboss.org/browse/DROOLS-1118
>             Project: Drools
>          Issue Type: Feature Request
>          Components: build
>            Reporter: Geoffrey De Smet
>
> In the first phase, I 'd be happy with an exclusive approach: just ban GPL and AGPL.
> In a later phase, we probably want an inclusive approach: only list the ones that we do accept (but due to license proliferation that's not easy).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:44:01 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:44:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1105) Publish kie-aries-blueprint
 and kie-spring XSDs to drools.org
In-Reply-To: <JIRA.12611723.1458740806000@Atlassian.JIRA>
References: <JIRA.12611723.1458740806000@Atlassian.JIRA>
	<JIRA.12611723.1458740806000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12611723.1458740806000.20838.1514900641589@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1105?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1105:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> Publish kie-aries-blueprint and kie-spring XSDs to drools.org
> -------------------------------------------------------------
>
>                 Key: DROOLS-1105
>                 URL: https://issues.jboss.org/browse/DROOLS-1105
>             Project: Drools
>          Issue Type: Task
>          Components: build
>    Affects Versions: 6.4.0.CR2
>            Reporter: Petr ?irok?
>
> {{kie-aries-blueprint}} and {{kie-spring}} XSDs should be published alongside the kie-module XSD at drools.org/xsd.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:44:01 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:44:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1088) Add
 spring-jbpm-osgi-example to JBPM repository
In-Reply-To: <JIRA.12609603.1457523011000@Atlassian.JIRA>
References: <JIRA.12609603.1457523011000@Atlassian.JIRA>
	<JIRA.12609603.1457523011000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12609603.1457523011000.20842.1514900641672@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1088:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> Add spring-jbpm-osgi-example to JBPM repository
> -----------------------------------------------
>
>                 Key: DROOLS-1088
>                 URL: https://issues.jboss.org/browse/DROOLS-1088
>             Project: Drools
>          Issue Type: Feature Request
>    Affects Versions: 6.4.0.CR1
>            Reporter: David virgil naranjo
>
> The spring-jbpm-osgi-example is currently placed on Fuse-bxms-integ repository. It will be removed from this repository because it does not contain any kie-camel or another fuse-bxms-integ dependency.
> It is required to include this quickstart and its feature to the jbpm repository:
>     <feature name="fuse-bxms-spring-jbpm-osgi-example" version="${project.version}">
>         <feature version="${karaf.version.org.kie}">kie-spring</feature>
>         <bundle>mvn:org.jboss.integration.fuse.quickstarts/spring-jbpm-osgi-example/${project.version}</bundle>
>     </feature>



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:44:01 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:44:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1170) JDK9 with drools: Build:
 switch back to maven-jaxb2-plugin (but it throws ClassNotFoundException:
 com.sun.codemodel.CodeWriter)
In-Reply-To: <JIRA.12618966.1462890333000@Atlassian.JIRA>
References: <JIRA.12618966.1462890333000@Atlassian.JIRA>
	<JIRA.12618966.1462890333000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618966.1462890333000.20819.1514900641133@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1170:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> JDK9 with drools: Build: switch back to maven-jaxb2-plugin (but it throws ClassNotFoundException: com.sun.codemodel.CodeWriter)
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1170
>                 URL: https://issues.jboss.org/browse/DROOLS-1170
>             Project: Drools
>          Issue Type: Bug
>          Components: build
>            Reporter: Geoffrey De Smet
>            Priority: Minor
>              Labels: java9
>
> See
> https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/kie-all-build-master-jdk9/
> {code}
> 13:47:25 org.apache.maven.lifecycle.LifecycleExecutionException: Failed to execute goal org.codehaus.mojo:jaxb2-maven-plugin:2.2:xjc (default) on project drools-pmml: Execution default of goal org.codehaus.mojo:jaxb2-maven-plugin:2.2:xjc failed: A required class was missing while executing org.codehaus.mojo:jaxb2-maven-plugin:2.2:xjc: com/sun/codemodel/CodeWriter
> 13:47:25 -----------------------------------------------------
> 13:47:25 realm =    plugin>org.codehaus.mojo:jaxb2-maven-plugin:2.2
> 13:47:25 strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> 13:47:25 urls[0] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/mojo/jaxb2-maven-plugin/2.2/jaxb2-maven-plugin-2.2.jar
> 13:47:25 urls[1] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/javax/xml/bind/jaxb-api/2.2.11/jaxb-api-2.2.11.jar
> 13:47:25 urls[2] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-core/2.2.11/jaxb-core-2.2.11.jar
> 13:47:25 urls[3] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-runtime/2.2.11/jaxb-runtime-2.2.11.jar
> 13:47:25 urls[4] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-xjc/2.2.11/jaxb-xjc-2.2.11.jar
> 13:47:25 urls[5] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-jxc/2.2.11/jaxb-jxc-2.2.11.jar
> 13:47:25 urls[6] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/com/thoughtworks/qdox/qdox/2.0-M3/qdox-2.0-M3.jar
> 13:47:25 urls[7] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> 13:47:25 urls[8] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> 13:47:25 urls[9] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> 13:47:25 urls[10] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> 13:47:25 urls[11] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> 13:47:25 urls[12] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> 13:47:25 urls[13] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> 13:47:25 urls[14] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-compiler-api/2.5/plexus-compiler-api-2.5.jar
> 13:47:25 urls[15] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-utils/3.0.22/plexus-utils-3.0.22.jar
> 13:47:25 urls[16] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-build-api/0.0.7/plexus-build-api-0.0.7.jar
> 13:47:25 Number of foreign imports: 1
> 13:47:25 import: Entry[import  from realm ClassRealm[project>org.drools:drools:7.0.0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]
> 13:47:25 
> 13:47:25 -----------------------------------------------------
> 13:47:25 
> 13:47:25 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:224)
> 13:47:25 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:153)
> 13:47:25 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:145)
> 13:47:25 	at org.apache.maven.lifecycle.internal.LifecycleModuleBuilder.buildProject(LifecycleModuleBuilder.java:116)
> 13:47:25 	at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:188)
> 13:47:25 	at org.apache.maven.lifecycle.internal.builder.multithreaded.MultiThreadedBuilder$1.call(MultiThreadedBuilder.java:184)
> 13:47:25 	at java.util.concurrent.FutureTask.run(java.base at 9-ea/FutureTask.java:266)
> 13:47:25 	at java.util.concurrent.Executors$RunnableAdapter.call(java.base at 9-ea/Executors.java:514)
> 13:47:25 	at java.util.concurrent.FutureTask.run(java.base at 9-ea/FutureTask.java:266)
> 13:47:25 	at java.util.concurrent.ThreadPoolExecutor.runWorker(java.base at 9-ea/ThreadPoolExecutor.java:1158)
> 13:47:25 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(java.base at 9-ea/ThreadPoolExecutor.java:632)
> 13:47:25 	at java.lang.Thread.run(java.base at 9-ea/Thread.java:804)
> 13:47:25 Caused by: org.apache.maven.plugin.PluginExecutionException: Execution default of goal org.codehaus.mojo:jaxb2-maven-plugin:2.2:xjc failed: A required class was missing while executing org.codehaus.mojo:jaxb2-maven-plugin:2.2:xjc: com/sun/codemodel/CodeWriter
> 13:47:25 -----------------------------------------------------
> 13:47:25 realm =    plugin>org.codehaus.mojo:jaxb2-maven-plugin:2.2
> 13:47:25 strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> 13:47:25 urls[0] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/mojo/jaxb2-maven-plugin/2.2/jaxb2-maven-plugin-2.2.jar
> 13:47:25 urls[1] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/javax/xml/bind/jaxb-api/2.2.11/jaxb-api-2.2.11.jar
> 13:47:25 urls[2] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-core/2.2.11/jaxb-core-2.2.11.jar
> 13:47:25 urls[3] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-runtime/2.2.11/jaxb-runtime-2.2.11.jar
> 13:47:25 urls[4] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-xjc/2.2.11/jaxb-xjc-2.2.11.jar
> 13:47:25 urls[5] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-jxc/2.2.11/jaxb-jxc-2.2.11.jar
> 13:47:25 urls[6] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/com/thoughtworks/qdox/qdox/2.0-M3/qdox-2.0-M3.jar
> 13:47:25 urls[7] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> 13:47:25 urls[8] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> 13:47:25 urls[9] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> 13:47:25 urls[10] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> 13:47:25 urls[11] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> 13:47:25 urls[12] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> 13:47:25 urls[13] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> 13:47:25 urls[14] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-compiler-api/2.5/plexus-compiler-api-2.5.jar
> 13:47:25 urls[15] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-utils/3.0.22/plexus-utils-3.0.22.jar
> 13:47:25 urls[16] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-build-api/0.0.7/plexus-build-api-0.0.7.jar
> 13:47:25 Number of foreign imports: 1
> 13:47:25 import: Entry[import  from realm ClassRealm[project>org.drools:drools:7.0.0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]
> 13:47:25 
> 13:47:25 -----------------------------------------------------
> 13:47:25 
> 13:47:25 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:166)
> 13:47:25 	at org.apache.maven.lifecycle.internal.MojoExecutor.execute(MojoExecutor.java:208)
> 13:47:25 	... 11 more
> 13:47:25 Caused by: org.apache.maven.plugin.PluginContainerException: A required class was missing while executing org.codehaus.mojo:jaxb2-maven-plugin:2.2:xjc: com/sun/codemodel/CodeWriter
> 13:47:25 -----------------------------------------------------
> 13:47:25 realm =    plugin>org.codehaus.mojo:jaxb2-maven-plugin:2.2
> 13:47:25 strategy = org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy
> 13:47:25 urls[0] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/mojo/jaxb2-maven-plugin/2.2/jaxb2-maven-plugin-2.2.jar
> 13:47:25 urls[1] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/javax/xml/bind/jaxb-api/2.2.11/jaxb-api-2.2.11.jar
> 13:47:25 urls[2] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-core/2.2.11/jaxb-core-2.2.11.jar
> 13:47:25 urls[3] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-runtime/2.2.11/jaxb-runtime-2.2.11.jar
> 13:47:25 urls[4] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-xjc/2.2.11/jaxb-xjc-2.2.11.jar
> 13:47:25 urls[5] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/glassfish/jaxb/jaxb-jxc/2.2.11/jaxb-jxc-2.2.11.jar
> 13:47:25 urls[6] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/com/thoughtworks/qdox/qdox/2.0-M3/qdox-2.0-M3.jar
> 13:47:25 urls[7] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/sisu/sisu-inject-bean/1.4.2/sisu-inject-bean-1.4.2.jar
> 13:47:25 urls[8] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/sisu/sisu-guice/2.1.7/sisu-guice-2.1.7-noaop.jar
> 13:47:25 urls[9] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/aether/aether-util/1.7/aether-util-1.7.jar
> 13:47:25 urls[10] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-interpolation/1.14/plexus-interpolation-1.14.jar
> 13:47:25 urls[11] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-component-annotations/1.5.5/plexus-component-annotations-1.5.5.jar
> 13:47:25 urls[12] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-sec-dispatcher/1.3/plexus-sec-dispatcher-1.3.jar
> 13:47:25 urls[13] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-cipher/1.4/plexus-cipher-1.4.jar
> 13:47:25 urls[14] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-compiler-api/2.5/plexus-compiler-api-2.5.jar
> 13:47:25 urls[15] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/codehaus/plexus/plexus-utils/3.0.22/plexus-utils-3.0.22.jar
> 13:47:25 urls[16] = file:/home/jenkins/workspace/kie-all-build-master-jdk9/.repository/org/sonatype/plexus/plexus-build-api/0.0.7/plexus-build-api-0.0.7.jar
> 13:47:25 Number of foreign imports: 1
> 13:47:25 import: Entry[import  from realm ClassRealm[project>org.drools:drools:7.0.0-SNAPSHOT, parent: ClassRealm[maven.api, parent: null]]]
> 13:47:25 
> 13:47:25 -----------------------------------------------------
> 13:47:25 
> 13:47:25 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:164)
> 13:47:25 	... 12 more
> 13:47:25 Caused by: java.lang.NoClassDefFoundError: com/sun/codemodel/CodeWriter
> 13:47:25 	at org.codehaus.mojo.jaxb2.javageneration.AbstractJavaGeneratorMojo.performExecution(AbstractJavaGeneratorMojo.java:402)
> 13:47:25 	at org.codehaus.mojo.jaxb2.AbstractJaxbMojo.execute(AbstractJaxbMojo.java:257)
> 13:47:25 	at org.apache.maven.plugin.DefaultBuildPluginManager.executeMojo(DefaultBuildPluginManager.java:132)
> 13:47:25 	... 12 more
> 13:47:25 Caused by: java.lang.ClassNotFoundException: com.sun.codemodel.CodeWriter
> 13:47:25 	at org.codehaus.plexus.classworlds.strategy.SelfFirstStrategy.loadClass(SelfFirstStrategy.java:50)
> 13:47:25 	at org.codehaus.plexus.classworlds.realm.ClassRealm.unsynchronizedLoadClass(ClassRealm.java:259)
> 13:47:25 	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:235)
> 13:47:25 	at org.codehaus.plexus.classworlds.realm.ClassRealm.loadClass(ClassRealm.java:227)
> 13:47:25 	... 15 more
> {code}
> Looks like we need a newer version of the maven-jaxb2-plugin.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:45:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 2 Jan 2018 08:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1474) GssapiCompatibilitySuiteChild
 fails on solaris
In-Reply-To: <JIRA.12726223.1514900642000@Atlassian.JIRA>
References: <JIRA.12726223.1514900642000@Atlassian.JIRA>
	<JIRA.12726223.1514900642662@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726223.1514900642000.20843.1514900700444@Atlassian.JIRA>

Martin Choma created ELY-1474:
---------------------------------

             Summary: GssapiCompatibilitySuiteChild fails on solaris
                 Key: ELY-1474
                 URL: https://issues.jboss.org/browse/ELY-1474
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Testsuite
            Reporter: Martin Choma
            Priority: Critical
             Fix For: 1.2.0.Beta12



- On same java (Oracle java) test does not fail on other OS
- We don't test other javas on solaris OS

Problem is on line comparing expected sasl message witch actual.

{code:java|title=GssapiCompatibilitySuiteChild}
exchange = evaluateByClient(exchange);
        assertEquals(" ", ByteIterator.ofBytes(exchange).hexEncode().drainToString());
{code}

Stacktrace
{noformat}
org.junit.ComparisonFailure: expected:<...03020110a281bf0481bc[ ]> but was:<...03020110a281bf0481bc[ ]>
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:121)
{noformat}

Log
{noformat}
19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:52> loginClient
Debug is  true storeKey true useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is true principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Refreshing Kerberos configuration
		[Krb5LoginModule] user entered username: jduke

principal is jduke at WILDFLY.ORG
EncryptionKey: keyType=16 keyBytes (hex dump)=0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;

Added server's keyKerberos Principal jduke at WILDFLY.ORGKey Version 0key EncryptionKey: keyType=16 keyBytes (hex dump)=
0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;


		[Krb5LoginModule] added Krb5Principal  jduke at WILDFLY.ORG to Subject
Commit Succeeded 

19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:57> loginServer
Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator false KeyTab is /mnt/hudson_workspace/workspace/wildfly-elytron-unit-tests/20ff21f6/wildfly-elytron/./target/apache-ds/working/serverKeyTab refreshKrb5Config is true principal is sasl/test_server_1 tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Refreshing Kerberos configuration
principal is sasl/test_server_1 at WILDFLY.ORG
Will use keytab
Commit Succeeded 

19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:68> Acceptor Name 'sasl at test_server_1'
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:100> CallbackHandler does not support CredentialCallback: javax.security.auth.callback.UnsupportedCallbackException
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$NoCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:421)
	at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:120)
	at org.wildfly.security.sasl.gssapi.GssapiClient.<init>(GssapiClient.java:93)
	at org.wildfly.security.sasl.gssapi.GssapiClientFactory.createSaslClient(GssapiClientFactory.java:42)
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$0(GssapiCompatibilitySuiteChild.java:103)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:422)
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:97)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runners.Suite.runChild(Suite.java:128)
	at org.junit.runners.Suite.runChild(Suite.java:27)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)

19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:119> Delegating credential = false
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:140> Setting requering mutual authentication to true
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:74> Obtaining GSSCredential for the service from callback handler...
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:80> Unable to obtain GSSCredential from CallbackHandler: javax.security.auth.callback.UnsupportedCallbackException
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$AuthorizeOnlyCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:413)
	at org.wildfly.security.sasl.gssapi.GssapiServer.<init>(GssapiServer.java:75)
	at org.wildfly.security.sasl.gssapi.GssapiServerFactory.createSaslServer(GssapiServerFactory.java:44)
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$1(GssapiCompatibilitySuiteChild.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:422)
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:106)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runners.Suite.runChild(Suite.java:128)
	at org.junit.runners.Suite.runChild(Suite.java:27)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)

19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:87> Our name 'sasl at test_server_1'
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:229> GSSContext not established, expecting subsequent exchanges.
{noformat}

[1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/jdk=java18_default,label=eap-sustaining&&solaris11&&x86_64/testReport/-sustaining&&solaris10&&sparc/testReport
[2] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/testReport/




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:45:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1066) Remove not needed "wrap"s
 in drools-karaf-features
In-Reply-To: <JIRA.12607253.1456225154000@Atlassian.JIRA>
References: <JIRA.12607253.1456225154000@Atlassian.JIRA>
	<JIRA.12607253.1456225154000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12607253.1456225154000.20845.1514900700543@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1066?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1066:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> Remove not needed "wrap"s in drools-karaf-features
> --------------------------------------------------
>
>                 Key: DROOLS-1066
>                 URL: https://issues.jboss.org/browse/DROOLS-1066
>             Project: Drools
>          Issue Type: Enhancement
>          Components: integration
>    Affects Versions: 6.4.0.Beta1
>            Reporter: Petr ?irok?
>
> drools-karaf-features (https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-features/src/main/filtered-resources/repository/features.xml) use wrap protocol for bundles where it should not be needed (e.g. for other KIE artifacts which should already contain OSGi metadata). The file needs to be reviewed and all useless wraps have to be removed (they only make things more confusing).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:45:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1027) Replace
 org.apache.genonimo.specs with org.jboss.specs in Karaf features file
In-Reply-To: <JIRA.12599603.1452849485000@Atlassian.JIRA>
References: <JIRA.12599603.1452849485000@Atlassian.JIRA>
	<JIRA.12599603.1452849485000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599603.1452849485000.20847.1514900700585@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1027?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-1027:
-----------------------------------

    Assignee:     (was: Petr ?irok?)


> Replace org.apache.genonimo.specs with org.jboss.specs in Karaf features file
> -----------------------------------------------------------------------------
>
>                 Key: DROOLS-1027
>                 URL: https://issues.jboss.org/browse/DROOLS-1027
>             Project: Drools
>          Issue Type: Task
>    Affects Versions: 6.3.0.Final
>            Reporter: Petr ?irok?
>
> Drools karaf features (https://github.com/droolsjbpm/droolsjbpm-integration/blob/master/drools-osgi/drools-karaf-features/pom.xml) refer to org.apache.geronimo.specs jars. We should try to migrate to JBoss spec files as we use them everywhere else.
> We need to make sure all the JBoss specs jars are OSGi ready.
> This should be fixed once we branch to 7.x.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:45:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-850) All maven assemblies must
 use <useTransitiveFiltering>true</> for every <dependencySet>
In-Reply-To: <JIRA.12578373.1437129483000@Atlassian.JIRA>
References: <JIRA.12578373.1437129483000@Atlassian.JIRA>
	<JIRA.12578373.1437129483000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12578373.1437129483000.20850.1514900700687@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-850:
----------------------------------

    Assignee:     (was: Petr ?irok?)


> All maven assemblies must use <useTransitiveFiltering>true</> for every <dependencySet>
> ---------------------------------------------------------------------------------------
>
>                 Key: DROOLS-850
>                 URL: https://issues.jboss.org/browse/DROOLS-850
>             Project: Drools
>          Issue Type: Task
>            Reporter: Geoffrey De Smet
>            Priority: Minor
>         Attachments: drools-850.png
>
>
> When the assemblies were originally written, this option wasn't available yet. Because don't use it, we have been doing <excludes> for transitive dependencies, which have being going stale/incorrect as we've been upgrading dependency versions. it's a mess. The only sane thing to do is to use this option everywhere. As they admit, it should be the default but they couldn't:
> "<useTransitiveFiltering> Determines whether the include/exclude patterns in this dependency set will be applied to the transitive path of a given artifact. If true, and the current artifact is a transitive dependency brought in by another artifact which matches an inclusion or exclusion pattern, then the current artifact has the same inclusion/exclusion logic applied to it as well. By default, this value is false, in order to preserve backward compatibility with version 2.1. This means that includes/excludes only apply directly to the current artifact, and not to the transitive set of artifacts which brought it in. (Since 2.2-beta-1) "
> See
>   https://maven.apache.org/plugins/maven-assembly-plugin/assembly.html#class_dependencySet



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:45:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-772) Maven deploys should upload
 a PGP signature file too for final releases
In-Reply-To: <JIRA.12569758.1429948774000@Atlassian.JIRA>
References: <JIRA.12569758.1429948774000@Atlassian.JIRA>
	<JIRA.12569758.1429948774000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12569758.1429948774000.20853.1514900700751@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-772:
----------------------------------

    Assignee:     (was: Petr ?irok?)


> Maven deploys should upload a PGP signature file too for final releases
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-772
>                 URL: https://issues.jboss.org/browse/DROOLS-772
>             Project: Drools
>          Issue Type: Feature Request
>            Reporter: Alexander Kj?ll
>            Priority: Minor
>
> The jar files provided on maven doesn't have a pgp signature provided with them.
> This makes it hard to verify the authenticity of the packages that we download.
> This is a copy of #PLANNER-329 but as we depend on both projects it would be good to have this in place here also.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:45:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-760) Code style formatters are
	not up-to-date
In-Reply-To: <JIRA.12568012.1428583737000@Atlassian.JIRA>
References: <JIRA.12568012.1428583737000@Atlassian.JIRA>
	<JIRA.12568012.1428583737000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12568012.1428583737000.20858.1514900700882@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-760?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-760:
----------------------------------

    Assignee:     (was: Petr ?irok?)


> Code style formatters are not up-to-date
> ----------------------------------------
>
>                 Key: DROOLS-760
>                 URL: https://issues.jboss.org/browse/DROOLS-760
>             Project: Drools
>          Issue Type: Task
>            Reporter: Tibor Zim?nyi
>            Priority: Minor
>              Labels: reported-by-qe
>         Attachments: code-styleQE.zip
>
>
> Code style formatters in git repo are not actual. Or not widely used. This causes that different styles are used in code. 
> There should be some agreement about how the code should be written and this should be forced in PRs. This can remove many problems with whitespaces in PR diffs. 
> Attached code style templates can be used as a base for new templates that (hope) will be used in Drools projects.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:45:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-746) Window operators - Type
	safety
In-Reply-To: <JIRA.12566540.1426879705000@Atlassian.JIRA>
References: <JIRA.12566540.1426879705000@Atlassian.JIRA>
	<JIRA.12566540.1426879705000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12566540.1426879705000.20860.1514900700921@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-746:
----------------------------------

    Assignee:     (was: Petr ?irok?)


> Window operators - Type safety
> ------------------------------
>
>                 Key: DROOLS-746
>                 URL: https://issues.jboss.org/browse/DROOLS-746
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 6.2.0.Final
>         Environment: OS: Mac OS Yosemite 10.10.2
> Java: 1.7.0_75 / 1.8.0_25
>            Reporter: Wilson Akio Higashino
>
> It seems the rule compiler is not correctly checking type safety when using window operators to define rule conditions.
> I defined a rule using the following code (note that I incorrectly used "time:window" to define the window, instead of "window:time"):
> declare SensorReading
>     @role(event)
>     @timestamp(timestamp)
> end
> rule "boilers"
>     when
>         $b1: (SensorReading(sensorId == 1L && status == SensorStatus.ON) over time:window(10s)) 
>     then
>          ....
> end
> The rule has been compiled and executed, but not following the correct window semantics.  The forum link contains a full description of the (unexpected) behaviour I found when defining rule like this.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:46:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-729) Android Support
In-Reply-To: <JIRA.12564382.1424988603000@Atlassian.JIRA>
References: <JIRA.12564382.1424988603000@Atlassian.JIRA>
	<JIRA.12564382.1424988603000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12564382.1424988603000.20864.1514900760540@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-729:
----------------------------------

    Assignee:     (was: Petr ?irok?)


> Android Support
> ---------------
>
>                 Key: DROOLS-729
>                 URL: https://issues.jboss.org/browse/DROOLS-729
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 6.2.0.Final
>         Environment: Android
>            Reporter: Mark Kedzierski
>            Priority: Optional
>              Labels: Android
>
> I've done some work porting Drools 6.0.1.Final to work on Android.  My current effort uses Dex classloaders for all generated classes.  Precompiled rule packages execute on Android with either java or mvel dialect.
> code:
> http://www.github.com/kedzie/drools-android
> Features:
> -Dex classloaders for all generated classes
> -Roboguice integration for injecting knowledge bases from precompiled packages
> -Maven plugin which pre-compiles rule packages
> Issues:
> -Android 5.0 support requires change in mvel2.  android 5 doesn't allow overriding the java.version system property.  mvel needs to look for an alternate property if that one is not available.  One which can be set.  I am preparing a pull request for this.
> -using KieClasspathContainer depends on my pull request to maven-android-plugin to not strip out kmodule.xml and other meta inf resources
> -multiple kjars in dependencies will clobber each other's kmodule.xml.  as all jars are merged into a single apk.
> I am wondering how to move forward and contribute this code.  I think it would be ideal if the same codebase worked on both desktop and android platforms.  Otherwise it would need to be a seperate fork.  Also how to manage unit testing in the Android version.  Any thoughts welcome.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:46:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-708) Add checkstyle plugin config
 that bans/reports tabs for indentation + fix current sources
In-Reply-To: <JIRA.12562713.1423481458000@Atlassian.JIRA>
References: <JIRA.12562713.1423481458000@Atlassian.JIRA>
	<JIRA.12562713.1423481458000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562713.1423481458000.20866.1514900760574@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-708:
----------------------------------

    Assignee:     (was: Petr ?irok?)


> Add checkstyle plugin config that bans/reports tabs for indentation + fix current sources
> -----------------------------------------------------------------------------------------
>
>                 Key: DROOLS-708
>                 URL: https://issues.jboss.org/browse/DROOLS-708
>             Project: Drools
>          Issue Type: Task
>          Components: build
>            Reporter: Petr ?irok?
>
> Adding checkstyle plugin config that bans the tabs for indenting should make it easier to detect these errors.
> We need to decide if the plugin should be on by default or executed on demand and if want to fail the build in case some violations are found.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:46:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 2 Jan 2018 08:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1474) GssapiCompatibilitySuiteChild
 fails on solaris
In-Reply-To: <JIRA.12726223.1514900643000@Atlassian.JIRA>
References: <JIRA.12726223.1514900643000@Atlassian.JIRA>
	<JIRA.12726223.1514900643000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726223.1514900643000.20868.1514900760618@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1474:
------------------------------
    Description: 
- On same java (Oracle java) test does not fail on other OS
- We don't test other javas on solaris OS

Problem is on line comparing expected sasl message witch actual.

{code:java|title=GssapiCompatibilitySuiteChild}
exchange = evaluateByClient(exchange);
        assertEquals(" ", ByteIterator.ofBytes(exchange).hexEncode().drainToString());
{code}

Stacktrace
{noformat}
org.junit.ComparisonFailure: expected:<...03020110a281bf0481bc[ ]> but was:<...03020110a281bf0481bc[ ]>
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:121)
{noformat}

Log
{noformat}
19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:52> loginClient
Debug is  true storeKey true useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is true principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Refreshing Kerberos configuration
		[Krb5LoginModule] user entered username: jduke

principal is jduke at WILDFLY.ORG
EncryptionKey: keyType=16 keyBytes (hex dump)=0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;

Added server's keyKerberos Principal jduke at WILDFLY.ORGKey Version 0key EncryptionKey: keyType=16 keyBytes (hex dump)=
0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;


		[Krb5LoginModule] added Krb5Principal  jduke at WILDFLY.ORG to Subject
Commit Succeeded 

19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:57> loginServer
Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator false KeyTab is /mnt/hudson_workspace/workspace/wildfly-elytron-unit-tests/20ff21f6/wildfly-elytron/./target/apache-ds/working/serverKeyTab refreshKrb5Config is true principal is sasl/test_server_1 tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Refreshing Kerberos configuration
principal is sasl/test_server_1 at WILDFLY.ORG
Will use keytab
Commit Succeeded 

19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:68> Acceptor Name 'sasl at test_server_1'
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:100> CallbackHandler does not support CredentialCallback: javax.security.auth.callback.UnsupportedCallbackException
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$NoCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:421)
	at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:120)
	at org.wildfly.security.sasl.gssapi.GssapiClient.<init>(GssapiClient.java:93)
	at org.wildfly.security.sasl.gssapi.GssapiClientFactory.createSaslClient(GssapiClientFactory.java:42)
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$0(GssapiCompatibilitySuiteChild.java:103)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:422)
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:97)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runners.Suite.runChild(Suite.java:128)
	at org.junit.runners.Suite.runChild(Suite.java:27)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)

19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:119> Delegating credential = false
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:140> Setting requering mutual authentication to true
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:74> Obtaining GSSCredential for the service from callback handler...
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:80> Unable to obtain GSSCredential from CallbackHandler: javax.security.auth.callback.UnsupportedCallbackException
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$AuthorizeOnlyCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:413)
	at org.wildfly.security.sasl.gssapi.GssapiServer.<init>(GssapiServer.java:75)
	at org.wildfly.security.sasl.gssapi.GssapiServerFactory.createSaslServer(GssapiServerFactory.java:44)
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$1(GssapiCompatibilitySuiteChild.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:422)
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:106)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runners.Suite.runChild(Suite.java:128)
	at org.junit.runners.Suite.runChild(Suite.java:27)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)

19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:87> Our name 'sasl at test_server_1'
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:229> GSSContext not established, expecting subsequent exchanges.
{noformat}

[1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/jdk=java18_default,label=eap-sustaining&&solaris11&&x86_64/testReport/-sustaining&&solaris10&&sparc/testReport
[2] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/testReport/


  was:

- On same java (Oracle java) test does not fail on other OS
- We don't test other javas on solaris OS

Problem is on line comparing expected sasl message witch actual.

{code:java|title=GssapiCompatibilitySuiteChild}
exchange = evaluateByClient(exchange);
        assertEquals(" ", ByteIterator.ofBytes(exchange).hexEncode().drainToString());
{code}

Stacktrace
{noformat}
org.junit.ComparisonFailure: expected:<...03020110a281bf0481bc[ ]> but was:<...03020110a281bf0481bc[ ]>
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:121)
{noformat}

Log
{noformat}
19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:52> loginClient
Debug is  true storeKey true useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is true principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Refreshing Kerberos configuration
		[Krb5LoginModule] user entered username: jduke

principal is jduke at WILDFLY.ORG
EncryptionKey: keyType=16 keyBytes (hex dump)=0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;

Added server's keyKerberos Principal jduke at WILDFLY.ORGKey Version 0key EncryptionKey: keyType=16 keyBytes (hex dump)=
0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;


		[Krb5LoginModule] added Krb5Principal  jduke at WILDFLY.ORG to Subject
Commit Succeeded 

19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:57> loginServer
Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator false KeyTab is /mnt/hudson_workspace/workspace/wildfly-elytron-unit-tests/20ff21f6/wildfly-elytron/./target/apache-ds/working/serverKeyTab refreshKrb5Config is true principal is sasl/test_server_1 tryFirstPass is false useFirstPass is false storePass is false clearPass is false
Refreshing Kerberos configuration
principal is sasl/test_server_1 at WILDFLY.ORG
Will use keytab
Commit Succeeded 

19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:68> Acceptor Name 'sasl at test_server_1'
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:100> CallbackHandler does not support CredentialCallback: javax.security.auth.callback.UnsupportedCallbackException
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$NoCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:421)
	at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:120)
	at org.wildfly.security.sasl.gssapi.GssapiClient.<init>(GssapiClient.java:93)
	at org.wildfly.security.sasl.gssapi.GssapiClientFactory.createSaslClient(GssapiClientFactory.java:42)
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$0(GssapiCompatibilitySuiteChild.java:103)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:422)
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:97)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runners.Suite.runChild(Suite.java:128)
	at org.junit.runners.Suite.runChild(Suite.java:27)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)

19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:119> Delegating credential = false
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:140> Setting requering mutual authentication to true
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:74> Obtaining GSSCredential for the service from callback handler...
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:80> Unable to obtain GSSCredential from CallbackHandler: javax.security.auth.callback.UnsupportedCallbackException
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$AuthorizeOnlyCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:413)
	at org.wildfly.security.sasl.gssapi.GssapiServer.<init>(GssapiServer.java:75)
	at org.wildfly.security.sasl.gssapi.GssapiServerFactory.createSaslServer(GssapiServerFactory.java:44)
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$1(GssapiCompatibilitySuiteChild.java:111)
	at java.security.AccessController.doPrivileged(Native Method)
	at javax.security.auth.Subject.doAs(Subject.java:422)
	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:106)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runners.Suite.runChild(Suite.java:128)
	at org.junit.runners.Suite.runChild(Suite.java:27)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)

19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:87> Our name 'sasl at test_server_1'
19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:229> GSSContext not established, expecting subsequent exchanges.
{noformat}

[1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/jdk=java18_default,label=eap-sustaining&&solaris11&&x86_64/testReport/-sustaining&&solaris10&&sparc/testReport
[2] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/testReport/




> GssapiCompatibilitySuiteChild fails on solaris
> ----------------------------------------------
>
>                 Key: ELY-1474
>                 URL: https://issues.jboss.org/browse/ELY-1474
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>
> - On same java (Oracle java) test does not fail on other OS
> - We don't test other javas on solaris OS
> Problem is on line comparing expected sasl message witch actual.
> {code:java|title=GssapiCompatibilitySuiteChild}
> exchange = evaluateByClient(exchange);
>         assertEquals(" ", ByteIterator.ofBytes(exchange).hexEncode().drainToString());
> {code}
> Stacktrace
> {noformat}
> org.junit.ComparisonFailure: expected:<...03020110a281bf0481bc[ ]> but was:<...03020110a281bf0481bc[ ]>
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:121)
> {noformat}
> Log
> {noformat}
> 19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:52> loginClient
> Debug is  true storeKey true useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is true principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
> Refreshing Kerberos configuration
> 		[Krb5LoginModule] user entered username: jduke
> principal is jduke at WILDFLY.ORG
> EncryptionKey: keyType=16 keyBytes (hex dump)=0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
> 0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;
> Added server's keyKerberos Principal jduke at WILDFLY.ORGKey Version 0key EncryptionKey: keyType=16 keyBytes (hex dump)=
> 0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
> 0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;
> 		[Krb5LoginModule] added Krb5Principal  jduke at WILDFLY.ORG to Subject
> Commit Succeeded 
> 19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:57> loginServer
> Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator false KeyTab is /mnt/hudson_workspace/workspace/wildfly-elytron-unit-tests/20ff21f6/wildfly-elytron/./target/apache-ds/working/serverKeyTab refreshKrb5Config is true principal is sasl/test_server_1 tryFirstPass is false useFirstPass is false storePass is false clearPass is false
> Refreshing Kerberos configuration
> principal is sasl/test_server_1 at WILDFLY.ORG
> Will use keytab
> Commit Succeeded 
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:68> Acceptor Name 'sasl at test_server_1'
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:100> CallbackHandler does not support CredentialCallback: javax.security.auth.callback.UnsupportedCallbackException
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$NoCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:421)
> 	at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:120)
> 	at org.wildfly.security.sasl.gssapi.GssapiClient.<init>(GssapiClient.java:93)
> 	at org.wildfly.security.sasl.gssapi.GssapiClientFactory.createSaslClient(GssapiClientFactory.java:42)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$0(GssapiCompatibilitySuiteChild.java:103)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:97)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
> 	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runners.Suite.runChild(Suite.java:128)
> 	at org.junit.runners.Suite.runChild(Suite.java:27)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:119> Delegating credential = false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:140> Setting requering mutual authentication to true
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:74> Obtaining GSSCredential for the service from callback handler...
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:80> Unable to obtain GSSCredential from CallbackHandler: javax.security.auth.callback.UnsupportedCallbackException
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$AuthorizeOnlyCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:413)
> 	at org.wildfly.security.sasl.gssapi.GssapiServer.<init>(GssapiServer.java:75)
> 	at org.wildfly.security.sasl.gssapi.GssapiServerFactory.createSaslServer(GssapiServerFactory.java:44)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$1(GssapiCompatibilitySuiteChild.java:111)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:106)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
> 	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runners.Suite.runChild(Suite.java:128)
> 	at org.junit.runners.Suite.runChild(Suite.java:27)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:87> Our name 'sasl at test_server_1'
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:229> GSSContext not established, expecting subsequent exchanges.
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/jdk=java18_default,label=eap-sustaining&&solaris11&&x86_64/testReport/-sustaining&&solaris10&&sparc/testReport
> [2] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:46:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-704) Java scriptTask compilation
 error reports invalid line
In-Reply-To: <JIRA.12562321.1422972754000@Atlassian.JIRA>
References: <JIRA.12562321.1422972754000@Atlassian.JIRA>
	<JIRA.12562321.1422972754000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12562321.1422972754000.20872.1514900760837@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-704:
----------------------------------

    Assignee:     (was: Petr ?irok?)


> Java scriptTask compilation error reports invalid line
> ------------------------------------------------------
>
>                 Key: DROOLS-704
>                 URL: https://issues.jboss.org/browse/DROOLS-704
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.1.0.Final
>         Environment: Windows 7 x64,
> jdk1.6.0_45 x64
> jbpm 6.1.0.Final
>            Reporter: ???????? ?????????
>            Priority: Minor
>
> In case of a compilation error inside the scriptTask java code, the line and the column reported inside the org.drools.compiler.kie.builder.impl.MessageImpl are incorrect.
> The MessageImpl.getPath() should also return a path with the node id that contains the compilation error.
> To reproduce:
> {code:java}
> KieHelper kieHelper = new KieHelper();
> kieHelper.addResource(ResourceFactory.newClassPathResource("sample-jbpm6.bpmn"));
> Results res =  kieHelper.verify();
> for (Message msg : res.getMessages()) {
>      System.out.println("Error: " + msg);
> }
> if (res.hasMessages(Message.Level.ERROR)) {
>      throw new IllegalStateException("Could not verify the workflow");
> }
> {code}
> {noformat}
> Error: class org.drools.compiler.kie.builder.impl.MessageImpl
> [main] ERROR org.drools.compiler.kie.builder.impl.AbstractKieModule - Unable to build KieBaseModel:defaultKieBase
> Process Compilation error : Process org.jbpm.Hello World(com.sample.bpmn.hello)
> 	org/jbpm/Process_org$u46$jbpm$u46$Hello_World265679914.java (9:416) : Syntax error on token "halskdjfh", delete this token
> Exception in thread "main" java.lang.IllegalStateException: Could not verify the workflow
> 	at Main.main(Main.java:26)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
> 	at java.lang.reflect.Method.invoke(Method.java:597)
> 	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:134)
> Process finished with exit code 1
> {noformat}
> I've tested with both with "ECLIPSE" and "NATIVE" as values of the "drools.dialect.java.compiler".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:46:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-396) Caused by:
 java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
In-Reply-To: <JIRA.12529023.1389287238000@Atlassian.JIRA>
References: <JIRA.12529023.1389287238000@Atlassian.JIRA>
	<JIRA.12529023.1389287238000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12529023.1389287238000.20875.1514900760938@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-396:
----------------------------------

    Assignee:     (was: Petr ?irok?)


> Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
> -------------------------------------------------------------------------------------
>
>                 Key: DROOLS-396
>                 URL: https://issues.jboss.org/browse/DROOLS-396
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.0.0.Final
>            Reporter: leonardo lizana
>            Priority: Critical
>         Attachments: noclassdeffound.zip
>
>
> I'm trying to testing latest version of drools 6.0.1.Final version and i have the issue of  " java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener" . However, i can see class is now on the  the following path "org.drools.core.event.DebugProcessEventListener" and why the context is seeking in  org/drools/event/DebugProcessEventListener. instead of "org.drools.core.event.DebugProcessEventListener"
> is there anything that i'm doing bad?
> * with drools 5.5 everything is working OK.
> Here is my pom.xml
> --------------------------
> <dependency>
> 			<groupId>org.drools</groupId>
> 			<artifactId>knowledge-api</artifactId>
> 			<version>${drools.version}</version>
> 		</dependency>
> 		<dependency>
> 			<groupId>org.drools</groupId>
> 			<artifactId>drools-core</artifactId>
> 			<version>${drools.version}</version>
> 		</dependency>
> 		<dependency>
> 			<groupId>org.drools</groupId>
> 			<artifactId>drools-compiler</artifactId>
> 			<version>${drools.version}</version>
> 		</dependency>
> 		<dependency>
> 			<groupId>org.drools</groupId>
> 			<artifactId>drools-spring</artifactId>
> 			<version>5.5.0.Final</version>
> 		</dependency>
> here is the log error:
> ----------------------------
> Caused by: java.lang.NoClassDefFoundError: org/drools/event/DebugProcessEventListener
> 	at org.drools.container.spring.namespace.KnowledgeSessionDefinitionParser.parseInternal(KnowledgeSessionDefinitionParser.java:115)
> 	at org.springframework.beans.factory.xml.AbstractBeanDefinitionParser.parse(AbstractBeanDefinitionParser.java:59)
> 	at org.springframework.beans.factory.xml.NamespaceHandlerSupport.parse(NamespaceHandlerSupport.java:73)
> 	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1338)
> 	at org.springframework.beans.factory.xml.BeanDefinitionParserDelegate.parseCustomElement(BeanDefinitionParserDelegate.java:1328)
> 	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.parseBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:135)
> 	at org.springframework.beans.factory.xml.DefaultBeanDefinitionDocumentReader.registerBeanDefinitions(DefaultBeanDefinitionDocumentReader.java:93)
> 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.registerBeanDefinitions(XmlBeanDefinitionReader.java:493)
> 	at org.springframework.beans.factory.xml.XmlBeanDefinitionReader.doLoadBeanDefinitions(XmlBeanDefinitionReader.java:390)
> Here is the contex-drools.xml
> -------------------------------------
> <beans xmlns="http://www.springframework.org/schema/beans"
>     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>     xmlns:context="http://www.springframework.org/schema/context"
>     xmlns:drools="http://drools.org/schema/drools-spring"
>     xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-3.0.xsd
>     http://www.springframework.org/schema/context http://www.springframework.org/schema/context/spring-context-3.0.xsd
>     http://drools.org/schema/drools-spring http://anonsvn.jboss.org/repos/labs/labs/jbossrules/trunk/drools-container/drools-spring/src/main/resources/org/drools/container/spring/drools-spring-1.2.0.xsd"
>     default-autowire="byName">
>      
>   <drools:resource id="rulesEnergyUsage" type="DRL" source="classpath:com/aepenergy/b2b/miscpull/rules/rulesEnergyUsage.drl"/>
>   <drools:kbase id="kBaseEnergyUsage">
>     <drools:resources>
>       <drools:resource ref="rulesEnergyUsage"/>
>     </drools:resources>
>   </drools:kbase>
>   <drools:ksession id="kSessionEnergyUsage"  kbase="kBaseEnergyUsage" type="stateful"/>
>  </beans>



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:46:01 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:46:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-303) CCE when updating
	cron-scheduled rule
In-Reply-To: <JIRA.12508088.1382022039000@Atlassian.JIRA>
References: <JIRA.12508088.1382022039000@Atlassian.JIRA>
	<JIRA.12508088.1382022039000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12508088.1382022039000.20880.1514900761082@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-303:
----------------------------------

    Assignee:     (was: Petr ?irok?)


> CCE when updating cron-scheduled rule
> -------------------------------------
>
>                 Key: DROOLS-303
>                 URL: https://issues.jboss.org/browse/DROOLS-303
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 5.5.1.Final
>            Reporter: Davide Sottara
>
> Regression: timer jobs are unnecessarily cast to JDKTimerJobs



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:46:01 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:46:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-278) ProtobufMarshaller throws
 ClassCastException when marshalling CDI proxied KieSession.
In-Reply-To: <JIRA.12501777.1380410976000@Atlassian.JIRA>
References: <JIRA.12501777.1380410976000@Atlassian.JIRA>
	<JIRA.12501777.1380410976000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501777.1380410976000.20883.1514900761149@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-278:
----------------------------------

    Assignee:     (was: Petr ?irok?)


> ProtobufMarshaller throws ClassCastException when marshalling CDI proxied KieSession.
> -------------------------------------------------------------------------------------
>
>                 Key: DROOLS-278
>                 URL: https://issues.jboss.org/browse/DROOLS-278
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.0.8.5, Hotspot 1.7.0_40
>            Reporter: Duncan Doyle
>
> I have a CDI (Weld) @Producer which produces a KieSession. The KieSession is therefore proxied by a CDI/Weld proxy. When I try to marshall such a KieSession object, the ProtobufMarshaller throws the following ClassCastException:
> 01:21:07.505 [main] ERROR o.j.d.b.c.CdiSessionPersistenceTest - Error saving KieSession.
> java.lang.ClassCastException: org.jboss.weld.proxies.CommandExecutor$EntryPoint$KieRuntime$KieRuntimeEventManager$KieSession$ProcessEventManager$ProcessRuntime$RuleRuntime$StatefulProcessSession$StatefulRuleSession$WorkingMemoryEventManager$761192450$Proxy$_$$_WeldClientProxy cannot be cast to org.drools.core.impl.StatefulKnowledgeSessionImpl
> 	at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:157) ~[drools-core-6.0.0.CR4-Pre1.jar:6.0.0.CR4-Pre1]
> 	at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:148) ~[drools-core-6.0.0.CR4-Pre1.jar:6.0.0.CR4-Pre1]
> 	at org.jboss.ddoyle.brms.cep.ha.management.FileKieSessionLoader.save(FileKieSessionLoader.java:67) ~[classes/:na]
> 	at org.jboss.ddoyle.brms.cep.ha.management.FileKieSessionLoader.save(FileKieSessionLoader.java:37) ~[classes/:na]
> 	at org.jboss.ddoyle.brms.cep.ha.drools.session.SessionManager.saveKieSession(SessionManager.java:27) ~[classes/:na]
> 	at org.jboss.ddoyle.brms.cep.ha.drools.session.SessionManager$Proxy$_$$_WeldClientProxy.saveKieSession(SessionManager$Proxy$_$$_WeldClientProxy.java) ~[classes/:na]
> 	at org.jboss.ddoyle.brms.cdi.CdiSessionPersistenceTest.testCdiSessionPersistence(CdiSessionPersistenceTest.java:43) ~[test-classes/:na]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_40]
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) [junit-4.11.jar:na]
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) [junit-4.11.jar:na]
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) [junit-4.11.jar:na]
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) [junit-4.11.jar:na]
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) [junit-4.11.jar:na]
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [junit-4.11.jar:na]
> 	at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) [surefire-junit4-2.10.jar:2.10]
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) [surefire-junit4-2.10.jar:2.10]
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) [surefire-junit4-2.10.jar:2.10]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_40]
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) [surefire-api-2.10.jar:2.10]
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) [surefire-booter-2.10.jar:2.10]
> 	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) [surefire-booter-2.10.jar:2.10]
> 	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) [surefire-booter-2.10.jar:2.10]
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) [surefire-booter-2.10.jar:2.10]
> I've created a reproducer which shows the behaviour: https://github.com/DuncanDoyle/DroolsSessionCdiClassCastException
> Just run 'mvn clean test' in the project.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:47:00 2018
From: issues at jboss.org (=?UTF-8?Q?Petr_=C5=A0irok=C3=BD_=28JIRA=29?=)
Date: Tue, 2 Jan 2018 08:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-158) Improve Drools Fusion
 Documentation of Event expiration mechanism
In-Reply-To: <JIRA.12475676.1348763084000@Atlassian.JIRA>
References: <JIRA.12475676.1348763084000@Atlassian.JIRA>
	<JIRA.12475676.1348763084000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12475676.1348763084000.20888.1514900820509@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-158?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr ?irok? reassigned DROOLS-158:
----------------------------------

    Assignee:     (was: Petr ?irok?)


> Improve Drools Fusion Documentation of Event expiration mechanism
> -----------------------------------------------------------------
>
>                 Key: DROOLS-158
>                 URL: https://issues.jboss.org/browse/DROOLS-158
>             Project: Drools
>          Issue Type: Task
>         Environment: Eclipse 3.7 SR2, Jboss Tools, Drools 5.4.0.Final, Win XP. Attaching Eclipse project
>            Reporter: Matteo Mortari
>         Attachments: Screenshot-2012-09-27_18.25.40.png, SimpleCEP2 (very simple demo).zip
>
>
> h4. Executive Summary
> This is to kindly request, if you can please improve the Drools Fusion documentation to explain more specifically about ?Automatic Event Lifecycle Management?, and the basis how Event expiration actually works. Possibly by means of simple examples, or blueprints detailing CEP best implementation patterns specifically for Fusion, could greatly benefit.
> Thank you, I love RedHat and the JBoss Community :) but trying to understand completely Fusion?s Event expiration is making me crazy :P
> h4. Rationale
> The documentation in [par. ?2.5.2. Stream Mode?| http://docs.jboss.org/drools/release/5.4.0.Final/drools-fusion-docs/html_single/#d0e1126] is imho vague in the second requirement, specifically the generic statement ?the use of non-time-synchronized streams may result in some unexpected results?.  Especially it seems to me not only streams must be time-synchronized, but +also streams and the session clock must be strictly in-sync?+
> Take for instance the attached Eclipse project, to replicate one un-expected behavior - I?m specifically not raising this JIRA as a bug, because of the aforementioned ?vagueness? in the doc, I don?t have specific evidence this is strictly a bug. 
> (!) The assumption in this application: Events are inserted with a lag if compared to the session clock to simulate a communication lag and slight delay. However, all Events are inserted in strict chronological order. The issue here is: *because Events, despite in chronological order, are inserted slightly late if compared to the session clock, some unexpected behavior of the After LHS operator occurs*
> There is a simple rule that checks for two Event of type Message to happen within 1minute delay.
> {code:title=Sample.drl|borderStyle=solid}
> declare Message
> @role(event)
> @timestamp (timestamp)
> end
> rule "asd"
> when
> 	$m1 : Message()
> 	$m2 : Message(this after[0, 1m] $m1, this != $m1)
> then
> 	System.out.println("x");
> end 
> {code}
> Events are being inserted in strict chronological order. A first Event of type Message is inserted. Pseudo clock is advanced rapidly. Then a second Event of type Message is inserted having timestamp {{\+1}} second to the previous one.
> In the Audit log, also attached, you will see the very first Event, matched as {{$m1}}, get expired and retracted immediately after the rule has fired. This is OK: now the very first Event can no longer match in this rule, and because is the only rule available, gets expired and retracted. As you would expect from the documentation. Happily.
> This analogously repeats in the application and reflected in the audit log.
> !Screenshot-2012-09-27_18.25.40.png|align=center!
> Now skip to the *last* Event of type Message inserted. The consequence of this last Event being inserted is that the rule had fired again; analogously, this is the only Event of type Message remaining in the working memory. Happily.
> As the pseudo clock gets advanced rapidly, now no more Events are inserted. When the pseudo clock reaches {{\+60}} seconds from the +session time+ when this last Event was inserted, the Event is retracted. This is the issue and the unexpected behavior. I have NOT specified {{window:time(1m)}} in my rule, but seems to behaving like that. Shouldn?t the engine wait for a very next Event *of any type* to be inserted into the working memory, to evaluate the current stream timestamp and therefore infer this Event can now safely be expired and retracted?
> The rule, by the way it?s written, would check to see if two Events of type Message are available within a 1minute of timespan. While instead, seems to me by the unexpected results, this also implicitly stating {{window:time(1m)}} being the Max of the parameters for the time constraint operators available in the rule.
> If you can explain better the Event expiration mechanism and improve the Documentation, it would greatly help to understand for instance why this scenario behaves in this (from my perspective) unexpected behavior.
> I seize the chance to thank you once again, Ciao



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 08:58:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 2 Jan 2018 08:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2202) DMN runtime typecheck not
 managed for context and DT output
In-Reply-To: <JIRA.12726225.1514901474000@Atlassian.JIRA>
References: <JIRA.12726225.1514901474000@Atlassian.JIRA>
	<JIRA.12726225.1514901474738@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726225.1514901474000.20956.1514901480075@Atlassian.JIRA>

Matteo Mortari created DROOLS-2202:
--------------------------------------

             Summary: DMN runtime typecheck not managed for context and DT output
                 Key: DROOLS-2202
                 URL: https://issues.jboss.org/browse/DROOLS-2202
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari
         Attachments: screenshot-1.png, screenshot-2.png

A Context result (last line)
and
A Decision Table output column

are not obliging to the configuration for runtime typecheck.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 09:02:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 2 Jan 2018 09:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2203) NPE when structured DT
 output field is null
In-Reply-To: <JIRA.12726226.1514901664000@Atlassian.JIRA>
References: <JIRA.12726226.1514901664000@Atlassian.JIRA>
	<JIRA.12726226.1514901664333@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726226.1514901664000.20978.1514901720095@Atlassian.JIRA>

Matteo Mortari created DROOLS-2203:
--------------------------------------

             Summary: NPE when structured DT output field is null
                 Key: DROOLS-2203
                 URL: https://issues.jboss.org/browse/DROOLS-2203
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari
         Attachments: image-2017-12-28-14-36-21-072.png

When a DMN Decision Table output is structured, and one of the field of the output structure is assigned a null value, throws NPE
 !image-2017-12-28-14-36-21-072.png|thumbnail! 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 09:47:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 2 Jan 2018 09:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.21375.1514904420412@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508560#comment-13508560 ] 

Edson Tirelli commented on DROOLS-2194:
---------------------------------------

[~littlemustard] , I am not sure how you are "manipulating the kjar" but there are a few things you need to be careful with:

1. as any other mavenized jar, kjars are immutable. If you change the content of a kjar, you should bump its version to a new version.

2. when you create a kjar with either the maven plugin or in memory using the API, it generates a pre-compiled bytecode cache. If you change the content of the kjar, but leave the cache in there, it might be getting out of sync and then it is unpredictable.

There are examples in the Drools codebase of how to generate kjars in memory and save them to disk. If your use case requires you to do that, please make sure you are using the correct APIs for it, instead of opening the jar file and adding/removing files (not sure if you are doing it or not).

Here is an utility method that shows how to create a kjar in memory. Just take the returning byte[] and save it to disk as a .jar file:

https://github.com/kiegroup/drools/blob/master/kie-dmn/kie-dmn-core/src/main/java/org/kie/dmn/core/util/KieHelper.java#L49

I will close this ticket for now, but if you think you are using the API correctly and still having problems, please reopen and attach the code you are using to change the kjar.



> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Edson Tirelli
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 09:47:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 2 Jan 2018 09:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.21379.1514904420501@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned DROOLS-2194:
-------------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)


> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 09:47:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 2 Jan 2018 09:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.21386.1514904420710@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli resolved DROOLS-2194.
-----------------------------------
    Resolution: Incomplete Description


> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 09:57:00 2018
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 2 Jan 2018 09:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9647) allow property name to be
 specified in PersistenceUnit/PersistenceContext unitName
In-Reply-To: <JIRA.12726233.1514904961000@Atlassian.JIRA>
References: <JIRA.12726233.1514904961000@Atlassian.JIRA>
	<JIRA.12726233.1514904961449@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726233.1514904961000.21494.1514905020623@Atlassian.JIRA>

Scott Marlow created WFLY-9647:
----------------------------------

             Summary: allow property name to be specified in PersistenceUnit/PersistenceContext unitName
                 Key: WFLY-9647
                 URL: https://issues.jboss.org/browse/WFLY-9647
             Project: WildFly
          Issue Type: Task
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow


Add extension that allows system property substitution of unitName:
{quote}
@PersistenceContext(unitName = ?${test.case.persistence.context}")
 private EntityManager entityManager;

@PersistenceUnit(unitName = ?${test.case.persistence.context}")
 private EntityManagerFactory entityManagerFactory;
{quote}





--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 09:57:01 2018
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 2 Jan 2018 09:57:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9647) allow property name to be
 specified in PersistenceUnit/PersistenceContext unitName
In-Reply-To: <JIRA.12726233.1514904961000@Atlassian.JIRA>
References: <JIRA.12726233.1514904961000@Atlassian.JIRA>
	<JIRA.12726233.1514904961000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726233.1514904961000.21501.1514905021936@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-9647:
-------------------------------
    Description: 
Add extension that allows system property substitution of unitName:
{code}
@PersistenceContext(unitName = ?${test.case.persistence.context}")
 private EntityManager entityManager;

@PersistenceUnit(unitName = ?${test.case.persistence.context}")
 private EntityManagerFactory entityManagerFactory;
{code}



  was:
Add extension that allows system property substitution of unitName:
{quote}
@PersistenceContext(unitName = ?${test.case.persistence.context}")
 private EntityManager entityManager;

@PersistenceUnit(unitName = ?${test.case.persistence.context}")
 private EntityManagerFactory entityManagerFactory;
{quote}





> allow property name to be specified in PersistenceUnit/PersistenceContext unitName
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-9647
>                 URL: https://issues.jboss.org/browse/WFLY-9647
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>
> Add extension that allows system property substitution of unitName:
> {code}
> @PersistenceContext(unitName = ?${test.case.persistence.context}")
>  private EntityManager entityManager;
> @PersistenceUnit(unitName = ?${test.case.persistence.context}")
>  private EntityManagerFactory entityManagerFactory;
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  2 10:56:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 2 Jan 2018 10:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-85) Support GSS-Proxy
In-Reply-To: <JIRA.12552990.1411397770000@Atlassian.JIRA>
References: <JIRA.12552990.1411397770000@Atlassian.JIRA>
	<JIRA.12552990.1411397770000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552990.1411397770000.22015.1514908560506@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-85?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-85:
-----------------------------

    Assignee: Jan Kalina


> Support GSS-Proxy
> -----------------
>
>                 Key: ELY-85
>                 URL: https://issues.jboss.org/browse/ELY-85
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SASL
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta13
>
>
> GSS Proxy is something we should consider being able to support when running on an OS that supports it: -
> -https://fedorahosted.org/gss-proxy/-
> https://pagure.io/gssproxy
> The big first step will be to identify what is required to achieve this, is this something that can be solved with a custom login module or does this also impact on the Java supplied GSSAPI implementation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 11:03:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 2 Jan 2018 11:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-283) Investigate Elytron and
 gssproxy interoperability
In-Reply-To: <JIRA.12583605.1441213044000@Atlassian.JIRA>
References: <JIRA.12583605.1441213044000@Atlassian.JIRA>
	<JIRA.12583605.1441213044000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583605.1441213044000.22052.1514908980401@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508621#comment-13508621 ] 

Jan Kalina commented on ELY-283:
--------------------------------

Complete instructions to setup wildfly+elytron to use gssapi composed into tutorial:

https://hkalina.github.io/2018/01/02/gssproxy/

Things to fix/improve in elytron:
* path to the keytab in kerberos-security-factory should be made optional

> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
>                 Key: ELY-283
>                 URL: https://issues.jboss.org/browse/ELY-283
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: SASL
>            Reporter: Peter Skopek
>            Assignee: Jan Kalina
>             Fix For: 2.0.0.Alpha1
>
>         Attachments: jkalina-openjdk-native-gss.patch, openjdk-patch-native-mechs.patch, reproducer-gss.zip
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 11:40:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 2 Jan 2018 11:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3484) Nonintuitive error message
 when for loop is used inside of if/try/batch constructs
In-Reply-To: <JIRA.12725648.1513696168000@Atlassian.JIRA>
References: <JIRA.12725648.1513696168000@Atlassian.JIRA>
	<JIRA.12725648.1513696168000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725648.1513696168000.22185.1514911200292@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508456#comment-13508456 ] 

Jean-Francois Denise edited comment on WFCORE-3484 at 1/2/18 11:39 AM:
-----------------------------------------------------------------------

You have revealed multiple issues there:
1) Variables can't be set and used inside if/try/for.
For example:
if (outcome != success) of /system-property=test:read-resource
set foo=bar
echo $foo

==> You will get an exception. This is the same exception that you are getting when echoing propName

2) There is no check when a redirection is already active and a new redirection is used:e.g.: if followed by if, ... The CLI accepts the new redirection silently.

Finally, having an If inside a for is supported. Nesting of the same redirection is not supported, but you can mix redirections. I will update the analysis document, it was not clear.




was (Author: jdenise):
You have revealed multiple issues there:
1) Variables can't be set and used inside if/try/for.
For example:
if (outcome != success) of /system-property=test:read-resource
set foo=bar
echo $foo

==> You will get an exception. This is the same exception that you are getting when echoing propName

2) There is no check when a redirection is already active and a new redirection is used:e.g.: try followed by if, if followed by if, ... The CLI accepts the new redirection silently.

3) Command name completion is not helpful, although a redirection is active (eg: if), other redirections are proposed (try, for).


> Nonintuitive error message when for loop is used inside of if/try/batch constructs
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-3484
>                 URL: https://issues.jboss.org/browse/WFCORE-3484
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Erich Duda
>            Assignee: Jean-Francois Denise
>
> CLI enables to use for loop construct for looping over commands or operations. See WFCORE-3236 for details. Because of design limitations of CLI, using of for loop is not supported inside of if, try, for and batch constructs. However if you try to do that, error message is not intuitive in all cases and it is difficult to find out why the code does not work.
> Let's see on real examples.
> {code:title=Using for inside if}
> [standalone at embedded /] if (outcome != success) of /system-property=test:read-resource
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone at embedded /] echo $propName
> Unrecognized variable propName
> {code}
> As you can see in the example, when you write aforementioned commands into the CLI, no error is thrown until you use the variable declared in the for construct. Additionally the error message is not saying anything about that using of "for" is not allowed inside of "if".
> {code:title=Using for inside try}
> [standalone at embedded /] try
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone at embedded /] echo $propName
> Unrecognized variable propName
> {code}
> The same applies here as for "if" case.
> {code:title=Using for inside batch}
> [standalone at embedded /] batch
> [standalone at embedded / #] for propName in :read-children-names(child-type=system-property)
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> {code}
> In the batch case, the error message is better (it says that command is not available), but still it is not clear why the command is not available.
> {code:title=Using for inside for}
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> for is not allowed while in for block
> {code}
> Using of nested for loops generates nice error message which clearly explains what is wrong. All other cases should throw similar error.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 12:16:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 2 Jan 2018 12:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2204) DMN QName regex problem and
 assimilated for function drools:kind
In-Reply-To: <JIRA.12726251.1514913323000@Atlassian.JIRA>
References: <JIRA.12726251.1514913323000@Atlassian.JIRA>
	<JIRA.12726251.1514913323470@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726251.1514913323000.22254.1514913360317@Atlassian.JIRA>

Matteo Mortari created DROOLS-2204:
--------------------------------------

             Summary: DMN QName regex problem and assimilated for function drools:kind
                 Key: DROOLS-2204
                 URL: https://issues.jboss.org/browse/DROOLS-2204
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari


DMN QName regex does not match with serialization strategy.

A qname string serialization as 

{code:java}
{http://namespace}localPart
{code}

would fail the regex of MarshallingUtils.

Additionally FunctionDefinition could now rely on the additionalAttributes generally available at the level of DMNModelInstrumentedBase (which would also serialize any other type of additional attributes, preserving from any original .dmn file).

Finally, it was noted calling getDecisionResultByName on DMNResultImpl by passing a wrong name would have thrown the stacktrace for wrong use of Optional.get(), instead of returning null as per getDecisionResultById() of the same class.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  2 14:57:00 2018
From: issues at jboss.org (Duncan Doyle (JIRA))
Date: Tue, 2 Jan 2018 14:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-278) ProtobufMarshaller throws
 ClassCastException when marshalling CDI proxied KieSession.
In-Reply-To: <JIRA.12501777.1380410976000@Atlassian.JIRA>
References: <JIRA.12501777.1380410976000@Atlassian.JIRA>
	<JIRA.12501777.1380410976000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12501777.1380410976000.22582.1514923020056@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Duncan Doyle reassigned DROOLS-278:
-----------------------------------

    Assignee: Duncan Doyle


> ProtobufMarshaller throws ClassCastException when marshalling CDI proxied KieSession.
> -------------------------------------------------------------------------------------
>
>                 Key: DROOLS-278
>                 URL: https://issues.jboss.org/browse/DROOLS-278
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions:  6.0.0.CR3
>         Environment: Mac OS-X 1.0.8.5, Hotspot 1.7.0_40
>            Reporter: Duncan Doyle
>            Assignee: Duncan Doyle
>
> I have a CDI (Weld) @Producer which produces a KieSession. The KieSession is therefore proxied by a CDI/Weld proxy. When I try to marshall such a KieSession object, the ProtobufMarshaller throws the following ClassCastException:
> 01:21:07.505 [main] ERROR o.j.d.b.c.CdiSessionPersistenceTest - Error saving KieSession.
> java.lang.ClassCastException: org.jboss.weld.proxies.CommandExecutor$EntryPoint$KieRuntime$KieRuntimeEventManager$KieSession$ProcessEventManager$ProcessRuntime$RuleRuntime$StatefulProcessSession$StatefulRuleSession$WorkingMemoryEventManager$761192450$Proxy$_$$_WeldClientProxy cannot be cast to org.drools.core.impl.StatefulKnowledgeSessionImpl
> 	at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:157) ~[drools-core-6.0.0.CR4-Pre1.jar:6.0.0.CR4-Pre1]
> 	at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:148) ~[drools-core-6.0.0.CR4-Pre1.jar:6.0.0.CR4-Pre1]
> 	at org.jboss.ddoyle.brms.cep.ha.management.FileKieSessionLoader.save(FileKieSessionLoader.java:67) ~[classes/:na]
> 	at org.jboss.ddoyle.brms.cep.ha.management.FileKieSessionLoader.save(FileKieSessionLoader.java:37) ~[classes/:na]
> 	at org.jboss.ddoyle.brms.cep.ha.drools.session.SessionManager.saveKieSession(SessionManager.java:27) ~[classes/:na]
> 	at org.jboss.ddoyle.brms.cep.ha.drools.session.SessionManager$Proxy$_$$_WeldClientProxy.saveKieSession(SessionManager$Proxy$_$$_WeldClientProxy.java) ~[classes/:na]
> 	at org.jboss.ddoyle.brms.cdi.CdiSessionPersistenceTest.testCdiSessionPersistence(CdiSessionPersistenceTest.java:43) ~[test-classes/:na]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_40]
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:47) [junit-4.11.jar:na]
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12) [junit-4.11.jar:na]
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:44) [junit-4.11.jar:na]
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271) [junit-4.11.jar:na]
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70) [junit-4.11.jar:na]
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229) [junit-4.11.jar:na]
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:309) [junit-4.11.jar:na]
> 	at org.apache.maven.surefire.junit4.JUnit4TestSet.execute(JUnit4TestSet.java:53) [surefire-junit4-2.10.jar:2.10]
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:123) [surefire-junit4-2.10.jar:2.10]
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:104) [surefire-junit4-2.10.jar:2.10]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_40]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_40]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_40]
> 	at java.lang.reflect.Method.invoke(Method.java:606) ~[na:1.7.0_40]
> 	at org.apache.maven.surefire.util.ReflectionUtils.invokeMethodWithArray(ReflectionUtils.java:164) [surefire-api-2.10.jar:2.10]
> 	at org.apache.maven.surefire.booter.ProviderFactory$ProviderProxy.invoke(ProviderFactory.java:110) [surefire-booter-2.10.jar:2.10]
> 	at org.apache.maven.surefire.booter.SurefireStarter.invokeProvider(SurefireStarter.java:175) [surefire-booter-2.10.jar:2.10]
> 	at org.apache.maven.surefire.booter.SurefireStarter.runSuitesInProcessWhenForked(SurefireStarter.java:107) [surefire-booter-2.10.jar:2.10]
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:68) [surefire-booter-2.10.jar:2.10]
> I've created a reproducer which shows the behaviour: https://github.com/DuncanDoyle/DroolsSessionCdiClassCastException
> Just run 'mvn clean test' in the project.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 03:43:00 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Wed, 3 Jan 2018 03:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1383) Startup success detection
 mechanism fails if JBOSS_HOME and jboss.server.base.dir are set
 differently.
In-Reply-To: <JIRA.12585389.1442584310000@Atlassian.JIRA>
References: <JIRA.12585389.1442584310000@Atlassian.JIRA>
	<JIRA.12585389.1442584310000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12585389.1442584310000.23689.1514968980268@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1383?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao reassigned WFCORE-1383:
-------------------------------

    Assignee: Lin Gao


> Startup success detection mechanism fails if JBOSS_HOME and jboss.server.base.dir are set differently.
> ------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1383
>                 URL: https://issues.jboss.org/browse/WFCORE-1383
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Scripts
>    Affects Versions: 2.0.0.CR1
>         Environment: Linux/Debian
>            Reporter: Thorsten Moeller
>            Assignee: Lin Gao
>
> If the property `jboss.server.base.dir` and the environment variable `JBOSS_HOME` point to different directories (which we do, for instance, to start multiple JBoss/Wildfly instances, each with its own standalone directory) then the startup success detection mechanism implemented by the script <WILDFLY_HOME>/bin/init.d/wildfly-init-debian.sh wrongly reports startup as failed even if it actually succeeded.
> Tracing it down, I found that since Wildly 10 the startup script searches for the file `<JBOSS_HOME>/standalone/tmp/startup-marker`. However, that file is actually written to `jboss.server.base.dir/tmp/startup-marker`; hence, it is not found if the directories are not the same.
> I don't see a way how to fix this. As far as I can seen, it's not possible to access the jboss.server.base.dir property within the startup script. But the use case of having separate directories should be supported and it should work.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 04:26:02 2018
From: issues at jboss.org (Senthil Kumar Kamaraj (JIRA))
Date: Wed, 3 Jan 2018 04:26:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2205) Issues in KIE WB
In-Reply-To: <JIRA.12726289.1514971515000@Atlassian.JIRA>
References: <JIRA.12726289.1514971515000@Atlassian.JIRA>
	<JIRA.12726289.1514971515128@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726289.1514971515000.23967.1514971562278@Atlassian.JIRA>

Senthil Kumar Kamaraj created DROOLS-2205:
---------------------------------------------

             Summary: Issues in KIE WB
                 Key: DROOLS-2205
                 URL: https://issues.jboss.org/browse/DROOLS-2205
             Project: Drools
          Issue Type: Bug
    Affects Versions: 7.4.1.Final
            Reporter: Senthil Kumar Kamaraj
            Assignee: Edson Tirelli


There are some issues in KIE workbench 7.4.1 release

   1.  Creating group on KIE WB on tomcat throws exception sometimes, but the group is created.

  2.  When trying to delete the user from KIE WB, the user is not getting deleted.

  3.  Language support other than English is not complete: partial support

   4.  Sometimes, when I am trying to perform operation on "newly created project" in KIE Workbench, URL is redirected to other existing project.

    5.  KIE WB user creation: Unable to create new user gracefully from the GUI: error: Cannot read property 'p8b' of null.
     
     6.  The new user creation is failing if it is assigned to Groups and Roles.
           Received Error : Group not found.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 04:33:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 3 Jan 2018 04:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-283) Investigate Elytron and
 gssproxy interoperability
In-Reply-To: <JIRA.12583605.1441213044000@Atlassian.JIRA>
References: <JIRA.12583605.1441213044000@Atlassian.JIRA>
	<JIRA.12583605.1441213044000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583605.1441213044000.24078.1514971980436@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508621#comment-13508621 ] 

Jan Kalina edited comment on ELY-283 at 1/3/18 4:32 AM:
--------------------------------------------------------

Complete instructions to setup wildfly+elytron to use gssapi composed into tutorial:

https://hkalina.github.io/2018/01/02/gssproxy/

Things to fix/improve in elytron:
* path to the keytab in kerberos-security-factory should be made optional
* workaround JDK-8194073 - wil not fix GS2-KRB5, but will fix GSSAPI (!)


was (Author: honza889):
Complete instructions to setup wildfly+elytron to use gssapi composed into tutorial:

https://hkalina.github.io/2018/01/02/gssproxy/

Things to fix/improve in elytron:
* path to the keytab in kerberos-security-factory should be made optional

> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
>                 Key: ELY-283
>                 URL: https://issues.jboss.org/browse/ELY-283
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: SASL
>            Reporter: Peter Skopek
>            Assignee: Jan Kalina
>             Fix For: 2.0.0.Alpha1
>
>         Attachments: jkalina-openjdk-native-gss.patch, openjdk-patch-native-mechs.patch, reproducer-gss.zip
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 05:42:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 3 Jan 2018 05:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-85) Support GSS-Proxy
In-Reply-To: <JIRA.12552990.1411397770000@Atlassian.JIRA>
References: <JIRA.12552990.1411397770000@Atlassian.JIRA>
	<JIRA.12552990.1411397770000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552990.1411397770000.24523.1514976120223@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508864#comment-13508864 ] 

Jan Kalina commented on ELY-85:
-------------------------------

Native Kerberos is supported, there are just following issues:
* properties like *sun.security.jgss.lib* needs to be set during JVM initialization - in standalone.xml it is too late - need to set using JAVA_OPTS
* SASL mechanims GS2 will work until JDK will be fixed - problem with null address in channel binding cannot be workarounded
* mechanisms SASL GSSAPI and HTTP SPNEGO needs workaround of JDK-8194073 - implemented in PR of ELY-85

Complete setup instructions at https://hkalina.github.io/2018/01/02/gssproxy/

> Support GSS-Proxy
> -----------------
>
>                 Key: ELY-85
>                 URL: https://issues.jboss.org/browse/ELY-85
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SASL
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta13
>
>
> GSS Proxy is something we should consider being able to support when running on an OS that supports it: -
> -https://fedorahosted.org/gss-proxy/-
> https://pagure.io/gssproxy
> The big first step will be to identify what is required to achieve this, is this something that can be solved with a custom login module or does this also impact on the Java supplied GSSAPI implementation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 05:43:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 3 Jan 2018 05:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-85) Support GSS-Proxy
In-Reply-To: <JIRA.12552990.1411397770000@Atlassian.JIRA>
References: <JIRA.12552990.1411397770000@Atlassian.JIRA>
	<JIRA.12552990.1411397770000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552990.1411397770000.24532.1514976180751@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508864#comment-13508864 ] 

Jan Kalina edited comment on ELY-85 at 1/3/18 5:42 AM:
-------------------------------------------------------

Native Kerberos is supported, there are just following issues:
* properties like *sun.security.jgss.lib* needs to be set during JVM initialization - in standalone.xml it is too late - need to set using JAVA_OPTS
* SASL mechanims GS2 will not work until JDK will be fixed - problem with null address in channel binding cannot be workarounded
* mechanisms SASL GSSAPI and HTTP SPNEGO needs workaround of JDK-8194073 - implemented in PR of ELY-85

Complete setup instructions at https://hkalina.github.io/2018/01/02/gssproxy/


was (Author: honza889):
Native Kerberos is supported, there are just following issues:
* properties like *sun.security.jgss.lib* needs to be set during JVM initialization - in standalone.xml it is too late - need to set using JAVA_OPTS
* SASL mechanims GS2 will work until JDK will be fixed - problem with null address in channel binding cannot be workarounded
* mechanisms SASL GSSAPI and HTTP SPNEGO needs workaround of JDK-8194073 - implemented in PR of ELY-85

Complete setup instructions at https://hkalina.github.io/2018/01/02/gssproxy/

> Support GSS-Proxy
> -----------------
>
>                 Key: ELY-85
>                 URL: https://issues.jboss.org/browse/ELY-85
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SASL
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta13
>
>
> GSS Proxy is something we should consider being able to support when running on an OS that supports it: -
> -https://fedorahosted.org/gss-proxy/-
> https://pagure.io/gssproxy
> The big first step will be to identify what is required to achieve this, is this something that can be solved with a custom login module or does this also impact on the Java supplied GSSAPI implementation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 05:47:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Wed, 3 Jan 2018 05:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3484) Variables can't be set and
 used inside if/try blocks
In-Reply-To: <JIRA.12725648.1513696168000@Atlassian.JIRA>
References: <JIRA.12725648.1513696168000@Atlassian.JIRA>
	<JIRA.12725648.1513696168000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725648.1513696168000.24571.1514976420195@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erich Duda updated WFCORE-3484:
-------------------------------
    Summary: Variables can't be set and used inside if/try blocks  (was: Nonintuitive error message when for loop is used inside of if/try/batch constructs)


> Variables can't be set and used inside if/try blocks
> ----------------------------------------------------
>
>                 Key: WFCORE-3484
>                 URL: https://issues.jboss.org/browse/WFCORE-3484
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Erich Duda
>            Assignee: Jean-Francois Denise
>
> CLI enables to use for loop construct for looping over commands or operations. See WFCORE-3236 for details. Because of design limitations of CLI, using of for loop is not supported inside of if, try, for and batch constructs. However if you try to do that, error message is not intuitive in all cases and it is difficult to find out why the code does not work.
> Let's see on real examples.
> {code:title=Using for inside if}
> [standalone at embedded /] if (outcome != success) of /system-property=test:read-resource
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone at embedded /] echo $propName
> Unrecognized variable propName
> {code}
> As you can see in the example, when you write aforementioned commands into the CLI, no error is thrown until you use the variable declared in the for construct. Additionally the error message is not saying anything about that using of "for" is not allowed inside of "if".
> {code:title=Using for inside try}
> [standalone at embedded /] try
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone at embedded /] echo $propName
> Unrecognized variable propName
> {code}
> The same applies here as for "if" case.
> {code:title=Using for inside batch}
> [standalone at embedded /] batch
> [standalone at embedded / #] for propName in :read-children-names(child-type=system-property)
> The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
> {code}
> In the batch case, the error message is better (it says that command is not available), but still it is not clear why the command is not available.
> {code:title=Using for inside for}
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> [standalone at embedded /] for propName in :read-children-names(child-type=system-property)
> for is not allowed while in for block
> {code}
> Using of nested for loops generates nice error message which clearly explains what is wrong. All other cases should throw similar error.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 05:48:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Wed, 3 Jan 2018 05:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3484) Variables can't be set and
 used inside if/try blocks
In-Reply-To: <JIRA.12725648.1513696168000@Atlassian.JIRA>
References: <JIRA.12725648.1513696168000@Atlassian.JIRA>
	<JIRA.12725648.1513696168000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725648.1513696168000.24583.1514976480611@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erich Duda updated WFCORE-3484:
-------------------------------
    Description: 
If you try to write the following commands into the CLI you will get an error {{Unrecognized variable}}.

{code}
[standalone at embedded /] if (outcome != success) of /system-property=test:read-resource
[standalone at embedded /] set foo=bar
[standalone at embedded /] echo $foo
Unrecognized variable foo
{code}

  was:
CLI enables to use for loop construct for looping over commands or operations. See WFCORE-3236 for details. Because of design limitations of CLI, using of for loop is not supported inside of if, try, for and batch constructs. However if you try to do that, error message is not intuitive in all cases and it is difficult to find out why the code does not work.

Let's see on real examples.

{code:title=Using for inside if}
[standalone at embedded /] if (outcome != success) of /system-property=test:read-resource
[standalone at embedded /] for propName in :read-children-names(child-type=system-property)
[standalone at embedded /] echo $propName
Unrecognized variable propName
{code}

As you can see in the example, when you write aforementioned commands into the CLI, no error is thrown until you use the variable declared in the for construct. Additionally the error message is not saying anything about that using of "for" is not allowed inside of "if".

{code:title=Using for inside try}
[standalone at embedded /] try
[standalone at embedded /] for propName in :read-children-names(child-type=system-property)
[standalone at embedded /] echo $propName
Unrecognized variable propName
{code}

The same applies here as for "if" case.

{code:title=Using for inside batch}
[standalone at embedded /] batch
[standalone at embedded / #] for propName in :read-children-names(child-type=system-property)
The command is not available in the current context (e.g. required subsystems or connection to the controller might be unavailable).
{code}

In the batch case, the error message is better (it says that command is not available), but still it is not clear why the command is not available.

{code:title=Using for inside for}
[standalone at embedded /] for propName in :read-children-names(child-type=system-property)
[standalone at embedded /] for propName in :read-children-names(child-type=system-property)
for is not allowed while in for block
{code}

Using of nested for loops generates nice error message which clearly explains what is wrong. All other cases should throw similar error.



> Variables can't be set and used inside if/try blocks
> ----------------------------------------------------
>
>                 Key: WFCORE-3484
>                 URL: https://issues.jboss.org/browse/WFCORE-3484
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Erich Duda
>            Assignee: Jean-Francois Denise
>
> If you try to write the following commands into the CLI you will get an error {{Unrecognized variable}}.
> {code}
> [standalone at embedded /] if (outcome != success) of /system-property=test:read-resource
> [standalone at embedded /] set foo=bar
> [standalone at embedded /] echo $foo
> Unrecognized variable foo
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 05:51:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Wed, 3 Jan 2018 05:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3484) Variables can't be set and
 used inside if/try blocks
In-Reply-To: <JIRA.12725648.1513696168000@Atlassian.JIRA>
References: <JIRA.12725648.1513696168000@Atlassian.JIRA>
	<JIRA.12725648.1513696168000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725648.1513696168000.24608.1514976660990@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508871#comment-13508871 ] 

Erich Duda commented on WFCORE-3484:
------------------------------------

Thanks for the reply. I have updated the Jira to describe the issue 1) as the wrong error messages were caused by that issue.

> Variables can't be set and used inside if/try blocks
> ----------------------------------------------------
>
>                 Key: WFCORE-3484
>                 URL: https://issues.jboss.org/browse/WFCORE-3484
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Erich Duda
>            Assignee: Jean-Francois Denise
>
> If you try to write the following commands into the CLI you will get an error {{Unrecognized variable}}.
> {code}
> [standalone at embedded /] if (outcome != success) of /system-property=test:read-resource
> [standalone at embedded /] set foo=bar
> [standalone at embedded /] echo $foo
> Unrecognized variable foo
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 05:52:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Wed, 3 Jan 2018 05:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3484) Variables can't be set and
 used inside if/try/for blocks
In-Reply-To: <JIRA.12725648.1513696168000@Atlassian.JIRA>
References: <JIRA.12725648.1513696168000@Atlassian.JIRA>
	<JIRA.12725648.1513696168000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725648.1513696168000.24615.1514976720306@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erich Duda updated WFCORE-3484:
-------------------------------
    Summary: Variables can't be set and used inside if/try/for blocks  (was: Variables can't be set and used inside if/try blocks)


> Variables can't be set and used inside if/try/for blocks
> --------------------------------------------------------
>
>                 Key: WFCORE-3484
>                 URL: https://issues.jboss.org/browse/WFCORE-3484
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Erich Duda
>            Assignee: Jean-Francois Denise
>
> If you try to write the following commands into the CLI you will get an error {{Unrecognized variable}}.
> {code}
> [standalone at embedded /] if (outcome != success) of /system-property=test:read-resource
> [standalone at embedded /] set foo=bar
> [standalone at embedded /] echo $foo
> Unrecognized variable foo
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 06:04:00 2018
From: issues at jboss.org (Senthil Kumar Kamaraj (JIRA))
Date: Wed, 3 Jan 2018 06:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2206) Login / Logout issue in KIE
	workbench
In-Reply-To: <JIRA.12726327.1514977383000@Atlassian.JIRA>
References: <JIRA.12726327.1514977383000@Atlassian.JIRA>
	<JIRA.12726327.1514977383922@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726327.1514977383000.24738.1514977440455@Atlassian.JIRA>

Senthil Kumar Kamaraj created DROOLS-2206:
---------------------------------------------

             Summary: Login / Logout issue in KIE workbench
                 Key: DROOLS-2206
                 URL: https://issues.jboss.org/browse/DROOLS-2206
             Project: Drools
          Issue Type: Bug
            Reporter: Senthil Kumar Kamaraj
            Assignee: Edson Tirelli


1.  KIE WB Logout issue: KIE WB should automatically navigate to the login page by default if the corresponding session is logged out from other browser/tab session

2.  KIE WB login issue:Unable to complete your request. The following exception occurred: java.lang.RuntimeException: org.eclipse.jgit.api.errors.TransportException:

3.  The browser back button still having the previous login session valid even after logged out from the KIE workbench.

4.  Unable to logout after multiple login and logout sessions. non consistent.

5.  Sometimes when trying to re login to KIE workbench unexpected redirection to logout page

6.  Sometimes when trying to login into KIE workbench without keycloak configured, login unsuccessful without any error message displayed in the browser(blank screen)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 07:18:01 2018
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 3 Jan 2018 07:18:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3485) Misleading
 failure-description for capabilities in domain
In-Reply-To: <JIRA.12726347.1514981869000@Atlassian.JIRA>
References: <JIRA.12726347.1514981869000@Atlassian.JIRA>
	<JIRA.12726347.1514981869686@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726347.1514981869000.25273.1514981881608@Atlassian.JIRA>

Ondrej Lukas created WFCORE-3485:
------------------------------------

             Summary: Misleading failure-description for capabilities in domain
                 Key: WFCORE-3485
                 URL: https://issues.jboss.org/browse/WFCORE-3485
             Project: WildFly Core
          Issue Type: Bug
          Components: Domain Management
            Reporter: Ondrej Lukas
            Assignee: Brian Stansberry


In case when configuration in domain.xml tries to reference any capability from host.xml (or vice versa), but should not be able to reference it then it correctly fails, but there is failure-description which is misleading. 

Start domain with default domain.xml and host.xml and run following CLI command and see:

{code}
/profile=full/subsystem=elytron/http-authentication-factory=some-factory:add(http-server-mechanism-factory=global,security-domain=ManagementDomain)
{
    "outcome" => "failed",
    "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
    org.wildfly.security.security-domain.ManagementDomain in context 'profile=full'; Possible registration points for this capability: 
		/host=master/subsystem=elytron/security-domain=*
		/profile=*/subsystem=elytron/security-domain=*"},
    "rolled-back" => true
}
{code}

It should show only correct registration point {{/profile=\*/subsystem=elytron/security-domain=\*}}. It is misleading because ManagementDomain capability exists in {{/host=master/subsystem=elytron/security-domain=*}}.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 07:19:00 2018
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 3 Jan 2018 07:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3485) Misleading
 failure-description for capabilities in domain
In-Reply-To: <JIRA.12726347.1514981870000@Atlassian.JIRA>
References: <JIRA.12726347.1514981870000@Atlassian.JIRA>
	<JIRA.12726347.1514981870000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726347.1514981870000.25280.1514981940473@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated WFCORE-3485:
---------------------------------
    Affects Version/s: 3.0.10.Final


> Misleading failure-description for capabilities in domain
> ---------------------------------------------------------
>
>                 Key: WFCORE-3485
>                 URL: https://issues.jboss.org/browse/WFCORE-3485
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.10.Final
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>
> In case when configuration in domain.xml tries to reference any capability from host.xml (or vice versa), but should not be able to reference it then it correctly fails, but there is failure-description which is misleading. 
> Start domain with default domain.xml and host.xml and run following CLI command and see:
> {code}
> /profile=full/subsystem=elytron/http-authentication-factory=some-factory:add(http-server-mechanism-factory=global,security-domain=ManagementDomain)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.security.security-domain.ManagementDomain in context 'profile=full'; Possible registration points for this capability: 
> 		/host=master/subsystem=elytron/security-domain=*
> 		/profile=*/subsystem=elytron/security-domain=*"},
>     "rolled-back" => true
> }
> {code}
> It should show only correct registration point {{/profile=\*/subsystem=elytron/security-domain=\*}}. It is misleading because ManagementDomain capability exists in {{/host=master/subsystem=elytron/security-domain=*}}.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 07:27:00 2018
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 3 Jan 2018 07:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1475) Empty username for
 FormAuthenticationMechanism causes IllegalArgumentException
In-Reply-To: <JIRA.12726352.1514982408000@Atlassian.JIRA>
References: <JIRA.12726352.1514982408000@Atlassian.JIRA>
	<JIRA.12726352.1514982408040@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726352.1514982408000.25362.1514982420625@Atlassian.JIRA>

Ondrej Lukas created ELY-1475:
---------------------------------

             Summary: Empty username for FormAuthenticationMechanism causes IllegalArgumentException
                 Key: ELY-1475
                 URL: https://issues.jboss.org/browse/ELY-1475
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Ondrej Lukas
            Assignee: Darran Lofthouse


In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username.

See exception:
{code}
ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException
	at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60)
	at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
	at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106)
	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
	at java.lang.Thread.run(Thread.java:748)
{code}

It seems that [1] should also check {{username.length() == 0}}.

[1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3ecae6be7ce1c9b96ab642ddc4ad/src/main/java/org/wildfly/security/http/impl/FormAuthenticationMechanism.java#L165




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 07:28:00 2018
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 3 Jan 2018 07:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1475) Empty username for
 FormAuthenticationMechanism causes IllegalArgumentException
In-Reply-To: <JIRA.12726352.1514982408000@Atlassian.JIRA>
References: <JIRA.12726352.1514982408000@Atlassian.JIRA>
	<JIRA.12726352.1514982408000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726352.1514982408000.25365.1514982480248@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-1475:
------------------------------
    Affects Version/s: 1.2.0.Beta11


> Empty username for FormAuthenticationMechanism causes IllegalArgumentException
> ------------------------------------------------------------------------------
>
>                 Key: ELY-1475
>                 URL: https://issues.jboss.org/browse/ELY-1475
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>
> In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username.
> See exception:
> {code}
> ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException
> 	at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {code}
> It seems that [1] should also check {{username.length() == 0}}.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3ecae6be7ce1c9b96ab642ddc4ad/src/main/java/org/wildfly/security/http/impl/FormAuthenticationMechanism.java#L165



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 07:28:00 2018
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Wed, 3 Jan 2018 07:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1475) Empty username for
 FormAuthenticationMechanism causes IllegalArgumentException
In-Reply-To: <JIRA.12726352.1514982408000@Atlassian.JIRA>
References: <JIRA.12726352.1514982408000@Atlassian.JIRA>
	<JIRA.12726352.1514982408000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726352.1514982408000.25368.1514982480317@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas reassigned ELY-1475:
---------------------------------

    Assignee:     (was: Darran Lofthouse)


> Empty username for FormAuthenticationMechanism causes IllegalArgumentException
> ------------------------------------------------------------------------------
>
>                 Key: ELY-1475
>                 URL: https://issues.jboss.org/browse/ELY-1475
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Ondrej Lukas
>
> In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username.
> See exception:
> {code}
> ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException
> 	at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {code}
> It seems that [1] should also check {{username.length() == 0}}.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3ecae6be7ce1c9b96ab642ddc4ad/src/main/java/org/wildfly/security/http/impl/FormAuthenticationMechanism.java#L165



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 07:31:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 3 Jan 2018 07:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1475) Empty username for
 FormAuthenticationMechanism causes IllegalArgumentException
In-Reply-To: <JIRA.12726352.1514982408000@Atlassian.JIRA>
References: <JIRA.12726352.1514982408000@Atlassian.JIRA>
	<JIRA.12726352.1514982408000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726352.1514982408000.25407.1514982660712@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned ELY-1475:
-------------------------------------

    Assignee: Darran Lofthouse


> Empty username for FormAuthenticationMechanism causes IllegalArgumentException
> ------------------------------------------------------------------------------
>
>                 Key: ELY-1475
>                 URL: https://issues.jboss.org/browse/ELY-1475
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta12
>
>
> In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username.
> See exception:
> {code}
> ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException
> 	at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {code}
> It seems that [1] should also check {{username.length() == 0}}.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3ecae6be7ce1c9b96ab642ddc4ad/src/main/java/org/wildfly/security/http/impl/FormAuthenticationMechanism.java#L165



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 07:31:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 3 Jan 2018 07:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1475) Empty username for
 FormAuthenticationMechanism causes IllegalArgumentException
In-Reply-To: <JIRA.12726352.1514982408000@Atlassian.JIRA>
References: <JIRA.12726352.1514982408000@Atlassian.JIRA>
	<JIRA.12726352.1514982408000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726352.1514982408000.25414.1514982660884@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1475:
----------------------------------
    Fix Version/s: 1.2.0.Beta12


> Empty username for FormAuthenticationMechanism causes IllegalArgumentException
> ------------------------------------------------------------------------------
>
>                 Key: ELY-1475
>                 URL: https://issues.jboss.org/browse/ELY-1475
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta12
>
>
> In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username.
> See exception:
> {code}
> ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException
> 	at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {code}
> It seems that [1] should also check {{username.length() == 0}}.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3ecae6be7ce1c9b96ab642ddc4ad/src/main/java/org/wildfly/security/http/impl/FormAuthenticationMechanism.java#L165



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 07:51:00 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Wed, 3 Jan 2018 07:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3486) "shutdown --help" does not
 declare that '--timeout' is only relevant to standalone servers
In-Reply-To: <JIRA.12726358.1514983852000@Atlassian.JIRA>
References: <JIRA.12726358.1514983852000@Atlassian.JIRA>
	<JIRA.12726358.1514983852854@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726358.1514983852000.25529.1514983860568@Atlassian.JIRA>

Yeray Borges created WFCORE-3486:
------------------------------------

             Summary: "shutdown --help" does not declare that '--timeout' is only relevant to standalone servers 
                 Key: WFCORE-3486
                 URL: https://issues.jboss.org/browse/WFCORE-3486
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
    Affects Versions: 4.0.0.Alpha5
            Reporter: Yeray Borges
            Assignee: Yeray Borges
            Priority: Minor


In standalone mode shutdown can be used with a timeout in order to execute a graceful shutdown of the server. 
In domain mode this attribute is not used and it is not taken into account when the domian is shutting down.

The CLI output of 'shutdown --help' does not declare that '--timeout' is only relevant to standalone servers and is it not allowed if '--host' is used. The handler should reject that combo.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 07:51:00 2018
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Wed, 3 Jan 2018 07:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1475) Empty username for
 FormAuthenticationMechanism causes IllegalArgumentException
In-Reply-To: <JIRA.12726352.1514982408000@Atlassian.JIRA>
References: <JIRA.12726352.1514982408000@Atlassian.JIRA>
	<JIRA.12726352.1514982408000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726352.1514982408000.25535.1514983860686@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-1475:
----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Empty username for FormAuthenticationMechanism causes IllegalArgumentException
> ------------------------------------------------------------------------------
>
>                 Key: ELY-1475
>                 URL: https://issues.jboss.org/browse/ELY-1475
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>             Fix For: 1.2.0.Beta12
>
>
> In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username.
> See exception:
> {code}
> ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException
> 	at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {code}
> It seems that [1] should also check {{username.length() == 0}}.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3ecae6be7ce1c9b96ab642ddc4ad/src/main/java/org/wildfly/security/http/impl/FormAuthenticationMechanism.java#L165



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 08:07:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 3 Jan 2018 08:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3457) Reduce Classes in the
	Elytron Subsystem
In-Reply-To: <JIRA.12724639.1513168462000@Atlassian.JIRA>
References: <JIRA.12724639.1513168462000@Atlassian.JIRA>
	<JIRA.12724639.1513168462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724639.1513168462000.25669.1514984820756@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-3457:
-------------------------------------
    Description: 
We currently compile to 323 classes, as this subsystem is almost exclusively about management representation (Model and XML) rather than implementation all 323 of these classes will need to be loaded when the subsystem is installed.

By switching to builders where we can instead of anonymous inner classes and possibly using more common classes I believe a reasonable early target could be drop this to 200 to 250 classes so possibly up to a 33% saving.

Even without restructuring our resource registrations a lot of our classes exist just to logically group related resources rather than any other purpose.

  was:
We currently compile to 308 classes, as this subsystem is almost exclusively about management representation (Model and XML) rather than implementation all 308 of these classes will need to be loaded when the subsystem is installed.

By switching to builders where we can instead of anonymous inner classes and possibly using more common classes I believe a reasonable early target could be drop this to 200 to 250 classes so possibly up to a 33% saving.

Even without restructuring our resource registrations a lot of our classes exist just to logically group related resources rather than any other purpose.



> Reduce Classes in the Elytron Subsystem
> ---------------------------------------
>
>                 Key: WFCORE-3457
>                 URL: https://issues.jboss.org/browse/WFCORE-3457
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha6
>
>
> We currently compile to 323 classes, as this subsystem is almost exclusively about management representation (Model and XML) rather than implementation all 323 of these classes will need to be loaded when the subsystem is installed.
> By switching to builders where we can instead of anonymous inner classes and possibly using more common classes I believe a reasonable early target could be drop this to 200 to 250 classes so possibly up to a 33% saving.
> Even without restructuring our resource registrations a lot of our classes exist just to logically group related resources rather than any other purpose.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 08:11:00 2018
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Wed, 3 Jan 2018 08:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3487) ValueTypeCompletionTestCase
 test renaming
In-Reply-To: <JIRA.12726363.1514985022000@Atlassian.JIRA>
References: <JIRA.12726363.1514985022000@Atlassian.JIRA>
	<JIRA.12726363.1514985022077@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726363.1514985022000.25673.1514985060197@Atlassian.JIRA>

Miroslav Novak created WFCORE-3487:
--------------------------------------

             Summary: ValueTypeCompletionTestCase test renaming
                 Key: WFCORE-3487
                 URL: https://issues.jboss.org/browse/WFCORE-3487
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
    Affects Versions: 4.0.0.Alpha5
            Reporter: Miroslav Novak
            Priority: Optional


ValueTypeCompletionTestCase contains test names which does not imply what the test is doing. Rename those tests.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 08:11:00 2018
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Wed, 3 Jan 2018 08:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3487) ValueTypeCompletionTestCase
 test renaming
In-Reply-To: <JIRA.12726363.1514985022000@Atlassian.JIRA>
References: <JIRA.12726363.1514985022000@Atlassian.JIRA>
	<JIRA.12726363.1514985022000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726363.1514985022000.25676.1514985060305@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak reassigned WFCORE-3487:
--------------------------------------

    Assignee: Miroslav Novak


> ValueTypeCompletionTestCase test renaming
> -----------------------------------------
>
>                 Key: WFCORE-3487
>                 URL: https://issues.jboss.org/browse/WFCORE-3487
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Miroslav Novak
>            Assignee: Miroslav Novak
>            Priority: Optional
>
> ValueTypeCompletionTestCase contains test names which does not imply what the test is doing. Rename those tests.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 08:43:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 3 Jan 2018 08:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1476) The project current contains
 27 instances of Security::getProviders
In-Reply-To: <JIRA.12726370.1514986931000@Atlassian.JIRA>
References: <JIRA.12726370.1514986931000@Atlassian.JIRA>
	<JIRA.12726370.1514986931608@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726370.1514986931000.25986.1514986980395@Atlassian.JIRA>

Darran Lofthouse created ELY-1476:
-------------------------------------

             Summary: The project current contains 27 instances of Security::getProviders
                 Key: ELY-1476
                 URL: https://issues.jboss.org/browse/ELY-1476
             Project: WildFly Elytron
          Issue Type: Bug
          Components: API / SPI
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.2.0.Beta12






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 08:44:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 3 Jan 2018 08:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1476) The project current contains
 27 instances of Security::getProviders
In-Reply-To: <JIRA.12726370.1514986932000@Atlassian.JIRA>
References: <JIRA.12726370.1514986932000@Atlassian.JIRA>
	<JIRA.12726370.1514986932000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726370.1514986932000.25989.1514987040239@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1476:
----------------------------------
    Description: Each of these ens up being backed by their own lambda, if we add a Supplier<Provider[]> REGISTERED_PROVDERS = Security::getProviders to ProviderUtil all can share this.


> The project current contains 27 instances of Security::getProviders
> -------------------------------------------------------------------
>
>                 Key: ELY-1476
>                 URL: https://issues.jboss.org/browse/ELY-1476
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta12
>
>
> Each of these ens up being backed by their own lambda, if we add a Supplier<Provider[]> REGISTERED_PROVDERS = Security::getProviders to ProviderUtil all can share this.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 08:46:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 3 Jan 2018 08:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1476) The project current contains
 27 instances of Security::getProviders
In-Reply-To: <JIRA.12726370.1514986932000@Atlassian.JIRA>
References: <JIRA.12726370.1514986932000@Atlassian.JIRA>
	<JIRA.12726370.1514986932000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726370.1514986932000.26002.1514987160111@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1476?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1476:
----------------------------------
    Description: Each of these ens up being backed by their own lambda, if we add a Supplier<Provider[]> INSTALLED_PROVDERS = Security::getProviders to ProviderUtil all can share this.  (was: Each of these ens up being backed by their own lambda, if we add a Supplier<Provider[]> REGISTERED_PROVDERS = Security::getProviders to ProviderUtil all can share this.)


> The project current contains 27 instances of Security::getProviders
> -------------------------------------------------------------------
>
>                 Key: ELY-1476
>                 URL: https://issues.jboss.org/browse/ELY-1476
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta12
>
>
> Each of these ens up being backed by their own lambda, if we add a Supplier<Provider[]> INSTALLED_PROVDERS = Security::getProviders to ProviderUtil all can share this.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 08:56:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 3 Jan 2018 08:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2189) Business central shows
 redundant warning messages from validation.
In-Reply-To: <JIRA.12725521.1513620337000@Atlassian.JIRA>
References: <JIRA.12725521.1513620337000@Atlassian.JIRA>
	<JIRA.12725521.1513620337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725521.1513620337000.26050.1514987760318@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2189:
--------------------------------
    Tester: Jozef Marko


> Business central shows redundant warning messages from validation.
> ------------------------------------------------------------------
>
>                 Key: DROOLS-2189
>                 URL: https://issues.jboss.org/browse/DROOLS-2189
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>            Reporter: Toni Rikkola
>            Assignee: Toni Rikkola
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 09:19:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 3 Jan 2018 09:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1477) LegacyPropertiesSecurityRealm
 uses a stream with a filter and a forEach that could be rewritten as a
 simple for loop
In-Reply-To: <JIRA.12726380.1514989118000@Atlassian.JIRA>
References: <JIRA.12726380.1514989118000@Atlassian.JIRA>
	<JIRA.12726380.1514989118634@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726380.1514989118000.26159.1514989140263@Atlassian.JIRA>

Darran Lofthouse created ELY-1477:
-------------------------------------

             Summary: LegacyPropertiesSecurityRealm uses a stream with a filter and a forEach that could be rewritten as a simple for loop
                 Key: ELY-1477
                 URL: https://issues.jboss.org/browse/ELY-1477
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Realms
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.2.0.Beta12






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 09:29:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 3 Jan 2018 09:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest
 fails on IBM JDK
In-Reply-To: <JIRA.12702872.1500553419000@Atlassian.JIRA>
References: <JIRA.12702872.1500553419000@Atlassian.JIRA>
	<JIRA.12702872.1500553419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702872.1500553419000.26177.1514989740446@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1295:
----------------------------
    Priority: Critical  (was: Major)


> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
>                 Key: ELY-1295
>                 URL: https://issues.jboss.org/browse/ELY-1295
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Peter Palaga
>            Priority: Critical
>              Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>  
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>  
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> 	at java.lang.Class.forNameImpl(Native Method)
> 	at java.lang.Class.forName(Class.java:278)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	at java.security.KeyStore.getEntry(KeyStore.java:1532)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> 	... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/72967600a98dee832e151ff8f6fb64af0a84bd14#diff-faa6b27609575ef29472bcc75c87eb36R87



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 09:29:05 2018
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 3 Jan 2018 09:29:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6695) JspTagTestCase fails on
	Windows
In-Reply-To: <JIRA.12630419.1465485615000@Atlassian.JIRA>
References: <JIRA.12630419.1465485615000@Atlassian.JIRA>
	<JIRA.12630419.1465485615000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12630419.1465485615000.26189.1514989745819@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-6695:
------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/10735  (was: https://github.com/wildfly/wildfly/pull/8958)


> JspTagTestCase fails on Windows
> -------------------------------
>
>                 Key: WFLY-6695
>                 URL: https://issues.jboss.org/browse/WFLY-6695
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.1.0.CR1
>         Environment: Windows 10, Oracle JDK 1.8.0_92
>            Reporter: Frank Langelage
>
> build.bat clean install failed with
> -------------------------------------------------------------------------------
> Test set: org.jboss.as.test.integration.jsp.JspTagTestCase
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.768 sec <<< FAILURE! - in org.jboss.as.test.integration.jsp.JspTagTestCase
> test(org.jboss.as.test.integration.jsp.JspTagTestCase)  Time elapsed: 0.486 sec  <<< FAILURE!
> org.junit.ComparisonFailure: expected:<This is a header[
> <div>tag</div>
> Static content]
> > but was:<This is a header[
> <div>tag</div>
> Static content
> ]
> >
> 	at org.junit.Assert.assertEquals(Assert.java:115)
> 	at org.junit.Assert.assertEquals(Assert.java:144)
> 	at org.jboss.as.test.integration.jsp.JspTagTestCase.test(JspTagTestCase.java:67)
> Replacing all occurence of "\n" with System.getProperty("line.separator") in the expected String solved the problem for me.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 09:38:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 3 Jan 2018 09:38:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest
 fails on IBM JDK
In-Reply-To: <JIRA.12702872.1500553419000@Atlassian.JIRA>
References: <JIRA.12702872.1500553419000@Atlassian.JIRA>
	<JIRA.12702872.1500553419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702872.1500553419000.26262.1514990281597@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-1295:
-------------------------------

    Assignee: Jan Kalina


> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
>                 Key: ELY-1295
>                 URL: https://issues.jboss.org/browse/ELY-1295
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>  
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>  
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> 	at java.lang.Class.forNameImpl(Native Method)
> 	at java.lang.Class.forName(Class.java:278)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	at java.security.KeyStore.getEntry(KeyStore.java:1532)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> 	... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/72967600a98dee832e151ff8f6fb64af0a84bd14#diff-faa6b27609575ef29472bcc75c87eb36R87



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 09:38:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 3 Jan 2018 09:38:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest
 fails on IBM JDK
In-Reply-To: <JIRA.12702872.1500553419000@Atlassian.JIRA>
References: <JIRA.12702872.1500553419000@Atlassian.JIRA>
	<JIRA.12702872.1500553419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702872.1500553419000.26265.1514990281680@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1295:
----------------------------
    Component/s: Credential Store


> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
>                 Key: ELY-1295
>                 URL: https://issues.jboss.org/browse/ELY-1295
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>  
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>  
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> 	at java.lang.Class.forNameImpl(Native Method)
> 	at java.lang.Class.forName(Class.java:278)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	at java.security.KeyStore.getEntry(KeyStore.java:1532)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> 	... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/72967600a98dee832e151ff8f6fb64af0a84bd14#diff-faa6b27609575ef29472bcc75c87eb36R87



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 09:46:00 2018
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Wed, 3 Jan 2018 09:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6695) JspTagTestCase fails on
	Windows
In-Reply-To: <JIRA.12630419.1465485615000@Atlassian.JIRA>
References: <JIRA.12630419.1465485615000@Atlassian.JIRA>
	<JIRA.12630419.1465485615000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12630419.1465485615000.26299.1514990760601@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-6695:
---------------------------------

    Assignee: Tomaz Cerar


> JspTagTestCase fails on Windows
> -------------------------------
>
>                 Key: WFLY-6695
>                 URL: https://issues.jboss.org/browse/WFLY-6695
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 10.1.0.CR1
>         Environment: Windows 10, Oracle JDK 1.8.0_92
>            Reporter: Frank Langelage
>            Assignee: Tomaz Cerar
>
> build.bat clean install failed with
> -------------------------------------------------------------------------------
> Test set: org.jboss.as.test.integration.jsp.JspTagTestCase
> -------------------------------------------------------------------------------
> Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.768 sec <<< FAILURE! - in org.jboss.as.test.integration.jsp.JspTagTestCase
> test(org.jboss.as.test.integration.jsp.JspTagTestCase)  Time elapsed: 0.486 sec  <<< FAILURE!
> org.junit.ComparisonFailure: expected:<This is a header[
> <div>tag</div>
> Static content]
> > but was:<This is a header[
> <div>tag</div>
> Static content
> ]
> >
> 	at org.junit.Assert.assertEquals(Assert.java:115)
> 	at org.junit.Assert.assertEquals(Assert.java:144)
> 	at org.jboss.as.test.integration.jsp.JspTagTestCase.test(JspTagTestCase.java:67)
> Replacing all occurence of "\n" with System.getProperty("line.separator") in the expected String solved the problem for me.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 10:01:00 2018
From: issues at jboss.org (=?UTF-8?Q?Rene_B=C3=B6ing_=28JIRA=29?=)
Date: Wed, 3 Jan 2018 10:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3488) Add support for custom
 syslog message formatting
In-Reply-To: <JIRA.12726385.1514991658000@Atlassian.JIRA>
References: <JIRA.12726385.1514991658000@Atlassian.JIRA>
	<JIRA.12726385.1514991658184@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726385.1514991658000.26421.1514991660194@Atlassian.JIRA>

Rene B?ing created WFCORE-3488:
----------------------------------

             Summary: Add support for custom syslog message formatting
                 Key: WFCORE-3488
                 URL: https://issues.jboss.org/browse/WFCORE-3488
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Logging
            Reporter: Rene B?ing
            Assignee: James Perkins


Hello,
it would be great, if the syslog logging handler would be able to use a custom message formatter, just like the other logging handlers do. This would be much appreciated, since i wouldn't need to implement my own logic to append for example a stacktrace to a message.

Kind regards,
Rene



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan  3 10:05:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 3 Jan 2018 10:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3488) Add support for custom
 syslog message formatting
In-Reply-To: <JIRA.12726385.1514991658000@Atlassian.JIRA>
References: <JIRA.12726385.1514991658000@Atlassian.JIRA>
	<JIRA.12726385.1514991658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726385.1514991658000.26454.1514991900515@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509031#comment-13509031 ] 

David Lloyd commented on WFCORE-3488:
-------------------------------------

Note that the syslog handler already supports a formatter; it just seems to be missing from the resource description.

> Add support for custom syslog message formatting
> ------------------------------------------------
>
>                 Key: WFCORE-3488
>                 URL: https://issues.jboss.org/browse/WFCORE-3488
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Logging
>            Reporter: Rene B?ing
>            Assignee: James Perkins
>
> Hello,
> it would be great, if the syslog logging handler would be able to use a custom message formatter, just like the other logging handlers do. This would be much appreciated, since i wouldn't need to implement my own logic to append for example a stacktrace to a message.
> Kind regards,
> Rene



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan  3 10:08:01 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 3 Jan 2018 10:08:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2207) Validation and Verification
 panel is missing
In-Reply-To: <JIRA.12726386.1514992053000@Atlassian.JIRA>
References: <JIRA.12726386.1514992053000@Atlassian.JIRA>
	<JIRA.12726386.1514992053337@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726386.1514992053000.26482.1514992081021@Atlassian.JIRA>

Jozef Marko created DROOLS-2207:
-----------------------------------

             Summary: Validation and Verification panel is missing
                 Key: DROOLS-2207
                 URL: https://issues.jboss.org/browse/DROOLS-2207
             Project: Drools
          Issue Type: Bug
          Components: Guided Decision Table Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis
            Priority: Critical


The Validation and Verification panel is missing. The server log contains error [1], however looking into the workbench war, all v&v jars seems to be present.

[1]
ERROR [org.drools.workbench.services.verifier.plugin.backend.VerifierWebWorkerServlet] (default task-119) Failed to load verifier web worker.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 10:10:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 3 Jan 2018 10:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2207) Validation and Verification
 panel is missing
In-Reply-To: <JIRA.12726386.1514992053000@Atlassian.JIRA>
References: <JIRA.12726386.1514992053000@Atlassian.JIRA>
	<JIRA.12726386.1514992053000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726386.1514992053000.26491.1514992200178@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis reassigned DROOLS-2207:
--------------------------------------

    Assignee: Toni Rikkola  (was: Michael Anstis)


> Validation and Verification panel is missing
> --------------------------------------------
>
>                 Key: DROOLS-2207
>                 URL: https://issues.jboss.org/browse/DROOLS-2207
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Toni Rikkola
>            Priority: Critical
>
> The Validation and Verification panel is missing. The server log contains error [1], however looking into the workbench war, all v&v jars seems to be present.
> [1]
> ERROR [org.drools.workbench.services.verifier.plugin.backend.VerifierWebWorkerServlet] (default task-119) Failed to load verifier web worker.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 10:19:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 3 Jan 2018 10:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2208) Sometimes the agenda stops
 firing even if there are outstanding activations to be evaluated
In-Reply-To: <JIRA.12726390.1514992722000@Atlassian.JIRA>
References: <JIRA.12726390.1514992722000@Atlassian.JIRA>
	<JIRA.12726390.1514992722182@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726390.1514992722000.26522.1514992740872@Atlassian.JIRA>

Mario Fusco created DROOLS-2208:
-----------------------------------

             Summary: Sometimes the agenda stops firing even if there are outstanding activations to be evaluated
                 Key: DROOLS-2208
                 URL: https://issues.jboss.org/browse/DROOLS-2208
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Mario Fusco
            Assignee: Mario Fusco






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 10:22:00 2018
From: issues at jboss.org (Tanmay Kumar Pandey (JIRA))
Date: Wed, 3 Jan 2018 10:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1165) Syntax error on Java EE for
 6.4.0.Final (6.3.0.Final worked fine)
In-Reply-To: <JIRA.12618257.1462437964000@Atlassian.JIRA>
References: <JIRA.12618257.1462437964000@Atlassian.JIRA>
	<JIRA.12618257.1462437964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618257.1462437964000.26590.1514992920924@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509043#comment-13509043 ] 

Tanmay Kumar Pandey commented on DROOLS-1165:
---------------------------------------------

Hi Mario,

I'm getting the same errors while deploying rules on Wildfly 10.1.0 with JAVA EE 8. Drools version is 6.4

> Syntax error on Java EE for 6.4.0.Final (6.3.0.Final worked fine)
> -----------------------------------------------------------------
>
>                 Key: DROOLS-1165
>                 URL: https://issues.jboss.org/browse/DROOLS-1165
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.4.0.Final
>         Environment: Java EE 7, Wildfly
>            Reporter: Matteo Mortari
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: 20160505.syntaxerroronjavaeefor640f.zip
>
>
> Hello, not sure if this is actually a Drools issue, or just some compiler error due to some other dependencies issue. Anyhow attached reproducer contains a DRL syntactically correct, parses correctly 6.4.0.Final when not on Java EE. When on Java EE instead, fails to parse lamenting syntax error, snippet:
> {code}
> [ function valueSizeGEofvalueSizeGEof (line:42): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:42): The import java.util.stream.Collectors.groupingBy cannot be resolved
> valueSizeGEof (line:44): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:44): The import com.acme.testaccumulatestreamonjavaee.MapOfList.mapOfList cannot be resolved
> valueSizeGEof (line:46): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:46): The import com.acme.testaccumulatestreamonjavaee.EntryKey.entryKey cannot be resolved
> valueSizeGEof (line:52): Syntax error, parameterized types are only available if source level is 1.5 or greater
> valueSizeGEof (line:53): Type mismatch: cannot convert from Integer to int
> valueSizeGEof (line:54): Syntax error, parameterized types are only available if source level is 1.5 or greater
> valueSizeGEof (line:55): Syntax error, annotations are only available if source level is 1.5 or greater
> valueSizeGEof (line:56): Syntax error, parameterized types are only available if source level is 1.5 or greater
>  ]
> {code}
> Please notice if using 6.3.0.Final, on Java EE, is OK without errors.
> For the reproducer, maven {{clean test}} using profile {{wildfy82-embedded}}. I am using Arquillian to demonstrate the difference using version 6.3.0.Final Vs 6.4.0.Final.
> Can you kindly advise, please?
> Thank you
> Ciao
> MM



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 10:32:00 2018
From: issues at jboss.org (Tanmay Kumar Pandey (JIRA))
Date: Wed, 3 Jan 2018 10:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1165) Syntax error on Java EE for
 6.4.0.Final (6.3.0.Final worked fine)
In-Reply-To: <JIRA.12618257.1462437964000@Atlassian.JIRA>
References: <JIRA.12618257.1462437964000@Atlassian.JIRA>
	<JIRA.12618257.1462437964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618257.1462437964000.26659.1514993520385@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509048#comment-13509048 ] 

Tanmay Kumar Pandey commented on DROOLS-1165:
---------------------------------------------

I even tried upgrading to drools 7.5, I get same error regardless.
Three errors are Error: unable to resolve method using strict-mode: 
and 
text=Unable to Analyse Expression log.debug


> Syntax error on Java EE for 6.4.0.Final (6.3.0.Final worked fine)
> -----------------------------------------------------------------
>
>                 Key: DROOLS-1165
>                 URL: https://issues.jboss.org/browse/DROOLS-1165
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.4.0.Final
>         Environment: Java EE 7, Wildfly
>            Reporter: Matteo Mortari
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: 20160505.syntaxerroronjavaeefor640f.zip
>
>
> Hello, not sure if this is actually a Drools issue, or just some compiler error due to some other dependencies issue. Anyhow attached reproducer contains a DRL syntactically correct, parses correctly 6.4.0.Final when not on Java EE. When on Java EE instead, fails to parse lamenting syntax error, snippet:
> {code}
> [ function valueSizeGEofvalueSizeGEof (line:42): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:42): The import java.util.stream.Collectors.groupingBy cannot be resolved
> valueSizeGEof (line:44): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:44): The import com.acme.testaccumulatestreamonjavaee.MapOfList.mapOfList cannot be resolved
> valueSizeGEof (line:46): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:46): The import com.acme.testaccumulatestreamonjavaee.EntryKey.entryKey cannot be resolved
> valueSizeGEof (line:52): Syntax error, parameterized types are only available if source level is 1.5 or greater
> valueSizeGEof (line:53): Type mismatch: cannot convert from Integer to int
> valueSizeGEof (line:54): Syntax error, parameterized types are only available if source level is 1.5 or greater
> valueSizeGEof (line:55): Syntax error, annotations are only available if source level is 1.5 or greater
> valueSizeGEof (line:56): Syntax error, parameterized types are only available if source level is 1.5 or greater
>  ]
> {code}
> Please notice if using 6.3.0.Final, on Java EE, is OK without errors.
> For the reproducer, maven {{clean test}} using profile {{wildfy82-embedded}}. I am using Arquillian to demonstrate the difference using version 6.3.0.Final Vs 6.4.0.Final.
> Can you kindly advise, please?
> Thank you
> Ciao
> MM



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 10:32:00 2018
From: issues at jboss.org (Tanmay Kumar Pandey (JIRA))
Date: Wed, 3 Jan 2018 10:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1165) Syntax error on Java EE for
 6.4.0.Final (6.3.0.Final worked fine)
In-Reply-To: <JIRA.12618257.1462437964000@Atlassian.JIRA>
References: <JIRA.12618257.1462437964000@Atlassian.JIRA>
	<JIRA.12618257.1462437964000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12618257.1462437964000.26667.1514993520647@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509048#comment-13509048 ] 

Tanmay Kumar Pandey edited comment on DROOLS-1165 at 1/3/18 10:31 AM:
----------------------------------------------------------------------

I even tried upgrading to drools 7.5, I get same error regardless.
Three errors are Error: unable to resolve method using strict-mode: 
and 
text=Unable to Analyse Expression log.debug

and Syntax error, static imports are only available if source level is 1.5 or greater



was (Author: tkpandey001):
I even tried upgrading to drools 7.5, I get same error regardless.
Three errors are Error: unable to resolve method using strict-mode: 
and 
text=Unable to Analyse Expression log.debug


> Syntax error on Java EE for 6.4.0.Final (6.3.0.Final worked fine)
> -----------------------------------------------------------------
>
>                 Key: DROOLS-1165
>                 URL: https://issues.jboss.org/browse/DROOLS-1165
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 6.4.0.Final
>         Environment: Java EE 7, Wildfly
>            Reporter: Matteo Mortari
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: 20160505.syntaxerroronjavaeefor640f.zip
>
>
> Hello, not sure if this is actually a Drools issue, or just some compiler error due to some other dependencies issue. Anyhow attached reproducer contains a DRL syntactically correct, parses correctly 6.4.0.Final when not on Java EE. When on Java EE instead, fails to parse lamenting syntax error, snippet:
> {code}
> [ function valueSizeGEofvalueSizeGEof (line:42): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:42): The import java.util.stream.Collectors.groupingBy cannot be resolved
> valueSizeGEof (line:44): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:44): The import com.acme.testaccumulatestreamonjavaee.MapOfList.mapOfList cannot be resolved
> valueSizeGEof (line:46): Syntax error, static imports are only available if source level is 1.5 or greater
> valueSizeGEof (line:46): The import com.acme.testaccumulatestreamonjavaee.EntryKey.entryKey cannot be resolved
> valueSizeGEof (line:52): Syntax error, parameterized types are only available if source level is 1.5 or greater
> valueSizeGEof (line:53): Type mismatch: cannot convert from Integer to int
> valueSizeGEof (line:54): Syntax error, parameterized types are only available if source level is 1.5 or greater
> valueSizeGEof (line:55): Syntax error, annotations are only available if source level is 1.5 or greater
> valueSizeGEof (line:56): Syntax error, parameterized types are only available if source level is 1.5 or greater
>  ]
> {code}
> Please notice if using 6.3.0.Final, on Java EE, is OK without errors.
> For the reproducer, maven {{clean test}} using profile {{wildfy82-embedded}}. I am using Arquillian to demonstrate the difference using version 6.3.0.Final Vs 6.4.0.Final.
> Can you kindly advise, please?
> Thank you
> Ciao
> MM



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 10:41:00 2018
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Wed, 3 Jan 2018 10:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2189) Business central shows
 redundant warning messages from validation.
In-Reply-To: <JIRA.12725521.1513620337000@Atlassian.JIRA>
References: <JIRA.12725521.1513620337000@Atlassian.JIRA>
	<JIRA.12725521.1513620337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725521.1513620337000.26734.1514994060312@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toni Rikkola closed DROOLS-2189.
--------------------------------
    Resolution: Done


> Business central shows redundant warning messages from validation.
> ------------------------------------------------------------------
>
>                 Key: DROOLS-2189
>                 URL: https://issues.jboss.org/browse/DROOLS-2189
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>            Reporter: Toni Rikkola
>            Assignee: Toni Rikkola
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 10:56:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 3 Jan 2018 10:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3488) Add support for custom
 syslog message formatting
In-Reply-To: <JIRA.12726385.1514991658000@Atlassian.JIRA>
References: <JIRA.12726385.1514991658000@Atlassian.JIRA>
	<JIRA.12726385.1514991658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726385.1514991658000.26890.1514994960466@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509060#comment-13509060 ] 

James Perkins commented on WFCORE-3488:
---------------------------------------

This is something that's been planned, but we'd want to change all the attributes at once. The blocking issue is support for TLS connections. This is something that's being worked on though.

> Add support for custom syslog message formatting
> ------------------------------------------------
>
>                 Key: WFCORE-3488
>                 URL: https://issues.jboss.org/browse/WFCORE-3488
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Logging
>            Reporter: Rene B?ing
>            Assignee: James Perkins
>
> Hello,
> it would be great, if the syslog logging handler would be able to use a custom message formatter, just like the other logging handlers do. This would be much appreciated, since i wouldn't need to implement my own logic to append for example a stacktrace to a message.
> Kind regards,
> Rene



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan  3 10:56:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 3 Jan 2018 10:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3488) Add support for custom
 syslog message formatting
In-Reply-To: <JIRA.12726385.1514991658000@Atlassian.JIRA>
References: <JIRA.12726385.1514991658000@Atlassian.JIRA>
	<JIRA.12726385.1514991658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726385.1514991658000.26895.1514994960568@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed WFCORE-3488.
---------------------------------
    Resolution: Duplicate Issue


> Add support for custom syslog message formatting
> ------------------------------------------------
>
>                 Key: WFCORE-3488
>                 URL: https://issues.jboss.org/browse/WFCORE-3488
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Logging
>            Reporter: Rene B?ing
>            Assignee: James Perkins
>
> Hello,
> it would be great, if the syslog logging handler would be able to use a custom message formatter, just like the other logging handlers do. This would be much appreciated, since i wouldn't need to implement my own logic to append for example a stacktrace to a message.
> Kind regards,
> Rene



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan  3 12:25:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 3 Jan 2018 12:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2209) Error with accumulator and
 DataSource being used in rule units
In-Reply-To: <JIRA.12726413.1515000271000@Atlassian.JIRA>
References: <JIRA.12726413.1515000271000@Atlassian.JIRA>
	<JIRA.12726413.1515000271262@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726413.1515000271000.27268.1515000300164@Atlassian.JIRA>

Mario Fusco created DROOLS-2209:
-----------------------------------

             Summary: Error with accumulator and DataSource being used in rule units
                 Key: DROOLS-2209
                 URL: https://issues.jboss.org/browse/DROOLS-2209
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Mario Fusco
            Assignee: Mario Fusco






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 12:33:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 3 Jan 2018 12:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2209) Error with accumulator and
 DataSource being used in rule units
In-Reply-To: <JIRA.12726413.1515000271000@Atlassian.JIRA>
References: <JIRA.12726413.1515000271000@Atlassian.JIRA>
	<JIRA.12726413.1515000271000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726413.1515000271000.27280.1515000780052@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509097#comment-13509097 ] 

Mario Fusco commented on DROOLS-2209:
-------------------------------------

An accumulate on a rule unit's data source produces a NullPointerException in the BaseLeftTuple.getObject method

> Error with accumulator and DataSource being used in rule units
> --------------------------------------------------------------
>
>                 Key: DROOLS-2209
>                 URL: https://issues.jboss.org/browse/DROOLS-2209
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 17:04:00 2018
From: issues at jboss.org (Farah Juma (JIRA))
Date: Wed, 3 Jan 2018 17:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1478) Use System.lineSeparator()
 when generating PEM content to avoid issues on Windows
In-Reply-To: <JIRA.12726426.1515017009000@Atlassian.JIRA>
References: <JIRA.12726426.1515017009000@Atlassian.JIRA>
	<JIRA.12726426.1515017009121@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726426.1515017009000.27526.1515017040114@Atlassian.JIRA>

Farah Juma created ELY-1478:
-------------------------------

             Summary: Use System.lineSeparator() when generating PEM content to avoid issues on Windows
                 Key: ELY-1478
                 URL: https://issues.jboss.org/browse/ELY-1478
             Project: WildFly Elytron
          Issue Type: Task
          Components: Utils
            Reporter: Farah Juma
            Assignee: Farah Juma


A couple of the new tests in {{KeyStoresTestCase}} in the PR for WFCORE-3305 have started failing recently on Windows due to newline characters not being written properly in generated PEM files:

{code}
KeyStoresTestCase.testExportCertificatePem 	
java.lang.AssertionError: array lengths differed, expected.length=1068 actual.length=1050
    at org.wildfly.extension.elytron.KeyStoresTestCase.testExportCertificate(KeyStoresTestCase.java:566)
    at org.wildfly.extension.elytron.KeyStoresTestCase.testExportCertificatePem(KeyStoresTestCase.java:542)
{code}

{code}
KeyStoresTestCase.testGenerateCertificateSigningRequest
java.lang.AssertionError: array lengths differed, expected.length=782 actual.length=769
    at org.wildfly.extension.elytron.KeyStoresTestCase.testGenerateCertificateSigningRequest(KeyStoresTestCase.java:327)
{code}




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 21:13:00 2018
From: issues at jboss.org (Manjunath S Paramesan (JIRA))
Date: Wed, 3 Jan 2018 21:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2210) Drools 7.3.0 serialization
 null pointer exceptions with sliding windows
In-Reply-To: <JIRA.12726432.1515031979000@Atlassian.JIRA>
References: <JIRA.12726432.1515031979000@Atlassian.JIRA>
	<JIRA.12726432.1515031979253@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726432.1515031979000.27653.1515031980327@Atlassian.JIRA>

Manjunath S Paramesan created DROOLS-2210:
---------------------------------------------

             Summary: Drools 7.3.0 serialization null pointer exceptions with sliding windows
                 Key: DROOLS-2210
                 URL: https://issues.jboss.org/browse/DROOLS-2210
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.3.0.Final
            Reporter: Manjunath S Paramesan
            Assignee: Mario Fusco
            Priority: Critical


We have a fairly large rule-base with temporal reasoning and sliding windows. 

While serializing the drools session we observe random null pointer exceptions as see below:

Exception in thread "pool-92-thread-98" java.lang.NullPointerException
	at org.drools.core.rule.SlidingTimeWindow$BehaviorJobContextTimerOutputMarshaller.serialize(SlidingTimeWindow.java:323)
	at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.writeTimers(ProtobufOutputMarshaller.java:880)
	at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.serializeSession(ProtobufOutputMarshaller.java:210)
	at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.writeSession(ProtobufOutputMarshaller.java:118)
	at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:162)
	at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:146)
	at com.mlnms.common.fmwk.drools.impl.DroolsClientImpl.backupKieSession(DroolsClientImpl.java:743)
	at com.mlnms.common.fmwk.drools.impl.DroolsClientImpl.lambda$processStatefulEvents$0(DroolsClientImpl.java:506)
	at java.lang.Thread.run(Thread.java:745)
	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)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan  3 22:21:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 3 Jan 2018 22:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2251) ObjectTypeValidator should
 not implement AllowedValuesValidator
In-Reply-To: <JIRA.12674018.1485889380000@Atlassian.JIRA>
References: <JIRA.12674018.1485889380000@Atlassian.JIRA>
	<JIRA.12674018.1485889380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674018.1485889380000.27656.1515036060221@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-2251:
----------------------------------------

    Assignee: Brian Stansberry


> ObjectTypeValidator should not implement AllowedValuesValidator
> ---------------------------------------------------------------
>
>                 Key: WFCORE-2251
>                 URL: https://issues.jboss.org/browse/WFCORE-2251
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> ObjectTypeValidator is incorrectly implementing AllowedValuesValidator and should not implement it at all.
> The values returned from an AllowedValuesValidator are meant to be an enumeration of the *complete* legal values for the attribute. ObjectTypeValidator is simply returning the legal keys for the fields in the object, which are not complete legal values.
> The result of this is any attribute that uses this validator (which all complex objects probably do) will report bogus and unnecessary data in the read-resource-description "allowed-values" metadata. Unnecessary because the description of the attribute already includes full details of the fields via the "value-type" metadata.
> I'm classifying this as minor because the bogus metadata likely does no harm.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 01:29:00 2018
From: issues at jboss.org (Jive JIRA Integration (JIRA))
Date: Thu, 4 Jan 2018 01:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9636) EJB lookup over HTTP times
 out connection after 60 seconds
In-Reply-To: <JIRA.12725992.1513958595000@Atlassian.JIRA>
References: <JIRA.12725992.1513958595000@Atlassian.JIRA>
	<JIRA.12725992.1513958595000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725992.1513958595000.27832.1515047340288@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jive JIRA Integration updated WFLY-9636:
----------------------------------------
    Forum Reference: https://developer.jboss.org/message/979001#979001


> EJB lookup over HTTP times out connection after 60 seconds
> ----------------------------------------------------------
>
>                 Key: WFLY-9636
>                 URL: https://issues.jboss.org/browse/WFLY-9636
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, IO, Naming
>    Affects Versions: 11.0.0.Final
>         Environment: I work with https://developer.jboss.org/people/jaikiran on https://developer.jboss.org/thread/276635 so my Wildfly 11 environment has this fix in it.
>            Reporter: peter craddock
>            Assignee: Stuart Douglas
>
> The code examples and trace logging can be found here https://developer.jboss.org/thread/276840  
> I have work round the problem but was asked to raise it for further investigation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 02:51:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 4 Jan 2018 02:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1479) Coverity,
 Missing call to superclass in AbstractGssapiMechanism
In-Reply-To: <JIRA.12726440.1515052215000@Atlassian.JIRA>
References: <JIRA.12726440.1515052215000@Atlassian.JIRA>
	<JIRA.12726440.1515052215217@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726440.1515052215000.27995.1515052260135@Atlassian.JIRA>

Martin Choma created ELY-1479:
---------------------------------

             Summary: Coverity, Missing call to superclass in AbstractGssapiMechanism
                 Key: ELY-1479
                 URL: https://issues.jboss.org/browse/ELY-1479
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Authentication Mechanisms
    Affects Versions: 1.2.0.Beta11
            Reporter: Martin Choma


super.getNegotiatedProperty() is not called in AbstractGssapiMechanism#getNegotiatedProperty, although it is called in similar cases in Gs2SaslServer, DigestSaslServer, AnonymousSaslClient.

{code:java|title=AbstractGssapiMechanism.java}
    @Override
    public Object getNegotiatedProperty(String propName) {
        assertComplete();

        switch (propName) {
            case Sasl.QOP:
                return selectedQop.getName();
            case Sasl.MAX_BUFFER:
                return Integer.toString(actualMaxReceiveBuffer != 0 ? actualMaxReceiveBuffer : configuredMaxReceiveBuffer);
            case Sasl.RAW_SEND_SIZE:
                return Integer.toString(maxBuffer);
        }

        return null;
    }
{code}

This coverity report is not caused by recent change in AbstractGssapiMechanism but rather Gs2SaslServer and DigestSaslServer

[1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847684&defectInstanceId=9457508&mergedDefectId=1463150



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 02:57:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 4 Jan 2018 02:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2207) Validation and Verification
 panel is missing
In-Reply-To: <JIRA.12726386.1514992053000@Atlassian.JIRA>
References: <JIRA.12726386.1514992053000@Atlassian.JIRA>
	<JIRA.12726386.1514992053000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726386.1514992053000.28005.1515052620112@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2207:
--------------------------------
    Affects Version/s: 7.5.0.Final


> Validation and Verification panel is missing
> --------------------------------------------
>
>                 Key: DROOLS-2207
>                 URL: https://issues.jboss.org/browse/DROOLS-2207
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.5.0.Final, 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Toni Rikkola
>            Priority: Critical
>
> The Validation and Verification panel is missing. The server log contains error [1], however looking into the workbench war, all v&v jars seems to be present.
> [1]
> ERROR [org.drools.workbench.services.verifier.plugin.backend.VerifierWebWorkerServlet] (default task-119) Failed to load verifier web worker.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 03:11:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 4 Jan 2018 03:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1480) Coverity,
 Explicit null dereferenced in FileSystemSecurityRealm
In-Reply-To: <JIRA.12726441.1515053416000@Atlassian.JIRA>
References: <JIRA.12726441.1515053416000@Atlassian.JIRA>
	<JIRA.12726441.1515053416971@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726441.1515053416000.28027.1515053460208@Atlassian.JIRA>

Martin Choma created ELY-1480:
---------------------------------

             Summary: Coverity, Explicit null dereferenced in FileSystemSecurityRealm
                 Key: ELY-1480
                 URL: https://issues.jboss.org/browse/ELY-1480
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Authentication Client
    Affects Versions: 1.2.0.Beta11
            Reporter: Martin Choma


There are 2 occurences of call to PasswordFactory.getInstance(algorithm) in FileSystemSecurityRealm where algorithm can be null, because algorithm is optional in wildfly-config.xml

{code:xml|title=elytron-1_0_1.xsd}
    <xsd:complexType name="credential-type">
        <xsd:simpleContent>
            <xsd:extension base="xsd:string">
                <xsd:attribute name="algorithm" type="xsd:string" use="optional"/>
                <xsd:attribute name="format" type="xsd:string" use="optional"/>
            </xsd:extension>
        </xsd:simpleContent>
    </xsd:complexType>

    <xsd:complexType name="otp-credential-type">
        <xsd:simpleContent>
            <xsd:extension base="xsd:string">
                <xsd:attribute name="algorithm" type="xsd:string" use="optional"/>
                <xsd:attribute name="hash" type="xsd:string" use="optional"/>
                <xsd:attribute name="seed" type="xsd:string" use="optional"/>
                <xsd:attribute name="sequence" type="xsd:string" use="optional"/>
            </xsd:extension>
        </xsd:simpleContent>
    </xsd:complexType>
{code}

Algorithm is dereferenced in PasswordFactory.getInstance(algorithm) down in 
{code:java|title=java.security.Provider$ServiceKey.java}
        private ServiceKey(String type, String algorithm, boolean intern) {
            this.type = type;
            this.originalAlgorithm = algorithm;
            algorithm = algorithm.toUpperCase(ENGLISH);
            this.algorithm = intern ? algorithm.intern() : algorithm;
        }
{code}

[1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847809&defectInstanceId=9457601&mergedDefectId=1463442
[2] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847809&defectInstanceId=9457602&mergedDefectId=1463441




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 03:54:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 4 Jan 2018 03:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1481) Coverity,
 Explicit null dereferenced in FileSystemSecurityRealm
In-Reply-To: <JIRA.12726445.1515055991000@Atlassian.JIRA>
References: <JIRA.12726445.1515055991000@Atlassian.JIRA>
	<JIRA.12726445.1515055991807@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726445.1515055991000.28170.1515056040246@Atlassian.JIRA>

Martin Choma created ELY-1481:
---------------------------------

             Summary: Coverity, Explicit null dereferenced in FileSystemSecurityRealm
                 Key: ELY-1481
                 URL: https://issues.jboss.org/browse/ELY-1481
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Authentication Client
    Affects Versions: 1.2.0.Beta11
            Reporter: Martin Choma


There are 2 occurences of call to PasswordFactory.getInstance(algorithm) in FileSystemSecurityRealm where algorithm can be null, because algorithm is optional in wildfly-config.xml

{code:xml|title=elytron-1_0_1.xsd}
    <xsd:complexType name="credential-type">
        <xsd:simpleContent>
            <xsd:extension base="xsd:string">
                <xsd:attribute name="algorithm" type="xsd:string" use="optional"/>
                <xsd:attribute name="format" type="xsd:string" use="optional"/>
            </xsd:extension>
        </xsd:simpleContent>
    </xsd:complexType>

    <xsd:complexType name="otp-credential-type">
        <xsd:simpleContent>
            <xsd:extension base="xsd:string">
                <xsd:attribute name="algorithm" type="xsd:string" use="optional"/>
                <xsd:attribute name="hash" type="xsd:string" use="optional"/>
                <xsd:attribute name="seed" type="xsd:string" use="optional"/>
                <xsd:attribute name="sequence" type="xsd:string" use="optional"/>
            </xsd:extension>
        </xsd:simpleContent>
    </xsd:complexType>
{code}

Algorithm is dereferenced in PasswordFactory.getInstance(algorithm) down in 
{code:java|title=java.security.Provider$ServiceKey.java}
        private ServiceKey(String type, String algorithm, boolean intern) {
            this.type = type;
            this.originalAlgorithm = algorithm;
            algorithm = algorithm.toUpperCase(ENGLISH);
            this.algorithm = intern ? algorithm.intern() : algorithm;
        }
{code}

[1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847809&defectInstanceId=9457601&mergedDefectId=1463442
[2] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847809&defectInstanceId=9457602&mergedDefectId=1463441




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 04:13:00 2018
From: issues at jboss.org (Francis ANDRE (JIRA))
Date: Thu, 4 Jan 2018 04:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1363) IOException: Could not delete
 C:\ProgramFiles\JBoss\ironjacamar-1.2.7.Final\tmp\scortcicsecirar-3.1.0.rar\bouncycastle-1.04.jar
In-Reply-To: <JIRA.12726024.1514280204000@Atlassian.JIRA>
References: <JIRA.12726024.1514280204000@Atlassian.JIRA>
	<JIRA.12726024.1514280204000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726024.1514280204000.28230.1515057180255@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1363?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Francis ANDRE updated JBJCA-1363:
---------------------------------
    Priority: Major  (was: Blocker)


> IOException: Could not delete C:\ProgramFiles\JBoss\ironjacamar-1.2.7.Final\tmp\scortcicsecirar-3.1.0.rar\bouncycastle-1.04.jar
> -------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: JBJCA-1363
>                 URL: https://issues.jboss.org/browse/JBJCA-1363
>             Project: IronJacamar
>          Issue Type: Bug
>          Components: Deployer
>    Affects Versions: 1.0.17.Final, 1.2.7.Final
>         Environment: C:\ProgramFiles\JBoss\ironjacamar-1.2.7.Final\bin>"%java_home%\bin\java" -version
> java version "1.7.0_80"
> Java(TM) SE Runtime Environment (build 1.7.0_80-b15)
> Java HotSpot(TM) 64-Bit Server VM (build 24.80-b11, mixed mode)
> Windows 10
>            Reporter: Francis ANDRE
>
> Hi
> Got this exception when deploying a EIS rar
> C:\ProgramFiles\JBoss\ironjacamar-1.2.7.Final\bin>run
> ===============================================================================
>   IronJacamar
>   IRON_JACAMAR_HOME: C:\ProgramFiles\JBoss\ironjacamar-1.2.7.Final
>   JAVA: C:\Program Files\Java\jdk1.7.0_80\bin\java
>   JAVA_OPTS: -Xmx512m
> ===============================================================================
> 10:16:49,330 INFO  [Fungal] Fungal 0.11.0.Final started
> 10:16:49,908 INFO  [Version] HV000001: Hibernate Validator 5.0.1.Final
> 10:16:50,065 INFO  [WebServer] Jetty 8.1.3.v20120416 started
> 10:16:50,143 INFO  [RADeployer] IJ020001: Required license terms for file:/C:/ProgramFiles/JBoss/ironjacamar-1.2.7.Final/system/jdbc-xa.rar
> 10:16:50,221 INFO  [RADeployer] IJ020001: Required license terms for file:/C:/ProgramFiles/JBoss/ironjacamar-1.2.7.Final/system/jdbc-local.rar
> 10:16:50,268 INFO  [RADeployer] IJ020001: Required license terms for file:/C:/ProgramFiles/JBoss/ironjacamar-1.2.7.Final/system/scortcicsecirar-3.1.0.rar
> 10:16:50,362 INFO  [WARDeployer] Deployed: file:/C:/ProgramFiles/JBoss/ironjacamar-1.2.7.Final/system/root.war
> 10:16:50,362 INFO  [WARDeployer] Deployed: file:/C:/ProgramFiles/JBoss/ironjacamar-1.2.7.Final/system/console.war
> 10:16:50,362 SEVERE [Fungal] Deployment file:/C:/ProgramFiles/JBoss/ironjacamar-1.2.7.Final/deploy/scortcicsecirar-3.1.0.rar failed: com.github.fungal.spi.deployers.DeployException: Deployment file:/C:/ProgramFiles/JBoss/ironjacamar-1.2.7.Final/deploy/scortcicsecirar-3.1.0.rar failed
>         at org.jboss.jca.deployers.fungal.RADeployer.deploy(RADeployer.java:209)
>         at com.github.fungal.impl.MainDeployerImpl.deploy(MainDeployerImpl.java:144)
>         at com.github.fungal.impl.KernelImpl$UnitDeployer.run(KernelImpl.java:1947)
>         at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
>         at java.lang.Thread.run(Thread.java:745)
> Caused by: java.io.IOException: Could not delete C:\ProgramFiles\JBoss\ironjacamar-1.2.7.Final\tmp\scortcicsecirar-3.1.0.rar\bouncycastle-1.04.jar
>         at com.github.fungal.api.util.FileUtil.delete(FileUtil.java:378)
>         at com.github.fungal.api.util.FileUtil.extract(FileUtil.java:179)
>         at org.jboss.jca.deployers.fungal.RADeployer.deploy(RADeployer.java:131)
>         ... 5 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 05:06:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 4 Jan 2018 05:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3489) CLI completion does not
 work correctly for control flow commands inside of for loop
In-Reply-To: <JIRA.12726450.1515058457000@Atlassian.JIRA>
References: <JIRA.12726450.1515058457000@Atlassian.JIRA>
	<JIRA.12726450.1515058457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726450.1515058457000.28556.1515060360588@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509217#comment-13509217 ] 

Jean-Francois Denise commented on WFCORE-3489:
----------------------------------------------

What you are observing is not specific to the for loop, try/if are already showing the same behaviour.


> CLI completion does not work correctly for control flow commands inside of for loop
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-3489
>                 URL: https://issues.jboss.org/browse/WFCORE-3489
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Erich Duda
>            Assignee: Jean-Francois Denise
>
> The issue appears when you write following commands into the CLI.
> {code}
> [standalone at embedded /] for var in :read-resource
> [standalone at embedded /] try
> [standalone at embedded /] <TAB>
> :                     cd                    connect               deployment-overlay    help                  module                read-attribute        set                   undeploy
> alias                 clear                 connection-info       done                  history               patch                 read-operation        stop-embedded-server  unset
> attachment            command               deploy                echo                  if                    pwd                   reload                try                   version
> batch                 command-timeout       deployment-info       echo-dmr              ls                    quit                  run-batch             unalias
> {code}
> As you can  see the completion helper offers a {{try}} command although it should offer {{catch}} command.
> This issue is caused by design limitation of CLI. When you type some commands inside of for loop block, they are just added into internal list and they are not evaluated until {{done}} command is called.
> The same applies also for other control flow commands such as {{if-else-endif}}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 04:41:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Thu, 4 Jan 2018 04:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3490) IllegalArgumentException
 when for loop is used for command producing non iterable result
In-Reply-To: <JIRA.12726451.1515058807000@Atlassian.JIRA>
References: <JIRA.12726451.1515058807000@Atlassian.JIRA>
	<JIRA.12726451.1515058807004@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726451.1515058807000.28333.1515058860342@Atlassian.JIRA>

Erich Duda created WFCORE-3490:
----------------------------------

             Summary: IllegalArgumentException when for loop is used for command producing non iterable result
                 Key: WFCORE-3490
                 URL: https://issues.jboss.org/browse/WFCORE-3490
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
    Affects Versions: 4.0.0.Alpha5
            Reporter: Erich Duda
            Assignee: Jean-Francois Denise


{code}
[standalone at embedded /] set name=World
[standalone at embedded /] for var in :resolve-expression(expression=Hello $name!)
java.lang.IllegalArgumentException
{code}

As you can see in the example, the commands produce {{IllegalArgumentException}}. Instead of {{IllegalArgumentException}} there should be an error message explaining what is wrong.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 04:41:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Thu, 4 Jan 2018 04:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3489) CLI completion does not
 work correctly for control flow commands inside of for loop
In-Reply-To: <JIRA.12726450.1515058457000@Atlassian.JIRA>
References: <JIRA.12726450.1515058457000@Atlassian.JIRA>
	<JIRA.12726450.1515058457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726450.1515058457000.28338.1515058860931@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erich Duda updated WFCORE-3489:
-------------------------------
    Affects: User Experience


> CLI completion does not work correctly for control flow commands inside of for loop
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-3489
>                 URL: https://issues.jboss.org/browse/WFCORE-3489
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Erich Duda
>            Assignee: Jean-Francois Denise
>
> The issue appears when you write following commands into the CLI.
> {code}
> [standalone at embedded /] for var in :read-resource
> [standalone at embedded /] try
> [standalone at embedded /] <TAB>
> :                     cd                    connect               deployment-overlay    help                  module                read-attribute        set                   undeploy
> alias                 clear                 connection-info       done                  history               patch                 read-operation        stop-embedded-server  unset
> attachment            command               deploy                echo                  if                    pwd                   reload                try                   version
> batch                 command-timeout       deployment-info       echo-dmr              ls                    quit                  run-batch             unalias
> {code}
> As you can  see the completion helper offers a {{try}} command although it should offer {{catch}} command.
> This issue is caused by design limitation of CLI. When you type some commands inside of for loop block, they are just added into internal list and they are not evaluated until {{done}} command is called.
> The same applies also for other control flow commands such as {{if-else-endif}}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 05:15:00 2018
From: issues at jboss.org (Ondrej Lukas (JIRA))
Date: Thu, 4 Jan 2018 05:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1298) GssapiCompatibilitySuiteChild
 fails on IBM JDK
In-Reply-To: <JIRA.12703073.1500634358000@Atlassian.JIRA>
References: <JIRA.12703073.1500634358000@Atlassian.JIRA>
	<JIRA.12703073.1500634358000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12703073.1500634358000.28595.1515060900460@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondrej Lukas updated ELY-1298:
------------------------------
    Priority: Critical  (was: Major)


> GssapiCompatibilitySuiteChild fails on IBM JDK
> ----------------------------------------------
>
>                 Key: ELY-1298
>                 URL: https://issues.jboss.org/browse/ELY-1298
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Peter Palaga
>            Priority: Critical
>              Labels: ibm-java
>
> A followup of ELY-1293
> {{System.currentTimeMillis()}} is native in IBM JDK and at the same time, IBM JDK does not support  java.lang.instrument API for native methods. Therefore, {{System.currentTimeMillis()}} cannot be mocked on IBM JDK using jmockit.
> {code}
> export JAVA_HOME=path/to/ibm/java8
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> mvn clean test 
> {code}
> Expected: the tests mocking {{System.currentTimeMillis()}} should pass
> Actual: the tests mocking {{System.currentTimeMillis()}} throw the following exception or similar:
> {code}
> java.lang.UnsupportedOperationException: class redefinition failed: attempted to change method modifiers
> 	at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest$1.<init>(PeriodicRotatingFileAuditEndpointTest.java:212)
> 	at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest.mockTime(PeriodicRotatingFileAuditEndpointTest.java:212)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> This is currently the case with 
> * GssapiCompatibilitySuiteChild



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 05:26:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Thu, 4 Jan 2018 05:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3489) CLI completion does not
 work correctly for control flow commands inside of for loop
In-Reply-To: <JIRA.12726450.1515058457000@Atlassian.JIRA>
References: <JIRA.12726450.1515058457000@Atlassian.JIRA>
	<JIRA.12726450.1515058457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726450.1515058457000.28657.1515061560182@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509226#comment-13509226 ] 

Erich Duda commented on WFCORE-3489:
------------------------------------

You're right I will update the description.

> CLI completion does not work correctly for control flow commands inside of for loop
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-3489
>                 URL: https://issues.jboss.org/browse/WFCORE-3489
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Erich Duda
>            Assignee: Jean-Francois Denise
>
> The issue appears when you write following commands into the CLI.
> {code}
> [standalone at embedded /] for var in :read-resource
> [standalone at embedded /] try
> [standalone at embedded /] <TAB>
> :                     cd                    connect               deployment-overlay    help                  module                read-attribute        set                   undeploy
> alias                 clear                 connection-info       done                  history               patch                 read-operation        stop-embedded-server  unset
> attachment            command               deploy                echo                  if                    pwd                   reload                try                   version
> batch                 command-timeout       deployment-info       echo-dmr              ls                    quit                  run-batch             unalias
> {code}
> As you can  see the completion helper offers a {{try}} command although it should offer {{catch}} command.
> This issue is caused by design limitation of CLI. When you type some commands inside of for loop block, they are just added into internal list and they are not evaluated until {{done}} command is called.
> The same applies also for other control flow commands such as {{if-else-endif}}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 05:27:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Thu, 4 Jan 2018 05:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3489) CLI completion does not
 work correctly inside of control flow commands
In-Reply-To: <JIRA.12726450.1515058457000@Atlassian.JIRA>
References: <JIRA.12726450.1515058457000@Atlassian.JIRA>
	<JIRA.12726450.1515058457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726450.1515058457000.28663.1515061620361@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erich Duda updated WFCORE-3489:
-------------------------------
    Summary: CLI completion does not work correctly inside of control flow commands  (was: CLI completion does not work correctly for control flow commands inside of for loop)


> CLI completion does not work correctly inside of control flow commands
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-3489
>                 URL: https://issues.jboss.org/browse/WFCORE-3489
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Erich Duda
>            Assignee: Jean-Francois Denise
>
> The issue appears when you write following commands into the CLI.
> {code}
> [standalone at embedded /] for var in :read-resource
> [standalone at embedded /] try
> [standalone at embedded /] <TAB>
> :                     cd                    connect               deployment-overlay    help                  module                read-attribute        set                   undeploy
> alias                 clear                 connection-info       done                  history               patch                 read-operation        stop-embedded-server  unset
> attachment            command               deploy                echo                  if                    pwd                   reload                try                   version
> batch                 command-timeout       deployment-info       echo-dmr              ls                    quit                  run-batch             unalias
> {code}
> As you can  see the completion helper offers a {{try}} command although it should offer {{catch}} command.
> This issue is caused by design limitation of CLI. When you type some commands inside of for loop block, they are just added into internal list and they are not evaluated until {{done}} command is called.
> The same applies also for other control flow commands such as {{if-else-endif}}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 05:38:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Thu, 4 Jan 2018 05:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3489) CLI completion does not
 work correctly inside of control flow commands
In-Reply-To: <JIRA.12726450.1515058457000@Atlassian.JIRA>
References: <JIRA.12726450.1515058457000@Atlassian.JIRA>
	<JIRA.12726450.1515058457000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726450.1515058457000.28785.1515062280866@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erich Duda updated WFCORE-3489:
-------------------------------
    Description: 
When you use control flow constructs consisting of more commands (e.g. {{for-done}}) CLI completion helper should offer commands based on the current context. So if you type {{for}} command, CLI completion should offer {{done}} command. The same applies for other constructs like {{if-else}}, {{try-catch-finally}} and so on.

However if you use these composite operations inside of other composite operations, the following situation occurs.

{code}
[standalone at embedded /] for var in :read-resource
[standalone at embedded /] try
[standalone at embedded /] <TAB>
:                     cd                    connect               deployment-overlay    help                  module                read-attribute        set                   undeploy
alias                 clear                 connection-info       done                  history               patch                 read-operation        stop-embedded-server  unset
attachment            command               deploy                echo                  if                    pwd                   reload                try                   version
batch                 command-timeout       deployment-info       echo-dmr              ls                    quit                  run-batch             unalias
{code}

As you can  see the completion helper offers a {{try}} command although it should offer {{catch}} command.

This issue is caused by design limitation of CLI. When you type some commands inside of for loop block, they are just added into internal list and they are not evaluated until {{done}} command is called. The same applies also for other control flow commands.

  was:
The issue appears when you write following commands into the CLI.

{code}
[standalone at embedded /] for var in :read-resource
[standalone at embedded /] try
[standalone at embedded /] <TAB>
:                     cd                    connect               deployment-overlay    help                  module                read-attribute        set                   undeploy
alias                 clear                 connection-info       done                  history               patch                 read-operation        stop-embedded-server  unset
attachment            command               deploy                echo                  if                    pwd                   reload                try                   version
batch                 command-timeout       deployment-info       echo-dmr              ls                    quit                  run-batch             unalias
{code}

As you can  see the completion helper offers a {{try}} command although it should offer {{catch}} command.

This issue is caused by design limitation of CLI. When you type some commands inside of for loop block, they are just added into internal list and they are not evaluated until {{done}} command is called.

The same applies also for other control flow commands such as {{if-else-endif}}



> CLI completion does not work correctly inside of control flow commands
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-3489
>                 URL: https://issues.jboss.org/browse/WFCORE-3489
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Erich Duda
>            Assignee: Jean-Francois Denise
>
> When you use control flow constructs consisting of more commands (e.g. {{for-done}}) CLI completion helper should offer commands based on the current context. So if you type {{for}} command, CLI completion should offer {{done}} command. The same applies for other constructs like {{if-else}}, {{try-catch-finally}} and so on.
> However if you use these composite operations inside of other composite operations, the following situation occurs.
> {code}
> [standalone at embedded /] for var in :read-resource
> [standalone at embedded /] try
> [standalone at embedded /] <TAB>
> :                     cd                    connect               deployment-overlay    help                  module                read-attribute        set                   undeploy
> alias                 clear                 connection-info       done                  history               patch                 read-operation        stop-embedded-server  unset
> attachment            command               deploy                echo                  if                    pwd                   reload                try                   version
> batch                 command-timeout       deployment-info       echo-dmr              ls                    quit                  run-batch             unalias
> {code}
> As you can  see the completion helper offers a {{try}} command although it should offer {{catch}} command.
> This issue is caused by design limitation of CLI. When you type some commands inside of for loop block, they are just added into internal list and they are not evaluated until {{done}} command is called. The same applies also for other control flow commands.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 05:43:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 4 Jan 2018 05:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2181) Icons (Edit, Collapse,
 Delete etc) do not respond to mouse clicks
In-Reply-To: <JIRA.12725260.1513341217000@Atlassian.JIRA>
References: <JIRA.12725260.1513341217000@Atlassian.JIRA>
	<JIRA.12725260.1513341217000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725260.1513341217000.28809.1515062580378@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2181:
--------------------------------
    Tester: Jozef Marko


> Icons (Edit, Collapse, Delete etc) do not respond to mouse clicks
> -----------------------------------------------------------------
>
>                 Key: DROOLS-2181
>                 URL: https://issues.jboss.org/browse/DROOLS-2181
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Tree Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> - Double-click on a node (object/action) to edit/delete/collapse.
> - Pop-up shows the icons/buttons.
> - Click on Edit/Delete/collapse icon. Icons are frozen.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 05:45:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 4 Jan 2018 05:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest
 fails on IBM JDK
In-Reply-To: <JIRA.12702872.1500553419000@Atlassian.JIRA>
References: <JIRA.12702872.1500553419000@Atlassian.JIRA>
	<JIRA.12702872.1500553419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702872.1500553419000.28815.1515062700107@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509232#comment-13509232 ] 

Jan Kalina commented on ELY-1295:
---------------------------------

Reason of *Get Key failed:  Unrecognized key type.* is:
ibm.security.x509.AlgorithmId.algName() is unable to decode OID "1.2.840.113549.1.12.1.3" to algorithm name (by OID repository it should be "pbeWithSHA1And3-KeyTripleDES-CBC").

PBE with SHA1 + SHA3 is not supported by IBM by this - one of following (from similar ones) should work ok:
* PBEWithSHAAndDES
* PBEWithSHAAndRC2
* PBEWithSHAAnd40BitRC4
* PBEWithSHAAnd128BitRC4
* PBEWithSHAAnd3KeyTripleDES
* PBEWithSHAAnd2KeyTripleDES
* PBEWithSHAAnd40BitRC2
* PBEWithSHAAnd128BitRC2

> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
>                 Key: ELY-1295
>                 URL: https://issues.jboss.org/browse/ELY-1295
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>  
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>  
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> 	at java.lang.Class.forNameImpl(Native Method)
> 	at java.lang.Class.forName(Class.java:278)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	at java.security.KeyStore.getEntry(KeyStore.java:1532)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> 	... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/72967600a98dee832e151ff8f6fb64af0a84bd14#diff-faa6b27609575ef29472bcc75c87eb36R87



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 05:57:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 4 Jan 2018 05:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest
 fails on IBM JDK
In-Reply-To: <JIRA.12702872.1500553419000@Atlassian.JIRA>
References: <JIRA.12702872.1500553419000@Atlassian.JIRA>
	<JIRA.12702872.1500553419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702872.1500553419000.28856.1515063420167@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509232#comment-13509232 ] 

Jan Kalina edited comment on ELY-1295 at 1/4/18 5:56 AM:
---------------------------------------------------------

Reason of *Get Key failed:  Unrecognized key type.* is:
ibm.security.x509.AlgorithmId.algName() is unable to decode OID "1.2.840.113549.1.7.1" to algorithm name - but by OID repository it is "pkcs7-data" - not a key type...


was (Author: honza889):
Reason of *Get Key failed:  Unrecognized key type.* is:
ibm.security.x509.AlgorithmId.algName() is unable to decode OID "1.2.840.113549.1.12.1.3" to algorithm name (by OID repository it should be "pbeWithSHA1And3-KeyTripleDES-CBC").

PBE with SHA1 + SHA3 is not supported by IBM by this - one of following (from similar ones) should work ok:
* PBEWithSHAAndDES
* PBEWithSHAAndRC2
* PBEWithSHAAnd40BitRC4
* PBEWithSHAAnd128BitRC4
* PBEWithSHAAnd3KeyTripleDES
* PBEWithSHAAnd2KeyTripleDES
* PBEWithSHAAnd40BitRC2
* PBEWithSHAAnd128BitRC2

> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
>                 Key: ELY-1295
>                 URL: https://issues.jboss.org/browse/ELY-1295
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>  
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>  
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> 	at java.lang.Class.forNameImpl(Native Method)
> 	at java.lang.Class.forName(Class.java:278)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	at java.security.KeyStore.getEntry(KeyStore.java:1532)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> 	... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/72967600a98dee832e151ff8f6fb64af0a84bd14#diff-faa6b27609575ef29472bcc75c87eb36R87



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 06:04:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 4 Jan 2018 06:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest
 fails on IBM JDK
In-Reply-To: <JIRA.12702872.1500553419000@Atlassian.JIRA>
References: <JIRA.12702872.1500553419000@Atlassian.JIRA>
	<JIRA.12702872.1500553419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702872.1500553419000.28873.1515063840123@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509232#comment-13509232 ] 

Jan Kalina edited comment on ELY-1295 at 1/4/18 6:03 AM:
---------------------------------------------------------

Reason of *Get Key failed:  Unrecognized key type.* is:
ibm.security.x509.AlgorithmId.algName() is unable to decode OID "1.2.840.113549.1.7.1" to algorithm name - but by OID repository it is "pkcs7-data" - not a key type...
Looks like IBM JDK has problem to store password credential into PKCS12 keystore, as it tries to decode it as key...


was (Author: honza889):
Reason of *Get Key failed:  Unrecognized key type.* is:
ibm.security.x509.AlgorithmId.algName() is unable to decode OID "1.2.840.113549.1.7.1" to algorithm name - but by OID repository it is "pkcs7-data" - not a key type...

> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
>                 Key: ELY-1295
>                 URL: https://issues.jboss.org/browse/ELY-1295
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>  
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>  
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> 	at java.lang.Class.forNameImpl(Native Method)
> 	at java.lang.Class.forName(Class.java:278)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	at java.security.KeyStore.getEntry(KeyStore.java:1532)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> 	... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/72967600a98dee832e151ff8f6fb64af0a84bd14#diff-faa6b27609575ef29472bcc75c87eb36R87



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 06:15:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 4 Jan 2018 06:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2211) Trying to modify a global
 wm object from the consequence of a rule belonging to rule unit causes a
 NPE
In-Reply-To: <JIRA.12726481.1515064456000@Atlassian.JIRA>
References: <JIRA.12726481.1515064456000@Atlassian.JIRA>
	<JIRA.12726481.1515064456171@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726481.1515064456000.28882.1515064500698@Atlassian.JIRA>

Mario Fusco created DROOLS-2211:
-----------------------------------

             Summary: Trying to modify a global wm object from the consequence of a rule belonging to rule unit causes a NPE
                 Key: DROOLS-2211
                 URL: https://issues.jboss.org/browse/DROOLS-2211
             Project: Drools
          Issue Type: Bug
            Reporter: Mario Fusco
            Assignee: Edson Tirelli






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 06:15:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 4 Jan 2018 06:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2211) Trying to modify a global
 wm object from the consequence of a rule belonging to rule unit causes a
 NPE
In-Reply-To: <JIRA.12726481.1515064456000@Atlassian.JIRA>
References: <JIRA.12726481.1515064456000@Atlassian.JIRA>
	<JIRA.12726481.1515064456000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726481.1515064456000.28885.1515064500774@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-2211:
-----------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)


> Trying to modify a global wm object from the consequence of a rule belonging to rule unit causes a NPE
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2211
>                 URL: https://issues.jboss.org/browse/DROOLS-2211
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 06:15:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 4 Jan 2018 06:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2211) Trying to modify a global
 wm object from the consequence of a rule belonging to rule unit causes a
 NPE
In-Reply-To: <JIRA.12726481.1515064456000@Atlassian.JIRA>
References: <JIRA.12726481.1515064456000@Atlassian.JIRA>
	<JIRA.12726481.1515064456000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726481.1515064456000.28887.1515064500829@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2211:
--------------------------------
    Component/s: core engine


> Trying to modify a global wm object from the consequence of a rule belonging to rule unit causes a NPE
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2211
>                 URL: https://issues.jboss.org/browse/DROOLS-2211
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 06:26:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Thu, 4 Jan 2018 06:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2211) Trying to modify a global
 wm object from the consequence of a rule belonging to rule unit causes a
 NPE
In-Reply-To: <JIRA.12726481.1515064456000@Atlassian.JIRA>
References: <JIRA.12726481.1515064456000@Atlassian.JIRA>
	<JIRA.12726481.1515064456000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726481.1515064456000.28896.1515065160083@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-2211.
---------------------------------
    Resolution: Done


Fixed by https://github.com/kiegroup/drools/commit/9694340ed2fcef65d6803adede4b59f4899ab955

> Trying to modify a global wm object from the consequence of a rule belonging to rule unit causes a NPE
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2211
>                 URL: https://issues.jboss.org/browse/DROOLS-2211
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 06:40:00 2018
From: issues at jboss.org (Hayk Hovsepyan (JIRA))
Date: Thu, 4 Jan 2018 06:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-216) CFME Tests - Disable
 Middleware Provider
In-Reply-To: <JIRA.12725510.1513613482000@Atlassian.JIRA>
References: <JIRA.12725510.1513613482000@Atlassian.JIRA>
	<JIRA.12725510.1513613482000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725510.1513613482000.28940.1515066000047@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509244#comment-13509244 ] 

Hayk Hovsepyan commented on HAWKULARQE-216:
-------------------------------------------

PR sent https://github.com/ManageIQ/integration_tests/pull/6212

> CFME Tests - Disable Middleware Provider
> ----------------------------------------
>
>                 Key: HAWKULARQE-216
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-216
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: Hayk Hovsepyan
>            Assignee: Hayk Hovsepyan
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 06:55:00 2018
From: issues at jboss.org (=?UTF-8?Q?Guilherme_Baufaker_R=C3=AAgo_=28JIRA=29?=)
Date: Thu, 4 Jan 2018 06:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-215) Verify MM is removed
 totally from CFME UI
In-Reply-To: <JIRA.12725508.1513613439000@Atlassian.JIRA>
References: <JIRA.12725508.1513613439000@Atlassian.JIRA>
	<JIRA.12725508.1513613439000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725508.1513613439000.29049.1515066900405@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509252#comment-13509252 ] 

Guilherme Baufaker R?go commented on HAWKULARQE-215:
----------------------------------------------------

Bug on Control > Explorer Page on ManageIQ Master (https://bugzilla.redhat.com/show_bug.cgi?id=1530575)

Waiting new CFME image to be available on Sprout to verify it.

> Verify MM is removed totally from CFME UI
> -----------------------------------------
>
>                 Key: HAWKULARQE-215
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-215
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: Hayk Hovsepyan
>            Assignee: Michael Foley
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan  4 06:55:00 2018
From: issues at jboss.org (=?UTF-8?Q?Guilherme_Baufaker_R=C3=AAgo_=28JIRA=29?=)
Date: Thu, 4 Jan 2018 06:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-215) Verify MM is removed
 totally from CFME UI
In-Reply-To: <JIRA.12725508.1513613439000@Atlassian.JIRA>
References: <JIRA.12725508.1513613439000@Atlassian.JIRA>
	<JIRA.12725508.1513613439000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725508.1513613439000.29055.1515066900671@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Guilherme Baufaker R?go updated HAWKULARQE-215:
-----------------------------------------------
    Comment: was deleted

(was: Bug on Control > Explorer Page on ManageIQ Master (https://bugzilla.redhat.com/show_bug.cgi?id=1530575)

Waiting new CFME image to be available on Sprout to verify it.)


> Verify MM is removed totally from CFME UI
> -----------------------------------------
>
>                 Key: HAWKULARQE-215
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-215
>             Project: Hawkular QE
>          Issue Type: Sub-task
>            Reporter: Hayk Hovsepyan
>            Assignee: Michael Foley
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan  4 06:55:00 2018
From: issues at jboss.org (=?UTF-8?Q?Guilherme_Baufaker_R=C3=AAgo_=28JIRA=29?=)
Date: Thu, 4 Jan 2018 06:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-214) [QE] - Disable
	Middleware Manager
In-Reply-To: <JIRA.12725507.1513613351000@Atlassian.JIRA>
References: <JIRA.12725507.1513613351000@Atlassian.JIRA>
	<JIRA.12725507.1513613351000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725507.1513613351000.29060.1515066900767@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/HAWKULARQE-214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509253#comment-13509253 ] 

Guilherme Baufaker R?go commented on HAWKULARQE-214:
----------------------------------------------------

Bug on Control > Explorer Page on ManageIQ Master (https://bugzilla.redhat.com/show_bug.cgi?id=1530575)

Waiting new CFME image to be available on Sprout to verify it.

> [QE] - Disable Middleware Manager
> ---------------------------------
>
>                 Key: HAWKULARQE-214
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-214
>             Project: Hawkular QE
>          Issue Type: Task
>            Reporter: Hayk Hovsepyan
>            Assignee: Michael Foley
>            Priority: Blocker
>
> https://bugzilla.redhat.com/show_bug.cgi?id=1526791
> Remove Middleware Manager from CFME UI:
> Menu: Middleware
> Control -> Explorer
> Cloud Intel -> Reports
> More info at: http://pad.engineering.redhat.com/middleware-deletion-task
> Disable Middleware Manager provider in CFME Tests framework.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan  4 07:12:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 4 Jan 2018 07:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest
 fails on IBM JDK
In-Reply-To: <JIRA.12702872.1500553419000@Atlassian.JIRA>
References: <JIRA.12702872.1500553419000@Atlassian.JIRA>
	<JIRA.12702872.1500553419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702872.1500553419000.29116.1515067920226@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509232#comment-13509232 ] 

Jan Kalina edited comment on ELY-1295 at 1/4/18 7:11 AM:
---------------------------------------------------------

Reason of *Get Key failed:  Unrecognized key type.* is, PKCS12KeyStoreOracle from IBM JDK is trying to put any Key into SecretKeyFactory, while we suppose it returns non-PBE SecretKeySpec directly.
SecretKeySpec(byte[], DATA_OID) which we use for storing PasswordCredentials in KeyStore cannot be stored in this KeyStore implementation...


was (Author: honza889):
Reason of *Get Key failed:  Unrecognized key type.* is:
ibm.security.x509.AlgorithmId.algName() is unable to decode OID "1.2.840.113549.1.7.1" to algorithm name - but by OID repository it is "pkcs7-data" - not a key type...
Looks like IBM JDK has problem to store password credential into PKCS12 keystore, as it tries to decode it as key...

> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
>                 Key: ELY-1295
>                 URL: https://issues.jboss.org/browse/ELY-1295
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>  
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>  
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> 	at java.lang.Class.forNameImpl(Native Method)
> 	at java.lang.Class.forName(Class.java:278)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	at java.security.KeyStore.getEntry(KeyStore.java:1532)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> 	... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/72967600a98dee832e151ff8f6fb64af0a84bd14#diff-faa6b27609575ef29472bcc75c87eb36R87



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 07:43:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 4 Jan 2018 07:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-283) Investigate Elytron and
 gssproxy interoperability
In-Reply-To: <JIRA.12583605.1441213044000@Atlassian.JIRA>
References: <JIRA.12583605.1441213044000@Atlassian.JIRA>
	<JIRA.12583605.1441213044000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583605.1441213044000.29302.1515069780462@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508621#comment-13508621 ] 

Jan Kalina edited comment on ELY-283 at 1/4/18 7:43 AM:
--------------------------------------------------------

Complete instructions to setup wildfly+elytron to use gssapi composed into tutorial:

https://hkalina.github.io/2018/01/02/gssproxy/

Things to fix/improve in elytron:
* path to the keytab in kerberos-security-factory should be made optional
* workaround JDK-8194073 - wil not fix GS2-KRB5, but will fix GSSAPI (!)

-> ELY-85


was (Author: honza889):
Complete instructions to setup wildfly+elytron to use gssapi composed into tutorial:

https://hkalina.github.io/2018/01/02/gssproxy/

Things to fix/improve in elytron:
* path to the keytab in kerberos-security-factory should be made optional
* workaround JDK-8194073 - wil not fix GS2-KRB5, but will fix GSSAPI (!)

> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
>                 Key: ELY-283
>                 URL: https://issues.jboss.org/browse/ELY-283
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: SASL
>            Reporter: Peter Skopek
>            Assignee: Jan Kalina
>             Fix For: 2.0.0.Alpha1
>
>         Attachments: jkalina-openjdk-native-gss.patch, openjdk-patch-native-mechs.patch, reproducer-gss.zip
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 07:47:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 4 Jan 2018 07:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-283) Investigate Elytron and
 gssproxy interoperability
In-Reply-To: <JIRA.12583605.1441213044000@Atlassian.JIRA>
References: <JIRA.12583605.1441213044000@Atlassian.JIRA>
	<JIRA.12583605.1441213044000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583605.1441213044000.29318.1515070020351@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13508167#comment-13508167 ] 

Jan Kalina edited comment on ELY-283 at 1/4/18 7:46 AM:
--------------------------------------------------------

For needs of OpenJDK patch review I has prepared simple reproducer without AS: [^reproducer-gss.zip] 
{panel}
Hi, I was just able to prepare usable reproducer (attaching in ZIP file) and fixing patch of JDK (attaching too).
Before I was able to make my usecase working, I has found second issue too - I has included it too.

Issues and their reproducing:

*1) already described problem of wrong initialized SunNativeProvider.INSTANCE*

This can be reproduced by recreating GSSManager before createGSSContext - ProviderList.factories
will be initialized as part of initSecContext/acceptSecContext which will cause using wrong initialized
SunNativeProvider.INSTANCE and described exception.

*2) when channel binding is used SIGSEGV occure*

This can be reproduced by setting channel binding without initAddr/acceptAddr.
This is caused by sending uninitialized (with random length) cb->initiator_address from JDK to the kerberos.
(It is used by krb library for messages checksum calculation even when addrtype is GSS_C_AF_NULLADDR.)

Attached reproducer-gss.zip reproduces both issues and attached patch fixes both.

I would welcome merging into OpenJDK. (I am covered by OCA of Red Hat)

This issue affect both tested JDKs, JKD8u121 and upstream JDK9 from mercurial master.

Thanks,
Jan
{panel}
Also reported as Oracle JDK issues:
* 1) as [JDK-8194073|https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194073]
* 2) as [JDK-8194630|https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8194630] 


was (Author: honza889):
For needs of OpenJDK patch review I has prepared simple reproducer without AS: [^reproducer-gss.zip] 
{panel}
Hi, I was just able to prepare usable reproducer (attaching in ZIP file) and fixing patch of JDK (attaching too).
Before I was able to make my usecase working, I has found second issue too - I has included it too.

Issues and their reproducing:

*1) already described problem of wrong initialized SunNativeProvider.INSTANCE*

This can be reproduced by recreating GSSManager before createGSSContext - ProviderList.factories
will be initialized as part of initSecContext/acceptSecContext which will cause using wrong initialized
SunNativeProvider.INSTANCE and described exception.

*2) when channel binding is used SIGSEGV occure*

This can be reproduced by setting channel binding without initAddr/acceptAddr.
This is caused by sending uninitialized (with random length) cb->initiator_address from JDK to the kerberos.
(It is used by krb library for messages checksum calculation even when addrtype is GSS_C_AF_NULLADDR.)

Attached reproducer-gss.zip reproduces both issues and attached patch fixes both.

I would welcome merging into OpenJDK. (I am covered by OCA of Red Hat)

This issue affect both tested JDKs, JKD8u121 and upstream JDK9 from mercurial master.

Thanks,
Jan
{panel}

> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
>                 Key: ELY-283
>                 URL: https://issues.jboss.org/browse/ELY-283
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: SASL
>            Reporter: Peter Skopek
>            Assignee: Jan Kalina
>             Fix For: 2.0.0.Alpha1
>
>         Attachments: jkalina-openjdk-native-gss.patch, openjdk-patch-native-mechs.patch, reproducer-gss.zip
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 07:47:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 4 Jan 2018 07:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-283) Investigate Elytron and
 gssproxy interoperability
In-Reply-To: <JIRA.12583605.1441213044000@Atlassian.JIRA>
References: <JIRA.12583605.1441213044000@Atlassian.JIRA>
	<JIRA.12583605.1441213044000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583605.1441213044000.29323.1515070020471@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina resolved ELY-283.
----------------------------
    Resolution: Done


> Investigate Elytron and gssproxy interoperability
> -------------------------------------------------
>
>                 Key: ELY-283
>                 URL: https://issues.jboss.org/browse/ELY-283
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: SASL
>            Reporter: Peter Skopek
>            Assignee: Jan Kalina
>             Fix For: 2.0.0.Alpha1
>
>         Attachments: jkalina-openjdk-native-gss.patch, openjdk-patch-native-mechs.patch, reproducer-gss.zip
>
>
> Investigate Elytron and gssproxy interoperability.
> https://fedorahosted.org/gss-proxy/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 08:10:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 4 Jan 2018 08:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2212) [DMN Editor] Relation and
 Invocation can not be saved
In-Reply-To: <JIRA.12726502.1515071342000@Atlassian.JIRA>
References: <JIRA.12726502.1515071342000@Atlassian.JIRA>
	<JIRA.12726502.1515071342738@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726502.1515071342000.29436.1515071400429@Atlassian.JIRA>

Jozef Marko created DROOLS-2212:
-----------------------------------

             Summary: [DMN Editor] Relation and Invocation can not be saved
                 Key: DROOLS-2212
                 URL: https://issues.jboss.org/browse/DROOLS-2212
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis
         Attachments: error.log

Save operation in dmn editor throws an exception if the dmn diagram contains decision node holding relation or invocation context entry.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 08:11:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 4 Jan 2018 08:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2212) [DMN Editor] Relation and
 Invocation can not be saved
In-Reply-To: <JIRA.12726502.1515071343000@Atlassian.JIRA>
References: <JIRA.12726502.1515071343000@Atlassian.JIRA>
	<JIRA.12726502.1515071343000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726502.1515071343000.29448.1515071460238@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2212:
--------------------------------
    QE Status: ON_QA  (was: NEW)


> [DMN Editor] Relation and Invocation can not be saved
> -----------------------------------------------------
>
>                 Key: DROOLS-2212
>                 URL: https://issues.jboss.org/browse/DROOLS-2212
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: error.log
>
>
> Save operation in dmn editor throws an exception if the dmn diagram contains decision node holding relation or invocation context entry.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 08:26:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 4 Jan 2018 08:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1369) FIPS mode,
 Elytron HTTP DIGEST authentication mechanism not fips compliant
In-Reply-To: <JIRA.12712431.1505900284000@Atlassian.JIRA>
References: <JIRA.12712431.1505900284000@Atlassian.JIRA>
	<JIRA.12712431.1505900284000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712431.1505900284000.29576.1515072360588@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509303#comment-13509303 ] 

Martin Choma commented on ELY-1369:
-----------------------------------

So do I understand correctly, that to enable new mechanisms only thing to do is to specify auth-method in web.xml to be DIGEST-SHA-256 or DIGEST-SHA-512-256 ?

> FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant
> --------------------------------------------------------------------------
>
>                 Key: ELY-1369
>                 URL: https://issues.jboss.org/browse/ELY-1369
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.2.0.Beta3
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta11
>
>
> Elytron HTTP DIGEST authentication comply to rfc2617 - which means MD5 is used by default (it means it is hardcode, with no way to configure another hash algorithm). But MD5 could make troubles in fips environment [5].
> {code:java|title=DigestAuthenticationMechanism.java}
>         String algorithm = convertToken(ALGORITHM, responseTokens.get(ALGORITHM));
>         if (MD5.equals(algorithm) == false) {
>             throw log.mechUnsupportedAlgorithm(getMechanismName(), algorithm);
>         }
> {code}
> There exists proposed rfc7616 which makes algorithm configurable, work on new DIGEST features are covered by [1]. [~dlofthouse] is it planned for [1] to target 7.1? 
> [1] https://issues.jboss.org/browse/ELY-286
> [2] https://developer.jboss.org/wiki/ElytronHTTPDigestNonceHandling-Design
> [3] https://tools.ietf.org/html/rfc2617
> [4] https://tools.ietf.org/html/rfc7616
> [5] https://access.redhat.com/support/cases/#/case/01761455



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 09:08:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 4 Jan 2018 09:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2181) Icons (Edit, Collapse,
 Delete etc) do not respond to mouse clicks
In-Reply-To: <JIRA.12725260.1513341217000@Atlassian.JIRA>
References: <JIRA.12725260.1513341217000@Atlassian.JIRA>
	<JIRA.12725260.1513341217000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725260.1513341217000.29948.1515074880530@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509339#comment-13509339 ] 

Michael Anstis commented on DROOLS-2181:
----------------------------------------

The problem was caused by https://issues.jboss.org/browse/GUVNOR-3524

> Icons (Edit, Collapse, Delete etc) do not respond to mouse clicks
> -----------------------------------------------------------------
>
>                 Key: DROOLS-2181
>                 URL: https://issues.jboss.org/browse/DROOLS-2181
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Tree Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> - Double-click on a node (object/action) to edit/delete/collapse.
> - Pop-up shows the icons/buttons.
> - Click on Edit/Delete/collapse icon. Icons are frozen.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 09:22:00 2018
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Thu, 4 Jan 2018 09:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9574) Distribution files does not
 have POSIX permissions perfectly set
In-Reply-To: <JIRA.12722288.1511536392000@Atlassian.JIRA>
References: <JIRA.12722288.1511536392000@Atlassian.JIRA>
	<JIRA.12722288.1511536392000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722288.1511536392000.30024.1515075720181@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9574?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509347#comment-13509347 ] 

Romain Pelisse commented on WFLY-9574:
--------------------------------------

It turns out that the Wildfly builds are associating the files with the proper permissions. The issue is only on the EAP builds. Thus, I'm closing this issue.

> Distribution files does not have POSIX permissions perfectly set
> ----------------------------------------------------------------
>
>                 Key: WFLY-9574
>                 URL: https://issues.jboss.org/browse/WFLY-9574
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Build System
>    Affects Versions: 11.0.0.Final
>            Reporter: Romain Pelisse
>            Assignee: Romain Pelisse
>            Priority: Minor
>
> The server provisioning copy (and extract) files in order to assemble the distribution based the information of the feature-pack. 
> While doing so on a POSIX system, it keeps the permissions of the original files, which are not always optimum (see JBEAP-12374). Specifically, .properties and .jar files are associated with the mask rw-rw-r-- giving access to it to any other and allowing group member to modify the file ;
> On a "regular" Maven project, all of those changes could be specified in the assembly.xml, however in Wildfly cases, this is not really option because the provisioning-maven-plugin and feature-pack-build-maven-plugin are manipulating the content of the archive being built. Also, using assembly.xml would mean edit and update the 4 or 5 different assembly.xml in the project directory tree.
> I plan thus to propose a fix for wildfly-build-tools to address all those (small) problems.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 09:46:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 4 Jan 2018 09:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3491) Allow to add a key-store
 and generate a key-pair inside the same composite
In-Reply-To: <JIRA.12726520.1515077145000@Atlassian.JIRA>
References: <JIRA.12726520.1515077145000@Atlassian.JIRA>
	<JIRA.12726520.1515077145396@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726520.1515077145000.30144.1515077160596@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-3491:
--------------------------------------------

             Summary: Allow to add a key-store and generate a key-pair inside the same composite
                 Key: WFCORE-3491
                 URL: https://issues.jboss.org/browse/WFCORE-3491
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Security
            Reporter: Jean-Francois Denise
            Assignee: Darran Lofthouse


I am facing an issue with key-store 'add' and 'generate-key-pair'
operations being located in the same composite:

"WFLYELY00007: The required service 'service
org.wildfly.security.key-store.generated_ks' is not UP, it is currently
'STARTING'."





--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 10:07:01 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 4 Jan 2018 10:07:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2205) Issues in KIE WB
In-Reply-To: <JIRA.12726289.1514971515000@Atlassian.JIRA>
References: <JIRA.12726289.1514971515000@Atlassian.JIRA>
	<JIRA.12726289.1514971515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726289.1514971515000.30322.1515078421459@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned DROOLS-2205:
-------------------------------------

    Assignee: Toni Rikkola  (was: Edson Tirelli)


> Issues in KIE WB
> ----------------
>
>                 Key: DROOLS-2205
>                 URL: https://issues.jboss.org/browse/DROOLS-2205
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.4.1.Final
>            Reporter: Senthil Kumar Kamaraj
>            Assignee: Toni Rikkola
>
> There are some issues in KIE workbench 7.4.1 release
>    1.  Creating group on KIE WB on tomcat throws exception sometimes, but the group is created.
>   2.  When trying to delete the user from KIE WB, the user is not getting deleted.
>   3.  Language support other than English is not complete: partial support
>    4.  Sometimes, when I am trying to perform operation on "newly created project" in KIE Workbench, URL is redirected to other existing project.
>     5.  KIE WB user creation: Unable to create new user gracefully from the GUI: error: Cannot read property 'p8b' of null.
>      
>      6.  The new user creation is failing if it is assigned to Groups and Roles.
>            Received Error : Group not found.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 10:08:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 4 Jan 2018 10:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2205) Issues in KIE WB
In-Reply-To: <JIRA.12726289.1514971515000@Atlassian.JIRA>
References: <JIRA.12726289.1514971515000@Atlassian.JIRA>
	<JIRA.12726289.1514971515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726289.1514971515000.30328.1515078480425@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509377#comment-13509377 ] 

Edson Tirelli commented on DROOLS-2205:
---------------------------------------

[~senlog80] did you try version 7.5.0?



> Issues in KIE WB
> ----------------
>
>                 Key: DROOLS-2205
>                 URL: https://issues.jboss.org/browse/DROOLS-2205
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.4.1.Final
>            Reporter: Senthil Kumar Kamaraj
>            Assignee: Toni Rikkola
>
> There are some issues in KIE workbench 7.4.1 release
>    1.  Creating group on KIE WB on tomcat throws exception sometimes, but the group is created.
>   2.  When trying to delete the user from KIE WB, the user is not getting deleted.
>   3.  Language support other than English is not complete: partial support
>    4.  Sometimes, when I am trying to perform operation on "newly created project" in KIE Workbench, URL is redirected to other existing project.
>     5.  KIE WB user creation: Unable to create new user gracefully from the GUI: error: Cannot read property 'p8b' of null.
>      
>      6.  The new user creation is failing if it is assigned to Groups and Roles.
>            Received Error : Group not found.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 10:09:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 4 Jan 2018 10:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2206) Login / Logout issue in KIE
	workbench
In-Reply-To: <JIRA.12726327.1514977384000@Atlassian.JIRA>
References: <JIRA.12726327.1514977384000@Atlassian.JIRA>
	<JIRA.12726327.1514977384000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726327.1514977384000.30335.1515078540337@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned DROOLS-2206:
-------------------------------------

    Assignee: Toni Rikkola  (was: Edson Tirelli)


> Login / Logout issue in KIE workbench
> -------------------------------------
>
>                 Key: DROOLS-2206
>                 URL: https://issues.jboss.org/browse/DROOLS-2206
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Senthil Kumar Kamaraj
>            Assignee: Toni Rikkola
>
> 1.  KIE WB Logout issue: KIE WB should automatically navigate to the login page by default if the corresponding session is logged out from other browser/tab session
> 2.  KIE WB login issue:Unable to complete your request. The following exception occurred: java.lang.RuntimeException: org.eclipse.jgit.api.errors.TransportException:
> 3.  The browser back button still having the previous login session valid even after logged out from the KIE workbench.
> 4.  Unable to logout after multiple login and logout sessions. non consistent.
> 5.  Sometimes when trying to re login to KIE workbench unexpected redirection to logout page
> 6.  Sometimes when trying to login into KIE workbench without keycloak configured, login unsuccessful without any error message displayed in the browser(blank screen)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 10:09:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 4 Jan 2018 10:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2206) Login / Logout issue in KIE
	workbench
In-Reply-To: <JIRA.12726327.1514977384000@Atlassian.JIRA>
References: <JIRA.12726327.1514977384000@Atlassian.JIRA>
	<JIRA.12726327.1514977384000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726327.1514977384000.30342.1515078540567@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2206?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509378#comment-13509378 ] 

Edson Tirelli commented on DROOLS-2206:
---------------------------------------

Is this on version 7.5.0?

> Login / Logout issue in KIE workbench
> -------------------------------------
>
>                 Key: DROOLS-2206
>                 URL: https://issues.jboss.org/browse/DROOLS-2206
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Senthil Kumar Kamaraj
>            Assignee: Toni Rikkola
>
> 1.  KIE WB Logout issue: KIE WB should automatically navigate to the login page by default if the corresponding session is logged out from other browser/tab session
> 2.  KIE WB login issue:Unable to complete your request. The following exception occurred: java.lang.RuntimeException: org.eclipse.jgit.api.errors.TransportException:
> 3.  The browser back button still having the previous login session valid even after logged out from the KIE workbench.
> 4.  Unable to logout after multiple login and logout sessions. non consistent.
> 5.  Sometimes when trying to re login to KIE workbench unexpected redirection to logout page
> 6.  Sometimes when trying to login into KIE workbench without keycloak configured, login unsuccessful without any error message displayed in the browser(blank screen)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 10:15:00 2018
From: issues at jboss.org (Senthil Kumar Kamaraj (JIRA))
Date: Thu, 4 Jan 2018 10:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2205) Issues in KIE WB
In-Reply-To: <JIRA.12726289.1514971515000@Atlassian.JIRA>
References: <JIRA.12726289.1514971515000@Atlassian.JIRA>
	<JIRA.12726289.1514971515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726289.1514971515000.30391.1515078900273@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509384#comment-13509384 ] 

Senthil Kumar Kamaraj commented on DROOLS-2205:
-----------------------------------------------

I will try this in 7.5.0 and update the status

> Issues in KIE WB
> ----------------
>
>                 Key: DROOLS-2205
>                 URL: https://issues.jboss.org/browse/DROOLS-2205
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.4.1.Final
>            Reporter: Senthil Kumar Kamaraj
>            Assignee: Toni Rikkola
>
> There are some issues in KIE workbench 7.4.1 release
>    1.  Creating group on KIE WB on tomcat throws exception sometimes, but the group is created.
>   2.  When trying to delete the user from KIE WB, the user is not getting deleted.
>   3.  Language support other than English is not complete: partial support
>    4.  Sometimes, when I am trying to perform operation on "newly created project" in KIE Workbench, URL is redirected to other existing project.
>     5.  KIE WB user creation: Unable to create new user gracefully from the GUI: error: Cannot read property 'p8b' of null.
>      
>      6.  The new user creation is failing if it is assigned to Groups and Roles.
>            Received Error : Group not found.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 10:21:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 4 Jan 2018 10:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest
 fails on IBM JDK
In-Reply-To: <JIRA.12702872.1500553419000@Atlassian.JIRA>
References: <JIRA.12702872.1500553419000@Atlassian.JIRA>
	<JIRA.12702872.1500553419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702872.1500553419000.30408.1515079260202@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509386#comment-13509386 ] 

Jan Kalina commented on ELY-1295:
---------------------------------

PKCS12 implementation in IBM JDK simply does not support storing SecretKeySpec of unknown algorithm, so we are unable to pass PasswordCredential here - as I dont see another option how to pass custom object into PKCS12, I recommend to declare storing PasswordCredentials into PKCS12 is unsupported on IBM JDK.

[~pskopek] do you think it will be ok to just ignore test this for IBM?

> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
>                 Key: ELY-1295
>                 URL: https://issues.jboss.org/browse/ELY-1295
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>  
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>  
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> 	at java.lang.Class.forNameImpl(Native Method)
> 	at java.lang.Class.forName(Class.java:278)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	at java.security.KeyStore.getEntry(KeyStore.java:1532)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> 	... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/72967600a98dee832e151ff8f6fb64af0a84bd14#diff-faa6b27609575ef29472bcc75c87eb36R87



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 10:24:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 4 Jan 2018 10:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest
 fails on IBM JDK
In-Reply-To: <JIRA.12702872.1500553419000@Atlassian.JIRA>
References: <JIRA.12702872.1500553419000@Atlassian.JIRA>
	<JIRA.12702872.1500553419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702872.1500553419000.30455.1515079440541@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509392#comment-13509392 ] 

Jan Kalina commented on ELY-1295:
---------------------------------

PKCS12 implementation in IBM JDK simply does not support storing SecretKeySpec of unknown algorithm, so we are unable to pass PasswordCredential here - as I dont see another option how to pass custom object into PKCS12, I recommend to declare storing PasswordCredentials into PKCS12 is unsupported on IBM JDK.

[~pskopek] do you think it will be ok to just ignore test this for IBM?

> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
>                 Key: ELY-1295
>                 URL: https://issues.jboss.org/browse/ELY-1295
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>  
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>  
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> 	at java.lang.Class.forNameImpl(Native Method)
> 	at java.lang.Class.forName(Class.java:278)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	at java.security.KeyStore.getEntry(KeyStore.java:1532)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> 	... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/72967600a98dee832e151ff8f6fb64af0a84bd14#diff-faa6b27609575ef29472bcc75c87eb36R87



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 10:24:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 4 Jan 2018 10:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest
 fails on IBM JDK
In-Reply-To: <JIRA.12702872.1500553419000@Atlassian.JIRA>
References: <JIRA.12702872.1500553419000@Atlassian.JIRA>
	<JIRA.12702872.1500553419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702872.1500553419000.30458.1515079440623@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1295:
----------------------------
    Comment: was deleted

(was: PKCS12 implementation in IBM JDK simply does not support storing SecretKeySpec of unknown algorithm, so we are unable to pass PasswordCredential here - as I dont see another option how to pass custom object into PKCS12, I recommend to declare storing PasswordCredentials into PKCS12 is unsupported on IBM JDK.

[~pskopek] do you think it will be ok to just ignore test this for IBM?)


> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
>                 Key: ELY-1295
>                 URL: https://issues.jboss.org/browse/ELY-1295
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>  
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>  
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> 	at java.lang.Class.forNameImpl(Native Method)
> 	at java.lang.Class.forName(Class.java:278)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	at java.security.KeyStore.getEntry(KeyStore.java:1532)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> 	... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/72967600a98dee832e151ff8f6fb64af0a84bd14#diff-faa6b27609575ef29472bcc75c87eb36R87



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 10:25:00 2018
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Thu, 4 Jan 2018 10:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2213) Cannot recreate the same
 KieBase when using canonical model
In-Reply-To: <JIRA.12726549.1515079459000@Atlassian.JIRA>
References: <JIRA.12726549.1515079459000@Atlassian.JIRA>
	<JIRA.12726549.1515079459253@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726549.1515079459000.30461.1515079500156@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-2213:
-------------------------------------

             Summary: Cannot recreate the same KieBase when using canonical model
                 Key: DROOLS-2213
                 URL: https://issues.jboss.org/browse/DROOLS-2213
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Tibor Zim?nyi
            Assignee: Mario Fusco


Creating the same KieBase from a KieContainer with the same ReleaseId second time fails on NullPoinerException [1]. I will create a PR with a reproducer.

[1] https://gist.github.com/baldimir/b3fa7ed299d5e0d7b74e4cc8bc4878f3





--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan  4 10:34:00 2018
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Thu, 4 Jan 2018 10:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2213) Cannot recreate the same
 KieBase when using canonical model
In-Reply-To: <JIRA.12726549.1515079459000@Atlassian.JIRA>
References: <JIRA.12726549.1515079459000@Atlassian.JIRA>
	<JIRA.12726549.1515079459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726549.1515079459000.7.1515080040336@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tibor Zim?nyi updated DROOLS-2213:
----------------------------------
    Description: 
Creating the same KieBase from a KieContainer with the same ReleaseId second time fails on NullPoinerException [1]. Reproducer can be found here [2].

[1] https://gist.github.com/baldimir/b3fa7ed299d5e0d7b74e4cc8bc4878f3
[2] https://github.com/kiegroup/drools/pull/1681



  was:
Creating the same KieBase from a KieContainer with the same ReleaseId second time fails on NullPoinerException [1]. I will create a PR with a reproducer.

[1] https://gist.github.com/baldimir/b3fa7ed299d5e0d7b74e4cc8bc4878f3





> Cannot recreate the same KieBase when using canonical model
> -----------------------------------------------------------
>
>                 Key: DROOLS-2213
>                 URL: https://issues.jboss.org/browse/DROOLS-2213
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Mario Fusco
>
> Creating the same KieBase from a KieContainer with the same ReleaseId second time fails on NullPoinerException [1]. Reproducer can be found here [2].
> [1] https://gist.github.com/baldimir/b3fa7ed299d5e0d7b74e4cc8bc4878f3
> [2] https://github.com/kiegroup/drools/pull/1681



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan  4 10:39:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 4 Jan 2018 10:39:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-483) GssapiTestSuite and Gs2Test
 fail with com.ibm.security.krb5.KrbException, status code: 9 for IBM JDK
In-Reply-To: <JIRA.12613243.1459842812000@Atlassian.JIRA>
References: <JIRA.12613243.1459842812000@Atlassian.JIRA>
	<JIRA.12613243.1459842812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613243.1459842812000.38.1515080341510@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-483:
---------------------------
    Labels: ibm-java  (was: )


> GssapiTestSuite and Gs2Test fail with com.ibm.security.krb5.KrbException, status code: 9 for IBM JDK
> ----------------------------------------------------------------------------------------------------
>
>                 Key: ELY-483
>                 URL: https://issues.jboss.org/browse/ELY-483
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta5
>            Reporter: Ondrej Lukas
>              Labels: ibm-java
>
> Test cases initialization from GssapiTestSuite and Gs2Test fail with following exception for IBM JDK:
> {code}
> javax.security.auth.login.FailedLoginException: 
> Login error: com.ibm.security.krb5.KrbException, status code: 9
> 	message: The client or server has a null key
> 	at com.ibm.security.jgss.i18n.I18NException.throwFailedLoginException(I18NException.java:15)
> 	at com.ibm.security.auth.module.Krb5LoginModule.j(Krb5LoginModule.java:727)
> 	at com.ibm.security.auth.module.Krb5LoginModule.b(Krb5LoginModule.java:307)
> 	at com.ibm.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:59)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:788)
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:196)
> 	at javax.security.auth.login.LoginContext$5.run(LoginContext.java:721)
> 	at javax.security.auth.login.LoginContext$5.run(LoginContext.java:719)
> 	at java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:719)
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:593)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.login(JaasUtil.java:71)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.loginClient(JaasUtil.java:53)
> 	at org.wildfly.security.sasl.gssapi.JdkClientJdkServer.initialise(JdkClientJdkServer.java:47)
>     ...
> {code}
> It is test case issue but it can hide any another functional issue because affected tests are not running with IBM JDK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 10:40:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 4 Jan 2018 10:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-483) GssapiTestSuite and Gs2Test
 fail with com.ibm.security.krb5.KrbException, status code: 9 for IBM JDK
In-Reply-To: <JIRA.12613243.1459842812000@Atlassian.JIRA>
References: <JIRA.12613243.1459842812000@Atlassian.JIRA>
	<JIRA.12613243.1459842812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613243.1459842812000.41.1515080400685@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-483:
------------------------------

    Assignee: Jan Kalina


> GssapiTestSuite and Gs2Test fail with com.ibm.security.krb5.KrbException, status code: 9 for IBM JDK
> ----------------------------------------------------------------------------------------------------
>
>                 Key: ELY-483
>                 URL: https://issues.jboss.org/browse/ELY-483
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta5
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>              Labels: ibm-java
>
> Test cases initialization from GssapiTestSuite and Gs2Test fail with following exception for IBM JDK:
> {code}
> javax.security.auth.login.FailedLoginException: 
> Login error: com.ibm.security.krb5.KrbException, status code: 9
> 	message: The client or server has a null key
> 	at com.ibm.security.jgss.i18n.I18NException.throwFailedLoginException(I18NException.java:15)
> 	at com.ibm.security.auth.module.Krb5LoginModule.j(Krb5LoginModule.java:727)
> 	at com.ibm.security.auth.module.Krb5LoginModule.b(Krb5LoginModule.java:307)
> 	at com.ibm.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:59)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:788)
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:196)
> 	at javax.security.auth.login.LoginContext$5.run(LoginContext.java:721)
> 	at javax.security.auth.login.LoginContext$5.run(LoginContext.java:719)
> 	at java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:719)
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:593)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.login(JaasUtil.java:71)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.loginClient(JaasUtil.java:53)
> 	at org.wildfly.security.sasl.gssapi.JdkClientJdkServer.initialise(JdkClientJdkServer.java:47)
>     ...
> {code}
> It is test case issue but it can hide any another functional issue because affected tests are not running with IBM JDK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 10:42:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 4 Jan 2018 10:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2212) [DMN Editor] Relation and
 Invocation can not be saved
In-Reply-To: <JIRA.12726502.1515071343000@Atlassian.JIRA>
References: <JIRA.12726502.1515071343000@Atlassian.JIRA>
	<JIRA.12726502.1515071343000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726502.1515071343000.54.1515080520449@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2212:
-----------------------------------
    Sprint: 2018 Week 01-02


> [DMN Editor] Relation and Invocation can not be saved
> -----------------------------------------------------
>
>                 Key: DROOLS-2212
>                 URL: https://issues.jboss.org/browse/DROOLS-2212
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: error.log
>
>
> Save operation in dmn editor throws an exception if the dmn diagram contains decision node holding relation or invocation context entry.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 10:43:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 4 Jan 2018 10:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1298) GssapiCompatibilitySuiteChild
 fails on IBM JDK
In-Reply-To: <JIRA.12703073.1500634358000@Atlassian.JIRA>
References: <JIRA.12703073.1500634358000@Atlassian.JIRA>
	<JIRA.12703073.1500634358000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12703073.1500634358000.59.1515080580764@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-1298:
-------------------------------

    Assignee: Jan Kalina


> GssapiCompatibilitySuiteChild fails on IBM JDK
> ----------------------------------------------
>
>                 Key: ELY-1298
>                 URL: https://issues.jboss.org/browse/ELY-1298
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: ibm-java
>
> A followup of ELY-1293
> {{System.currentTimeMillis()}} is native in IBM JDK and at the same time, IBM JDK does not support  java.lang.instrument API for native methods. Therefore, {{System.currentTimeMillis()}} cannot be mocked on IBM JDK using jmockit.
> {code}
> export JAVA_HOME=path/to/ibm/java8
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> mvn clean test 
> {code}
> Expected: the tests mocking {{System.currentTimeMillis()}} should pass
> Actual: the tests mocking {{System.currentTimeMillis()}} throw the following exception or similar:
> {code}
> java.lang.UnsupportedOperationException: class redefinition failed: attempted to change method modifiers
> 	at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest$1.<init>(PeriodicRotatingFileAuditEndpointTest.java:212)
> 	at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest.mockTime(PeriodicRotatingFileAuditEndpointTest.java:212)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> This is currently the case with 
> * GssapiCompatibilitySuiteChild



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 10:56:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 4 Jan 2018 10:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-85) Support GSS-Proxy
In-Reply-To: <JIRA.12552990.1411397770000@Atlassian.JIRA>
References: <JIRA.12552990.1411397770000@Atlassian.JIRA>
	<JIRA.12552990.1411397770000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552990.1411397770000.146.1515081360626@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509428#comment-13509428 ] 

David Lloyd commented on ELY-85:
--------------------------------

Does this work on IBM?

> Support GSS-Proxy
> -----------------
>
>                 Key: ELY-85
>                 URL: https://issues.jboss.org/browse/ELY-85
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SASL
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta13
>
>
> GSS Proxy is something we should consider being able to support when running on an OS that supports it: -
> -https://fedorahosted.org/gss-proxy/-
> https://pagure.io/gssproxy
> The big first step will be to identify what is required to achieve this, is this something that can be solved with a custom login module or does this also impact on the Java supplied GSSAPI implementation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 12:07:00 2018
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Thu, 4 Jan 2018 12:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9509) Default SFSB Lifecycle
 methods transaction attribute causing warnings
In-Reply-To: <JIRA.12719044.1509573756000@Atlassian.JIRA>
References: <JIRA.12719044.1509573756000@Atlassian.JIRA>
	<JIRA.12719044.1509573756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719044.1509573756000.585.1515085620642@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9509?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509482#comment-13509482 ] 

RH Bugzilla Integration commented on WFLY-9509:
-----------------------------------------------

Ji?? B?lek <jbilek at redhat.com> changed the Status of [bug 1508105|https://bugzilla.redhat.com/show_bug.cgi?id=1508105] from ON_QA to VERIFIED

> Default SFSB Lifecycle methods transaction attribute causing warnings
> ---------------------------------------------------------------------
>
>                 Key: WFLY-9509
>                 URL: https://issues.jboss.org/browse/WFLY-9509
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 11.0.0.Final
>            Reporter: Brad Maxwell
>            Assignee: Brad Maxwell
>             Fix For: 12.0.0.Alpha1
>
>         Attachments: warning-reproducer.zip
>
>
> EJB 2 deployment that does not specify transaction attribute for lifecycle methods such as: ejbActivate, ejbRemove, ejbPassivate are logging this warning.
> JBAS014279: Invalid transaction attribute type REQUIRED on SFSB lifecyle method Method ejbRemove(), valid types are REQUIRES_NEW and NOT_SUPPORTED. Method will be treated as NOT_SUPPORTED.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan  4 12:31:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 4 Jan 2018 12:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3447) CLI security commands.
In-Reply-To: <JIRA.12723502.1512476013000@Atlassian.JIRA>
References: <JIRA.12723502.1512476013000@Atlassian.JIRA>
	<JIRA.12723502.1512476013000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723502.1512476013000.664.1515087060165@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise updated WFCORE-3447:
-----------------------------------------
    Description: 
In order to help configure server side security, a set of CLI commands should be defined to drive users to realise the main use cases:
- SSL keystore management
- SSL/HTTPS enablement/disablement
- SASL/HTTP authentication (based on certificate).

Analysis docs, work in progress: https://developer.jboss.org/wiki/SSLCommandsForCLI and https://developer.jboss.org/wiki/AuthenticationCommandsForCLI

  was:
In order to help configure server side security, a set of CLI commands should be defined to drive users to realise the main use cases:
- SSL keystore management
- SSL/HTTPS enablement/disablement
- SASL/HTTP authentication (based on certificate).

An analysis doc, work in progress: https://developer.jboss.org/wiki/SSLCommandsForCLI



> CLI security commands.
> ----------------------
>
>                 Key: WFCORE-3447
>                 URL: https://issues.jboss.org/browse/WFCORE-3447
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> In order to help configure server side security, a set of CLI commands should be defined to drive users to realise the main use cases:
> - SSL keystore management
> - SSL/HTTPS enablement/disablement
> - SASL/HTTP authentication (based on certificate).
> Analysis docs, work in progress: https://developer.jboss.org/wiki/SSLCommandsForCLI and https://developer.jboss.org/wiki/AuthenticationCommandsForCLI



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 13:01:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Thu, 4 Jan 2018 13:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9648) Restore ability to disable
 initial state transfer for replicated/distributed caches
In-Reply-To: <JIRA.12726655.1515088819000@Atlassian.JIRA>
References: <JIRA.12726655.1515088819000@Atlassian.JIRA>
	<JIRA.12726655.1515088819210@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726655.1515088819000.759.1515088860088@Atlassian.JIRA>

Paul Ferraro created WFLY-9648:
----------------------------------

             Summary: Restore ability to disable initial state transfer for replicated/distributed caches
                 Key: WFLY-9648
                 URL: https://issues.jboss.org/browse/WFLY-9648
             Project: WildFly
          Issue Type: Enhancement
          Components: Clustering
    Affects Versions: 11.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


{code:xml}<state-transfer mode="DISABLED|ACTIVE|PASSIVE"/>{code}

* DISABLED = cache starts cold, initial state transfer disabled
* ACTIVE = cache starts warm, where initial state transfer enabled, but cache is not available until complete
* PASSIVE = cache starts cold, but initial state transfer enabled



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 13:16:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 4 Jan 2018 13:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2212) [DMN Editor] Relation and
 Invocation can not be saved
In-Reply-To: <JIRA.12726502.1515071343000@Atlassian.JIRA>
References: <JIRA.12726502.1515071343000@Atlassian.JIRA>
	<JIRA.12726502.1515071343000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726502.1515071343000.809.1515089760478@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis resolved DROOLS-2212.
------------------------------------
    Resolution: Done


> [DMN Editor] Relation and Invocation can not be saved
> -----------------------------------------------------
>
>                 Key: DROOLS-2212
>                 URL: https://issues.jboss.org/browse/DROOLS-2212
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: error.log
>
>
> Save operation in dmn editor throws an exception if the dmn diagram contains decision node holding relation or invocation context entry.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 13:18:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 4 Jan 2018 13:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2212) [DMN Editor] Relation and
 Invocation can not be saved
In-Reply-To: <JIRA.12726502.1515071343000@Atlassian.JIRA>
References: <JIRA.12726502.1515071343000@Atlassian.JIRA>
	<JIRA.12726502.1515071343000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726502.1515071343000.812.1515089880095@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509509#comment-13509509 ] 

Michael Anstis commented on DROOLS-2212:
----------------------------------------

[~jomarko] Please see https://github.com/manstis/kie-wb-common/commit/9a5e4c253697558b172c57271bd007384d96d372

I am thinking of moving my branch into ```kiegroup/kie-wb-common``` and submit things as PRs too.. 

[~jomarko] [~tari_manga] WDYT (re: move DMN to ```kiegroup``` now)?

> [DMN Editor] Relation and Invocation can not be saved
> -----------------------------------------------------
>
>                 Key: DROOLS-2212
>                 URL: https://issues.jboss.org/browse/DROOLS-2212
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: error.log
>
>
> Save operation in dmn editor throws an exception if the dmn diagram contains decision node holding relation or invocation context entry.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 14:24:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Thu, 4 Jan 2018 14:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1946) DMN Editor
In-Reply-To: <JIRA.12696991.1497281558000@Atlassian.JIRA>
References: <JIRA.12696991.1497281558000@Atlassian.JIRA>
	<JIRA.12696991.1497281558000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696991.1497281558000.1012.1515093840673@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509527#comment-13509527 ] 

Liz Clayton commented on DROOLS-1946:
-------------------------------------

[~manstis] Linking to a related UX design jira for this work. 

> DMN Editor
> ----------
>
>                 Key: DROOLS-1946
>                 URL: https://issues.jboss.org/browse/DROOLS-1946
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>              Labels: UX
>             Fix For: 7.6.0.Final
>
>
> Place holder for all DMN Editor related activities



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 14:56:00 2018
From: issues at jboss.org (Pedro Almeida (JIRA))
Date: Thu, 4 Jan 2018 14:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.1049.1515095760634@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Almeida reopened DROOLS-2194:
-----------------------------------


[~tirelli] Thanks 4 all the indications. With that in mind, I changed my project to use no physical kJars but still, I would get the same error as I mentioned, and found more 2 others. I think I am doing all right now. Basically all is related to the SingleAccumulate class:

-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:124)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:88)

I created a small maven project and I was able to replicate the problems both using physical kJars and in-memory kJars.

> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 14:57:00 2018
From: issues at jboss.org (Pedro Almeida (JIRA))
Date: Thu, 4 Jan 2018 14:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.1053.1515095820281@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Almeida updated DROOLS-2194:
----------------------------------
    Attachment: DroolsDynamicReload.zip


> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>         Attachments: DroolsDynamicReload.zip
>
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 14:57:00 2018
From: issues at jboss.org (Pedro Almeida (JIRA))
Date: Thu, 4 Jan 2018 14:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.1057.1515095820475@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509537#comment-13509537 ] 

Pedro Almeida edited comment on DROOLS-2194 at 1/4/18 2:56 PM:
---------------------------------------------------------------

[~tirelli] Thanks 4 all the indications. With that in mind, I changed my project to use no physical kJars but still, I would get the same error as I mentioned, and found more 2 others. I think I am doing all right now. Basically all is related to the SingleAccumulate class:

-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:124)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:88)

I created a small maven project and I was able to replicate the problems both using physical kJars and in-memory kJars. I'm attaching it to the issue so you can take a look at it.

Thanks.


was (Author: littlemustard):
[~tirelli] Thanks 4 all the indications. With that in mind, I changed my project to use no physical kJars but still, I would get the same error as I mentioned, and found more 2 others. I think I am doing all right now. Basically all is related to the SingleAccumulate class:

-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:124)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:88)

I created a small maven project and I was able to replicate the problems both using physical kJars and in-memory kJars.

> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>         Attachments: DroolsDynamicReload.zip
>
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 14:58:00 2018
From: issues at jboss.org (Pedro Almeida (JIRA))
Date: Thu, 4 Jan 2018 14:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.1061.1515095880196@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509537#comment-13509537 ] 

Pedro Almeida edited comment on DROOLS-2194 at 1/4/18 2:57 PM:
---------------------------------------------------------------

[~tirelli] Thanks 4 all the indications. With that in mind, I changed my project to use no physical kJars but still, I would get the same error as I mentioned, and found 2 others more. I think I am doing all right now. Basically all is related to the SingleAccumulate class:

-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:124)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:88)

I created a small maven project and I was able to replicate the problems both using physical kJars and in-memory kJars. I'm attaching it to the issue so you can take a look at it.

Thanks.


was (Author: littlemustard):
[~tirelli] Thanks 4 all the indications. With that in mind, I changed my project to use no physical kJars but still, I would get the same error as I mentioned, and found more 2 others. I think I am doing all right now. Basically all is related to the SingleAccumulate class:

-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:124)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:88)

I created a small maven project and I was able to replicate the problems both using physical kJars and in-memory kJars. I'm attaching it to the issue so you can take a look at it.

Thanks.

> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>         Attachments: DroolsDynamicReload.zip
>
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 14:59:00 2018
From: issues at jboss.org (Pedro Almeida (JIRA))
Date: Thu, 4 Jan 2018 14:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.1066.1515095940243@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509537#comment-13509537 ] 

Pedro Almeida edited comment on DROOLS-2194 at 1/4/18 2:58 PM:
---------------------------------------------------------------

[~tirelli] Thanks 4 all the indications. With that in mind, I changed my project to use no physical kJars but still, I would get the same error as I mentioned, and found 2 others more. I think I am doing everything right now. Basically all is related to the SingleAccumulate class:

-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:124)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:88)

I created a small maven project and I was able to replicate the problems both using physical kJars and in-memory kJars. I'm attaching it to the issue so you can take a look at it.

Thanks.


was (Author: littlemustard):
[~tirelli] Thanks 4 all the indications. With that in mind, I changed my project to use no physical kJars but still, I would get the same error as I mentioned, and found 2 others more. I think I am doing all right now. Basically all is related to the SingleAccumulate class:

-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:124)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:88)

I created a small maven project and I was able to replicate the problems both using physical kJars and in-memory kJars. I'm attaching it to the issue so you can take a look at it.

Thanks.

> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>         Attachments: DroolsDynamicReload.zip
>
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 15:05:00 2018
From: issues at jboss.org (Pedro Almeida (JIRA))
Date: Thu, 4 Jan 2018 15:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.1085.1515096300132@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509537#comment-13509537 ] 

Pedro Almeida edited comment on DROOLS-2194 at 1/4/18 3:04 PM:
---------------------------------------------------------------

[~tirelli] Thanks 4 all the indications. With that in mind, I changed my project to use no physical kJars but still, I would get the same error as I mentioned, and found 2 others more. I think I am doing everything right now. Basically all is related to the SingleAccumulate class:

-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:124)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:88)

I created a small maven project and I was able to replicate the problems both using physical kJars and in-memory kJars. I'm attaching it to the issue so you can take a look at it.
You can run the tests located on the test folder.

Thanks.


was (Author: littlemustard):
[~tirelli] Thanks 4 all the indications. With that in mind, I changed my project to use no physical kJars but still, I would get the same error as I mentioned, and found 2 others more. I think I am doing everything right now. Basically all is related to the SingleAccumulate class:

-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:124)
-org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:88)

I created a small maven project and I was able to replicate the problems both using physical kJars and in-memory kJars. I'm attaching it to the issue so you can take a look at it.

Thanks.

> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>         Attachments: DroolsDynamicReload.zip
>
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 23:58:00 2018
From: issues at jboss.org (Jive JIRA Integration (JIRA))
Date: Thu, 4 Jan 2018 23:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9644) Wildfly 11 can't deploy
 simple REST web service because it can't find javax.ws.rs.core.Application
In-Reply-To: <JIRA.12726089.1514762045000@Atlassian.JIRA>
References: <JIRA.12726089.1514762045000@Atlassian.JIRA>
	<JIRA.12726089.1514762045000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726089.1514762045000.1848.1515128280347@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jive JIRA Integration updated WFLY-9644:
----------------------------------------
    Forum Reference: https://developer.jboss.org/message/979185#979185


> Wildfly 11 can't deploy simple REST web service because it can't find javax.ws.rs.core.Application
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9644
>                 URL: https://issues.jboss.org/browse/WFLY-9644
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 11.0.0.Final
>         Environment: Ubuntu 16.04, JDK 1.8
>            Reporter: Dean Schulze
>            Assignee: Alessio Soldano
>         Attachments: test-app.zip
>
>
> Simple JAX-RS .war file with an Application .class file (extends javax.ws.rs.core.Application) and one resource .class file.  No web.xml file.  Deploying gives this error:
> Cannot upload deployment: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.pdfupload.POST_MODULE" => "WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"pdfupload\" Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYRS0006: Could not load JAX-RS Application class Caused by: java.lang.ClassNotFoundException: pdf.upload.server.PdfUploadApplication from [Module \"deployment.pdfupload\" from Service Module Loader]"}}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan  4 23:59:00 2018
From: issues at jboss.org (jaikiran pai (JIRA))
Date: Thu, 4 Jan 2018 23:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9644) Wildfly 11 can't deploy
 simple REST web service because it can't find javax.ws.rs.core.Application
In-Reply-To: <JIRA.12726089.1514762045000@Atlassian.JIRA>
References: <JIRA.12726089.1514762045000@Atlassian.JIRA>
	<JIRA.12726089.1514762045000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726089.1514762045000.1854.1515128340250@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9644?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509641#comment-13509641 ] 

jaikiran pai commented on WFLY-9644:
------------------------------------

The referenced forum thread [1] has more details about what's causing this issue. There's also a dev list discussion [2] on what the expectations of a runtime-name are.

[1] https://developer.jboss.org/thread/276899
[2] http://lists.jboss.org/pipermail/wildfly-dev/2018-January/006299.html

> Wildfly 11 can't deploy simple REST web service because it can't find javax.ws.rs.core.Application
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9644
>                 URL: https://issues.jboss.org/browse/WFLY-9644
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>    Affects Versions: 11.0.0.Final
>         Environment: Ubuntu 16.04, JDK 1.8
>            Reporter: Dean Schulze
>            Assignee: Alessio Soldano
>         Attachments: test-app.zip
>
>
> Simple JAX-RS .war file with an Application .class file (extends javax.ws.rs.core.Application) and one resource .class file.  No web.xml file.  Deploying gives this error:
> Cannot upload deployment: {"WFLYCTL0080: Failed services" => {"jboss.deployment.unit.pdfupload.POST_MODULE" => "WFLYSRV0153: Failed to process phase POST_MODULE of deployment \"pdfupload\" Caused by: org.jboss.as.server.deployment.DeploymentUnitProcessingException: WFLYRS0006: Could not load JAX-RS Application class Caused by: java.lang.ClassNotFoundException: pdf.upload.server.PdfUploadApplication from [Module \"deployment.pdfupload\" from Service Module Loader]"}}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 00:46:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 5 Jan 2018 00:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2212) [DMN Editor] Relation and
 Invocation can not be saved
In-Reply-To: <JIRA.12726502.1515071343000@Atlassian.JIRA>
References: <JIRA.12726502.1515071343000@Atlassian.JIRA>
	<JIRA.12726502.1515071343000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726502.1515071343000.1926.1515131160308@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509644#comment-13509644 ] 

Jozef Marko commented on DROOLS-2212:
-------------------------------------

[~manstis] Personally I am definitely for merging into {{kiegroup/kie-wb-common}}. I think it will bring our work open to all kiegroup members and thus we could get more feedback.

> [DMN Editor] Relation and Invocation can not be saved
> -----------------------------------------------------
>
>                 Key: DROOLS-2212
>                 URL: https://issues.jboss.org/browse/DROOLS-2212
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: error.log
>
>
> Save operation in dmn editor throws an exception if the dmn diagram contains decision node holding relation or invocation context entry.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 01:08:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 5 Jan 2018 01:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2214) [DMN Editor] Content of the
 decision node is not copied
In-Reply-To: <JIRA.12726674.1515132439000@Atlassian.JIRA>
References: <JIRA.12726674.1515132439000@Atlassian.JIRA>
	<JIRA.12726674.1515132439543@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726674.1515132439000.1932.1515132480160@Atlassian.JIRA>

Jozef Marko created DROOLS-2214:
-----------------------------------

             Summary: [DMN Editor] Content of the decision node is not copied
                 Key: DROOLS-2214
                 URL: https://issues.jboss.org/browse/DROOLS-2214
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis


User has possibility to copy a DRG node by a CTRL+C shortcut, however the problem is that content of the node is not copied.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 01:10:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 5 Jan 2018 01:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2212) [DMN Editor] Relation and
 Invocation can not be saved
In-Reply-To: <JIRA.12726502.1515071343000@Atlassian.JIRA>
References: <JIRA.12726502.1515071343000@Atlassian.JIRA>
	<JIRA.12726502.1515071343000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726502.1515071343000.1935.1515132600120@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2212?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2212:
--------------------------------
    QE Status: VERIFIED  (was: ON_QA)


> [DMN Editor] Relation and Invocation can not be saved
> -----------------------------------------------------
>
>                 Key: DROOLS-2212
>                 URL: https://issues.jboss.org/browse/DROOLS-2212
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: error.log
>
>
> Save operation in dmn editor throws an exception if the dmn diagram contains decision node holding relation or invocation context entry.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 01:22:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 5 Jan 2018 01:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2215) [DMN Editor] Function
 Definition is not saved
In-Reply-To: <JIRA.12726675.1515133295000@Atlassian.JIRA>
References: <JIRA.12726675.1515133295000@Atlassian.JIRA>
	<JIRA.12726675.1515133295493@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726675.1515133295000.1939.1515133320177@Atlassian.JIRA>

Jozef Marko created DROOLS-2215:
-----------------------------------

             Summary: [DMN Editor] Function Definition is not saved
                 Key: DROOLS-2215
                 URL: https://issues.jboss.org/browse/DROOLS-2215
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 01:24:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 5 Jan 2018 01:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2216) [DMN Editor] Decision Table
 Definition is not saved
In-Reply-To: <JIRA.12726676.1515133398000@Atlassian.JIRA>
References: <JIRA.12726676.1515133398000@Atlassian.JIRA>
	<JIRA.12726676.1515133398839@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726676.1515133398000.1949.1515133440491@Atlassian.JIRA>

Jozef Marko created DROOLS-2216:
-----------------------------------

             Summary: [DMN Editor] Decision Table Definition is not saved
                 Key: DROOLS-2216
                 URL: https://issues.jboss.org/browse/DROOLS-2216
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 01:24:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 5 Jan 2018 01:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2216) [DMN Editor] Decision Table
 Definition is not saved
In-Reply-To: <JIRA.12726676.1515133399000@Atlassian.JIRA>
References: <JIRA.12726676.1515133399000@Atlassian.JIRA>
	<JIRA.12726676.1515133399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726676.1515133399000.1952.1515133440629@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2216:
--------------------------------
    Steps to Reproduce: 
# Create new DMN diagram
# Add Decision node
# Open Decision node properties
# Configure this Decision node as Decision Table
# Save DMN diagram
# Reopen the DMN Diagram
# Check the Decision node properties
# The Decision node won't be configured as a Decision Table more

  was:
# Create new DMN diagram
# Add Decision node
# Open Decision node properties
# Configure this Decision node as Function
# Save DMN diagram
# Reopen the DMN Diagram
# Check the Decision node properties
# The Decision node won't be configured as a Function more



> [DMN Editor] Decision Table Definition is not saved
> ---------------------------------------------------
>
>                 Key: DROOLS-2216
>                 URL: https://issues.jboss.org/browse/DROOLS-2216
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 01:26:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 5 Jan 2018 01:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133514000@Atlassian.JIRA>
References: <JIRA.12726677.1515133514000@Atlassian.JIRA>
	<JIRA.12726677.1515133514565@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133514000.1955.1515133560230@Atlassian.JIRA>

Jozef Marko created DROOLS-2217:
-----------------------------------

             Summary: [DMN Editor] Context Entry Definition is not saved
                 Key: DROOLS-2217
                 URL: https://issues.jboss.org/browse/DROOLS-2217
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 01:26:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 5 Jan 2018 01:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.1958.1515133560354@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2217:
--------------------------------
    Steps to Reproduce: 
# Create new DMN diagram
# Add Decision node
# Open Decision node properties
# Configure this Decision node as Context Entry
# Save DMN diagram
# Reopen the DMN Diagram
# Check the Decision node properties
# The Decision node won't be configured as a Context Entry more

  was:
# Create new DMN diagram
# Add Decision node
# Open Decision node properties
# Configure this Decision node as Decision Table
# Save DMN diagram
# Reopen the DMN Diagram
# Check the Decision node properties
# The Decision node won't be configured as a Decision Table more



> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 02:12:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 5 Jan 2018 02:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2218) Stabilize
 DecisionTableXLSServiceImplCDITest
In-Reply-To: <JIRA.12726681.1515136288000@Atlassian.JIRA>
References: <JIRA.12726681.1515136288000@Atlassian.JIRA>
	<JIRA.12726681.1515136288827@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726681.1515136288000.2018.1515136320068@Atlassian.JIRA>

Jozef Marko created DROOLS-2218:
-----------------------------------

             Summary: Stabilize DecisionTableXLSServiceImplCDITest
                 Key: DROOLS-2218
                 URL: https://issues.jboss.org/browse/DROOLS-2218
             Project: Drools
          Issue Type: Task
          Components: XLS Decision Table Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Jozef Marko


The test {{DecisionTableXLSServiceImplCDITest}} is failing during building PRs on jenkins. Stabilize the test.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 05:31:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 5 Jan 2018 05:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2215) [DMN Editor] Function
 Definition is not saved
In-Reply-To: <JIRA.12726675.1515133295000@Atlassian.JIRA>
References: <JIRA.12726675.1515133295000@Atlassian.JIRA>
	<JIRA.12726675.1515133295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726675.1515133295000.2644.1515148260550@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2215:
-----------------------------------
    Sprint: 2018 Week 01-02


> [DMN Editor] Function Definition is not saved
> ---------------------------------------------
>
>                 Key: DROOLS-2215
>                 URL: https://issues.jboss.org/browse/DROOLS-2215
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 05:32:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 5 Jan 2018 05:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2216) [DMN Editor] Decision Table
 Definition is not saved
In-Reply-To: <JIRA.12726676.1515133399000@Atlassian.JIRA>
References: <JIRA.12726676.1515133399000@Atlassian.JIRA>
	<JIRA.12726676.1515133399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726676.1515133399000.2650.1515148320434@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2216:
-----------------------------------
    Sprint: 2018 Week 01-02


> [DMN Editor] Decision Table Definition is not saved
> ---------------------------------------------------
>
>                 Key: DROOLS-2216
>                 URL: https://issues.jboss.org/browse/DROOLS-2216
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 05:32:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 5 Jan 2018 05:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.2657.1515148320612@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2217:
-----------------------------------
    Sprint: 2018 Week 01-02


> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 05:32:00 2018
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Fri, 5 Jan 2018 05:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3492) MBean remove notification
 listener use wrong operation name
In-Reply-To: <JIRA.12726716.1515148278000@Atlassian.JIRA>
References: <JIRA.12726716.1515148278000@Atlassian.JIRA>
	<JIRA.12726716.1515148278589@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726716.1515148278000.2654.1515148320552@Atlassian.JIRA>

Bartosz Baranowski created WFCORE-3492:
------------------------------------------

             Summary: MBean remove notification listener use wrong operation name
                 Key: WFCORE-3492
                 URL: https://issues.jboss.org/browse/WFCORE-3492
             Project: WildFly Core
          Issue Type: Bug
            Reporter: Bartosz Baranowski






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 05:32:00 2018
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Fri, 5 Jan 2018 05:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3492) MBean remove notification
 listener use wrong operation name
In-Reply-To: <JIRA.12726716.1515148279000@Atlassian.JIRA>
References: <JIRA.12726716.1515148279000@Atlassian.JIRA>
	<JIRA.12726716.1515148279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726716.1515148279000.2663.1515148320797@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509743#comment-13509743 ] 

Bartosz Baranowski commented on WFCORE-3492:
--------------------------------------------

https://github.com/wildfly/wildfly-core/blob/master/jmx/src/main/java/org/jboss/as/jmx/MBeanServerSignature.java#L92

> MBean remove notification listener use wrong operation name
> -----------------------------------------------------------
>
>                 Key: WFCORE-3492
>                 URL: https://issues.jboss.org/browse/WFCORE-3492
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Bartosz Baranowski
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 05:35:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 5 Jan 2018 05:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2214) [DMN Editor] Content of the
 decision node is not copied
In-Reply-To: <JIRA.12726674.1515132440000@Atlassian.JIRA>
References: <JIRA.12726674.1515132440000@Atlassian.JIRA>
	<JIRA.12726674.1515132440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726674.1515132440000.2675.1515148500408@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509744#comment-13509744 ] 

Michael Anstis commented on DROOLS-2214:
----------------------------------------

[~jomarko] [~roger600] I assume the {{CTRL-C}} feature is provided by Stunner? (I've not added anything specific yet!)

[~roger600] Could you please point me to where the applicable code is!?? I might need to extend it (provide the means to extend it) to copy more "node" data.

> [DMN Editor] Content of the decision node is not copied
> -------------------------------------------------------
>
>                 Key: DROOLS-2214
>                 URL: https://issues.jboss.org/browse/DROOLS-2214
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>
> User has possibility to copy a DRG node by a CTRL+C shortcut, however the problem is that content of the node is not copied.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 05:35:01 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 5 Jan 2018 05:35:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2214) [DMN Editor] Content of the
 decision node is not copied
In-Reply-To: <JIRA.12726674.1515132440000@Atlassian.JIRA>
References: <JIRA.12726674.1515132440000@Atlassian.JIRA>
	<JIRA.12726674.1515132440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726674.1515132440000.2684.1515148501803@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2214:
-----------------------------------
    Sprint: 2018 Week 03-04


> [DMN Editor] Content of the decision node is not copied
> -------------------------------------------------------
>
>                 Key: DROOLS-2214
>                 URL: https://issues.jboss.org/browse/DROOLS-2214
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>
> User has possibility to copy a DRG node by a CTRL+C shortcut, however the problem is that content of the node is not copied.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 06:18:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 5 Jan 2018 06:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-85) Support GSS-Proxy
In-Reply-To: <JIRA.12552990.1411397770000@Atlassian.JIRA>
References: <JIRA.12552990.1411397770000@Atlassian.JIRA>
	<JIRA.12552990.1411397770000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552990.1411397770000.2872.1515151080281@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-85?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509778#comment-13509778 ] 

Jan Kalina commented on ELY-85:
-------------------------------

Hasnt find way how to use native kerberos on IBM at all yet... will have to return to this yet...

> Support GSS-Proxy
> -----------------
>
>                 Key: ELY-85
>                 URL: https://issues.jboss.org/browse/ELY-85
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SASL
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta13
>
>
> GSS Proxy is something we should consider being able to support when running on an OS that supports it: -
> -https://fedorahosted.org/gss-proxy/-
> https://pagure.io/gssproxy
> The big first step will be to identify what is required to achieve this, is this something that can be solved with a custom login module or does this also impact on the Java supplied GSSAPI implementation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 07:09:00 2018
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Fri, 5 Jan 2018 07:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2205) Issues in KIE WB
In-Reply-To: <JIRA.12726289.1514971515000@Atlassian.JIRA>
References: <JIRA.12726289.1514971515000@Atlassian.JIRA>
	<JIRA.12726289.1514971515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726289.1514971515000.3121.1515154140273@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2205?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509819#comment-13509819 ] 

Toni Rikkola commented on DROOLS-2205:
--------------------------------------

3. The language features are usually behind for community. The team lacks native speakers for some of them, but any translation help from community is appreciated. 

For other areas. Yes please test with 7.5.0 I bet there has been bug fixes on the user creation area. If you still run into issues, please provide few steps for reproducing. 

> Issues in KIE WB
> ----------------
>
>                 Key: DROOLS-2205
>                 URL: https://issues.jboss.org/browse/DROOLS-2205
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.4.1.Final
>            Reporter: Senthil Kumar Kamaraj
>            Assignee: Toni Rikkola
>
> There are some issues in KIE workbench 7.4.1 release
>    1.  Creating group on KIE WB on tomcat throws exception sometimes, but the group is created.
>   2.  When trying to delete the user from KIE WB, the user is not getting deleted.
>   3.  Language support other than English is not complete: partial support
>    4.  Sometimes, when I am trying to perform operation on "newly created project" in KIE Workbench, URL is redirected to other existing project.
>     5.  KIE WB user creation: Unable to create new user gracefully from the GUI: error: Cannot read property 'p8b' of null.
>      
>      6.  The new user creation is failing if it is assigned to Groups and Roles.
>            Received Error : Group not found.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 07:15:00 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Fri, 5 Jan 2018 07:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3486) "shutdown --help" does not
 declare that '--timeout' is only relevant to standalone servers
In-Reply-To: <JIRA.12726358.1514983853000@Atlassian.JIRA>
References: <JIRA.12726358.1514983853000@Atlassian.JIRA>
	<JIRA.12726358.1514983853000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726358.1514983853000.3168.1515154500259@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges updated WFCORE-3486:
---------------------------------
    Description: 
In standalone mode, shutdown can be used with a timeout in order to execute a graceful shutdown of the server. 
In domain mode, this attribute is not used and it is not taken into account when the domain is shutting down.

The CLI output of {{shutdown -help}} does not declare that {{-timeout}} is only relevant to standalone servers and is it not allowed if {{-host}} is used. The handler should reject that combo.

  was:
In standalone mode shutdown can be used with a timeout in order to execute a graceful shutdown of the server. 
In domain mode this attribute is not used and it is not taken into account when the domian is shutting down.

The CLI output of 'shutdown --help' does not declare that '--timeout' is only relevant to standalone servers and is it not allowed if '--host' is used. The handler should reject that combo.



> "shutdown --help" does not declare that '--timeout' is only relevant to standalone servers 
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3486
>                 URL: https://issues.jboss.org/browse/WFCORE-3486
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Yeray Borges
>            Assignee: Yeray Borges
>            Priority: Minor
>
> In standalone mode, shutdown can be used with a timeout in order to execute a graceful shutdown of the server. 
> In domain mode, this attribute is not used and it is not taken into account when the domain is shutting down.
> The CLI output of {{shutdown -help}} does not declare that {{-timeout}} is only relevant to standalone servers and is it not allowed if {{-host}} is used. The handler should reject that combo.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 07:30:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 5 Jan 2018 07:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2215) [DMN Editor] Function
 Definition is not saved
In-Reply-To: <JIRA.12726675.1515133295000@Atlassian.JIRA>
References: <JIRA.12726675.1515133295000@Atlassian.JIRA>
	<JIRA.12726675.1515133295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726675.1515133295000.3265.1515155400366@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509835#comment-13509835 ] 

Michael Anstis commented on DROOLS-2215:
----------------------------------------

[~tari_manga] Could you please advise where/how you created the DMN files for the pre-existing tests? I'd like to do similar for the tests for this JIRA. 

> [DMN Editor] Function Definition is not saved
> ---------------------------------------------
>
>                 Key: DROOLS-2215
>                 URL: https://issues.jboss.org/browse/DROOLS-2215
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 07:59:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 5 Jan 2018 07:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2215) [DMN Editor] Function
 Definition is not saved
In-Reply-To: <JIRA.12726675.1515133295000@Atlassian.JIRA>
References: <JIRA.12726675.1515133295000@Atlassian.JIRA>
	<JIRA.12726675.1515133295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726675.1515133295000.3490.1515157140385@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis reassigned DROOLS-2215:
--------------------------------------

    Assignee: Matteo Mortari  (was: Michael Anstis)


> [DMN Editor] Function Definition is not saved
> ---------------------------------------------
>
>                 Key: DROOLS-2215
>                 URL: https://issues.jboss.org/browse/DROOLS-2215
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 08:00:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 5 Jan 2018 08:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2216) [DMN Editor] Decision Table
 Definition is not saved
In-Reply-To: <JIRA.12726676.1515133399000@Atlassian.JIRA>
References: <JIRA.12726676.1515133399000@Atlassian.JIRA>
	<JIRA.12726676.1515133399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726676.1515133399000.3494.1515157200656@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis reassigned DROOLS-2216:
--------------------------------------

    Assignee: Matteo Mortari  (was: Michael Anstis)


> [DMN Editor] Decision Table Definition is not saved
> ---------------------------------------------------
>
>                 Key: DROOLS-2216
>                 URL: https://issues.jboss.org/browse/DROOLS-2216
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 08:00:01 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 5 Jan 2018 08:00:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.3504.1515157201175@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis reassigned DROOLS-2217:
--------------------------------------

    Assignee: Matteo Mortari  (was: Michael Anstis)


> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 08:01:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 5 Jan 2018 08:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.3521.1515157260889@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509865#comment-13509865 ] 

Michael Anstis commented on DROOLS-2217:
----------------------------------------

[~jomarko] I tried creating a Context with current code (at 5-Jan) and could not replicate this. Can you check/provide more steps?

> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 08:06:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Fri, 5 Jan 2018 08:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.3556.1515157560147@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509868#comment-13509868 ] 

Matteo Mortari commented on DROOLS-2217:
----------------------------------------

Additionally, I don't believe a Decision can be a "context entry". A Context, yes, a Context-Entry alone, I don't think so.
/cc [~manstis][~jomarko]

> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 08:21:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 5 Jan 2018 08:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.3583.1515158460310@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509874#comment-13509874 ] 

Michael Anstis commented on DROOLS-2217:
----------------------------------------

[~tari_manga] I took [~jomarko] wording on face value; and made the Decision's Expression a Context with two ContextEntries....

The UI does not allow Users to create a ContextEntry as the child of a Decision; only as per the DMN hierachy: Decision->Context->ContextEntry.

> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 08:21:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 5 Jan 2018 08:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-483) GssapiTestSuite and Gs2Test
 fail with com.ibm.security.krb5.KrbException, status code: 9 for IBM JDK
In-Reply-To: <JIRA.12613243.1459842812000@Atlassian.JIRA>
References: <JIRA.12613243.1459842812000@Atlassian.JIRA>
	<JIRA.12613243.1459842812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613243.1459842812000.3592.1515158460698@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509875#comment-13509875 ] 

Jan Kalina commented on ELY-483:
--------------------------------

Will be fixed as suggested by [~olukas] + GSS compatiblity tests needs to be reconsidered - it was not good idea and it has more troubles like ELY-1298.

> GssapiTestSuite and Gs2Test fail with com.ibm.security.krb5.KrbException, status code: 9 for IBM JDK
> ----------------------------------------------------------------------------------------------------
>
>                 Key: ELY-483
>                 URL: https://issues.jboss.org/browse/ELY-483
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.1.0.Beta5
>            Reporter: Ondrej Lukas
>            Assignee: Jan Kalina
>              Labels: ibm-java
>
> Test cases initialization from GssapiTestSuite and Gs2Test fail with following exception for IBM JDK:
> {code}
> javax.security.auth.login.FailedLoginException: 
> Login error: com.ibm.security.krb5.KrbException, status code: 9
> 	message: The client or server has a null key
> 	at com.ibm.security.jgss.i18n.I18NException.throwFailedLoginException(I18NException.java:15)
> 	at com.ibm.security.auth.module.Krb5LoginModule.j(Krb5LoginModule.java:727)
> 	at com.ibm.security.auth.module.Krb5LoginModule.b(Krb5LoginModule.java:307)
> 	at com.ibm.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:59)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:95)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:55)
> 	at java.lang.reflect.Method.invoke(Method.java:507)
> 	at javax.security.auth.login.LoginContext.invoke(LoginContext.java:788)
> 	at javax.security.auth.login.LoginContext.access$000(LoginContext.java:196)
> 	at javax.security.auth.login.LoginContext$5.run(LoginContext.java:721)
> 	at javax.security.auth.login.LoginContext$5.run(LoginContext.java:719)
> 	at java.security.AccessController.doPrivileged(AccessController.java:686)
> 	at javax.security.auth.login.LoginContext.invokeCreatorPriv(LoginContext.java:719)
> 	at javax.security.auth.login.LoginContext.login(LoginContext.java:593)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.login(JaasUtil.java:71)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.loginClient(JaasUtil.java:53)
> 	at org.wildfly.security.sasl.gssapi.JdkClientJdkServer.initialise(JdkClientJdkServer.java:47)
>     ...
> {code}
> It is test case issue but it can hide any another functional issue because affected tests are not running with IBM JDK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 08:35:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 5 Jan 2018 08:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1937) [DMN Editor] Dynamic Form
 Properties with nested hierarchy binds to wrong object/widget
In-Reply-To: <JIRA.12699176.1498471606000@Atlassian.JIRA>
References: <JIRA.12699176.1498471606000@Atlassian.JIRA>
	<JIRA.12699176.1498471606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12699176.1498471606000.3699.1515159300191@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13509890#comment-13509890 ] 

Michael Anstis commented on DROOLS-1937:
----------------------------------------

[~pere.fernandez] [~roger600] Hi, I don't suppose anyone has any pointers for how [~pere.fernandez] worked around/fixed this!?!?

It is beginning to "bite" the DMN Editor that more people are starting to fiddle with..

> [DMN Editor] Dynamic Form Properties with nested hierarchy binds to wrong object/widget
> ---------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1937
>                 URL: https://issues.jboss.org/browse/DROOLS-1937
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Roger Mart?nez
>            Priority: Critical
>              Labels: Stunner
>
> The Dynamic Form generated from a nested object hierarchy binds objects/widgets to the incorrect instances. For example; the below classes define an {{Id}} form field that is used in both {{InputData}} (through inheritance) and {{InformationItem}} (through sub-form reference and inheritance). When changing the {{Id}} field (for example) in the {{InputData}} form property the "Id" value of the nested "Information Item" is updated.
> {code}
> public abstract class DMNModelInstrumentedBase implements DMNDefinition {
>  
>     //No @FormFields etc
>  
> }
>  
> public abstract class DMNElement extends DMNModelInstrumentedBase {
>  
>     @Property
>     @FormField
>     protected Id id;
>  
>     @Property
>     @FormField(afterElement = "id")
>     protected Label label;
>  
>     @Property
>     @FormField(afterElement = "label")
>     protected Description description;
>  
>     ....
> }
>  
> public abstract class NamedElement extends DMNElement {
>  
>     @Property
>     @FormField(afterElement = "description")
>     protected Name name;
>  
>     ....
> }
>  
> @FormDefinition(policy = FieldPolicy.ONLY_MARKED)
> public class InformationItem extends NamedElement implements DMNPropertySet {
>  
>     @Property
>     @FormField(afterElement = "name")
>     protected QName typeRef;
>  
>     ....
> }
> public abstract class DRGElement extends NamedElement {}
> @FormDefinition(policy = FieldPolicy.ONLY_MARKED)
> public class InputData extends DRGElement {
>     ...
>     @PropertySet
>     @FormField(afterElement = "name")
>     protected InformationItem variable;
>     ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan  5 08:43:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 5 Jan 2018 08:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2155) table editor should use
 full canvas area available
In-Reply-To: <JIRA.12722667.1511895299000@Atlassian.JIRA>
References: <JIRA.12722667.1511895299000@Atlassian.JIRA>
	<JIRA.12722667.1511895299000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722667.1511895299000.3749.1515159780385@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2155:
-----------------------------------
    Sprint: 2018 Week 01-02


> table editor should use full canvas area available
> --------------------------------------------------
>
>                 Key: DROOLS-2155
>                 URL: https://issues.jboss.org/browse/DROOLS-2155
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Michael Anstis
>            Priority: Minor
>              Labels: UX
>
> DMN table editor should use the full canvas width that is available (minus panels, toolbars, etc.) It should not appear as a smaller fixed size area, with scrollbars, within the canvas. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 10:03:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 5 Jan 2018 10:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2219) CCE on node memories when
 using rule units but inserting a fact into the shared memory
In-Reply-To: <JIRA.12726766.1515164546000@Atlassian.JIRA>
References: <JIRA.12726766.1515164546000@Atlassian.JIRA>
	<JIRA.12726766.1515164546362@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726766.1515164546000.4630.1515164580514@Atlassian.JIRA>

Mario Fusco created DROOLS-2219:
-----------------------------------

             Summary: CCE on node memories when using rule units but inserting a fact into the shared memory
                 Key: DROOLS-2219
                 URL: https://issues.jboss.org/browse/DROOLS-2219
             Project: Drools
          Issue Type: Bug
            Reporter: Mario Fusco
            Assignee: Edson Tirelli






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 10:03:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 5 Jan 2018 10:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2219) CCE on node memories when
 using rule units but inserting a fact into the shared memory
In-Reply-To: <JIRA.12726766.1515164546000@Atlassian.JIRA>
References: <JIRA.12726766.1515164546000@Atlassian.JIRA>
	<JIRA.12726766.1515164546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726766.1515164546000.4634.1515164580641@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reassigned DROOLS-2219:
-----------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)


> CCE on node memories when using rule units but inserting a fact into the shared memory
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2219
>                 URL: https://issues.jboss.org/browse/DROOLS-2219
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 10:03:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 5 Jan 2018 10:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2219) CCE on node memories when
 using rule units but inserting a fact into the shared memory
In-Reply-To: <JIRA.12726766.1515164546000@Atlassian.JIRA>
References: <JIRA.12726766.1515164546000@Atlassian.JIRA>
	<JIRA.12726766.1515164546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726766.1515164546000.4635.1515164580669@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2219:
--------------------------------
    Component/s: core engine


> CCE on node memories when using rule units but inserting a fact into the shared memory
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2219
>                 URL: https://issues.jboss.org/browse/DROOLS-2219
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 10:44:00 2018
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Fri, 5 Jan 2018 10:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8917) EJB run-as identity gets lost
 if an unsecured ejb in the call stack
In-Reply-To: <JIRA.12696744.1497035216000@Atlassian.JIRA>
References: <JIRA.12696744.1497035216000@Atlassian.JIRA>
	<JIRA.12696744.1497035216000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696744.1497035216000.4946.1515167040306@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8917?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510005#comment-13510005 ] 

RH Bugzilla Integration commented on WFLY-8917:
-----------------------------------------------

Ji?? B?lek <jbilek at redhat.com> changed the Status of [bug 1460347|https://bugzilla.redhat.com/show_bug.cgi?id=1460347] from ON_QA to VERIFIED

> EJB run-as identity gets lost if an unsecured ejb in the call stack 
> --------------------------------------------------------------------
>
>                 Key: WFLY-8917
>                 URL: https://issues.jboss.org/browse/WFLY-8917
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Derek Horton
>            Assignee: Darran Lofthouse
>             Fix For: 11.0.0.Beta1
>
>         Attachments: SimpleEAR_EJB3.ear
>
>
> Having an unsecured EJB in the call stack will cause the RunAs identity to get lost.
> An example might look like this:
> unsecured web app (RunAs: JBossAdmin) -> unsecured HelloBean EJB -> secured GoodBye EJB (RolesAllowed: JBossAdmin)
> This will fail as the unsecured ejb causes the RunAs identity to get dropped/lost.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan  5 10:45:00 2018
From: issues at jboss.org (Scott Van Wart (JIRA))
Date: Fri, 5 Jan 2018 10:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9529) Using injected JMS in a
 background task/thread leads to NameNotFoundException:
 java:comp/TransactionSynchronizationRegistry
In-Reply-To: <JIRA.12719861.1510066270000@Atlassian.JIRA>
References: <JIRA.12719861.1510066270000@Atlassian.JIRA>
	<JIRA.12719861.1510066270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719861.1510066270000.4952.1515167100395@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510006#comment-13510006 ] 

Scott Van Wart commented on WFLY-9529:
--------------------------------------

[~emmartins] I don't suppose there's a workaround for this in the meantime?  I'm at a couple of months and am still dealing with this regularly.

> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9529
>                 URL: https://issues.jboss.org/browse/WFLY-9529
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Naming
>    Affects Versions: 10.1.0.Final, 11.0.0.Final
>         Environment: Running on Windows 10, Java 64-bit 1.8.0_131
>            Reporter: Scott Van Wart
>            Assignee: Eduardo Martins
>              Labels: ActiveMQ, jms, transaction
>         Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete.  That seemed unreliable (sometimes it would still produce NameNotFoundException).  I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way.  Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project.  It can be built with Maven.  It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 10:59:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 5 Jan 2018 10:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9649) Clustering capabilities
 created via BinaryRequirementCapability need to define a dynamic name
 mapper
In-Reply-To: <JIRA.12726771.1515167906000@Atlassian.JIRA>
References: <JIRA.12726771.1515167906000@Atlassian.JIRA>
	<JIRA.12726771.1515167906663@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726771.1515167906000.5021.1515167940407@Atlassian.JIRA>

Paul Ferraro created WFLY-9649:
----------------------------------

             Summary: Clustering capabilities created via BinaryRequirementCapability need to define a dynamic name mapper
                 Key: WFLY-9649
                 URL: https://issues.jboss.org/browse/WFLY-9649
             Project: WildFly
          Issue Type: Bug
          Components: Clustering
    Affects Versions: 11.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro


This is required so that any tooling can correctly construct the capability names from a PathAddress using only the registered RuntimeCapability object.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 11:12:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 5 Jan 2018 11:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3492) MBean remove notification
 listener use wrong operation name
In-Reply-To: <JIRA.12726716.1515148279000@Atlassian.JIRA>
References: <JIRA.12726716.1515148279000@Atlassian.JIRA>
	<JIRA.12726716.1515148279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726716.1515148279000.5095.1515168720133@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-3492:
----------------------------------------

    Assignee: Bartosz Baranowski


Assigning to, Bartosz, as you already did a downstream PR.

> MBean remove notification listener use wrong operation name
> -----------------------------------------------------------
>
>                 Key: WFCORE-3492
>                 URL: https://issues.jboss.org/browse/WFCORE-3492
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 11:17:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 5 Jan 2018 11:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9633) Add mixed domain tests for
	EAP 7.1.0
In-Reply-To: <JIRA.12725936.1513892581000@Atlassian.JIRA>
References: <JIRA.12725936.1513892581000@Atlassian.JIRA>
	<JIRA.12725936.1513892581000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725936.1513892581000.5143.1515169020829@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-9633:
--------------------------------------

    Assignee: Kabir Khan  (was: Brian Stansberry)


> Add mixed domain tests for EAP 7.1.0
> ------------------------------------
>
>                 Key: WFLY-9633
>                 URL: https://issues.jboss.org/browse/WFLY-9633
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Test Suite
>            Reporter: Kabir Khan
>            Assignee: Kabir Khan
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 11:55:01 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 5 Jan 2018 11:55:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3485) Misleading
 failure-description for capabilities in domain
In-Reply-To: <JIRA.12726347.1514981870000@Atlassian.JIRA>
References: <JIRA.12726347.1514981870000@Atlassian.JIRA>
	<JIRA.12726347.1514981870000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726347.1514981870000.5310.1515171301554@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3485:
-------------------------------------
    Priority: Minor  (was: Major)


> Misleading failure-description for capabilities in domain
> ---------------------------------------------------------
>
>                 Key: WFCORE-3485
>                 URL: https://issues.jboss.org/browse/WFCORE-3485
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.10.Final
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> In case when configuration in domain.xml tries to reference any capability from host.xml (or vice versa), but should not be able to reference it then it correctly fails, but there is failure-description which is misleading. 
> Start domain with default domain.xml and host.xml and run following CLI command and see:
> {code}
> /profile=full/subsystem=elytron/http-authentication-factory=some-factory:add(http-server-mechanism-factory=global,security-domain=ManagementDomain)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.security.security-domain.ManagementDomain in context 'profile=full'; Possible registration points for this capability: 
> 		/host=master/subsystem=elytron/security-domain=*
> 		/profile=*/subsystem=elytron/security-domain=*"},
>     "rolled-back" => true
> }
> {code}
> It should show only correct registration point {{/profile=\*/subsystem=elytron/security-domain=\*}}. It is misleading because ManagementDomain capability exists in {{/host=master/subsystem=elytron/security-domain=*}}.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 12:00:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 5 Jan 2018 12:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3485) Misleading
 failure-description for capabilities in domain
In-Reply-To: <JIRA.12726347.1514981870000@Atlassian.JIRA>
References: <JIRA.12726347.1514981870000@Atlassian.JIRA>
	<JIRA.12726347.1514981870000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726347.1514981870000.5355.1515171600802@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3485?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510046#comment-13510046 ] 

Brian Stansberry commented on WFCORE-3485:
------------------------------------------

The /host=master/subsystem=elytron/security-domain=* location *is* a possible registration point for the capability, i.e. it's a resource address that can provide that capability. It's a valid point though that that registration point can't satisfy the requirement, so mentioning it is distracting. It can't satisfy the requirement because that address is in a CapabilityScope that is not visible to the /profile=* resources.

Whether we fix this will depend on how much complexity filtering the message output to account for scope adds.

> Misleading failure-description for capabilities in domain
> ---------------------------------------------------------
>
>                 Key: WFCORE-3485
>                 URL: https://issues.jboss.org/browse/WFCORE-3485
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.10.Final
>            Reporter: Ondrej Lukas
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> In case when configuration in domain.xml tries to reference any capability from host.xml (or vice versa), but should not be able to reference it then it correctly fails, but there is failure-description which is misleading. 
> Start domain with default domain.xml and host.xml and run following CLI command and see:
> {code}
> /profile=full/subsystem=elytron/http-authentication-factory=some-factory:add(http-server-mechanism-factory=global,security-domain=ManagementDomain)
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0369: Required capabilities are not available:
>     org.wildfly.security.security-domain.ManagementDomain in context 'profile=full'; Possible registration points for this capability: 
> 		/host=master/subsystem=elytron/security-domain=*
> 		/profile=*/subsystem=elytron/security-domain=*"},
>     "rolled-back" => true
> }
> {code}
> It should show only correct registration point {{/profile=\*/subsystem=elytron/security-domain=\*}}. It is misleading because ManagementDomain capability exists in {{/host=master/subsystem=elytron/security-domain=*}}.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 14:10:00 2018
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 5 Jan 2018 14:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9650) add persistence unit hint for
 JNDI lookup that returns object passed to persistence provider (for OGM to
 integrate with wildfly-nosql profiles)
In-Reply-To: <JIRA.12726812.1515179351000@Atlassian.JIRA>
References: <JIRA.12726812.1515179351000@Atlassian.JIRA>
	<JIRA.12726812.1515179351621@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726812.1515179351000.5638.1515179400112@Atlassian.JIRA>

Scott Marlow created WFLY-9650:
----------------------------------

             Summary: add persistence unit hint for JNDI lookup that returns object passed to persistence provider (for OGM to integrate with wildfly-nosql profiles)
                 Key: WFLY-9650
                 URL: https://issues.jboss.org/browse/WFLY-9650
             Project: WildFly
          Issue Type: Task
          Components: JPA / Hibernate
            Reporter: Scott Marlow
            Assignee: Scott Marlow






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 14:59:00 2018
From: issues at jboss.org (Farah Juma (JIRA))
Date: Fri, 5 Jan 2018 14:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3396) Provide certificate
 authority integration
In-Reply-To: <JIRA.12718944.1509541615000@Atlassian.JIRA>
References: <JIRA.12718944.1509541615000@Atlassian.JIRA>
	<JIRA.12718944.1509541615000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718944.1509541615000.5692.1515182340302@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Farah Juma updated WFCORE-3396:
-------------------------------
    Description: 
Let's Encrypt provide API to fully automate (gain/renew) certificate retrieval using ACME protocol. Integrate this capability into wildfly.

This can simplify administrator work. No need to perform certification renewal routine tasks.

This is follow up on WFCORE-3305 and piece of bigger task "Simplify SSL configuration in wildfly". That said it is just "User experience" issue. Administrator still can work with Let's Encrypt by third party client and just reference wildfly to this certificate.

[1] Latest draft: https://tools.ietf.org/html/draft-ietf-acme-acme-09

  was:
Let's Encrypt provide API to fully automate (gain/renew) certificate retrieval using ACME protocol. Integrate this capability into wildfly.

This can simplify administrator work. No need to perform certification renewal routine tasks.

This is follow up on WFCORE-3305 and piece of bigger task "Simplify SSL configuration in wildfly". That said it is just "User experience" issue. Administrator still can work with Let's Encrypt by third party client and just reference wildfly to this certificate.

[1] Latest draft: https://tools.ietf.org/html/draft-ietf-acme-acme-08



> Provide certificate authority integration
> -----------------------------------------
>
>                 Key: WFCORE-3396
>                 URL: https://issues.jboss.org/browse/WFCORE-3396
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: 4.0.0.Alpha2
>            Reporter: Martin Choma
>            Assignee: Farah Juma
>
> Let's Encrypt provide API to fully automate (gain/renew) certificate retrieval using ACME protocol. Integrate this capability into wildfly.
> This can simplify administrator work. No need to perform certification renewal routine tasks.
> This is follow up on WFCORE-3305 and piece of bigger task "Simplify SSL configuration in wildfly". That said it is just "User experience" issue. Administrator still can work with Let's Encrypt by third party client and just reference wildfly to this certificate.
> [1] Latest draft: https://tools.ietf.org/html/draft-ietf-acme-acme-09



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 15:41:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 5 Jan 2018 15:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1298) GssapiCompatibilitySuiteChild
 fails on IBM JDK
In-Reply-To: <JIRA.12703073.1500634358000@Atlassian.JIRA>
References: <JIRA.12703073.1500634358000@Atlassian.JIRA>
	<JIRA.12703073.1500634358000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12703073.1500634358000.5740.1515184860192@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510115#comment-13510115 ] 

Jan Kalina commented on ELY-1298:
---------------------------------

In the end will remove compatibility tests of GSSAPI - the output is mostly generated by backing GSS mechanism and it is very sensitive on its implementation. I will only extend checking of negotiated MAX_BUFFER/RAW_SEND_SIZE, which is more or less only thing negotiated by the SASL mechanism itself.

> GssapiCompatibilitySuiteChild fails on IBM JDK
> ----------------------------------------------
>
>                 Key: ELY-1298
>                 URL: https://issues.jboss.org/browse/ELY-1298
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: ibm-java
>
> A followup of ELY-1293
> {{System.currentTimeMillis()}} is native in IBM JDK and at the same time, IBM JDK does not support  java.lang.instrument API for native methods. Therefore, {{System.currentTimeMillis()}} cannot be mocked on IBM JDK using jmockit.
> {code}
> export JAVA_HOME=path/to/ibm/java8
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> mvn clean test 
> {code}
> Expected: the tests mocking {{System.currentTimeMillis()}} should pass
> Actual: the tests mocking {{System.currentTimeMillis()}} throw the following exception or similar:
> {code}
> java.lang.UnsupportedOperationException: class redefinition failed: attempted to change method modifiers
> 	at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest$1.<init>(PeriodicRotatingFileAuditEndpointTest.java:212)
> 	at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest.mockTime(PeriodicRotatingFileAuditEndpointTest.java:212)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> This is currently the case with 
> * GssapiCompatibilitySuiteChild



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan  5 16:20:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 5 Jan 2018 16:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2154) Design navigation between
 the DRG and DRD's
In-Reply-To: <JIRA.12722654.1511888546000@Atlassian.JIRA>
References: <JIRA.12722654.1511888546000@Atlassian.JIRA>
	<JIRA.12722654.1511888546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722654.1511888546000.5789.1515187200237@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510121#comment-13510121 ] 

Liz Clayton commented on DROOLS-2154:
-------------------------------------

Designs documented at: https://docs.google.com/document/d/14pnw6QUTj5BsUJyz4uP_ozLLkYBvCYGXd1VIaK6jFHQ/edit?ts=5a4feb47

> Design navigation between the DRG and DRD's
> -------------------------------------------
>
>                 Key: DROOLS-2154
>                 URL: https://issues.jboss.org/browse/DROOLS-2154
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>
> *Use case description:
*
> As a business user (Citizen Developer?), I want to navigate between the DRG and the DRDs, and the content of each node, to model business decision logic.
> *Requirements:*
> * Diagram modeling must be absolutely consistent with Process Modeler: Process Designer and DMN editors should provide the same features, support the same interactions and appear visually similar in all aspects to one and other at "Level 1". Divergence may exist at "Level 2".
> *Verification Conditions*
> * The user of this feature is able to understand that the the DRDs are subsets of the whole DRG model/file.
> * The user of this feature can seamlessly navigate between the diagrams and the content of the nodes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan  5 16:20:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 5 Jan 2018 16:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2154) Design navigation between
 the DRG and DRD's
In-Reply-To: <JIRA.12722654.1511888546000@Atlassian.JIRA>
References: <JIRA.12722654.1511888546000@Atlassian.JIRA>
	<JIRA.12722654.1511888546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722654.1511888546000.5793.1515187200328@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2154:
--------------------------------
    Attachment:     (was: Screen Shot 2017-12-15 at 10.16.33 AM.png)


> Design navigation between the DRG and DRD's
> -------------------------------------------
>
>                 Key: DROOLS-2154
>                 URL: https://issues.jboss.org/browse/DROOLS-2154
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>
> *Use case description:
*
> As a business user (Citizen Developer?), I want to navigate between the DRG and the DRDs, and the content of each node, to model business decision logic.
> *Requirements:*
> * Diagram modeling must be absolutely consistent with Process Modeler: Process Designer and DMN editors should provide the same features, support the same interactions and appear visually similar in all aspects to one and other at "Level 1". Divergence may exist at "Level 2".
> *Verification Conditions*
> * The user of this feature is able to understand that the the DRDs are subsets of the whole DRG model/file.
> * The user of this feature can seamlessly navigate between the diagrams and the content of the nodes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan  5 16:21:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 5 Jan 2018 16:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2154) Design navigation between
 the DRG and DRD's
In-Reply-To: <JIRA.12722654.1511888546000@Atlassian.JIRA>
References: <JIRA.12722654.1511888546000@Atlassian.JIRA>
	<JIRA.12722654.1511888546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722654.1511888546000.5802.1515187260584@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2154:
--------------------------------
    Attachment: Screen Shot 2018-01-05 at 2.26.30 PM.png


> Design navigation between the DRG and DRD's
> -------------------------------------------
>
>                 Key: DROOLS-2154
>                 URL: https://issues.jboss.org/browse/DROOLS-2154
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: Screen Shot 2018-01-05 at 2.26.30 PM.png
>
>
> *Use case description:
*
> As a business user (Citizen Developer?), I want to navigate between the DRG and the DRDs, and the content of each node, to model business decision logic.
> *Requirements:*
> * Diagram modeling must be absolutely consistent with Process Modeler: Process Designer and DMN editors should provide the same features, support the same interactions and appear visually similar in all aspects to one and other at "Level 1". Divergence may exist at "Level 2".
> *Verification Conditions*
> * The user of this feature is able to understand that the the DRDs are subsets of the whole DRG model/file.
> * The user of this feature can seamlessly navigate between the diagrams and the content of the nodes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan  5 16:22:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 5 Jan 2018 16:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2154) Design navigation between
 the DRG and DRD's
In-Reply-To: <JIRA.12722654.1511888546000@Atlassian.JIRA>
References: <JIRA.12722654.1511888546000@Atlassian.JIRA>
	<JIRA.12722654.1511888546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722654.1511888546000.5808.1515187320348@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2154:
--------------------------------
    Attachment: Screen Shot 2018-01-05 at 2.51.44 PM.png


> Design navigation between the DRG and DRD's
> -------------------------------------------
>
>                 Key: DROOLS-2154
>                 URL: https://issues.jboss.org/browse/DROOLS-2154
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: Screen Shot 2018-01-05 at 2.26.30 PM.png, Screen Shot 2018-01-05 at 2.56.09 PM.png
>
>
> *Use case description:
*
> As a business user (Citizen Developer?), I want to navigate between the DRG and the DRDs, and the content of each node, to model business decision logic.
> *Requirements:*
> * Diagram modeling must be absolutely consistent with Process Modeler: Process Designer and DMN editors should provide the same features, support the same interactions and appear visually similar in all aspects to one and other at "Level 1". Divergence may exist at "Level 2".
> *Verification Conditions*
> * The user of this feature is able to understand that the the DRDs are subsets of the whole DRG model/file.
> * The user of this feature can seamlessly navigate between the diagrams and the content of the nodes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan  5 16:22:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 5 Jan 2018 16:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2154) Design navigation between
 the DRG and DRD's
In-Reply-To: <JIRA.12722654.1511888546000@Atlassian.JIRA>
References: <JIRA.12722654.1511888546000@Atlassian.JIRA>
	<JIRA.12722654.1511888546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722654.1511888546000.5813.1515187320481@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2154:
--------------------------------
    Attachment: Screen Shot 2018-01-05 at 2.56.09 PM.png


> Design navigation between the DRG and DRD's
> -------------------------------------------
>
>                 Key: DROOLS-2154
>                 URL: https://issues.jboss.org/browse/DROOLS-2154
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: Screen Shot 2018-01-05 at 2.26.30 PM.png, Screen Shot 2018-01-05 at 2.56.09 PM.png
>
>
> *Use case description:
*
> As a business user (Citizen Developer?), I want to navigate between the DRG and the DRDs, and the content of each node, to model business decision logic.
> *Requirements:*
> * Diagram modeling must be absolutely consistent with Process Modeler: Process Designer and DMN editors should provide the same features, support the same interactions and appear visually similar in all aspects to one and other at "Level 1". Divergence may exist at "Level 2".
> *Verification Conditions*
> * The user of this feature is able to understand that the the DRDs are subsets of the whole DRG model/file.
> * The user of this feature can seamlessly navigate between the diagrams and the content of the nodes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan  5 16:22:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 5 Jan 2018 16:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2154) Design navigation between
 the DRG and DRD's
In-Reply-To: <JIRA.12722654.1511888546000@Atlassian.JIRA>
References: <JIRA.12722654.1511888546000@Atlassian.JIRA>
	<JIRA.12722654.1511888546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722654.1511888546000.5817.1515187320579@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2154:
--------------------------------
    Attachment:     (was: Screen Shot 2018-01-05 at 2.51.44 PM.png)


> Design navigation between the DRG and DRD's
> -------------------------------------------
>
>                 Key: DROOLS-2154
>                 URL: https://issues.jboss.org/browse/DROOLS-2154
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: Screen Shot 2018-01-05 at 2.26.30 PM.png, Screen Shot 2018-01-05 at 2.56.09 PM.png
>
>
> *Use case description:
*
> As a business user (Citizen Developer?), I want to navigate between the DRG and the DRDs, and the content of each node, to model business decision logic.
> *Requirements:*
> * Diagram modeling must be absolutely consistent with Process Modeler: Process Designer and DMN editors should provide the same features, support the same interactions and appear visually similar in all aspects to one and other at "Level 1". Divergence may exist at "Level 2".
> *Verification Conditions*
> * The user of this feature is able to understand that the the DRDs are subsets of the whole DRG model/file.
> * The user of this feature can seamlessly navigate between the diagrams and the content of the nodes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan  5 16:23:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 5 Jan 2018 16:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2154) Design navigation between
 the DRG and DRD's
In-Reply-To: <JIRA.12722654.1511888546000@Atlassian.JIRA>
References: <JIRA.12722654.1511888546000@Atlassian.JIRA>
	<JIRA.12722654.1511888546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722654.1511888546000.5821.1515187380176@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2154:
--------------------------------
    Attachment: Screen Shot 2018-01-05 at 3.12.08 PM.png


> Design navigation between the DRG and DRD's
> -------------------------------------------
>
>                 Key: DROOLS-2154
>                 URL: https://issues.jboss.org/browse/DROOLS-2154
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: Screen Shot 2018-01-05 at 2.26.30 PM.png, Screen Shot 2018-01-05 at 2.56.09 PM.png, Screen Shot 2018-01-05 at 3.12.08 PM.png
>
>
> *Use case description:
*
> As a business user (Citizen Developer?), I want to navigate between the DRG and the DRDs, and the content of each node, to model business decision logic.
> *Requirements:*
> * Diagram modeling must be absolutely consistent with Process Modeler: Process Designer and DMN editors should provide the same features, support the same interactions and appear visually similar in all aspects to one and other at "Level 1". Divergence may exist at "Level 2".
> *Verification Conditions*
> * The user of this feature is able to understand that the the DRDs are subsets of the whole DRG model/file.
> * The user of this feature can seamlessly navigate between the diagrams and the content of the nodes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan  5 18:10:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 5 Jan 2018 18:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9648) Restore ability to disable
 initial state transfer for replicated/distributed caches
In-Reply-To: <JIRA.12726655.1515088819000@Atlassian.JIRA>
References: <JIRA.12726655.1515088819000@Atlassian.JIRA>
	<JIRA.12726655.1515088819000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726655.1515088819000.5911.1515193800219@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated WFLY-9648:
-------------------------------
    Description: Additionally, a timeout of zero should auto-disable awaitInitialTransfer.  (was: {code:xml}<state-transfer mode="DISABLED|ACTIVE|PASSIVE"/>{code}

* DISABLED = cache starts cold, initial state transfer disabled
* ACTIVE = cache starts warm, where initial state transfer enabled, but cache is not available until complete
* PASSIVE = cache starts cold, but initial state transfer enabled)


> Restore ability to disable initial state transfer for replicated/distributed caches
> -----------------------------------------------------------------------------------
>
>                 Key: WFLY-9648
>                 URL: https://issues.jboss.org/browse/WFLY-9648
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Clustering
>    Affects Versions: 11.0.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>
> Additionally, a timeout of zero should auto-disable awaitInitialTransfer.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan  6 07:25:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 6 Jan 2018 07:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1482) GSSAPI tests can be more clear
 as Parameterized
In-Reply-To: <JIRA.12726824.1515241455000@Atlassian.JIRA>
References: <JIRA.12726824.1515241455000@Atlassian.JIRA>
	<JIRA.12726824.1515241455138@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726824.1515241455000.6048.1515241500138@Atlassian.JIRA>

Jan Kalina created ELY-1482:
-------------------------------

             Summary: GSSAPI tests can be more clear as Parameterized
                 Key: ELY-1482
                 URL: https://issues.jboss.org/browse/ELY-1482
             Project: WildFly Elytron
          Issue Type: Enhancement
            Reporter: Jan Kalina
            Assignee: Jan Kalina


This 4 tests in GssapiTestSuite can be replaced by one Parametrized JUnit test:
* JdkClientJdkServerSuiteChild
* JdkClientWildFlyServerSuiteChild
* WildFlyClientJdkServerSuiteChild
* WildFlyClientWildFlyServerSuiteChild



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan  6 07:25:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 6 Jan 2018 07:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1482) GSSAPI tests can be more clear
 as Parameterized
In-Reply-To: <JIRA.12726824.1515241455000@Atlassian.JIRA>
References: <JIRA.12726824.1515241455000@Atlassian.JIRA>
	<JIRA.12726824.1515241455000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726824.1515241455000.6050.1515241500332@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1482:
----------------------------
    Component/s: Testsuite


> GSSAPI tests can be more clear as Parameterized
> -----------------------------------------------
>
>                 Key: ELY-1482
>                 URL: https://issues.jboss.org/browse/ELY-1482
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Testsuite
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> This 4 tests in GssapiTestSuite can be replaced by one Parametrized JUnit test:
> * JdkClientJdkServerSuiteChild
> * JdkClientWildFlyServerSuiteChild
> * WildFlyClientJdkServerSuiteChild
> * WildFlyClientWildFlyServerSuiteChild



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan  6 07:26:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Sat, 6 Jan 2018 07:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1482) GSSAPI tests can be more clear
 as Parameterized
In-Reply-To: <JIRA.12726824.1515241455000@Atlassian.JIRA>
References: <JIRA.12726824.1515241455000@Atlassian.JIRA>
	<JIRA.12726824.1515241455000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726824.1515241455000.6052.1515241560062@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1482:
----------------------------
    Affects Version/s: 1.2.0.Beta11


> GSSAPI tests can be more clear as Parameterized
> -----------------------------------------------
>
>                 Key: ELY-1482
>                 URL: https://issues.jboss.org/browse/ELY-1482
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Testsuite
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> This 4 tests in GssapiTestSuite can be replaced by one Parametrized JUnit test:
> * JdkClientJdkServerSuiteChild
> * JdkClientWildFlyServerSuiteChild
> * WildFlyClientJdkServerSuiteChild
> * WildFlyClientWildFlyServerSuiteChild



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan  6 11:56:00 2018
From: issues at jboss.org (Serg Pol (JIRA))
Date: Sat, 6 Jan 2018 11:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.6085.1515257760139@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510151#comment-13510151 ] 

Serg Pol commented on WFLY-9610:
--------------------------------

this delayed BatchJob is executed later if free thread appears, according my test. 
Is it possible to manage execution of delayed BatchJobs with status STARTING? To switch it off?
For example if BatchJob wasn't started because of no available free threads than it will not be started any more later, for example in half hour. 
Starting of BatchJobs in wrong time because of no available free threads now can be bad for some tasks-use cases.

> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan  6 12:14:00 2018
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Sat, 6 Jan 2018 12:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.6089.1515258840152@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510152#comment-13510152 ] 

Cheng Fang commented on WFLY-9610:
----------------------------------

A job execution in STARTING status can be stopped by the batch client.  So your requirement (run it or drop it) can be achieved by a timed stop operation from the batch client.  For a general time-to-live feature in job execution, we will need to evaluate it more.

> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan  6 12:57:00 2018
From: issues at jboss.org (Serg Pol (JIRA))
Date: Sat, 6 Jan 2018 12:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.6097.1515261420114@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510154#comment-13510154 ] 

Serg Pol commented on WFLY-9610:
--------------------------------

do You mean call jobOperator.stop(executionId) or abandon(executionId) in this case?
will it work in this case? because BatchJob wasn't yet started(status STARTING) in reality 
thanks

> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan  6 16:52:00 2018
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Sat, 6 Jan 2018 16:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.6104.1515275520214@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510156#comment-13510156 ] 

Cheng Fang commented on WFLY-9610:
----------------------------------

Calling jobOperator.stop(executionId) to stop the job execution.  It should work even though it's in STARTING status.  If it doesn't, please file a JIRA issue and it should be fixed.

> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan  6 22:08:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 6 Jan 2018 22:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3493) MBeanInfoFactory stores
 invalid minValue/maxValue data for jboss.as.expr domain
In-Reply-To: <JIRA.12726826.1515294459000@Atlassian.JIRA>
References: <JIRA.12726826.1515294459000@Atlassian.JIRA>
	<JIRA.12726826.1515294459036@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726826.1515294459000.6114.1515294480211@Atlassian.JIRA>

Brian Stansberry created WFCORE-3493:
----------------------------------------

             Summary: MBeanInfoFactory stores invalid minValue/maxValue data for jboss.as.expr domain
                 Key: WFCORE-3493
                 URL: https://issues.jboss.org/browse/WFCORE-3493
             Project: WildFly Core
          Issue Type: Task
          Components: JMX
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


MBeanInfoFactory.getParameterInfos is trying to store a minValue and maxValue in the OpenMBeanParameterInfo it creates if the DMR description data includes a "min" or a "max". This is fine when numeric types are what is being stored, but with the jboss.as.expr domain what's being stored are Strings. And OpenMBeanParameterInfo is meant to do meaningful comparisons of values against any configured min and max. It does this via Comparable.compareTo calls on the provided objects. That doesn't work with String, e.g. "6".compareTo("2147483647") reports that 6 is bigger.

Constructing the OpenMBeanParameterInfo itself will fail if item has a default that doesn't lexically compare properly with any min or max or if the min and max don't happen to lexically compare properly. The only reason this doesn't blow up now is we don't happen to have any attributes with default values that are lexically greater than the string form of their max (e.g. 3 or higher would be more than Integer.MAX_VALUE).

I expect we'd also see failures if anyone used the OpenMBeanParameterInfo we provide and called isValue on it with something like 3.

I think the correct solution is to simply not provide this data for any non-numeric OpenMBeanParameterInfo. There would be a loss of information provided to human readers who happen to inspect the OpenMBeanParameterInfo but what we provide now is not correct for software consumers. An alternative is to only turn this off is the attribute has a default that doesn't fall lexically between the min and the max, or if we have min that is lexically greater than the max. This would mean we continue to present human readable data and just hope that there are no software consumers that expect it to function as per the OpenMBeanParameterInfo javadoc.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan  6 22:18:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 6 Jan 2018 22:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3493) MBeanInfoFactory stores
 invalid minValue/maxValue data for jboss.as.expr domain
In-Reply-To: <JIRA.12726826.1515294459000@Atlassian.JIRA>
References: <JIRA.12726826.1515294459000@Atlassian.JIRA>
	<JIRA.12726826.1515294459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726826.1515294459000.6117.1515295080108@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3493:
-------------------------------------
    Issue Type: Bug  (was: Task)


> MBeanInfoFactory stores invalid minValue/maxValue data for jboss.as.expr domain
> -------------------------------------------------------------------------------
>
>                 Key: WFCORE-3493
>                 URL: https://issues.jboss.org/browse/WFCORE-3493
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: JMX
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> MBeanInfoFactory.getParameterInfos is trying to store a minValue and maxValue in the OpenMBeanParameterInfo it creates if the DMR description data includes a "min" or a "max". This is fine when numeric types are what is being stored, but with the jboss.as.expr domain what's being stored are Strings. And OpenMBeanParameterInfo is meant to do meaningful comparisons of values against any configured min and max. It does this via Comparable.compareTo calls on the provided objects. That doesn't work with String, e.g. "6".compareTo("2147483647") reports that 6 is bigger.
> Constructing the OpenMBeanParameterInfo itself will fail if item has a default that doesn't lexically compare properly with any min or max or if the min and max don't happen to lexically compare properly. The only reason this doesn't blow up now is we don't happen to have any attributes with default values that are lexically greater than the string form of their max (e.g. 3 or higher would be more than Integer.MAX_VALUE).
> I expect we'd also see failures if anyone used the OpenMBeanParameterInfo we provide and called isValue on it with something like 3.
> I think the correct solution is to simply not provide this data for any non-numeric OpenMBeanParameterInfo. There would be a loss of information provided to human readers who happen to inspect the OpenMBeanParameterInfo but what we provide now is not correct for software consumers. An alternative is to only turn this off is the attribute has a default that doesn't fall lexically between the min and the max, or if we have min that is lexically greater than the max. This would mean we continue to present human readable data and just hope that there are no software consumers that expect it to function as per the OpenMBeanParameterInfo javadoc.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan  6 22:23:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 6 Jan 2018 22:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-973) JMX - Non string attributes
 dont work well with expressions & min/max
In-Reply-To: <JIRA.12543947.1402913834000@Atlassian.JIRA>
References: <JIRA.12543947.1402913834000@Atlassian.JIRA>
	<JIRA.12543947.1402913834000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543947.1402913834000.6122.1515295380395@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-973?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510158#comment-13510158 ] 

Brian Stansberry commented on WFCORE-973:
-----------------------------------------

After many years I finally understand what the issue is here! I filed WFCORE-3493 which I now realize is the same thing that this is talking about. 

> JMX - Non string attributes dont work well with expressions & min/max
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-973
>                 URL: https://issues.jboss.org/browse/WFCORE-973
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, JMX
>            Reporter: Tomaz Cerar
>            Assignee: Enrique Gonz?lez Mart?nez
>            Priority: Minor
>         Attachments: stacktrace.log
>
>
> See ModelControllerMBeanTestCase.java:255
> problem is in conversion of attributes and when we have expressions jmx attribute type becomes String even if AD is of type INT
> And if attribute has min/max setting mbean fails validation upon creation
> I am not actually sure how we can fix this.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Sat Jan  6 22:23:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 6 Jan 2018 22:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-973) JMX - Non string attributes
 dont work well with expressions & min/max
In-Reply-To: <JIRA.12543947.1402913834000@Atlassian.JIRA>
References: <JIRA.12543947.1402913834000@Atlassian.JIRA>
	<JIRA.12543947.1402913834000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12543947.1402913834000.6127.1515295380599@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-973:
---------------------------------------

    Assignee: Brian Stansberry  (was: Enrique Gonz?lez Mart?nez)


> JMX - Non string attributes dont work well with expressions & min/max
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-973
>                 URL: https://issues.jboss.org/browse/WFCORE-973
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, JMX
>            Reporter: Tomaz Cerar
>            Assignee: Brian Stansberry
>            Priority: Minor
>         Attachments: stacktrace.log
>
>
> See ModelControllerMBeanTestCase.java:255
> problem is in conversion of attributes and when we have expressions jmx attribute type becomes String even if AD is of type INT
> And if attribute has min/max setting mbean fails validation upon creation
> I am not actually sure how we can fix this.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Sun Jan  7 15:57:00 2018
From: issues at jboss.org (Erik . (JIRA))
Date: Sun, 7 Jan 2018 15:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9391) Validation errors with
	"jboss-web_11_0.xsd
In-Reply-To: <JIRA.12713594.1506458582000@Atlassian.JIRA>
References: <JIRA.12713594.1506458582000@Atlassian.JIRA>
	<JIRA.12713594.1506458582000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12713594.1506458582000.6375.1515358620228@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510166#comment-13510166 ] 

Erik . commented on WFLY-9391:
------------------------------

The include for jboss-common_7_0.xsd 
{code:xml}
<xsd:include schemaLocation="jboss-common_7_0.xsd"/>
{code}
 to solve WFLY-5410 was added in jboss-web_10_1.xsd but not to jboss-web_10_0.xsd and jboss-web_11_0.xsd.



> Validation errors with "jboss-web_11_0.xsd
> ------------------------------------------
>
>                 Key: WFLY-9391
>                 URL: https://issues.jboss.org/browse/WFLY-9391
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.CR1
>            Reporter: Wolfgang Knauf
>            Assignee: Jason Greene
>
> Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
> First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee" 
> <xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
> The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
> It would probably also make sense to include the full schemaLocation URL ;-).
> After fixing the namespace, there are four more errors left:
> *src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a( n ) group component
> src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a( n ) 'simpleType definition' component
> src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
> src-resolve: Cannot resolve the name 'jboss:security-roleType' to a( n ) 'type definition' component*
> The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan  7 16:02:00 2018
From: issues at jboss.org (Erik . (JIRA))
Date: Sun, 7 Jan 2018 16:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9391) Validation errors with
	"jboss-web_11_0.xsd
In-Reply-To: <JIRA.12713594.1506458582000@Atlassian.JIRA>
References: <JIRA.12713594.1506458582000@Atlassian.JIRA>
	<JIRA.12713594.1506458582000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12713594.1506458582000.6383.1515358920429@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510166#comment-13510166 ] 

Erik . edited comment on WFLY-9391 at 1/7/18 4:01 PM:
------------------------------------------------------

The include for jboss-common_7_0.xsd 
{code:xml}
<xsd:include schemaLocation="jboss-common_7_0.xsd"/>
{code}
 to solve WFLY-5410 was added in jboss-web_10_1.xsd but not to jboss-web_10_0.xsd and jboss-web_11_0.xsd.

{code:xml}
<xsd:import schemaLocation="web-app_3_1.xsd" namespace="http://java.sun.com/xml/ns/javaee"/>
{code}
should be replace by
{code:xml}
   <xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="web-app_3_1.xsd"/>
   <xsd:include schemaLocation="jboss-common_7_0.xsd"/>
{code}



was (Author: emeuwese):
The include for jboss-common_7_0.xsd 
{code:xml}
<xsd:include schemaLocation="jboss-common_7_0.xsd"/>
{code}
 to solve WFLY-5410 was added in jboss-web_10_1.xsd but not to jboss-web_10_0.xsd and jboss-web_11_0.xsd.



> Validation errors with "jboss-web_11_0.xsd
> ------------------------------------------
>
>                 Key: WFLY-9391
>                 URL: https://issues.jboss.org/browse/WFLY-9391
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.CR1
>            Reporter: Wolfgang Knauf
>            Assignee: Jason Greene
>
> Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
> First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee" 
> <xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
> The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
> It would probably also make sense to include the full schemaLocation URL ;-).
> After fixing the namespace, there are four more errors left:
> *src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a( n ) group component
> src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a( n ) 'simpleType definition' component
> src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
> src-resolve: Cannot resolve the name 'jboss:security-roleType' to a( n ) 'type definition' component*
> The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan  7 16:02:00 2018
From: issues at jboss.org (Erik . (JIRA))
Date: Sun, 7 Jan 2018 16:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9391) Validation errors with
	"jboss-web_11_0.xsd
In-Reply-To: <JIRA.12713594.1506458582000@Atlassian.JIRA>
References: <JIRA.12713594.1506458582000@Atlassian.JIRA>
	<JIRA.12713594.1506458582000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12713594.1506458582000.6388.1515358920552@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510166#comment-13510166 ] 

Erik . edited comment on WFLY-9391 at 1/7/18 4:01 PM:
------------------------------------------------------

The include for jboss-common_7_0.xsd 
{code:xml}
<xsd:include schemaLocation="jboss-common_7_0.xsd"/>
{code}
 to solve WFLY-5410 was added in jboss-web_10_1.xsd but not to jboss-web_10_0.xsd and jboss-web_11_0.xsd.

The line in jboss-web_11_0.xsd
{code:xml}
<xsd:import schemaLocation="web-app_3_1.xsd" namespace="http://java.sun.com/xml/ns/javaee"/>
{code}
should be replace by:
{code:xml}
   <xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="web-app_3_1.xsd"/>
   <xsd:include schemaLocation="jboss-common_7_0.xsd"/>
{code}



was (Author: emeuwese):
The include for jboss-common_7_0.xsd 
{code:xml}
<xsd:include schemaLocation="jboss-common_7_0.xsd"/>
{code}
 to solve WFLY-5410 was added in jboss-web_10_1.xsd but not to jboss-web_10_0.xsd and jboss-web_11_0.xsd.

{code:xml}
<xsd:import schemaLocation="web-app_3_1.xsd" namespace="http://java.sun.com/xml/ns/javaee"/>
{code}
should be replace by
{code:xml}
   <xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="web-app_3_1.xsd"/>
   <xsd:include schemaLocation="jboss-common_7_0.xsd"/>
{code}


> Validation errors with "jboss-web_11_0.xsd
> ------------------------------------------
>
>                 Key: WFLY-9391
>                 URL: https://issues.jboss.org/browse/WFLY-9391
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.CR1
>            Reporter: Wolfgang Knauf
>            Assignee: Jason Greene
>
> Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
> First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee" 
> <xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
> The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
> It would probably also make sense to include the full schemaLocation URL ;-).
> After fixing the namespace, there are four more errors left:
> *src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a( n ) group component
> src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a( n ) 'simpleType definition' component
> src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
> src-resolve: Cannot resolve the name 'jboss:security-roleType' to a( n ) 'type definition' component*
> The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 02:12:00 2018
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Mon, 8 Jan 2018 02:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3492) MBean remove notification
 listener use wrong operation name
In-Reply-To: <JIRA.12726716.1515148279000@Atlassian.JIRA>
References: <JIRA.12726716.1515148279000@Atlassian.JIRA>
	<JIRA.12726716.1515148279000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726716.1515148279000.6861.1515395520143@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510219#comment-13510219 ] 

Bartosz Baranowski commented on WFCORE-3492:
--------------------------------------------

Ach, yeah, missed this, thanks.

> MBean remove notification listener use wrong operation name
> -----------------------------------------------------------
>
>                 Key: WFCORE-3492
>                 URL: https://issues.jboss.org/browse/WFCORE-3492
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Bartosz Baranowski
>            Assignee: Bartosz Baranowski
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 04:50:00 2018
From: issues at jboss.org (=?UTF-8?Q?Bartosz_Spyrko-=C5=9Amietanko_=28JIRA=29?=)
Date: Mon, 8 Jan 2018 04:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-129) Create a better error
 message if the time zone argument is missing from the %z format pattern
In-Reply-To: <JIRA.12613660.1459978581000@Atlassian.JIRA>
References: <JIRA.12613660.1459978581000@Atlassian.JIRA>
	<JIRA.12613660.1459978581000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12613660.1459978581000.7584.1515405000106@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-129?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Spyrko-?mietanko reassigned LOGMGR-129:
-----------------------------------------------

    Assignee:     (was: Bartosz Spyrko-?mietanko)


> Create a better error message if the time zone argument is missing from the %z format pattern
> ---------------------------------------------------------------------------------------------
>
>                 Key: LOGMGR-129
>                 URL: https://issues.jboss.org/browse/LOGMGR-129
>             Project: JBoss Log Manager
>          Issue Type: Task
>            Reporter: James Perkins
>
> Using the {{%z}} format pattern and not including a time zone argument results in an NPE. A better error message should be thrown indicating an argument is required.
> {code:title=Example pattern}
> %z{GMT}
> {code}
> A bonus would be to possibly add a warning, once only though, if the time {{%d}} was processed before the time zone {{%z}}.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan  8 05:33:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 8 Jan 2018 05:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3494) CLI,
 infinite loop when accepting temporarily SSL certificate
In-Reply-To: <JIRA.12726888.1515407570000@Atlassian.JIRA>
References: <JIRA.12726888.1515407570000@Atlassian.JIRA>
	<JIRA.12726888.1515407570364@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726888.1515407570000.7861.1515407580080@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-3494:
--------------------------------------------

             Summary: CLI, infinite loop when accepting temporarily SSL certificate
                 Key: WFCORE-3494
                 URL: https://issues.jboss.org/browse/WFCORE-3494
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


Scenario:
1) Accept Temporarily CERT1 CN=CA,
2) Disable SSL
3) Enable SSL with new certificate CERT2, same DN CN=CA
4) Prompt user to accept CERT2, Internal certificates set iterator returns items in this order (important): CERT2,CERT1
5) Internally create a delegate that will do the actual certificate check and add to it all certificates: theTrustStore.setCertificateEntry(current.getSubjectX500Principal().getName(), current);
6) So CERT1 and CERT2 are sharing the same name, CERT1 overrides CERT2, CERT2 (the certificate to add) will never be added
7) Infinite loop.

The problem comes from the fact that DN is used as the alias. In the case of temporarily added certificate, a unique alias should be created.

For certificate added permanently to the trust-store, the DN is also used as the alias. In this case, the last accepted certificate is the one stored, there is no mismatch.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 05:49:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 8 Jan 2018 05:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3495) Update jboss-logmanager to
	2.1.0.Alpha6
In-Reply-To: <JIRA.12726894.1515408471000@Atlassian.JIRA>
References: <JIRA.12726894.1515408471000@Atlassian.JIRA>
	<JIRA.12726894.1515408471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726894.1515408471000.7961.1515408540377@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky moved JBEAP-14053 to WFCORE-3495:
-----------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-3495  (was: JBEAP-14053)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Logging
                           (was: Logging)
    Affects Version/s:     (was: 7.1.0.CR3)
        Fix Version/s:     (was: 7.1.1.GA)


> Update jboss-logmanager to 2.1.0.Alpha6
> ---------------------------------------
>
>                 Key: WFCORE-3495
>                 URL: https://issues.jboss.org/browse/WFCORE-3495
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Logging
>            Reporter: Ivo Studensky
>            Assignee: Petr Saka?
>
> Version of log manager needs to be updated to include some bug fixes



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan  8 05:50:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 8 Jan 2018 05:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3495) Update jboss-logmanager to
	2.1.0.Alpha6
In-Reply-To: <JIRA.12726894.1515408471000@Atlassian.JIRA>
References: <JIRA.12726894.1515408471000@Atlassian.JIRA>
	<JIRA.12726894.1515408471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726894.1515408471000.7971.1515408600318@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky reassigned WFCORE-3495:
-------------------------------------

    Assignee: James Perkins  (was: Petr Saka?)


> Update jboss-logmanager to 2.1.0.Alpha6
> ---------------------------------------
>
>                 Key: WFCORE-3495
>                 URL: https://issues.jboss.org/browse/WFCORE-3495
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Logging
>            Reporter: Ivo Studensky
>            Assignee: James Perkins
>
> Version of log manager needs to be updated to include some bug fixes



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan  8 06:44:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 8 Jan 2018 06:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794471@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.8647.1515411840609@Atlassian.JIRA>

Martin Choma created ELY-1483:
---------------------------------

             Summary: japicmp detects compatibility issues
                 Key: ELY-1483
                 URL: https://issues.jboss.org/browse/ELY-1483
             Project: WildFly Elytron
          Issue Type: Bug
          Components: API / SPI
    Affects Versions: 1.2.0.Beta11
            Reporter: Martin Choma
            Priority: Critical
             Fix For: 1.2.0.Beta12


I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  These incompatibilities were detected:

- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)

[1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 06:45:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 8 Jan 2018 06:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.8668.1515411900405@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1483:
------------------------------
    Attachment: japicmp.html


> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  These incompatibilities were detected:
> - removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 06:52:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 8 Jan 2018 06:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.8753.1515412320414@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1483:
------------------------------
    Description: 
I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  These incompatibilities were detected:

- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)

[1] https://github.com/wildfly-security/wildfly-elytron/pull/1067

  was:
I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  These incompatibilities were detected:

- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)

[1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  These incompatibilities were detected:
> - removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 06:58:02 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 8 Jan 2018 06:58:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.8810.1515412682562@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510741#comment-13510741 ] 

Darran Lofthouse commented on ELY-1483:
---------------------------------------

[~fjuma] Do you mind taking a look into this one?  I think the ans1.util package was never public so that one may be a false positive but some of the other do seem to be popping up in our public javadoc, may need to check if they were also public in our module definition.


> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  These incompatibilities were detected:
> - removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 07:08:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 8 Jan 2018 07:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.8854.1515413280141@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510748#comment-13510748 ] 

Martin Choma commented on ELY-1483:
-----------------------------------

Packages asn1 and x500 were included into check per Farah comment https://github.com/wildfly-security/wildfly-elytron/pull/1038#discussion_r158077176

But thinking about it now, probably they should be not included in this stage, because they were private in 1.1.7.Final (weren't mentioned in module definition)?

They should be included once we will compare 1.2.x with 1.next

> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  These incompatibilities were detected:
> - removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 07:49:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 8 Jan 2018 07:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.9113.1515415740360@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510776#comment-13510776 ] 

Darran Lofthouse commented on ELY-1483:
---------------------------------------

+1 that is something else we need to take into account, as at the point we released a 1.1.x Final we need the signatures based on what was public at the time to verify against 1.2.x - when we tag a Final of 1.2.x we will have a new definition of which packages are public to take forward.

> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  These incompatibilities were detected:
> - removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 08:11:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 8 Jan 2018 08:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.9213.1515417060355@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510798#comment-13510798 ] 

Jozef Marko commented on DROOLS-2217:
-------------------------------------

Sorry for my wording, I will be more careful next time.

> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 08:29:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 8 Jan 2018 08:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.9326.1515418140358@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510830#comment-13510830 ] 

Matteo Mortari commented on DROOLS-2217:
----------------------------------------

Not a problem, I thought there could have been a problem if the UI allowed, hence mentioned.

I think you can indeed retest this, and the Context should normally be already saved correctly, as per previous work done on master.

> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 08:55:01 2018
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 8 Jan 2018 08:55:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1436) Log jdbc-realm key-mapper
	processing
In-Reply-To: <JIRA.12719794.1510048725000@Atlassian.JIRA>
References: <JIRA.12719794.1510048725000@Atlassian.JIRA>
	<JIRA.12719794.1510048725000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719794.1510048725000.9494.1515419701714@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-1436:
----------------------------------

    Assignee: Ilia Vassilev  (was: Darran Lofthouse)


> Log jdbc-realm key-mapper processing
> ------------------------------------
>
>                 Key: ELY-1436
>                 URL: https://issues.jboss.org/browse/ELY-1436
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>             Fix For: 1.2.0.Beta12
>
>
> User reported problem with getting work jdbc_realm with bcrypt mapper. He had configured org.wildfly.security to log TRACE messages, but log does not provide any useful information regarding mapping password from DB.
> In this case seems problem was in mixing base64 vs. modular crypt format.
> Looking into PasswordKeyMapper there is a lot of logic and lot of steps which can get wrong. So logging some TRACE messages can hint user what is going on and what went wrong.
> Also I have noticed there is unhandled exception. Please at least log some TRACE message.
> {code:java|title=PasswordKeyMapper.java}
> } catch (InvalidKeySpecException e) {
> 	// fall out (unlikely but possible)
> }
> {code}
> [1] https://developer.jboss.org/message/977727



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 09:07:02 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 8 Jan 2018 09:07:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1298) GssapiCompatibilitySuiteChild
 fails on IBM JDK
In-Reply-To: <JIRA.12703073.1500634358000@Atlassian.JIRA>
References: <JIRA.12703073.1500634358000@Atlassian.JIRA>
	<JIRA.12703073.1500634358000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12703073.1500634358000.9599.1515420422458@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510115#comment-13510115 ] 

Jan Kalina edited comment on ELY-1298 at 1/8/18 9:06 AM:
---------------------------------------------------------

In the end will remove compatibility tests of GSSAPI - the output is mostly generated by backing GSS mechanism and it is very sensitive on its implementation. Even if the time mocking would be resolved, the test will be unsustainable.
I will only extend checking of negotiated MAX_BUFFER/RAW_SEND_SIZE in other tests, which is more or less only thing negotiated by the SASL mechanism itself.


was (Author: honza889):
In the end will remove compatibility tests of GSSAPI - the output is mostly generated by backing GSS mechanism and it is very sensitive on its implementation. I will only extend checking of negotiated MAX_BUFFER/RAW_SEND_SIZE, which is more or less only thing negotiated by the SASL mechanism itself.

> GssapiCompatibilitySuiteChild fails on IBM JDK
> ----------------------------------------------
>
>                 Key: ELY-1298
>                 URL: https://issues.jboss.org/browse/ELY-1298
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: ibm-java
>
> A followup of ELY-1293
> {{System.currentTimeMillis()}} is native in IBM JDK and at the same time, IBM JDK does not support  java.lang.instrument API for native methods. Therefore, {{System.currentTimeMillis()}} cannot be mocked on IBM JDK using jmockit.
> {code}
> export JAVA_HOME=path/to/ibm/java8
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
> mvn clean test 
> {code}
> Expected: the tests mocking {{System.currentTimeMillis()}} should pass
> Actual: the tests mocking {{System.currentTimeMillis()}} throw the following exception or similar:
> {code}
> java.lang.UnsupportedOperationException: class redefinition failed: attempted to change method modifiers
> 	at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest$1.<init>(PeriodicRotatingFileAuditEndpointTest.java:212)
> 	at org.wildfly.security.audit.PeriodicRotatingFileAuditEndpointTest.mockTime(PeriodicRotatingFileAuditEndpointTest.java:212)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> {code}
> This is currently the case with 
> * GssapiCompatibilitySuiteChild



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 09:23:02 2018
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 8 Jan 2018 09:23:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1480) Coverity,
 Explicit null dereferenced in FileSystemSecurityRealm
In-Reply-To: <JIRA.12726441.1515053417000@Atlassian.JIRA>
References: <JIRA.12726441.1515053417000@Atlassian.JIRA>
	<JIRA.12726441.1515053417000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726441.1515053417000.9840.1515421382370@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-1480:
----------------------------------

    Assignee: Ilia Vassilev


> Coverity, Explicit null dereferenced in FileSystemSecurityRealm
> ---------------------------------------------------------------
>
>                 Key: ELY-1480
>                 URL: https://issues.jboss.org/browse/ELY-1480
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> There are 2 occurences of call to PasswordFactory.getInstance(algorithm) in FileSystemSecurityRealm where algorithm can be null, because algorithm is optional in wildfly-config.xml
> {code:xml|title=elytron-1_0_1.xsd}
>     <xsd:complexType name="credential-type">
>         <xsd:simpleContent>
>             <xsd:extension base="xsd:string">
>                 <xsd:attribute name="algorithm" type="xsd:string" use="optional"/>
>                 <xsd:attribute name="format" type="xsd:string" use="optional"/>
>             </xsd:extension>
>         </xsd:simpleContent>
>     </xsd:complexType>
>     <xsd:complexType name="otp-credential-type">
>         <xsd:simpleContent>
>             <xsd:extension base="xsd:string">
>                 <xsd:attribute name="algorithm" type="xsd:string" use="optional"/>
>                 <xsd:attribute name="hash" type="xsd:string" use="optional"/>
>                 <xsd:attribute name="seed" type="xsd:string" use="optional"/>
>                 <xsd:attribute name="sequence" type="xsd:string" use="optional"/>
>             </xsd:extension>
>         </xsd:simpleContent>
>     </xsd:complexType>
> {code}
> Algorithm is dereferenced in PasswordFactory.getInstance(algorithm) down in 
> {code:java|title=java.security.Provider$ServiceKey.java}
>         private ServiceKey(String type, String algorithm, boolean intern) {
>             this.type = type;
>             this.originalAlgorithm = algorithm;
>             algorithm = algorithm.toUpperCase(ENGLISH);
>             this.algorithm = intern ? algorithm.intern() : algorithm;
>         }
> {code}
> [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847809&defectInstanceId=9457601&mergedDefectId=1463442
> [2] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847809&defectInstanceId=9457602&mergedDefectId=1463441



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 09:24:01 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 8 Jan 2018 09:24:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2181) Icons (Edit, Collapse,
 Delete etc) do not respond to mouse clicks
In-Reply-To: <JIRA.12725260.1513341217000@Atlassian.JIRA>
References: <JIRA.12725260.1513341217000@Atlassian.JIRA>
	<JIRA.12725260.1513341217000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725260.1513341217000.9853.1515421441790@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511245#comment-13511245 ] 

Jozef Marko commented on DROOLS-2181:
-------------------------------------

If we have code freeze and there is no RHDM/RHBA jira for that, I think it shouldn't be on 7.5.x. I see your point Michael, that if user will enable trees and try them, they will not work, however I think as we don't support trees officially is fine to keep fix just in master.

> Icons (Edit, Collapse, Delete etc) do not respond to mouse clicks
> -----------------------------------------------------------------
>
>                 Key: DROOLS-2181
>                 URL: https://issues.jboss.org/browse/DROOLS-2181
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Tree Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>             Fix For: 7.6.0.Final
>
>
> - Double-click on a node (object/action) to edit/delete/collapse.
> - Pop-up shows the icons/buttons.
> - Click on Edit/Delete/collapse icon. Icons are frozen.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 09:24:01 2018
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 8 Jan 2018 09:24:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1479) Coverity,
 Missing call to superclass in AbstractGssapiMechanism
In-Reply-To: <JIRA.12726440.1515052215000@Atlassian.JIRA>
References: <JIRA.12726440.1515052215000@Atlassian.JIRA>
	<JIRA.12726440.1515052215000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726440.1515052215000.9856.1515421441977@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1479?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-1479:
----------------------------------

    Assignee: Ilia Vassilev


> Coverity, Missing call to superclass in AbstractGssapiMechanism
> ---------------------------------------------------------------
>
>                 Key: ELY-1479
>                 URL: https://issues.jboss.org/browse/ELY-1479
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Mechanisms
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> super.getNegotiatedProperty() is not called in AbstractGssapiMechanism#getNegotiatedProperty, although it is called in similar cases in Gs2SaslServer, DigestSaslServer, AnonymousSaslClient.
> {code:java|title=AbstractGssapiMechanism.java}
>     @Override
>     public Object getNegotiatedProperty(String propName) {
>         assertComplete();
>         switch (propName) {
>             case Sasl.QOP:
>                 return selectedQop.getName();
>             case Sasl.MAX_BUFFER:
>                 return Integer.toString(actualMaxReceiveBuffer != 0 ? actualMaxReceiveBuffer : configuredMaxReceiveBuffer);
>             case Sasl.RAW_SEND_SIZE:
>                 return Integer.toString(maxBuffer);
>         }
>         return null;
>     }
> {code}
> This coverity report is not caused by recent change in AbstractGssapiMechanism but rather Gs2SaslServer and DigestSaslServer
> [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847684&defectInstanceId=9457508&mergedDefectId=1463150



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 09:27:05 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 8 Jan 2018 09:27:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2181) Icons (Edit, Collapse,
 Delete etc) do not respond to mouse clicks
In-Reply-To: <JIRA.12725260.1513341217000@Atlassian.JIRA>
References: <JIRA.12725260.1513341217000@Atlassian.JIRA>
	<JIRA.12725260.1513341217000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725260.1513341217000.9950.1515421625231@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2181?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511251#comment-13511251 ] 

Edson Tirelli commented on DROOLS-2181:
---------------------------------------

[~manstis] to clarify, we have feature freeze on 7.5.x branch, but critical bug fixes will continue to go in there. 

This sounds like a critical bug if trees are not working. Can you please clone this ticket into RHDM? I will ack it.

> Icons (Edit, Collapse, Delete etc) do not respond to mouse clicks
> -----------------------------------------------------------------
>
>                 Key: DROOLS-2181
>                 URL: https://issues.jboss.org/browse/DROOLS-2181
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Tree Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>             Fix For: 7.6.0.Final
>
>
> - Double-click on a node (object/action) to edit/delete/collapse.
> - Pop-up shows the icons/buttons.
> - Click on Edit/Delete/collapse icon. Icons are frozen.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 09:29:01 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Mon, 8 Jan 2018 09:29:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2220) Icons (Edit, Collapse,
 Delete etc) do not respond to mouse clicks
In-Reply-To: <JIRA.12726935.1515421730000@Atlassian.JIRA>
References: <JIRA.12726935.1515421730000@Atlassian.JIRA>
	<JIRA.12726935.1515421730434@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726935.1515421730000.9975.1515421741292@Atlassian.JIRA>

Michael Anstis created DROOLS-2220:
--------------------------------------

             Summary: Icons (Edit, Collapse, Delete etc) do not respond to mouse clicks
                 Key: DROOLS-2220
                 URL: https://issues.jboss.org/browse/DROOLS-2220
             Project: Drools
          Issue Type: Bug
          Components: Guided Decision Tree Editor
    Affects Versions: 7.5.0.Final
            Reporter: Michael Anstis
            Assignee: Michael Anstis
             Fix For: 7.6.0.Final


- Double-click on a node (object/action) to edit/delete/collapse.

- Pop-up shows the icons/buttons.

- Click on Edit/Delete/collapse icon. Icons are frozen.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 09:35:00 2018
From: issues at jboss.org (Farah Juma (JIRA))
Date: Mon, 8 Jan 2018 09:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.10091.1515422100332@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511261#comment-13511261 ] 

Farah Juma commented on ELY-1483:
---------------------------------

+1, the org.wildfly.security.asn1, org.wildfly.security.x500, and org.wildfly.security.x500.cert packages were all internal API in 1.1.x Final so these packages should only be included once we compare 1.2.x with 1.next. Sorry for the confusion [~mchoma]. This means that all of the incompatibilities mentioned in the description here are false positives.

> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  These incompatibilities were detected:
> - removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 10:28:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 8 Jan 2018 10:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2221) [Guided Decision Tree]
 Deletion of parent node throws an exception
In-Reply-To: <JIRA.12726959.1515425232000@Atlassian.JIRA>
References: <JIRA.12726959.1515425232000@Atlassian.JIRA>
	<JIRA.12726959.1515425232626@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726959.1515425232000.10893.1515425280215@Atlassian.JIRA>

Jozef Marko created DROOLS-2221:
-----------------------------------

             Summary: [Guided Decision Tree] Deletion of parent node throws an exception
                 Key: DROOLS-2221
                 URL: https://issues.jboss.org/browse/DROOLS-2221
             Project: Drools
          Issue Type: Bug
          Components: Guided Decision Tree Editor
    Affects Versions: 7.5.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis
         Attachments: Screenshot from 2018-01-08 16-26-11.png, Screenshot from 2018-01-08 16-27-02.png





--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 10:29:01 2018
From: issues at jboss.org (Jiri Locker (JIRA))
Date: Mon, 8 Jan 2018 10:29:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1323) DefaultAgenda.immediateHalt
 takes up 20% of performance in stateful cases: investigate why
In-Reply-To: <JIRA.12654021.1476115812000@Atlassian.JIRA>
References: <JIRA.12654021.1476115812000@Atlassian.JIRA>
	<JIRA.12654021.1476115812000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12654021.1476115812000.10924.1515425341910@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1323?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jiri Locker updated DROOLS-1323:
--------------------------------
    Summary: DefaultAgenda.immediateHalt takes up 20% of performance in stateful cases: investigate why  (was: DefaultAgenda.immediateHalt takes up 20% of performance in statefull cases: investigate why)


> DefaultAgenda.immediateHalt takes up 20% of performance in stateful cases: investigate why
> ------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1323
>                 URL: https://issues.jboss.org/browse/DROOLS-1323
>             Project: Drools
>          Issue Type: Task
>          Components: core engine
>            Reporter: Geoffrey De Smet
>            Assignee: Mario Fusco
>            Priority: Minor
>         Attachments: Selection_240.png, Selection_241.png, Selection_245.png, Selection_246.png, Selection_247.png, Selection_249.png
>
>
> Mario and Geoffrey will investigate, but here's the profiler reports to prove it.
> to reproduce: OptaPlannerExamplesApp -> cloud balancing use case -> load dataset with 1600computer + turn off refresh checkbox -> start cpu profiling -> button solve



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 10:48:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 8 Jan 2018 10:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3495) Update jboss-logmanager to
	2.1.0.Alpha6
In-Reply-To: <JIRA.12726894.1515408471000@Atlassian.JIRA>
References: <JIRA.12726894.1515408471000@Atlassian.JIRA>
	<JIRA.12726894.1515408471000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726894.1515408471000.11174.1515426480280@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed WFCORE-3495.
---------------------------------
    Resolution: Duplicate Issue


> Update jboss-logmanager to 2.1.0.Alpha6
> ---------------------------------------
>
>                 Key: WFCORE-3495
>                 URL: https://issues.jboss.org/browse/WFCORE-3495
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Logging
>            Reporter: Ivo Studensky
>            Assignee: James Perkins
>
> Version of log manager needs to be updated to include some bug fixes



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 11:34:00 2018
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 8 Jan 2018 11:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9391) Validation errors with
	"jboss-web_11_0.xsd
In-Reply-To: <JIRA.12713594.1506458582000@Atlassian.JIRA>
References: <JIRA.12713594.1506458582000@Atlassian.JIRA>
	<JIRA.12713594.1506458582000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12713594.1506458582000.11609.1515429240277@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511379#comment-13511379 ] 

ehsavoie Hugonnet commented on WFLY-9391:
-----------------------------------------

jboss-web_10_0.xsd has already been released and as such can't be modified: please use jboss-web_10_1.xsd instead

> Validation errors with "jboss-web_11_0.xsd
> ------------------------------------------
>
>                 Key: WFLY-9391
>                 URL: https://issues.jboss.org/browse/WFLY-9391
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.CR1
>            Reporter: Wolfgang Knauf
>            Assignee: Jason Greene
>
> Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
> First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee" 
> <xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
> The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
> It would probably also make sense to include the full schemaLocation URL ;-).
> After fixing the namespace, there are four more errors left:
> *src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a( n ) group component
> src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a( n ) 'simpleType definition' component
> src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
> src-resolve: Cannot resolve the name 'jboss:security-roleType' to a( n ) 'type definition' component*
> The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 11:37:01 2018
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 8 Jan 2018 11:37:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9391) Validation errors with
	"jboss-web_11_0.xsd
In-Reply-To: <JIRA.12713594.1506458582000@Atlassian.JIRA>
References: <JIRA.12713594.1506458582000@Atlassian.JIRA>
	<JIRA.12713594.1506458582000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12713594.1506458582000.11684.1515429421435@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet reassigned WFLY-9391:
---------------------------------------

    Assignee: ehsavoie Hugonnet  (was: Jason Greene)


> Validation errors with "jboss-web_11_0.xsd
> ------------------------------------------
>
>                 Key: WFLY-9391
>                 URL: https://issues.jboss.org/browse/WFLY-9391
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.CR1
>            Reporter: Wolfgang Knauf
>            Assignee: ehsavoie Hugonnet
>
> Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
> First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee" 
> <xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
> The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
> It would probably also make sense to include the full schemaLocation URL ;-).
> After fixing the namespace, there are four more errors left:
> *src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a( n ) group component
> src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a( n ) 'simpleType definition' component
> src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
> src-resolve: Cannot resolve the name 'jboss:security-roleType' to a( n ) 'type definition' component*
> The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 11:43:00 2018
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 8 Jan 2018 11:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5410) jboss-web_10_0.xsd is
	inccorect
In-Reply-To: <JIRA.12586139.1443185101000@Atlassian.JIRA>
References: <JIRA.12586139.1443185101000@Atlassian.JIRA>
	<JIRA.12586139.1443185101000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586139.1443185101000.11771.1515429780183@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511392#comment-13511392 ] 

ehsavoie Hugonnet commented on WFLY-5410:
-----------------------------------------

Was fixed in jboss-web_10_1.xsd

> jboss-web_10_0.xsd is inccorect
> -------------------------------
>
>                 Key: WFLY-5410
>                 URL: https://issues.jboss.org/browse/WFLY-5410
>             Project: WildFly
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.0.0.CR2
>            Reporter: ehsavoie Hugonnet
>            Assignee: Eduardo Martins
>
> jboss-web_10_0.xsd requires an extension of javaee 7 xsd in the jboss namespace for <xsd:group ref="jboss:jndiEnvironmentRefsGroup"/>.
> This was in jboss_commons_6_0.xsd for Javaee 6 so we need to have a similar schema for Javaee 7and import it in jboss-web_10_0.xsd.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 11:44:00 2018
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 8 Jan 2018 11:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5410) jboss-web_10_0.xsd is
	inccorect
In-Reply-To: <JIRA.12586139.1443185101000@Atlassian.JIRA>
References: <JIRA.12586139.1443185101000@Atlassian.JIRA>
	<JIRA.12586139.1443185101000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586139.1443185101000.11785.1515429840895@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511392#comment-13511392 ] 

ehsavoie Hugonnet edited comment on WFLY-5410 at 1/8/18 11:43 AM:
------------------------------------------------------------------

Was fixed in jboss-web_10_1.xsd as released schemas are not to be updated.


was (Author: ehugonnet):
Was fixed in jboss-web_10_1.xsd

> jboss-web_10_0.xsd is inccorect
> -------------------------------
>
>                 Key: WFLY-5410
>                 URL: https://issues.jboss.org/browse/WFLY-5410
>             Project: WildFly
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.0.0.CR2
>            Reporter: ehsavoie Hugonnet
>            Assignee: Eduardo Martins
>
> jboss-web_10_0.xsd requires an extension of javaee 7 xsd in the jboss namespace for <xsd:group ref="jboss:jndiEnvironmentRefsGroup"/>.
> This was in jboss_commons_6_0.xsd for Javaee 6 so we need to have a similar schema for Javaee 7and import it in jboss-web_10_0.xsd.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 11:44:00 2018
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 8 Jan 2018 11:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5410) jboss-web_10_0.xsd is
	inccorect
In-Reply-To: <JIRA.12586139.1443185101000@Atlassian.JIRA>
References: <JIRA.12586139.1443185101000@Atlassian.JIRA>
	<JIRA.12586139.1443185101000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586139.1443185101000.11788.1515429840974@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet reassigned WFLY-5410:
---------------------------------------

    Assignee: ehsavoie Hugonnet  (was: Eduardo Martins)


> jboss-web_10_0.xsd is inccorect
> -------------------------------
>
>                 Key: WFLY-5410
>                 URL: https://issues.jboss.org/browse/WFLY-5410
>             Project: WildFly
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.0.0.CR2
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> jboss-web_10_0.xsd requires an extension of javaee 7 xsd in the jboss namespace for <xsd:group ref="jboss:jndiEnvironmentRefsGroup"/>.
> This was in jboss_commons_6_0.xsd for Javaee 6 so we need to have a similar schema for Javaee 7and import it in jboss-web_10_0.xsd.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 11:44:01 2018
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Mon, 8 Jan 2018 11:44:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5410) jboss-web_10_0.xsd is
	inccorect
In-Reply-To: <JIRA.12586139.1443185101000@Atlassian.JIRA>
References: <JIRA.12586139.1443185101000@Atlassian.JIRA>
	<JIRA.12586139.1443185101000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586139.1443185101000.11796.1515429841224@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet resolved WFLY-5410.
-------------------------------------
    Resolution: Done


> jboss-web_10_0.xsd is inccorect
> -------------------------------
>
>                 Key: WFLY-5410
>                 URL: https://issues.jboss.org/browse/WFLY-5410
>             Project: WildFly
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.0.0.CR2
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> jboss-web_10_0.xsd requires an extension of javaee 7 xsd in the jboss namespace for <xsd:group ref="jboss:jndiEnvironmentRefsGroup"/>.
> This was in jboss_commons_6_0.xsd for Javaee 6 so we need to have a similar schema for Javaee 7and import it in jboss-web_10_0.xsd.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 11:52:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 8 Jan 2018 11:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-457) SASL SAML Authentication
	Mechanism
In-Reply-To: <JIRA.12610630.1458114939000@Atlassian.JIRA>
References: <JIRA.12610630.1458114939000@Atlassian.JIRA>
	<JIRA.12610630.1458114939000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12610630.1458114939000.11871.1515430320969@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-457:
------------------------------

    Assignee:     (was: Jan Kalina)


> SASL SAML Authentication Mechanism
> ----------------------------------
>
>                 Key: ELY-457
>                 URL: https://issues.jboss.org/browse/ELY-457
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: SASL
>            Reporter: Darran Lofthouse
>             Fix For: 2.0.0.Alpha1
>
>
> https://tools.ietf.org/html/rfc6595



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 11:58:00 2018
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 8 Jan 2018 11:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1449) Coverity: Dead local store in
 DigestUtil.java
In-Reply-To: <JIRA.12721529.1511172123000@Atlassian.JIRA>
References: <JIRA.12721529.1511172123000@Atlassian.JIRA>
	<JIRA.12721529.1511172123000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721529.1511172123000.11900.1515430680337@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1449?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-1449:
----------------------------------

    Assignee: Ilia Vassilev


> Coverity: Dead local store in DigestUtil.java
> ---------------------------------------------
>
>                 Key: ELY-1449
>                 URL: https://issues.jboss.org/browse/ELY-1449
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Utils
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>            Priority: Trivial
>
> In org.?wildfly.?security.?mechanism.?digest.?DigestUtil.?parseResponse(byte[], java.?nio.?charset.?Charset, boolean, org.?wildfly.?security.?_private.?ElytronMessages): This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction
> https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=40661976&defectInstanceId=8722291&mergedDefectId=1462036



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan  8 12:03:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 8 Jan 2018 12:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1173) InvalidNameState not used for
 non-existing identities in ServerAuthenticationContext
In-Reply-To: <JIRA.12693019.1495176267000@Atlassian.JIRA>
References: <JIRA.12693019.1495176267000@Atlassian.JIRA>
	<JIRA.12693019.1495176267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693019.1495176267000.11952.1515430980889@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1173?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed ELY-1173.
---------------------------
    Resolution: Rejected


> InvalidNameState not used for non-existing identities in ServerAuthenticationContext
> ------------------------------------------------------------------------------------
>
>                 Key: ELY-1173
>                 URL: https://issues.jboss.org/browse/ELY-1173
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Minor
>
> There was added new state *InvalidNameState* into *ServerAuthenticationContext* as part of ELY-1115, but it is currently used only when principal is rewritten to null - not when identity is not found in security realm.
> After adding this will be probably necessary to implement more State methods in *InvalidNameState* to have wildfly tests green.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 12:04:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 8 Jan 2018 12:04:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-907) LdapRealm - different
 principal/credential for referrals
In-Reply-To: <JIRA.12674341.1486030363000@Atlassian.JIRA>
References: <JIRA.12674341.1486030363000@Atlassian.JIRA>
	<JIRA.12674341.1486030363000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674341.1486030363000.11991.1515431041348@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-907:
---------------------------
    Issue Type: Feature Request  (was: Enhancement)


> LdapRealm - different principal/credential for referrals
> --------------------------------------------------------
>
>                 Key: ELY-907
>                 URL: https://issues.jboss.org/browse/ELY-907
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Minor
>
> When LdapRealm follows referrals, it uses the original context's environment properties, including principal/credential, to create a connection to the referred server. Sometimes you might want to follow the referral using different authentication information.
> This can be done when using AuthenticationContext.
> Note: how to pass different credentials into referred DirContext:
> http://www.cs.binghamton.edu/~steflik/cs328/jndi/tutorial/ldap/referral/throw.html (part Authenticating to a Referral Context)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 12:04:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 8 Jan 2018 12:04:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-907) LdapRealm - different
 principal/credential for referrals
In-Reply-To: <JIRA.12674341.1486030363000@Atlassian.JIRA>
References: <JIRA.12674341.1486030363000@Atlassian.JIRA>
	<JIRA.12674341.1486030363000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674341.1486030363000.11994.1515431041421@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-907:
---------------------------
    Priority: Optional  (was: Minor)


> LdapRealm - different principal/credential for referrals
> --------------------------------------------------------
>
>                 Key: ELY-907
>                 URL: https://issues.jboss.org/browse/ELY-907
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Optional
>
> When LdapRealm follows referrals, it uses the original context's environment properties, including principal/credential, to create a connection to the referred server. Sometimes you might want to follow the referral using different authentication information.
> This can be done when using AuthenticationContext.
> Note: how to pass different credentials into referred DirContext:
> http://www.cs.binghamton.edu/~steflik/cs328/jndi/tutorial/ldap/referral/throw.html (part Authenticating to a Referral Context)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 12:05:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 8 Jan 2018 12:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-907) LdapRealm - different
 principal/credential for referrals
In-Reply-To: <JIRA.12674341.1486030363000@Atlassian.JIRA>
References: <JIRA.12674341.1486030363000@Atlassian.JIRA>
	<JIRA.12674341.1486030363000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12674341.1486030363000.11995.1515431100057@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-907?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-907:
---------------------------
    Component/s: Realms


> LdapRealm - different principal/credential for referrals
> --------------------------------------------------------
>
>                 Key: ELY-907
>                 URL: https://issues.jboss.org/browse/ELY-907
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Realms
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Optional
>
> When LdapRealm follows referrals, it uses the original context's environment properties, including principal/credential, to create a connection to the referred server. Sometimes you might want to follow the referral using different authentication information.
> This can be done when using AuthenticationContext.
> Note: how to pass different credentials into referred DirContext:
> http://www.cs.binghamton.edu/~steflik/cs328/jndi/tutorial/ldap/referral/throw.html (part Authenticating to a Referral Context)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 12:25:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 8 Jan 2018 12:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1369) FIPS mode,
 Elytron HTTP DIGEST authentication mechanism not fips compliant
In-Reply-To: <JIRA.12712431.1505900284000@Atlassian.JIRA>
References: <JIRA.12712431.1505900284000@Atlassian.JIRA>
	<JIRA.12712431.1505900284000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712431.1505900284000.12128.1515432300219@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511424#comment-13511424 ] 

Jan Kalina commented on ELY-1369:
---------------------------------

[~mchoma] yes (btw, more auth-methods in web.xml delimited by comma:)
{code}<auth-method>DIGEST-SHA-256,DIGEST-SHA-512-256,BASIC</auth-method>{code}

> FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant
> --------------------------------------------------------------------------
>
>                 Key: ELY-1369
>                 URL: https://issues.jboss.org/browse/ELY-1369
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.2.0.Beta3
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta11
>
>
> Elytron HTTP DIGEST authentication comply to rfc2617 - which means MD5 is used by default (it means it is hardcode, with no way to configure another hash algorithm). But MD5 could make troubles in fips environment [5].
> {code:java|title=DigestAuthenticationMechanism.java}
>         String algorithm = convertToken(ALGORITHM, responseTokens.get(ALGORITHM));
>         if (MD5.equals(algorithm) == false) {
>             throw log.mechUnsupportedAlgorithm(getMechanismName(), algorithm);
>         }
> {code}
> There exists proposed rfc7616 which makes algorithm configurable, work on new DIGEST features are covered by [1]. [~dlofthouse] is it planned for [1] to target 7.1? 
> [1] https://issues.jboss.org/browse/ELY-286
> [2] https://developer.jboss.org/wiki/ElytronHTTPDigestNonceHandling-Design
> [3] https://tools.ietf.org/html/rfc2617
> [4] https://tools.ietf.org/html/rfc7616
> [5] https://access.redhat.com/support/cases/#/case/01761455



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 12:25:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 8 Jan 2018 12:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1369) FIPS mode,
 Elytron HTTP DIGEST authentication mechanism not fips compliant
In-Reply-To: <JIRA.12712431.1505900284000@Atlassian.JIRA>
References: <JIRA.12712431.1505900284000@Atlassian.JIRA>
	<JIRA.12712431.1505900284000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712431.1505900284000.12134.1515432300342@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511424#comment-13511424 ] 

Jan Kalina edited comment on ELY-1369 at 1/8/18 12:24 PM:
----------------------------------------------------------

[~mchoma] yes ( btw, more auth-methods in web.xml delimited by comma: )
{code}<auth-method>DIGEST-SHA-256,DIGEST-SHA-512-256,BASIC</auth-method>{code}


was (Author: honza889):
[~mchoma] yes (btw, more auth-methods in web.xml delimited by comma:)
{code}<auth-method>DIGEST-SHA-256,DIGEST-SHA-512-256,BASIC</auth-method>{code}

> FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant
> --------------------------------------------------------------------------
>
>                 Key: ELY-1369
>                 URL: https://issues.jboss.org/browse/ELY-1369
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.2.0.Beta3
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta11
>
>
> Elytron HTTP DIGEST authentication comply to rfc2617 - which means MD5 is used by default (it means it is hardcode, with no way to configure another hash algorithm). But MD5 could make troubles in fips environment [5].
> {code:java|title=DigestAuthenticationMechanism.java}
>         String algorithm = convertToken(ALGORITHM, responseTokens.get(ALGORITHM));
>         if (MD5.equals(algorithm) == false) {
>             throw log.mechUnsupportedAlgorithm(getMechanismName(), algorithm);
>         }
> {code}
> There exists proposed rfc7616 which makes algorithm configurable, work on new DIGEST features are covered by [1]. [~dlofthouse] is it planned for [1] to target 7.1? 
> [1] https://issues.jboss.org/browse/ELY-286
> [2] https://developer.jboss.org/wiki/ElytronHTTPDigestNonceHandling-Design
> [3] https://tools.ietf.org/html/rfc2617
> [4] https://tools.ietf.org/html/rfc7616
> [5] https://access.redhat.com/support/cases/#/case/01761455



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 12:28:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 8 Jan 2018 12:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7040) Add a set of tests for HTTP
 authentication when backed by Elytron
In-Reply-To: <JIRA.12648687.1473075293000@Atlassian.JIRA>
References: <JIRA.12648687.1473075293000@Atlassian.JIRA>
	<JIRA.12648687.1473075293000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648687.1473075293000.12144.1515432480257@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7040?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511425#comment-13511425 ] 

Jan Kalina commented on WFLY-7040:
----------------------------------

Probably similar to unittests in elytron implemented as part of ELY-1369 (HttpAuthenticatorTest)

> Add a set of tests for HTTP authentication when backed by Elytron
> -----------------------------------------------------------------
>
>                 Key: WFLY-7040
>                 URL: https://issues.jboss.org/browse/WFLY-7040
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite, Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: elytron_testing
>             Fix For: 12.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 13:01:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 8 Jan 2018 13:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5410) jboss-web_10_0.xsd is
	inccorect
In-Reply-To: <JIRA.12586139.1443185101000@Atlassian.JIRA>
References: <JIRA.12586139.1443185101000@Atlassian.JIRA>
	<JIRA.12586139.1443185101000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586139.1443185101000.12305.1515434460142@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511437#comment-13511437 ] 

Brian Stansberry commented on WFLY-5410:
----------------------------------------

[~ehugonnet] is JBMETA-389 done?

> jboss-web_10_0.xsd is inccorect
> -------------------------------
>
>                 Key: WFLY-5410
>                 URL: https://issues.jboss.org/browse/WFLY-5410
>             Project: WildFly
>          Issue Type: Bug
>          Components: Documentation
>    Affects Versions: 10.0.0.CR2
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> jboss-web_10_0.xsd requires an extension of javaee 7 xsd in the jboss namespace for <xsd:group ref="jboss:jndiEnvironmentRefsGroup"/>.
> This was in jboss_commons_6_0.xsd for Javaee 6 so we need to have a similar schema for Javaee 7and import it in jboss-web_10_0.xsd.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 14:22:00 2018
From: issues at jboss.org (=?UTF-8?Q?Roger_Mart=C3=ADnez_=28JIRA=29?=)
Date: Mon, 8 Jan 2018 14:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1937) [DMN Editor] Dynamic Form
 Properties with nested hierarchy binds to wrong object/widget
In-Reply-To: <JIRA.12699176.1498471606000@Atlassian.JIRA>
References: <JIRA.12699176.1498471606000@Atlassian.JIRA>
	<JIRA.12699176.1498471606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12699176.1498471606000.12423.1515439320163@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511455#comment-13511455 ] 

Roger Mart?nez commented on DROOLS-1937:
----------------------------------------

Hey [~manstis]

Just asked for a configuration change in the Stunner's JIRA agile board in order to show this ticket and be able to give it priority and so assign to someone. Sorry about the inconveniences, will start with it ASAP! Thanks!

> [DMN Editor] Dynamic Form Properties with nested hierarchy binds to wrong object/widget
> ---------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1937
>                 URL: https://issues.jboss.org/browse/DROOLS-1937
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Roger Mart?nez
>            Priority: Critical
>              Labels: Stunner
>
> The Dynamic Form generated from a nested object hierarchy binds objects/widgets to the incorrect instances. For example; the below classes define an {{Id}} form field that is used in both {{InputData}} (through inheritance) and {{InformationItem}} (through sub-form reference and inheritance). When changing the {{Id}} field (for example) in the {{InputData}} form property the "Id" value of the nested "Information Item" is updated.
> {code}
> public abstract class DMNModelInstrumentedBase implements DMNDefinition {
>  
>     //No @FormFields etc
>  
> }
>  
> public abstract class DMNElement extends DMNModelInstrumentedBase {
>  
>     @Property
>     @FormField
>     protected Id id;
>  
>     @Property
>     @FormField(afterElement = "id")
>     protected Label label;
>  
>     @Property
>     @FormField(afterElement = "label")
>     protected Description description;
>  
>     ....
> }
>  
> public abstract class NamedElement extends DMNElement {
>  
>     @Property
>     @FormField(afterElement = "description")
>     protected Name name;
>  
>     ....
> }
>  
> @FormDefinition(policy = FieldPolicy.ONLY_MARKED)
> public class InformationItem extends NamedElement implements DMNPropertySet {
>  
>     @Property
>     @FormField(afterElement = "name")
>     protected QName typeRef;
>  
>     ....
> }
> public abstract class DRGElement extends NamedElement {}
> @FormDefinition(policy = FieldPolicy.ONLY_MARKED)
> public class InputData extends DRGElement {
>     ...
>     @PropertySet
>     @FormField(afterElement = "name")
>     protected InformationItem variable;
>     ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan  8 14:23:00 2018
From: issues at jboss.org (=?UTF-8?Q?Roger_Mart=C3=ADnez_=28JIRA=29?=)
Date: Mon, 8 Jan 2018 14:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2214) [DMN Editor] Content of the
 decision node is not copied
In-Reply-To: <JIRA.12726674.1515132440000@Atlassian.JIRA>
References: <JIRA.12726674.1515132440000@Atlassian.JIRA>
	<JIRA.12726674.1515132440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726674.1515132440000.12427.1515439380345@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Roger Mart?nez updated DROOLS-2214:
-----------------------------------
    Labels: Stunner  (was: )


> [DMN Editor] Content of the decision node is not copied
> -------------------------------------------------------
>
>                 Key: DROOLS-2214
>                 URL: https://issues.jboss.org/browse/DROOLS-2214
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>              Labels: Stunner
>
> User has possibility to copy a DRG node by a CTRL+C shortcut, however the problem is that content of the node is not copied.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan  8 14:26:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Mon, 8 Jan 2018 14:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9598) Clustering Testsuite 2.0: CLI, no ant,
 no XSLT, 3-node DIST testing support
In-Reply-To: <JIRA.12723725.1512556909000@Atlassian.JIRA>
References: <JIRA.12723725.1512556909000@Atlassian.JIRA>
	<JIRA.12723725.1512556909000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723725.1512556909000.12440.1515439560295@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9598?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-9598:
---------------------------------
    Summary: Clustering Testsuite 2.0: CLI, no ant, no XSLT, 3-node DIST testing support  (was: Clustering Testsuite 2.0: CLI, no ant, no XSLT, 3-node DIST testing)


> Clustering Testsuite 2.0: CLI, no ant, no XSLT, 3-node DIST testing support
> ---------------------------------------------------------------------------
>
>                 Key: WFLY-9598
>                 URL: https://issues.jboss.org/browse/WFLY-9598
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering, Test Suite
>    Affects Versions: 11.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>             Fix For: 12.0.0.Alpha1
>
>
> Goals
> * simplify test development
> * make the testsuite manageable again
> * lower execution time 
> Steps to take
> * move the testsuite away from using XSLT and just rely on the CLI scripts
> * provide utility for configuring servers using CLI



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 14:26:00 2018
From: issues at jboss.org (=?UTF-8?Q?Roger_Mart=C3=ADnez_=28JIRA=29?=)
Date: Mon, 8 Jan 2018 14:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2214) [DMN Editor] Content of the
 decision node is not copied
In-Reply-To: <JIRA.12726674.1515132440000@Atlassian.JIRA>
References: <JIRA.12726674.1515132440000@Atlassian.JIRA>
	<JIRA.12726674.1515132440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726674.1515132440000.12444.1515439560484@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511458#comment-13511458 ] 

Roger Mart?nez commented on DROOLS-2214:
----------------------------------------

Hey [~manstis]

This is a brand new feature released just a few weeks ago, tbh I don't know the details for it yet.. so would be nice if [~tdolphine] can give us that information, pleaseee :) 

Where you think [~tdolphine] should be the best point to provide additional capabilities for the copy/paste here, probably creating an specialization for the CloneManager? Or being able to provide different clone logics from the different PropertySets (a default one for BPMN, but DMN can for example provide its own)... Thanks!

> [DMN Editor] Content of the decision node is not copied
> -------------------------------------------------------
>
>                 Key: DROOLS-2214
>                 URL: https://issues.jboss.org/browse/DROOLS-2214
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>              Labels: Stunner
>
> User has possibility to copy a DRG node by a CTRL+C shortcut, however the problem is that content of the node is not copied.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan  8 14:28:00 2018
From: issues at jboss.org (=?UTF-8?Q?Roger_Mart=C3=ADnez_=28JIRA=29?=)
Date: Mon, 8 Jan 2018 14:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2214) [DMN Editor] Content of the
 decision node is not copied
In-Reply-To: <JIRA.12726674.1515132440000@Atlassian.JIRA>
References: <JIRA.12726674.1515132440000@Atlassian.JIRA>
	<JIRA.12726674.1515132440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726674.1515132440000.12448.1515439680130@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511459#comment-13511459 ] 

Roger Mart?nez commented on DROOLS-2214:
----------------------------------------

As far as I know the copy/paste stuff delegates to some CloneManager/s.. but would prefer [~tdolphine] to provide the right information :) Thx!

> [DMN Editor] Content of the decision node is not copied
> -------------------------------------------------------
>
>                 Key: DROOLS-2214
>                 URL: https://issues.jboss.org/browse/DROOLS-2214
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>              Labels: Stunner
>
> User has possibility to copy a DRG node by a CTRL+C shortcut, however the problem is that content of the node is not copied.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan  8 14:41:00 2018
From: issues at jboss.org (Tiago Dolphine (JIRA))
Date: Mon, 8 Jan 2018 14:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2214) [DMN Editor] Content of the
 decision node is not copied
In-Reply-To: <JIRA.12726674.1515132440000@Atlassian.JIRA>
References: <JIRA.12726674.1515132440000@Atlassian.JIRA>
	<JIRA.12726674.1515132440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726674.1515132440000.12495.1515440460632@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511467#comment-13511467 ] 

Tiago Dolphine commented on DROOLS-2214:
----------------------------------------

The relationship between nodes are being handled on the CloneNodeCommand, this can be extended to add custom logic, or if we decided that this could be handled by the default clone command we can add there. The CloneManager is handling only the properties values cloning.
I don't know a lot about the DMN but I can try to take this issue, what do you think [~roger600] [~manstis] ?
Anyway if the copy/paste is not expected on the DMN now, we can disable it for the DMN until we get this issue resolved.

> [DMN Editor] Content of the decision node is not copied
> -------------------------------------------------------
>
>                 Key: DROOLS-2214
>                 URL: https://issues.jboss.org/browse/DROOLS-2214
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>              Labels: Stunner
>
> User has possibility to copy a DRG node by a CTRL+C shortcut, however the problem is that content of the node is not copied.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 14:53:00 2018
From: issues at jboss.org (=?UTF-8?Q?Roger_Mart=C3=ADnez_=28JIRA=29?=)
Date: Mon, 8 Jan 2018 14:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2214) [DMN Editor] Content of the
 decision node is not copied
In-Reply-To: <JIRA.12726674.1515132440000@Atlassian.JIRA>
References: <JIRA.12726674.1515132440000@Atlassian.JIRA>
	<JIRA.12726674.1515132440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726674.1515132440000.12502.1515441180368@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511468#comment-13511468 ] 

Roger Mart?nez commented on DROOLS-2214:
----------------------------------------

Hey [~manstis] [~tdolphine]

Well not sure if DMN is actually being included/delivered in the workbench... probably better letting [~manstis] decide what's next step here :) I would vote for not disabling it, just implementing the missing additional capabilities for cloning more metadata... but up to you guys, not even sure what are the requirements for the DMN editor. 

> [DMN Editor] Content of the decision node is not copied
> -------------------------------------------------------
>
>                 Key: DROOLS-2214
>                 URL: https://issues.jboss.org/browse/DROOLS-2214
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>              Labels: Stunner
>
> User has possibility to copy a DRG node by a CTRL+C shortcut, however the problem is that content of the node is not copied.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan  8 15:22:00 2018
From: issues at jboss.org (Bilge Ozpeynirci (JIRA))
Date: Mon, 8 Jan 2018 15:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9651) JAX-RS 2.1 Support
In-Reply-To: <JIRA.12727003.1515442900000@Atlassian.JIRA>
References: <JIRA.12727003.1515442900000@Atlassian.JIRA>
	<JIRA.12727003.1515442900002@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727003.1515442900000.12632.1515442920134@Atlassian.JIRA>

Bilge Ozpeynirci created WFLY-9651:
--------------------------------------

             Summary: JAX-RS 2.1 Support
                 Key: WFLY-9651
                 URL: https://issues.jboss.org/browse/WFLY-9651
             Project: WildFly
          Issue Type: Sub-task
          Components: REST
            Reporter: Bilge Ozpeynirci
            Assignee: Alessio Soldano






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 15:26:00 2018
From: issues at jboss.org (Bilge Ozpeynirci (JIRA))
Date: Mon, 8 Jan 2018 15:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9651) JAX-RS 2.1 Support
In-Reply-To: <JIRA.12727003.1515442900000@Atlassian.JIRA>
References: <JIRA.12727003.1515442900000@Atlassian.JIRA>
	<JIRA.12727003.1515442900000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727003.1515442900000.12653.1515443160267@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bilge Ozpeynirci updated WFLY-9651:
-----------------------------------
        Parent:     (was: WFLY-6455)
    Issue Type: Feature Request  (was: Sub-task)


> JAX-RS 2.1 Support
> ------------------
>
>                 Key: WFLY-9651
>                 URL: https://issues.jboss.org/browse/WFLY-9651
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: REST
>            Reporter: Bilge Ozpeynirci
>            Assignee: Alessio Soldano
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 15:31:00 2018
From: issues at jboss.org (Bilge Ozpeynirci (JIRA))
Date: Mon, 8 Jan 2018 15:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9652) CDI 2.0 Support
In-Reply-To: <JIRA.12727004.1515443419000@Atlassian.JIRA>
References: <JIRA.12727004.1515443419000@Atlassian.JIRA>
	<JIRA.12727004.1515443419067@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727004.1515443419000.12663.1515443460316@Atlassian.JIRA>

Bilge Ozpeynirci created WFLY-9652:
--------------------------------------

             Summary: CDI 2.0 Support
                 Key: WFLY-9652
                 URL: https://issues.jboss.org/browse/WFLY-9652
             Project: WildFly
          Issue Type: Sub-task
          Components: CDI / Weld
            Reporter: Bilge Ozpeynirci
            Assignee: Matej Novotny
             Fix For: 12.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 15:31:00 2018
From: issues at jboss.org (Bilge Ozpeynirci (JIRA))
Date: Mon, 8 Jan 2018 15:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9652) CDI 2.0 Support
In-Reply-To: <JIRA.12727004.1515443419000@Atlassian.JIRA>
References: <JIRA.12727004.1515443419000@Atlassian.JIRA>
	<JIRA.12727004.1515443419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727004.1515443419000.12666.1515443460471@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9652?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bilge Ozpeynirci updated WFLY-9652:
-----------------------------------
        Parent:     (was: WFLY-6455)
    Issue Type: Feature Request  (was: Sub-task)


> CDI 2.0 Support
> ---------------
>
>                 Key: WFLY-9652
>                 URL: https://issues.jboss.org/browse/WFLY-9652
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld
>            Reporter: Bilge Ozpeynirci
>            Assignee: Matej Novotny
>             Fix For: 12.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 15:35:00 2018
From: issues at jboss.org (Bilge Ozpeynirci (JIRA))
Date: Mon, 8 Jan 2018 15:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9653) JSON-P 1.1 Support
In-Reply-To: <JIRA.12727005.1515443658000@Atlassian.JIRA>
References: <JIRA.12727005.1515443658000@Atlassian.JIRA>
	<JIRA.12727005.1515443658245@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727005.1515443658000.12680.1515443700208@Atlassian.JIRA>

Bilge Ozpeynirci created WFLY-9653:
--------------------------------------

             Summary: JSON-P 1.1 Support
                 Key: WFLY-9653
                 URL: https://issues.jboss.org/browse/WFLY-9653
             Project: WildFly
          Issue Type: Sub-task
          Components: EE
            Reporter: Bilge Ozpeynirci
            Assignee: James Perkins






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 15:35:00 2018
From: issues at jboss.org (Bilge Ozpeynirci (JIRA))
Date: Mon, 8 Jan 2018 15:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9653) JSON-P 1.1 Support
In-Reply-To: <JIRA.12727005.1515443658000@Atlassian.JIRA>
References: <JIRA.12727005.1515443658000@Atlassian.JIRA>
	<JIRA.12727005.1515443658000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727005.1515443658000.12683.1515443700275@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9653?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bilge Ozpeynirci updated WFLY-9653:
-----------------------------------
        Parent:     (was: WFLY-6455)
    Issue Type: Feature Request  (was: Sub-task)


> JSON-P 1.1 Support
> ------------------
>
>                 Key: WFLY-9653
>                 URL: https://issues.jboss.org/browse/WFLY-9653
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>            Reporter: Bilge Ozpeynirci
>            Assignee: James Perkins
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 15:37:00 2018
From: issues at jboss.org (Bilge Ozpeynirci (JIRA))
Date: Mon, 8 Jan 2018 15:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9654) JSON-B 1.0 Support
In-Reply-To: <JIRA.12727006.1515443806000@Atlassian.JIRA>
References: <JIRA.12727006.1515443806000@Atlassian.JIRA>
	<JIRA.12727006.1515443806089@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727006.1515443806000.12689.1515443820148@Atlassian.JIRA>

Bilge Ozpeynirci created WFLY-9654:
--------------------------------------

             Summary: JSON-B 1.0 Support
                 Key: WFLY-9654
                 URL: https://issues.jboss.org/browse/WFLY-9654
             Project: WildFly
          Issue Type: Sub-task
          Components: EE
            Reporter: Bilge Ozpeynirci
            Assignee: James Perkins






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 15:38:00 2018
From: issues at jboss.org (Bilge Ozpeynirci (JIRA))
Date: Mon, 8 Jan 2018 15:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9654) JSON-B 1.0 Support
In-Reply-To: <JIRA.12727006.1515443806000@Atlassian.JIRA>
References: <JIRA.12727006.1515443806000@Atlassian.JIRA>
	<JIRA.12727006.1515443806000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727006.1515443806000.12692.1515443880207@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9654?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bilge Ozpeynirci updated WFLY-9654:
-----------------------------------
        Parent:     (was: WFLY-6455)
    Issue Type: Feature Request  (was: Sub-task)


> JSON-B 1.0 Support
> ------------------
>
>                 Key: WFLY-9654
>                 URL: https://issues.jboss.org/browse/WFLY-9654
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EE
>            Reporter: Bilge Ozpeynirci
>            Assignee: James Perkins
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 15:53:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Mon, 8 Jan 2018 15:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2184) UX design DRD logic table
	actions
In-Reply-To: <JIRA.12725294.1513357201000@Atlassian.JIRA>
References: <JIRA.12725294.1513357201000@Atlassian.JIRA>
	<JIRA.12725294.1513357201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725294.1513357201000.12750.1515444780313@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2184:
--------------------------------
    Sprint: 2018 Week 01-02


> UX design DRD logic table actions
> ---------------------------------
>
>                 Key: DROOLS-2184
>                 URL: https://issues.jboss.org/browse/DROOLS-2184
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>
> Use case description:

 As a business user (Citizen Developer?), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.



> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan  8 16:16:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Mon, 8 Jan 2018 16:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1946) DMN Editor
In-Reply-To: <JIRA.12696991.1497281558000@Atlassian.JIRA>
References: <JIRA.12696991.1497281558000@Atlassian.JIRA>
	<JIRA.12696991.1497281558000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696991.1497281558000.12813.1515446160179@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511482#comment-13511482 ] 

Liz Clayton commented on DROOLS-1946:
-------------------------------------

[~manstis] Link to related design task. 

> DMN Editor
> ----------
>
>                 Key: DROOLS-1946
>                 URL: https://issues.jboss.org/browse/DROOLS-1946
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>              Labels: UX
>             Fix For: 7.6.0.Final
>
>
> Place holder for all DMN Editor related activities



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 16:51:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Mon, 8 Jan 2018 16:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2221) [Guided Decision Tree]
 Deletion of parent node throws an exception
In-Reply-To: <JIRA.12726959.1515425233000@Atlassian.JIRA>
References: <JIRA.12726959.1515425233000@Atlassian.JIRA>
	<JIRA.12726959.1515425233000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726959.1515425233000.12892.1515448260278@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2221:
-----------------------------------
    Sprint: 2018 Week 01-02


> [Guided Decision Tree] Deletion of parent node throws an exception
> ------------------------------------------------------------------
>
>                 Key: DROOLS-2221
>                 URL: https://issues.jboss.org/browse/DROOLS-2221
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Tree Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: Screenshot from 2018-01-08 16-26-11.png, Screenshot from 2018-01-08 16-27-02.png
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 16:51:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Mon, 8 Jan 2018 16:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2221) [Guided Decision Tree]
 Deletion of parent node throws an exception
In-Reply-To: <JIRA.12726959.1515425233000@Atlassian.JIRA>
References: <JIRA.12726959.1515425233000@Atlassian.JIRA>
	<JIRA.12726959.1515425233000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726959.1515425233000.12900.1515448260454@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2221?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511490#comment-13511490 ] 

Michael Anstis commented on DROOLS-2221:
----------------------------------------

The bug only happens when the root node is deleted.

> [Guided Decision Tree] Deletion of parent node throws an exception
> ------------------------------------------------------------------
>
>                 Key: DROOLS-2221
>                 URL: https://issues.jboss.org/browse/DROOLS-2221
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Tree Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: Screenshot from 2018-01-08 16-26-11.png, Screenshot from 2018-01-08 16-27-02.png
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 16:56:00 2018
From: issues at jboss.org (Erik . (JIRA))
Date: Mon, 8 Jan 2018 16:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9391) Validation errors with
	"jboss-web_11_0.xsd
In-Reply-To: <JIRA.12713594.1506458582000@Atlassian.JIRA>
References: <JIRA.12713594.1506458582000@Atlassian.JIRA>
	<JIRA.12713594.1506458582000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12713594.1506458582000.12908.1515448560332@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511491#comment-13511491 ] 

Erik . commented on WFLY-9391:
------------------------------

The artifact wildfly-dist in the latest snapshot for 12.0.0.Alpha1 includes the jboss-web_10_0.xsd and jboss-web_11_0.xsd not the jboss-web_10_1.xsd and both files still contain the error.

> Validation errors with "jboss-web_11_0.xsd
> ------------------------------------------
>
>                 Key: WFLY-9391
>                 URL: https://issues.jboss.org/browse/WFLY-9391
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.CR1
>            Reporter: Wolfgang Knauf
>            Assignee: ehsavoie Hugonnet
>
> Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
> First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee" 
> <xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
> The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
> It would probably also make sense to include the full schemaLocation URL ;-).
> After fixing the namespace, there are four more errors left:
> *src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a( n ) group component
> src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a( n ) 'simpleType definition' component
> src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
> src-resolve: Cannot resolve the name 'jboss:security-roleType' to a( n ) 'type definition' component*
> The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan  8 18:50:00 2018
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Mon, 8 Jan 2018 18:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1354) Potential for deadlock on
	pool's flush
In-Reply-To: <JIRA.12706456.1502125219000@Atlassian.JIRA>
References: <JIRA.12706456.1502125219000@Atlassian.JIRA>
	<JIRA.12706456.1502125219000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12706456.1502125219000.13067.1515455400519@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511513#comment-13511513 ] 

RH Bugzilla Integration commented on JBJCA-1354:
------------------------------------------------

Ji?? B?lek <jbilek at redhat.com> changed the Status of [bug 1480095|https://bugzilla.redhat.com/show_bug.cgi?id=1480095] from ON_QA to NEW

> Potential for deadlock on pool's flush
> --------------------------------------
>
>                 Key: JBJCA-1354
>                 URL: https://issues.jboss.org/browse/JBJCA-1354
>             Project: IronJacamar
>          Issue Type: Bug
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> There is a potential for deadlock on all flushes in pools. The problem is that flush is synchronized and inside the flush the code can be delegated to listeners, that are external to IronJacamar.
> If those listeners use their own synchronization system , they could require synchronization locking in themselves. If there is another thread locking the listener and at some point invoking an operation that results in a pool flush, the system could enter a deadlock state.
> An example of stack trace:
> {noformat}
> Found one Java-level deadlock:
> =============================
> "JMSCCThreadPoolWorker-18":
>   waiting to lock monitor 0x00007f1d2409ff48 (object 0x00000007853ad060, a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool),
>   which is held by "JMSCCThreadPoolWorker-16"
> "JMSCCThreadPoolWorker-16":
>   waiting to lock monitor 0x00007f1d1c15d138 (object 0x0000000785998598, a com.ibm.mq.connector.outbound.ConnectionEventHandler),
>   which is held by "JMSCCThreadPoolWorker-17"
> "JMSCCThreadPoolWorker-17":
>   waiting to lock monitor 0x00007f1d2409ff48 (object 0x00000007853ad060, a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool),
>   which is held by "JMSCCThreadPoolWorker-16"
> Java stack information for the threads listed above:
> ===================================================
> "JMSCCThreadPoolWorker-18":
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.flush(AbstractPool.java:322)
> 	- waiting to lock <0x00000007853ad060> (a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool)
> 	at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:368)
> 	at com.ibm.mq.connector.outbound.ConnectionEventHandler.fireEvent(ConnectionEventHandler.java:141)
> 	- locked <0x0000000788fe1fa0> (a com.ibm.mq.connector.outbound.ConnectionEventHandler)
> 	at com.ibm.mq.connector.outbound.ManagedConnectionImpl.onException(ManagedConnectionImpl.java:848)
> 	at com.ibm.msg.client.jms.internal.JmsProviderExceptionListener.run(JmsProviderExceptionListener.java:427)
> 	at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:214)
> 	at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:105)
> 	at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:229)
> 	at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:303)
> 	at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1241)
> "JMSCCThreadPoolWorker-16":
> 	at com.ibm.mq.connector.outbound.ConnectionEventHandler.removeListener(ConnectionEventHandler.java:93)
> 	- waiting to lock <0x0000000785998598> (a com.ibm.mq.connector.outbound.ConnectionEventHandler)
> 	at com.ibm.mq.connector.outbound.ManagedConnectionImpl.removeConnectionEventListener(ManagedConnectionImpl.java:434)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.doDestroy(SemaphoreArrayListManagedConnectionPool.java:891)
> 	at org.jboss.jca.core.connectionmanager.pool.mcp.SemaphoreArrayListManagedConnectionPool.flush(SemaphoreArrayListManagedConnectionPool.java:621)
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.flush(AbstractPool.java:330)
> 	- locked <0x00000007853ad060> (a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool)
> 	at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:368)
> 	at com.ibm.mq.connector.outbound.ConnectionEventHandler.fireEvent(ConnectionEventHandler.java:141)
> 	- locked <0x0000000788fe20b0> (a com.ibm.mq.connector.outbound.ConnectionEventHandler)
> 	at com.ibm.mq.connector.outbound.ManagedConnectionImpl.onException(ManagedConnectionImpl.java:848)
> 	at com.ibm.msg.client.jms.internal.JmsProviderExceptionListener.run(JmsProviderExceptionListener.java:427)
> 	at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:214)
> 	at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:105)
> 	at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:229)
> 	at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:303)
> 	at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1241)
> "JMSCCThreadPoolWorker-17":
> 	at org.jboss.jca.core.connectionmanager.pool.AbstractPool.flush(AbstractPool.java:322)
> 	- waiting to lock <0x00000007853ad060> (a org.jboss.jca.core.connectionmanager.pool.strategy.OnePool)
> 	at org.jboss.jca.core.connectionmanager.listener.AbstractConnectionListener.connectionErrorOccurred(AbstractConnectionListener.java:368)
> 	at com.ibm.mq.connector.outbound.ConnectionEventHandler.fireEvent(ConnectionEventHandler.java:141)
> 	- locked <0x0000000785998598> (a com.ibm.mq.connector.outbound.ConnectionEventHandler)
> 	at com.ibm.mq.connector.outbound.ManagedConnectionImpl.onException(ManagedConnectionImpl.java:848)
> 	at com.ibm.msg.client.jms.internal.JmsProviderExceptionListener.run(JmsProviderExceptionListener.java:427)
> 	at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.runTask(WorkQueueItem.java:214)
> 	at com.ibm.msg.client.commonservices.workqueue.SimpleWorkQueueItem.runItem(SimpleWorkQueueItem.java:105)
> 	at com.ibm.msg.client.commonservices.workqueue.WorkQueueItem.run(WorkQueueItem.java:229)
> 	at com.ibm.msg.client.commonservices.workqueue.WorkQueueManager.runWorkQueueItem(WorkQueueManager.java:303)
> 	at com.ibm.msg.client.commonservices.j2se.workqueue.WorkQueueManagerImplementation$ThreadPoolWorker.run(WorkQueueManagerImplementation.java:1241)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  9 03:13:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 9 Jan 2018 03:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1369) FIPS mode,
 Elytron HTTP DIGEST authentication mechanism not fips compliant
In-Reply-To: <JIRA.12712431.1505900284000@Atlassian.JIRA>
References: <JIRA.12712431.1505900284000@Atlassian.JIRA>
	<JIRA.12712431.1505900284000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712431.1505900284000.13806.1515485580530@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511590#comment-13511590 ] 

Martin Choma commented on ELY-1369:
-----------------------------------

[~honza889], what happens in this specific case. Challenge for all auth-methods is generated by server. and client (browser) choose which auth-method he wants to continue?

> FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant
> --------------------------------------------------------------------------
>
>                 Key: ELY-1369
>                 URL: https://issues.jboss.org/browse/ELY-1369
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.2.0.Beta3
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta11
>
>
> Elytron HTTP DIGEST authentication comply to rfc2617 - which means MD5 is used by default (it means it is hardcode, with no way to configure another hash algorithm). But MD5 could make troubles in fips environment [5].
> {code:java|title=DigestAuthenticationMechanism.java}
>         String algorithm = convertToken(ALGORITHM, responseTokens.get(ALGORITHM));
>         if (MD5.equals(algorithm) == false) {
>             throw log.mechUnsupportedAlgorithm(getMechanismName(), algorithm);
>         }
> {code}
> There exists proposed rfc7616 which makes algorithm configurable, work on new DIGEST features are covered by [1]. [~dlofthouse] is it planned for [1] to target 7.1? 
> [1] https://issues.jboss.org/browse/ELY-286
> [2] https://developer.jboss.org/wiki/ElytronHTTPDigestNonceHandling-Design
> [3] https://tools.ietf.org/html/rfc2617
> [4] https://tools.ietf.org/html/rfc7616
> [5] https://access.redhat.com/support/cases/#/case/01761455



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 03:21:00 2018
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 9 Jan 2018 03:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-389) Missing jboss_commons_7_0.xsd
In-Reply-To: <JIRA.12586140.1443185185000@Atlassian.JIRA>
References: <JIRA.12586140.1443185185000@Atlassian.JIRA>
	<JIRA.12586140.1443185185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586140.1443185185000.13845.1515486060812@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBMETA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet reassigned JBMETA-389:
----------------------------------------

    Assignee: ehsavoie Hugonnet  (was: Eduardo Martins)


> Missing jboss_commons_7_0.xsd
> -----------------------------
>
>                 Key: JBMETA-389
>                 URL: https://issues.jboss.org/browse/JBMETA-389
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>    Affects Versions: 10.0.0.Beta1
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> jboss-web_10_0.xsd requires an extension of javaee 7 xsd in the jboss namespace for <xsd:group ref="jboss:jndiEnvironmentRefsGroup"/>.
> This was in jboss_commons_6_0.xsd for Javaee 6 so we need to have a similar schema for Javaee 7and import it in jboss-web_10_0.xsd.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 03:22:00 2018
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 9 Jan 2018 03:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-389) Missing jboss_commons_7_0.xsd
In-Reply-To: <JIRA.12586140.1443185185000@Atlassian.JIRA>
References: <JIRA.12586140.1443185185000@Atlassian.JIRA>
	<JIRA.12586140.1443185185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12586140.1443185185000.13881.1515486120194@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBMETA-389?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet resolved JBMETA-389.
--------------------------------------
    Fix Version/s: 10.0.2.Final
       Resolution: Done


> Missing jboss_commons_7_0.xsd
> -----------------------------
>
>                 Key: JBMETA-389
>                 URL: https://issues.jboss.org/browse/JBMETA-389
>             Project: JBoss Metadata
>          Issue Type: Bug
>          Components: web
>    Affects Versions: 10.0.0.Beta1
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>             Fix For: 10.0.2.Final
>
>
> jboss-web_10_0.xsd requires an extension of javaee 7 xsd in the jboss namespace for <xsd:group ref="jboss:jndiEnvironmentRefsGroup"/>.
> This was in jboss_commons_6_0.xsd for Javaee 6 so we need to have a similar schema for Javaee 7and import it in jboss-web_10_0.xsd.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 03:26:00 2018
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 9 Jan 2018 03:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9655) Validation errors with
	"jboss-web_11_0.xsd
In-Reply-To: <JIRA.12727034.1515486311000@Atlassian.JIRA>
References: <JIRA.12727034.1515486311000@Atlassian.JIRA>
	<JIRA.12727034.1515486311746@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727034.1515486311000.13889.1515486360214@Atlassian.JIRA>

ehsavoie Hugonnet created WFLY-9655:
---------------------------------------

             Summary: Validation errors with "jboss-web_11_0.xsd
                 Key: WFLY-9655
                 URL: https://issues.jboss.org/browse/WFLY-9655
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 11.0.0.CR1
            Reporter: ehsavoie Hugonnet
            Assignee: ehsavoie Hugonnet


Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.

First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee" 

<xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>

The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*

It would probably also make sense to include the full schemaLocation URL ;-).

After fixing the namespace, there are four more errors left:
*src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a( n ) group component
src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a( n ) 'simpleType definition' component
src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
src-resolve: Cannot resolve the name 'jboss:security-roleType' to a( n ) 'type definition' component*

The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 03:26:00 2018
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Tue, 9 Jan 2018 03:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBMETA-404) Validation errors with
 "jboss-web_11_0.xsd
In-Reply-To: <JIRA.12727034.1515486312000@Atlassian.JIRA>
References: <JIRA.12727034.1515486312000@Atlassian.JIRA>
	<JIRA.12727034.1515486312000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727034.1515486312000.13891.1515486360284@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBMETA-404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

ehsavoie Hugonnet moved WFLY-9655 to JBMETA-404:
------------------------------------------------

              Project: JBoss Metadata  (was: WildFly)
                  Key: JBMETA-404  (was: WFLY-9655)
             Workflow: classic default workflow  (was: GIT Pull Request workflow )
    Affects Version/s: 10.0.2.Final
                           (was: 11.0.0.CR1)


> Validation errors with "jboss-web_11_0.xsd
> ------------------------------------------
>
>                 Key: JBMETA-404
>                 URL: https://issues.jboss.org/browse/JBMETA-404
>             Project: JBoss Metadata
>          Issue Type: Bug
>    Affects Versions: 10.0.2.Final
>            Reporter: ehsavoie Hugonnet
>            Assignee: ehsavoie Hugonnet
>
> Eclipse reports some errors when validating a "jboss-web.xml" file which defines the 11.0 xsd.
> First problem: "web-app_3_1.xsd" is imported. The target namespace seems to be invalid, it should be "http://xmlns.jcp.org/xml/ns/javaee" instead of "http://java.sun.com/xml/ns/javaee" 
> <xsd:import namespace="http://xmlns.jcp.org/xml/ns/javaee" schemaLocation="http://xmlns.jcp.org/xml/ns/javaee/web-app_3_1.xsd"/>
> The validation error: *"The namespace attribute 'http://java.sun.com/xml/ns/javaee' of an import element information must be identical to the targetNamespace attribute 'http://xmlns.jcp.org/xml/ns/javaee' of the imported document".*
> It would probably also make sense to include the full schemaLocation URL ;-).
> After fixing the namespace, there are four more errors left:
> *src-resolve: Cannot resolve the name 'jboss:jndiEnvironmentRefsGroup' to a( n ) group component
> src-resolve: Cannot resolve the name 'javaee:generic-booleanType' to a( n ) 'simpleType definition' component
> src-ct.2.1: Complex type definition Representation Error for type 'symbolic-link-allowedType' ...
> src-resolve: Cannot resolve the name 'jboss:security-roleType' to a( n ) 'type definition' component*
> The first two errors: previous versions of jboss-web.xsd imported "jboss-common_6_0.xsd" which defined a "jndiEnvironmentRefsGroup". This file also imported "javaee_6.xsd", which defines the "generic-booleanType".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 03:39:00 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Tue, 9 Jan 2018 03:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6191)
 ExpressionSubstitutionInContainerTestCase fails due to
 AccessControlException with security manager enabled
In-Reply-To: <JIRA.12603690.1455274970000@Atlassian.JIRA>
References: <JIRA.12603690.1455274970000@Atlassian.JIRA>
	<JIRA.12603690.1455274970000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603690.1455274970000.13952.1515487140322@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges reassigned WFLY-6191:
----------------------------------

    Assignee: Yeray Borges  (was: ehsavoie Hugonnet)


> ExpressionSubstitutionInContainerTestCase fails due to AccessControlException with security manager enabled
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6191
>                 URL: https://issues.jboss.org/browse/WFLY-6191
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Hynek ?v?bek
>            Assignee: Yeray Borges
>
> *org.jboss.as.test.integration.management.api.expression.ExpressionSubstitutionInContainerTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.management.api.expression.ExpressionSubstitutionInContainerTestCase}}
> {code}
> Failed to start service jboss.deployment.unit."expression-substitution-test.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."expression-substitution-test.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "expression-substitution-test.jar"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/expression-substitution-test.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1525)
> 	at java.lang.Class.getClassLoader(Class.java:683)
> 	at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1529)
> 	at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51)
> 	at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2099)
> 	at org.jboss.msc.service.ServiceControllerImpl.commitInstallation(ServiceControllerImpl.java:265)
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:771)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> 	at org.jboss.as.test.integration.management.api.expression.ExpressionTestManagementService.activate(ExpressionTestManagementService.java:69)
> 	at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:74)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> 	... 5 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  9 03:49:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 9 Jan 2018 03:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.14009.1515487740318@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1483:
------------------------------
    Description: 
I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:

{noformat}
[ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
{noformat}

But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?

False positives:
-- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)-

[1] https://github.com/wildfly-security/wildfly-elytron/pull/1067

  was:
I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  These incompatibilities were detected:

- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)

[1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:
> {noformat}
> [ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
> {noformat}
> But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?
> False positives:
> -- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)-
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 03:50:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 9 Jan 2018 03:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.14017.1515487800482@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1483:
------------------------------
    Description: 
I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:

{noformat}
[ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
{noformat}

But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?

False positives:
-
- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
-

[1] https://github.com/wildfly-security/wildfly-elytron/pull/1067

  was:
I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:

{noformat}
[ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
{noformat}

But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?

False positives:
-- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)-

[1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:
> {noformat}
> [ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
> {noformat}
> But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?
> False positives:
> -
> - removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> -
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 03:50:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 9 Jan 2018 03:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.14021.1515487800624@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1483:
------------------------------
    Description: 
I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:

{noformat}
[ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
{noformat}

But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?

False positives:
-- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)-
- removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
-

[1] https://github.com/wildfly-security/wildfly-elytron/pull/1067

  was:
I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:

{noformat}
[ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
{noformat}

But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?

False positives:
-
- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
-

[1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:
> {noformat}
> [ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
> {noformat}
> But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?
> False positives:
> -- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)-
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> -
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 03:50:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 9 Jan 2018 03:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.14025.1515487800742@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1483:
------------------------------
    Description: 
I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:

{noformat}
[ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
{noformat}

But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?

False positives:
- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util) -
- removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)-
- removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)-
- removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)-
- removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)-
- removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)-
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)-
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator) -
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)-
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)-


[1] https://github.com/wildfly-security/wildfly-elytron/pull/1067

  was:
I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:

{noformat}
[ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
{noformat}

But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?

False positives:
-- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)-
- removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)  
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
-

[1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:
> {noformat}
> [ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
> {noformat}
> But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?
> False positives:
> - removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util) -
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)-
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)-
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)-
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)-
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)-
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)-
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator) -
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)-
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)-
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 03:51:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Tue, 9 Jan 2018 03:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.14032.1515487860209@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1483:
------------------------------
    Description: 
I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:

{noformat}
[ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
{noformat}

But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?

False positives because packages asn/x500 were not public in 1.1.7.final :
- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
- removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)


[1] https://github.com/wildfly-security/wildfly-elytron/pull/1067

  was:
I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:

{noformat}
[ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
{noformat}

But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?

False positives:
- removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util) -
- removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)-
- removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)-
- removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)-
- removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)-
- removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)-
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)-
- constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator) -
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)-
- method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)-


[1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta12
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:
> {noformat}
> [ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
> {noformat}
> But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?
> False positives because packages asn/x500 were not public in 1.1.7.final :
> - removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 05:06:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 9 Jan 2018 05:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2214) [DMN Editor] Content of the
 decision node is not copied
In-Reply-To: <JIRA.12726674.1515132440000@Atlassian.JIRA>
References: <JIRA.12726674.1515132440000@Atlassian.JIRA>
	<JIRA.12726674.1515132440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726674.1515132440000.14892.1515492360658@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511664#comment-13511664 ] 

Michael Anstis commented on DROOLS-2214:
----------------------------------------

[~tdolphine] A "DMN Editor" node is not just the Stunner {{Node}} and properties.

Each {{Node}} holds an object that needs to be deep-cloned too; when the User copy and pastes the {{Node}}.

This object is set with {{Node.getContent().setDefiniton(o)}} but {{o}} is the top-level of a object hierarchy that can be several layers deep.

DMN's use of Stunner should have exactly the same functionality as BPMN2 (or any other use of Stunner's "out of the box" features).

This JIRA represents the issue of cloning a DMN {{Node]}. I don't think we need to disable it; or record the issue elsewhere. When resolved; this JIRA can close.

> [DMN Editor] Content of the decision node is not copied
> -------------------------------------------------------
>
>                 Key: DROOLS-2214
>                 URL: https://issues.jboss.org/browse/DROOLS-2214
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>              Labels: Stunner
>
> User has possibility to copy a DRG node by a CTRL+C shortcut, however the problem is that content of the node is not copied.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 05:07:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 9 Jan 2018 05:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2214) [DMN Editor] Content of the
 decision node is not copied
In-Reply-To: <JIRA.12726674.1515132440000@Atlassian.JIRA>
References: <JIRA.12726674.1515132440000@Atlassian.JIRA>
	<JIRA.12726674.1515132440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726674.1515132440000.14903.1515492420638@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis reassigned DROOLS-2214:
--------------------------------------

    Assignee: Tiago Dolphine  (was: Michael Anstis)


> [DMN Editor] Content of the decision node is not copied
> -------------------------------------------------------
>
>                 Key: DROOLS-2214
>                 URL: https://issues.jboss.org/browse/DROOLS-2214
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Tiago Dolphine
>              Labels: Stunner
>
> User has possibility to copy a DRG node by a CTRL+C shortcut, however the problem is that content of the node is not copied.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 05:07:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 9 Jan 2018 05:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2214) [DMN Editor] Content of the
 decision node is not copied
In-Reply-To: <JIRA.12726674.1515132440000@Atlassian.JIRA>
References: <JIRA.12726674.1515132440000@Atlassian.JIRA>
	<JIRA.12726674.1515132440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726674.1515132440000.14914.1515492420932@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis reassigned DROOLS-2214:
--------------------------------------

    Assignee: Michael Anstis  (was: Tiago Dolphine)


> [DMN Editor] Content of the decision node is not copied
> -------------------------------------------------------
>
>                 Key: DROOLS-2214
>                 URL: https://issues.jboss.org/browse/DROOLS-2214
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>              Labels: Stunner
>
> User has possibility to copy a DRG node by a CTRL+C shortcut, however the problem is that content of the node is not copied.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 05:09:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 9 Jan 2018 05:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2222) Stunner: Ensure
 "copy/paste" (nodes) supports DMN's deep definition
In-Reply-To: <JIRA.12727058.1515492503000@Atlassian.JIRA>
References: <JIRA.12727058.1515492503000@Atlassian.JIRA>
	<JIRA.12727058.1515492503108@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727058.1515492503000.14923.1515492540244@Atlassian.JIRA>

Michael Anstis created DROOLS-2222:
--------------------------------------

             Summary: Stunner: Ensure "copy/paste" (nodes) supports DMN's deep definition
                 Key: DROOLS-2222
                 URL: https://issues.jboss.org/browse/DROOLS-2222
             Project: Drools
          Issue Type: Sub-task
            Reporter: Michael Anstis
            Assignee: Tiago Dolphine


As discussed on DROOLS-2214 Stunner needs to support (or provide extension points) for DMN's "copy/paste" of a {{Node}} to also deep-clone the definition. Please either (a) use this JIRA to record any changes needed in Stunner, (b) provide an explanation of how DMN can override the copy/paste to deep-clone definitions. Thanks.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 05:09:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 9 Jan 2018 05:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2222) Stunner: Ensure
 "copy/paste" (nodes) supports DMN's deep definition
In-Reply-To: <JIRA.12727058.1515492503000@Atlassian.JIRA>
References: <JIRA.12727058.1515492503000@Atlassian.JIRA>
	<JIRA.12727058.1515492503000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727058.1515492503000.14928.1515492540389@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2222?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2222:
-----------------------------------
    Component/s: Stunner
                 DMN Editor


> Stunner: Ensure "copy/paste" (nodes) supports DMN's deep definition
> -------------------------------------------------------------------
>
>                 Key: DROOLS-2222
>                 URL: https://issues.jboss.org/browse/DROOLS-2222
>             Project: Drools
>          Issue Type: Sub-task
>          Components: DMN Editor, Stunner
>            Reporter: Michael Anstis
>            Assignee: Tiago Dolphine
>
> As discussed on DROOLS-2214 Stunner needs to support (or provide extension points) for DMN's "copy/paste" of a {{Node}} to also deep-clone the definition. Please either (a) use this JIRA to record any changes needed in Stunner, (b) provide an explanation of how DMN can override the copy/paste to deep-clone definitions. Thanks.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 05:48:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 9 Jan 2018 05:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1811) [Guided Decision Table]
 Column Wizard usability improvements
In-Reply-To: <JIRA.12708510.1503497847000@Atlassian.JIRA>
References: <JIRA.12708510.1503497847000@Atlassian.JIRA>
	<JIRA.12708510.1503497847000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12708510.1503497847000.15118.1515494880671@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1811?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511700#comment-13511700 ] 

Jozef Marko commented on DROOLS-1811:
-------------------------------------

[~tirelli] This jira is part of BAPL-807 that targets to RHDM-7.0.GA, could we cherry pick commit for DROOLS-1811 into 7.5.x brach?

> [Guided Decision Table] Column Wizard usability improvements
> ------------------------------------------------------------
>
>                 Key: DROOLS-1811
>                 URL: https://issues.jboss.org/browse/DROOLS-1811
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.2.0.Final
>            Reporter: Jozef Marko
>            Assignee: Guilherme Carreiro
>              Labels: UX
>             Fix For: 7.6.0.Final
>
>         Attachments: Screenshot from 2017-11-08 10-34-17.png
>
>   Original Estimate: 3 days
>  Remaining Estimate: 3 days
>
> On the _BRMS 7.0 - Getting Started Experience_ meeting, there were mentioned these points that could improve the column wizard:
> - Placement of input fields
> -- *Field binding* should be on the same page as *Field*
> -- Pages like *Operator* and *Field* could be merged or at least recapitulate what was selected on previous pages of the wizard
> - *[UPDATED SOLVED]* Input fields should be explained somehow. For newbies it is really hard to understand what is the *Calculation Type* or *Value List*. I liked concept of small _i_ in blue circle that shows hint after mouse is over this info sign.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 06:46:00 2018
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Tue, 9 Jan 2018 06:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9529) Using injected JMS in a
 background task/thread leads to NameNotFoundException:
 java:comp/TransactionSynchronizationRegistry
In-Reply-To: <JIRA.12719861.1510066270000@Atlassian.JIRA>
References: <JIRA.12719861.1510066270000@Atlassian.JIRA>
	<JIRA.12719861.1510066270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719861.1510066270000.15636.1515498360756@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511747#comment-13511747 ] 

Eduardo Martins commented on WFLY-9529:
---------------------------------------

[~silvaran] maybe I was not clear enough but packing your app in a war, instead of ear, is the workaround. This (app scope cdi events) is a relative new and grey area in spec, for instance Glassfish 5 provides some JNDI access but JMS there malfunctions, plus the fix in progress is in sensitive code so I want to be sure we going the right direction.

> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9529
>                 URL: https://issues.jboss.org/browse/WFLY-9529
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Naming
>    Affects Versions: 10.1.0.Final, 11.0.0.Final
>         Environment: Running on Windows 10, Java 64-bit 1.8.0_131
>            Reporter: Scott Van Wart
>            Assignee: Eduardo Martins
>              Labels: ActiveMQ, jms, transaction
>         Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete.  That seemed unreliable (sometimes it would still produce NameNotFoundException).  I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way.  Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project.  It can be built with Maven.  It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 07:50:00 2018
From: issues at jboss.org (Scott Van Wart (JIRA))
Date: Tue, 9 Jan 2018 07:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9529) Using injected JMS in a
 background task/thread leads to NameNotFoundException:
 java:comp/TransactionSynchronizationRegistry
In-Reply-To: <JIRA.12719861.1510066270000@Atlassian.JIRA>
References: <JIRA.12719861.1510066270000@Atlassian.JIRA>
	<JIRA.12719861.1510066270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719861.1510066270000.16291.1515502200886@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511806#comment-13511806 ] 

Scott Van Wart commented on WFLY-9529:
--------------------------------------

[~emmartins] You were perfectly clear.  I was looking for a workaround.  Unfortunately packaging our deployment as a single WAR would involve a dramatic restructuring that we simply can't do.  I've since created an EJB that accepts a lambda it provides with an @Injected JMSContext.  We're running with this for awhile to see if the issue appears but it looks like a viable workaround for now.

> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9529
>                 URL: https://issues.jboss.org/browse/WFLY-9529
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Naming
>    Affects Versions: 10.1.0.Final, 11.0.0.Final
>         Environment: Running on Windows 10, Java 64-bit 1.8.0_131
>            Reporter: Scott Van Wart
>            Assignee: Eduardo Martins
>              Labels: ActiveMQ, jms, transaction
>         Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete.  That seemed unreliable (sometimes it would still produce NameNotFoundException).  I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way.  Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project.  It can be built with Maven.  It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:05:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 9 Jan 2018 08:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9096) JMS client fails to connect
 with SSL on IBM JDK 8
In-Reply-To: <JIRA.12702471.1500397702000@Atlassian.JIRA>
References: <JIRA.12702471.1500397702000@Atlassian.JIRA>
	<JIRA.12702471.1500397702000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702471.1500397702000.16386.1515503100959@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511811#comment-13511811 ] 

Jan Kalina commented on WFLY-9096:
----------------------------------

Fix can be merged as soon as Artemis will be upgraded as part of WFLY-9407.

> JMS client fails to connect with SSL on IBM JDK 8
> -------------------------------------------------
>
>                 Key: WFLY-9096
>                 URL: https://issues.jboss.org/browse/WFLY-9096
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Security
>    Affects Versions: 11.0.0.Alpha1
>         Environment: IBM JDK 8:
> {code}
> $ java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxi3280sr4fp2-20170322_01(SR4 FP2))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux x86-32 20170314_340265 (JIT enabled, AOT enabled)
> J9VM - R28_20170314_2309_B340265
> JIT  - tr.r14.java.green_20170314_134138
> GC   - R28_20170314_2309_B340265
> J9CL - 20170314_340265)
> JCL - 20170318_01 based on Oracle jdk8u121-b13
> {code}
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: eap7.1-risks-mitigation
>
> If server is configured to authenticate JMS client with SSL configured using Elytron SSLContext then if client is using IBM JDK 8, authentication fails with:
> {code}
> ERROR: AMQ214016: Failed to create netty connection
> java.nio.channels.ClosedChannelException
> 	at io.netty.handler.ssl.SslHandler.channelInactive(...)(Unknown Source)
> Producer got exception and ended:javax.jms.JMSException: Failed to create session factory
> javax.jms.JMSException: Failed to create session factory
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:757)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:265)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:260)
> 	at ProducerTransSession.run(ProducerTransSession.java:75)
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
> 	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:787)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:755)
> 	... 3 more
> {code}
> If client uses Oracle JDK 8 or SSL authentication is configured on http listener using PicketBox then client connects successfully.
> Issue is under investigation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:10:02 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 9 Jan 2018 08:10:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9096) JMS client fails to connect
 with SSL on IBM JDK 8
In-Reply-To: <JIRA.12702471.1500397702000@Atlassian.JIRA>
References: <JIRA.12702471.1500397702000@Atlassian.JIRA>
	<JIRA.12702471.1500397702000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702471.1500397702000.16407.1515503402011@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9096?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511811#comment-13511811 ] 

Jan Kalina edited comment on WFLY-9096 at 1/9/18 8:09 AM:
----------------------------------------------------------

Fix can be merged as soon as Artemis will be upgraded as part of WFLY-9407. (backports was rejected - artemis will be upgraded soon instead)


was (Author: honza889):
Fix can be merged as soon as Artemis will be upgraded as part of WFLY-9407.

> JMS client fails to connect with SSL on IBM JDK 8
> -------------------------------------------------
>
>                 Key: WFLY-9096
>                 URL: https://issues.jboss.org/browse/WFLY-9096
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Security
>    Affects Versions: 11.0.0.Alpha1
>         Environment: IBM JDK 8:
> {code}
> $ java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxi3280sr4fp2-20170322_01(SR4 FP2))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux x86-32 20170314_340265 (JIT enabled, AOT enabled)
> J9VM - R28_20170314_2309_B340265
> JIT  - tr.r14.java.green_20170314_134138
> GC   - R28_20170314_2309_B340265
> J9CL - 20170314_340265)
> JCL - 20170318_01 based on Oracle jdk8u121-b13
> {code}
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: eap7.1-risks-mitigation
>
> If server is configured to authenticate JMS client with SSL configured using Elytron SSLContext then if client is using IBM JDK 8, authentication fails with:
> {code}
> ERROR: AMQ214016: Failed to create netty connection
> java.nio.channels.ClosedChannelException
> 	at io.netty.handler.ssl.SslHandler.channelInactive(...)(Unknown Source)
> Producer got exception and ended:javax.jms.JMSException: Failed to create session factory
> javax.jms.JMSException: Failed to create session factory
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:757)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:265)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnection(ActiveMQConnectionFactory.java:260)
> 	at ProducerTransSession.run(ProducerTransSession.java:75)
> Caused by: ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
> 	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:787)
> 	at org.apache.activemq.artemis.jms.client.ActiveMQConnectionFactory.createConnectionInternal(ActiveMQConnectionFactory.java:755)
> 	... 3 more
> {code}
> If client uses Oracle JDK 8 or SSL authentication is configured on http listener using PicketBox then client connects successfully.
> Issue is under investigation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:18:00 2018
From: issues at jboss.org (Shabbeer Shaik (JIRA))
Date: Tue, 9 Jan 2018 08:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2223) Conversion from XLSX
 decision table -> Guided Decision Table has not worked correctly.
In-Reply-To: <JIRA.12727109.1515503385000@Atlassian.JIRA>
References: <JIRA.12727109.1515503385000@Atlassian.JIRA>
	<JIRA.12727109.1515503385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727109.1515503385000.16438.1515503880405@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Shabbeer Shaik updated DROOLS-2223:
-----------------------------------
    Description: 
Please check the below link for more details

https://groups.google.com/forum/#!topic/drools-usage/iPIwL-QC77w 



  was:
Please check the below link for more details

https://groups.google.com/forum/#!topic/drools-usage/iPIwL-QC77w 

Getting Error :

{color:red}Error :{color}

[KBase: defaultKieBase]: Unable to Analyse Expression getBP_DATE() > "-12": [Error: Comparison operation requires compatible types. Found class java.util.Date and class java.lang.String]




> Conversion from XLSX decision table -> Guided Decision Table has not worked correctly.
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2223
>                 URL: https://issues.jboss.org/browse/DROOLS-2223
>             Project: Drools
>          Issue Type: Bug
>          Components: decision tables, Guided Decision Table Editor, XLS Decision Table Editor
>    Affects Versions: 7.4.1.Final
>            Reporter: Shabbeer Shaik
>            Assignee: Mario Fusco
>         Attachments: myrepo_Test_Dates.zip
>
>
> Please check the below link for more details
> https://groups.google.com/forum/#!topic/drools-usage/iPIwL-QC77w 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:18:01 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 9 Jan 2018 08:18:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2223) Conversion from XLSX
 decision table -> Guided Decision Table has not worked correctly.
In-Reply-To: <JIRA.12727109.1515503385000@Atlassian.JIRA>
References: <JIRA.12727109.1515503385000@Atlassian.JIRA>
	<JIRA.12727109.1515503385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727109.1515503385000.16442.1515503881132@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2223:
--------------------------------
         Tester: Jozef Marko
    Description: 
Please check the below link for more details

https://groups.google.com/forum/#!topic/drools-usage/iPIwL-QC77w 

Getting Error :

{color:red}Error :{color}

[KBase: defaultKieBase]: Unable to Analyse Expression getBP_DATE() > "-12": [Error: Comparison operation requires compatible types. Found class java.util.Date and class java.lang.String]


  was:
Please check the below link for more details

https://groups.google.com/forum/#!topic/drools-usage/iPIwL-QC77w 





> Conversion from XLSX decision table -> Guided Decision Table has not worked correctly.
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2223
>                 URL: https://issues.jboss.org/browse/DROOLS-2223
>             Project: Drools
>          Issue Type: Bug
>          Components: decision tables, Guided Decision Table Editor, XLS Decision Table Editor
>    Affects Versions: 7.4.1.Final
>            Reporter: Shabbeer Shaik
>            Assignee: Mario Fusco
>         Attachments: myrepo_Test_Dates.zip
>
>
> Please check the below link for more details
> https://groups.google.com/forum/#!topic/drools-usage/iPIwL-QC77w 
> Getting Error :
> {color:red}Error :{color}
> [KBase: defaultKieBase]: Unable to Analyse Expression getBP_DATE() > "-12": [Error: Comparison operation requires compatible types. Found class java.util.Date and class java.lang.String]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:18:01 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 9 Jan 2018 08:18:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2223) Conversion from XLSX
 decision table -> Guided Decision Table has not worked correctly.
In-Reply-To: <JIRA.12727109.1515503385000@Atlassian.JIRA>
References: <JIRA.12727109.1515503385000@Atlassian.JIRA>
	<JIRA.12727109.1515503385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727109.1515503385000.16446.1515503881477@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2223:
--------------------------------
    Component/s:     (was: decision tables)


> Conversion from XLSX decision table -> Guided Decision Table has not worked correctly.
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2223
>                 URL: https://issues.jboss.org/browse/DROOLS-2223
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor, XLS Decision Table Editor
>    Affects Versions: 7.4.1.Final
>            Reporter: Shabbeer Shaik
>            Assignee: Mario Fusco
>         Attachments: myrepo_Test_Dates.zip
>
>
> Please check the below link for more details
> https://groups.google.com/forum/#!topic/drools-usage/iPIwL-QC77w 
> Getting Error :
> {color:red}Error :{color}
> [KBase: defaultKieBase]: Unable to Analyse Expression getBP_DATE() > "-12": [Error: Comparison operation requires compatible types. Found class java.util.Date and class java.lang.String]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:19:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 9 Jan 2018 08:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2223) Conversion from XLSX
 decision table -> Guided Decision Table has not worked correctly.
In-Reply-To: <JIRA.12727109.1515503385000@Atlassian.JIRA>
References: <JIRA.12727109.1515503385000@Atlassian.JIRA>
	<JIRA.12727109.1515503385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727109.1515503385000.16451.1515503940454@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko reassigned DROOLS-2223:
-----------------------------------

    Assignee: Michael Anstis  (was: Mario Fusco)


> Conversion from XLSX decision table -> Guided Decision Table has not worked correctly.
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2223
>                 URL: https://issues.jboss.org/browse/DROOLS-2223
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor, XLS Decision Table Editor
>    Affects Versions: 7.4.1.Final
>            Reporter: Shabbeer Shaik
>            Assignee: Michael Anstis
>         Attachments: myrepo_Test_Dates.zip
>
>
> Please check the below link for more details
> https://groups.google.com/forum/#!topic/drools-usage/iPIwL-QC77w 
> Getting Error :
> {color:red}Error :{color}
> [KBase: defaultKieBase]: Unable to Analyse Expression getBP_DATE() > "-12": [Error: Comparison operation requires compatible types. Found class java.util.Date and class java.lang.String]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:25:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 9 Jan 2018 08:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2001) Can't enter time of day
 portion of Date object belonging to a fact in test Scenarios
In-Reply-To: <JIRA.12443200.1312293096000@Atlassian.JIRA>
References: <JIRA.12443200.1312293096000@Atlassian.JIRA>
	<JIRA.12443200.1312293096000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12443200.1312293096000.16497.1515504300919@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2001?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2001:
--------------------------------
    Tester: Jozef Marko


> Can't enter time of day portion of Date object belonging to a fact in test Scenarios 
> -------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2001
>                 URL: https://issues.jboss.org/browse/DROOLS-2001
>             Project: Drools
>          Issue Type: Bug
>          Components: Test Scenarios Editor
>    Affects Versions: 5.5.0.Final
>         Environment: Running on Windows 7 with BRMS Standalone 5.1.  Issue arises in both firefox and google chrome browsers.
>            Reporter: Jeff Forte
>            Assignee: Guilherme Carreiro
>             Fix For: 7.6.0.Final
>
>
> I have a set of facts that hold a Date asset for comparison between each other.  The comparison is supposed to be between the time of day of the object; however, when trying to enter the date and time of day into the test scenario the time of day portion always gets wiped upon running the scenario. The date stays but there is no long any time of day and I can't seem to find a way to enter the time even with the "enter date" button. I can't test while this is happening. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:10:03 2018
From: issues at jboss.org (Shabbeer Shaik (JIRA))
Date: Tue, 9 Jan 2018 08:10:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2223) Conversion from XLSX
 decision table -> Guided Decision Table has not worked correctly.
In-Reply-To: <JIRA.12727109.1515503385000@Atlassian.JIRA>
References: <JIRA.12727109.1515503385000@Atlassian.JIRA>
	<JIRA.12727109.1515503385167@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727109.1515503385000.16412.1515503403115@Atlassian.JIRA>

Shabbeer Shaik created DROOLS-2223:
--------------------------------------

             Summary: Conversion from XLSX decision table -> Guided Decision Table has not worked correctly.
                 Key: DROOLS-2223
                 URL: https://issues.jboss.org/browse/DROOLS-2223
             Project: Drools
          Issue Type: Bug
          Components: decision tables, Guided Decision Table Editor, XLS Decision Table Editor
    Affects Versions: 7.4.1.Final
            Reporter: Shabbeer Shaik
            Assignee: Mario Fusco
         Attachments: myrepo_Test_Dates.zip

Please check the below link for more details

https://groups.google.com/forum/#!topic/drools-usage/iPIwL-QC77w 

Getting Error :

{color:red}Error :{color}

[KBase: defaultKieBase]: Unable to Analyse Expression getBP_DATE() > "-12": [Error: Comparison operation requires compatible types. Found class java.util.Date and class java.lang.String]




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:29:01 2018
From: issues at jboss.org (Eduardo Martins (JIRA))
Date: Tue, 9 Jan 2018 08:29:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9529) Using injected JMS in a
 background task/thread leads to NameNotFoundException:
 java:comp/TransactionSynchronizationRegistry
In-Reply-To: <JIRA.12719861.1510066270000@Atlassian.JIRA>
References: <JIRA.12719861.1510066270000@Atlassian.JIRA>
	<JIRA.12719861.1510066270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719861.1510066270000.16521.1515504541092@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511822#comment-13511822 ] 

Eduardo Martins commented on WFLY-9529:
---------------------------------------

The issue is really bound to usage of the CDI event, that is delivered without the Java EE JNDI so if you use a Java EE component such as a EJB that will work fine. I was assuming you just wanted a workaround with the CDI event, and right now only real workaround would be replace the ear with a war.

> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9529
>                 URL: https://issues.jboss.org/browse/WFLY-9529
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Naming
>    Affects Versions: 10.1.0.Final, 11.0.0.Final
>         Environment: Running on Windows 10, Java 64-bit 1.8.0_131
>            Reporter: Scott Van Wart
>            Assignee: Eduardo Martins
>              Labels: ActiveMQ, jms, transaction
>         Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete.  That seemed unreliable (sometimes it would still produce NameNotFoundException).  I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way.  Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project.  It can be built with Maven.  It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:38:00 2018
From: issues at jboss.org (Martin Weiler (JIRA))
Date: Tue, 9 Jan 2018 08:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2224) Inconsistent values
 returned by AccessorKey.hashCode causes NullPointerException during binary
 deserialization
In-Reply-To: <JIRA.12727114.1515505046000@Atlassian.JIRA>
References: <JIRA.12727114.1515505046000@Atlassian.JIRA>
	<JIRA.12727114.1515505046347@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727114.1515505046000.16579.1515505080967@Atlassian.JIRA>

Martin Weiler created DROOLS-2224:
-------------------------------------

             Summary: Inconsistent values returned by AccessorKey.hashCode causes NullPointerException during binary deserialization
                 Key: DROOLS-2224
                 URL: https://issues.jboss.org/browse/DROOLS-2224
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Martin Weiler
            Assignee: Mario Fusco


Consider the following sequence of events:
# serialize a set of text rule files
# create a binary file for the serialized rule files
# deserialize the binary file created in the step 2.

When each step is executed in different JVM runs, step 3 fails with a NullPointerException:

{noformat}
java.lang.NullPointerException: null
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.isHashable(CompositeObjectSinkAdapter.java:158)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.getHashableAccessor(CompositeObjectSinkAdapter.java:149)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.addObjectSink(CompositeObjectSinkAdapter.java:108)
	at org.drools.core.reteoo.SingleObjectSinkAdapter.addObjectSink(SingleObjectSinkAdapter.java:55)
	at org.drools.core.reteoo.ObjectSource.addObjectSink(ObjectSource.java:216)
	at org.drools.core.reteoo.LeftInputAdapterNode.attach(LeftInputAdapterNode.java:155)
	at org.drools.core.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:141)
	at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.buildTupleSource(GroupElementBuilder.java:126)
	at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:109)
	at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
	at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
	at org.drools.core.impl.KnowledgeBaseImpl.internalAddRule(KnowledgeBaseImpl.java:1526)
	at org.drools.core.impl.KnowledgeBaseImpl.internalAddPackages(KnowledgeBaseImpl.java:915)
	at org.drools.core.impl.KnowledgeBaseImpl.lambda$addPackages$1(KnowledgeBaseImpl.java:717)
	at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
	at org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:717)
	at org.drools.compiler.integrationtests.SerializedPackageMergeTwoSteps2Test.testBuildAndSerializePackagesInTwoSteps2(SerializedPackageMergeTwoSteps2Test.java:88)
{noformat}

If making one single run for all 3 steps, everything works fine.

The problem are inconsistent hashCode values for the AccessorKey object when the JVM is restarted, due to the usage of Enum.hashCode:
https://github.com/kiegroup/drools/blob/master/drools-core/src/main/java/org/drools/core/base/AccessorKey.java#L48



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:41:01 2018
From: issues at jboss.org (Martin Weiler (JIRA))
Date: Tue, 9 Jan 2018 08:41:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2225) Inconsistent values
 returned by AccessorKey.hashCode causes NullPointerException during binary
 deserialization
In-Reply-To: <JIRA.12727117.1515505247000@Atlassian.JIRA>
References: <JIRA.12727117.1515505247000@Atlassian.JIRA>
	<JIRA.12727117.1515505247905@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727117.1515505247000.16633.1515505261099@Atlassian.JIRA>

Martin Weiler created DROOLS-2225:
-------------------------------------

             Summary: Inconsistent values returned by AccessorKey.hashCode causes NullPointerException during binary deserialization
                 Key: DROOLS-2225
                 URL: https://issues.jboss.org/browse/DROOLS-2225
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Martin Weiler
            Assignee: Mario Fusco


Consider the following sequence of events:
# serialize a set of text rule files
# create a binary file for the serialized rule files
# deserialize the binary file created in the step 2.

When each step is executed in different JVM runs, step 3 fails with a NullPointerException:

{noformat}
java.lang.NullPointerException: null
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.isHashable(CompositeObjectSinkAdapter.java:158)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.getHashableAccessor(CompositeObjectSinkAdapter.java:149)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.addObjectSink(CompositeObjectSinkAdapter.java:108)
	at org.drools.core.reteoo.SingleObjectSinkAdapter.addObjectSink(SingleObjectSinkAdapter.java:55)
	at org.drools.core.reteoo.ObjectSource.addObjectSink(ObjectSource.java:216)
	at org.drools.core.reteoo.LeftInputAdapterNode.attach(LeftInputAdapterNode.java:155)
	at org.drools.core.reteoo.builder.BuildUtils.attachNode(BuildUtils.java:141)
	at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.buildTupleSource(GroupElementBuilder.java:126)
	at org.drools.core.reteoo.builder.GroupElementBuilder$AndBuilder.build(GroupElementBuilder.java:109)
	at org.drools.core.reteoo.builder.GroupElementBuilder.build(GroupElementBuilder.java:68)
	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:161)
	at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
	at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
	at org.drools.core.impl.KnowledgeBaseImpl.internalAddRule(KnowledgeBaseImpl.java:1526)
	at org.drools.core.impl.KnowledgeBaseImpl.internalAddPackages(KnowledgeBaseImpl.java:915)
	at org.drools.core.impl.KnowledgeBaseImpl.lambda$addPackages$1(KnowledgeBaseImpl.java:717)
	at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
	at org.drools.core.impl.KnowledgeBaseImpl.addPackages(KnowledgeBaseImpl.java:717)
	at org.drools.compiler.integrationtests.SerializedPackageMergeTwoSteps2Test.testBuildAndSerializePackagesInTwoSteps2(SerializedPackageMergeTwoSteps2Test.java:88)
{noformat}

If making one single run for all 3 steps, everything works fine.

The problem are inconsistent hashCode values for the AccessorKey object when the JVM is restarted, due to the usage of Enum.hashCode:
https://github.com/kiegroup/drools/blob/master/drools-core/src/main/java/org/drools/core/base/AccessorKey.java#L48



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:42:01 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Tue, 9 Jan 2018 08:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6191)
 ExpressionSubstitutionInContainerTestCase fails due to
 AccessControlException with security manager enabled
In-Reply-To: <JIRA.12603690.1455274970000@Atlassian.JIRA>
References: <JIRA.12603690.1455274970000@Atlassian.JIRA>
	<JIRA.12603690.1455274970000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12603690.1455274970000.16660.1515505321385@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6191?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges updated WFLY-6191:
-------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/8802, https://github.com/wildfly/wildfly/pull/10741  (was: https://github.com/wildfly/wildfly/pull/8802)


> ExpressionSubstitutionInContainerTestCase fails due to AccessControlException with security manager enabled
> -----------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-6191
>                 URL: https://issues.jboss.org/browse/WFLY-6191
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Hynek ?v?bek
>            Assignee: Yeray Borges
>
> *org.jboss.as.test.integration.management.api.expression.ExpressionSubstitutionInContainerTestCase*
> {{./integration-tests.sh -fae -Dmaven.test.failure.ignore=true -DfailIfNoTests=false -Dsecurity.manager -Dts.basic -Dts.noSmoke -Dtest=org.jboss.as.test.integration.management.api.expression.ExpressionSubstitutionInContainerTestCase}}
> {code}
> Failed to start service jboss.deployment.unit."expression-substitution-test.jar".INSTALL: org.jboss.msc.service.StartException in service jboss.deployment.unit."expression-substitution-test.jar".INSTALL: WFLYSRV0153: Failed to process phase INSTALL of deployment "expression-substitution-test.jar"
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:154)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1948)
> 	at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1881)
> 	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.security.AccessControlException: WFSM000001: Permission check failed (permission "("java.lang.RuntimePermission" "getClassLoader")" in code source "(vfs:/content/expression-substitution-test.jar <no signer certificates>)" of "null")
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
> 	at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
> 	at java.lang.ClassLoader.checkClassLoaderPermission(ClassLoader.java:1525)
> 	at java.lang.Class.getClassLoader(Class.java:683)
> 	at org.jboss.msc.service.ServiceControllerImpl.invokeListener(ServiceControllerImpl.java:1529)
> 	at org.jboss.msc.service.ServiceControllerImpl.access$2800(ServiceControllerImpl.java:51)
> 	at org.jboss.msc.service.ServiceControllerImpl$ListenerTask.run(ServiceControllerImpl.java:2099)
> 	at org.jboss.msc.service.ServiceControllerImpl.commitInstallation(ServiceControllerImpl.java:265)
> 	at org.jboss.msc.service.ServiceContainerImpl.install(ServiceContainerImpl.java:771)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> 	at org.jboss.msc.service.ServiceTargetImpl.install(ServiceTargetImpl.java:223)
> 	at org.jboss.msc.service.ServiceControllerImpl$ChildServiceTarget.install(ServiceControllerImpl.java:2401)
> 	at org.jboss.msc.service.ServiceBuilderImpl.install(ServiceBuilderImpl.java:317)
> 	at org.jboss.as.test.integration.management.api.expression.ExpressionTestManagementService.activate(ExpressionTestManagementService.java:69)
> 	at org.jboss.as.server.deployment.service.ServiceActivatorProcessor.deploy(ServiceActivatorProcessor.java:74)
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:147)
> 	... 5 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  9 08:47:00 2018
From: issues at jboss.org (Scott Van Wart (JIRA))
Date: Tue, 9 Jan 2018 08:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9529) Using injected JMS in a
 background task/thread leads to NameNotFoundException:
 java:comp/TransactionSynchronizationRegistry
In-Reply-To: <JIRA.12719861.1510066270000@Atlassian.JIRA>
References: <JIRA.12719861.1510066270000@Atlassian.JIRA>
	<JIRA.12719861.1510066270000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719861.1510066270000.16801.1515505620397@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9529?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511853#comment-13511853 ] 

Scott Van Wart commented on WFLY-9529:
--------------------------------------

That sounds fair.  I didn't realize it was CDI event specific, though your comment on December 13th sort of alluded to it. I can't think of a place where I've encountered this issue _without_ using CDI events.  We use local CDI events and then have a service that watches for them and sends them out over JMS as necessary, which of course uses @Observe methods.  Thanks.

> Using injected JMS in a background task/thread leads to NameNotFoundException: java:comp/TransactionSynchronizationRegistry
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9529
>                 URL: https://issues.jboss.org/browse/WFLY-9529
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Naming
>    Affects Versions: 10.1.0.Final, 11.0.0.Final
>         Environment: Running on Windows 10, Java 64-bit 1.8.0_131
>            Reporter: Scott Van Wart
>            Assignee: Eduardo Martins
>              Labels: ActiveMQ, jms, transaction
>         Attachments: injected-jms.zip, injected-jms2.zip, wildfly-11-injected-jms.txt
>
>
> If I try to use an @Injected JMSContext while executing within a background task (ManagedExecutorService) or thread (ManagedThreadFactory), I get the attached stacktrace. I've experienced this a number of times with Wildfly 10.1.0, including messages sent in Infinispan's expiry task thread.
> My original workaround was to submit an additional task on a separate thread to send the message, then wait for it to complete.  That seemed unreliable (sometimes it would still produce NameNotFoundException).  I've resorted to creating my own JMSContext by using @Resource( lookup="java:/ConnectionFactory" ) and sending messages that way.  Both workarounds prevent the message sending logic from participating in any ongoing transactions.
> I'm also attaching a sample EAR project.  It can be built with Maven.  It creates a background task that waits 3 seconds and then tries to send a JMS message in a new transaction using an injected JMS context. I use the standalone-full.xml profile to run it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:58:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 9 Jan 2018 08:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7041) Add testing for Web -> EJB
 Identity Propagation
In-Reply-To: <JIRA.12648688.1473075377000@Atlassian.JIRA>
References: <JIRA.12648688.1473075377000@Atlassian.JIRA>
	<JIRA.12648688.1473075377000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648688.1473075377000.16906.1515506280633@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina resolved WFLY-7041.
------------------------------
    Resolution: Done


yes, web-EJB identity propagation was already test-covered as part of WFLY-8255 (and unignored in WFLY-7778) - setting as resolved

> Add testing for Web -> EJB Identity Propagation
> -----------------------------------------------
>
>                 Key: WFLY-7041
>                 URL: https://issues.jboss.org/browse/WFLY-7041
>             Project: WildFly
>          Issue Type: Task
>          Components: EJB, Security, Test Suite
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: elytron_testing
>             Fix For: 12.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 08:59:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 9 Jan 2018 08:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7041) Add testing for Web -> EJB
 Identity Propagation
In-Reply-To: <JIRA.12648688.1473075377000@Atlassian.JIRA>
References: <JIRA.12648688.1473075377000@Atlassian.JIRA>
	<JIRA.12648688.1473075377000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12648688.1473075377000.16916.1515506340313@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7041?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFLY-7041:
-----------------------------
    Git Pull Request: https://github.com/wildfly-security-incubator/wildfly/pull/125  (was: https://github.com/wildfly-security-incubator/wildfly/pull/56)


> Add testing for Web -> EJB Identity Propagation
> -----------------------------------------------
>
>                 Key: WFLY-7041
>                 URL: https://issues.jboss.org/browse/WFLY-7041
>             Project: WildFly
>          Issue Type: Task
>          Components: EJB, Security, Test Suite
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: elytron_testing
>             Fix For: 12.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 09:19:00 2018
From: issues at jboss.org (Marek Novotny (JIRA))
Date: Tue, 9 Jan 2018 09:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2165) Upgrade revapi-maven-plugin
 from 0.9.4 to 0.9.5
In-Reply-To: <JIRA.12723714.1512553818000@Atlassian.JIRA>
References: <JIRA.12723714.1512553818000@Atlassian.JIRA>
	<JIRA.12723714.1512553818000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723714.1512553818000.17118.1515507540782@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2165?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13511880#comment-13511880 ] 

Marek Novotny commented on DROOLS-2165:
---------------------------------------

Why to upgrade to 0.9.5? Is there added @threadSafe somewhere in that version/release. I couldn't find it. Am I blind or looking in wrong place - https://github.com/revapi/revapi/commits/revapi-maven-plugin-0.9.5?

> Upgrade revapi-maven-plugin from 0.9.4 to 0.9.5
> -----------------------------------------------
>
>                 Key: DROOLS-2165
>                 URL: https://issues.jboss.org/browse/DROOLS-2165
>             Project: Drools
>          Issue Type: Task
>          Components: build
>            Reporter: Geoffrey De Smet
>            Assignee: Michael Biarnes Kiefer
>
> It's a good thing to just do,
> but hopefully this message goes away on the jenkins job for drools:
> {code}
> 09:33:13 [INFO] ------------------------------------------------------------------------
> 09:33:13 [INFO] Building KIE :: Maven Archetypes 7.6.0-SNAPSHOT
> 09:33:13 [INFO] ------------------------------------------------------------------------
> 09:33:13 [WARNING] *****************************************************************
> 09:33:13 [WARNING] * Your build is requesting parallel execution, but project      *
> 09:33:13 [WARNING] * contains the following plugin(s) that have goals not marked   *
> 09:33:13 [WARNING] * as @threadSafe to support parallel building.                  *
> 09:33:13 [WARNING] * While this /may/ work fine, please look for plugin updates    *
> 09:33:13 [WARNING] * and/or request plugins be made thread-safe.                   *
> 09:33:13 [WARNING] * If reporting an issue, report it against the plugin in        *
> 09:33:13 [WARNING] * question, not against maven-core                              *
> 09:33:13 [WARNING] *****************************************************************
> 09:33:13 [WARNING] The following plugins are not marked @threadSafe in KIE :: Public API:
> 09:33:13 [WARNING] org.revapi:revapi-maven-plugin:0.9.4
> 09:33:13 [WARNING] Enable debug to see more precisely which goals are not marked @threadSafe.
> 09:33:13 [WARNING] *****************************************************************
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 09:58:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Tue, 9 Jan 2018 09:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3496) Upgrade WildFly Elytron to
	1.2.0.Beta10
In-Reply-To: <JIRA.12727151.1515509859000@Atlassian.JIRA>
References: <JIRA.12727151.1515509859000@Atlassian.JIRA>
	<JIRA.12727151.1515509859986@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727151.1515509859000.17598.1515509880497@Atlassian.JIRA>

Ivo Studensky created WFCORE-3496:
-------------------------------------

             Summary: Upgrade WildFly Elytron to 1.2.0.Beta10
                 Key: WFCORE-3496
                 URL: https://issues.jboss.org/browse/WFCORE-3496
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Ivo Studensky
            Assignee: Darran Lofthouse
            Priority: Blocker
             Fix For: 4.0.0.Alpha3






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 09:59:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Tue, 9 Jan 2018 09:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3496) Upgrade WildFly Elytron to
	1.2.0.Beta10
In-Reply-To: <JIRA.12727151.1515509860000@Atlassian.JIRA>
References: <JIRA.12727151.1515509860000@Atlassian.JIRA>
	<JIRA.12727151.1515509860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727151.1515509860000.17610.1515509940787@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFCORE-3496:
----------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly-core/pull/2919)


> Upgrade WildFly Elytron to 1.2.0.Beta10
> ---------------------------------------
>
>                 Key: WFCORE-3496
>                 URL: https://issues.jboss.org/browse/WFCORE-3496
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Ivo Studensky
>            Assignee: Darran Lofthouse
>            Priority: Blocker
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 09:59:01 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Tue, 9 Jan 2018 09:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3496) Upgrade WildFly Elytron to
	1.2.0.Beta10
In-Reply-To: <JIRA.12727151.1515509860000@Atlassian.JIRA>
References: <JIRA.12727151.1515509860000@Atlassian.JIRA>
	<JIRA.12727151.1515509860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727151.1515509860000.17618.1515509941022@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFCORE-3496:
----------------------------------
    Priority: Major  (was: Blocker)


> Upgrade WildFly Elytron to 1.2.0.Beta10
> ---------------------------------------
>
>                 Key: WFCORE-3496
>                 URL: https://issues.jboss.org/browse/WFCORE-3496
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Ivo Studensky
>            Assignee: Darran Lofthouse
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 09:59:01 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Tue, 9 Jan 2018 09:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3496) Upgrade WildFly Elytron to
	1.2.0.Beta10
In-Reply-To: <JIRA.12727151.1515509860000@Atlassian.JIRA>
References: <JIRA.12727151.1515509860000@Atlassian.JIRA>
	<JIRA.12727151.1515509860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727151.1515509860000.17628.1515509941295@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFCORE-3496:
----------------------------------
    Fix Version/s:     (was: 4.0.0.Alpha3)


> Upgrade WildFly Elytron to 1.2.0.Beta10
> ---------------------------------------
>
>                 Key: WFCORE-3496
>                 URL: https://issues.jboss.org/browse/WFCORE-3496
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Ivo Studensky
>            Assignee: Darran Lofthouse
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 10:00:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Tue, 9 Jan 2018 10:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3497) (7.1.z) Upgrade WildFly
 Elytron to 1.1.8.Final
In-Reply-To: <JIRA.12727152.1515509977000@Atlassian.JIRA>
References: <JIRA.12727152.1515509977000@Atlassian.JIRA>
	<JIRA.12727152.1515509977642@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727152.1515509977000.17632.1515510000455@Atlassian.JIRA>

Ivo Studensky created WFCORE-3497:
-------------------------------------

             Summary: (7.1.z) Upgrade WildFly Elytron to 1.1.8.Final
                 Key: WFCORE-3497
                 URL: https://issues.jboss.org/browse/WFCORE-3497
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Ivo Studensky
            Assignee: Darran Lofthouse






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 10:00:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Tue, 9 Jan 2018 10:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3497) (7.1.z) Upgrade WildFly
 Elytron to 1.1.8.Final
In-Reply-To: <JIRA.12727152.1515509978000@Atlassian.JIRA>
References: <JIRA.12727152.1515509978000@Atlassian.JIRA>
	<JIRA.12727152.1515509978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727152.1515509978000.17644.1515510000857@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky reassigned WFCORE-3497:
-------------------------------------

    Assignee: Ivo Studensky  (was: Darran Lofthouse)


> (7.1.z) Upgrade WildFly Elytron to 1.1.8.Final
> ----------------------------------------------
>
>                 Key: WFCORE-3497
>                 URL: https://issues.jboss.org/browse/WFCORE-3497
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 10:33:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Tue, 9 Jan 2018 10:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3498) Eliminate
 ServiceVerificationHandler and all its usages
In-Reply-To: <JIRA.12727164.1515511926000@Atlassian.JIRA>
References: <JIRA.12727164.1515511926000@Atlassian.JIRA>
	<JIRA.12727164.1515511926516@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727164.1515511926000.17944.1515511980562@Atlassian.JIRA>

Richard Opalka created WFCORE-3498:
--------------------------------------

             Summary: Eliminate ServiceVerificationHandler and all its usages
                 Key: WFCORE-3498
                 URL: https://issues.jboss.org/browse/WFCORE-3498
             Project: WildFly Core
          Issue Type: Task
          Components: Server
    Affects Versions: 4.0.0.Alpha5
            Reporter: Richard Opalka
            Assignee: Richard Opalka
             Fix For: 4.0.0.Alpha6


SVH have been deprecated ~ 20 months ago. Now is the time to eliminate it completely.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 10:39:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Tue, 9 Jan 2018 10:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3499) Clean up PathServices
In-Reply-To: <JIRA.12727168.1515512297000@Atlassian.JIRA>
References: <JIRA.12727168.1515512297000@Atlassian.JIRA>
	<JIRA.12727168.1515512297580@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727168.1515512297000.18029.1515512340353@Atlassian.JIRA>

Richard Opalka created WFCORE-3499:
--------------------------------------

             Summary: Clean up PathServices
                 Key: WFCORE-3499
                 URL: https://issues.jboss.org/browse/WFCORE-3499
             Project: WildFly Core
          Issue Type: Task
          Components: Server
    Affects Versions: 4.0.0.Alpha5
            Reporter: Richard Opalka
            Assignee: Richard Opalka
             Fix For: 4.0.0.Alpha6


There are method parameters in path services such as
 * newControllers
 * listeners
that are not used. We can drop them.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 11:18:00 2018
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Tue, 9 Jan 2018 11:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9657) NullPointerException when
 trying to get all job executions
In-Reply-To: <JIRA.12727176.1515514637000@Atlassian.JIRA>
References: <JIRA.12727176.1515514637000@Atlassian.JIRA>
	<JIRA.12727176.1515514637774@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727176.1515514637000.18318.1515514680680@Atlassian.JIRA>

Cheng Fang created WFLY-9657:
--------------------------------

             Summary: NullPointerException when trying to get all job executions
                 Key: WFLY-9657
                 URL: https://issues.jboss.org/browse/WFLY-9657
             Project: WildFly
          Issue Type: Bug
          Components: Batch
    Affects Versions: 11.0.0.Final
            Reporter: Cheng Fang
            Assignee: Cheng Fang


In jberet-ui, the job executions page by default displays all known job executions in the batch runtime. When running in WildFly 11, clicking the jberet-ui job executions page shows no job execution, and in server.log, there is the NPE:

{code:text}
Caused by: java.lang.NullPointerException
	at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobExecutions(JobOperatorService.java:295)
	at org.jberet.operations.DelegatingJobOperator.getJobExecutions(DelegatingJobOperator.java:92)
	at org.jberet.rest.service.JobService.getJobExecutions(JobService.java:113)
	at org.jberet.rest.resource.JobExecutionResource.getJobExecutions(JobExecutionResource.java:64)
	at org.jberet.rest.resource.JobExecutionResource$Proxy$_$$_WeldClientProxy.getJobExecutions(Unknown Source)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406)
	... 43 more
{code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 11:22:01 2018
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Tue, 9 Jan 2018 11:22:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9657) NullPointerException when
 trying to get all job executions
In-Reply-To: <JIRA.12727176.1515514638000@Atlassian.JIRA>
References: <JIRA.12727176.1515514638000@Atlassian.JIRA>
	<JIRA.12727176.1515514638000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727176.1515514638000.18398.1515514921335@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512008#comment-13512008 ] 

Cheng Fang commented on WFLY-9657:
----------------------------------

For the above page, jberet-rest-api calls {{JobOperator.getJobExecutions(JobInstance = null)}}, to get all job executions known to the batch runtime and deployment.

In {{JobOperatorService.getJobExecutions(JobInstance)}} method, we'll need to check for null job instance.

> NullPointerException when trying to get all job executions
> ----------------------------------------------------------
>
>                 Key: WFLY-9657
>                 URL: https://issues.jboss.org/browse/WFLY-9657
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 11.0.0.Final
>            Reporter: Cheng Fang
>            Assignee: Cheng Fang
>
> In jberet-ui, the job executions page by default displays all known job executions in the batch runtime. When running in WildFly 11, clicking the jberet-ui job executions page shows no job execution, and in server.log, there is the NPE:
> {code:text}
> Caused by: java.lang.NullPointerException
> 	at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobExecutions(JobOperatorService.java:295)
> 	at org.jberet.operations.DelegatingJobOperator.getJobExecutions(DelegatingJobOperator.java:92)
> 	at org.jberet.rest.service.JobService.getJobExecutions(JobService.java:113)
> 	at org.jberet.rest.resource.JobExecutionResource.getJobExecutions(JobExecutionResource.java:64)
> 	at org.jberet.rest.resource.JobExecutionResource$Proxy$_$$_WeldClientProxy.getJobExecutions(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406)
> 	... 43 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 11:22:01 2018
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Tue, 9 Jan 2018 11:22:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9657) NullPointerException when
 trying to get all job executions
In-Reply-To: <JIRA.12727176.1515514638000@Atlassian.JIRA>
References: <JIRA.12727176.1515514638000@Atlassian.JIRA>
	<JIRA.12727176.1515514638000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727176.1515514638000.18403.1515514921525@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Cheng Fang reassigned WFLY-9657:
--------------------------------

    Assignee: James Perkins  (was: Cheng Fang)


> NullPointerException when trying to get all job executions
> ----------------------------------------------------------
>
>                 Key: WFLY-9657
>                 URL: https://issues.jboss.org/browse/WFLY-9657
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 11.0.0.Final
>            Reporter: Cheng Fang
>            Assignee: James Perkins
>
> In jberet-ui, the job executions page by default displays all known job executions in the batch runtime. When running in WildFly 11, clicking the jberet-ui job executions page shows no job execution, and in server.log, there is the NPE:
> {code:text}
> Caused by: java.lang.NullPointerException
> 	at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobExecutions(JobOperatorService.java:295)
> 	at org.jberet.operations.DelegatingJobOperator.getJobExecutions(DelegatingJobOperator.java:92)
> 	at org.jberet.rest.service.JobService.getJobExecutions(JobService.java:113)
> 	at org.jberet.rest.resource.JobExecutionResource.getJobExecutions(JobExecutionResource.java:64)
> 	at org.jberet.rest.resource.JobExecutionResource$Proxy$_$$_WeldClientProxy.getJobExecutions(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406)
> 	... 43 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 11:23:00 2018
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Tue, 9 Jan 2018 11:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9657) NullPointerException when
 trying to get all job executions
In-Reply-To: <JIRA.12727176.1515514638000@Atlassian.JIRA>
References: <JIRA.12727176.1515514638000@Atlassian.JIRA>
	<JIRA.12727176.1515514638000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727176.1515514638000.18420.1515514980802@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512011#comment-13512011 ] 

Cheng Fang commented on WFLY-9657:
----------------------------------

[~jamezp] can you take a look?

> NullPointerException when trying to get all job executions
> ----------------------------------------------------------
>
>                 Key: WFLY-9657
>                 URL: https://issues.jboss.org/browse/WFLY-9657
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 11.0.0.Final
>            Reporter: Cheng Fang
>            Assignee: James Perkins
>
> In jberet-ui, the job executions page by default displays all known job executions in the batch runtime. When running in WildFly 11, clicking the jberet-ui job executions page shows no job execution, and in server.log, there is the NPE:
> {code:text}
> Caused by: java.lang.NullPointerException
> 	at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobExecutions(JobOperatorService.java:295)
> 	at org.jberet.operations.DelegatingJobOperator.getJobExecutions(DelegatingJobOperator.java:92)
> 	at org.jberet.rest.service.JobService.getJobExecutions(JobService.java:113)
> 	at org.jberet.rest.resource.JobExecutionResource.getJobExecutions(JobExecutionResource.java:64)
> 	at org.jberet.rest.resource.JobExecutionResource$Proxy$_$$_WeldClientProxy.getJobExecutions(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406)
> 	... 43 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 12:01:01 2018
From: issues at jboss.org (=?UTF-8?Q?Guilherme_Ara=C3=BAjo_=28JIRA=29?=)
Date: Tue, 9 Jan 2018 12:01:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.19009.1515517261258@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512052#comment-13512052 ] 

Guilherme Ara?jo commented on DROOLS-2194:
------------------------------------------

 [~mfusco] [~tirelli] Can you give us feedback on this issue? 

> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>         Attachments: DroolsDynamicReload.zip
>
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  9 12:19:00 2018
From: issues at jboss.org (Trond Arild Lode Tobiassen Heidelberg (JIRA))
Date: Tue, 9 Jan 2018 12:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9604) wildfly-11.0.0.Final JPA
In-Reply-To: <JIRA.12724194.1512836827000@Atlassian.JIRA>
References: <JIRA.12724194.1512836827000@Atlassian.JIRA>
	<JIRA.12724194.1512836827000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724194.1512836827000.19141.1515518340042@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512070#comment-13512070 ] 

Trond Arild Lode Tobiassen Heidelberg commented on WFLY-9604:
-------------------------------------------------------------

No one wants to comment on this one?

> wildfly-11.0.0.Final JPA
> ------------------------
>
>                 Key: WFLY-9604
>                 URL: https://issues.jboss.org/browse/WFLY-9604
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>    Affects Versions: 11.0.0.Final
>         Environment: Javaee 7, Windows 7, jdk 8 151
>            Reporter: Trond Arild Lode Tobiassen Heidelberg
>              Labels: task
>             Fix For: 12.0.0.Alpha1
>
>
> I am deploying to above. I get this error message:
>  
> {"jboss.persistenceunit.registrar#REGDB" => "org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type Caused by: org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type"},
>  
>  
> I have this code:
>  
> @OneToOne(optional = true, cascade = CascadeType.ALL, targetEntity = AbstractPart.class)
> @JoinColumn(name = "PART", unique = false, nullable = true, updatable = false)
> protected X part;
> What about the target= vs the targetEntity=? There is no target attribute or @Type annotation available.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 12:21:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 9 Jan 2018 12:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9658) Batch jobs in a
 sub-deployment can be started but not queried
In-Reply-To: <JIRA.12727196.1515518430000@Atlassian.JIRA>
References: <JIRA.12727196.1515518430000@Atlassian.JIRA>
	<JIRA.12727196.1515518430062@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727196.1515518430000.19146.1515518460156@Atlassian.JIRA>

James Perkins created WFLY-9658:
-----------------------------------

             Summary: Batch jobs in a sub-deployment can be started but not queried
                 Key: WFLY-9658
                 URL: https://issues.jboss.org/browse/WFLY-9658
             Project: WildFly
          Issue Type: Bug
          Components: Batch
            Reporter: James Perkins
            Assignee: James Perkins


In an EAR deployment that contains a multiple batch deployments each sub-deployment can start jobs from other sub-deployments, but the job information cannot be queried. For example a job can be started from a WAR that is in an EJB, however you cannot execute {{JobOperator.getJobInstance()}} from the WAR on the same job.

Visibility should be consistent for starting and querying batch jobs.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 12:27:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 9 Jan 2018 12:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9658) Batch jobs in a
 sub-deployment can be started but not queried
In-Reply-To: <JIRA.12727196.1515518430000@Atlassian.JIRA>
References: <JIRA.12727196.1515518430000@Atlassian.JIRA>
	<JIRA.12727196.1515518430000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727196.1515518430000.19228.1515518820851@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFLY-9658:
--------------------------------
    Description: 
In an EAR deployment that contains a multiple batch deployments each sub-deployment can start jobs from other sub-deployments, but the job information cannot be queried. For example a job can be started from a WAR that is in an EJB, however you cannot execute {{JobOperator.getJobInstance()}} from the WAR on the same job.

Visibility should be consistent for starting and querying batch jobs.

More details on https://github.com/jberet/jsr352/issues/105.

  was:
In an EAR deployment that contains a multiple batch deployments each sub-deployment can start jobs from other sub-deployments, but the job information cannot be queried. For example a job can be started from a WAR that is in an EJB, however you cannot execute {{JobOperator.getJobInstance()}} from the WAR on the same job.

Visibility should be consistent for starting and querying batch jobs.



> Batch jobs in a sub-deployment can be started but not queried
> -------------------------------------------------------------
>
>                 Key: WFLY-9658
>                 URL: https://issues.jboss.org/browse/WFLY-9658
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> In an EAR deployment that contains a multiple batch deployments each sub-deployment can start jobs from other sub-deployments, but the job information cannot be queried. For example a job can be started from a WAR that is in an EJB, however you cannot execute {{JobOperator.getJobInstance()}} from the WAR on the same job.
> Visibility should be consistent for starting and querying batch jobs.
> More details on https://github.com/jberet/jsr352/issues/105.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 12:29:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 9 Jan 2018 12:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9657) NullPointerException when
 trying to get all job executions
In-Reply-To: <JIRA.12727176.1515514638000@Atlassian.JIRA>
References: <JIRA.12727176.1515514638000@Atlassian.JIRA>
	<JIRA.12727176.1515514638000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727176.1515514638000.19248.1515518940269@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9657?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512081#comment-13512081 ] 

James Perkins commented on WFLY-9657:
-------------------------------------

Yes. It may be related to https://issues.jboss.org/browse/WFLY-9658.

> NullPointerException when trying to get all job executions
> ----------------------------------------------------------
>
>                 Key: WFLY-9657
>                 URL: https://issues.jboss.org/browse/WFLY-9657
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 11.0.0.Final
>            Reporter: Cheng Fang
>            Assignee: James Perkins
>
> In jberet-ui, the job executions page by default displays all known job executions in the batch runtime. When running in WildFly 11, clicking the jberet-ui job executions page shows no job execution, and in server.log, there is the NPE:
> {code:text}
> Caused by: java.lang.NullPointerException
> 	at org.wildfly.extension.batch.jberet.deployment.JobOperatorService.getJobExecutions(JobOperatorService.java:295)
> 	at org.jberet.operations.DelegatingJobOperator.getJobExecutions(DelegatingJobOperator.java:92)
> 	at org.jberet.rest.service.JobService.getJobExecutions(JobService.java:113)
> 	at org.jberet.rest.resource.JobExecutionResource.getJobExecutions(JobExecutionResource.java:64)
> 	at org.jberet.rest.resource.JobExecutionResource$Proxy$_$$_WeldClientProxy.getJobExecutions(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:140)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249)
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236)
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:406)
> 	... 43 more
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 13:08:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 9 Jan 2018 13:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3480) ls output is unfriendly if
 any element in return contents is longer than terminal width
In-Reply-To: <JIRA.12725960.1513937509000@Atlassian.JIRA>
References: <JIRA.12725960.1513937509000@Atlassian.JIRA>
	<JIRA.12725960.1513937509000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725960.1513937509000.19383.1515521280188@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3480?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise updated WFCORE-3480:
-----------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3026


> ls output is unfriendly if any element in return contents is longer than terminal width
> ---------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3480
>                 URL: https://issues.jboss.org/browse/WFCORE-3480
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Marek Kopeck?
>            Assignee: Jean-Francois Denise
>            Priority: Blocker
>
> When 'ls' operation is performed over 'provider-loader' element, the output is very ugly - I get many empty lines with one very long attribute value and few more attributes with simple values.
> Expected: no empty lines between printed attributes so the output does not take like 4 screen size.
> *Steps to reproduce:*
> # prepare WF based on wf-core
> # start WF
> # ls /subsystem=elytron/provider-loader=elytron
> # see very long output with many empty lines between particular attribute records printed



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan  9 13:17:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 9 Jan 2018 13:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2182) NPE when @Expires is
 missing on event type
In-Reply-To: <JIRA.12725285.1513353924000@Atlassian.JIRA>
References: <JIRA.12725285.1513353924000@Atlassian.JIRA>
	<JIRA.12725285.1513353924000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725285.1513353924000.19400.1515521820203@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco reopened DROOLS-2182:
---------------------------------


> NPE when @Expires is missing on event type
> ------------------------------------------
>
>                 Key: DROOLS-2182
>                 URL: https://issues.jboss.org/browse/DROOLS-2182
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Christian Bauer
>            Assignee: Mario Fusco
>
> This code in {{ClassObjectTypeConf}} assumes that an event class always has an @Expires annotation, which is optional:
> {code}
>             Role role = clazz.getAnnotation(Role.class);
>             if (role != null) {
>                 isEvent = role.value() == Type.EVENT;
>                 if (isEvent) {
>                     Expires expires = clazz.getAnnotation(Expires.class);
>                     expirationOffset = TimeIntervalParser.parseSingle( expires.value() );
>                 }
>             }
> {code}
> {code}
> java.lang.NullPointerException
> 	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:99)
> 	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:69)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:181)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1493)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1453)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1447)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 13:20:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 9 Jan 2018 13:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2182) NPE when @Expires is
 missing on event type
In-Reply-To: <JIRA.12725285.1513353924000@Atlassian.JIRA>
References: <JIRA.12725285.1513353924000@Atlassian.JIRA>
	<JIRA.12725285.1513353924000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725285.1513353924000.19418.1515522000628@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-2182.
---------------------------------
    Resolution: Done


Fixed by https://github.com/kiegroup/drools/commit/2efb867d9663094c2addf2397b3f5327bf4bd2ff

> NPE when @Expires is missing on event type
> ------------------------------------------
>
>                 Key: DROOLS-2182
>                 URL: https://issues.jboss.org/browse/DROOLS-2182
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Christian Bauer
>            Assignee: Mario Fusco
>
> This code in {{ClassObjectTypeConf}} assumes that an event class always has an @Expires annotation, which is optional:
> {code}
>             Role role = clazz.getAnnotation(Role.class);
>             if (role != null) {
>                 isEvent = role.value() == Type.EVENT;
>                 if (isEvent) {
>                     Expires expires = clazz.getAnnotation(Expires.class);
>                     expirationOffset = TimeIntervalParser.parseSingle( expires.value() );
>                 }
>             }
> {code}
> {code}
> java.lang.NullPointerException
> 	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:99)
> 	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:69)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:181)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1493)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1453)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1447)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 14:09:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 9 Jan 2018 14:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9604) wildfly-11.0.0.Final JPA
In-Reply-To: <JIRA.12724194.1512836827000@Atlassian.JIRA>
References: <JIRA.12724194.1512836827000@Atlassian.JIRA>
	<JIRA.12724194.1512836827000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724194.1512836827000.19528.1515524940116@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-9604:
-----------------------------------
    Component/s: JPA / Hibernate
                     (was: EJB)


At a glance this looks like something that belongs on the forums, with a JIRA opened when a specific bug or RFE is identified.

I'm changing the Component on this to JPA in case the folks who work on that component and are more familiar notice it and see a bug/RFE from what's stated in the description.

> wildfly-11.0.0.Final JPA
> ------------------------
>
>                 Key: WFLY-9604
>                 URL: https://issues.jboss.org/browse/WFLY-9604
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 11.0.0.Final
>         Environment: Javaee 7, Windows 7, jdk 8 151
>            Reporter: Trond Arild Lode Tobiassen Heidelberg
>              Labels: task
>             Fix For: 12.0.0.Alpha1
>
>
> I am deploying to above. I get this error message:
>  
> {"jboss.persistenceunit.registrar#REGDB" => "org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type Caused by: org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type"},
>  
>  
> I have this code:
>  
> @OneToOne(optional = true, cascade = CascadeType.ALL, targetEntity = AbstractPart.class)
> @JoinColumn(name = "PART", unique = false, nullable = true, updatable = false)
> protected X part;
> What about the target= vs the targetEntity=? There is no target attribute or @Type annotation available.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 14:16:00 2018
From: issues at jboss.org (Trond Arild Lode Tobiassen Heidelberg (JIRA))
Date: Tue, 9 Jan 2018 14:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9604) wildfly-11.0.0.Final JPA
In-Reply-To: <JIRA.12724194.1512836827000@Atlassian.JIRA>
References: <JIRA.12724194.1512836827000@Atlassian.JIRA>
	<JIRA.12724194.1512836827000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724194.1512836827000.19536.1515525360274@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512113#comment-13512113 ] 

Trond Arild Lode Tobiassen Heidelberg commented on WFLY-9604:
-------------------------------------------------------------

Thanks for the comment.

> wildfly-11.0.0.Final JPA
> ------------------------
>
>                 Key: WFLY-9604
>                 URL: https://issues.jboss.org/browse/WFLY-9604
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 11.0.0.Final
>         Environment: Javaee 7, Windows 7, jdk 8 151
>            Reporter: Trond Arild Lode Tobiassen Heidelberg
>              Labels: task
>             Fix For: 12.0.0.Alpha1
>
>
> I am deploying to above. I get this error message:
>  
> {"jboss.persistenceunit.registrar#REGDB" => "org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type Caused by: org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type"},
>  
>  
> I have this code:
>  
> @OneToOne(optional = true, cascade = CascadeType.ALL, targetEntity = AbstractPart.class)
> @JoinColumn(name = "PART", unique = false, nullable = true, updatable = false)
> protected X part;
> What about the target= vs the targetEntity=? There is no target attribute or @Type annotation available.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 14:17:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 9 Jan 2018 14:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1357) GSSCredential CredentialSource
 (local-kerberos) into XML
In-Reply-To: <JIRA.12710629.1504787558000@Atlassian.JIRA>
References: <JIRA.12710629.1504787558000@Atlassian.JIRA>
	<JIRA.12710629.1504787558000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12710629.1504787558000.19539.1515525420051@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1357?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512114#comment-13512114 ] 

Jan Kalina commented on ELY-1357:
---------------------------------

Additional note: To allow Windows to use the current user's tickets, following setup ({{allowtgtsessionkey}} key in registry) is neccessary:
https://hc.apache.org/httpcomponents-client-ga/tutorial/html/authentication.html#d5e825

> GSSCredential CredentialSource (local-kerberos) into XML
> --------------------------------------------------------
>
>                 Key: ELY-1357
>                 URL: https://issues.jboss.org/browse/ELY-1357
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Credentials
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Blocker
>             Fix For: 1.2.0.Beta5
>
>
> Initially this should be minimal / no configuration to make a GSSCrdential available if the local user has a Kerberos ticket - at a later point we can review adding additional config such as client keytabs etc...



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 14:25:00 2018
From: issues at jboss.org (Trond Arild Lode Tobiassen Heidelberg (JIRA))
Date: Tue, 9 Jan 2018 14:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9604) wildfly-11.0.0.Final JPA
In-Reply-To: <JIRA.12724194.1512836827000@Atlassian.JIRA>
References: <JIRA.12724194.1512836827000@Atlassian.JIRA>
	<JIRA.12724194.1512836827000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724194.1512836827000.19555.1515525900466@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512113#comment-13512113 ] 

Trond Arild Lode Tobiassen Heidelberg edited comment on WFLY-9604 at 1/9/18 2:24 PM:
-------------------------------------------------------------------------------------

Thanks for the comment. I want to mention that the actual code runs well under glassfish and paraya.


was (Author: trondarild):
Thanks for the comment.

> wildfly-11.0.0.Final JPA
> ------------------------
>
>                 Key: WFLY-9604
>                 URL: https://issues.jboss.org/browse/WFLY-9604
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JPA / Hibernate
>    Affects Versions: 11.0.0.Final
>         Environment: Javaee 7, Windows 7, jdk 8 151
>            Reporter: Trond Arild Lode Tobiassen Heidelberg
>              Labels: task
>             Fix For: 12.0.0.Alpha1
>
>
> I am deploying to above. I get this error message:
>  
> {"jboss.persistenceunit.registrar#REGDB" => "org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type Caused by: org.hibernate.AnnotationException: Property no.tobiassenit.sipstack.sip.message.AbstractMessage.part has an unbound type and no explicit target entity. Resolve this Generic usage issue or set an explicit target attribute (eg @OneToMany(target=) or use an explicit @Type"},
>  
>  
> I have this code:
>  
> @OneToOne(optional = true, cascade = CascadeType.ALL, targetEntity = AbstractPart.class)
> @JoinColumn(name = "PART", unique = false, nullable = true, updatable = false)
> protected X part;
> What about the target= vs the targetEntity=? There is no target attribute or @Type annotation available.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 17:02:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 9 Jan 2018 17:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3500) update module
 org.glassfish.javax.json to version 1.1
In-Reply-To: <JIRA.12698545.1498078917000@Atlassian.JIRA>
References: <JIRA.12698545.1498078917000@Atlassian.JIRA>
	<JIRA.12698545.1498078917000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12698545.1498078917000.19805.1515535320401@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins moved WFLY-8982 to WFCORE-3500:
---------------------------------------------

        Project: WildFly Core  (was: WildFly)
            Key: WFCORE-3500  (was: WFLY-8982)
    Component/s:     (was: EE)


> update module org.glassfish.javax.json to version 1.1
> -----------------------------------------------------
>
>                 Key: WFCORE-3500
>                 URL: https://issues.jboss.org/browse/WFCORE-3500
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: R Searls
>            Assignee: James Perkins
>
> Module org/glassfish/javax/json/main/module.xml
> is hard coded with version 1.0.4.  It needs to be updated to version 1.1
> or higher to support JSON-Binding.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan  9 19:40:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 9 Jan 2018 19:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3501) Allow System properties to
 be set at parse time before extensions are loaded in standalone mode
In-Reply-To: <JIRA.12727220.1515544799000@Atlassian.JIRA>
References: <JIRA.12727220.1515544799000@Atlassian.JIRA>
	<JIRA.12727220.1515544799020@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727220.1515544799000.20540.1515544800073@Atlassian.JIRA>

Stuart Douglas created WFCORE-3501:
--------------------------------------

             Summary: Allow System properties to be set at parse time before extensions are loaded in standalone mode
                 Key: WFCORE-3501
                 URL: https://issues.jboss.org/browse/WFCORE-3501
             Project: WildFly Core
          Issue Type: Feature Request
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 03:33:00 2018
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Wed, 10 Jan 2018 03:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2226) RuleUnitExampleTest.testGo
 fails on Windows
In-Reply-To: <JIRA.12727237.1515573121000@Atlassian.JIRA>
References: <JIRA.12727237.1515573121000@Atlassian.JIRA>
	<JIRA.12727237.1515573121829@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727237.1515573121000.21281.1515573180441@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-2226:
-------------------------------------

             Summary: RuleUnitExampleTest.testGo fails on Windows
                 Key: DROOLS-2226
                 URL: https://issues.jboss.org/browse/DROOLS-2226
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Tibor Zim?nyi
            Assignee: Mario Fusco
            Priority: Minor


When I run test RuleUnitExampleTest.testGo() on Windows, it fails with this output [1]. It looks like some Windows case sensitivity issue. 

[1] https://gist.github.com/baldimir/c62b6d9c41c3ba9f0649a3d4c2bee7f8



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 10 04:07:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 10 Jan 2018 04:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2226) RuleUnitExampleTest.testGo
 fails on Windows
In-Reply-To: <JIRA.12727237.1515573122000@Atlassian.JIRA>
References: <JIRA.12727237.1515573122000@Atlassian.JIRA>
	<JIRA.12727237.1515573122000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727237.1515573122000.21487.1515575220504@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2226:
--------------------------------
    Sprint: 2018 Week 01-02


> RuleUnitExampleTest.testGo fails on Windows
> -------------------------------------------
>
>                 Key: DROOLS-2226
>                 URL: https://issues.jboss.org/browse/DROOLS-2226
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Mario Fusco
>            Priority: Minor
>
> When I run test RuleUnitExampleTest.testGo() on Windows, it fails with this output [1]. It looks like some Windows case sensitivity issue. 
> [1] https://gist.github.com/baldimir/c62b6d9c41c3ba9f0649a3d4c2bee7f8



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 10 04:07:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 10 Jan 2018 04:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2226) RuleUnitExampleTest.testGo
 fails on Windows
In-Reply-To: <JIRA.12727237.1515573122000@Atlassian.JIRA>
References: <JIRA.12727237.1515573122000@Atlassian.JIRA>
	<JIRA.12727237.1515573122000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727237.1515573122000.21491.1515575220961@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-2226.
---------------------------------
    Resolution: Done


Fixed https://github.com/kiegroup/drools/commit/5fad04919f255933bdd34afdb8da10b94f2c8c43

> RuleUnitExampleTest.testGo fails on Windows
> -------------------------------------------
>
>                 Key: DROOLS-2226
>                 URL: https://issues.jboss.org/browse/DROOLS-2226
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Mario Fusco
>            Priority: Minor
>
> When I run test RuleUnitExampleTest.testGo() on Windows, it fails with this output [1]. It looks like some Windows case sensitivity issue. 
> [1] https://gist.github.com/baldimir/c62b6d9c41c3ba9f0649a3d4c2bee7f8



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 10 04:10:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 10 Jan 2018 04:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2182) NPE when @Expires is
 missing on event type
In-Reply-To: <JIRA.12725285.1513353924000@Atlassian.JIRA>
References: <JIRA.12725285.1513353924000@Atlassian.JIRA>
	<JIRA.12725285.1513353924000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725285.1513353924000.21511.1515575400257@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2182?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2182:
--------------------------------
    Sprint: 2018 Week 01-02


> NPE when @Expires is missing on event type
> ------------------------------------------
>
>                 Key: DROOLS-2182
>                 URL: https://issues.jboss.org/browse/DROOLS-2182
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Christian Bauer
>            Assignee: Mario Fusco
>
> This code in {{ClassObjectTypeConf}} assumes that an event class always has an @Expires annotation, which is optional:
> {code}
>             Role role = clazz.getAnnotation(Role.class);
>             if (role != null) {
>                 isEvent = role.value() == Type.EVENT;
>                 if (isEvent) {
>                     Expires expires = clazz.getAnnotation(Expires.class);
>                     expirationOffset = TimeIntervalParser.parseSingle( expires.value() );
>                 }
>             }
> {code}
> {code}
> java.lang.NullPointerException
> 	at org.drools.core.reteoo.ClassObjectTypeConf.<init>(ClassObjectTypeConf.java:99)
> 	at org.drools.core.common.ObjectTypeConfigurationRegistry.getObjectTypeConf(ObjectTypeConfigurationRegistry.java:69)
> 	at org.drools.core.common.NamedEntryPoint.insert(NamedEntryPoint.java:181)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1493)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1453)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.insert(StatefulKnowledgeSessionImpl.java:1447)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 04:10:01 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 10 Jan 2018 04:10:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2213) Cannot recreate the same
 KieBase when using canonical model
In-Reply-To: <JIRA.12726549.1515079459000@Atlassian.JIRA>
References: <JIRA.12726549.1515079459000@Atlassian.JIRA>
	<JIRA.12726549.1515079459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726549.1515079459000.21515.1515575401104@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2213?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2213:
--------------------------------
    Sprint: 2018 Week 01-02


> Cannot recreate the same KieBase when using canonical model
> -----------------------------------------------------------
>
>                 Key: DROOLS-2213
>                 URL: https://issues.jboss.org/browse/DROOLS-2213
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Mario Fusco
>
> Creating the same KieBase from a KieContainer with the same ReleaseId second time fails on NullPoinerException [1]. Reproducer can be found here [2].
> [1] https://gist.github.com/baldimir/b3fa7ed299d5e0d7b74e4cc8bc4878f3
> [2] https://github.com/kiegroup/drools/pull/1681



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 10 04:10:01 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 10 Jan 2018 04:10:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2219) CCE on node memories when
 using rule units but inserting a fact into the shared memory
In-Reply-To: <JIRA.12726766.1515164546000@Atlassian.JIRA>
References: <JIRA.12726766.1515164546000@Atlassian.JIRA>
	<JIRA.12726766.1515164546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726766.1515164546000.21517.1515575401337@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2219:
--------------------------------
    Sprint: 2018 Week 01-02


> CCE on node memories when using rule units but inserting a fact into the shared memory
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2219
>                 URL: https://issues.jboss.org/browse/DROOLS-2219
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 04:11:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 10 Jan 2018 04:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2211) Trying to modify a global
 wm object from the consequence of a rule belonging to rule unit causes a
 NPE
In-Reply-To: <JIRA.12726481.1515064456000@Atlassian.JIRA>
References: <JIRA.12726481.1515064456000@Atlassian.JIRA>
	<JIRA.12726481.1515064456000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726481.1515064456000.21519.1515575460121@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2211?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2211:
--------------------------------
    Sprint: 2018 Week 01-02


> Trying to modify a global wm object from the consequence of a rule belonging to rule unit causes a NPE
> ------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2211
>                 URL: https://issues.jboss.org/browse/DROOLS-2211
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 04:11:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 10 Jan 2018 04:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2208) Sometimes the agenda stops
 firing even if there are outstanding activations to be evaluated
In-Reply-To: <JIRA.12726390.1514992722000@Atlassian.JIRA>
References: <JIRA.12726390.1514992722000@Atlassian.JIRA>
	<JIRA.12726390.1514992722000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726390.1514992722000.21521.1515575460347@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2208?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2208:
--------------------------------
    Sprint: 2018 Week 01-02


> Sometimes the agenda stops firing even if there are outstanding activations to be evaluated
> -------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2208
>                 URL: https://issues.jboss.org/browse/DROOLS-2208
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 04:11:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 10 Jan 2018 04:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2209) Error with accumulator and
 DataSource being used in rule units
In-Reply-To: <JIRA.12726413.1515000271000@Atlassian.JIRA>
References: <JIRA.12726413.1515000271000@Atlassian.JIRA>
	<JIRA.12726413.1515000271000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726413.1515000271000.21523.1515575460650@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2209?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2209:
--------------------------------
    Sprint: 2018 Week 01-02


> Error with accumulator and DataSource being used in rule units
> --------------------------------------------------------------
>
>                 Key: DROOLS-2209
>                 URL: https://issues.jboss.org/browse/DROOLS-2209
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 04:13:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 10 Jan 2018 04:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3502) Test-runner doesn't handle
 debug options correctly
In-Reply-To: <JIRA.12727245.1515575538000@Atlassian.JIRA>
References: <JIRA.12727245.1515575538000@Atlassian.JIRA>
	<JIRA.12727245.1515575538813@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727245.1515575538000.21554.1515575580598@Atlassian.JIRA>

Marek Kopeck? created WFCORE-3502:
-------------------------------------

             Summary: Test-runner doesn't handle debug options correctly
                 Key: WFCORE-3502
                 URL: https://issues.jboss.org/browse/WFCORE-3502
             Project: WildFly Core
          Issue Type: Bug
          Components: Test Suite
            Reporter: Marek Kopeck?
            Assignee: Marek Kopeck?


Test-runner doesn't handle debug options correctly.

If jdpa profile is used, surefire jvm uses this JVM attribute: {{-agentlib:jdwp=transport=dt_socket,address=$\{as.debug.port\},server=y,suspend=y}}.

The same attribute is passed to started server. But server debugging should be set by {{wildfly.debug}} and {{wildfly.debug.port}} java properties. So if user wants to debug surefire with 8787 port and server with 8786 port, he uses jdpa profile, {{wildfly.debug}} property and {{wildfly.debug.port}} property and test fails:

{{mvn test -DfailIfNoTests=false -DtestLogToFile=false -Dtest=CdTestCase -Djpda -Dwildfly.debug=true -Dwildfly.debug.port=8786}}
{noformat}
ERROR: Cannot load this JVM TI agent twice, check your java command line for duplicate jdwp options.
Error occurred during initialization of VM
agent library failed to init: jdwp
Running null
{noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 10 04:20:01 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 10 Jan 2018 04:20:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3502) Fix debug options in
	test-runner
In-Reply-To: <JIRA.12727245.1515575539000@Atlassian.JIRA>
References: <JIRA.12727245.1515575539000@Atlassian.JIRA>
	<JIRA.12727245.1515575539000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727245.1515575539000.21664.1515576001594@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-3502:
----------------------------------
    Summary: Fix debug options in test-runner  (was: Test-runner doesn't handle debug options correctly)


> Fix debug options in test-runner
> --------------------------------
>
>                 Key: WFCORE-3502
>                 URL: https://issues.jboss.org/browse/WFCORE-3502
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Test-runner doesn't handle debug options correctly.
> If jdpa profile is used, surefire jvm uses this JVM attribute: {{-agentlib:jdwp=transport=dt_socket,address=$\{as.debug.port\},server=y,suspend=y}}.
> The same attribute is passed to started server. But server debugging should be set by {{wildfly.debug}} and {{wildfly.debug.port}} java properties. So if user wants to debug surefire with 8787 port and server with 8786 port, he uses jdpa profile, {{wildfly.debug}} property and {{wildfly.debug.port}} property and test fails:
> {{mvn test -DfailIfNoTests=false -DtestLogToFile=false -Dtest=CdTestCase -Djpda -Dwildfly.debug=true -Dwildfly.debug.port=8786}}
> {noformat}
> ERROR: Cannot load this JVM TI agent twice, check your java command line for duplicate jdwp options.
> Error occurred during initialization of VM
> agent library failed to init: jdwp
> Running null
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 10 04:23:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 10 Jan 2018 04:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3502) Fix debug options in
	test-runner
In-Reply-To: <JIRA.12727245.1515575539000@Atlassian.JIRA>
References: <JIRA.12727245.1515575539000@Atlassian.JIRA>
	<JIRA.12727245.1515575539000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727245.1515575539000.21674.1515576180334@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-3502:
----------------------------------
    Description: 
Test-runner doesn't handle debug options correctly.

If jdpa profile is used, surefire jvm uses this JVM attribute: {{-agentlib:jdwp=transport=dt_socket,address=$\{as.debug.port\},server=y,suspend=y}}.

The same attribute is passed to started server. But server debugging should be set by {{wildfly.debug}} and {{wildfly.debug.port}} java properties. So if user wants to debug surefire with 8787 port and server with 8786 port, user uses jdpa profile, {{wildfly.debug}} property and {{wildfly.debug.port}} property and test fails:

{{mvn test -DfailIfNoTests=false -DtestLogToFile=false -Dtest=CdTestCase -Djpda -Dwildfly.debug=true -Dwildfly.debug.port=8786}}
{noformat}
ERROR: Cannot load this JVM TI agent twice, check your java command line for duplicate jdwp options.
Error occurred during initialization of VM
agent library failed to init: jdwp
Running null
{noformat}

  was:
Test-runner doesn't handle debug options correctly.

If jdpa profile is used, surefire jvm uses this JVM attribute: {{-agentlib:jdwp=transport=dt_socket,address=$\{as.debug.port\},server=y,suspend=y}}.

The same attribute is passed to started server. But server debugging should be set by {{wildfly.debug}} and {{wildfly.debug.port}} java properties. So if user wants to debug surefire with 8787 port and server with 8786 port, he uses jdpa profile, {{wildfly.debug}} property and {{wildfly.debug.port}} property and test fails:

{{mvn test -DfailIfNoTests=false -DtestLogToFile=false -Dtest=CdTestCase -Djpda -Dwildfly.debug=true -Dwildfly.debug.port=8786}}
{noformat}
ERROR: Cannot load this JVM TI agent twice, check your java command line for duplicate jdwp options.
Error occurred during initialization of VM
agent library failed to init: jdwp
Running null
{noformat}



> Fix debug options in test-runner
> --------------------------------
>
>                 Key: WFCORE-3502
>                 URL: https://issues.jboss.org/browse/WFCORE-3502
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Test-runner doesn't handle debug options correctly.
> If jdpa profile is used, surefire jvm uses this JVM attribute: {{-agentlib:jdwp=transport=dt_socket,address=$\{as.debug.port\},server=y,suspend=y}}.
> The same attribute is passed to started server. But server debugging should be set by {{wildfly.debug}} and {{wildfly.debug.port}} java properties. So if user wants to debug surefire with 8787 port and server with 8786 port, user uses jdpa profile, {{wildfly.debug}} property and {{wildfly.debug.port}} property and test fails:
> {{mvn test -DfailIfNoTests=false -DtestLogToFile=false -Dtest=CdTestCase -Djpda -Dwildfly.debug=true -Dwildfly.debug.port=8786}}
> {noformat}
> ERROR: Cannot load this JVM TI agent twice, check your java command line for duplicate jdwp options.
> Error occurred during initialization of VM
> agent library failed to init: jdwp
> Running null
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 10 04:24:06 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 10 Jan 2018 04:24:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3502) Fix debug options in
	test-runner
In-Reply-To: <JIRA.12727245.1515575539000@Atlassian.JIRA>
References: <JIRA.12727245.1515575539000@Atlassian.JIRA>
	<JIRA.12727245.1515575539000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727245.1515575539000.21731.1515576246381@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-3502:
----------------------------------
    Affects Version/s: 4.0.0.Alpha5


> Fix debug options in test-runner
> --------------------------------
>
>                 Key: WFCORE-3502
>                 URL: https://issues.jboss.org/browse/WFCORE-3502
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Test-runner doesn't handle debug options correctly.
> If jdpa profile is used, surefire jvm uses this JVM attribute: {{-agentlib:jdwp=transport=dt_socket,address=$\{as.debug.port\},server=y,suspend=y}}.
> The same attribute is passed to started server. But server debugging should be set by {{wildfly.debug}} and {{wildfly.debug.port}} java properties. So if user wants to debug surefire with 8787 port and server with 8786 port, user uses jdpa profile, {{wildfly.debug}} property and {{wildfly.debug.port}} property and test fails:
> {{mvn test -DfailIfNoTests=false -DtestLogToFile=false -Dtest=CdTestCase -Djpda -Dwildfly.debug=true -Dwildfly.debug.port=8786}}
> {noformat}
> ERROR: Cannot load this JVM TI agent twice, check your java command line for duplicate jdwp options.
> Error occurred during initialization of VM
> agent library failed to init: jdwp
> Running null
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 10 04:32:00 2018
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Wed, 10 Jan 2018 04:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2227) Verifier should manage
 predicate columns properly
In-Reply-To: <JIRA.12727249.1515576672000@Atlassian.JIRA>
References: <JIRA.12727249.1515576672000@Atlassian.JIRA>
	<JIRA.12727249.1515576672661@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727249.1515576672000.21865.1515576720287@Atlassian.JIRA>

Toni Rikkola created DROOLS-2227:
------------------------------------

             Summary: Verifier should manage predicate columns properly
                 Key: DROOLS-2227
                 URL: https://issues.jboss.org/browse/DROOLS-2227
             Project: Drools
          Issue Type: Enhancement
          Components: Guided Decision Table Editor
            Reporter: Toni Rikkola
            Assignee: Toni Rikkola






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 04:32:00 2018
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Wed, 10 Jan 2018 04:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2227) Verifier should manage
 predicate columns properly
In-Reply-To: <JIRA.12727249.1515576673000@Atlassian.JIRA>
References: <JIRA.12727249.1515576673000@Atlassian.JIRA>
	<JIRA.12727249.1515576673000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727249.1515576673000.21867.1515576720339@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512295#comment-13512295 ] 

Toni Rikkola commented on DROOLS-2227:
--------------------------------------

ping [~jomarko]

> Verifier should manage predicate columns properly
> -------------------------------------------------
>
>                 Key: DROOLS-2227
>                 URL: https://issues.jboss.org/browse/DROOLS-2227
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Guided Decision Table Editor
>            Reporter: Toni Rikkola
>            Assignee: Toni Rikkola
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 04:41:01 2018
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Wed, 10 Jan 2018 04:41:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2227) Verifier should manage
 predicate columns properly
In-Reply-To: <JIRA.12727249.1515576673000@Atlassian.JIRA>
References: <JIRA.12727249.1515576673000@Atlassian.JIRA>
	<JIRA.12727249.1515576673000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727249.1515576673000.21942.1515577261242@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toni Rikkola updated DROOLS-2227:
---------------------------------
    Description: 
 < Rikkola> for dtables, string comparison is probably enough, 
                 prooobably
 < Rikkola> and when I type that nope
< Rikkola> eval( 1+1) and eval( 0+2) are the same, but no way to know
 < Rikkola> maybe a warning when columns like this are used, the V&V might 
                 not pick everything up



> Verifier should manage predicate columns properly
> -------------------------------------------------
>
>                 Key: DROOLS-2227
>                 URL: https://issues.jboss.org/browse/DROOLS-2227
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Guided Decision Table Editor
>            Reporter: Toni Rikkola
>            Assignee: Toni Rikkola
>
>  < Rikkola> for dtables, string comparison is probably enough, 
>                  prooobably
>  < Rikkola> and when I type that nope
> < Rikkola> eval( 1+1) and eval( 0+2) are the same, but no way to know
>  < Rikkola> maybe a warning when columns like this are used, the V&V might 
>                  not pick everything up



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 04:41:02 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 10 Jan 2018 04:41:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1369) FIPS mode,
 Elytron HTTP DIGEST authentication mechanism not fips compliant
In-Reply-To: <JIRA.12712431.1505900284000@Atlassian.JIRA>
References: <JIRA.12712431.1505900284000@Atlassian.JIRA>
	<JIRA.12712431.1505900284000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712431.1505900284000.21949.1515577262108@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512304#comment-13512304 ] 

Darran Lofthouse commented on ELY-1369:
---------------------------------------

Our biggest gap here is likely to be clients not supporting the new digests.

> FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant
> --------------------------------------------------------------------------
>
>                 Key: ELY-1369
>                 URL: https://issues.jboss.org/browse/ELY-1369
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.2.0.Beta3
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta11
>
>
> Elytron HTTP DIGEST authentication comply to rfc2617 - which means MD5 is used by default (it means it is hardcode, with no way to configure another hash algorithm). But MD5 could make troubles in fips environment [5].
> {code:java|title=DigestAuthenticationMechanism.java}
>         String algorithm = convertToken(ALGORITHM, responseTokens.get(ALGORITHM));
>         if (MD5.equals(algorithm) == false) {
>             throw log.mechUnsupportedAlgorithm(getMechanismName(), algorithm);
>         }
> {code}
> There exists proposed rfc7616 which makes algorithm configurable, work on new DIGEST features are covered by [1]. [~dlofthouse] is it planned for [1] to target 7.1? 
> [1] https://issues.jboss.org/browse/ELY-286
> [2] https://developer.jboss.org/wiki/ElytronHTTPDigestNonceHandling-Design
> [3] https://tools.ietf.org/html/rfc2617
> [4] https://tools.ietf.org/html/rfc7616
> [5] https://access.redhat.com/support/cases/#/case/01761455



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 04:54:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 10 Jan 2018 04:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2228) [Guided Decision Table]
 Rename Set the field value with Work Item parameter column
In-Reply-To: <JIRA.12727252.1515577972000@Atlassian.JIRA>
References: <JIRA.12727252.1515577972000@Atlassian.JIRA>
	<JIRA.12727252.1515577972000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727252.1515577972000.22019.1515578040183@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis moved RHDM-259 to DROOLS-2228:
---------------------------------------------

              Project: Drools  (was: Red Hat Decision Manager)
                  Key: DROOLS-2228  (was: RHDM-259)
             Workflow: GIT Pull Request workflow   (was: CDW with docs v1)
       Docs QE Status: NEW
          Component/s: Guided Decision Table Editor
                           (was: Business Central)
        Affects Build:   (was: ER2)
    Affects Version/s: 7.5.0.Final
                           (was: 7.0.0)
            QE Status: NEW


> [Guided Decision Table] Rename Set the field value with Work Item parameter column
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-2228
>                 URL: https://issues.jboss.org/browse/DROOLS-2228
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>            Priority: Trivial
>              Labels: bxms-bughunt-7-la-er2
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> The column *Set the field value with Work Item parameter* actually set the field with Work Item result so maybe it could be renamed to *Set the field value with Work Item result*.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 04:54:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 10 Jan 2018 04:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2228) [Guided Decision Table]
 Rename Set the field value with Work Item parameter column
In-Reply-To: <JIRA.12727252.1515577972000@Atlassian.JIRA>
References: <JIRA.12727252.1515577972000@Atlassian.JIRA>
	<JIRA.12727252.1515577972000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727252.1515577972000.22023.1515578040913@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2228:
-----------------------------------
    Sprint: 2018 Week 01-02


> [Guided Decision Table] Rename Set the field value with Work Item parameter column
> ----------------------------------------------------------------------------------
>
>                 Key: DROOLS-2228
>                 URL: https://issues.jboss.org/browse/DROOLS-2228
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>            Priority: Trivial
>              Labels: bxms-bughunt-7-la-er2
>   Original Estimate: 1 day
>  Remaining Estimate: 1 day
>
> The column *Set the field value with Work Item parameter* actually set the field with Work Item result so maybe it could be renamed to *Set the field value with Work Item result*.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 05:03:00 2018
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Wed, 10 Jan 2018 05:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9643) Getting Internal server error
 on exception if the rest service content type is "application/xml"
In-Reply-To: <JIRA.12726085.1514643775000@Atlassian.JIRA>
References: <JIRA.12726085.1514643775000@Atlassian.JIRA>
	<JIRA.12726085.1514643775000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726085.1514643775000.22066.1515578580412@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512319#comment-13512319 ] 

Alessio Soldano commented on WFLY-9643:
---------------------------------------

[~gopalams] , could you please provider a reproducer app for this?

> Getting Internal server error on exception if the rest service content type is "application/xml"
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9643
>                 URL: https://issues.jboss.org/browse/WFLY-9643
>             Project: WildFly
>          Issue Type: Bug
>          Components: REST
>            Reporter: Gopal krishna
>            Assignee: Alessio Soldano
>
> We are getting Internal server error if any exception is thrown from spring interceptor  when rest API header is set as "application/xml". This works if the rest API header is set as "application/json".
> we didnt see this issue in jboss 7 and  WAS



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 05:05:00 2018
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Wed, 10 Jan 2018 05:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9646) Wsconsume is not able to
 generate jar file from wsdl
In-Reply-To: <JIRA.12726113.1514878188000@Atlassian.JIRA>
References: <JIRA.12726113.1514878188000@Atlassian.JIRA>
	<JIRA.12726113.1514878188000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726113.1514878188000.22078.1515578700833@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano updated WFLY-9646:
----------------------------------
    Fix Version/s: 12.0.0.Alpha1


> Wsconsume is not able to generate jar file from wsdl
> ----------------------------------------------------
>
>                 Key: WFLY-9646
>                 URL: https://issues.jboss.org/browse/WFLY-9646
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts, Web Services
>            Reporter: Marek Kopeck?
>            Assignee: Alessio Soldano
>            Priority: Blocker
>             Fix For: 12.0.0.Alpha1
>
>
> *Description:*
> Wsconsume is able to generate jar file from wsdl on WildFly 11. On WildFly master, wsconsume doesn't create any files in "out" folder. It leads to Exception from wsdl2java tool.
> *Steps to reproduce:*
> # cd $\{JBOSS_HOME\}/bin
> # # download Echo1.wsdl, Echo1Service.wsdl and Echo1Service_schema1.xsd files, these files are attached to this jira
> # mkdir out
> # ./wsconsume.sh -j wsClientShort.jar -p org.jboss.test.script -o out Echo1Service.wsdl
> *Actual results:*
> {noformat}
> [mkopecky at dhcp-10-40-4-226 bin]$ ./wsconsume.sh -j wsClientShort.jar -p org.jboss.test.script -o out Echo1Service.wsdl
> Could not find log4j.properties or log4j.xml configuration, logging to console.
> Loading FrontEnd jaxws ...
> Loading DataBinding jaxb ...
> wsdl2java -clientjar wsClientShort.jar -compile -exsh false -p org.jboss.test.script -d /home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583 -verbose -classdir /home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out -allowElementReferences file:/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/Echo1Service.wsdl
> wsdl2java - Apache CXF 3.1.12
> JBWS024002: Failed to invoke org.apache.cxf.tools.wsdlto.WSDLToJava
> org.apache.cxf.tools.common.ToolException: java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583/org/jboss/test/script/package-info.java" "read")
> 	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:423)
> 	at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> 	at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> 	at org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:313)
> 	at org.jboss.ws.tools.cmd.WSConsume.importServices(WSConsume.java:298)
> 	at org.jboss.ws.tools.cmd.WSConsume.mainInternal(WSConsume.java:108)
> 	at org.jboss.ws.tools.cmd.WSConsume.main(WSConsume.java:96)
> 	at org.jboss.modules.Module.run(Module.java:344)
> 	at org.jboss.modules.Main.main(Main.java:525)
> Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583/org/jboss/test/script/package-info.java" "read")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> 	at java.security.AccessController.checkPermission(AccessController.java:884)
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> 	at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> 	at java.io.File.isDirectory(File.java:844)
> 	at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:69)
> 	at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:64)
> 	at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromFiles(JavacFileManager.java:785)
> 	at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromStrings(JavacFileManager.java:185)
> 	at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:192)
> 	at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:141)
> 	at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:123)
> 	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:306)
> 	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
> 	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:415)
> 	... 8 more
> [mkopecky at dhcp-10-40-4-226 bin]$ ll out/
> total 0
> [mkopecky at dhcp-10-40-4-226 bin]$
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 10 05:14:00 2018
From: issues at jboss.org (Martin Weiler (JIRA))
Date: Wed, 10 Jan 2018 05:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1008) KieServer to update
 container for SNAPSHOT kjar
In-Reply-To: <JIRA.12596940.1450284849000@Atlassian.JIRA>
References: <JIRA.12596940.1450284849000@Atlassian.JIRA>
	<JIRA.12596940.1450284849000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12596940.1450284849000.22139.1515579240345@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512326#comment-13512326 ] 

Martin Weiler commented on DROOLS-1008:
---------------------------------------

Just for the records, this issue seems to be similar to https://issues.jboss.org/browse/RHBPMS-5076 which has been fixed recently on 6.5.x.

> 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
>
>
> General:
> When a kjar has 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, regardless of settings.xml snapshot updatePolicy setting.  Retrieving a new snapshot version is only possible through use of KieScanner.scanNow() or recycling the JVM, which will both fetch the new artifact from the remote repository and reload the kmodule in the KieServer JVM.
> Steps to reproduce:
> * KieServer and Business Central deployed to separate JVMs, pointing to independent maven repositories. Snapshot updatePolicy should be "always" in KieServer settings.xml.
> * Deploy new kjar snapshot from Business Central to remote artifactory. (unique version "1")
> * Start KieServer (verify new snapshot version is pulled from remote)
> * Deploy new kjar snapnshot. (unique version "2")
> Expected behavior:
> * Creating a new container, or invoking updateReleaseId() on existing container will pull latest snapshot from remote artifactory.
> Actual Behavior
> * Creating a new container, or invoking updateReleaseId() on existing container, does not query remote artifactory for latest snapshots.
> Workaround:
> * Forcing a KieScanner.scanNow() will fetch new snapshot from remote artifactory.
> * Or, restarting KieScanner JVM will fetch new snapshot from remote artifactory.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 05:25:00 2018
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Wed, 10 Jan 2018 05:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2229) Error shown every time GDT
 editor opened in Firefox and IE11
In-Reply-To: <JIRA.12727272.1515579815000@Atlassian.JIRA>
References: <JIRA.12727272.1515579815000@Atlassian.JIRA>
	<JIRA.12727272.1515579815000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727272.1515579815000.22268.1515579900526@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toni Rikkola moved RHDM-260 to DROOLS-2229:
-------------------------------------------

              Project: Drools  (was: Red Hat Decision Manager)
                  Key: DROOLS-2229  (was: RHDM-260)
             Workflow: GIT Pull Request workflow   (was: CDW with docs v1)
       Docs QE Status: NEW
        Affects Build:   (was: ER1)
    Affects Version/s:     (was: 7.0.0.GA)
            QE Status: NEW
        Fix Version/s:     (was: 7.0.0.GA)


> Error shown every time GDT editor opened in Firefox and IE11
> ------------------------------------------------------------
>
>                 Key: DROOLS-2229
>                 URL: https://issues.jboss.org/browse/DROOLS-2229
>             Project: Drools
>          Issue Type: Bug
>         Environment: - Firefox browser
> - IE11
>            Reporter: Toni Rikkola
>            Assignee: Toni Rikkola
>            Priority: Blocker
>
> The following error appears every time I create new / open existing GDT
> in Firefox (tested with latest 57.0.1 as well as with latest 52 esr) or IE11 but it works fine on chrome.
> "Unable to complete your request. The following exception occurred: (String) : ReferenceError: window is not defined (http://localhost:8080/decision-central/verifier/D1F31C11AAF94D26DDBD996797F01787.cache.js:2649)."
> Reproducible 100% with RHDM ER1 using Firefox and IE



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 05:25:01 2018
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Wed, 10 Jan 2018 05:25:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2229) Error shown every time GDT
 editor opened in Firefox and IE11
In-Reply-To: <JIRA.12727272.1515579815000@Atlassian.JIRA>
References: <JIRA.12727272.1515579815000@Atlassian.JIRA>
	<JIRA.12727272.1515579815000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727272.1515579815000.22276.1515579901325@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toni Rikkola updated DROOLS-2229:
---------------------------------
    Component/s: Guided Decision Table Editor


> Error shown every time GDT editor opened in Firefox and IE11
> ------------------------------------------------------------
>
>                 Key: DROOLS-2229
>                 URL: https://issues.jboss.org/browse/DROOLS-2229
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>         Environment: - Firefox browser
> - IE11
>            Reporter: Toni Rikkola
>            Assignee: Toni Rikkola
>            Priority: Blocker
>
> The following error appears every time I create new / open existing GDT
> in Firefox (tested with latest 57.0.1 as well as with latest 52 esr) or IE11 but it works fine on chrome.
> "Unable to complete your request. The following exception occurred: (String) : ReferenceError: window is not defined (http://localhost:8080/decision-central/verifier/D1F31C11AAF94D26DDBD996797F01787.cache.js:2649)."
> Reproducible 100% with RHDM ER1 using Firefox and IE



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 06:34:00 2018
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Wed, 10 Jan 2018 06:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1365) Statistics not updated when
 a connection listener is destroyed
In-Reply-To: <JIRA.12727293.1515584025000@Atlassian.JIRA>
References: <JIRA.12727293.1515584025000@Atlassian.JIRA>
	<JIRA.12727293.1515584025924@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727293.1515584025000.22731.1515584040484@Atlassian.JIRA>

Flavia Rainone created JBJCA-1365:
-------------------------------------

             Summary: Statistics not updated when a connection listener is destroyed
                 Key: JBJCA-1365
                 URL: https://issues.jboss.org/browse/JBJCA-1365
             Project: IronJacamar
          Issue Type: Bug
            Reporter: Flavia Rainone
            Assignee: Flavia Rainone


In Ironjacamar 1.0.4, there is a regression caused by JBJCA-1354 fix.
Whenever a connection is closed, and the corresponding tx connection listener is removed from the pool, the managed connection pool is not notified and that causes the statistics to go inconsistent.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 06:35:00 2018
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Wed, 10 Jan 2018 06:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1365) Statistics not updated when
 a connection listener is destroyed
In-Reply-To: <JIRA.12727293.1515584026000@Atlassian.JIRA>
References: <JIRA.12727293.1515584026000@Atlassian.JIRA>
	<JIRA.12727293.1515584026000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727293.1515584026000.22745.1515584100331@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JBJCA-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512378#comment-13512378 ] 

Flavia Rainone commented on JBJCA-1365:
---------------------------------------

This issue is a regression caused when the fix for JBJCA-1354 was ported to branch 1.0.

> Statistics not updated when a connection listener is destroyed
> --------------------------------------------------------------
>
>                 Key: JBJCA-1365
>                 URL: https://issues.jboss.org/browse/JBJCA-1365
>             Project: IronJacamar
>          Issue Type: Bug
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> In Ironjacamar 1.0.4, there is a regression caused by JBJCA-1354 fix.
> Whenever a connection is closed, and the corresponding tx connection listener is removed from the pool, the managed connection pool is not notified and that causes the statistics to go inconsistent.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 06:57:00 2018
From: issues at jboss.org (Shabbeer Shaik (JIRA))
Date: Wed, 10 Jan 2018 06:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2223) Conversion from XLSX
 decision table -> Guided Decision Table has not worked correctly.
In-Reply-To: <JIRA.12727109.1515503385000@Atlassian.JIRA>
References: <JIRA.12727109.1515503385000@Atlassian.JIRA>
	<JIRA.12727109.1515503385000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727109.1515503385000.22869.1515585420130@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512390#comment-13512390 ] 

Shabbeer Shaik commented on DROOLS-2223:
----------------------------------------

Please let me know if you need any other information. 

Thanks in advance.

> Conversion from XLSX decision table -> Guided Decision Table has not worked correctly.
> --------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2223
>                 URL: https://issues.jboss.org/browse/DROOLS-2223
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor, XLS Decision Table Editor
>    Affects Versions: 7.4.1.Final
>            Reporter: Shabbeer Shaik
>            Assignee: Michael Anstis
>         Attachments: myrepo_Test_Dates.zip
>
>
> Please check the below link for more details
> https://groups.google.com/forum/#!topic/drools-usage/iPIwL-QC77w 
> Getting Error :
> {color:red}Error :{color}
> [KBase: defaultKieBase]: Unable to Analyse Expression getBP_DATE() > "-12": [Error: Comparison operation requires compatible types. Found class java.util.Date and class java.lang.String]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 06:58:02 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 10 Jan 2018 06:58:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.22878.1515585482157@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512392#comment-13512392 ] 

Mario Fusco commented on DROOLS-2194:
-------------------------------------

[~tirelli] I confirm this is bug. For now I created a more isolated reproducer, I'm still investigating the problem.

> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>         Attachments: DroolsDynamicReload.zip
>
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 07:06:00 2018
From: issues at jboss.org (Flavia Rainone (JIRA))
Date: Wed, 10 Jan 2018 07:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBJCA-1365) Statistics not updated when
 a connection listener is destroyed
In-Reply-To: <JIRA.12727293.1515584026000@Atlassian.JIRA>
References: <JIRA.12727293.1515584026000@Atlassian.JIRA>
	<JIRA.12727293.1515584026000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727293.1515584026000.22944.1515585960098@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBJCA-1365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Flavia Rainone updated JBJCA-1365:
----------------------------------
    Git Pull Request: https://github.com/ironjacamar/ironjacamar/pull/646


> Statistics not updated when a connection listener is destroyed
> --------------------------------------------------------------
>
>                 Key: JBJCA-1365
>                 URL: https://issues.jboss.org/browse/JBJCA-1365
>             Project: IronJacamar
>          Issue Type: Bug
>            Reporter: Flavia Rainone
>            Assignee: Flavia Rainone
>
> In Ironjacamar 1.0.4, there is a regression caused by JBJCA-1354 fix.
> Whenever a connection is closed, and the corresponding tx connection listener is removed from the pool, the managed connection pool is not notified and that causes the statistics to go inconsistent.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 07:41:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 10 Jan 2018 07:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2230) Deadlock related to
 org.kie.workbench.common.services.backend.builder.core.LRUProjectDependenciesClassLoaderCache
In-Reply-To: <JIRA.12727309.1515587983000@Atlassian.JIRA>
References: <JIRA.12727309.1515587983000@Atlassian.JIRA>
	<JIRA.12727309.1515587983000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727309.1515587983000.23191.1515588060293@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis moved RHDM-261 to DROOLS-2230:
---------------------------------------------

              Project: Drools  (was: Red Hat Decision Manager)
                  Key: DROOLS-2230  (was: RHDM-261)
             Workflow: GIT Pull Request workflow   (was: CDW with docs v1)
       Docs QE Status: NEW
          Component/s: build
                           (was: Business Central)
        Affects Build:   (was: DR1)
    Affects Version/s: 7.5.0.Final
                           (was: 7.0.0.GA)
            QE Status: NEW
        Fix Version/s:     (was: 7.0.0.GA)


> Deadlock related to org.kie.workbench.common.services.backend.builder.core.LRUProjectDependenciesClassLoaderCache
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2230
>                 URL: https://issues.jboss.org/browse/DROOLS-2230
>             Project: Drools
>          Issue Type: Bug
>          Components: build
>    Affects Versions: 7.5.0.Final
>         Environment: EAP 7.1
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>            Priority: Blocker
>              Labels: reported-by-qe
>
> We have encountered a deadlock in business-central prohibiting EAP from stopping:
> Found one Java-level deadlock:
> =============================
> "Thread-848":
>   waiting to lock monitor 0x00007f3f8008f788 (object 0x000000008f743730, a org.kie.workbench.common.services.backend.builder.core.LRUProjectDependenciesClassLoaderCache$Proxy$_$$_WeldClientProxy),
>   which is held by "Thread-377"
> "Thread-377":
>   waiting to lock monitor 0x00007f3f80092228 (object 0x000000009579fac0, a org.drools.compiler.kie.builder.impl.KieFileSystemImpl),
>   which is held by "Thread-520"
> "Thread-520":
>   waiting to lock monitor 0x00007f3f8008f788 (object 0x000000008f743730, a org.kie.workbench.common.services.backend.builder.core.LRUProjectDependenciesClassLoaderCache$Proxy$_$$_WeldClientProxy),
>   which is held by "Thread-377"
> Please have a look at the full jstack output in the attachment.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 07:41:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 10 Jan 2018 07:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2230) Deadlock related to
 org.kie.workbench.common.services.backend.builder.core.LRUProjectDependenciesClassLoaderCache
In-Reply-To: <JIRA.12727309.1515587983000@Atlassian.JIRA>
References: <JIRA.12727309.1515587983000@Atlassian.JIRA>
	<JIRA.12727309.1515587983000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727309.1515587983000.23193.1515588060381@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2230:
-----------------------------------
    Sprint: 2018 Week 01-02


> Deadlock related to org.kie.workbench.common.services.backend.builder.core.LRUProjectDependenciesClassLoaderCache
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2230
>                 URL: https://issues.jboss.org/browse/DROOLS-2230
>             Project: Drools
>          Issue Type: Bug
>          Components: build
>    Affects Versions: 7.5.0.Final
>         Environment: EAP 7.1
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>            Priority: Blocker
>              Labels: reported-by-qe
>
> We have encountered a deadlock in business-central prohibiting EAP from stopping:
> Found one Java-level deadlock:
> =============================
> "Thread-848":
>   waiting to lock monitor 0x00007f3f8008f788 (object 0x000000008f743730, a org.kie.workbench.common.services.backend.builder.core.LRUProjectDependenciesClassLoaderCache$Proxy$_$$_WeldClientProxy),
>   which is held by "Thread-377"
> "Thread-377":
>   waiting to lock monitor 0x00007f3f80092228 (object 0x000000009579fac0, a org.drools.compiler.kie.builder.impl.KieFileSystemImpl),
>   which is held by "Thread-520"
> "Thread-520":
>   waiting to lock monitor 0x00007f3f8008f788 (object 0x000000008f743730, a org.kie.workbench.common.services.backend.builder.core.LRUProjectDependenciesClassLoaderCache$Proxy$_$$_WeldClientProxy),
>   which is held by "Thread-377"
> Please have a look at the full jstack output in the attachment.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 07:59:00 2018
From: issues at jboss.org (Nuno Godinho de Matos (JIRA))
Date: Wed, 10 Jan 2018 07:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9542) Iron JAC Amar is being told
 to create more KeyConnectionAssociation under CachedConnectionManagerImpl
 then actual JTA transactions open (Reproducible with NESTED EJB calls)
In-Reply-To: <JIRA.12720207.1510223589000@Atlassian.JIRA>
References: <JIRA.12720207.1510223589000@Atlassian.JIRA>
	<JIRA.12720207.1510223589000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720207.1510223589000.23320.1515589140276@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512442#comment-13512442 ] 

Nuno Godinho de Matos commented on WFLY-9542:
---------------------------------------------

Hi,

Is there an IRON jac Amar expert that could give some feedback on this issue?

My impression is that the right fix for this problem would be that somehow that Cached Connection manager, before creating a New Stack() it would to have context of the Transaction Id for which the new stack of connections being created is, and compare it to the transaction id associated to the already existing stack.
If the transaction ID is the same (e.g one EJB calling another EJB that has TransactionAttribute=Supports), then there is no need to create a new Stack at all. The JTA transaction context is still the same.
If the pop of a stack is being triggered, the cachec connection manager would have to, somehow, know what the JTA transaction ID context to which it is going back into is.
if the JTA Transaction ID continues to be the same, then there is no need to pop the stack.
If the JTA Transaction ID context change,s then the POP can go through.


Otherwise, perhaps what could be done as well is , just working on the POP stack logic.
The POP stack logic could take its list of connections about to disappear and keep it an local variable.
After the POP is done, it culd compare the JTA transction id of the current stack that remains open to that that it just popped.

If the transaction ids are exactly the same, it should not discar those connections but registered them on the active stack.

Something of the sort.
If think the second solution, I might be able to implement it on my own --- once I have time to dedicate to wildfly.
The first solution, I think I would need an expert on this to give me proper guidance.

Kindest regards,
And many thanks for all the help.

> Iron JAC Amar is being told to create more KeyConnectionAssociation under CachedConnectionManagerImpl then actual JTA transactions open (Reproducible with NESTED EJB calls)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9542
>                 URL: https://issues.jboss.org/browse/WFLY-9542
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Nuno Godinho de Matos
>              Labels: Arjuna, IronJacamar, JTA
>
> I have been trying to understand for what reason we sometimes are seing the exception:
> {panel}
> IJ000311: Throwable from unregister connection: java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 2021ff6.
> {panel}
> I have now created a sample application that allows the exception to be reproduced:
> https://github.com/99sono/wildlfly-ironjacamar-unregisterconnection/
> To summarize:
> If we start a JTA transaction T1 by invoking an @EJB with TransacitonAttirbute RequiresNew.
> And then this EJB calls a second EJB with TransacitonAttirbute Supports.
> Then we will have the problem that if the First JDBC access is done on the nested EJB, the connection handed over to the JPA layer (eclipselink) will be popped out of the
> org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.currentObjects
> As soon as we come out of the Nested EJB call.
> I do not know how serious this is.
> If somehow the popped out connection continues in fact locked to the ongoing JTA transaction or if might be going back to the connection pool and potentially be up for grabs.
> This I do not know how... I lack the knowledge to say how crucial it is to have a good synchrinization between the connections being managed under the:
> org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl
> And the JPA layer.
> But intuitively, I would say: quite important.
> So whenever a Stack gets popped with connections being managed, I would intuitively say: one of the parties has done something wrong. Either:
> (a) ARJUNA is asking JAC AMAR to open stacks when the JTA transaction is the same and it shouldn't, or
> (b) It does not really matter that the conneciton is popped out - somehow JAC AMAR still knows that the connection it popped out is still bound to the JTA transaction and the problem is logically strange but of low impact...
> What appears to be true, is that eclipselink is doing something logicla, in the sense that it is only asking for the conneciton to be closed/unregistered at the end of the JTA transaction.
> NOTE:
> In fact the error that we see when we get the stack trace, could also happen and no stack trance be logged by jac AMAR. 
> This is the scenario when JAC  leaves the unregister conneciton via:
> org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl would be going out via the:
> {panel}
> CopyOnWriteArrayList<ConnectionRecord> conns = cmToConnectionsMap.get(cm);
>       // Can happen if connections are "passed" between contexts
>       if (conns == null)
>          return; 
> {panel}
> But in my oppinion this exit path deserves the exact same stack trace.
> The sample application is to be found here:
> https://github.com/99sono/wildlfly-ironjacamar-unregisterconnection/
> This sample application is not as simple to deploy because one needs to hava a data source configured.
> In any case the sample application has in src/test/resources my standalone.xml.
> It should be realtively easy to fix the JDBC drivers configured in the atnadlone.xml.
> And it should be relatively simple to fix the persistence.xml to search for eclipselink in the appropriate moduel.
> I will no copy paste bellow the LOG of the exception of the sample application.
> {panel}
> 2017-11-09 10:20:00,918 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) 
> --------------------------------------
> -- STARTING TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING >: observing the CDI event StartupEventToTryToReproduceIJ000311Issue  
> --------------------------------------
> 2017-11-09 10:20:00,919 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Doing a fetch ALL query. just to bind the connection manager to the KEY of stack level 1.
> 2017-11-09 10:20:01,033 FINE  [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) Eclipselink connected (jndiName: java:/jdbc/SAMPLE_DS)- obtaining connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 1d5b3a43. Eclipselink Server session is: ServerSession(
> 	DatabaseAccessor(connected)
> 	PostgreSQLPlatform)   
> 2017-11-09 10:20:01,057 FINE  [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) EclipseLink - Closing connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 1d5b3a43
> 2017-11-09 10:20:01,063 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) At this point the org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl will have  registered on stack1 the connection used by eclipselink, and unregistered as well.
>  However, this temporary register/de-register is sufficient to add to the current key.getCMToConnectionsMap()  and entry for the JDBC connection manger.
>   This is fundamental, because without this step the exception that we will later see would be hidden away - even though the logical problem would be there no exception would be logged.  By taking this magical step here, we have ensured that we will be able to reproduce the excpetion later. 
>    To summarize what has happend so far.
>  1. We have forced eclipselink to register and unregister a connection due to are fetch id query 
>  2. The JTA transaction ID TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING >  continues healthy and running without any problem 3. Meanwhile internally, our CachedConnectionManagerImpl, for this thread, has a single task of keys in its currentObjects field 
>   4. The leading key on this stack does not hold any connectionrecords (eclipselink returned the connecton to the pool) but it does have a KEY for the JDBC connection manager 5. Point 4 is the magical step to allow us to see the stack trace but not the core of the issue - just the core of seing the stack trace 
> 2017-11-09 10:20:01,066 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) START: executoreSynchronousSameJta 
> 2017-11-09 10:20:01,066 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Right now we are within the same JTA transaction. But on a NESTED EJB call.
>   What technically has happened at this point is that IRON JAC AMAR now has a second stack (keyAssociation)
>   in the currentObjects. We add in stacks each time we go through an EJB evne if we keep the JTA transaction
>   and this is the BUG. But we will see more about this later.
>  
> 2017-11-09 10:20:01,066 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) STARTING 3: observing the CDI event StartupEventToTryToReproduceIJ000311Issue - The current transaction id is: TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING > 
> 2017-11-09 10:20:01,066 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Going to create 50 entities on the database
> 2017-11-09 10:20:01,067 FINE  [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) Eclipselink connected (jndiName: jdbc/SAMPLE_NON_JTA_DS)- obtaining connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 4be2573e. Eclipselink Server session is: ClientSession({})   
> 2017-11-09 10:20:01,073 FINE  [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) EclipseLink - Closing connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 4be2573e
> 2017-11-09 10:20:01,078 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) 50 entities should have been created: 
> 2017-11-09 10:20:01,078 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Now we want to flush - we want to force eclipselink to have to acquire the java:/jdbc/SAMPLE_DS and not be allowed to close the connection yet. 
> 2017-11-09 10:20:01,085 FINE  [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) Eclipselink connected (jndiName: java:/jdbc/SAMPLE_DS)- obtaining connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 2021ff6. Eclipselink Server session is: ClientSession({default=DatabaseAccessor(connected)})   
> 2017-11-09 10:20:01,101 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) The flush has been done. We expec that the log now shows us that java:/jdbc/SAMPLE_DS connection was acquired but not yet closed by eclipselink. 
> 2017-11-09 10:20:01,101 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) ENDING TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING >: finishing to observer. The current transaction id is: {} 
> 2017-11-09 10:20:01,101 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) OK. Now we are about to leave our nested EJB call. What is happening now is very important. 
> 1. We will leave a nested EJB call but not the JTA transaction 2. Wildfly will go to the cachedConnectonManagerImpl and tell it to pop a stack (BUG) 3. The stack that goes away is actually holding the JDBC connection thta has been given to ECLIPSELINK and thta eclipselink will later try to close 4. When we leave this call we go back to STACK 1, where no connections are being managed
> 2017-11-09 10:20:01,102 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73)  FINISH: executoreSynchronousSameJta:
>  
> 2017-11-09 10:20:01,102 WARN  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) NOW we are out of our nested EJB call. We are bout to leave the main EJB transaction call. 
> In short we are about to reproduce the stack trace. 
> What will now happen is the following. 
> 1. Wildfly will tell eclipselink that the transaction is at an end and it should commit if it can 
> 2. Eclipselink does its job of committing the changes and takes the JTA connection it was given and tries to close it 
> 3. IRON JAC AMAR will log the stack trace we wanted to reproduce saying it has not idea what connection we are trying to return to the pool. 
> 4. The reason the CachedConnectionManagerImpl does not know about the connection is because it was managed under STACK 2 but was popped out of existence after the nested transaction 
>  5. Now it is very important to keep in mind that even if we were not seing the stack trace  the error would be there (the moment we popped a key stack that had still connections) 6. Keep in mind that if we were to modify the source code  and disable our reproduceBugService.fetchAlIds() call we would see no stack trace but the same issue would be present.7. The difference that doing the reproduceBugService.fetchAlIds() does is whether or not CachedConnectionManagerImpl during unregister connection leaves via the if conns == null return null or if goes further into the if (!ignoreConnections)
>  8. OK - Now that we understand what is happening behind the scenes we can let eclipselink try to close the JDBC connection at the end of the JTA transaction
>  
> 2017-11-09 10:20:01,106 FINE  [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) EclipseLink - Closing connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 2021ff6
> 2017-11-09 10:20:01,107 INFO  [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (ServerService Thread Pool -- 73) IJ000311: Throwable from unregister connection: java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 2021ff6
> 	at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.unregisterConnection(CachedConnectionManagerImpl.java:408)
> 	at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.connectionClosed(TxConnectionListener.java:645)
> 	at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.returnHandle(BaseWrapperManagedConnection.java:596)
> 	at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:541)
> 	at org.jboss.jca.adapters.jdbc.WrappedConnection.returnConnection(WrappedConnection.java:298)
> 	at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:256)
> 	at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.closeDatasourceConnection(DatabaseAccessor.java:522)
> 	at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.closeConnection(DatasourceAccessor.java:537)
> 	at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.closeConnection(DatabaseAccessor.java:545)
> 	at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.closeJTSConnection(DatasourceAccessor.java:188)
> 	at org.eclipse.persistence.sessions.server.ClientSession.releaseJTSConnection(ClientSession.java:171)
> 	at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:175)
> 	at org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:68)
> 	at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:116)
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:368)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:349)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:241)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb$$$view9.observeStartupEventToTryToReproduceIJ000311Issue(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb$Proxy$_$$_Weld$EnterpriseProxy$.observeStartupEventToTryToReproduceIJ000311Issue(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
> 	at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129)
> 	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313)
> 	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291)
> 	at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269)
> 	at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:302)
> 	at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:291)
> 	at org.jboss.weld.event.EventImpl.fire(EventImpl.java:89)
> 	at startupconnectionproblem.event.FireStartupEventsServiceImpl.fireStartupCDIEvents(FireStartupEventsServiceImpl.java:41)
> 	at startupconnectionproblem.event.FireStartupEventsServiceImpl$Proxy$_$$_WeldClientProxy.fireStartupCDIEvents(Unknown Source)
> 	at startupconnectionproblem.event.StartupSingletonLocalEjb.postConstrcut(StartupSingletonLocalEjb.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:114)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:103)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.notSupported(LifecycleCMTTxInterceptor.java:87)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.StartupCountDownInterceptor.processInvocation(StartupCountDownInterceptor.java:25)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 2017-11-09 10:20:01,114 INFO  [startupconnectionproblem.event.FireStartupEventsServiceImpl] (ServerService Thread Pool -- 73) FIINSH: StartupEventToTryToReproduceIJ000311Issue 
> 2017-11-09 10:20:01,114 INFO  [startupconnectionproblem.event.StartupSingletonLocalEjb] (ServerService Thread Pool -- 73) ENDING 1: Post construct of startup bean singleton ending
> 2017-11-09 10:20:01,240 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 73) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '/app'
> 2017-11-09 10:20:02,098 INFO  [org.primefaces.webapp.PostConstructA
> {panel}
> Thanks for considering this issue.
> I do not know how much impact this issue can actually have.
> We have many hundred different types of JTA business transactions, and we see this sample application happening on system tests and stress tests relatively often.
> Now that I have better understand of the issue, I can in some cases rework the code to dodge this problem to avoid nested calls of EJBS on the same transaciton - but this will not always be possible.
> And I would be quite afraid of this issue, if means that our connectons still in the hands of ElcipseLInk are going back to the pool.
> This would explain some strange errors we have had only on stress test application, that we do not see when using a different app server.
> I must say it was extremelly difficult to be able to make the stack trace reproducible.
> There are many tricky points to be able to lead the code to go precisely through the code path that leads to the excpetion.
> But it is relatively trivial to make the code leave through the "silent bug iron jac amar code path".
> Many thanks for all the help on this.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 08:32:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 10 Jan 2018 08:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1485) HTTP DIGEST requires cnonce to
	be base64
In-Reply-To: <JIRA.12727316.1515591112000@Atlassian.JIRA>
References: <JIRA.12727316.1515591112000@Atlassian.JIRA>
	<JIRA.12727316.1515591112947@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727316.1515591112000.23539.1515591120463@Atlassian.JIRA>

Jan Kalina created ELY-1485:
-------------------------------

             Summary: HTTP DIGEST requires cnonce to be base64
                 Key: ELY-1485
                 URL: https://issues.jboss.org/browse/ELY-1485
             Project: WildFly Elytron
          Issue Type: Bug
          Components: HTTP
    Affects Versions: 1.2.0.Beta11
            Reporter: Jan Kalina
            Assignee: Jan Kalina


NonceManager of HTTP DIGEST mechanism requires nonce to base64 encoded value, otherwise it fails on DecodeException.

In RFC there is no requirement for client to use base64 value as cnonce. There is only recommendation for server nonce:

{panel}
nonce
      A server-specified data string which MUST be different each time a
      digest-challenge is sent as part of initial authentication.  It is
      *recommended* that this string be base64 or hexadecimal data.
{panel}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 08:40:00 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Wed, 10 Jan 2018 08:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9559) JMXPropertyEditorsTestCase
 should use 1 deployment not 40
In-Reply-To: <JIRA.12721450.1510940998000@Atlassian.JIRA>
References: <JIRA.12721450.1510940998000@Atlassian.JIRA>
	<JIRA.12721450.1510940998000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721450.1510940998000.23573.1515591600366@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9559?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges reassigned WFLY-9559:
----------------------------------

    Assignee: Yeray Borges


> JMXPropertyEditorsTestCase should use 1 deployment not 40
> ---------------------------------------------------------
>
>                 Key: WFLY-9559
>                 URL: https://issues.jboss.org/browse/WFLY-9559
>             Project: WildFly
>          Issue Type: Task
>          Components: JMX, Test Suite
>            Reporter: Brian Stansberry
>            Assignee: Yeray Borges
>            Priority: Minor
>
> JMXPropertyEditorsTestCase does 40 different deployment operations, with each identical except for changing a deployment descriptor to configure xml for 1 mbean attribute. Then the test checks that value.
> Do 1 deployment with 40 config items and then check them all. Eliminate 78 management ops (39 pairs of deploy/undeploy.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 08:57:00 2018
From: issues at jboss.org (Serg Pol (JIRA))
Date: Wed, 10 Jan 2018 08:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.23708.1515592620869@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512481#comment-13512481 ] 

Serg Pol commented on WFLY-9610:
--------------------------------

jobOperator.stop(executionId) has set BatchJobs in status STOPPING from status STARTING and after a thread became available has stopped them and set them status STOPPED.
To my sorrow these BatchJobs were really started (from status STARTING) before they were stopped!
I thought that they will not be started/called at all in this case!

> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 08:57:01 2018
From: issues at jboss.org (Serg Pol (JIRA))
Date: Wed, 10 Jan 2018 08:57:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.23717.1515592621154@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512481#comment-13512481 ] 

Serg Pol edited comment on WFLY-9610 at 1/10/18 8:56 AM:
---------------------------------------------------------

jobOperator.stop(executionId) has set BatchJobs in status STOPPING from status STARTING and after a thread became available has stopped them and set them in status STOPPED.
To my sorrow these BatchJobs were really started (from status STARTING) before they were stopped!
I thought that they will not be started/called at all in this case!


was (Author: serg_732173):
jobOperator.stop(executionId) has set BatchJobs in status STOPPING from status STARTING and after a thread became available has stopped them and set them status STOPPED.
To my sorrow these BatchJobs were really started (from status STARTING) before they were stopped!
I thought that they will not be started/called at all in this case!

> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 09:00:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 10 Jan 2018 09:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1485) HTTP DIGEST requires cnonce to
	be base64
In-Reply-To: <JIRA.12727316.1515591113000@Atlassian.JIRA>
References: <JIRA.12727316.1515591113000@Atlassian.JIRA>
	<JIRA.12727316.1515591113000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727316.1515591113000.23726.1515592800146@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1485:
----------------------------
    Labels: digest  (was: )


> HTTP DIGEST requires cnonce to be base64
> ----------------------------------------
>
>                 Key: ELY-1485
>                 URL: https://issues.jboss.org/browse/ELY-1485
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>              Labels: digest
>
> NonceManager of HTTP DIGEST mechanism requires nonce to base64 encoded value, otherwise it fails on DecodeException.
> In RFC there is no requirement for client to use base64 value as cnonce. There is only recommendation for server nonce:
> {panel}
> nonce
>       A server-specified data string which MUST be different each time a
>       digest-challenge is sent as part of initial authentication.  It is
>       *recommended* that this string be base64 or hexadecimal data.
> {panel}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 09:18:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 10 Jan 2018 09:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1485) HTTP DIGEST requires cnonce to
	be base64
In-Reply-To: <JIRA.12727316.1515591113000@Atlassian.JIRA>
References: <JIRA.12727316.1515591113000@Atlassian.JIRA>
	<JIRA.12727316.1515591113000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727316.1515591113000.23838.1515593880263@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed ELY-1485.
---------------------------
    Resolution: Rejected


Sorry, my fault, mismatched nonce and cnonce, it is required only for server nonce, which is correct.

> HTTP DIGEST requires cnonce to be base64
> ----------------------------------------
>
>                 Key: ELY-1485
>                 URL: https://issues.jboss.org/browse/ELY-1485
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>              Labels: digest
>
> NonceManager of HTTP DIGEST mechanism requires nonce to base64 encoded value, otherwise it fails on DecodeException.
> In RFC there is no requirement for client to use base64 value as cnonce. There is only recommendation for server nonce:
> {panel}
> nonce
>       A server-specified data string which MUST be different each time a
>       digest-challenge is sent as part of initial authentication.  It is
>       *recommended* that this string be base64 or hexadecimal data.
> {panel}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 09:48:00 2018
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Wed, 10 Jan 2018 09:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.24229.1515595680091@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512531#comment-13512531 ] 

Cheng Fang commented on WFLY-9610:
----------------------------------

So the batch status transition is:

STARTING -> STOPPING -> STOPPED

If the stop request is issued early enough (while the job execution is still waiting for available threads), the job execution batch status will be set to STOPPING, and from STOPPING the only outcome is STOPPED.  So how do you know "these BatchJobs were really started (from status STARTING) before they were stopped!"?  What part of the application code is executed that you don't expect them to be executed?

> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 10:29:00 2018
From: issues at jboss.org (Serg Pol (JIRA))
Date: Wed, 10 Jan 2018 10:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.24505.1515598140658@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512572#comment-13512572 ] 

Serg Pol commented on WFLY-9610:
--------------------------------

thanks
"So how do you know "these BatchJobs were really started (from status STARTING) before they were stopped!"?"
* i have log - init method of BatchJobs makes some logs (seems method open of AbstractItemReader of ChunkJob). Than BatchJobs were seems stopped. Records in StepExecutions were made and contain some info of these BatchJobs.
"What part of the application code is executed that you don't expect them to be executed?"
* i don't follow question. i thought if BatchJobs are in status - STOPPING (after STARTING)  than these BatchJobs will not be started at all! DB tables contained just status STARTING not STOPPING till free available Thread (at the end status STOPPED was set in DB)! Status STOPPING can be perhaps lost in this case because it was not saved yet in db if server will be sudenly shutdown.

> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 10:29:01 2018
From: issues at jboss.org (Serg Pol (JIRA))
Date: Wed, 10 Jan 2018 10:29:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.24512.1515598141303@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512572#comment-13512572 ] 

Serg Pol edited comment on WFLY-9610 at 1/10/18 10:28 AM:
----------------------------------------------------------

thanks
"So how do you know "these BatchJobs were really started (from status STARTING) before they were stopped!"?"
* i have log - init method of BatchJobs makes some logs (seems method open of AbstractItemReader of ChunkJob). Than BatchJobs were seems stopped. Records in StepExecutions were made and contain some info of these BatchJobs.
"What part of the application code is executed that you don't expect them to be executed?"

* i don't follow question. i thought if BatchJobs are in status - STOPPING (after STARTING)  than these BatchJobs will not be started at all! DB tables contained just status STARTING not STOPPING till free available Thread (at the end status STOPPED was set in DB)! Status STOPPING can be perhaps lost in this case because it was not saved yet in db if server will be sudenly shutdown.


was (Author: serg_732173):
thanks
"So how do you know "these BatchJobs were really started (from status STARTING) before they were stopped!"?"
* i have log - init method of BatchJobs makes some logs (seems method open of AbstractItemReader of ChunkJob). Than BatchJobs were seems stopped. Records in StepExecutions were made and contain some info of these BatchJobs.
"What part of the application code is executed that you don't expect them to be executed?"
* i don't follow question. i thought if BatchJobs are in status - STOPPING (after STARTING)  than these BatchJobs will not be started at all! DB tables contained just status STARTING not STOPPING till free available Thread (at the end status STOPPED was set in DB)! Status STOPPING can be perhaps lost in this case because it was not saved yet in db if server will be sudenly shutdown.

> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 10:30:00 2018
From: issues at jboss.org (Serg Pol (JIRA))
Date: Wed, 10 Jan 2018 10:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.24522.1515598200539@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512572#comment-13512572 ] 

Serg Pol edited comment on WFLY-9610 at 1/10/18 10:29 AM:
----------------------------------------------------------

thanks
"So how do you know "these BatchJobs were really started (from status STARTING) before they were stopped!"?"
- i have log - init method of BatchJobs makes some logs (seems method open of AbstractItemReader of ChunkJob). Than BatchJobs were seems stopped. Records in StepExecutions were made and contain some info of these BatchJobs.

"What part of the application code is executed that you don't expect them to be executed?"
- i don't follow question. i thought if BatchJobs are in status - STOPPING (after STARTING)  than these BatchJobs will not be started at all! DB tables contained just status STARTING not STOPPING till free available Thread (at the end status STOPPED was set in DB)! Status STOPPING can be perhaps lost in this case because it was not saved yet in db if server will be sudenly shutdown.


was (Author: serg_732173):
thanks
"So how do you know "these BatchJobs were really started (from status STARTING) before they were stopped!"?"
* i have log - init method of BatchJobs makes some logs (seems method open of AbstractItemReader of ChunkJob). Than BatchJobs were seems stopped. Records in StepExecutions were made and contain some info of these BatchJobs.
"What part of the application code is executed that you don't expect them to be executed?"

* i don't follow question. i thought if BatchJobs are in status - STOPPING (after STARTING)  than these BatchJobs will not be started at all! DB tables contained just status STARTING not STOPPING till free available Thread (at the end status STOPPED was set in DB)! Status STOPPING can be perhaps lost in this case because it was not saved yet in db if server will be sudenly shutdown.

> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 10:59:00 2018
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Wed, 10 Jan 2018 10:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest
 fails on IBM JDK
In-Reply-To: <JIRA.12702872.1500553419000@Atlassian.JIRA>
References: <JIRA.12702872.1500553419000@Atlassian.JIRA>
	<JIRA.12702872.1500553419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702872.1500553419000.24920.1515599940373@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512610#comment-13512610 ] 

Peter Skopek commented on ELY-1295:
-----------------------------------

It is OK to ignore this. There is a way to setup external storage encrypted with proper SecretKey from supported keystore (JCEKS).

> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
>                 Key: ELY-1295
>                 URL: https://issues.jboss.org/browse/ELY-1295
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Peter Palaga
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: ibm-java
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>  
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>  
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> 	at java.lang.Class.forNameImpl(Native Method)
> 	at java.lang.Class.forName(Class.java:278)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	at java.security.KeyStore.getEntry(KeyStore.java:1532)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> 	... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/72967600a98dee832e151ff8f6fb64af0a84bd14#diff-faa6b27609575ef29472bcc75c87eb36R87



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 11:09:00 2018
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Wed, 10 Jan 2018 11:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.25003.1515600540618@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512617#comment-13512617 ] 

Cheng Fang commented on WFLY-9610:
----------------------------------

this will be fixed to ensure a complete stop.  See [JBERET-377|https://issues.jboss.org/browse/JBERET-377]  Stop job execution with STARTING status before it's actually started

> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 11:52:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 10 Jan 2018 11:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1369) FIPS mode,
 Elytron HTTP DIGEST authentication mechanism not fips compliant
In-Reply-To: <JIRA.12712431.1505900284000@Atlassian.JIRA>
References: <JIRA.12712431.1505900284000@Atlassian.JIRA>
	<JIRA.12712431.1505900284000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712431.1505900284000.25422.1515603120122@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512658#comment-13512658 ] 

Martin Choma commented on ELY-1369:
-----------------------------------

Curl has [1]. There is some long-termly proposed patch for Firefox. But yes this does not seem as priority for browser.  Still there can be some in future.
 
[1] https://github.com/curl/curl/pull/1934
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=472823

> FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant
> --------------------------------------------------------------------------
>
>                 Key: ELY-1369
>                 URL: https://issues.jboss.org/browse/ELY-1369
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.2.0.Beta3
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta11
>
>
> Elytron HTTP DIGEST authentication comply to rfc2617 - which means MD5 is used by default (it means it is hardcode, with no way to configure another hash algorithm). But MD5 could make troubles in fips environment [5].
> {code:java|title=DigestAuthenticationMechanism.java}
>         String algorithm = convertToken(ALGORITHM, responseTokens.get(ALGORITHM));
>         if (MD5.equals(algorithm) == false) {
>             throw log.mechUnsupportedAlgorithm(getMechanismName(), algorithm);
>         }
> {code}
> There exists proposed rfc7616 which makes algorithm configurable, work on new DIGEST features are covered by [1]. [~dlofthouse] is it planned for [1] to target 7.1? 
> [1] https://issues.jboss.org/browse/ELY-286
> [2] https://developer.jboss.org/wiki/ElytronHTTPDigestNonceHandling-Design
> [3] https://tools.ietf.org/html/rfc2617
> [4] https://tools.ietf.org/html/rfc7616
> [5] https://access.redhat.com/support/cases/#/case/01761455



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 11:58:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Wed, 10 Jan 2018 11:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1369) FIPS mode,
 Elytron HTTP DIGEST authentication mechanism not fips compliant
In-Reply-To: <JIRA.12712431.1505900284000@Atlassian.JIRA>
References: <JIRA.12712431.1505900284000@Atlassian.JIRA>
	<JIRA.12712431.1505900284000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712431.1505900284000.25494.1515603480850@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512658#comment-13512658 ] 

Martin Choma edited comment on ELY-1369 at 1/10/18 11:57 AM:
-------------------------------------------------------------

Curl has [1]. There is some long-termly proposed patch for Firefox [2]. Customer using Python script - found one PR from Python world [3]. But yes this does not seem as priority for clients.  Still there can be some in future.
 
[1] https://github.com/curl/curl/pull/1934
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=472823
[3] https://github.com/httplib2/httplib2/pull/23


was (Author: mchoma):
Curl has [1]. There is some long-termly proposed patch for Firefox. But yes this does not seem as priority for browser.  Still there can be some in future.
 
[1] https://github.com/curl/curl/pull/1934
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=472823

> FIPS mode, Elytron HTTP DIGEST authentication mechanism not fips compliant
> --------------------------------------------------------------------------
>
>                 Key: ELY-1369
>                 URL: https://issues.jboss.org/browse/ELY-1369
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.2.0.Beta3
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta11
>
>
> Elytron HTTP DIGEST authentication comply to rfc2617 - which means MD5 is used by default (it means it is hardcode, with no way to configure another hash algorithm). But MD5 could make troubles in fips environment [5].
> {code:java|title=DigestAuthenticationMechanism.java}
>         String algorithm = convertToken(ALGORITHM, responseTokens.get(ALGORITHM));
>         if (MD5.equals(algorithm) == false) {
>             throw log.mechUnsupportedAlgorithm(getMechanismName(), algorithm);
>         }
> {code}
> There exists proposed rfc7616 which makes algorithm configurable, work on new DIGEST features are covered by [1]. [~dlofthouse] is it planned for [1] to target 7.1? 
> [1] https://issues.jboss.org/browse/ELY-286
> [2] https://developer.jboss.org/wiki/ElytronHTTPDigestNonceHandling-Design
> [3] https://tools.ietf.org/html/rfc2617
> [4] https://tools.ietf.org/html/rfc7616
> [5] https://access.redhat.com/support/cases/#/case/01761455



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 12:15:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 10 Jan 2018 12:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.25610.1515604500348@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2194:
--------------------------------
    Sprint: 2018 Week 01-02


> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>         Attachments: DroolsDynamicReload.zip
>
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 12:16:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 10 Jan 2018 12:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.25614.1515604560522@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-2194.
---------------------------------
    Resolution: Done


Fixed by https://github.com/kiegroup/drools/commit/377c580932f27df0ea787d1edac4c6cc2c0add8f

> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>         Attachments: DroolsDynamicReload.zip
>
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 12:35:00 2018
From: issues at jboss.org (Pedro Almeida (JIRA))
Date: Wed, 10 Jan 2018 12:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.25694.1515605700162@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512688#comment-13512688 ] 

Pedro Almeida commented on DROOLS-2194:
---------------------------------------

[~mfusco], thanks for the quick fix. 
Are you by any chance releasing a patch with this fix soon ?

Thanks.


> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>         Attachments: DroolsDynamicReload.zip
>
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 12:40:00 2018
From: issues at jboss.org (Pedro Almeida (JIRA))
Date: Wed, 10 Jan 2018 12:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.25705.1515606000426@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13512688#comment-13512688 ] 

Pedro Almeida edited comment on DROOLS-2194 at 1/10/18 12:39 PM:
-----------------------------------------------------------------

[~mfusco], thanks for the quick reply. 
Are you by any chance releasing a patch with this fix soon ?

Thanks.



was (Author: littlemustard):
[~mfusco], thanks for the quick fix. 
Are you by any chance releasing a patch with this fix soon ?

Thanks.


> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>         Attachments: DroolsDynamicReload.zip
>
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 14:14:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Wed, 10 Jan 2018 14:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.27110.1515611640589@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli updated DROOLS-2194:
----------------------------------
    Fix Version/s: 7.6.0.Final


> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>             Fix For: 7.6.0.Final
>
>         Attachments: DroolsDynamicReload.zip
>
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 14:15:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Wed, 10 Jan 2018 14:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2194) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12725789.1513795667000@Atlassian.JIRA>
References: <JIRA.12725789.1513795667000@Atlassian.JIRA>
	<JIRA.12725789.1513795667000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725789.1513795667000.27125.1515611700718@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2194?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513072#comment-13513072 ] 

Edson Tirelli commented on DROOLS-2194:
---------------------------------------

[~littlemustard] the next release (7.6.0) is currently scheduled for mid-february. 

> ClassCastException after kiescanner scanNow() method
> ----------------------------------------------------
>
>                 Key: DROOLS-2194
>                 URL: https://issues.jboss.org/browse/DROOLS-2194
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Pedro Almeida
>            Assignee: Mario Fusco
>             Fix For: 7.6.0.Final
>
>         Attachments: DroolsDynamicReload.zip
>
>
> I need to add and remove rules in runtime, without losing facts. 
> I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
> The scanner is attached and the scanNow() method is invoked whenever a change occurs.
> But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:
> 18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
> 	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
> 	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
> 	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
> 	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
> 	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
> 	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
> 	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
> 	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
> 	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
> 	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
> 	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
> 	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
> 	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
> 	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
> 	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
> 	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
> 	... 182 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 14:16:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Wed, 10 Jan 2018 14:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2231) ClassCastException after
 kiescanner scanNow() method
In-Reply-To: <JIRA.12727406.1515611756000@Atlassian.JIRA>
References: <JIRA.12727406.1515611756000@Atlassian.JIRA>
	<JIRA.12727406.1515611756147@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727406.1515611756000.27136.1515611760798@Atlassian.JIRA>

Edson Tirelli created DROOLS-2231:
-------------------------------------

             Summary: ClassCastException after kiescanner scanNow() method
                 Key: DROOLS-2231
                 URL: https://issues.jboss.org/browse/DROOLS-2231
             Project: Drools
          Issue Type: Bug
    Affects Versions: 7.5.0.Final
            Reporter: Pedro Almeida
            Assignee: Mario Fusco
             Fix For: 7.6.0.Final


I need to add and remove rules in runtime, without losing facts. 
I'm achieving this by manipulating a kJar on my .m2 folder by adding and removing rules.
The scanner is attached and the scanNow() method is invoked whenever a change occurs.
But whenever I load a rule back (say on rule YYY), I get errors on (XXX), seems like it has to do with accumulates and can occur on various rules, something like:

18:13:15,354 SEVERE [org.rule.package.core.DroolsEJB] (default task-30) Error executing fireAllRules(): java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0: java.lang.RuntimeException: java.lang.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:106)
	at org.drools.core.phreak.PhreakAccumulateNode.addMatch(PhreakAccumulateNode.java:750)
	at org.drools.core.phreak.PhreakAccumulateNode.doRightInserts(PhreakAccumulateNode.java:230)
	at org.drools.core.phreak.PhreakAccumulateNode.doNode(PhreakAccumulateNode.java:85)
	at org.drools.core.phreak.RuleNetworkEvaluator.switchOnDoBetaNode(RuleNetworkEvaluator.java:567)
	at org.drools.core.phreak.RuleNetworkEvaluator.evalBetaNode(RuleNetworkEvaluator.java:538)
	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:373)
	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:636)
	at org.drools.core.phreak.AddRemoveRule.flushLeftTupleIfNecessary(AddRemoveRule.java:609)
	at org.drools.core.reteoo.BetaNode.assertObject(BetaNode.java:313)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
	at org.drools.core.reteoo.SingleObjectSinkAdapter.propagateAssertObject(SingleObjectSinkAdapter.java:70)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:142)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:367)
	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1051)
	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014)
	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1295)
	at org.rule.package.core.DroolsEJB.fireAllRules(DroolsEJB.java:263)
	at org.rule.package.core.DroolsEJB.insertEvent(DroolsEJB.java:244)
	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.singleton.SingletonComponentInstanceAssociationInterceptor.processInvocation(SingletonComponentInstanceAssociationInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInCallerTx(CMTTxInterceptor.java:254)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:329)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
	at org.rule.package.core.DroolsEJB$$$view12.insertEvent(Unknown Source)
	at sun.reflect.GeneratedMethodAccessor97.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
	at org.rule.package.core.DroolsEJB$Proxy$_$$_Weld$EnterpriseProxy$.insertEvent(Unknown Source)
	at org.rule.package.core.EventCorrelationServiceEJB.insertEvent(EventCorrelationServiceEJB.java:24)
	at sun.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.pool.PooledInstanceInterceptor.processInvocation(PooledInstanceInterceptor.java:51)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.remote.EJBRemoteTransactionPropagatingInterceptor.processInvocation(EJBRemoteTransactionPropagatingInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.deployment.processors.EjbSuspendInterceptor.processInvocation(EjbSuspendInterceptor.java:53)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.invokeMethod(MethodInvocationMessageHandler.java:327)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.access$100(MethodInvocationMessageHandler.java:67)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler$1.run(MethodInvocationMessageHandler.java:200)
	at org.jboss.as.ejb3.remote.protocol.versionone.MethodInvocationMessageHandler.processMessage(MethodInvocationMessageHandler.java:262)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.processMessage(VersionOneProtocolChannelReceiver.java:213)
	at org.jboss.as.ejb3.remote.protocol.versiontwo.VersionTwoProtocolChannelReceiver.processMessage(VersionTwoProtocolChannelReceiver.java:76)
	at org.jboss.as.ejb3.remote.protocol.versionone.VersionOneProtocolChannelReceiver.handleMessage(VersionOneProtocolChannelReceiver.java:159)
	at org.jboss.remoting3.remote.RemoteConnectionChannel$5.run(RemoteConnectionChannel.java:456)
	at org.jboss.remoting3.EndpointImpl$TrackingExecutor$1.run(EndpointImpl.java:731)
	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.ClassCastException: org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0 cannot be cast to org.rule.package.Rule_XXX_$u40$Start$u41$1698483954$Accumulate0
	at org.rule.package.Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.accumulate(Rule_XXX_$u40$Start$u41$1698483954Accumulate0Invoker.java:46)
	at org.drools.core.rule.SingleAccumulate.accumulate(SingleAccumulate.java:98)
	... 182 more




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 14:17:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 10 Jan 2018 14:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-133) Use StackWalker to get
 extended log record information
In-Reply-To: <JIRA.12615826.1461090161000@Atlassian.JIRA>
References: <JIRA.12615826.1461090161000@Atlassian.JIRA>
	<JIRA.12615826.1461090161000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12615826.1461090161000.27141.1515611820258@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGMGR-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513074#comment-13513074 ] 

David Lloyd commented on LOGMGR-133:
------------------------------------

This needs a (beta) tag before I can introduce the Java 9 supplement part.

> Use StackWalker to get extended log record information
> ------------------------------------------------------
>
>                 Key: LOGMGR-133
>                 URL: https://issues.jboss.org/browse/LOGMGR-133
>             Project: JBoss Log Manager
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>             Fix For: 2.1.0.Alpha6
>
>
> Under Java 9, you can use a StackWalker to efficiently traverse the stack and return information about callers.  Using this mechanism should be substantially better-performing than snapshotting the stack to acquire the calling class information for the extended log record class.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 14:26:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 10 Jan 2018 14:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-133) Use StackWalker to get
 extended log record information
In-Reply-To: <JIRA.12615826.1461090161000@Atlassian.JIRA>
References: <JIRA.12615826.1461090161000@Atlassian.JIRA>
	<JIRA.12615826.1461090161000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12615826.1461090161000.27244.1515612360300@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGMGR-133?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513080#comment-13513080 ] 

James Perkins commented on LOGMGR-133:
--------------------------------------

I'll try to get one out soon. I was hoping to get the delayed handler in, which I think is pretty much ready at this point. The only change I need to make is with the configuration API to allow properties not to be persisted to the {{logging.properties}} file.

> Use StackWalker to get extended log record information
> ------------------------------------------------------
>
>                 Key: LOGMGR-133
>                 URL: https://issues.jboss.org/browse/LOGMGR-133
>             Project: JBoss Log Manager
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>             Fix For: 2.1.0.Alpha6
>
>
> Under Java 9, you can use a StackWalker to efficiently traverse the stack and return information about callers.  Using this mechanism should be substantially better-performing than snapshotting the stack to acquire the calling class information for the extended log record class.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 14:28:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 10 Jan 2018 14:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-131) Add format characters for
 module name, module version
In-Reply-To: <JIRA.12615824.1461089999000@Atlassian.JIRA>
References: <JIRA.12615824.1461089999000@Atlassian.JIRA>
	<JIRA.12615824.1461089999000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12615824.1461089999000.27248.1515612480353@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-131?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned LOGMGR-131:
----------------------------------

      Assignee: David Lloyd
    Resolution: Done


> Add format characters for module name, module version
> -----------------------------------------------------
>
>                 Key: LOGMGR-131
>                 URL: https://issues.jboss.org/browse/LOGMGR-131
>             Project: JBoss Log Manager
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 2.1.0.Alpha6
>
>
> In JDK9, StackTraceElements contain moduleName and moduleVersion fields.  This information is useful for debugging purposes, thus format characters should be allocated towards these values.  Ideally it'll be something non-conflicting with respect to log4j and other common ancestor/related frameworks, but that is less important than the basic support.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 14:29:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 10 Jan 2018 14:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-184) Wrong values for unknown
	method/class
In-Reply-To: <JIRA.12723556.1512486366000@Atlassian.JIRA>
References: <JIRA.12723556.1512486366000@Atlassian.JIRA>
	<JIRA.12723556.1512486366000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723556.1512486366000.27265.1515612540282@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved LOGMGR-184.
--------------------------------
    Fix Version/s: 2.1.0.Alpha6
       Resolution: Done


> Wrong values for unknown method/class
> -------------------------------------
>
>                 Key: LOGMGR-184
>                 URL: https://issues.jboss.org/browse/LOGMGR-184
>             Project: JBoss Log Manager
>          Issue Type: Bug
>          Components: core
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 2.1.0.Alpha6
>
>
> Unknown method/class in ExtLogRecord use a value of "<unknown>", but the LogRecord spec says that {{null}} should be used.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 10 14:47:00 2018
From: issues at jboss.org (=?UTF-8?Q?Roger_Mart=C3=ADnez_=28JIRA=29?=)
Date: Wed, 10 Jan 2018 14:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1937) [DMN Editor] Dynamic Form
 Properties with nested hierarchy binds to wrong object/widget
In-Reply-To: <JIRA.12699176.1498471606000@Atlassian.JIRA>
References: <JIRA.12699176.1498471606000@Atlassian.JIRA>
	<JIRA.12699176.1498471606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12699176.1498471606000.27316.1515613620167@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513087#comment-13513087 ] 

Roger Mart?nez commented on DROOLS-1937:
----------------------------------------

[~manstis] Moving this ticket on top of backlog in order to address it ASAP, it now appears on the Stunner board.

> [DMN Editor] Dynamic Form Properties with nested hierarchy binds to wrong object/widget
> ---------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1937
>                 URL: https://issues.jboss.org/browse/DROOLS-1937
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Roger Mart?nez
>            Priority: Critical
>              Labels: Stunner
>
> The Dynamic Form generated from a nested object hierarchy binds objects/widgets to the incorrect instances. For example; the below classes define an {{Id}} form field that is used in both {{InputData}} (through inheritance) and {{InformationItem}} (through sub-form reference and inheritance). When changing the {{Id}} field (for example) in the {{InputData}} form property the "Id" value of the nested "Information Item" is updated.
> {code}
> public abstract class DMNModelInstrumentedBase implements DMNDefinition {
>  
>     //No @FormFields etc
>  
> }
>  
> public abstract class DMNElement extends DMNModelInstrumentedBase {
>  
>     @Property
>     @FormField
>     protected Id id;
>  
>     @Property
>     @FormField(afterElement = "id")
>     protected Label label;
>  
>     @Property
>     @FormField(afterElement = "label")
>     protected Description description;
>  
>     ....
> }
>  
> public abstract class NamedElement extends DMNElement {
>  
>     @Property
>     @FormField(afterElement = "description")
>     protected Name name;
>  
>     ....
> }
>  
> @FormDefinition(policy = FieldPolicy.ONLY_MARKED)
> public class InformationItem extends NamedElement implements DMNPropertySet {
>  
>     @Property
>     @FormField(afterElement = "name")
>     protected QName typeRef;
>  
>     ....
> }
> public abstract class DRGElement extends NamedElement {}
> @FormDefinition(policy = FieldPolicy.ONLY_MARKED)
> public class InputData extends DRGElement {
>     ...
>     @PropertySet
>     @FormField(afterElement = "name")
>     protected InformationItem variable;
>     ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 10 14:49:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 10 Jan 2018 14:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1937) [DMN Editor] Dynamic Form
 Properties with nested hierarchy binds to wrong object/widget
In-Reply-To: <JIRA.12699176.1498471606000@Atlassian.JIRA>
References: <JIRA.12699176.1498471606000@Atlassian.JIRA>
	<JIRA.12699176.1498471606000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12699176.1498471606000.27320.1515613740152@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513088#comment-13513088 ] 

Michael Anstis commented on DROOLS-1937:
----------------------------------------

[~roger600] <3

> [DMN Editor] Dynamic Form Properties with nested hierarchy binds to wrong object/widget
> ---------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1937
>                 URL: https://issues.jboss.org/browse/DROOLS-1937
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Roger Mart?nez
>            Priority: Critical
>              Labels: Stunner
>
> The Dynamic Form generated from a nested object hierarchy binds objects/widgets to the incorrect instances. For example; the below classes define an {{Id}} form field that is used in both {{InputData}} (through inheritance) and {{InformationItem}} (through sub-form reference and inheritance). When changing the {{Id}} field (for example) in the {{InputData}} form property the "Id" value of the nested "Information Item" is updated.
> {code}
> public abstract class DMNModelInstrumentedBase implements DMNDefinition {
>  
>     //No @FormFields etc
>  
> }
>  
> public abstract class DMNElement extends DMNModelInstrumentedBase {
>  
>     @Property
>     @FormField
>     protected Id id;
>  
>     @Property
>     @FormField(afterElement = "id")
>     protected Label label;
>  
>     @Property
>     @FormField(afterElement = "label")
>     protected Description description;
>  
>     ....
> }
>  
> public abstract class NamedElement extends DMNElement {
>  
>     @Property
>     @FormField(afterElement = "description")
>     protected Name name;
>  
>     ....
> }
>  
> @FormDefinition(policy = FieldPolicy.ONLY_MARKED)
> public class InformationItem extends NamedElement implements DMNPropertySet {
>  
>     @Property
>     @FormField(afterElement = "name")
>     protected QName typeRef;
>  
>     ....
> }
> public abstract class DRGElement extends NamedElement {}
> @FormDefinition(policy = FieldPolicy.ONLY_MARKED)
> public class InputData extends DRGElement {
>     ...
>     @PropertySet
>     @FormField(afterElement = "name")
>     protected InformationItem variable;
>     ...
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 10 22:13:01 2018
From: issues at jboss.org (=?UTF-8?B?0KPRg9Cz0LDQvSDQnNGN0L3QtNCx0LDRj9GAIChKSVJBKQ==?=)
Date: Wed, 10 Jan 2018 22:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3858) Infinispan cache
 configuration is not always applied to security-domain
In-Reply-To: <JIRA.12552308.1410873338000@Atlassian.JIRA>
References: <JIRA.12552308.1410873338000@Atlassian.JIRA>
	<JIRA.12552308.1410873338000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12552308.1410873338000.28031.1515640381101@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513160#comment-13513160 ] 

????? ???????? commented on WFLY-3858:
--------------------------------------

infinispan ver.: 9.1.4.Final
wildfly ver. : 10

But infinispan still doesn't fire expire event sometimes. It works normally when we cleared cache, but after few events it doesn't fire expire event only after cache.get or cache.size method. Any suggestions? How to avoid that situation?

> Infinispan cache configuration is not always applied to security-domain
> -----------------------------------------------------------------------
>
>                 Key: WFLY-3858
>                 URL: https://issues.jboss.org/browse/WFLY-3858
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 8.1.0.Final
>            Reporter: Robert Tuck
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Alpha1
>
>         Attachments: debugger output.txt
>
>
> On Wildfly 8.1.0.Final, I have the following standalone-ha.xml:
>         <subsystem xmlns="urn:jboss:domain:infinispan:2.0">
> ...
>             <cache-container name="security" default-cache="auth-cache" start="EAGER">
>                 <transport cluster="${cluster.name}_SEC" lock-timeout="60000"/>
>                 <replicated-cache name="auth-cache" batching="true" mode="ASYNC">
>                     <eviction strategy="LRU" max-entries="10000"/>
>                     <expiration lifespan="60000"/>
>                 </replicated-cache>
>             </cache-container>
> </subsystem>
> ...
>         <subsystem xmlns="urn:jboss:domain:security:1.2">
> <security-domains>
> ...
>                 <security-domain name="OAuth-Consumer" cache-type="infinispan">
>                     <authentication>
>                         <login-module code="com.idbs.ewb.server.auth.module.OAuthConsumerLoginModule" flag="sufficient"
>                                       module="deployment.ewb-server-ear.ear">
>                             <module-option name="allowedConsumerAuthFailures" value="-1"/>
>                             <module-option name="consumerLoginFailureTimeoutMs" value="3000"/>
>                         </login-module>
>                     </authentication>
>                 </security-domain>
> </security-domains>
> </subsystem>
> After startup the OAuth-Consumer security domain cache "auth-cache" is not always configured with the specified settings (~50% of the time). This can be verified by monitoring the jboss.infinispan nodes with JConsole and retrieving the cache settings, and tracking the cache hits during logins. This shows that succesful logins are cached but do not expire after the expected 60s, and that the expiration lifespan is set to -1 rather than 60000, as are eviction max entries.
> After some debugging I have narrowed down the problem to some code that gets called from inside org.jboss.as.security.plugins.JNDIBasedSecurityManagement:
>    public SecurityDomainContext createSecurityDomainContext(String securityDomain, Object cacheFactory) throws Exception {
>         log.debugf("Creating SDC for domain=" + securityDomain);
>         AuthenticationManager am = createAuthenticationManager(securityDomain);
>         // create authentication cache
>         if (cacheFactory instanceof EmbeddedCacheManager) {
>             EmbeddedCacheManager cacheManager = EmbeddedCacheManager.class.cast(cacheFactory);
>             @SuppressWarnings("rawtypes")
>             Cache cache = null;
>             if (cacheManager != null) {
>                 // TODO override global settings with security domain specific
>                 ConfigurationBuilder builder = new ConfigurationBuilder();
>                 Configuration baseCfg = cacheManager.getCacheConfiguration("auth-cache");
> ^^^^ This call here doesn?t always return the correct configuration, baseCfg is then null.
>                 if (baseCfg != null) {
>                     builder.read(baseCfg);
>                 }
>                 cacheManager.defineConfiguration(securityDomain, builder.build());
>                 cache = cacheManager.getCache(securityDomain);
>             }
>             if (cache != null && am instanceof CacheableManager) {
>                 @SuppressWarnings({ "unchecked", "rawtypes" })
>                 CacheableManager<Map, Principal> cm = (CacheableManager<Map, Principal>) am;
>                 cm.setCache(cache);
>             }
>         } else if (cacheFactory instanceof DefaultAuthenticationCacheFactory) {
> <?>
> }
> getCacheConfiguration(String) is implemented inside org.infinispan.manager.DefaultCacheManager:
>    @Override
>    public Configuration getCacheConfiguration(String name) {
>       Configuration configuration = configurationOverrides.get(name);
>      if (configuration == null && cacheExists(name)) {
>          return defaultConfiguration;
>       }
>       return configuration;
>    }
> Seems like the condition configuration == null occurs when the cache doesn?t exist, therefore it returns null. This appears to be a race condition between this code and where it gets registered in wireAndStartCache(String).
>  



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 11 00:27:01 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Thu, 11 Jan 2018 00:27:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9502)
 javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name
 "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
In-Reply-To: <JIRA.12718725.1509442317000@Atlassian.JIRA>
References: <JIRA.12718725.1509442317000@Atlassian.JIRA>
	<JIRA.12718725.1509442317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718725.1509442317000.28143.1515648421510@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao updated WFLY-9502:
--------------------------
    Labels: downstream_dependency  (was: )


> javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9502
>                 URL: https://issues.jboss.org/browse/WFLY-9502
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Naming
>    Affects Versions: 11.0.0.Final
>            Reporter: Martin ?vehla
>            Assignee: Martyn Taylor
>            Priority: Critical
>              Labels: downstream_dependency
>
> When I create jms bridge on EAP7 that tries to connect to EAP6, it throws following issue when trying to do remote lookup for connection factory or destination on EAP6.
> {code}
> 2017-10-31 09:44:18,769 WARN  [org.apache.activemq.artemis.jms.bridge] (Thread-102) AMQ342010: Failed to connect JMS Bridge N/A: javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null"
> 	at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
> 	at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:46)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:32)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1072)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1247)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2600(JMSBridgeImpl.java:75)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1747)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {\code}
> When debugging I noticed that WildFlyRootContext.getProviderContext there's no NamingProviderFactory available to resolve the name, so I think the error message is just a consequence of that.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 11 02:00:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 11 Jan 2018 02:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2232) Increase coverage
 org.kie.workbench.common.dmn.client.editors.expressions.types.literal
In-Reply-To: <JIRA.12727431.1515653985000@Atlassian.JIRA>
References: <JIRA.12727431.1515653985000@Atlassian.JIRA>
	<JIRA.12727431.1515653985488@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727431.1515653985000.28268.1515654000274@Atlassian.JIRA>

Jozef Marko created DROOLS-2232:
-----------------------------------

             Summary: Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
                 Key: DROOLS-2232
                 URL: https://issues.jboss.org/browse/DROOLS-2232
             Project: Drools
          Issue Type: Task
          Components: DMN Editor
            Reporter: Jozef Marko
            Assignee: Jozef Marko
         Attachments: index.html

The actual coverage form the attachment should be increased.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 02:04:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 11 Jan 2018 02:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2232) Increase coverage
 org.kie.workbench.common.dmn.client.editors.expressions.types.literal
In-Reply-To: <JIRA.12727431.1515653985000@Atlassian.JIRA>
References: <JIRA.12727431.1515653985000@Atlassian.JIRA>
	<JIRA.12727431.1515653985000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727431.1515653985000.28278.1515654240067@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2232:
--------------------------------
    Description: 
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- LiteralExpressionEditorDefinition
- LiteralExpressionColumnHeaderMetaData
- LiteralExpressionGridRenderer

  was:The actual coverage form the attachment should be increased.



> Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
> ---------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2232
>                 URL: https://issues.jboss.org/browse/DROOLS-2232
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>         Attachments: index.html
>
>
> The actual coverage form the attachment should be increased.
> - LiteralExpressionGrid
> - LiteralExpressionColumnRenderer
> - LiteralExpressionUIModelMapper
> - LiteralExpressionEditorDefinition
> - LiteralExpressionColumnHeaderMetaData
> - LiteralExpressionGridRenderer



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 02:05:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 11 Jan 2018 02:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2232) Increase coverage
 org.kie.workbench.common.dmn.client.editors.expressions.types.literal
In-Reply-To: <JIRA.12727431.1515653985000@Atlassian.JIRA>
References: <JIRA.12727431.1515653985000@Atlassian.JIRA>
	<JIRA.12727431.1515653985000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727431.1515653985000.28280.1515654300052@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2232:
--------------------------------
    Description: 
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- LiteralExpressionEditorDefinition
- LiteralExpressionColumnHeaderMetaData
- -LiteralExpressionGridRenderer- - just extends another class

  was:
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- LiteralExpressionEditorDefinition
- LiteralExpressionColumnHeaderMetaData
- LiteralExpressionGridRenderer



> Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
> ---------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2232
>                 URL: https://issues.jboss.org/browse/DROOLS-2232
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>         Attachments: index.html
>
>
> The actual coverage form the attachment should be increased.
> - LiteralExpressionGrid
> - LiteralExpressionColumnRenderer
> - LiteralExpressionUIModelMapper
> - LiteralExpressionEditorDefinition
> - LiteralExpressionColumnHeaderMetaData
> - -LiteralExpressionGridRenderer- - just extends another class



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 02:06:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 11 Jan 2018 02:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2232) Increase coverage
 org.kie.workbench.common.dmn.client.editors.expressions.types.literal
In-Reply-To: <JIRA.12727431.1515653985000@Atlassian.JIRA>
References: <JIRA.12727431.1515653985000@Atlassian.JIRA>
	<JIRA.12727431.1515653985000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727431.1515653985000.28282.1515654360054@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2232:
--------------------------------
    Description: 
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- LiteralExpressionEditorDefinition
- -LiteralExpressionColumnHeaderMetaData- - just extends another class
- -LiteralExpressionGridRenderer- - just extends another class

  was:
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- LiteralExpressionEditorDefinition
- LiteralExpressionColumnHeaderMetaData
- -LiteralExpressionGridRenderer- - just extends another class



> Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
> ---------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2232
>                 URL: https://issues.jboss.org/browse/DROOLS-2232
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>         Attachments: index.html
>
>
> The actual coverage form the attachment should be increased.
> - LiteralExpressionGrid
> - LiteralExpressionColumnRenderer
> - LiteralExpressionUIModelMapper
> - LiteralExpressionEditorDefinition
> - -LiteralExpressionColumnHeaderMetaData- - just extends another class
> - -LiteralExpressionGridRenderer- - just extends another class



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 02:07:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 11 Jan 2018 02:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2232) Increase coverage
 org.kie.workbench.common.dmn.client.editors.expressions.types.literal
In-Reply-To: <JIRA.12727431.1515653985000@Atlassian.JIRA>
References: <JIRA.12727431.1515653985000@Atlassian.JIRA>
	<JIRA.12727431.1515653985000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727431.1515653985000.28285.1515654420138@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2232:
--------------------------------
    Description: 
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- -LiteralExpressionEditorDefinition- - just getters and setters
- -LiteralExpressionColumnHeaderMetaData- - just extends another class
- -LiteralExpressionGridRenderer- - just extends another class

  was:
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- LiteralExpressionEditorDefinition
- -LiteralExpressionColumnHeaderMetaData- - just extends another class
- -LiteralExpressionGridRenderer- - just extends another class



> Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
> ---------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2232
>                 URL: https://issues.jboss.org/browse/DROOLS-2232
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>         Attachments: index.html
>
>
> The actual coverage form the attachment should be increased.
> - LiteralExpressionGrid
> - LiteralExpressionColumnRenderer
> - LiteralExpressionUIModelMapper
> - -LiteralExpressionEditorDefinition- - just getters and setters
> - -LiteralExpressionColumnHeaderMetaData- - just extends another class
> - -LiteralExpressionGridRenderer- - just extends another class



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 02:58:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 11 Jan 2018 02:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3502) Fix debug options in
	test-runner
In-Reply-To: <JIRA.12727245.1515575539000@Atlassian.JIRA>
References: <JIRA.12727245.1515575539000@Atlassian.JIRA>
	<JIRA.12727245.1515575539000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727245.1515575539000.28419.1515657480080@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-3502:
----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3029


> Fix debug options in test-runner
> --------------------------------
>
>                 Key: WFCORE-3502
>                 URL: https://issues.jboss.org/browse/WFCORE-3502
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Test-runner doesn't handle debug options correctly.
> If jdpa profile is used, surefire jvm uses this JVM attribute: {{-agentlib:jdwp=transport=dt_socket,address=$\{as.debug.port\},server=y,suspend=y}}.
> The same attribute is passed to started server. But server debugging should be set by {{wildfly.debug}} and {{wildfly.debug.port}} java properties. So if user wants to debug surefire with 8787 port and server with 8786 port, user uses jdpa profile, {{wildfly.debug}} property and {{wildfly.debug.port}} property and test fails:
> {{mvn test -DfailIfNoTests=false -DtestLogToFile=false -Dtest=CdTestCase -Djpda -Dwildfly.debug=true -Dwildfly.debug.port=8786}}
> {noformat}
> ERROR: Cannot load this JVM TI agent twice, check your java command line for duplicate jdwp options.
> Error occurred during initialization of VM
> agent library failed to init: jdwp
> Running null
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 11 03:22:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Thu, 11 Jan 2018 03:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3503) Duplicate commands in Help
In-Reply-To: <JIRA.12727441.1515658884000@Atlassian.JIRA>
References: <JIRA.12727441.1515658884000@Atlassian.JIRA>
	<JIRA.12727441.1515658884303@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727441.1515658884000.28490.1515658920390@Atlassian.JIRA>

Vratislav Marek created WFCORE-3503:
---------------------------------------

             Summary: Duplicate commands in Help
                 Key: WFCORE-3503
                 URL: https://issues.jboss.org/browse/WFCORE-3503
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
    Affects Versions: 4.0.0.Alpha5
            Reporter: Vratislav Marek
            Assignee: Jean-Francois Denise


I found duplicate command in CLI help 
For example twice commands:
* attachment
* if 
* undeploy
* command

{noformat}
[standalone at localhost:9990 /] help --commands
Commands available in the current context:
attachment                       connection-info                  deployment undeploy              help                             pwd                              set                              
attachment                       connection-info                  deployment undeploy-cli-archive  history                          pwd                              shutdown                        
batch                            deploy                           deployment-info                  history                          quit                             shutdown                        
batch                            deploy                           deployment-info                  if                               quit                             try                              
cd                               deployment deploy-cli-archive    deployment-overlay               if                               read-attribute                   try                              
cd                               deployment deploy-file           deployment-overlay               ls                               read-attribute                   undeploy                        
clear                            deployment deploy-url            echo                             ls                               read-operation                   undeploy                        
clear                            deployment disable               echo                             module                           read-operation                   unset                            
command                          deployment disable-all           echo-dmr                         module                           reload                           unset                            
command                          deployment enable                echo-dmr                         patch apply                      reload                           version                          
command-timeout                  deployment enable-all            for                              patch history                    run-batch                        
command-timeout                  deployment info                  for                              patch info                       run-batch                        
connect                          deployment list                  grep                             patch inspect                    set                              
To read a description of a specific command execute 'help <command name>'.
{noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 03:26:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Thu, 11 Jan 2018 03:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3503) Duplicate commands in Help
In-Reply-To: <JIRA.12727441.1515658884000@Atlassian.JIRA>
References: <JIRA.12727441.1515658884000@Atlassian.JIRA>
	<JIRA.12727441.1515658884000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727441.1515658884000.28519.1515659160484@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vratislav Marek updated WFCORE-3503:
------------------------------------
    Affects Version/s:     (was: 4.0.0.Alpha5)


> Duplicate commands in Help
> --------------------------
>
>                 Key: WFCORE-3503
>                 URL: https://issues.jboss.org/browse/WFCORE-3503
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> I found duplicate command in CLI help 
> For example twice commands:
> * attachment
> * if 
> * undeploy
> * command
> {noformat}
> [standalone at localhost:9990 /] help --commands
> Commands available in the current context:
> attachment                       connection-info                  deployment undeploy              help                             pwd                              set                              
> attachment                       connection-info                  deployment undeploy-cli-archive  history                          pwd                              shutdown                        
> batch                            deploy                           deployment-info                  history                          quit                             shutdown                        
> batch                            deploy                           deployment-info                  if                               quit                             try                              
> cd                               deployment deploy-cli-archive    deployment-overlay               if                               read-attribute                   try                              
> cd                               deployment deploy-file           deployment-overlay               ls                               read-attribute                   undeploy                        
> clear                            deployment deploy-url            echo                             ls                               read-operation                   undeploy                        
> clear                            deployment disable               echo                             module                           read-operation                   unset                            
> command                          deployment disable-all           echo-dmr                         module                           reload                           unset                            
> command                          deployment enable                echo-dmr                         patch apply                      reload                           version                          
> command-timeout                  deployment enable-all            for                              patch history                    run-batch                        
> command-timeout                  deployment info                  for                              patch info                       run-batch                        
> connect                          deployment list                  grep                             patch inspect                    set                              
> To read a description of a specific command execute 'help <command name>'.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 03:27:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Thu, 11 Jan 2018 03:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3503) Duplicate commands in Help
In-Reply-To: <JIRA.12727441.1515658884000@Atlassian.JIRA>
References: <JIRA.12727441.1515658884000@Atlassian.JIRA>
	<JIRA.12727441.1515658884000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727441.1515658884000.28536.1515659220592@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vratislav Marek updated WFCORE-3503:
------------------------------------
    Description: 
I found duplicate command in CLI help 
For example twice commands:
* attachment
* if 
* undeploy
* command

I see this issue in this [pull request|https://github.com/wildfly/wildfly-core/pull/2946/commits/3eae7f7d94aa5c9bc3914a8eaa2120a2c3fa2bfe] 

{noformat}
[standalone at localhost:9990 /] help --commands
Commands available in the current context:
attachment                       connection-info                  deployment undeploy              help                             pwd                              set                              
attachment                       connection-info                  deployment undeploy-cli-archive  history                          pwd                              shutdown                        
batch                            deploy                           deployment-info                  history                          quit                             shutdown                        
batch                            deploy                           deployment-info                  if                               quit                             try                              
cd                               deployment deploy-cli-archive    deployment-overlay               if                               read-attribute                   try                              
cd                               deployment deploy-file           deployment-overlay               ls                               read-attribute                   undeploy                        
clear                            deployment deploy-url            echo                             ls                               read-operation                   undeploy                        
clear                            deployment disable               echo                             module                           read-operation                   unset                            
command                          deployment disable-all           echo-dmr                         module                           reload                           unset                            
command                          deployment enable                echo-dmr                         patch apply                      reload                           version                          
command-timeout                  deployment enable-all            for                              patch history                    run-batch                        
command-timeout                  deployment info                  for                              patch info                       run-batch                        
connect                          deployment list                  grep                             patch inspect                    set                              
To read a description of a specific command execute 'help <command name>'.
{noformat}

  was:
I found duplicate command in CLI help 
For example twice commands:
* attachment
* if 
* undeploy
* command

{noformat}
[standalone at localhost:9990 /] help --commands
Commands available in the current context:
attachment                       connection-info                  deployment undeploy              help                             pwd                              set                              
attachment                       connection-info                  deployment undeploy-cli-archive  history                          pwd                              shutdown                        
batch                            deploy                           deployment-info                  history                          quit                             shutdown                        
batch                            deploy                           deployment-info                  if                               quit                             try                              
cd                               deployment deploy-cli-archive    deployment-overlay               if                               read-attribute                   try                              
cd                               deployment deploy-file           deployment-overlay               ls                               read-attribute                   undeploy                        
clear                            deployment deploy-url            echo                             ls                               read-operation                   undeploy                        
clear                            deployment disable               echo                             module                           read-operation                   unset                            
command                          deployment disable-all           echo-dmr                         module                           reload                           unset                            
command                          deployment enable                echo-dmr                         patch apply                      reload                           version                          
command-timeout                  deployment enable-all            for                              patch history                    run-batch                        
command-timeout                  deployment info                  for                              patch info                       run-batch                        
connect                          deployment list                  grep                             patch inspect                    set                              
To read a description of a specific command execute 'help <command name>'.
{noformat}



> Duplicate commands in Help
> --------------------------
>
>                 Key: WFCORE-3503
>                 URL: https://issues.jboss.org/browse/WFCORE-3503
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> I found duplicate command in CLI help 
> For example twice commands:
> * attachment
> * if 
> * undeploy
> * command
> I see this issue in this [pull request|https://github.com/wildfly/wildfly-core/pull/2946/commits/3eae7f7d94aa5c9bc3914a8eaa2120a2c3fa2bfe] 
> {noformat}
> [standalone at localhost:9990 /] help --commands
> Commands available in the current context:
> attachment                       connection-info                  deployment undeploy              help                             pwd                              set                              
> attachment                       connection-info                  deployment undeploy-cli-archive  history                          pwd                              shutdown                        
> batch                            deploy                           deployment-info                  history                          quit                             shutdown                        
> batch                            deploy                           deployment-info                  if                               quit                             try                              
> cd                               deployment deploy-cli-archive    deployment-overlay               if                               read-attribute                   try                              
> cd                               deployment deploy-file           deployment-overlay               ls                               read-attribute                   undeploy                        
> clear                            deployment deploy-url            echo                             ls                               read-operation                   undeploy                        
> clear                            deployment disable               echo                             module                           read-operation                   unset                            
> command                          deployment disable-all           echo-dmr                         module                           reload                           unset                            
> command                          deployment enable                echo-dmr                         patch apply                      reload                           version                          
> command-timeout                  deployment enable-all            for                              patch history                    run-batch                        
> command-timeout                  deployment info                  for                              patch info                       run-batch                        
> connect                          deployment list                  grep                             patch inspect                    set                              
> To read a description of a specific command execute 'help <command name>'.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 04:09:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 11 Jan 2018 04:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3496) Upgrade WildFly Elytron to
	1.2.0.Beta10
In-Reply-To: <JIRA.12727151.1515509860000@Atlassian.JIRA>
References: <JIRA.12727151.1515509860000@Atlassian.JIRA>
	<JIRA.12727151.1515509860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727151.1515509860000.28734.1515661740543@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFCORE-3496:
----------------------------------
    Labels: downstream_dependency  (was: )


> Upgrade WildFly Elytron to 1.2.0.Beta10
> ---------------------------------------
>
>                 Key: WFCORE-3496
>                 URL: https://issues.jboss.org/browse/WFCORE-3496
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Ivo Studensky
>            Assignee: Darran Lofthouse
>              Labels: downstream_dependency
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 04:23:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 11 Jan 2018 04:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7085) Server should verify EJB
 business methods during deployment and reject
In-Reply-To: <JIRA.12649493.1473435067000@Atlassian.JIRA>
References: <JIRA.12649493.1473435067000@Atlassian.JIRA>
	<JIRA.12649493.1473435067000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12649493.1473435067000.28849.1515662580737@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7085?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-7085:
--------------------------------
    Labels: downstream_dependency  (was: )


> Server should verify EJB business methods during deployment and reject
> ----------------------------------------------------------------------
>
>                 Key: WFLY-7085
>                 URL: https://issues.jboss.org/browse/WFLY-7085
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Wolf-Dieter Fink
>            Assignee: Tomasz Adamski
>              Labels: downstream_dependency
>             Fix For: 12.0.0.Alpha1
>
>
> The ejb 3.2 core specification state in chapter 4.9.6 that business methods should not be declared as final or static.
> But a Bean with a business method declared in the local or remote interface can be correct deployed and is accesible under some circumstances.
> To ensure that the Bean is according to the spec and avoid runtime or injection issues the methods should be checked and a VerifyError should be thrown at deployment time.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 04:37:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 11 Jan 2018 04:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3375) Upgrade jboss-logmanager
 from 2.1.0.Alpha5 to 2.1.0.Alpha6
In-Reply-To: <JIRA.12717310.1508430469000@Atlassian.JIRA>
References: <JIRA.12717310.1508430469000@Atlassian.JIRA>
	<JIRA.12717310.1508430469000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12717310.1508430469000.28967.1515663420129@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFCORE-3375:
----------------------------------
    Labels: downstream_dependency  (was: )


> Upgrade jboss-logmanager from 2.1.0.Alpha5 to 2.1.0.Alpha6
> ----------------------------------------------------------
>
>                 Key: WFCORE-3375
>                 URL: https://issues.jboss.org/browse/WFCORE-3375
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>              Labels: downstream_dependency
>
> The {{org.jboss.logmanager:jboss-logmanager:2.1.0.Alpha6}} will introduce a new {{CallerClassLoaderLogContextListener}} which needs to be used to ensure that modules don't create loggers on a deployments log context.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 04:45:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 11 Jan 2018 04:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3503) Duplicate commands in Help
In-Reply-To: <JIRA.12727441.1515658884000@Atlassian.JIRA>
References: <JIRA.12727441.1515658884000@Atlassian.JIRA>
	<JIRA.12727441.1515658884000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727441.1515658884000.29075.1515663900400@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513253#comment-13513253 ] 

Jean-Francois Denise commented on WFCORE-3503:
----------------------------------------------

Thank-you for reporting the issue. I fixed in the PR branch.


> Duplicate commands in Help
> --------------------------
>
>                 Key: WFCORE-3503
>                 URL: https://issues.jboss.org/browse/WFCORE-3503
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> I found duplicate command in CLI help 
> For example twice commands:
> * attachment
> * if 
> * undeploy
> * command
> I see this issue in this [pull request|https://github.com/wildfly/wildfly-core/pull/2946/commits/3eae7f7d94aa5c9bc3914a8eaa2120a2c3fa2bfe] 
> {noformat}
> [standalone at localhost:9990 /] help --commands
> Commands available in the current context:
> attachment                       connection-info                  deployment undeploy              help                             pwd                              set                              
> attachment                       connection-info                  deployment undeploy-cli-archive  history                          pwd                              shutdown                        
> batch                            deploy                           deployment-info                  history                          quit                             shutdown                        
> batch                            deploy                           deployment-info                  if                               quit                             try                              
> cd                               deployment deploy-cli-archive    deployment-overlay               if                               read-attribute                   try                              
> cd                               deployment deploy-file           deployment-overlay               ls                               read-attribute                   undeploy                        
> clear                            deployment deploy-url            echo                             ls                               read-operation                   undeploy                        
> clear                            deployment disable               echo                             module                           read-operation                   unset                            
> command                          deployment disable-all           echo-dmr                         module                           reload                           unset                            
> command                          deployment enable                echo-dmr                         patch apply                      reload                           version                          
> command-timeout                  deployment enable-all            for                              patch history                    run-batch                        
> command-timeout                  deployment info                  for                              patch info                       run-batch                        
> connect                          deployment list                  grep                             patch inspect                    set                              
> To read a description of a specific command execute 'help <command name>'.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 05:04:01 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 11 Jan 2018 05:04:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9659) Upgrade Ironjacamar to 1.4.7
In-Reply-To: <JIRA.12727468.1515664958000@Atlassian.JIRA>
References: <JIRA.12727468.1515664958000@Atlassian.JIRA>
	<JIRA.12727468.1515664958000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727468.1515664958000.29326.1515665041413@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky moved JBEAP-14069 to WFLY-9659:
---------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-9659  (was: JBEAP-14069)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: JCA
                           (was: Build System)
    Affects Version/s:     (was: 7.1.0.CR1)
        Fix Version/s:     (was: 7.1.1.GA)


> Upgrade Ironjacamar to 1.4.7
> ----------------------------
>
>                 Key: WFLY-9659
>                 URL: https://issues.jboss.org/browse/WFLY-9659
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JCA
>            Reporter: Ivo Studensky
>            Assignee: Petr Saka?
>              Labels: downstream_dependency
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 11 05:04:02 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 11 Jan 2018 05:04:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9659) Upgrade Ironjacamar to 1.4.7
In-Reply-To: <JIRA.12727468.1515664958000@Atlassian.JIRA>
References: <JIRA.12727468.1515664958000@Atlassian.JIRA>
	<JIRA.12727468.1515664958000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727468.1515664958000.29339.1515665042752@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9659:
--------------------------------
    Labels: downstream_dependency  (was: )


> Upgrade Ironjacamar to 1.4.7
> ----------------------------
>
>                 Key: WFLY-9659
>                 URL: https://issues.jboss.org/browse/WFLY-9659
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JCA
>            Reporter: Ivo Studensky
>            Assignee: Stefano Maestri
>              Labels: downstream_dependency
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 05:04:01 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 11 Jan 2018 05:04:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9659) Upgrade Ironjacamar to 1.4.7
In-Reply-To: <JIRA.12727468.1515664958000@Atlassian.JIRA>
References: <JIRA.12727468.1515664958000@Atlassian.JIRA>
	<JIRA.12727468.1515664958000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727468.1515664958000.29331.1515665041943@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9659?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky reassigned WFLY-9659:
-----------------------------------

    Assignee: Stefano Maestri  (was: Petr Saka?)


> Upgrade Ironjacamar to 1.4.7
> ----------------------------
>
>                 Key: WFLY-9659
>                 URL: https://issues.jboss.org/browse/WFLY-9659
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JCA
>            Reporter: Ivo Studensky
>            Assignee: Stefano Maestri
>              Labels: downstream_dependency
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 11 05:08:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 11 Jan 2018 05:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2232) Increase coverage
 org.kie.workbench.common.dmn.client.editors.expressions.types.literal
In-Reply-To: <JIRA.12727431.1515653985000@Atlassian.JIRA>
References: <JIRA.12727431.1515653985000@Atlassian.JIRA>
	<JIRA.12727431.1515653985000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727431.1515653985000.29355.1515665280131@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2232:
--------------------------------
    Description: 
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- -LiteralExpressionUIModelMapper- - https://github.com/kiegroup/kie-wb-common/pull/1346
- -LiteralExpressionEditorDefinition- - just getters and setters
- -LiteralExpressionColumnHeaderMetaData- - just extends another class
- -LiteralExpressionGridRenderer- - just extends another class

  was:
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- LiteralExpressionUIModelMapper
- -LiteralExpressionEditorDefinition- - just getters and setters
- -LiteralExpressionColumnHeaderMetaData- - just extends another class
- -LiteralExpressionGridRenderer- - just extends another class



> Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
> ---------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2232
>                 URL: https://issues.jboss.org/browse/DROOLS-2232
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>         Attachments: index.html
>
>
> The actual coverage form the attachment should be increased.
> - LiteralExpressionGrid
> - LiteralExpressionColumnRenderer
> - -LiteralExpressionUIModelMapper- - https://github.com/kiegroup/kie-wb-common/pull/1346
> - -LiteralExpressionEditorDefinition- - just getters and setters
> - -LiteralExpressionColumnHeaderMetaData- - just extends another class
> - -LiteralExpressionGridRenderer- - just extends another class



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 05:13:01 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 11 Jan 2018 05:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2227) Verifier should manage
 predicate columns properly
In-Reply-To: <JIRA.12727249.1515576673000@Atlassian.JIRA>
References: <JIRA.12727249.1515576673000@Atlassian.JIRA>
	<JIRA.12727249.1515576673000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727249.1515576673000.29403.1515665581109@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2227:
--------------------------------
    Tester: Jozef Marko


> Verifier should manage predicate columns properly
> -------------------------------------------------
>
>                 Key: DROOLS-2227
>                 URL: https://issues.jboss.org/browse/DROOLS-2227
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Guided Decision Table Editor
>            Reporter: Toni Rikkola
>            Assignee: Toni Rikkola
>
>  < Rikkola> for dtables, string comparison is probably enough, 
>                  prooobably
>  < Rikkola> and when I type that nope
> < Rikkola> eval( 1+1) and eval( 0+2) are the same, but no way to know
>  < Rikkola> maybe a warning when columns like this are used, the V&V might 
>                  not pick everything up



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 05:16:03 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 11 Jan 2018 05:16:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2227) Verifier should manage
 predicate columns properly
In-Reply-To: <JIRA.12727249.1515576673000@Atlassian.JIRA>
References: <JIRA.12727249.1515576673000@Atlassian.JIRA>
	<JIRA.12727249.1515576673000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727249.1515576673000.29448.1515665763084@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2227?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513283#comment-13513283 ] 

Jozef Marko commented on DROOLS-2227:
-------------------------------------

Hi [~Rikkola], sorry, was on training yesterday. How can I help you, do you plan to turn of validation form columns with predicate? I mean I can imagine the validation evaluates `eval(....)` expressions if there is some arithmetic operation consisting just of constatnts, however I am not sure what in cases like eval($count + $person.age).

> Verifier should manage predicate columns properly
> -------------------------------------------------
>
>                 Key: DROOLS-2227
>                 URL: https://issues.jboss.org/browse/DROOLS-2227
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Guided Decision Table Editor
>            Reporter: Toni Rikkola
>            Assignee: Toni Rikkola
>
>  < Rikkola> for dtables, string comparison is probably enough, 
>                  prooobably
>  < Rikkola> and when I type that nope
> < Rikkola> eval( 1+1) and eval( 0+2) are the same, but no way to know
>  < Rikkola> maybe a warning when columns like this are used, the V&V might 
>                  not pick everything up



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 05:21:01 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 11 Jan 2018 05:21:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9147) POJO WS not defaulting to
 Undertow default-security-domain
In-Reply-To: <JIRA.12705202.1501188983000@Atlassian.JIRA>
References: <JIRA.12705202.1501188983000@Atlassian.JIRA>
	<JIRA.12705202.1501188983000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12705202.1501188983000.29511.1515666061117@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9147?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9147:
--------------------------------
    Labels: downstream_dependency  (was: )


> POJO WS not defaulting to Undertow default-security-domain
> ----------------------------------------------------------
>
>                 Key: WFLY-9147
>                 URL: https://issues.jboss.org/browse/WFLY-9147
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web Services
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Brad Maxwell
>            Assignee: Jim Ma
>              Labels: downstream_dependency
>
> A POJO WS should default to the Undertow default-security-domain just as an EJB WS defaults to the default-security-domain defined in the ejb3 subsystem.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 05:42:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 11 Jan 2018 05:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9128) Upgrade Apache CXF to 3.1.13
In-Reply-To: <JIRA.12704639.1500992195000@Atlassian.JIRA>
References: <JIRA.12704639.1500992195000@Atlassian.JIRA>
	<JIRA.12704639.1500992195000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12704639.1500992195000.29697.1515667320669@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9128:
--------------------------------
    Labels: downstream_dependency  (was: )


> Upgrade Apache CXF to 3.1.13
> ----------------------------
>
>                 Key: WFLY-9128
>                 URL: https://issues.jboss.org/browse/WFLY-9128
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Services
>            Reporter: Ivo Studensky
>            Assignee: Alessio Soldano
>              Labels: downstream_dependency
>
> Upgrade Apache CXF to 3.1.11 (from 3.1.10)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 06:15:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 11 Jan 2018 06:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2232) Increase coverage
 org.kie.workbench.common.dmn.client.editors.expressions.types.literal
In-Reply-To: <JIRA.12727431.1515653985000@Atlassian.JIRA>
References: <JIRA.12727431.1515653985000@Atlassian.JIRA>
	<JIRA.12727431.1515653985000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727431.1515653985000.29961.1515669300253@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2232:
--------------------------------
    Description: 
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- -LiteralExpressionColumnRenderer- - https://github.com/kiegroup/kie-wb-common/pull/1347
- -LiteralExpressionUIModelMapper- - https://github.com/kiegroup/kie-wb-common/pull/1346
- -LiteralExpressionEditorDefinition- - just getters and setters
- -LiteralExpressionColumnHeaderMetaData- - just extends another class
- -LiteralExpressionGridRenderer- - just extends another class

  was:
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- LiteralExpressionColumnRenderer
- -LiteralExpressionUIModelMapper- - https://github.com/kiegroup/kie-wb-common/pull/1346
- -LiteralExpressionEditorDefinition- - just getters and setters
- -LiteralExpressionColumnHeaderMetaData- - just extends another class
- -LiteralExpressionGridRenderer- - just extends another class



> Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
> ---------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2232
>                 URL: https://issues.jboss.org/browse/DROOLS-2232
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>         Attachments: index.html
>
>
> The actual coverage form the attachment should be increased.
> - LiteralExpressionGrid
> - -LiteralExpressionColumnRenderer- - https://github.com/kiegroup/kie-wb-common/pull/1347
> - -LiteralExpressionUIModelMapper- - https://github.com/kiegroup/kie-wb-common/pull/1346
> - -LiteralExpressionEditorDefinition- - just getters and setters
> - -LiteralExpressionColumnHeaderMetaData- - just extends another class
> - -LiteralExpressionGridRenderer- - just extends another class



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 06:23:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 11 Jan 2018 06:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2160) Enhance UI in Test
	Scenarios Editor
In-Reply-To: <JIRA.12723168.1512142861000@Atlassian.JIRA>
References: <JIRA.12723168.1512142861000@Atlassian.JIRA>
	<JIRA.12723168.1512142861000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723168.1512142861000.30015.1515669780132@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko reassigned DROOLS-2160:
-----------------------------------

    Assignee: Jozef Marko  (was: Toni Rikkola)


> Enhance UI in Test Scenarios Editor
> -----------------------------------
>
>                 Key: DROOLS-2160
>                 URL: https://issues.jboss.org/browse/DROOLS-2160
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Test Scenarios Editor
>            Reporter: Ivo Bek
>            Assignee: Jozef Marko
>              Labels: UX
>         Attachments: Screenshot from 2017-12-01 16-38-52.png
>
>
> Test Scenarios editor needs to be polished:
> * Delete Buttons are too small - it would be good to enlarge them.
> * Some other elements doesn't have enough space around them.
> * Please do any other small visual changes which makes sense.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 07:02:00 2018
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Thu, 11 Jan 2018 07:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2233) DMN:
 time(date("2017-08-10")) should return 00:00:00z time
In-Reply-To: <JIRA.12727497.1515672063000@Atlassian.JIRA>
References: <JIRA.12727497.1515672063000@Atlassian.JIRA>
	<JIRA.12727497.1515672063425@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727497.1515672063000.30503.1515672120078@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-2233:
-------------------------------------

             Summary: DMN: time(date("2017-08-10")) should return 00:00:00z time
                 Key: DROOLS-2233
                 URL: https://issues.jboss.org/browse/DROOLS-2233
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
    Affects Versions: 7.5.0.Final
            Reporter: Tibor Zim?nyi
            Assignee: Tibor Zim?nyi


According to the specification in section "10.3.2.3.5 date": 
"Where necessary, including the valuedt function (see 10.3.2.x.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00)."

Currently the case time(date("2017-08-10")) returns null, because the evaluation ends with DateTimeException, because internally we represent dates as LocalDate class, which doesn't have time part. 

I will provide a PR with a fix.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 11 07:30:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 11 Jan 2018 07:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2232) Increase coverage
 org.kie.workbench.common.dmn.client.editors.expressions.types.literal
In-Reply-To: <JIRA.12727431.1515653985000@Atlassian.JIRA>
References: <JIRA.12727431.1515653985000@Atlassian.JIRA>
	<JIRA.12727431.1515653985000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727431.1515653985000.30762.1515673800062@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2232:
--------------------------------
    Description: 
The actual coverage form the attachment should be increased.
- -LiteralExpressionGrid- - just factory method calls
- -LiteralExpressionColumnRenderer- - https://github.com/kiegroup/kie-wb-common/pull/1347
- -LiteralExpressionUIModelMapper- - https://github.com/kiegroup/kie-wb-common/pull/1346
- -LiteralExpressionEditorDefinition- - just getters and setters
- -LiteralExpressionColumnHeaderMetaData- - just extends another class
- -LiteralExpressionGridRenderer- - just extends another class

  was:
The actual coverage form the attachment should be increased.
- LiteralExpressionGrid
- -LiteralExpressionColumnRenderer- - https://github.com/kiegroup/kie-wb-common/pull/1347
- -LiteralExpressionUIModelMapper- - https://github.com/kiegroup/kie-wb-common/pull/1346
- -LiteralExpressionEditorDefinition- - just getters and setters
- -LiteralExpressionColumnHeaderMetaData- - just extends another class
- -LiteralExpressionGridRenderer- - just extends another class



> Increase coverage org.kie.workbench.common.dmn.client.editors.expressions.types.literal
> ---------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2232
>                 URL: https://issues.jboss.org/browse/DROOLS-2232
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>         Attachments: index.html
>
>
> The actual coverage form the attachment should be increased.
> - -LiteralExpressionGrid- - just factory method calls
> - -LiteralExpressionColumnRenderer- - https://github.com/kiegroup/kie-wb-common/pull/1347
> - -LiteralExpressionUIModelMapper- - https://github.com/kiegroup/kie-wb-common/pull/1346
> - -LiteralExpressionEditorDefinition- - just getters and setters
> - -LiteralExpressionColumnHeaderMetaData- - just extends another class
> - -LiteralExpressionGridRenderer- - just extends another class



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 07:33:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 11 Jan 2018 07:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3501) Allow System properties to
 be set at parse time before extensions are loaded in standalone mode
In-Reply-To: <JIRA.12727220.1515544799000@Atlassian.JIRA>
References: <JIRA.12727220.1515544799000@Atlassian.JIRA>
	<JIRA.12727220.1515544799000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727220.1515544799000.30771.1515673980198@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3501?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3501:
-------------------------------------
     Issue Type: Task  (was: Feature Request)
    Description: Subject says it all, except that if the property value includes an expression and the expression cannot be resolved at parse time, the property will not be set at parse time and the logic already in place will deal with it. There should be no reason for anyone to use an expression, certainly not an unresolvable one, in a property that needs to be set before extensions are loaded.


> Allow System properties to be set at parse time before extensions are loaded in standalone mode
> -----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3501
>                 URL: https://issues.jboss.org/browse/WFCORE-3501
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> Subject says it all, except that if the property value includes an expression and the expression cannot be resolved at parse time, the property will not be set at parse time and the logic already in place will deal with it. There should be no reason for anyone to use an expression, certainly not an unresolvable one, in a property that needs to be set before extensions are loaded.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 08:23:00 2018
From: issues at jboss.org (=?UTF-8?Q?Bartosz_Spyrko-=C5=9Amietanko_=28JIRA=29?=)
Date: Thu, 11 Jan 2018 08:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3504) Logout redirect failed from
 a management Web console using IE
In-Reply-To: <JIRA.12727520.1515676305000@Atlassian.JIRA>
References: <JIRA.12727520.1515676305000@Atlassian.JIRA>
	<JIRA.12727520.1515676305000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727520.1515676305000.31151.1515676980076@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Spyrko-?mietanko moved JBEAP-14071 to WFCORE-3504:
----------------------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-3504  (was: JBEAP-14071)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Domain Management
                           (was: Web Console)
    Affects Version/s: 4.0.0.Alpha6
                           (was: 7.1.0.GA)
                           (was: 7.0.9.GA)


> Logout redirect failed from a management Web console using IE
> -------------------------------------------------------------
>
>                 Key: WFCORE-3504
>                 URL: https://issues.jboss.org/browse/WFCORE-3504
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 4.0.0.Alpha6
>         Environment: EAP 7.0.9 and EAP 7.1
> IE 11(internete explorer11 11.192.16200.0)
>            Reporter: Bartosz Spyrko-?mietanko
>            Assignee: Bartosz Spyrko-?mietanko
>            Priority: Minor
>
> When we logout from a management console with IE, the logout redirect is failed with an Error Code"INET_E_INVALID_URL".



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 11 08:29:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Thu, 11 Jan 2018 08:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3503) Duplicate commands in Help
In-Reply-To: <JIRA.12727441.1515658884000@Atlassian.JIRA>
References: <JIRA.12727441.1515658884000@Atlassian.JIRA>
	<JIRA.12727441.1515658884000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727441.1515658884000.31184.1515677340356@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3503?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513457#comment-13513457 ] 

Vratislav Marek commented on WFCORE-3503:
-----------------------------------------

I tested fix in pull-request, fix looks good.
{noformat}
[standalone at localhost:9990 /] help --commands 
Commands available in the current context:
attachment                       deploy                           deployment info                  for                              patch history                    run-batch                        
batch                            deployment deploy-cli-archive    deployment list                  grep                             patch info                       set                              
cd                               deployment deploy-file           deployment undeploy              help                             patch inspect                    shutdown                         
clear                            deployment deploy-url            deployment undeploy-cli-archive  history                          pwd                              try                              
command                          deployment disable               deployment-info                  if                               quit                             undeploy                         
command-timeout                  deployment disable-all           deployment-overlay               ls                               read-attribute                   unset                            
connect                          deployment enable                echo                             module                           read-operation                   version                          
connection-info                  deployment enable-all            echo-dmr                         patch apply                      reload                           
To read a description of a specific command execute 'help <command name>'.
{noformat}

Thank-you.

> Duplicate commands in Help
> --------------------------
>
>                 Key: WFCORE-3503
>                 URL: https://issues.jboss.org/browse/WFCORE-3503
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> I found duplicate command in CLI help 
> For example twice commands:
> * attachment
> * if 
> * undeploy
> * command
> I see this issue in this [pull request|https://github.com/wildfly/wildfly-core/pull/2946/commits/3eae7f7d94aa5c9bc3914a8eaa2120a2c3fa2bfe] 
> {noformat}
> [standalone at localhost:9990 /] help --commands
> Commands available in the current context:
> attachment                       connection-info                  deployment undeploy              help                             pwd                              set                              
> attachment                       connection-info                  deployment undeploy-cli-archive  history                          pwd                              shutdown                        
> batch                            deploy                           deployment-info                  history                          quit                             shutdown                        
> batch                            deploy                           deployment-info                  if                               quit                             try                              
> cd                               deployment deploy-cli-archive    deployment-overlay               if                               read-attribute                   try                              
> cd                               deployment deploy-file           deployment-overlay               ls                               read-attribute                   undeploy                        
> clear                            deployment deploy-url            echo                             ls                               read-operation                   undeploy                        
> clear                            deployment disable               echo                             module                           read-operation                   unset                            
> command                          deployment disable-all           echo-dmr                         module                           reload                           unset                            
> command                          deployment enable                echo-dmr                         patch apply                      reload                           version                          
> command-timeout                  deployment enable-all            for                              patch history                    run-batch                        
> command-timeout                  deployment info                  for                              patch info                       run-batch                        
> connect                          deployment list                  grep                             patch inspect                    set                              
> To read a description of a specific command execute 'help <command name>'.
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 09:38:00 2018
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Thu, 11 Jan 2018 09:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1486) Support
 credential-store-reference in oauth2-bearer-token client configuration
In-Reply-To: <JIRA.12727557.1515681446000@Atlassian.JIRA>
References: <JIRA.12727557.1515681446000@Atlassian.JIRA>
	<JIRA.12727557.1515681446498@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727557.1515681446000.31750.1515681480500@Atlassian.JIRA>

Pedro Igor created ELY-1486:
-------------------------------

             Summary: Support credential-store-reference in oauth2-bearer-token client configuration
                 Key: ELY-1486
                 URL: https://issues.jboss.org/browse/ELY-1486
             Project: WildFly Elytron
          Issue Type: Task
          Components: Authentication Client
    Affects Versions: 1.2.0.Beta11
            Reporter: Pedro Igor
            Assignee: Pedro Igor


Currently, when using oauth2-bearer-token in client configuration, passwords and client secrets are defined in clear format.

This issue aims to support obtaining these credentials from a credential store.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 10:07:00 2018
From: issues at jboss.org (Instantiation Exception (JIRA))
Date: Thu, 11 Jan 2018 10:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9661) Can't find
 wildfly-spec-api-10.1.0.Final.jar in Maven Central
In-Reply-To: <JIRA.12727566.1515683187000@Atlassian.JIRA>
References: <JIRA.12727566.1515683187000@Atlassian.JIRA>
	<JIRA.12727566.1515683187307@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727566.1515683187000.32031.1515683220352@Atlassian.JIRA>

Instantiation Exception created WFLY-9661:
---------------------------------------------

             Summary: Can't find wildfly-spec-api-10.1.0.Final.jar in Maven Central
                 Key: WFLY-9661
                 URL: https://issues.jboss.org/browse/WFLY-9661
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Instantiation Exception
            Assignee: Jason Greene


I have the following Maven configuration:

{code:xml}
<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0"
         xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">

    <modelVersion>4.0.0</modelVersion>

    <groupId>mycompany</groupId>
    <artifactId>payment</artifactId>
    <version>1.0-SNAPSHOT</version>
    <packaging>war</packaging>
    <name>payment</name>

    <properties>
        <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
        <maven.compiler.source>1.8</maven.compiler.source>
        <maven.compiler.target>1.8</maven.compiler.target>
        <failOnMissingWebXml>false</failOnMissingWebXml>
    </properties>

    <dependencyManagement>
        <dependencies>
            <dependency>
                <groupId>org.wildfly.bom</groupId>
                <artifactId>wildfly-javaee7-with-tools</artifactId>
                <version>10.1.0.Final</version>
                <type>pom</type>
                <scope>import</scope>
            </dependency>
        </dependencies>
    </dependencyManagement>

    <dependencies>
        <dependency>
            <groupId>org.wildfly</groupId>
            <artifactId>wildfly-spec-api</artifactId>
            <version>10.1.0.Final</version>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.jboss.resteasy</groupId>
            <artifactId>resteasy-jaxrs</artifactId>
            <scope>provided</scope>
        </dependency>
        <dependency>
            <groupId>org.hibernate</groupId>
            <artifactId>hibernate-validator</artifactId>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.projectlombok</groupId>
            <artifactId>lombok</artifactId>
            <version>1.16.12</version>
            <scope>provided</scope>
        </dependency>

        <dependency>
            <groupId>org.flywaydb</groupId>
            <artifactId>flyway-core</artifactId>
            <version>4.0.2</version>
        </dependency>
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>20.0</version>
        </dependency>

        <dependency>
            <groupId>io.rest-assured</groupId>
            <artifactId>rest-assured</artifactId>
            <version>3.0.2</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>junit</groupId>
            <artifactId>junit</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.hamcrest</groupId>
            <artifactId>hamcrest-library</artifactId>
            <version>1.3</version>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.mockito</groupId>
            <artifactId>mockito-core</artifactId>
            <version>1.10.19</version>
            <scope>test</scope>
        </dependency>

        <dependency>
            <groupId>org.jboss.arquillian.junit</groupId>
            <artifactId>arquillian-junit-container</artifactId>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.jboss.arquillian.graphene</groupId>
            <artifactId>graphene-webdriver</artifactId>
            <type>pom</type>
            <scope>test</scope>
        </dependency>
        <dependency>
            <groupId>org.wildfly.arquillian</groupId>
            <artifactId>wildfly-arquillian-container-remote</artifactId>
            <scope>test</scope>
        </dependency>
    </dependencies>

    <build>
        <finalName>payment</finalName>
    </build>
</project>
{code}

I type

{code}
mvn clean package
{code}

and I get following error

{code}
[INFO] ------------------------------------------------------------------------
Downloading: https://repo.maven.apache.org/maven2/org/wildfly/wildfly-spec-api/10.1.0.Final/wildfly-spec-api-10.1.0.Final.jar
[INFO] ------------------------------------------------------------------------
[INFO] BUILD FAILURE
[INFO] ------------------------------------------------------------------------
[INFO] Total time: 2.262 s
[INFO] Finished at: 2018-01-10T15:50:43+01:00
[INFO] Final Memory: 20M/399M
[INFO] ------------------------------------------------------------------------
[ERROR] Failed to execute goal on project payment: Could not resolve dependencies for project mycompany:payment:war:1.0-SNAPSHOT: Could not find artifact org.wildfly:wildfly-spec-api:jar:10.1.0.Final in central (https://repo.maven.apache.org/maven2) -> [Help 1]
[ERROR]
[ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
[ERROR] Re-run Maven using the -X switch to enable full debug logging.
[ERROR]
[ERROR] For more information about the errors and possible solutions, please read the following articles:
[ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
{code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 10:08:00 2018
From: issues at jboss.org (Instantiation Exception (JIRA))
Date: Thu, 11 Jan 2018 10:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9661) Can't find
 wildfly-spec-api-10.1.0.Final.jar in Maven Central
In-Reply-To: <JIRA.12727566.1515683187000@Atlassian.JIRA>
References: <JIRA.12727566.1515683187000@Atlassian.JIRA>
	<JIRA.12727566.1515683187000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727566.1515683187000.32036.1515683280373@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Instantiation Exception updated WFLY-9661:
------------------------------------------
    Issue Type: Bug  (was: Feature Request)


> Can't find wildfly-spec-api-10.1.0.Final.jar in Maven Central
> -------------------------------------------------------------
>
>                 Key: WFLY-9661
>                 URL: https://issues.jboss.org/browse/WFLY-9661
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Instantiation Exception
>            Assignee: Jason Greene
>
> I have the following Maven configuration:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
>     <modelVersion>4.0.0</modelVersion>
>     <groupId>mycompany</groupId>
>     <artifactId>payment</artifactId>
>     <version>1.0-SNAPSHOT</version>
>     <packaging>war</packaging>
>     <name>payment</name>
>     <properties>
>         <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
>         <maven.compiler.source>1.8</maven.compiler.source>
>         <maven.compiler.target>1.8</maven.compiler.target>
>         <failOnMissingWebXml>false</failOnMissingWebXml>
>     </properties>
>     <dependencyManagement>
>         <dependencies>
>             <dependency>
>                 <groupId>org.wildfly.bom</groupId>
>                 <artifactId>wildfly-javaee7-with-tools</artifactId>
>                 <version>10.1.0.Final</version>
>                 <type>pom</type>
>                 <scope>import</scope>
>             </dependency>
>         </dependencies>
>     </dependencyManagement>
>     <dependencies>
>         <dependency>
>             <groupId>org.wildfly</groupId>
>             <artifactId>wildfly-spec-api</artifactId>
>             <version>10.1.0.Final</version>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.jboss.resteasy</groupId>
>             <artifactId>resteasy-jaxrs</artifactId>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.hibernate</groupId>
>             <artifactId>hibernate-validator</artifactId>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.projectlombok</groupId>
>             <artifactId>lombok</artifactId>
>             <version>1.16.12</version>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.flywaydb</groupId>
>             <artifactId>flyway-core</artifactId>
>             <version>4.0.2</version>
>         </dependency>
>         <dependency>
>             <groupId>com.google.guava</groupId>
>             <artifactId>guava</artifactId>
>             <version>20.0</version>
>         </dependency>
>         <dependency>
>             <groupId>io.rest-assured</groupId>
>             <artifactId>rest-assured</artifactId>
>             <version>3.0.2</version>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>junit</groupId>
>             <artifactId>junit</artifactId>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.hamcrest</groupId>
>             <artifactId>hamcrest-library</artifactId>
>             <version>1.3</version>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.mockito</groupId>
>             <artifactId>mockito-core</artifactId>
>             <version>1.10.19</version>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.jboss.arquillian.junit</groupId>
>             <artifactId>arquillian-junit-container</artifactId>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.jboss.arquillian.graphene</groupId>
>             <artifactId>graphene-webdriver</artifactId>
>             <type>pom</type>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.wildfly.arquillian</groupId>
>             <artifactId>wildfly-arquillian-container-remote</artifactId>
>             <scope>test</scope>
>         </dependency>
>     </dependencies>
>     <build>
>         <finalName>payment</finalName>
>     </build>
> </project>
> {code}
> I type
> {code}
> mvn clean package
> {code}
> and I get following error
> {code}
> [INFO] ------------------------------------------------------------------------
> Downloading: https://repo.maven.apache.org/maven2/org/wildfly/wildfly-spec-api/10.1.0.Final/wildfly-spec-api-10.1.0.Final.jar
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 2.262 s
> [INFO] Finished at: 2018-01-10T15:50:43+01:00
> [INFO] Final Memory: 20M/399M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project payment: Could not resolve dependencies for project mycompany:payment:war:1.0-SNAPSHOT: Could not find artifact org.wildfly:wildfly-spec-api:jar:10.1.0.Final in central (https://repo.maven.apache.org/maven2) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 10:38:02 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 11 Jan 2018 10:38:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFBUILD-30) Schemas not extracted
	properly
In-Reply-To: <JIRA.12727570.1515685068000@Atlassian.JIRA>
References: <JIRA.12727570.1515685068000@Atlassian.JIRA>
	<JIRA.12727570.1515685068150@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727570.1515685068000.32564.1515685082626@Atlassian.JIRA>

David Lloyd created WFBUILD-30:
----------------------------------

             Summary: Schemas not extracted properly
                 Key: WFBUILD-30
                 URL: https://issues.jboss.org/browse/WFBUILD-30
             Project: WildFly Build Tools
          Issue Type: Bug
    Affects Versions: 1.2.3.Final
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar
             Fix For: 1.2.4.Final






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 11:03:01 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 11 Jan 2018 11:03:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9662) Upgrade JBoss Build Tools to
	1.2.4.Final
In-Reply-To: <JIRA.12727578.1515686568000@Atlassian.JIRA>
References: <JIRA.12727578.1515686568000@Atlassian.JIRA>
	<JIRA.12727578.1515686568001@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727578.1515686568000.32831.1515686581009@Atlassian.JIRA>

David Lloyd created WFLY-9662:
---------------------------------

             Summary: Upgrade JBoss Build Tools to 1.2.4.Final
                 Key: WFLY-9662
                 URL: https://issues.jboss.org/browse/WFLY-9662
             Project: WildFly
          Issue Type: Bug
          Components: Build System
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 12.0.0.Alpha1


Removes temporary fix for WFBUILD-30.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 11:04:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 11 Jan 2018 11:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFBUILD-30) Schemas not extracted
	properly
In-Reply-To: <JIRA.12727570.1515685068000@Atlassian.JIRA>
References: <JIRA.12727570.1515685068000@Atlassian.JIRA>
	<JIRA.12727570.1515685068000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727570.1515685068000.32847.1515686640766@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFBUILD-30?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFBUILD-30.
--------------------------------
    Resolution: Done


> Schemas not extracted properly
> ------------------------------
>
>                 Key: WFBUILD-30
>                 URL: https://issues.jboss.org/browse/WFBUILD-30
>             Project: WildFly Build Tools
>          Issue Type: Bug
>    Affects Versions: 1.2.3.Final
>            Reporter: Tomaz Cerar
>            Assignee: Tomaz Cerar
>             Fix For: 1.2.4.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 11:15:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 11 Jan 2018 11:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3444) Update wildfly-build-tools
 to 1.2.4.Final
In-Reply-To: <JIRA.12723359.1512405488000@Atlassian.JIRA>
References: <JIRA.12723359.1512405488000@Atlassian.JIRA>
	<JIRA.12723359.1512405488000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723359.1512405488000.32887.1515687300114@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFCORE-3444:
--------------------------------
    Summary: Update wildfly-build-tools to 1.2.4.Final  (was: Update wildfly-build-tools to 1.2.3.Final)


> Update wildfly-build-tools to 1.2.4.Final
> -----------------------------------------
>
>                 Key: WFCORE-3444
>                 URL: https://issues.jboss.org/browse/WFCORE-3444
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 4.0.0.Alpha6
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 15:27:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 11 Jan 2018 15:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3498) Eliminate
 ServiceVerificationHandler and all its usages
In-Reply-To: <JIRA.12727164.1515511927000@Atlassian.JIRA>
References: <JIRA.12727164.1515511927000@Atlassian.JIRA>
	<JIRA.12727164.1515511927000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727164.1515511927000.33640.1515702420111@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3498:
-------------------------------------
    Description: SVH have been deprecated ~ 40 months ago. Now is the time to eliminate it completely.  (was: SVH have been deprecated ~ 20 months ago. Now is the time to eliminate it completely.)


> Eliminate ServiceVerificationHandler and all its usages
> -------------------------------------------------------
>
>                 Key: WFCORE-3498
>                 URL: https://issues.jboss.org/browse/WFCORE-3498
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Server
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Alpha6
>
>
> SVH have been deprecated ~ 40 months ago. Now is the time to eliminate it completely.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 16:02:00 2018
From: issues at jboss.org (Tibor Digana (JIRA))
Date: Thu, 11 Jan 2018 16:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9400) Upgrade to Apache CXF 3.2
 series (through JBossWS 5.2)
In-Reply-To: <JIRA.12713948.1506615392000@Atlassian.JIRA>
References: <JIRA.12713948.1506615392000@Atlassian.JIRA>
	<JIRA.12713948.1506615392000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12713948.1506615392000.33735.1515704520145@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513742#comment-13513742 ] 

Tibor Digana commented on WFLY-9400:
------------------------------------

[~asoldano]
The Apache CXF 3.2.1 was released in November 2017:
http://cxf.apache.org/download.html
How far we are with this upgrade?
Thx.

> Upgrade to Apache CXF 3.2 series (through JBossWS 5.2)
> ------------------------------------------------------
>
>                 Key: WFLY-9400
>                 URL: https://issues.jboss.org/browse/WFLY-9400
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Services
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 12.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 17:30:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 11 Jan 2018 17:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2234) DMN JSON payload with
 decision-name or decision-id null causes NPE
In-Reply-To: <JIRA.12727616.1515709754000@Atlassian.JIRA>
References: <JIRA.12727616.1515709754000@Atlassian.JIRA>
	<JIRA.12727616.1515709754868@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727616.1515709754000.33862.1515709800086@Atlassian.JIRA>

Matteo Mortari created DROOLS-2234:
--------------------------------------

             Summary: DMN JSON payload with decision-name or decision-id null causes NPE
                 Key: DROOLS-2234
                 URL: https://issues.jboss.org/browse/DROOLS-2234
             Project: Drools
          Issue Type: Bug
          Components: dmn engine, kie server
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari


Only with JSON.
Sending a payload request with example:

{code:java}
{
  "model-namespace" : "http://www.trisotech.com/definitions/_fd2a47fb-a74a-44d7-b26e-cd1a6289839d",
  "model-name" : "Exercise 1.1",
  "decision-name" : null,
  "decision-id" : null,
  "dmn-context" : {"Credit Score" : 4000, "Income" : 50000} 
}
{code}

causes NPE:

{code:java}
23:25:06.509 [Acme.Utils.ThreadPool(1)-PooledThread: Acme.Serve.Serve$ServeConnection at 4d6e768] ERROR o.k.s.s.d.ModelEvaluatorServiceBase - Error from container 'input-data-string'
java.lang.NullPointerException: null
	at org.kie.server.services.dmn.ModelEvaluatorServiceBase.evaluateDecisions(ModelEvaluatorServiceBase.java:143) ~[classes/:na]
	at org.kie.server.remote.rest.dmn.ModelEvaluatorResource.evaluateDecisions(ModelEvaluatorResource.java:108) [kie-server-rest-dmn-7.6.0-SNAPSHOT.jar:7.6.0-SNAPSHOT]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_151]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_151]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_151]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_151]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.tjws.TJWSServletDispatcher.service(TJWSServletDispatcher.java:40) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
	at Acme.Serve.Serve$ServeConnection.runServlet(Serve.java:2328) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at Acme.Serve.Serve$ServeConnection.parseRequest(Serve.java:2282) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at Acme.Serve.Serve$ServeConnection.run(Serve.java:2054) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at Acme.Utils$ThreadPool$PooledThread.run(Utils.java:1402) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
{code}




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 17:32:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 11 Jan 2018 17:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2234) DMN JSON payload with
 decision-name or decision-id null causes NPE
In-Reply-To: <JIRA.12727616.1515709755000@Atlassian.JIRA>
References: <JIRA.12727616.1515709755000@Atlassian.JIRA>
	<JIRA.12727616.1515709755000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727616.1515709755000.33864.1515709920055@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari updated DROOLS-2234:
-----------------------------------
    Description: 
Only with JSON.
Sending a payload request with example:

{code:java}
{
  "model-namespace" : "http://www.trisotech.com/definitions/_fd2a47fb-a74a-44d7-b26e-cd1a6289839d",
  "model-name" : "Exercise 1.1",
  "decision-name" : null,
  "decision-id" : null,
  "dmn-context" : {"Credit Score" : 4000, "Income" : 50000} 
}
{code}

causes NPE:

{code:java}
23:25:06.509 [Acme.Utils.ThreadPool(1)-PooledThread: Acme.Serve.Serve$ServeConnection at 4d6e768] ERROR o.k.s.s.d.ModelEvaluatorServiceBase - Error from container 'input-data-string'
java.lang.NullPointerException: null
	at org.kie.server.services.dmn.ModelEvaluatorServiceBase.evaluateDecisions(ModelEvaluatorServiceBase.java:143) ~[classes/:na]
	at org.kie.server.remote.rest.dmn.ModelEvaluatorResource.evaluateDecisions(ModelEvaluatorResource.java:108) [kie-server-rest-dmn-7.6.0-SNAPSHOT.jar:7.6.0-SNAPSHOT]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_151]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_151]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_151]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_151]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.tjws.TJWSServletDispatcher.service(TJWSServletDispatcher.java:40) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
	at Acme.Serve.Serve$ServeConnection.runServlet(Serve.java:2328) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at Acme.Serve.Serve$ServeConnection.parseRequest(Serve.java:2282) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at Acme.Serve.Serve$ServeConnection.run(Serve.java:2054) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at Acme.Utils$ThreadPool$PooledThread.run(Utils.java:1402) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
{code}

Please notice there is currently NO WAY of having this JSON payload with the proper DMNClient.
This is because the DMNClient currently forbids null-ifying the decision-name or decision-id attribute.
Hence this is a case when not using the Kie Client but directly forging the JSON payload manually (for instance from another/.NET/JS client)

  was:
Only with JSON.
Sending a payload request with example:

{code:java}
{
  "model-namespace" : "http://www.trisotech.com/definitions/_fd2a47fb-a74a-44d7-b26e-cd1a6289839d",
  "model-name" : "Exercise 1.1",
  "decision-name" : null,
  "decision-id" : null,
  "dmn-context" : {"Credit Score" : 4000, "Income" : 50000} 
}
{code}

causes NPE:

{code:java}
23:25:06.509 [Acme.Utils.ThreadPool(1)-PooledThread: Acme.Serve.Serve$ServeConnection at 4d6e768] ERROR o.k.s.s.d.ModelEvaluatorServiceBase - Error from container 'input-data-string'
java.lang.NullPointerException: null
	at org.kie.server.services.dmn.ModelEvaluatorServiceBase.evaluateDecisions(ModelEvaluatorServiceBase.java:143) ~[classes/:na]
	at org.kie.server.remote.rest.dmn.ModelEvaluatorResource.evaluateDecisions(ModelEvaluatorResource.java:108) [kie-server-rest-dmn-7.6.0-SNAPSHOT.jar:7.6.0-SNAPSHOT]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_151]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_151]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_151]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_151]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.tjws.TJWSServletDispatcher.service(TJWSServletDispatcher.java:40) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
	at Acme.Serve.Serve$ServeConnection.runServlet(Serve.java:2328) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at Acme.Serve.Serve$ServeConnection.parseRequest(Serve.java:2282) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at Acme.Serve.Serve$ServeConnection.run(Serve.java:2054) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at Acme.Utils$ThreadPool$PooledThread.run(Utils.java:1402) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
{code}




> DMN JSON payload with decision-name or decision-id null causes NPE
> ------------------------------------------------------------------
>
>                 Key: DROOLS-2234
>                 URL: https://issues.jboss.org/browse/DROOLS-2234
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine, kie server
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>
> Only with JSON.
> Sending a payload request with example:
> {code:java}
> {
>   "model-namespace" : "http://www.trisotech.com/definitions/_fd2a47fb-a74a-44d7-b26e-cd1a6289839d",
>   "model-name" : "Exercise 1.1",
>   "decision-name" : null,
>   "decision-id" : null,
>   "dmn-context" : {"Credit Score" : 4000, "Income" : 50000} 
> }
> {code}
> causes NPE:
> {code:java}
> 23:25:06.509 [Acme.Utils.ThreadPool(1)-PooledThread: Acme.Serve.Serve$ServeConnection at 4d6e768] ERROR o.k.s.s.d.ModelEvaluatorServiceBase - Error from container 'input-data-string'
> java.lang.NullPointerException: null
> 	at org.kie.server.services.dmn.ModelEvaluatorServiceBase.evaluateDecisions(ModelEvaluatorServiceBase.java:143) ~[classes/:na]
> 	at org.kie.server.remote.rest.dmn.ModelEvaluatorResource.evaluateDecisions(ModelEvaluatorResource.java:108) [kie-server-rest-dmn-7.6.0-SNAPSHOT.jar:7.6.0-SNAPSHOT]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_151]
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_151]
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_151]
> 	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_151]
> 	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> 	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> 	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> 	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> 	at org.jboss.resteasy.plugins.server.tjws.TJWSServletDispatcher.service(TJWSServletDispatcher.java:40) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> 	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
> 	at Acme.Serve.Serve$ServeConnection.runServlet(Serve.java:2328) [tjws-3.0.19.Final.jar:3.0.19.Final]
> 	at Acme.Serve.Serve$ServeConnection.parseRequest(Serve.java:2282) [tjws-3.0.19.Final.jar:3.0.19.Final]
> 	at Acme.Serve.Serve$ServeConnection.run(Serve.java:2054) [tjws-3.0.19.Final.jar:3.0.19.Final]
> 	at Acme.Utils$ThreadPool$PooledThread.run(Utils.java:1402) [tjws-3.0.19.Final.jar:3.0.19.Final]
> 	at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
> {code}
> Please notice there is currently NO WAY of having this JSON payload with the proper DMNClient.
> This is because the DMNClient currently forbids null-ifying the decision-name or decision-id attribute.
> Hence this is a case when not using the Kie Client but directly forging the JSON payload manually (for instance from another/.NET/JS client)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 18:03:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Thu, 11 Jan 2018 18:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2235) DMN JSON payload with
 decision-name or decision-id null causes NPE
In-Reply-To: <JIRA.12727618.1515711759000@Atlassian.JIRA>
References: <JIRA.12727618.1515711759000@Atlassian.JIRA>
	<JIRA.12727618.1515711759694@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727618.1515711759000.33878.1515711780078@Atlassian.JIRA>

Matteo Mortari created DROOLS-2235:
--------------------------------------

             Summary: DMN JSON payload with decision-name or decision-id null causes NPE
                 Key: DROOLS-2235
                 URL: https://issues.jboss.org/browse/DROOLS-2235
             Project: Drools
          Issue Type: Bug
          Components: dmn engine, kie server
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari


Only with JSON.
Sending a payload request with example:

{code:java}
{
  "model-namespace" : "http://www.trisotech.com/definitions/_fd2a47fb-a74a-44d7-b26e-cd1a6289839d",
  "model-name" : "Exercise 1.1",
  "decision-name" : null,
  "decision-id" : null,
  "dmn-context" : {"Credit Score" : 4000, "Income" : 50000} 
}
{code}

causes NPE:

{code:java}
23:25:06.509 [Acme.Utils.ThreadPool(1)-PooledThread: Acme.Serve.Serve$ServeConnection at 4d6e768] ERROR o.k.s.s.d.ModelEvaluatorServiceBase - Error from container 'input-data-string'
java.lang.NullPointerException: null
	at org.kie.server.services.dmn.ModelEvaluatorServiceBase.evaluateDecisions(ModelEvaluatorServiceBase.java:143) ~[classes/:na]
	at org.kie.server.remote.rest.dmn.ModelEvaluatorResource.evaluateDecisions(ModelEvaluatorResource.java:108) [kie-server-rest-dmn-7.6.0-SNAPSHOT.jar:7.6.0-SNAPSHOT]
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.8.0_151]
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ~[na:1.8.0_151]
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.8.0_151]
	at java.lang.reflect.Method.invoke(Method.java:498) ~[na:1.8.0_151]
	at org.jboss.resteasy.core.MethodInjectorImpl.invoke(MethodInjectorImpl.java:139) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invokeOnTarget(ResourceMethodInvoker.java:295) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:249) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.ResourceMethodInvoker.invoke(ResourceMethodInvoker.java:236) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:402) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.core.SynchronousDispatcher.invoke(SynchronousDispatcher.java:209) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.servlet.ServletContainerDispatcher.service(ServletContainerDispatcher.java:221) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:56) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.tjws.TJWSServletDispatcher.service(TJWSServletDispatcher.java:40) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at org.jboss.resteasy.plugins.server.servlet.HttpServletDispatcher.service(HttpServletDispatcher.java:51) [resteasy-jaxrs-3.0.19.Final.jar:3.0.19.Final]
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:790) [jboss-servlet-api_3.1_spec-1.0.0.Final.jar:1.0.0.Final]
	at Acme.Serve.Serve$ServeConnection.runServlet(Serve.java:2328) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at Acme.Serve.Serve$ServeConnection.parseRequest(Serve.java:2282) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at Acme.Serve.Serve$ServeConnection.run(Serve.java:2054) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at Acme.Utils$ThreadPool$PooledThread.run(Utils.java:1402) [tjws-3.0.19.Final.jar:3.0.19.Final]
	at java.lang.Thread.run(Thread.java:748) [na:1.8.0_151]
{code}

Please notice there is currently NO WAY of having this JSON payload with the proper DMNClient.
This is because the DMNClient currently forbids null-ifying the decision-name or decision-id attribute.
Hence this is a case when not using the Kie Client but directly forging the JSON payload manually (for instance from another/.NET/JS client)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 18:14:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Thu, 11 Jan 2018 18:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9663) Remove OSGi obsolete code
In-Reply-To: <JIRA.12727619.1515712424000@Atlassian.JIRA>
References: <JIRA.12727619.1515712424000@Atlassian.JIRA>
	<JIRA.12727619.1515712424376@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727619.1515712424000.33890.1515712440065@Atlassian.JIRA>

Richard Opalka created WFLY-9663:
------------------------------------

             Summary: Remove OSGi obsolete code
                 Key: WFLY-9663
                 URL: https://issues.jboss.org/browse/WFLY-9663
             Project: WildFly
          Issue Type: Task
          Components: OSGi
    Affects Versions: 11.0.0.Final
            Reporter: Richard Opalka
            Assignee: Richard Opalka
             Fix For: 12.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 18:29:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 11 Jan 2018 18:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3413) Enhance module descriptions
 with a version number
In-Reply-To: <JIRA.12720511.1510344587000@Atlassian.JIRA>
References: <JIRA.12720511.1510344587000@Atlassian.JIRA>
	<JIRA.12720511.1510344587000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720511.1510344587000.33918.1515713340536@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3413?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFCORE-3413:
----------------------------------------

    Fix Version/s: 4.0.0.Alpha6
         Assignee: David Lloyd
       Resolution: Done


> Enhance module descriptions with a version number
> -------------------------------------------------
>
>                 Key: WFCORE-3413
>                 URL: https://issues.jboss.org/browse/WFCORE-3413
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Modules
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 4.0.0.Alpha6
>
>
> Since JBoss Modules 1.6, a module descriptor may contain a version number.  The version number will appear in stack traces starting in Java 9, so it's useful to add that information in the build process.  It will require a bit of work though because that information will have to be extracted from Maven properties as part of the build process.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 18:54:00 2018
From: issues at jboss.org (Ken Wills (JIRA))
Date: Thu, 11 Jan 2018 18:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3505) Booting a domain slave with
 no cached domain.xml and no available master does not exit as expected
In-Reply-To: <JIRA.12727620.1515714790000@Atlassian.JIRA>
References: <JIRA.12727620.1515714790000@Atlassian.JIRA>
	<JIRA.12727620.1515714790004@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727620.1515714790000.33938.1515714840096@Atlassian.JIRA>

Ken Wills created WFCORE-3505:
---------------------------------

             Summary: Booting a domain slave with no cached domain.xml and no available master does not exit as expected
                 Key: WFCORE-3505
                 URL: https://issues.jboss.org/browse/WFCORE-3505
             Project: WildFly Core
          Issue Type: Bug
            Reporter: Ken Wills






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 18:54:00 2018
From: issues at jboss.org (Ken Wills (JIRA))
Date: Thu, 11 Jan 2018 18:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3505) Booting a domain slave with
 no cached domain.xml and no available master does not exit as expected
In-Reply-To: <JIRA.12727620.1515714790000@Atlassian.JIRA>
References: <JIRA.12727620.1515714790000@Atlassian.JIRA>
	<JIRA.12727620.1515714790000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727620.1515714790000.33941.1515714840197@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills reassigned WFCORE-3505:
---------------------------------

    Assignee: Ken Wills


> Booting a domain slave with no cached domain.xml and no available master does not exit as expected
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3505
>                 URL: https://issues.jboss.org/browse/WFCORE-3505
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 18:58:00 2018
From: issues at jboss.org (Ken Wills (JIRA))
Date: Thu, 11 Jan 2018 18:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3505) Booting a domain slave with
 no cached domain.xml and no available master does not exit as expected
In-Reply-To: <JIRA.12727620.1515714790000@Atlassian.JIRA>
References: <JIRA.12727620.1515714790000@Atlassian.JIRA>
	<JIRA.12727620.1515714790000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727620.1515714790000.33944.1515715080260@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513776#comment-13513776 ] 

Ken Wills commented on WFCORE-3505:
-----------------------------------

As part of the empty config HC work, 0 length configurations were considered to be "empty". This is not correct in the case of domain.xml and a slave using --cached-dc if the master is unavailable on initial boot. 

Since the embedded empty config is always using supressLoad with --empty-domain-config, zero length domain.xml / domain-cached.xml is an error, and result in an exception and exit.

> Booting a domain slave with no cached domain.xml and no available master does not exit as expected
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3505
>                 URL: https://issues.jboss.org/browse/WFCORE-3505
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 18:58:00 2018
From: issues at jboss.org (Ken Wills (JIRA))
Date: Thu, 11 Jan 2018 18:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3505) Booting a domain slave with
 no cached domain.xml and no available master does not exit as expected
In-Reply-To: <JIRA.12727620.1515714790000@Atlassian.JIRA>
References: <JIRA.12727620.1515714790000@Atlassian.JIRA>
	<JIRA.12727620.1515714790000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727620.1515714790000.33946.1515715080338@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills updated WFCORE-3505:
------------------------------
    Comment: was deleted

(was: As part of the empty config HC work, 0 length configurations were considered to be "empty". This is not correct in the case of domain.xml and a slave using --cached-dc if the master is unavailable on initial boot. 

Since the embedded empty config is always using supressLoad with --empty-domain-config, zero length domain.xml / domain-cached.xml is an error, and result in an exception and exit.)


> Booting a domain slave with no cached domain.xml and no available master does not exit as expected
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3505
>                 URL: https://issues.jboss.org/browse/WFCORE-3505
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 11 18:58:00 2018
From: issues at jboss.org (Ken Wills (JIRA))
Date: Thu, 11 Jan 2018 18:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3505) Booting a domain slave with
 no cached domain.xml and no available master does not exit as expected
In-Reply-To: <JIRA.12727620.1515714790000@Atlassian.JIRA>
References: <JIRA.12727620.1515714790000@Atlassian.JIRA>
	<JIRA.12727620.1515714790000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727620.1515714790000.33949.1515715080401@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills updated WFCORE-3505:
------------------------------
    Description: 
As part of the empty config HC work, 0 length configurations were considered to be "empty". This is not correct in the case of domain.xml and a slave using --cached-dc if the master is unavailable on initial boot.

Since the embedded empty config is always using supressLoad with --empty-domain-config, zero length domain.xml / domain-cached.xml is an error, and result in an exception and exit.


> Booting a domain slave with no cached domain.xml and no available master does not exit as expected
> --------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3505
>                 URL: https://issues.jboss.org/browse/WFCORE-3505
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> As part of the empty config HC work, 0 length configurations were considered to be "empty". This is not correct in the case of domain.xml and a slave using --cached-dc if the master is unavailable on initial boot.
> Since the embedded empty config is always using supressLoad with --empty-domain-config, zero length domain.xml / domain-cached.xml is an error, and result in an exception and exit.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 00:11:00 2018
From: issues at jboss.org (jaikiran pai (JIRA))
Date: Fri, 12 Jan 2018 00:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9661) Can't find
 wildfly-spec-api-10.1.0.Final.jar in Maven Central
In-Reply-To: <JIRA.12727566.1515683187000@Atlassian.JIRA>
References: <JIRA.12727566.1515683187000@Atlassian.JIRA>
	<JIRA.12727566.1515683187000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727566.1515683187000.34319.1515733860220@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513831#comment-13513831 ] 

jaikiran pai commented on WFLY-9661:
------------------------------------

{code}
        <dependency>
            <groupId>org.wildfly</groupId>
            <artifactId>wildfly-spec-api</artifactId>
            <version>10.1.0.Final</version>
            <scope>provided</scope>
        </dependency>
{code}

That's missing the {{<type>}} which should be {{pom}}:

{code}
<type>pom</type>
{code}

> Can't find wildfly-spec-api-10.1.0.Final.jar in Maven Central
> -------------------------------------------------------------
>
>                 Key: WFLY-9661
>                 URL: https://issues.jboss.org/browse/WFLY-9661
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Instantiation Exception
>            Assignee: Jason Greene
>
> I have the following Maven configuration:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
>     <modelVersion>4.0.0</modelVersion>
>     <groupId>mycompany</groupId>
>     <artifactId>payment</artifactId>
>     <version>1.0-SNAPSHOT</version>
>     <packaging>war</packaging>
>     <name>payment</name>
>     <properties>
>         <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
>         <maven.compiler.source>1.8</maven.compiler.source>
>         <maven.compiler.target>1.8</maven.compiler.target>
>         <failOnMissingWebXml>false</failOnMissingWebXml>
>     </properties>
>     <dependencyManagement>
>         <dependencies>
>             <dependency>
>                 <groupId>org.wildfly.bom</groupId>
>                 <artifactId>wildfly-javaee7-with-tools</artifactId>
>                 <version>10.1.0.Final</version>
>                 <type>pom</type>
>                 <scope>import</scope>
>             </dependency>
>         </dependencies>
>     </dependencyManagement>
>     <dependencies>
>         <dependency>
>             <groupId>org.wildfly</groupId>
>             <artifactId>wildfly-spec-api</artifactId>
>             <version>10.1.0.Final</version>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.jboss.resteasy</groupId>
>             <artifactId>resteasy-jaxrs</artifactId>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.hibernate</groupId>
>             <artifactId>hibernate-validator</artifactId>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.projectlombok</groupId>
>             <artifactId>lombok</artifactId>
>             <version>1.16.12</version>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.flywaydb</groupId>
>             <artifactId>flyway-core</artifactId>
>             <version>4.0.2</version>
>         </dependency>
>         <dependency>
>             <groupId>com.google.guava</groupId>
>             <artifactId>guava</artifactId>
>             <version>20.0</version>
>         </dependency>
>         <dependency>
>             <groupId>io.rest-assured</groupId>
>             <artifactId>rest-assured</artifactId>
>             <version>3.0.2</version>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>junit</groupId>
>             <artifactId>junit</artifactId>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.hamcrest</groupId>
>             <artifactId>hamcrest-library</artifactId>
>             <version>1.3</version>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.mockito</groupId>
>             <artifactId>mockito-core</artifactId>
>             <version>1.10.19</version>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.jboss.arquillian.junit</groupId>
>             <artifactId>arquillian-junit-container</artifactId>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.jboss.arquillian.graphene</groupId>
>             <artifactId>graphene-webdriver</artifactId>
>             <type>pom</type>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.wildfly.arquillian</groupId>
>             <artifactId>wildfly-arquillian-container-remote</artifactId>
>             <scope>test</scope>
>         </dependency>
>     </dependencies>
>     <build>
>         <finalName>payment</finalName>
>     </build>
> </project>
> {code}
> I type
> {code}
> mvn clean package
> {code}
> and I get following error
> {code}
> [INFO] ------------------------------------------------------------------------
> Downloading: https://repo.maven.apache.org/maven2/org/wildfly/wildfly-spec-api/10.1.0.Final/wildfly-spec-api-10.1.0.Final.jar
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 2.262 s
> [INFO] Finished at: 2018-01-10T15:50:43+01:00
> [INFO] Final Memory: 20M/399M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project payment: Could not resolve dependencies for project mycompany:payment:war:1.0-SNAPSHOT: Could not find artifact org.wildfly:wildfly-spec-api:jar:10.1.0.Final in central (https://repo.maven.apache.org/maven2) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 03:19:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 12 Jan 2018 03:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2236) Cover marshalling of
	UnaryTests
In-Reply-To: <JIRA.12727659.1515745107000@Atlassian.JIRA>
References: <JIRA.12727659.1515745107000@Atlassian.JIRA>
	<JIRA.12727659.1515745107758@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727659.1515745107000.34670.1515745140101@Atlassian.JIRA>

Jozef Marko created DROOLS-2236:
-----------------------------------

             Summary: Cover marshalling of UnaryTests
                 Key: DROOLS-2236
                 URL: https://issues.jboss.org/browse/DROOLS-2236
             Project: Drools
          Issue Type: Task
          Components: DMN Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Jozef Marko
         Attachments: index.html

According to the attached jacoco report, the coverage of marshaling {{UnaryTests}} class should be increased.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 03:27:00 2018
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Fri, 12 Jan 2018 03:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9400) Upgrade to Apache CXF 3.2
 series (through JBossWS 5.2)
In-Reply-To: <JIRA.12713948.1506615392000@Atlassian.JIRA>
References: <JIRA.12713948.1506615392000@Atlassian.JIRA>
	<JIRA.12713948.1506615392000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12713948.1506615392000.34735.1515745620229@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9400?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513870#comment-13513870 ] 

Alessio Soldano commented on WFLY-9400:
---------------------------------------

[~tibor17], we're working on it, the PR for this upgrade is causing some regressions that we're currently dealing with. 

> Upgrade to Apache CXF 3.2 series (through JBossWS 5.2)
> ------------------------------------------------------
>
>                 Key: WFLY-9400
>                 URL: https://issues.jboss.org/browse/WFLY-9400
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Services
>            Reporter: Alessio Soldano
>            Assignee: Alessio Soldano
>             Fix For: 12.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 03:32:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Fri, 12 Jan 2018 03:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3506) Two spaces in help CLI
 command if wrong command is set
In-Reply-To: <JIRA.12727668.1515745877000@Atlassian.JIRA>
References: <JIRA.12727668.1515745877000@Atlassian.JIRA>
	<JIRA.12727668.1515745877837@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727668.1515745877000.34775.1515745920368@Atlassian.JIRA>

Marek Kopeck? created WFCORE-3506:
-------------------------------------

             Summary: Two spaces in help CLI command if wrong command is set
                 Key: WFCORE-3506
                 URL: https://issues.jboss.org/browse/WFCORE-3506
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Marek Kopeck?
            Priority: Trivial


CLI prints two spaces in help CLI command if wrong command is set. Two spaces are before "does" word.

I use [this PR|https://github.com/wildfly/wildfly-core/pull/2946]

*Example:*
{noformat}
[standalone at localhost:9990 /] help nonsence
Command nonsence  does not exist.
[standalone at localhost:9990 /]
{noformat}

*Expected results:*
{noformat}
[standalone at localhost:9990 /] help nonsence
Command nonsence does not exist.
[standalone at localhost:9990 /]
{noformat}




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 12 03:32:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Fri, 12 Jan 2018 03:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3506) Two spaces in help CLI
 command if wrong command is set
In-Reply-To: <JIRA.12727668.1515745878000@Atlassian.JIRA>
References: <JIRA.12727668.1515745878000@Atlassian.JIRA>
	<JIRA.12727668.1515745878000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727668.1515745878000.34779.1515745920494@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? reassigned WFCORE-3506:
-------------------------------------

    Assignee: Jean-Francois Denise


> Two spaces in help CLI command if wrong command is set
> ------------------------------------------------------
>
>                 Key: WFCORE-3506
>                 URL: https://issues.jboss.org/browse/WFCORE-3506
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Marek Kopeck?
>            Assignee: Jean-Francois Denise
>            Priority: Trivial
>
> CLI prints two spaces in help CLI command if wrong command is set. Two spaces are before "does" word.
> I use [this PR|https://github.com/wildfly/wildfly-core/pull/2946]
> *Example:*
> {noformat}
> [standalone at localhost:9990 /] help nonsence
> Command nonsence  does not exist.
> [standalone at localhost:9990 /]
> {noformat}
> *Expected results:*
> {noformat}
> [standalone at localhost:9990 /] help nonsence
> Command nonsence does not exist.
> [standalone at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 12 03:35:00 2018
From: issues at jboss.org (Instantiation Exception (JIRA))
Date: Fri, 12 Jan 2018 03:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9661) Can't find
 wildfly-spec-api-10.1.0.Final.jar in Maven Central
In-Reply-To: <JIRA.12727566.1515683187000@Atlassian.JIRA>
References: <JIRA.12727566.1515683187000@Atlassian.JIRA>
	<JIRA.12727566.1515683187000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727566.1515683187000.34801.1515746100484@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513877#comment-13513877 ] 

Instantiation Exception commented on WFLY-9661:
-----------------------------------------------

[~jaikiran] -- You are right, thanks!

> Can't find wildfly-spec-api-10.1.0.Final.jar in Maven Central
> -------------------------------------------------------------
>
>                 Key: WFLY-9661
>                 URL: https://issues.jboss.org/browse/WFLY-9661
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Instantiation Exception
>            Assignee: Jason Greene
>
> I have the following Maven configuration:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
>     <modelVersion>4.0.0</modelVersion>
>     <groupId>mycompany</groupId>
>     <artifactId>payment</artifactId>
>     <version>1.0-SNAPSHOT</version>
>     <packaging>war</packaging>
>     <name>payment</name>
>     <properties>
>         <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
>         <maven.compiler.source>1.8</maven.compiler.source>
>         <maven.compiler.target>1.8</maven.compiler.target>
>         <failOnMissingWebXml>false</failOnMissingWebXml>
>     </properties>
>     <dependencyManagement>
>         <dependencies>
>             <dependency>
>                 <groupId>org.wildfly.bom</groupId>
>                 <artifactId>wildfly-javaee7-with-tools</artifactId>
>                 <version>10.1.0.Final</version>
>                 <type>pom</type>
>                 <scope>import</scope>
>             </dependency>
>         </dependencies>
>     </dependencyManagement>
>     <dependencies>
>         <dependency>
>             <groupId>org.wildfly</groupId>
>             <artifactId>wildfly-spec-api</artifactId>
>             <version>10.1.0.Final</version>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.jboss.resteasy</groupId>
>             <artifactId>resteasy-jaxrs</artifactId>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.hibernate</groupId>
>             <artifactId>hibernate-validator</artifactId>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.projectlombok</groupId>
>             <artifactId>lombok</artifactId>
>             <version>1.16.12</version>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.flywaydb</groupId>
>             <artifactId>flyway-core</artifactId>
>             <version>4.0.2</version>
>         </dependency>
>         <dependency>
>             <groupId>com.google.guava</groupId>
>             <artifactId>guava</artifactId>
>             <version>20.0</version>
>         </dependency>
>         <dependency>
>             <groupId>io.rest-assured</groupId>
>             <artifactId>rest-assured</artifactId>
>             <version>3.0.2</version>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>junit</groupId>
>             <artifactId>junit</artifactId>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.hamcrest</groupId>
>             <artifactId>hamcrest-library</artifactId>
>             <version>1.3</version>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.mockito</groupId>
>             <artifactId>mockito-core</artifactId>
>             <version>1.10.19</version>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.jboss.arquillian.junit</groupId>
>             <artifactId>arquillian-junit-container</artifactId>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.jboss.arquillian.graphene</groupId>
>             <artifactId>graphene-webdriver</artifactId>
>             <type>pom</type>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.wildfly.arquillian</groupId>
>             <artifactId>wildfly-arquillian-container-remote</artifactId>
>             <scope>test</scope>
>         </dependency>
>     </dependencies>
>     <build>
>         <finalName>payment</finalName>
>     </build>
> </project>
> {code}
> I type
> {code}
> mvn clean package
> {code}
> and I get following error
> {code}
> [INFO] ------------------------------------------------------------------------
> Downloading: https://repo.maven.apache.org/maven2/org/wildfly/wildfly-spec-api/10.1.0.Final/wildfly-spec-api-10.1.0.Final.jar
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 2.262 s
> [INFO] Finished at: 2018-01-10T15:50:43+01:00
> [INFO] Final Memory: 20M/399M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project payment: Could not resolve dependencies for project mycompany:payment:war:1.0-SNAPSHOT: Could not find artifact org.wildfly:wildfly-spec-api:jar:10.1.0.Final in central (https://repo.maven.apache.org/maven2) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 03:37:00 2018
From: issues at jboss.org (Instantiation Exception (JIRA))
Date: Fri, 12 Jan 2018 03:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9661) Can't find
 wildfly-spec-api-10.1.0.Final.jar in Maven Central
In-Reply-To: <JIRA.12727566.1515683187000@Atlassian.JIRA>
References: <JIRA.12727566.1515683187000@Atlassian.JIRA>
	<JIRA.12727566.1515683187000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727566.1515683187000.34814.1515746220371@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Instantiation Exception closed WFLY-9661.
-----------------------------------------
    Resolution: Explained


> Can't find wildfly-spec-api-10.1.0.Final.jar in Maven Central
> -------------------------------------------------------------
>
>                 Key: WFLY-9661
>                 URL: https://issues.jboss.org/browse/WFLY-9661
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Instantiation Exception
>            Assignee: Jason Greene
>
> I have the following Maven configuration:
> {code:xml}
> <?xml version="1.0" encoding="UTF-8"?>
> <project xmlns="http://maven.apache.org/POM/4.0.0"
>          xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
>          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
>     <modelVersion>4.0.0</modelVersion>
>     <groupId>mycompany</groupId>
>     <artifactId>payment</artifactId>
>     <version>1.0-SNAPSHOT</version>
>     <packaging>war</packaging>
>     <name>payment</name>
>     <properties>
>         <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
>         <maven.compiler.source>1.8</maven.compiler.source>
>         <maven.compiler.target>1.8</maven.compiler.target>
>         <failOnMissingWebXml>false</failOnMissingWebXml>
>     </properties>
>     <dependencyManagement>
>         <dependencies>
>             <dependency>
>                 <groupId>org.wildfly.bom</groupId>
>                 <artifactId>wildfly-javaee7-with-tools</artifactId>
>                 <version>10.1.0.Final</version>
>                 <type>pom</type>
>                 <scope>import</scope>
>             </dependency>
>         </dependencies>
>     </dependencyManagement>
>     <dependencies>
>         <dependency>
>             <groupId>org.wildfly</groupId>
>             <artifactId>wildfly-spec-api</artifactId>
>             <version>10.1.0.Final</version>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.jboss.resteasy</groupId>
>             <artifactId>resteasy-jaxrs</artifactId>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.hibernate</groupId>
>             <artifactId>hibernate-validator</artifactId>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.projectlombok</groupId>
>             <artifactId>lombok</artifactId>
>             <version>1.16.12</version>
>             <scope>provided</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.flywaydb</groupId>
>             <artifactId>flyway-core</artifactId>
>             <version>4.0.2</version>
>         </dependency>
>         <dependency>
>             <groupId>com.google.guava</groupId>
>             <artifactId>guava</artifactId>
>             <version>20.0</version>
>         </dependency>
>         <dependency>
>             <groupId>io.rest-assured</groupId>
>             <artifactId>rest-assured</artifactId>
>             <version>3.0.2</version>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>junit</groupId>
>             <artifactId>junit</artifactId>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.hamcrest</groupId>
>             <artifactId>hamcrest-library</artifactId>
>             <version>1.3</version>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.mockito</groupId>
>             <artifactId>mockito-core</artifactId>
>             <version>1.10.19</version>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.jboss.arquillian.junit</groupId>
>             <artifactId>arquillian-junit-container</artifactId>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.jboss.arquillian.graphene</groupId>
>             <artifactId>graphene-webdriver</artifactId>
>             <type>pom</type>
>             <scope>test</scope>
>         </dependency>
>         <dependency>
>             <groupId>org.wildfly.arquillian</groupId>
>             <artifactId>wildfly-arquillian-container-remote</artifactId>
>             <scope>test</scope>
>         </dependency>
>     </dependencies>
>     <build>
>         <finalName>payment</finalName>
>     </build>
> </project>
> {code}
> I type
> {code}
> mvn clean package
> {code}
> and I get following error
> {code}
> [INFO] ------------------------------------------------------------------------
> Downloading: https://repo.maven.apache.org/maven2/org/wildfly/wildfly-spec-api/10.1.0.Final/wildfly-spec-api-10.1.0.Final.jar
> [INFO] ------------------------------------------------------------------------
> [INFO] BUILD FAILURE
> [INFO] ------------------------------------------------------------------------
> [INFO] Total time: 2.262 s
> [INFO] Finished at: 2018-01-10T15:50:43+01:00
> [INFO] Final Memory: 20M/399M
> [INFO] ------------------------------------------------------------------------
> [ERROR] Failed to execute goal on project payment: Could not resolve dependencies for project mycompany:payment:war:1.0-SNAPSHOT: Could not find artifact org.wildfly:wildfly-spec-api:jar:10.1.0.Final in central (https://repo.maven.apache.org/maven2) -> [Help 1]
> [ERROR]
> [ERROR] To see the full stack trace of the errors, re-run Maven with the -e switch.
> [ERROR] Re-run Maven using the -X switch to enable full debug logging.
> [ERROR]
> [ERROR] For more information about the errors and possible solutions, please read the following articles:
> [ERROR] [Help 1] http://cwiki.apache.org/confluence/display/MAVEN/DependencyResolutionException
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 04:54:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 12 Jan 2018 04:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3506) Two spaces in help CLI
 command if wrong command is set
In-Reply-To: <JIRA.12727668.1515745878000@Atlassian.JIRA>
References: <JIRA.12727668.1515745878000@Atlassian.JIRA>
	<JIRA.12727668.1515745878000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727668.1515745878000.35244.1515750840428@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3506?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13513913#comment-13513913 ] 

Jean-Francois Denise commented on WFCORE-3506:
----------------------------------------------

Good catch, fixed in PR branch. Thanks.

> Two spaces in help CLI command if wrong command is set
> ------------------------------------------------------
>
>                 Key: WFCORE-3506
>                 URL: https://issues.jboss.org/browse/WFCORE-3506
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Marek Kopeck?
>            Assignee: Jean-Francois Denise
>            Priority: Trivial
>
> CLI prints two spaces in help CLI command if wrong command is set. Two spaces are before "does" word.
> I use [this PR|https://github.com/wildfly/wildfly-core/pull/2946]
> *Example:*
> {noformat}
> [standalone at localhost:9990 /] help nonsence
> Command nonsence  does not exist.
> [standalone at localhost:9990 /]
> {noformat}
> *Expected results:*
> {noformat}
> [standalone at localhost:9990 /] help nonsence
> Command nonsence does not exist.
> [standalone at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 12 06:24:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 12 Jan 2018 06:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2237) Turn on CheckStyle for dmn
	editor
In-Reply-To: <JIRA.12727749.1515756238000@Atlassian.JIRA>
References: <JIRA.12727749.1515756238000@Atlassian.JIRA>
	<JIRA.12727749.1515756238155@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727749.1515756238000.35862.1515756240906@Atlassian.JIRA>

Jozef Marko created DROOLS-2237:
-----------------------------------

             Summary: Turn on CheckStyle for dmn editor
                 Key: DROOLS-2237
                 URL: https://issues.jboss.org/browse/DROOLS-2237
             Project: Drools
          Issue Type: Task
          Components: DMN Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Jozef Marko


Turn of the CheckStyle control of imports and licences for the dmn editor.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 07:38:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 12 Jan 2018 07:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2238) Property reactivity mask is
 not correctly calculated for nodes having a TimerNode as sink
In-Reply-To: <JIRA.12727785.1515760622000@Atlassian.JIRA>
References: <JIRA.12727785.1515760622000@Atlassian.JIRA>
	<JIRA.12727785.1515760622329@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727785.1515760622000.36267.1515760680094@Atlassian.JIRA>

Mario Fusco created DROOLS-2238:
-----------------------------------

             Summary: Property reactivity mask is not correctly calculated for nodes having a TimerNode as sink
                 Key: DROOLS-2238
                 URL: https://issues.jboss.org/browse/DROOLS-2238
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Mario Fusco
            Assignee: Mario Fusco






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 07:44:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 12 Jan 2018 07:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2238) Property reactivity mask is
 not correctly calculated for nodes having a TimerNode as sink
In-Reply-To: <JIRA.12727785.1515760622000@Atlassian.JIRA>
References: <JIRA.12727785.1515760622000@Atlassian.JIRA>
	<JIRA.12727785.1515760622000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727785.1515760622000.36297.1515761040072@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2238?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-2238.
---------------------------------
    Resolution: Done


Fixed by https://github.com/kiegroup/drools/commit/dbfdf7cfcc3c2e59c7c9ffd08f066162ee8adddb

> Property reactivity mask is not correctly calculated for nodes having a TimerNode as sink
> -----------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2238
>                 URL: https://issues.jboss.org/browse/DROOLS-2238
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 08:06:00 2018
From: issues at jboss.org (Serg Pol (JIRA))
Date: Fri, 12 Jan 2018 08:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.36536.1515762360234@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514067#comment-13514067 ] 

Serg Pol commented on WFLY-9610:
--------------------------------

thanks. do You know occasionally why status STOPPING was not saved in DB till free available Thread? Will You publicise changes in java Class for fix?

> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 08:55:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 12 Jan 2018 08:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2239) Property reactivity mask is
 not correctly calculated for nodes having a TimerNode as sink
In-Reply-To: <JIRA.12727807.1515765270000@Atlassian.JIRA>
References: <JIRA.12727807.1515765270000@Atlassian.JIRA>
	<JIRA.12727807.1515765270111@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727807.1515765270000.36854.1515765300573@Atlassian.JIRA>

Mario Fusco created DROOLS-2239:
-----------------------------------

             Summary: Property reactivity mask is not correctly calculated for nodes having a TimerNode as sink
                 Key: DROOLS-2239
                 URL: https://issues.jboss.org/browse/DROOLS-2239
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Mario Fusco
            Assignee: Mario Fusco






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 09:12:02 2018
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 12 Jan 2018 09:12:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9483) Upgrade Netty to 4.1.19.Final
In-Reply-To: <JIRA.12718132.1508948536000@Atlassian.JIRA>
References: <JIRA.12718132.1508948536000@Atlassian.JIRA>
	<JIRA.12718132.1508948536000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718132.1508948536000.37138.1515766322596@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-9483:
------------------------------
    Summary: Upgrade Netty to 4.1.19.Final  (was: Upgrade Netty to 4.1.16.Final)


> Upgrade Netty to 4.1.19.Final
> -----------------------------
>
>                 Key: WFLY-9483
>                 URL: https://issues.jboss.org/browse/WFLY-9483
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 12.0.0.Alpha1
>
>
> https://github.com/netty/netty/compare/netty-4.1.9.Final...netty-4.1.16.Final



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 09:12:03 2018
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 12 Jan 2018 09:12:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9483) Upgrade Netty to 4.1.19.Final
In-Reply-To: <JIRA.12718132.1508948536000@Atlassian.JIRA>
References: <JIRA.12718132.1508948536000@Atlassian.JIRA>
	<JIRA.12718132.1508948536000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718132.1508948536000.37146.1515766323419@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-9483:
------------------------------
    Description: https://github.com/netty/netty/compare/netty-4.1.9.Final...netty-4.1.19.Final  (was: https://github.com/netty/netty/compare/netty-4.1.9.Final...netty-4.1.16.Final)


> Upgrade Netty to 4.1.19.Final
> -----------------------------
>
>                 Key: WFLY-9483
>                 URL: https://issues.jboss.org/browse/WFLY-9483
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 12.0.0.Alpha1
>
>
> https://github.com/netty/netty/compare/netty-4.1.9.Final...netty-4.1.19.Final



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 09:13:02 2018
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 12 Jan 2018 09:13:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9484) Upgrade netty-xnio-transport
 to 0.1.4.Final
In-Reply-To: <JIRA.12718133.1508948714000@Atlassian.JIRA>
References: <JIRA.12718133.1508948714000@Atlassian.JIRA>
	<JIRA.12718133.1508948714000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718133.1508948714000.37172.1515766382231@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9484?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-9484:
------------------------------
    Summary: Upgrade netty-xnio-transport to 0.1.4.Final  (was: Upgrade netty-xnio-transport to 0.1.3.Final)


> Upgrade netty-xnio-transport to 0.1.4.Final
> -------------------------------------------
>
>                 Key: WFLY-9484
>                 URL: https://issues.jboss.org/browse/WFLY-9484
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>             Fix For: 12.0.0.Alpha1
>
>
> netty-xnio-transport must be updated to the version of XNIO and netty used in WildFly with Artemis 2.x releases



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 09:32:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 12 Jan 2018 09:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8416) Create BroadcastEndpoint
 implementation using WF clustering API
In-Reply-To: <JIRA.12683729.1490134159000@Atlassian.JIRA>
References: <JIRA.12683729.1490134159000@Atlassian.JIRA>
	<JIRA.12683729.1490134159000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12683729.1490134159000.37369.1515767520961@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8416?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro closed WFLY-8416.
------------------------------
    Resolution: Duplicate Issue


Duplicate of WFLY-9271.

> Create BroadcastEndpoint implementation using WF clustering API
> ---------------------------------------------------------------
>
>                 Key: WFLY-8416
>                 URL: https://issues.jboss.org/browse/WFLY-8416
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering, JMS
>    Affects Versions: 10.1.0.Final
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 12.0.0.Alpha1
>
>
> The upgrade to JGroups 4.0 will break the JGroups BroadcastEndpoint implementation in ActiveMQ Artemis (which uses JGroups 3.x).  JGroups is only used to broadcast/receive a byte[] to the cluster.  This can be easily implemented using the WildFly clustering API.  Such an implementation will simplify the transition to JGroups 4.0 and future-proof WildFly from any new API breakage as well as abstract away concepts like fork channels, etc.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 09:39:02 2018
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Fri, 12 Jan 2018 09:39:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2233) DMN:
 time(date("2017-08-10")) should return 00:00:00z time
In-Reply-To: <JIRA.12727497.1515672063000@Atlassian.JIRA>
References: <JIRA.12727497.1515672063000@Atlassian.JIRA>
	<JIRA.12727497.1515672063000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727497.1515672063000.37459.1515767942063@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tibor Zim?nyi updated DROOLS-2233:
----------------------------------
    Description: 
According to the specification in section "10.3.2.3.5 date": 
"Where necessary, including the valuedt function (see 10.3.2.x.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00)."

Currently the case time(date("2017-08-10")) returns null, because the evaluation ends with DateTimeException, because internally we represent dates as LocalDate class, which doesn't have time part. 

  was:
According to the specification in section "10.3.2.3.5 date": 
"Where necessary, including the valuedt function (see 10.3.2.x.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00)."

Currently the case time(date("2017-08-10")) returns null, because the evaluation ends with DateTimeException, because internally we represent dates as LocalDate class, which doesn't have time part. 

I will provide a PR with a fix.



> DMN: time(date("2017-08-10")) should return 00:00:00z time
> ----------------------------------------------------------
>
>                 Key: DROOLS-2233
>                 URL: https://issues.jboss.org/browse/DROOLS-2233
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Tibor Zim?nyi
>
> According to the specification in section "10.3.2.3.5 date": 
> "Where necessary, including the valuedt function (see 10.3.2.x.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00)."
> Currently the case time(date("2017-08-10")) returns null, because the evaluation ends with DateTimeException, because internally we represent dates as LocalDate class, which doesn't have time part. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 12 09:39:02 2018
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Fri, 12 Jan 2018 09:39:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2233) DMN:
 time(date("2017-08-10")) should return 00:00:00z time
In-Reply-To: <JIRA.12727497.1515672063000@Atlassian.JIRA>
References: <JIRA.12727497.1515672063000@Atlassian.JIRA>
	<JIRA.12727497.1515672063000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727497.1515672063000.37461.1515767942159@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514160#comment-13514160 ] 

Tibor Zim?nyi commented on DROOLS-2233:
---------------------------------------

Solved as part of this PR: https://github.com/kiegroup/drools/pull/1688

> DMN: time(date("2017-08-10")) should return 00:00:00z time
> ----------------------------------------------------------
>
>                 Key: DROOLS-2233
>                 URL: https://issues.jboss.org/browse/DROOLS-2233
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Tibor Zim?nyi
>
> According to the specification in section "10.3.2.3.5 date": 
> "Where necessary, including the valuedt function (see 10.3.2.x.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00)."
> Currently the case time(date("2017-08-10")) returns null, because the evaluation ends with DateTimeException, because internally we represent dates as LocalDate class, which doesn't have time part. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 12 09:42:00 2018
From: issues at jboss.org (Christian Bauer (JIRA))
Date: Fri, 12 Jan 2018 09:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2240) Timer rules with pseudo
	clock don't fire
In-Reply-To: <JIRA.12727827.1515768108000@Atlassian.JIRA>
References: <JIRA.12727827.1515768108000@Atlassian.JIRA>
	<JIRA.12727827.1515768108954@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727827.1515768108000.37481.1515768120618@Atlassian.JIRA>

Christian Bauer created DROOLS-2240:
---------------------------------------

             Summary: Timer rules with pseudo clock don't fire
                 Key: DROOLS-2240
                 URL: https://issues.jboss.org/browse/DROOLS-2240
             Project: Drools
          Issue Type: Bug
    Affects Versions: 7.5.0.Final
            Reporter: Christian Bauer
            Assignee: Edson Tirelli


We are trying to test rules with timer option and the pseudo clock. 

The problem can probably also be seen by enabling (note the @Ignore) this test: https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CepFireUntilHaltTimerTest.java

Based on this class, this is a minimal test that shows the problem:

{code}
import org.drools.core.time.SessionPseudoClock;
import org.junit.Test;
import org.kie.api.KieServices;
import org.kie.api.builder.KieFileSystem;
import org.kie.api.builder.model.KieBaseModel;
import org.kie.api.builder.model.KieModuleModel;
import org.kie.api.runtime.KieSession;
import org.kie.api.runtime.conf.ClockTypeOption;

import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.Future;
import java.util.concurrent.TimeUnit;

import static org.junit.Assert.assertEquals;

/**
 * Based on:
 * https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CepFireUntilHaltTimerTest.java
 */
public class PseudoClockTimerTest {

    private KieSession ksession;
    private SessionPseudoClock clock;

    public void init(String clockType) {
        String drl = "package test.rules\n" +
            "\n" +
            "rule \"Do something triggered by timer\"\n" +
            "timer (int: 1s 1s)\n" +
            "then\n" +
            "    System.out.println(\"### DO SOMETHING \" + drools.getWorkingMemory().getSessionClock().getCurrentTime());\n" +
            "    insert(\"### TIME IS \" + drools.getWorkingMemory().getSessionClock().getCurrentTime());\n" +
            "end\n";

        KieServices ks = KieServices.Factory.get();

        KieModuleModel module = ks.newKieModuleModel();

        KieBaseModel defaultBase = module.newKieBaseModel("defaultKBase")
            .setDefault(true)
            .addPackage("*");
        defaultBase.newKieSessionModel("defaultKSession")
            .setDefault(true)
            .setClockType(ClockTypeOption.get(clockType));

        KieFileSystem kfs = ks.newKieFileSystem()
            .write("src/main/resources/r1.drl", drl);
        kfs.writeKModuleXML(module.toXML());
        ks.newKieBuilder(kfs).buildAll();

        ksession = ks.newKieContainer(ks.getRepository().getDefaultReleaseId())
            .newKieSession();

        if (clockType.equals("pseudo"))
            clock = ksession.getSessionClock();
    }

    public void cleanup() {
        ksession.dispose();
    }

    @Test
    public void testTimerExecution() throws Exception {

        init("realtime");
        performRealtimeClockTest();
        cleanup();

        init("pseudo");
        performPseudoClockTest();
        cleanup();
    }

    private void performRealtimeClockTest() throws Exception {
        ExecutorService thread = Executors.newSingleThreadExecutor();
        final Future fireUntilHaltResult = thread.submit(() -> ksession.fireUntilHalt());

        try {
            Thread.sleep(10500);
            assertEquals(10, ksession.getFactCount());
        } finally {
            ksession.halt();
            fireUntilHaltResult.get(60000, TimeUnit.SECONDS);
            thread.shutdown();
        }
    }

    private void performPseudoClockTest() throws Exception {
        ExecutorService thread = Executors.newSingleThreadExecutor();
        final Future fireUntilHaltResult = thread.submit(() -> ksession.fireUntilHalt());

        try {
            Thread.sleep(500);

            // NOT WORKING:
            // clock.advanceTime(10, TimeUnit.SECONDS);
            // Thread.sleep(50);

            // WORKAROUND:
            for (int i = 0; i < 10; i++) {
                clock.advanceTime(1, TimeUnit.SECONDS);
                Thread.sleep(50);
            }

            assertEquals(10, ksession.getFactCount());
        } finally {
            ksession.halt();
            fireUntilHaltResult.get(60000, TimeUnit.SECONDS);
            thread.shutdown();
        }
    }
}
{code}

See the NOT WORKING and WORKAROUND markers. There doesn't seem to be any other test in the codebase with timer rules and the pseudo clock, so our conclusion is that this combination is not working at all.





--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 09:44:00 2018
From: issues at jboss.org (Pedro Igor (JIRA))
Date: Fri, 12 Jan 2018 09:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1486) Support
 credential-store-reference in oauth2-bearer-token client configuration
In-Reply-To: <JIRA.12727557.1515681446000@Atlassian.JIRA>
References: <JIRA.12727557.1515681446000@Atlassian.JIRA>
	<JIRA.12727557.1515681446000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727557.1515681446000.37516.1515768240824@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Pedro Igor closed ELY-1486.
---------------------------
    Resolution: Duplicate Issue


> Support credential-store-reference in oauth2-bearer-token client configuration
> ------------------------------------------------------------------------------
>
>                 Key: ELY-1486
>                 URL: https://issues.jboss.org/browse/ELY-1486
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Client
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Pedro Igor
>            Assignee: Pedro Igor
>
> Currently, when using oauth2-bearer-token in client configuration, passwords and client secrets are defined in clear format.
> This issue aims to support obtaining these credentials from a credential store.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 09:47:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 12 Jan 2018 09:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3507) CLI,
	use arrow Down key to scroll
In-Reply-To: <JIRA.12727830.1515768396000@Atlassian.JIRA>
References: <JIRA.12727830.1515768396000@Atlassian.JIRA>
	<JIRA.12727830.1515768396908@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727830.1515768396000.37547.1515768420403@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-3507:
--------------------------------------------

             Summary: CLI, use arrow Down key to scroll
                 Key: WFCORE-3507
                 URL: https://issues.jboss.org/browse/WFCORE-3507
             Project: WildFly Core
          Issue Type: Enhancement
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


In addition to return key, Down arrow is an obvious way to scroll a line of content.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 09:57:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Fri, 12 Jan 2018 09:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2240) Timer rules with pseudo
	clock don't fire
In-Reply-To: <JIRA.12727827.1515768109000@Atlassian.JIRA>
References: <JIRA.12727827.1515768109000@Atlassian.JIRA>
	<JIRA.12727827.1515768109000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727827.1515768109000.37682.1515769020850@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned DROOLS-2240:
-------------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)


> Timer rules with pseudo clock don't fire
> ----------------------------------------
>
>                 Key: DROOLS-2240
>                 URL: https://issues.jboss.org/browse/DROOLS-2240
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Christian Bauer
>            Assignee: Mario Fusco
>
> We are trying to test rules with timer option and the pseudo clock. 
> The problem can probably also be seen by enabling (note the @Ignore) this test: https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CepFireUntilHaltTimerTest.java
> Based on this class, this is a minimal test that shows the problem:
> {code}
> import org.drools.core.time.SessionPseudoClock;
> import org.junit.Test;
> import org.kie.api.KieServices;
> import org.kie.api.builder.KieFileSystem;
> import org.kie.api.builder.model.KieBaseModel;
> import org.kie.api.builder.model.KieModuleModel;
> import org.kie.api.runtime.KieSession;
> import org.kie.api.runtime.conf.ClockTypeOption;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> import java.util.concurrent.Future;
> import java.util.concurrent.TimeUnit;
> import static org.junit.Assert.assertEquals;
> /**
>  * Based on:
>  * https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CepFireUntilHaltTimerTest.java
>  */
> public class PseudoClockTimerTest {
>     private KieSession ksession;
>     private SessionPseudoClock clock;
>     public void init(String clockType) {
>         String drl = "package test.rules\n" +
>             "\n" +
>             "rule \"Do something triggered by timer\"\n" +
>             "timer (int: 1s 1s)\n" +
>             "then\n" +
>             "    System.out.println(\"### DO SOMETHING \" + drools.getWorkingMemory().getSessionClock().getCurrentTime());\n" +
>             "    insert(\"### TIME IS \" + drools.getWorkingMemory().getSessionClock().getCurrentTime());\n" +
>             "end\n";
>         KieServices ks = KieServices.Factory.get();
>         KieModuleModel module = ks.newKieModuleModel();
>         KieBaseModel defaultBase = module.newKieBaseModel("defaultKBase")
>             .setDefault(true)
>             .addPackage("*");
>         defaultBase.newKieSessionModel("defaultKSession")
>             .setDefault(true)
>             .setClockType(ClockTypeOption.get(clockType));
>         KieFileSystem kfs = ks.newKieFileSystem()
>             .write("src/main/resources/r1.drl", drl);
>         kfs.writeKModuleXML(module.toXML());
>         ks.newKieBuilder(kfs).buildAll();
>         ksession = ks.newKieContainer(ks.getRepository().getDefaultReleaseId())
>             .newKieSession();
>         if (clockType.equals("pseudo"))
>             clock = ksession.getSessionClock();
>     }
>     public void cleanup() {
>         ksession.dispose();
>     }
>     @Test
>     public void testTimerExecution() throws Exception {
>         init("realtime");
>         performRealtimeClockTest();
>         cleanup();
>         init("pseudo");
>         performPseudoClockTest();
>         cleanup();
>     }
>     private void performRealtimeClockTest() throws Exception {
>         ExecutorService thread = Executors.newSingleThreadExecutor();
>         final Future fireUntilHaltResult = thread.submit(() -> ksession.fireUntilHalt());
>         try {
>             Thread.sleep(10500);
>             assertEquals(10, ksession.getFactCount());
>         } finally {
>             ksession.halt();
>             fireUntilHaltResult.get(60000, TimeUnit.SECONDS);
>             thread.shutdown();
>         }
>     }
>     private void performPseudoClockTest() throws Exception {
>         ExecutorService thread = Executors.newSingleThreadExecutor();
>         final Future fireUntilHaltResult = thread.submit(() -> ksession.fireUntilHalt());
>         try {
>             Thread.sleep(500);
>             // NOT WORKING:
>             // clock.advanceTime(10, TimeUnit.SECONDS);
>             // Thread.sleep(50);
>             // WORKAROUND:
>             for (int i = 0; i < 10; i++) {
>                 clock.advanceTime(1, TimeUnit.SECONDS);
>                 Thread.sleep(50);
>             }
>             assertEquals(10, ksession.getFactCount());
>         } finally {
>             ksession.halt();
>             fireUntilHaltResult.get(60000, TimeUnit.SECONDS);
>             thread.shutdown();
>         }
>     }
> }
> {code}
> See the NOT WORKING and WORKAROUND markers. There doesn't seem to be any other test in the codebase with timer rules and the pseudo clock, so our conclusion is that this combination is not working at all.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 09:59:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 12 Jan 2018 09:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2241) Wrong pattern cloning
 causes missing FromNode sharing and eventually a NPE
In-Reply-To: <JIRA.12727833.1515769108000@Atlassian.JIRA>
References: <JIRA.12727833.1515769108000@Atlassian.JIRA>
	<JIRA.12727833.1515769108876@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727833.1515769108000.37717.1515769140265@Atlassian.JIRA>

Mario Fusco created DROOLS-2241:
-----------------------------------

             Summary: Wrong pattern cloning causes missing FromNode sharing and eventually a NPE
                 Key: DROOLS-2241
                 URL: https://issues.jboss.org/browse/DROOLS-2241
             Project: Drools
          Issue Type: Bug
            Reporter: Mario Fusco
            Assignee: Mario Fusco


Wrong cloning of a pattern having a FromNode as source causes wrong initialization of both node and pattern which in turn prevents sharing of FromNode when possible. 

Even worse when the duplicated FromNode are part of a subnetwork also the RiaNode at the end of the subnetwork is wrongly initialized leading to a NPE like the following:

{node}
java.lang.NullPointerException
	at org.drools.core.reteoo.RiaPathMemory.initDataDriven(RiaPathMemory.java:35)
	at org.drools.core.reteoo.PathMemory.<init>(PathMemory.java:50)
{node}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 10:01:00 2018
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Fri, 12 Jan 2018 10:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.37727.1515769260352@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514186#comment-13514186 ] 

Cheng Fang commented on WFLY-9610:
----------------------------------

After a job execution is submitted, a new job execution entry is created and inserted into job repository db, whether it will be on hold or not.  And the next time it is updated to the db is when the job execution gets the chance to run with available thread and so it can update itself into the db with new batch status.

the change to {{org.jberet.runtime.runner.JobExecutionRunner}}:
https://github.com/jberet/jsr352/commit/f27fb499aea1232bec1ee8050cb995e37929b3eb

The real change is moving the end curl brace from line 50 to line 84 to expand the if condition block so that the processing is skipped in case of STOPPING.



> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 10:07:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 12 Jan 2018 10:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2241) Wrong pattern cloning
 causes missing FromNode sharing and eventually a NPE
In-Reply-To: <JIRA.12727833.1515769109000@Atlassian.JIRA>
References: <JIRA.12727833.1515769109000@Atlassian.JIRA>
	<JIRA.12727833.1515769109000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727833.1515769109000.37788.1515769620875@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-2241.
---------------------------------
    Resolution: Done


Fixed by https://github.com/kiegroup/drools/commit/50625d913cae7ac7aea17232f2ab59ea16d36894

> Wrong pattern cloning causes missing FromNode sharing and eventually a NPE
> --------------------------------------------------------------------------
>
>                 Key: DROOLS-2241
>                 URL: https://issues.jboss.org/browse/DROOLS-2241
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>
> Wrong cloning of a pattern having a FromNode as source causes wrong initialization of both node and pattern which in turn prevents sharing of FromNode when possible. 
> Even worse when the duplicated FromNode are part of a subnetwork also the RiaNode at the end of the subnetwork is wrongly initialized leading to a NPE like the following:
> {node}
> java.lang.NullPointerException
> 	at org.drools.core.reteoo.RiaPathMemory.initDataDriven(RiaPathMemory.java:35)
> 	at org.drools.core.reteoo.PathMemory.<init>(PathMemory.java:50)
> {node}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 10:08:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 12 Jan 2018 10:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2242) Wrong pattern cloning
 causes missing FromNode sharing and eventually a NPE
In-Reply-To: <JIRA.12727836.1515769666000@Atlassian.JIRA>
References: <JIRA.12727836.1515769666000@Atlassian.JIRA>
	<JIRA.12727836.1515769666305@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727836.1515769666000.37810.1515769680283@Atlassian.JIRA>

Mario Fusco created DROOLS-2242:
-----------------------------------

             Summary: Wrong pattern cloning causes missing FromNode sharing and eventually a NPE
                 Key: DROOLS-2242
                 URL: https://issues.jboss.org/browse/DROOLS-2242
             Project: Drools
          Issue Type: Bug
            Reporter: Mario Fusco
            Assignee: Mario Fusco


Wrong cloning of a pattern having a FromNode as source causes wrong initialization of both node and pattern which in turn prevents sharing of FromNode when possible. 

Even worse when the duplicated FromNode are part of a subnetwork also the RiaNode at the end of the subnetwork is wrongly initialized leading to a NPE like the following:

{node}
java.lang.NullPointerException
	at org.drools.core.reteoo.RiaPathMemory.initDataDriven(RiaPathMemory.java:35)
	at org.drools.core.reteoo.PathMemory.<init>(PathMemory.java:50)
{node}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 10:41:00 2018
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 12 Jan 2018 10:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9591) Emulate Artemis 1.x address
	convention
In-Reply-To: <JIRA.12723267.1512385966000@Atlassian.JIRA>
References: <JIRA.12723267.1512385966000@Atlassian.JIRA>
	<JIRA.12723267.1512385966000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723267.1512385966000.38182.1515771660563@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-9591:
------------------------------
    Summary: Emulate Artemis 1.x address convention  (was: Correct attributes representing Artemis addresses)


> Emulate Artemis 1.x address convention
> --------------------------------------
>
>                 Key: WFLY-9591
>                 URL: https://issues.jboss.org/browse/WFLY-9591
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>
> Artemis 2.x has changed the naming convention for its resources.
> JMS Queue (resp. topic) no longer uses the "jms.queue." (resp. "jms.topic.") prefix to name its address and core queues.
> In the messaging-activemq subsystem, there are many attributes that correspond to such addresses.
> In the default configuration, we specified addresses for expiry and DLQ in the address-setting resources:
> {code}
> <address-setting name="#"
>                             dead-letter-address="jms.queue.DLQ"
>                             expiry-address="jms.queue.ExpiryQueue" />
> {code}
> This configuration must now be updated to use the new address naming convention:
> {code}
> <address-setting name="#"
>                             dead-letter-address="DLQ"
>                             expiry-address="ExpiryQueue" />
> {code}
> In order to preserve backwards compatibility, we must also "correct" previous configuration when they are loaded.
> If we detect that an attribute that corresponds to an Artemis address has a value that starts with "jms.queue." or "jms.topic.", we log a warning that such value is no longer correct for Artemis and use instead the value without the prefix.
> There is also a special case for the cluster-connection that was using the "jms" value in the default configuration to forward any address that started with "jms" (i.e. any JMS resources) to the cluster.
> This is no longer correct with Artemis 2.4 and instead we must use the "" (empty string) so that any addresses are forwarded to the cluster.
> Again, we must also correct the attribute if its value is "jms" to use "" instead.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 10:42:01 2018
From: issues at jboss.org (Jeff Mesnil (JIRA))
Date: Fri, 12 Jan 2018 10:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9591) Emulate Artemis 1.x address
	convention
In-Reply-To: <JIRA.12723267.1512385966000@Atlassian.JIRA>
References: <JIRA.12723267.1512385966000@Atlassian.JIRA>
	<JIRA.12723267.1512385966000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723267.1512385966000.38198.1515771721216@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9591?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jeff Mesnil updated WFLY-9591:
------------------------------
    Description: 
Artemis 2.x has changed the naming convention for its resources.
JMS Queue (resp. topic) no longer uses the "jms.queue." (resp. "jms.topic.") prefix to name its address and core queues.

In the messaging-activemq subsystem, there are many attributes that correspond to such addresses.
In the default configuration, we specified addresses for expiry and DLQ in the address-setting resources:

{code}
<address-setting name="#"
                            dead-letter-address="jms.queue.DLQ"
                            expiry-address="jms.queue.ExpiryQueue" />
{code}

This configuration must now be updated to use the new address naming convention:

{code}
<address-setting name="#"
                            dead-letter-address="DLQ"
                            expiry-address="ExpiryQueue" />
{code}

In order to preserve backwards compatibility, we decided to preserve Artemis 1.x address convention for JMS resources created by the messaging-activemq subsystem.
The user configuration and management code will remain compatible without any change.



  was:
Artemis 2.x has changed the naming convention for its resources.
JMS Queue (resp. topic) no longer uses the "jms.queue." (resp. "jms.topic.") prefix to name its address and core queues.

In the messaging-activemq subsystem, there are many attributes that correspond to such addresses.
In the default configuration, we specified addresses for expiry and DLQ in the address-setting resources:

{code}
<address-setting name="#"
                            dead-letter-address="jms.queue.DLQ"
                            expiry-address="jms.queue.ExpiryQueue" />
{code}

This configuration must now be updated to use the new address naming convention:

{code}
<address-setting name="#"
                            dead-letter-address="DLQ"
                            expiry-address="ExpiryQueue" />
{code}

In order to preserve backwards compatibility, we must also "correct" previous configuration when they are loaded.

If we detect that an attribute that corresponds to an Artemis address has a value that starts with "jms.queue." or "jms.topic.", we log a warning that such value is no longer correct for Artemis and use instead the value without the prefix.

There is also a special case for the cluster-connection that was using the "jms" value in the default configuration to forward any address that started with "jms" (i.e. any JMS resources) to the cluster.
This is no longer correct with Artemis 2.4 and instead we must use the "" (empty string) so that any addresses are forwarded to the cluster.

Again, we must also correct the attribute if its value is "jms" to use "" instead.






> Emulate Artemis 1.x address convention
> --------------------------------------
>
>                 Key: WFLY-9591
>                 URL: https://issues.jboss.org/browse/WFLY-9591
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>
> Artemis 2.x has changed the naming convention for its resources.
> JMS Queue (resp. topic) no longer uses the "jms.queue." (resp. "jms.topic.") prefix to name its address and core queues.
> In the messaging-activemq subsystem, there are many attributes that correspond to such addresses.
> In the default configuration, we specified addresses for expiry and DLQ in the address-setting resources:
> {code}
> <address-setting name="#"
>                             dead-letter-address="jms.queue.DLQ"
>                             expiry-address="jms.queue.ExpiryQueue" />
> {code}
> This configuration must now be updated to use the new address naming convention:
> {code}
> <address-setting name="#"
>                             dead-letter-address="DLQ"
>                             expiry-address="ExpiryQueue" />
> {code}
> In order to preserve backwards compatibility, we decided to preserve Artemis 1.x address convention for JMS resources created by the messaging-activemq subsystem.
> The user configuration and management code will remain compatible without any change.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 11:20:00 2018
From: issues at jboss.org (Serg Pol (JIRA))
Date: Fri, 12 Jan 2018 11:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.38426.1515774000592@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514262#comment-13514262 ] 

Serg Pol commented on WFLY-9610:
--------------------------------

thanks

> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 11:33:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 12 Jan 2018 11:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2240) Timer rules with pseudo
	clock don't fire
In-Reply-To: <JIRA.12727827.1515768109000@Atlassian.JIRA>
References: <JIRA.12727827.1515768109000@Atlassian.JIRA>
	<JIRA.12727827.1515768109000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727827.1515768109000.38488.1515774780491@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco updated DROOLS-2240:
--------------------------------
    Sprint: 2018 Week 01-02


> Timer rules with pseudo clock don't fire
> ----------------------------------------
>
>                 Key: DROOLS-2240
>                 URL: https://issues.jboss.org/browse/DROOLS-2240
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Christian Bauer
>            Assignee: Mario Fusco
>
> We are trying to test rules with timer option and the pseudo clock. 
> The problem can probably also be seen by enabling (note the @Ignore) this test: https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CepFireUntilHaltTimerTest.java
> Based on this class, this is a minimal test that shows the problem:
> {code}
> import org.drools.core.time.SessionPseudoClock;
> import org.junit.Test;
> import org.kie.api.KieServices;
> import org.kie.api.builder.KieFileSystem;
> import org.kie.api.builder.model.KieBaseModel;
> import org.kie.api.builder.model.KieModuleModel;
> import org.kie.api.runtime.KieSession;
> import org.kie.api.runtime.conf.ClockTypeOption;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> import java.util.concurrent.Future;
> import java.util.concurrent.TimeUnit;
> import static org.junit.Assert.assertEquals;
> /**
>  * Based on:
>  * https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CepFireUntilHaltTimerTest.java
>  */
> public class PseudoClockTimerTest {
>     private KieSession ksession;
>     private SessionPseudoClock clock;
>     public void init(String clockType) {
>         String drl = "package test.rules\n" +
>             "\n" +
>             "rule \"Do something triggered by timer\"\n" +
>             "timer (int: 1s 1s)\n" +
>             "then\n" +
>             "    System.out.println(\"### DO SOMETHING \" + drools.getWorkingMemory().getSessionClock().getCurrentTime());\n" +
>             "    insert(\"### TIME IS \" + drools.getWorkingMemory().getSessionClock().getCurrentTime());\n" +
>             "end\n";
>         KieServices ks = KieServices.Factory.get();
>         KieModuleModel module = ks.newKieModuleModel();
>         KieBaseModel defaultBase = module.newKieBaseModel("defaultKBase")
>             .setDefault(true)
>             .addPackage("*");
>         defaultBase.newKieSessionModel("defaultKSession")
>             .setDefault(true)
>             .setClockType(ClockTypeOption.get(clockType));
>         KieFileSystem kfs = ks.newKieFileSystem()
>             .write("src/main/resources/r1.drl", drl);
>         kfs.writeKModuleXML(module.toXML());
>         ks.newKieBuilder(kfs).buildAll();
>         ksession = ks.newKieContainer(ks.getRepository().getDefaultReleaseId())
>             .newKieSession();
>         if (clockType.equals("pseudo"))
>             clock = ksession.getSessionClock();
>     }
>     public void cleanup() {
>         ksession.dispose();
>     }
>     @Test
>     public void testTimerExecution() throws Exception {
>         init("realtime");
>         performRealtimeClockTest();
>         cleanup();
>         init("pseudo");
>         performPseudoClockTest();
>         cleanup();
>     }
>     private void performRealtimeClockTest() throws Exception {
>         ExecutorService thread = Executors.newSingleThreadExecutor();
>         final Future fireUntilHaltResult = thread.submit(() -> ksession.fireUntilHalt());
>         try {
>             Thread.sleep(10500);
>             assertEquals(10, ksession.getFactCount());
>         } finally {
>             ksession.halt();
>             fireUntilHaltResult.get(60000, TimeUnit.SECONDS);
>             thread.shutdown();
>         }
>     }
>     private void performPseudoClockTest() throws Exception {
>         ExecutorService thread = Executors.newSingleThreadExecutor();
>         final Future fireUntilHaltResult = thread.submit(() -> ksession.fireUntilHalt());
>         try {
>             Thread.sleep(500);
>             // NOT WORKING:
>             // clock.advanceTime(10, TimeUnit.SECONDS);
>             // Thread.sleep(50);
>             // WORKAROUND:
>             for (int i = 0; i < 10; i++) {
>                 clock.advanceTime(1, TimeUnit.SECONDS);
>                 Thread.sleep(50);
>             }
>             assertEquals(10, ksession.getFactCount());
>         } finally {
>             ksession.halt();
>             fireUntilHaltResult.get(60000, TimeUnit.SECONDS);
>             thread.shutdown();
>         }
>     }
> }
> {code}
> See the NOT WORKING and WORKAROUND markers. There doesn't seem to be any other test in the codebase with timer rules and the pseudo clock, so our conclusion is that this combination is not working at all.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 11:43:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 12 Jan 2018 11:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1487) HTTP Digest SHA mechs missing
 in available mechanisms
In-Reply-To: <JIRA.12727858.1515775376000@Atlassian.JIRA>
References: <JIRA.12727858.1515775376000@Atlassian.JIRA>
	<JIRA.12727858.1515775376360@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727858.1515775376000.38554.1515775380118@Atlassian.JIRA>

Jan Kalina created ELY-1487:
-------------------------------

             Summary: HTTP Digest SHA mechs missing in available mechanisms
                 Key: ELY-1487
                 URL: https://issues.jboss.org/browse/ELY-1487
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Jan Kalina
            Assignee: Jan Kalina


DIGEST-SHA-256 and DIGEST-SHA-512-256 are not correctly registered:

When trying to deploy application using one of them for authentication:
{code}
org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy DigestSha256MechTestCase.war: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./DigestSha256MechTestCase" => "java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory.
    Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory.
    Caused by: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory."}}}}
{code}

Problem is mechanisms are missing in output of {{ServerMechanismFactoryImpl.getMechanismNames()}}.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 11:44:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 12 Jan 2018 11:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1487) HTTP Digest SHA mechs missing
 in available mechanisms
In-Reply-To: <JIRA.12727858.1515775376000@Atlassian.JIRA>
References: <JIRA.12727858.1515775376000@Atlassian.JIRA>
	<JIRA.12727858.1515775376000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727858.1515775376000.38559.1515775440229@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1487:
----------------------------
    Affects Version/s: 1.2.0.Beta11


> HTTP Digest SHA mechs missing in available mechanisms
> -----------------------------------------------------
>
>                 Key: ELY-1487
>                 URL: https://issues.jboss.org/browse/ELY-1487
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> DIGEST-SHA-256 and DIGEST-SHA-512-256 are not correctly registered:
> When trying to deploy application using one of them for authentication:
> {code}
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy DigestSha256MechTestCase.war: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./DigestSha256MechTestCase" => "java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory."}}}}
> {code}
> Problem is mechanisms are missing in output of {{ServerMechanismFactoryImpl.getMechanismNames()}}.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 11:50:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Fri, 12 Jan 2018 11:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2240) Timer rules with pseudo
	clock don't fire
In-Reply-To: <JIRA.12727827.1515768109000@Atlassian.JIRA>
References: <JIRA.12727827.1515768109000@Atlassian.JIRA>
	<JIRA.12727827.1515768109000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727827.1515768109000.38609.1515775800299@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Mario Fusco resolved DROOLS-2240.
---------------------------------
    Resolution: Explained


You have a rule that is fires every second, have a pseudo-clock that makes a jump of 10 seconds in one shoot and expect the rule to fire 10 times. This is not how the psuedo-clock is supposed to work. Conversely time conditions are evaluated once at each discrete jump so what happens when you do 10 seconds jump is that the timestamp for the next expected rule firing is compared with the current time and if it's lower the rule fires once and that's all. When instead of do 10 subsequent jumps the condition is evaluated 10 times and then also the rule fires 10 times as per your expectations.

> Timer rules with pseudo clock don't fire
> ----------------------------------------
>
>                 Key: DROOLS-2240
>                 URL: https://issues.jboss.org/browse/DROOLS-2240
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Christian Bauer
>            Assignee: Mario Fusco
>
> We are trying to test rules with timer option and the pseudo clock. 
> The problem can probably also be seen by enabling (note the @Ignore) this test: https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CepFireUntilHaltTimerTest.java
> Based on this class, this is a minimal test that shows the problem:
> {code}
> import org.drools.core.time.SessionPseudoClock;
> import org.junit.Test;
> import org.kie.api.KieServices;
> import org.kie.api.builder.KieFileSystem;
> import org.kie.api.builder.model.KieBaseModel;
> import org.kie.api.builder.model.KieModuleModel;
> import org.kie.api.runtime.KieSession;
> import org.kie.api.runtime.conf.ClockTypeOption;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> import java.util.concurrent.Future;
> import java.util.concurrent.TimeUnit;
> import static org.junit.Assert.assertEquals;
> /**
>  * Based on:
>  * https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CepFireUntilHaltTimerTest.java
>  */
> public class PseudoClockTimerTest {
>     private KieSession ksession;
>     private SessionPseudoClock clock;
>     public void init(String clockType) {
>         String drl = "package test.rules\n" +
>             "\n" +
>             "rule \"Do something triggered by timer\"\n" +
>             "timer (int: 1s 1s)\n" +
>             "then\n" +
>             "    System.out.println(\"### DO SOMETHING \" + drools.getWorkingMemory().getSessionClock().getCurrentTime());\n" +
>             "    insert(\"### TIME IS \" + drools.getWorkingMemory().getSessionClock().getCurrentTime());\n" +
>             "end\n";
>         KieServices ks = KieServices.Factory.get();
>         KieModuleModel module = ks.newKieModuleModel();
>         KieBaseModel defaultBase = module.newKieBaseModel("defaultKBase")
>             .setDefault(true)
>             .addPackage("*");
>         defaultBase.newKieSessionModel("defaultKSession")
>             .setDefault(true)
>             .setClockType(ClockTypeOption.get(clockType));
>         KieFileSystem kfs = ks.newKieFileSystem()
>             .write("src/main/resources/r1.drl", drl);
>         kfs.writeKModuleXML(module.toXML());
>         ks.newKieBuilder(kfs).buildAll();
>         ksession = ks.newKieContainer(ks.getRepository().getDefaultReleaseId())
>             .newKieSession();
>         if (clockType.equals("pseudo"))
>             clock = ksession.getSessionClock();
>     }
>     public void cleanup() {
>         ksession.dispose();
>     }
>     @Test
>     public void testTimerExecution() throws Exception {
>         init("realtime");
>         performRealtimeClockTest();
>         cleanup();
>         init("pseudo");
>         performPseudoClockTest();
>         cleanup();
>     }
>     private void performRealtimeClockTest() throws Exception {
>         ExecutorService thread = Executors.newSingleThreadExecutor();
>         final Future fireUntilHaltResult = thread.submit(() -> ksession.fireUntilHalt());
>         try {
>             Thread.sleep(10500);
>             assertEquals(10, ksession.getFactCount());
>         } finally {
>             ksession.halt();
>             fireUntilHaltResult.get(60000, TimeUnit.SECONDS);
>             thread.shutdown();
>         }
>     }
>     private void performPseudoClockTest() throws Exception {
>         ExecutorService thread = Executors.newSingleThreadExecutor();
>         final Future fireUntilHaltResult = thread.submit(() -> ksession.fireUntilHalt());
>         try {
>             Thread.sleep(500);
>             // NOT WORKING:
>             // clock.advanceTime(10, TimeUnit.SECONDS);
>             // Thread.sleep(50);
>             // WORKAROUND:
>             for (int i = 0; i < 10; i++) {
>                 clock.advanceTime(1, TimeUnit.SECONDS);
>                 Thread.sleep(50);
>             }
>             assertEquals(10, ksession.getFactCount());
>         } finally {
>             ksession.halt();
>             fireUntilHaltResult.get(60000, TimeUnit.SECONDS);
>             thread.shutdown();
>         }
>     }
> }
> {code}
> See the NOT WORKING and WORKAROUND markers. There doesn't seem to be any other test in the codebase with timer rules and the pseudo clock, so our conclusion is that this combination is not working at all.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 11:55:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 12 Jan 2018 11:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9664) Add support for configuring
 scattered caches
In-Reply-To: <JIRA.12727862.1515776074000@Atlassian.JIRA>
References: <JIRA.12727862.1515776074000@Atlassian.JIRA>
	<JIRA.12727862.1515776074306@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727862.1515776074000.38648.1515776100090@Atlassian.JIRA>

Paul Ferraro created WFLY-9664:
----------------------------------

             Summary: Add support for configuring scattered caches
                 Key: WFLY-9664
                 URL: https://issues.jboss.org/browse/WFLY-9664
             Project: WildFly
          Issue Type: Enhancement
          Components: Clustering
    Affects Versions: 11.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 11:59:00 2018
From: issues at jboss.org (Christian Bauer (JIRA))
Date: Fri, 12 Jan 2018 11:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2240) Timer rules with pseudo
	clock don't fire
In-Reply-To: <JIRA.12727827.1515768109000@Atlassian.JIRA>
References: <JIRA.12727827.1515768109000@Atlassian.JIRA>
	<JIRA.12727827.1515768109000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727827.1515768109000.38747.1515776340498@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514285#comment-13514285 ] 

Christian Bauer commented on DROOLS-2240:
-----------------------------------------

Instead of the hundreds of workbench screenshots, maybe that should be in the documentation?

> Timer rules with pseudo clock don't fire
> ----------------------------------------
>
>                 Key: DROOLS-2240
>                 URL: https://issues.jboss.org/browse/DROOLS-2240
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Christian Bauer
>            Assignee: Mario Fusco
>
> We are trying to test rules with timer option and the pseudo clock. 
> The problem can probably also be seen by enabling (note the @Ignore) this test: https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CepFireUntilHaltTimerTest.java
> Based on this class, this is a minimal test that shows the problem:
> {code}
> import org.drools.core.time.SessionPseudoClock;
> import org.junit.Test;
> import org.kie.api.KieServices;
> import org.kie.api.builder.KieFileSystem;
> import org.kie.api.builder.model.KieBaseModel;
> import org.kie.api.builder.model.KieModuleModel;
> import org.kie.api.runtime.KieSession;
> import org.kie.api.runtime.conf.ClockTypeOption;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> import java.util.concurrent.Future;
> import java.util.concurrent.TimeUnit;
> import static org.junit.Assert.assertEquals;
> /**
>  * Based on:
>  * https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CepFireUntilHaltTimerTest.java
>  */
> public class PseudoClockTimerTest {
>     private KieSession ksession;
>     private SessionPseudoClock clock;
>     public void init(String clockType) {
>         String drl = "package test.rules\n" +
>             "\n" +
>             "rule \"Do something triggered by timer\"\n" +
>             "timer (int: 1s 1s)\n" +
>             "then\n" +
>             "    System.out.println(\"### DO SOMETHING \" + drools.getWorkingMemory().getSessionClock().getCurrentTime());\n" +
>             "    insert(\"### TIME IS \" + drools.getWorkingMemory().getSessionClock().getCurrentTime());\n" +
>             "end\n";
>         KieServices ks = KieServices.Factory.get();
>         KieModuleModel module = ks.newKieModuleModel();
>         KieBaseModel defaultBase = module.newKieBaseModel("defaultKBase")
>             .setDefault(true)
>             .addPackage("*");
>         defaultBase.newKieSessionModel("defaultKSession")
>             .setDefault(true)
>             .setClockType(ClockTypeOption.get(clockType));
>         KieFileSystem kfs = ks.newKieFileSystem()
>             .write("src/main/resources/r1.drl", drl);
>         kfs.writeKModuleXML(module.toXML());
>         ks.newKieBuilder(kfs).buildAll();
>         ksession = ks.newKieContainer(ks.getRepository().getDefaultReleaseId())
>             .newKieSession();
>         if (clockType.equals("pseudo"))
>             clock = ksession.getSessionClock();
>     }
>     public void cleanup() {
>         ksession.dispose();
>     }
>     @Test
>     public void testTimerExecution() throws Exception {
>         init("realtime");
>         performRealtimeClockTest();
>         cleanup();
>         init("pseudo");
>         performPseudoClockTest();
>         cleanup();
>     }
>     private void performRealtimeClockTest() throws Exception {
>         ExecutorService thread = Executors.newSingleThreadExecutor();
>         final Future fireUntilHaltResult = thread.submit(() -> ksession.fireUntilHalt());
>         try {
>             Thread.sleep(10500);
>             assertEquals(10, ksession.getFactCount());
>         } finally {
>             ksession.halt();
>             fireUntilHaltResult.get(60000, TimeUnit.SECONDS);
>             thread.shutdown();
>         }
>     }
>     private void performPseudoClockTest() throws Exception {
>         ExecutorService thread = Executors.newSingleThreadExecutor();
>         final Future fireUntilHaltResult = thread.submit(() -> ksession.fireUntilHalt());
>         try {
>             Thread.sleep(500);
>             // NOT WORKING:
>             // clock.advanceTime(10, TimeUnit.SECONDS);
>             // Thread.sleep(50);
>             // WORKAROUND:
>             for (int i = 0; i < 10; i++) {
>                 clock.advanceTime(1, TimeUnit.SECONDS);
>                 Thread.sleep(50);
>             }
>             assertEquals(10, ksession.getFactCount());
>         } finally {
>             ksession.halt();
>             fireUntilHaltResult.get(60000, TimeUnit.SECONDS);
>             thread.shutdown();
>         }
>     }
> }
> {code}
> See the NOT WORKING and WORKAROUND markers. There doesn't seem to be any other test in the codebase with timer rules and the pseudo clock, so our conclusion is that this combination is not working at all.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 12:11:00 2018
From: issues at jboss.org (Christian Bauer (JIRA))
Date: Fri, 12 Jan 2018 12:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2240) Timer rules with pseudo
	clock don't fire
In-Reply-To: <JIRA.12727827.1515768109000@Atlassian.JIRA>
References: <JIRA.12727827.1515768109000@Atlassian.JIRA>
	<JIRA.12727827.1515768109000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727827.1515768109000.38973.1515777060296@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514301#comment-13514301 ] 

Christian Bauer commented on DROOLS-2240:
-----------------------------------------

Should this work then?

{code}
for (int i = 0; i < 10; i++) {
    clock.advanceTime(1, TimeUnit.SECONDS);
}
Thread.sleep(50);
{code}

> Timer rules with pseudo clock don't fire
> ----------------------------------------
>
>                 Key: DROOLS-2240
>                 URL: https://issues.jboss.org/browse/DROOLS-2240
>             Project: Drools
>          Issue Type: Bug
>    Affects Versions: 7.5.0.Final
>            Reporter: Christian Bauer
>            Assignee: Mario Fusco
>
> We are trying to test rules with timer option and the pseudo clock. 
> The problem can probably also be seen by enabling (note the @Ignore) this test: https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CepFireUntilHaltTimerTest.java
> Based on this class, this is a minimal test that shows the problem:
> {code}
> import org.drools.core.time.SessionPseudoClock;
> import org.junit.Test;
> import org.kie.api.KieServices;
> import org.kie.api.builder.KieFileSystem;
> import org.kie.api.builder.model.KieBaseModel;
> import org.kie.api.builder.model.KieModuleModel;
> import org.kie.api.runtime.KieSession;
> import org.kie.api.runtime.conf.ClockTypeOption;
> import java.util.concurrent.ExecutorService;
> import java.util.concurrent.Executors;
> import java.util.concurrent.Future;
> import java.util.concurrent.TimeUnit;
> import static org.junit.Assert.assertEquals;
> /**
>  * Based on:
>  * https://github.com/kiegroup/drools/blob/master/drools-compiler/src/test/java/org/drools/compiler/integrationtests/CepFireUntilHaltTimerTest.java
>  */
> public class PseudoClockTimerTest {
>     private KieSession ksession;
>     private SessionPseudoClock clock;
>     public void init(String clockType) {
>         String drl = "package test.rules\n" +
>             "\n" +
>             "rule \"Do something triggered by timer\"\n" +
>             "timer (int: 1s 1s)\n" +
>             "then\n" +
>             "    System.out.println(\"### DO SOMETHING \" + drools.getWorkingMemory().getSessionClock().getCurrentTime());\n" +
>             "    insert(\"### TIME IS \" + drools.getWorkingMemory().getSessionClock().getCurrentTime());\n" +
>             "end\n";
>         KieServices ks = KieServices.Factory.get();
>         KieModuleModel module = ks.newKieModuleModel();
>         KieBaseModel defaultBase = module.newKieBaseModel("defaultKBase")
>             .setDefault(true)
>             .addPackage("*");
>         defaultBase.newKieSessionModel("defaultKSession")
>             .setDefault(true)
>             .setClockType(ClockTypeOption.get(clockType));
>         KieFileSystem kfs = ks.newKieFileSystem()
>             .write("src/main/resources/r1.drl", drl);
>         kfs.writeKModuleXML(module.toXML());
>         ks.newKieBuilder(kfs).buildAll();
>         ksession = ks.newKieContainer(ks.getRepository().getDefaultReleaseId())
>             .newKieSession();
>         if (clockType.equals("pseudo"))
>             clock = ksession.getSessionClock();
>     }
>     public void cleanup() {
>         ksession.dispose();
>     }
>     @Test
>     public void testTimerExecution() throws Exception {
>         init("realtime");
>         performRealtimeClockTest();
>         cleanup();
>         init("pseudo");
>         performPseudoClockTest();
>         cleanup();
>     }
>     private void performRealtimeClockTest() throws Exception {
>         ExecutorService thread = Executors.newSingleThreadExecutor();
>         final Future fireUntilHaltResult = thread.submit(() -> ksession.fireUntilHalt());
>         try {
>             Thread.sleep(10500);
>             assertEquals(10, ksession.getFactCount());
>         } finally {
>             ksession.halt();
>             fireUntilHaltResult.get(60000, TimeUnit.SECONDS);
>             thread.shutdown();
>         }
>     }
>     private void performPseudoClockTest() throws Exception {
>         ExecutorService thread = Executors.newSingleThreadExecutor();
>         final Future fireUntilHaltResult = thread.submit(() -> ksession.fireUntilHalt());
>         try {
>             Thread.sleep(500);
>             // NOT WORKING:
>             // clock.advanceTime(10, TimeUnit.SECONDS);
>             // Thread.sleep(50);
>             // WORKAROUND:
>             for (int i = 0; i < 10; i++) {
>                 clock.advanceTime(1, TimeUnit.SECONDS);
>                 Thread.sleep(50);
>             }
>             assertEquals(10, ksession.getFactCount());
>         } finally {
>             ksession.halt();
>             fireUntilHaltResult.get(60000, TimeUnit.SECONDS);
>             thread.shutdown();
>         }
>     }
> }
> {code}
> See the NOT WORKING and WORKAROUND markers. There doesn't seem to be any other test in the codebase with timer rules and the pseudo clock, so our conclusion is that this combination is not working at all.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 12:43:00 2018
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 12 Jan 2018 12:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1488) Coverity: Dead local store in
 DigestUtil.java
In-Reply-To: <JIRA.12727871.1515778937000@Atlassian.JIRA>
References: <JIRA.12727871.1515778937000@Atlassian.JIRA>
	<JIRA.12727871.1515778937734@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727871.1515778937000.39036.1515778980081@Atlassian.JIRA>

Ilia Vassilev created ELY-1488:
----------------------------------

             Summary: Coverity: Dead local store in DigestUtil.java
                 Key: ELY-1488
                 URL: https://issues.jboss.org/browse/ELY-1488
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Utils
    Affects Versions: 1.2.0.Beta10
            Reporter: Ilia Vassilev
            Assignee: Ilia Vassilev
            Priority: Trivial


In org.?wildfly.?security.?mechanism.?digest.?DigestUtil.?parseResponse(byte[], java.?nio.?charset.?Charset, boolean, org.?wildfly.?security.?_private.?ElytronMessages): This instruction assigns a value to a local variable, but the value is not read or used in any subsequent instruction

https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=40661976&defectInstanceId=8722291&mergedDefectId=1462036



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 12 16:58:00 2018
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 12 Jan 2018 16:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING
 attempts to delete row too late
In-Reply-To: <JIRA.12685499.1491050677000@Atlassian.JIRA>
References: <JIRA.12685499.1491050677000@Atlassian.JIRA>
	<JIRA.12685499.1491050677000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12685499.1491050677000.40796.1515794280411@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514681#comment-13514681 ] 

John Ament commented on WFLY-8488:
----------------------------------

[~rhusar] My original question about what the new configuration is for WF 11 wasn't really answered.  Can you help?

> 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.5.0#75005)

From issues at jboss.org  Fri Jan 12 16:58:00 2018
From: issues at jboss.org (John Ament (JIRA))
Date: Fri, 12 Jan 2018 16:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING
 attempts to delete row too late
In-Reply-To: <JIRA.12685499.1491050677000@Atlassian.JIRA>
References: <JIRA.12685499.1491050677000@Atlassian.JIRA>
	<JIRA.12685499.1491050677000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12685499.1491050677000.40803.1515794280600@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

John Ament reopened WFLY-8488:
------------------------------


> 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.5.0#75005)

From issues at jboss.org  Fri Jan 12 19:42:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 12 Jan 2018 19:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1487) HTTP Digest SHA mechs missing
 in available mechanisms
In-Reply-To: <JIRA.12727858.1515775376000@Atlassian.JIRA>
References: <JIRA.12727858.1515775376000@Atlassian.JIRA>
	<JIRA.12727858.1515775376000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727858.1515775376000.40839.1515804120064@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1487:
----------------------------
    Fix Version/s: 1.2.0.Beta12


> HTTP Digest SHA mechs missing in available mechanisms
> -----------------------------------------------------
>
>                 Key: ELY-1487
>                 URL: https://issues.jboss.org/browse/ELY-1487
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta12
>
>
> DIGEST-SHA-256 and DIGEST-SHA-512-256 are not correctly registered:
> When trying to deploy application using one of them for authentication:
> {code}
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy DigestSha256MechTestCase.war: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./DigestSha256MechTestCase" => "java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory."}}}}
> {code}
> Problem is mechanisms are missing in output of {{ServerMechanismFactoryImpl.getMechanismNames()}}.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 12 19:43:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 12 Jan 2018 19:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1487) HTTP Digest SHA mechs missing
 in available mechanisms
In-Reply-To: <JIRA.12727858.1515775376000@Atlassian.JIRA>
References: <JIRA.12727858.1515775376000@Atlassian.JIRA>
	<JIRA.12727858.1515775376000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727858.1515775376000.40841.1515804180054@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1487:
----------------------------
    Component/s: HTTP


> HTTP Digest SHA mechs missing in available mechanisms
> -----------------------------------------------------
>
>                 Key: ELY-1487
>                 URL: https://issues.jboss.org/browse/ELY-1487
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta12
>
>
> DIGEST-SHA-256 and DIGEST-SHA-512-256 are not correctly registered:
> When trying to deploy application using one of them for authentication:
> {code}
> org.jboss.arquillian.container.spi.client.container.DeploymentException: Cannot deploy DigestSha256MechTestCase.war: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => {"WFLYCTL0080: Failed services" => {"jboss.undertow.deployment.default-server.default-host./DigestSha256MechTestCase" => "java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory.
>     Caused by: java.lang.RuntimeException: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory.
>     Caused by: java.lang.IllegalStateException: WFLYUT0084: There are no mechanisms available from the HttpAuthenticationFactory."}}}}
> {code}
> Problem is mechanisms are missing in output of {{ServerMechanismFactoryImpl.getMechanismNames()}}.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 13 03:50:00 2018
From: issues at jboss.org (Zoltan Laszlo Ferenci (JIRA))
Date: Sat, 13 Jan 2018 03:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9665) HttpSession cannot be
 injected in distributed application
In-Reply-To: <JIRA.12727883.1515833380000@Atlassian.JIRA>
References: <JIRA.12727883.1515833380000@Atlassian.JIRA>
	<JIRA.12727883.1515833380162@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727883.1515833380000.40879.1515833400113@Atlassian.JIRA>

Zoltan Laszlo Ferenci created WFLY-9665:
-------------------------------------------

             Summary: HttpSession cannot be injected in distributed application
                 Key: WFLY-9665
                 URL: https://issues.jboss.org/browse/WFLY-9665
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld, EE
    Affects Versions: 10.1.0.Final
            Reporter: Zoltan Laszlo Ferenci
            Assignee: Martin Kouba
         Attachments: HttpSessionInjectionBug.zip

The CDI Specification states that HttpSession should be available for injection. It also has statements about when should the bean passivation capable.
The problem is that it seems the io.undertow.servlet.spec.HttpSessionImpl is not serializable, and whenever you try to inject, you get exception at passivation.
I would say it's normal if it's injected into a passivating scoped bean, because the CDI specification says that the bean is passivation capable only if all it's dependencies is passivation capable.
However this is the case even if it's injected in a RequestScoped bean, that shouldn't be passivated. In the sample project only the HttpSession should be passivated that is independent from the CDI. Anyway it gives an error in that case too, and doesn't store and recover the HttpSession.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 13 07:26:00 2018
From: issues at jboss.org (Chandresh Mishra (JIRA))
Date: Sat, 13 Jan 2018 07:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1735) Fetch KieSession from Kbase
 using session name
In-Reply-To: <JIRA.12712035.1505672317000@Atlassian.JIRA>
References: <JIRA.12712035.1505672317000@Atlassian.JIRA>
	<JIRA.12712035.1505672317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712035.1505672317000.40902.1515846360134@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514703#comment-13514703 ] 

Chandresh Mishra commented on DROOLS-1735:
------------------------------------------

[~mfusco] is there any update on this?

> Fetch KieSession  from Kbase using session name
> -----------------------------------------------
>
>                 Key: DROOLS-1735
>                 URL: https://issues.jboss.org/browse/DROOLS-1735
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 7.3.0.Final
>            Reporter: Chandresh Mishra
>            Assignee: Mario Fusco
>              Labels: new_and_noteworthy, task
>
> KieSession kSession = kContainer.getKieBase("KiebaseName")).newKieSession();
> There is no method available in KieBase to get KieSession by passing the session name.
> which is similar to get session from container 
> kSession = kContainer.newKieSession("SessionName");
> So , We can not choose a particular kieBase and KieSession at a same time by passing the name for both.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 13 07:26:00 2018
From: issues at jboss.org (Chandresh Mishra (JIRA))
Date: Sat, 13 Jan 2018 07:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1759) Not able to load all the
 kieModule from classpath
In-Reply-To: <JIRA.12715649.1507673188000@Atlassian.JIRA>
References: <JIRA.12715649.1507673188000@Atlassian.JIRA>
	<JIRA.12715649.1507673188000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12715649.1507673188000.40905.1515846360236@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1759?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514704#comment-13514704 ] 

Chandresh Mishra commented on DROOLS-1759:
------------------------------------------

[~mfusco] is there any update on this issue?

> Not able to load all the kieModule from classpath  
> ---------------------------------------------------
>
>                 Key: DROOLS-1759
>                 URL: https://issues.jboss.org/browse/DROOLS-1759
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.4.1.Final
>            Reporter: Chandresh Mishra
>            Assignee: Mario Fusco
>
> Hi ,
> I am trying to load a rules from classpath in gradle project. 
> It is a multi module gradle project.It has following structure.
> Application 
> Application-rule
> root
> Application has compile project(':application-rule') in build.gradle.
> application-rule  has external dependency on common-rules .
> Now when I am trying to load KieContainer from classpath in Application project. It is loading only kiebase in common-rules.jar .It is not loading kiebase in kmodule.xml present in Application-rule.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 14 10:21:00 2018
From: issues at jboss.org (Bruno Medeiros (JIRA))
Date: Sun, 14 Jan 2018 10:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9666) ClassLoader leak in
 org.jboss.el.cache.FactoryFinderCache (Wildfly 11)
In-Reply-To: <JIRA.12727948.1515943217000@Atlassian.JIRA>
References: <JIRA.12727948.1515943217000@Atlassian.JIRA>
	<JIRA.12727948.1515943217589@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727948.1515943217000.41121.1515943260196@Atlassian.JIRA>

Bruno Medeiros created WFLY-9666:
------------------------------------

             Summary: ClassLoader leak in org.jboss.el.cache.FactoryFinderCache (Wildfly 11)
                 Key: WFLY-9666
                 URL: https://issues.jboss.org/browse/WFLY-9666
             Project: WildFly
          Issue Type: Bug
          Components: Class Loading
    Affects Versions: 11.0.0.Final
         Environment: macOS
            Reporter: Bruno Medeiros
            Assignee: David Lloyd
            Priority: Critical
         Attachments: Screen Shot 2018-01-14 at 19.32.10.png

I was investigating why my class loader was leaking and after fixing all the problems within my application classes I got the leak shown in the attachment.

 !Screen Shot 2018-01-14 at 19.32.10.png|thumbnail! 

This is pretty similar with https://issues.jboss.org/browse/WFLY-3365, not sure if I should have reopened that one o raised this one, sorry if I took the wrong decision.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 14 16:05:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 14 Jan 2018 16:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9667) Change the Undertow subsystem
 to use io.undertow.server.DefaultByteBufferPool
In-Reply-To: <JIRA.12727949.1515963896000@Atlassian.JIRA>
References: <JIRA.12727949.1515963896000@Atlassian.JIRA>
	<JIRA.12727949.1515963896217@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727949.1515963896000.41151.1515963900098@Atlassian.JIRA>

Stuart Douglas created WFLY-9667:
------------------------------------

             Summary: Change the Undertow subsystem to use io.undertow.server.DefaultByteBufferPool
                 Key: WFLY-9667
                 URL: https://issues.jboss.org/browse/WFLY-9667
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Stuart Douglas
            Assignee: Jason Greene






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 14 16:06:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 14 Jan 2018 16:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9667) Change the Undertow subsystem
 to use io.undertow.server.DefaultByteBufferPool
In-Reply-To: <JIRA.12727949.1515963896000@Atlassian.JIRA>
References: <JIRA.12727949.1515963896000@Atlassian.JIRA>
	<JIRA.12727949.1515963896000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727949.1515963896000.41154.1515963960128@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFLY-9667:
------------------------------------

    Assignee: Stuart Douglas  (was: Jason Greene)


> Change the Undertow subsystem to use io.undertow.server.DefaultByteBufferPool
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-9667
>                 URL: https://issues.jboss.org/browse/WFLY-9667
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 14 16:06:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 14 Jan 2018 16:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9667) Change the Undertow subsystem
 to use io.undertow.server.DefaultByteBufferPool
In-Reply-To: <JIRA.12727949.1515963896000@Atlassian.JIRA>
References: <JIRA.12727949.1515963896000@Atlassian.JIRA>
	<JIRA.12727949.1515963896000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727949.1515963896000.41157.1515963960202@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9667?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-9667:
---------------------------------
    Component/s: Web (Undertow)


> Change the Undertow subsystem to use io.undertow.server.DefaultByteBufferPool
> -----------------------------------------------------------------------------
>
>                 Key: WFLY-9667
>                 URL: https://issues.jboss.org/browse/WFLY-9667
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 14 16:22:00 2018
From: issues at jboss.org (Karl-Philipp Richter (JIRA))
Date: Sun, 14 Jan 2018 16:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9668) Make datasources editable
In-Reply-To: <JIRA.12727950.1515964871000@Atlassian.JIRA>
References: <JIRA.12727950.1515964871000@Atlassian.JIRA>
	<JIRA.12727950.1515964871783@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727950.1515964871000.41160.1515964920181@Atlassian.JIRA>

Karl-Philipp Richter created WFLY-9668:
------------------------------------------

             Summary: Make datasources editable
                 Key: WFLY-9668
                 URL: https://issues.jboss.org/browse/WFLY-9668
             Project: WildFly
          Issue Type: Enhancement
          Components: Web Console
            Reporter: Karl-Philipp Richter
            Assignee: Harald Pehl


Datasource properties aren't editable after being created once in the web frontend after logging in as an admin user. That requires deletion and recreation of data sources.

Creation of data sources already is quite unintuitive in WildFly and takes a lot longer than necessary in an intuitive design, so this should be a start to improve this management aspect.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 14 20:55:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 14 Jan 2018 20:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFBUILD-31) Maven plugin overrides
 versions of feature pack artifacts by default
In-Reply-To: <JIRA.12727957.1515981255000@Atlassian.JIRA>
References: <JIRA.12727957.1515981255000@Atlassian.JIRA>
	<JIRA.12727957.1515981255514@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727957.1515981255000.41333.1515981300375@Atlassian.JIRA>

Stuart Douglas created WFBUILD-31:
-------------------------------------

             Summary: Maven plugin overrides versions of feature pack artifacts by default
                 Key: WFBUILD-31
                 URL: https://issues.jboss.org/browse/WFBUILD-31
             Project: WildFly Build Tools
          Issue Type: Bug
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 14 21:28:00 2018
From: issues at jboss.org (Karl-Philipp Richter (JIRA))
Date: Sun, 14 Jan 2018 21:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9668) Make datasources editable
In-Reply-To: <JIRA.12727950.1515964872000@Atlassian.JIRA>
References: <JIRA.12727950.1515964872000@Atlassian.JIRA>
	<JIRA.12727950.1515964872000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727950.1515964872000.41411.1515983280092@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9668?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514770#comment-13514770 ] 

Karl-Philipp Richter commented on WFLY-9668:
--------------------------------------------

The data source seems to be editable on the page opened after clicking "View", but that's not intutitive. Maybe change "View" to "View/Edit"?

> Make datasources editable
> -------------------------
>
>                 Key: WFLY-9668
>                 URL: https://issues.jboss.org/browse/WFLY-9668
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: Web Console
>            Reporter: Karl-Philipp Richter
>            Assignee: Harald Pehl
>
> Datasource properties aren't editable after being created once in the web frontend after logging in as an admin user. That requires deletion and recreation of data sources.
> Creation of data sources already is quite unintuitive in WildFly and takes a lot longer than necessary in an intuitive design, so this should be a start to improve this management aspect.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 14 21:54:00 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Sun, 14 Jan 2018 21:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9502)
 javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name
 "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
In-Reply-To: <JIRA.12718725.1509442317000@Atlassian.JIRA>
References: <JIRA.12718725.1509442317000@Atlassian.JIRA>
	<JIRA.12718725.1509442317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718725.1509442317000.41432.1515984840417@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao reassigned WFLY-9502:
-----------------------------

    Assignee: Lin Gao  (was: Martyn Taylor)


> javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9502
>                 URL: https://issues.jboss.org/browse/WFLY-9502
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Naming
>    Affects Versions: 11.0.0.Final
>            Reporter: Martin ?vehla
>            Assignee: Lin Gao
>            Priority: Critical
>              Labels: downstream_dependency
>
> When I create jms bridge on EAP7 that tries to connect to EAP6, it throws following issue when trying to do remote lookup for connection factory or destination on EAP6.
> {code}
> 2017-10-31 09:44:18,769 WARN  [org.apache.activemq.artemis.jms.bridge] (Thread-102) AMQ342010: Failed to connect JMS Bridge N/A: javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null"
> 	at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
> 	at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:46)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:32)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1072)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1247)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2600(JMSBridgeImpl.java:75)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1747)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {\code}
> When debugging I noticed that WildFlyRootContext.getProviderContext there's no NamingProviderFactory available to resolve the name, so I think the error message is just a consequence of that.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Sun Jan 14 23:57:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 14 Jan 2018 23:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3508) Undertow 1.4.22.Final
In-Reply-To: <JIRA.12727963.1515992164000@Atlassian.JIRA>
References: <JIRA.12727963.1515992164000@Atlassian.JIRA>
	<JIRA.12727963.1515992164201@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727963.1515992164000.41537.1515992220112@Atlassian.JIRA>

Stuart Douglas created WFCORE-3508:
--------------------------------------

             Summary: Undertow 1.4.22.Final
                 Key: WFCORE-3508
                 URL: https://issues.jboss.org/browse/WFCORE-3508
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 14 23:57:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 14 Jan 2018 23:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3508) Undertow 1.4.22.Final
In-Reply-To: <JIRA.12727963.1515992164000@Atlassian.JIRA>
References: <JIRA.12727963.1515992164000@Atlassian.JIRA>
	<JIRA.12727963.1515992164000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727963.1515992164000.41540.1515992220344@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3508?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFCORE-3508:
--------------------------------------

    Assignee: Stuart Douglas


> Undertow 1.4.22.Final
> ---------------------
>
>                 Key: WFCORE-3508
>                 URL: https://issues.jboss.org/browse/WFCORE-3508
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 00:25:00 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Mon, 15 Jan 2018 00:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9502)
 javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name
 "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
In-Reply-To: <JIRA.12718725.1509442317000@Atlassian.JIRA>
References: <JIRA.12718725.1509442317000@Atlassian.JIRA>
	<JIRA.12718725.1509442317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718725.1509442317000.41577.1515993900385@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao updated WFLY-9502:
--------------------------
    Steps to Reproduce: 
Start EAP 6 with port offset to 1000

{code}
jboss-eap-6.4/bin/standalone.sh -c standalone-full.xml -Djboss.socket.binding.port-offset=1000
{\code}

Create jms queue on EAP6

{code}
/subsystem=messaging/hornetq-server=default/jms-queue=TargetQueue:add(durable=true, entries=["java:jboss/exported/jms/queue/targetQueue"])
{\code}

Start EAP7/WildFly using standalone-full.xml:

{code}
wildfly-12.0.0.Alpha1-SNAPSHOT/bin/standalone.sh -c standalone-full.xml
{\code}

Create source queue on EAP7 and then try to create the bridge

{code}
/subsystem=messaging-activemq/server=default/jms-queue=SourceQueue:add(durable=true, entries=["java:/jms/queue/sourceQueue"])


/subsystem=messaging-activemq/jms-bridge=testBridge:add(module="org.hornetq.client", quality-of-service=AT_MOST_ONCE, failure-retry-interval=2500, max-retries=10, max-batch-size=200, max-batch-time=60, source-connection-factory=ConnectionFactory, source-destination="jms/queue/sourceQueue", target-connection-factory="jms/RemoteConnectionFactory", target-destination="jms/queue/targetQueue", target-context={"java.naming.factory.initial" => "org.jboss.naming.remote.client.InitialContextFactory", "java.naming.provider.url" => "remote://localhost:5447"})

{\code}

Note that you need to add dependency on {{org.wildfly.naming-client}} to {{org.hornetq.client}} module

  was:
Create jms queue on EAP6

{code}
/subsystem=messaging/horentq-server=default/jms-queue:add(durable=true, entries=\["java:jboss/exported/jms/queue/TargetQueue"])
{\code}

Create source queue on EAP7 and then try to create the bridge

{code}
/subsystem=messaging-activemq/server=default/jms-queue=SourceQueue:add(durable=true, entries=\["java:/jms/queue/SourceQueue"])

/subsytem=messaging-activemq/jms-bridge=testBridge:add( \
  module="org.hornetq.client" \
  quality-of-service=AT_MOST_ONCE, \
  failure-retry-interval=2500, \
  max-retries=10, \
  max-batch-size=200, \
  max-batch-time=60, \
  source-connection-factory="ConnectionFactory", \
  source-destination="/jms/queue/SourceQueue", \
  target-connection-factory="jms/RemoteConnectionFactory", \
  target-destination="jms/queue/TargetQueue", \
  target-context={"java.naming.factory.initial" => "org.jboss.as.naming.IntialContextFactory", \
    "java.naming.provider.url" => "remote://localhost:5447" })
{\code}

Note that you need to add dependency on {{org.wildfly.naming-client}} to {{org.hornetq.client}} module



> javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9502
>                 URL: https://issues.jboss.org/browse/WFLY-9502
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Naming
>    Affects Versions: 11.0.0.Final
>            Reporter: Martin ?vehla
>            Assignee: Lin Gao
>            Priority: Critical
>              Labels: downstream_dependency
>
> When I create jms bridge on EAP7 that tries to connect to EAP6, it throws following issue when trying to do remote lookup for connection factory or destination on EAP6.
> {code}
> 2017-10-31 09:44:18,769 WARN  [org.apache.activemq.artemis.jms.bridge] (Thread-102) AMQ342010: Failed to connect JMS Bridge N/A: javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null"
> 	at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
> 	at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:46)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:32)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1072)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1247)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2600(JMSBridgeImpl.java:75)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1747)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {\code}
> When debugging I noticed that WildFlyRootContext.getProviderContext there's no NamingProviderFactory available to resolve the name, so I think the error message is just a consequence of that.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 15 00:27:00 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Mon, 15 Jan 2018 00:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9502)
 javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name
 "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
In-Reply-To: <JIRA.12718725.1509442317000@Atlassian.JIRA>
References: <JIRA.12718725.1509442317000@Atlassian.JIRA>
	<JIRA.12718725.1509442317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718725.1509442317000.41583.1515994020279@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514781#comment-13514781 ] 

Lin Gao commented on WFLY-9502:
-------------------------------

Updated reproduce steps mainly chaning 'org.jboss.as.naming.InitialContextFactory' to 'org.jboss.naming.remote.client.InitialContextFactory'



> javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9502
>                 URL: https://issues.jboss.org/browse/WFLY-9502
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Naming
>    Affects Versions: 11.0.0.Final
>            Reporter: Martin ?vehla
>            Assignee: Lin Gao
>            Priority: Critical
>              Labels: downstream_dependency
>
> When I create jms bridge on EAP7 that tries to connect to EAP6, it throws following issue when trying to do remote lookup for connection factory or destination on EAP6.
> {code}
> 2017-10-31 09:44:18,769 WARN  [org.apache.activemq.artemis.jms.bridge] (Thread-102) AMQ342010: Failed to connect JMS Bridge N/A: javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null"
> 	at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
> 	at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:46)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:32)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1072)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1247)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2600(JMSBridgeImpl.java:75)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1747)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {\code}
> When debugging I noticed that WildFlyRootContext.getProviderContext there's no NamingProviderFactory available to resolve the name, so I think the error message is just a consequence of that.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 15 00:27:00 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Mon, 15 Jan 2018 00:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9502)
 javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name
 "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
In-Reply-To: <JIRA.12718725.1509442317000@Atlassian.JIRA>
References: <JIRA.12718725.1509442317000@Atlassian.JIRA>
	<JIRA.12718725.1509442317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718725.1509442317000.41589.1515994020470@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514781#comment-13514781 ] 

Lin Gao edited comment on WFLY-9502 at 1/15/18 12:26 AM:
---------------------------------------------------------

Updated reproduce steps mainly changing 'org.jboss.as.naming.InitialContextFactory' to 'org.jboss.naming.remote.client.InitialContextFactory'




was (Author: gaol):
Updated reproduce steps mainly chaning 'org.jboss.as.naming.InitialContextFactory' to 'org.jboss.naming.remote.client.InitialContextFactory'



> javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9502
>                 URL: https://issues.jboss.org/browse/WFLY-9502
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Naming
>    Affects Versions: 11.0.0.Final
>            Reporter: Martin ?vehla
>            Assignee: Lin Gao
>            Priority: Critical
>              Labels: downstream_dependency
>
> When I create jms bridge on EAP7 that tries to connect to EAP6, it throws following issue when trying to do remote lookup for connection factory or destination on EAP6.
> {code}
> 2017-10-31 09:44:18,769 WARN  [org.apache.activemq.artemis.jms.bridge] (Thread-102) AMQ342010: Failed to connect JMS Bridge N/A: javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null"
> 	at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
> 	at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:46)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:32)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1072)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1247)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2600(JMSBridgeImpl.java:75)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1747)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {\code}
> When debugging I noticed that WildFlyRootContext.getProviderContext there's no NamingProviderFactory available to resolve the name, so I think the error message is just a consequence of that.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 15 00:37:00 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Mon, 15 Jan 2018 00:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9502)
 javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name
 "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
In-Reply-To: <JIRA.12718725.1509442317000@Atlassian.JIRA>
References: <JIRA.12718725.1509442317000@Atlassian.JIRA>
	<JIRA.12718725.1509442317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718725.1509442317000.41603.1515994620212@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514782#comment-13514782 ] 

Lin Gao commented on WFLY-9502:
-------------------------------

As the reproduce steps noted, the exception in question comes from module dependencies, adding dependency of {{org.wildfly.naming-client}} to related modules fix this exception.

> javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9502
>                 URL: https://issues.jboss.org/browse/WFLY-9502
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Naming
>    Affects Versions: 11.0.0.Final
>            Reporter: Martin ?vehla
>            Assignee: Lin Gao
>            Priority: Critical
>              Labels: downstream_dependency
>
> When I create jms bridge on EAP7 that tries to connect to EAP6, it throws following issue when trying to do remote lookup for connection factory or destination on EAP6.
> {code}
> 2017-10-31 09:44:18,769 WARN  [org.apache.activemq.artemis.jms.bridge] (Thread-102) AMQ342010: Failed to connect JMS Bridge N/A: javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null"
> 	at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
> 	at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:46)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:32)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1072)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1247)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2600(JMSBridgeImpl.java:75)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1747)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {\code}
> When debugging I noticed that WildFlyRootContext.getProviderContext there's no NamingProviderFactory available to resolve the name, so I think the error message is just a consequence of that.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 15 00:40:00 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Mon, 15 Jan 2018 00:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9669) JMS bridge fails to create
 session factory with connection timeout between WildFly and EAP 6.4
In-Reply-To: <JIRA.12727964.1515994633000@Atlassian.JIRA>
References: <JIRA.12727964.1515994633000@Atlassian.JIRA>
	<JIRA.12727964.1515994633000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727964.1515994633000.41622.1515994800495@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9669?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao moved JBEAP-14086 to WFLY-9669:
---------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-9669  (was: JBEAP-14086)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: IIOP
                       JMS
                           (was: ActiveMQ)
                           (was: IIOP)
    Affects Version/s:     (was: 7.1.0.CR4)


> JMS bridge fails to create session factory with connection timeout between WildFly and EAP 6.4
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9669
>                 URL: https://issues.jboss.org/browse/WFLY-9669
>             Project: WildFly
>          Issue Type: Bug
>          Components: IIOP, JMS
>            Reporter: Lin Gao
>            Assignee: Martyn Taylor
>
> When having configured JMS bridge on EAP 7 with target queue on EAP 6.4 after starting the server, after short while I can see that it failed to create session factory with exception \[1\].
> I am also attaching config files of EAP 6.4 server and of EAP 7.1.0.CR4 server.
> \[1\]
> {noformat}
> 2017-11-23 16:49:31,423 WARN  [org.apache.activemq.artemis.jms.bridge] (Thread-230) AMQ342010: Failed to connect JMS Bridge N/A: javax.jms.JMSException: Failed to create session factory
> 	at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:673)
> 	at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:112)
> 	at org.hornetq.jms.client.HornetQConnectionFactory.createConnection(HornetQConnectionFactory.java:107)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.createConnection(JMSBridgeImpl.java:979)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1148)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1247)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2600(JMSBridgeImpl.java:75)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1747)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> Caused by: HornetQConnectionTimedOutException[errorType=CONNECTION_TIMEDOUT message=HQ119013: Timed out waiting to receive cluster topology. Group:null]
> 	at org.hornetq.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:946)
> 	at org.hornetq.jms.client.HornetQConnectionFactory.createConnectionInternal(HornetQConnectionFactory.java:669)
> 	... 10 more
> 2017-11-23 16:49:31,443 INFO  [org.apache.activemq.artemis.jms.bridge] (Thread-230) AMQ341000: Failed to set up JMS bridge N/A connections. Most probably the source or target servers are unavailable. Will retry after a pause of 2,500 ms
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 00:44:00 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Mon, 15 Jan 2018 00:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9502)
 javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name
 "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
In-Reply-To: <JIRA.12718725.1509442317000@Atlassian.JIRA>
References: <JIRA.12718725.1509442317000@Atlassian.JIRA>
	<JIRA.12718725.1509442317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718725.1509442317000.41628.1515995040249@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9502?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514783#comment-13514783 ] 

Lin Gao commented on WFLY-9502:
-------------------------------

Even the PR: https://github.com/wildfly/wildfly/pull/10749 fixed the modules dependency issue, there is another timeout problem (WFLY-9669) to prevent the create the JMS bridge.

> javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null" when jms bridge is trying to do remote lookup on EAP6/HornetQ
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9502
>                 URL: https://issues.jboss.org/browse/WFLY-9502
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS, Naming
>    Affects Versions: 11.0.0.Final
>            Reporter: Martin ?vehla
>            Assignee: Lin Gao
>            Priority: Critical
>              Labels: downstream_dependency
>
> When I create jms bridge on EAP7 that tries to connect to EAP6, it throws following issue when trying to do remote lookup for connection factory or destination on EAP6.
> {code}
> 2017-10-31 09:44:18,769 WARN  [org.apache.activemq.artemis.jms.bridge] (Thread-102) AMQ342010: Failed to connect JMS Bridge N/A: javax.naming.InvalidNameException: WFNAM00007: Invalid URL scheme name "null"
> 	at org.wildfly.naming.client.WildFlyRootContext.getProviderContext(WildFlyRootContext.java:808)
> 	at org.wildfly.naming.client.WildFlyRootContext.lookup(WildFlyRootContext.java:140)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at javax.naming.InitialContext.lookup(InitialContext.java:417)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIFactorySupport.createObject(JNDIFactorySupport.java:46)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JNDIDestinationFactory.createDestination(JNDIDestinationFactory.java:32)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjects(JMSBridgeImpl.java:1072)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.setupJMSObjectsWithRetry(JMSBridgeImpl.java:1247)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl.access$2600(JMSBridgeImpl.java:75)
> 	at org.apache.activemq.artemis.jms.bridge.impl.JMSBridgeImpl$FailureHandler.run(JMSBridgeImpl.java:1747)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {\code}
> When debugging I noticed that WildFlyRootContext.getProviderContext there's no NamingProviderFactory available to resolve the name, so I think the error message is just a consequence of that.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 15 02:38:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Mon, 15 Jan 2018 02:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3509) Tests for enhanced help for
	CLI
In-Reply-To: <JIRA.12727966.1516001874000@Atlassian.JIRA>
References: <JIRA.12727966.1516001874000@Atlassian.JIRA>
	<JIRA.12727966.1516001874313@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727966.1516001874000.41749.1516001880071@Atlassian.JIRA>

Marek Kopeck? created WFCORE-3509:
-------------------------------------

             Summary: Tests for enhanced help for CLI
                 Key: WFCORE-3509
                 URL: https://issues.jboss.org/browse/WFCORE-3509
             Project: WildFly Core
          Issue Type: Task
          Components: CLI
            Reporter: Marek Kopeck?
            Assignee: Marek Kopeck?


Tests for enhanced help for CLI



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 15 03:57:00 2018
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 15 Jan 2018 03:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9665) HttpSession cannot be
 injected in distributed application
In-Reply-To: <JIRA.12727883.1515833380000@Atlassian.JIRA>
References: <JIRA.12727883.1515833380000@Atlassian.JIRA>
	<JIRA.12727883.1515833380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727883.1515833380000.42031.1516006620255@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9665?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514850#comment-13514850 ] 

Martin Kouba commented on WFLY-9665:
------------------------------------

Hello Zoltan, this is a known issue - WELD-2346, it's fixed in Weld 2.4.3 and 3.0.0. You should either upgrade to WildFly 11.0.0.Final or use the latest Weld 2.4 patch for 10.1.0: http://download.jboss.org/weld/2.4.5.Final/wildfly-10.1.0.Final-weld-2.4.5.Final-patch.zip. 

> HttpSession cannot be injected in distributed application
> ---------------------------------------------------------
>
>                 Key: WFLY-9665
>                 URL: https://issues.jboss.org/browse/WFLY-9665
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EE
>    Affects Versions: 10.1.0.Final
>            Reporter: Zoltan Laszlo Ferenci
>            Assignee: Martin Kouba
>         Attachments: HttpSessionInjectionBug.zip
>
>
> The CDI Specification states that HttpSession should be available for injection. It also has statements about when should the bean passivation capable.
> The problem is that it seems the io.undertow.servlet.spec.HttpSessionImpl is not serializable, and whenever you try to inject, you get exception at passivation.
> I would say it's normal if it's injected into a passivating scoped bean, because the CDI specification says that the bean is passivation capable only if all it's dependencies is passivation capable.
> However this is the case even if it's injected in a RequestScoped bean, that shouldn't be passivated. In the sample project only the HttpSession should be passivated that is independent from the CDI. Anyway it gives an error in that case too, and doesn't store and recover the HttpSession.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 03:59:00 2018
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Mon, 15 Jan 2018 03:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9665) HttpSession cannot be
 injected in distributed application
In-Reply-To: <JIRA.12727883.1515833380000@Atlassian.JIRA>
References: <JIRA.12727883.1515833380000@Atlassian.JIRA>
	<JIRA.12727883.1515833380000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727883.1515833380000.42040.1516006740807@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9665?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba resolved WFLY-9665.
--------------------------------
    Resolution: Won't Do


> HttpSession cannot be injected in distributed application
> ---------------------------------------------------------
>
>                 Key: WFLY-9665
>                 URL: https://issues.jboss.org/browse/WFLY-9665
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, EE
>    Affects Versions: 10.1.0.Final
>            Reporter: Zoltan Laszlo Ferenci
>            Assignee: Martin Kouba
>         Attachments: HttpSessionInjectionBug.zip
>
>
> The CDI Specification states that HttpSession should be available for injection. It also has statements about when should the bean passivation capable.
> The problem is that it seems the io.undertow.servlet.spec.HttpSessionImpl is not serializable, and whenever you try to inject, you get exception at passivation.
> I would say it's normal if it's injected into a passivating scoped bean, because the CDI specification says that the bean is passivation capable only if all it's dependencies is passivation capable.
> However this is the case even if it's injected in a RequestScoped bean, that shouldn't be passivated. In the sample project only the HttpSession should be passivated that is independent from the CDI. Anyway it gives an error in that case too, and doesn't store and recover the HttpSession.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 04:58:04 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 15 Jan 2018 04:58:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9670) Add the subordinate orphan
 filters for Narayana
In-Reply-To: <JIRA.12727977.1516010267000@Atlassian.JIRA>
References: <JIRA.12727977.1516010267000@Atlassian.JIRA>
	<JIRA.12727977.1516010267156@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727977.1516010267000.42648.1516010284947@Atlassian.JIRA>

Tom Jenkinson created WFLY-9670:
-----------------------------------

             Summary: Add the subordinate orphan filters for Narayana
                 Key: WFLY-9670
                 URL: https://issues.jboss.org/browse/WFLY-9670
             Project: WildFly
          Issue Type: Bug
          Components: Transactions
            Reporter: Tom Jenkinson
            Assignee: Tom Jenkinson
            Priority: Blocker
             Fix For: 12.0.0.Alpha1


There are some missing orphan filters in Narayana that should be added to the WFLY default configuration.

Without them there is a data integrity issue as competing remote servers may rollback each others branches.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 05:14:00 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 15 Jan 2018 05:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9671) Upgrade Narayana to
	5.5.31.Final
In-Reply-To: <JIRA.12727980.1516011234000@Atlassian.JIRA>
References: <JIRA.12727980.1516011234000@Atlassian.JIRA>
	<JIRA.12727980.1516011234411@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727980.1516011234000.42859.1516011240284@Atlassian.JIRA>

Tom Jenkinson created WFLY-9671:
-----------------------------------

             Summary: Upgrade Narayana to 5.5.31.Final
                 Key: WFLY-9671
                 URL: https://issues.jboss.org/browse/WFLY-9671
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Transactions
            Reporter: Tom Jenkinson
            Assignee: Tom Jenkinson


https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310200&version=12336596



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 05:25:00 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 15 Jan 2018 05:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9670) Add the subordinate orphan
 filters and recovery module for Narayana
In-Reply-To: <JIRA.12727977.1516010267000@Atlassian.JIRA>
References: <JIRA.12727977.1516010267000@Atlassian.JIRA>
	<JIRA.12727977.1516010267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727977.1516010267000.43002.1516011900167@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-9670:
--------------------------------
    Summary: Add the subordinate orphan filters and recovery module for Narayana  (was: Add the subordinate orphan filters for Narayana)


> Add the subordinate orphan filters and recovery module for Narayana
> -------------------------------------------------------------------
>
>                 Key: WFLY-9670
>                 URL: https://issues.jboss.org/browse/WFLY-9670
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>            Priority: Blocker
>             Fix For: 12.0.0.Alpha1
>
>
> There are some missing orphan filters in Narayana that should be added to the WFLY default configuration.
> Without them there is a data integrity issue as competing remote servers may rollback each others branches.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 05:26:00 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 15 Jan 2018 05:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9670) Add the subordinate orphan
 filters and recovery module for Narayana
In-Reply-To: <JIRA.12727977.1516010267000@Atlassian.JIRA>
References: <JIRA.12727977.1516010267000@Atlassian.JIRA>
	<JIRA.12727977.1516010267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727977.1516010267000.43009.1516011960317@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9670?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson updated WFLY-9670:
--------------------------------
    Description: 
There is a missing orphan filter in Narayana that should be added to the WFLY default configuration.

Without it there is a data integrity issue as competing remote servers may rollback each others branches.

  was:
There are some missing orphan filters in Narayana that should be added to the WFLY default configuration.

Without them there is a data integrity issue as competing remote servers may rollback each others branches.



> Add the subordinate orphan filters and recovery module for Narayana
> -------------------------------------------------------------------
>
>                 Key: WFLY-9670
>                 URL: https://issues.jboss.org/browse/WFLY-9670
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>            Priority: Blocker
>             Fix For: 12.0.0.Alpha1
>
>
> There is a missing orphan filter in Narayana that should be added to the WFLY default configuration.
> Without it there is a data integrity issue as competing remote servers may rollback each others branches.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 05:54:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 15 Jan 2018 05:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9671) Upgrade Narayana to
	5.5.31.Final
In-Reply-To: <JIRA.12727980.1516011234000@Atlassian.JIRA>
References: <JIRA.12727980.1516011234000@Atlassian.JIRA>
	<JIRA.12727980.1516011234000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727980.1516011234000.43315.1516013640903@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9671:
--------------------------------
    Comment: was deleted

(was: A comment with security level 'Red Hat Employee' was removed.)


> Upgrade Narayana to 5.5.31.Final
> --------------------------------
>
>                 Key: WFLY-9671
>                 URL: https://issues.jboss.org/browse/WFLY-9671
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>
> https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310200&version=12336596



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 06:11:00 2018
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Mon, 15 Jan 2018 06:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1475) Empty username for
 FormAuthenticationMechanism causes IllegalArgumentException
In-Reply-To: <JIRA.12726352.1514982408000@Atlassian.JIRA>
References: <JIRA.12726352.1514982408000@Atlassian.JIRA>
	<JIRA.12726352.1514982408000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726352.1514982408000.43491.1516014660760@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Romain Pelisse reassigned ELY-1475:
-----------------------------------

    Assignee: Romain Pelisse  (was: Ilia Vassilev)


> Empty username for FormAuthenticationMechanism causes IllegalArgumentException
> ------------------------------------------------------------------------------
>
>                 Key: ELY-1475
>                 URL: https://issues.jboss.org/browse/ELY-1475
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Romain Pelisse
>             Fix For: 1.2.0.Beta12
>
>
> In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username.
> See exception:
> {code}
> ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException
> 	at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {code}
> It seems that [1] should also check {{username.length() == 0}}.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3ecae6be7ce1c9b96ab642ddc4ad/src/main/java/org/wildfly/security/http/impl/FormAuthenticationMechanism.java#L165



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 06:11:01 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 15 Jan 2018 06:11:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9672) Update Resteasy from
 3.0.24.Final to 3.0.25.Final
In-Reply-To: <JIRA.12727990.1516014619000@Atlassian.JIRA>
References: <JIRA.12727990.1516014619000@Atlassian.JIRA>
	<JIRA.12727990.1516014619000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727990.1516014619000.43515.1516014661456@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9672?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky moved JBEAP-14091 to WFLY-9672:
---------------------------------------------

           Project: WildFly  (was: JBoss Enterprise Application Platform)
               Key: WFLY-9672  (was: JBEAP-14091)
          Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
       Component/s: REST
                        (was: REST)
    Target Release:   (was: 7.backlog.GA)


> Update Resteasy from 3.0.24.Final to 3.0.25.Final
> -------------------------------------------------
>
>                 Key: WFLY-9672
>                 URL: https://issues.jboss.org/browse/WFLY-9672
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: REST
>            Reporter: Ivo Studensky
>            Assignee: Alessio Soldano
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 06:20:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 15 Jan 2018 06:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3496) Upgrade WildFly Elytron to
	1.2.0.Beta11
In-Reply-To: <JIRA.12727151.1515509860000@Atlassian.JIRA>
References: <JIRA.12727151.1515509860000@Atlassian.JIRA>
	<JIRA.12727151.1515509860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727151.1515509860000.43544.1516015200456@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-3496:
-------------------------------------
    Summary: Upgrade WildFly Elytron to 1.2.0.Beta11  (was: Upgrade WildFly Elytron to 1.2.0.Beta10)


> Upgrade WildFly Elytron to 1.2.0.Beta11
> ---------------------------------------
>
>                 Key: WFCORE-3496
>                 URL: https://issues.jboss.org/browse/WFCORE-3496
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Ivo Studensky
>            Assignee: Darran Lofthouse
>              Labels: downstream_dependency
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 06:20:01 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 15 Jan 2018 06:20:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3496) Upgrade WildFly Elytron to
	1.2.0.Beta12
In-Reply-To: <JIRA.12727151.1515509860000@Atlassian.JIRA>
References: <JIRA.12727151.1515509860000@Atlassian.JIRA>
	<JIRA.12727151.1515509860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727151.1515509860000.43552.1516015201131@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-3496:
-------------------------------------
    Summary: Upgrade WildFly Elytron to 1.2.0.Beta12  (was: Upgrade WildFly Elytron to 1.2.0.Beta11)


> Upgrade WildFly Elytron to 1.2.0.Beta12
> ---------------------------------------
>
>                 Key: WFCORE-3496
>                 URL: https://issues.jboss.org/browse/WFCORE-3496
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Ivo Studensky
>            Assignee: Darran Lofthouse
>              Labels: downstream_dependency
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 06:48:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 15 Jan 2018 06:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9128) Upgrade Apache CXF to 3.1.13
In-Reply-To: <JIRA.12704639.1500992195000@Atlassian.JIRA>
References: <JIRA.12704639.1500992195000@Atlassian.JIRA>
	<JIRA.12704639.1500992195000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12704639.1500992195000.43749.1516016880466@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9128:
--------------------------------
    Description: 
Upgrade Apache CXF to 3.1.13.


  was:
Upgrade Apache CXF to 3.1.11 (from 3.1.10)




> Upgrade Apache CXF to 3.1.13
> ----------------------------
>
>                 Key: WFLY-9128
>                 URL: https://issues.jboss.org/browse/WFLY-9128
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Services
>            Reporter: Ivo Studensky
>            Assignee: Alessio Soldano
>              Labels: downstream_dependency
>
> Upgrade Apache CXF to 3.1.13.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 07:02:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 15 Jan 2018 07:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9128) Upgrade Apache CXF to 3.1.13
In-Reply-To: <JIRA.12704639.1500992195000@Atlassian.JIRA>
References: <JIRA.12704639.1500992195000@Atlassian.JIRA>
	<JIRA.12704639.1500992195000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12704639.1500992195000.43913.1516017720590@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9128:
--------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/10751  (was: https://github.com/wildfly/wildfly/pull/10382)


> Upgrade Apache CXF to 3.1.13
> ----------------------------
>
>                 Key: WFLY-9128
>                 URL: https://issues.jboss.org/browse/WFLY-9128
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Services
>            Reporter: Ivo Studensky
>            Assignee: Alessio Soldano
>              Labels: downstream_dependency
>
> Upgrade Apache CXF to 3.1.13.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 07:21:01 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 15 Jan 2018 07:21:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3457) Reduce Classes in the
	Elytron Subsystem
In-Reply-To: <JIRA.12724639.1513168462000@Atlassian.JIRA>
References: <JIRA.12724639.1513168462000@Atlassian.JIRA>
	<JIRA.12724639.1513168462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724639.1513168462000.44058.1516018861712@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-3457:
-------------------------------------
    Description:     (was: We currently compile to 323 classes, as this subsystem is almost exclusively about management representation (Model and XML) rather than implementation all 323 of these classes will need to be loaded when the subsystem is installed.

By switching to builders where we can instead of anonymous inner classes and possibly using more common classes I believe a reasonable early target could be drop this to 200 to 250 classes so possibly up to a 33% saving.

Even without restructuring our resource registrations a lot of our classes exist just to logically group related resources rather than any other purpose.)


> Reduce Classes in the Elytron Subsystem
> ---------------------------------------
>
>                 Key: WFCORE-3457
>                 URL: https://issues.jboss.org/browse/WFCORE-3457
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha6
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 07:22:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 15 Jan 2018 07:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3457) Reduce class loading of
 Elytron subsystem
In-Reply-To: <JIRA.12724639.1513168462000@Atlassian.JIRA>
References: <JIRA.12724639.1513168462000@Atlassian.JIRA>
	<JIRA.12724639.1513168462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724639.1513168462000.44066.1516018920746@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-3457:
-------------------------------------
    Summary: Reduce class loading of Elytron subsystem  (was: Reduce Classes in the Elytron Subsystem)


> Reduce class loading of Elytron subsystem
> -----------------------------------------
>
>                 Key: WFCORE-3457
>                 URL: https://issues.jboss.org/browse/WFCORE-3457
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha6
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 07:24:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Mon, 15 Jan 2018 07:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3457) Reduce class loading of
 Elytron subsystem
In-Reply-To: <JIRA.12724639.1513168462000@Atlassian.JIRA>
References: <JIRA.12724639.1513168462000@Atlassian.JIRA>
	<JIRA.12724639.1513168462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724639.1513168462000.44090.1516019040571@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13514972#comment-13514972 ] 

Darran Lofthouse commented on WFCORE-3457:
------------------------------------------

I have reduced the scope of this down, as has been identified elsewhere a lot of the class count is caused by a single resource needing to implement multiple interfaces for different reasons i.e. resource definition, add handler, remove handler etc...

I could refactor a lot more to try and reduce what is loaded by converting the add handlers into some kind of factory so we only look up the impl if a resource exists but TBH we end up with either more classes or big classes which both impact on metaspace.


> Reduce class loading of Elytron subsystem
> -----------------------------------------
>
>                 Key: WFCORE-3457
>                 URL: https://issues.jboss.org/browse/WFCORE-3457
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha6
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 07:27:00 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Mon, 15 Jan 2018 07:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9122) Containers for distributed
 work manager tests always started in testsuite/integration/manualmode
In-Reply-To: <JIRA.12703252.1500880022000@Atlassian.JIRA>
References: <JIRA.12703252.1500880022000@Atlassian.JIRA>
	<JIRA.12703252.1500880022000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12703252.1500880022000.44104.1516019220421@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges reassigned WFLY-9122:
----------------------------------

    Assignee: Yeray Borges


> Containers for distributed work manager tests always started in testsuite/integration/manualmode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9122
>                 URL: https://issues.jboss.org/browse/WFLY-9122
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Yeray Borges
>
> The Arquillian containers {{dwm-container-0}} and {{dwm-container-1}} are always started in the manualmode testsuite module. 
> It can lead to port conflicts when another test wants to use its own server configuration with port offset 200 or 300. It also adds additional time to execute single test ({{mvn test -Dtest=MyTestCase}}), because these 2 containers has to be started first.
> The {{dwm-*}} containers are used by distributed work manager tests in package {{org.jboss.as.test.manualmode.jca.workmanager.distributed}}.
> CC [~rjanik]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 07:36:01 2018
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Mon, 15 Jan 2018 07:36:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1475) Empty username for
 FormAuthenticationMechanism causes IllegalArgumentException
In-Reply-To: <JIRA.12726352.1514982408000@Atlassian.JIRA>
References: <JIRA.12726352.1514982408000@Atlassian.JIRA>
	<JIRA.12726352.1514982408000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726352.1514982408000.44170.1516019761383@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-1475:
----------------------------------

    Assignee: Ilia Vassilev  (was: Romain Pelisse)


> Empty username for FormAuthenticationMechanism causes IllegalArgumentException
> ------------------------------------------------------------------------------
>
>                 Key: ELY-1475
>                 URL: https://issues.jboss.org/browse/ELY-1475
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>             Fix For: 1.2.0.Beta12
>
>
> In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username.
> See exception:
> {code}
> ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException
> 	at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {code}
> It seems that [1] should also check {{username.length() == 0}}.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3ecae6be7ce1c9b96ab642ddc4ad/src/main/java/org/wildfly/security/http/impl/FormAuthenticationMechanism.java#L165



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:07 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1946) DMN Editor
In-Reply-To: <JIRA.12696991.1497281558000@Atlassian.JIRA>
References: <JIRA.12696991.1497281558000@Atlassian.JIRA>
	<JIRA.12696991.1497281558000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696991.1497281558000.44694.1516023307079@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1946:
-----------------------------------
    Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04  (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02)


> DMN Editor
> ----------
>
>                 Key: DROOLS-1946
>                 URL: https://issues.jboss.org/browse/DROOLS-1946
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>              Labels: UX
>             Fix For: 7.6.0.Final
>
>
> Place holder for all DMN Editor related activities



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:09 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1825) [Guided Decision Table]
 Ability to change HIT policy in a decision table anytime
In-Reply-To: <JIRA.12697420.1497441043000@Atlassian.JIRA>
References: <JIRA.12697420.1497441043000@Atlassian.JIRA>
	<JIRA.12697420.1497441043000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12697420.1497441043000.44767.1516023309052@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1825:
-----------------------------------
    Sprint: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04  (was: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02)


> [Guided Decision Table] Ability to change HIT policy in a decision table anytime
> --------------------------------------------------------------------------------
>
>                 Key: DROOLS-1825
>                 URL: https://issues.jboss.org/browse/DROOLS-1825
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.1.0.Beta2
>            Reporter: Ivo Bek
>            Assignee: Toni Rikkola
>            Priority: Critical
>              Labels: UX
>         Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png, GDTAnalysis at 2x.png, GDTColumns at 2x.png
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy.
> Thus, it should be possible to change HIT policy in a decision table anytime.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:09 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1609) Augment FEEL AST node at
 compilation with return type
In-Reply-To: <JIRA.12696318.1496844128000@Atlassian.JIRA>
References: <JIRA.12696318.1496844128000@Atlassian.JIRA>
	<JIRA.12696318.1496844128000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696318.1496844128000.44774.1516023309323@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1609:
-----------------------------------
    Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04  (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02)


> Augment FEEL AST node at compilation with return type
> -----------------------------------------------------
>
>                 Key: DROOLS-1609
>                 URL: https://issues.jboss.org/browse/DROOLS-1609
>             Project: Drools
>          Issue Type: Enhancement
>          Components: dmn engine
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>            Priority: Minor
>
> This is needed so to be able to determine the result of a boxed function at compile time, in turn to be able at compile time to determine a valid compilation without error of a BKM for instance.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:09 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1959) [DMN Editor] Extend
 marshaller support for Expressions
In-Reply-To: <JIRA.12705255.1501234063000@Atlassian.JIRA>
References: <JIRA.12705255.1501234063000@Atlassian.JIRA>
	<JIRA.12705255.1501234063000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12705255.1501234063000.44782.1516023309562@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1959?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1959:
-----------------------------------
    Sprint: 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04  (was: 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02)


> [DMN Editor] Extend marshaller support for Expressions
> ------------------------------------------------------
>
>                 Key: DROOLS-1959
>                 URL: https://issues.jboss.org/browse/DROOLS-1959
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>
> When UI support for DMN Expression is available, the marshaller shall be extended to support marshalling between DMN xml and the stunner representation of the expression.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:09 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1701) FEEL code generation and
	compilation
In-Reply-To: <JIRA.12707146.1502459679000@Atlassian.JIRA>
References: <JIRA.12707146.1502459679000@Atlassian.JIRA>
	<JIRA.12707146.1502459679000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12707146.1502459679000.44800.1516023309990@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1701:
-----------------------------------
    Sprint: 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04  (was: 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02)


> FEEL code generation and compilation
> ------------------------------------
>
>                 Key: DROOLS-1701
>                 URL: https://issues.jboss.org/browse/DROOLS-1701
>             Project: Drools
>          Issue Type: Task
>          Components: dmn engine
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:10 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1795) [Guided Decision Table]
 Invalid error message when renaming bound variable name in conditional BRL
 column.
In-Reply-To: <JIRA.12712612.1505924833000@Atlassian.JIRA>
References: <JIRA.12712612.1505924833000@Atlassian.JIRA>
	<JIRA.12712612.1505924833000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712612.1505924833000.44823.1516023310544@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1795:
-----------------------------------
    Sprint: 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04  (was: 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02)


> [Guided Decision Table] Invalid error message when renaming bound variable name in conditional BRL column.
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1795
>                 URL: https://issues.jboss.org/browse/DROOLS-1795
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.0.0.Final
>            Reporter: Mark Coble
>            Assignee: Mark Coble
>            Priority: Minor
>             Fix For: 7.0.0.Final
>
>         Attachments: guvnor-3507.png
>
>
> If a condition BRL column is added to a DT with bound variables that are used in an action column and that variable name is subsequently changed, the attached error message occurs when updating the action column with the new variable name.   In the attached message the original variable name is 'app'.  Hitting 'ok' returns you to the DT which has actually refactored the DT with the new variable name and validation is successful.  



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:11 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1767) FEEL: add compile-time
	cycle detection
In-Reply-To: <JIRA.12716806.1508243245000@Atlassian.JIRA>
References: <JIRA.12716806.1508243245000@Atlassian.JIRA>
	<JIRA.12716806.1508243245000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12716806.1508243245000.44845.1516023311254@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1767:
-----------------------------------
    Sprint: 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04  (was: 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02)


> FEEL: add compile-time cycle detection 
> ---------------------------------------
>
>                 Key: DROOLS-1767
>                 URL: https://issues.jboss.org/browse/DROOLS-1767
>             Project: Drools
>          Issue Type: Enhancement
>          Components: dmn engine
>    Affects Versions: 7.4.1.Final
>            Reporter: Fedor Gavrilov
>            Assignee: Fedor Gavrilov
>            Priority: Minor
>
> Similar to what's done in https://issues.jboss.org/browse/DROOLS-1730 but during validation stage



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:11 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1770) More FEEL runtime cycle
	detection tests
In-Reply-To: <JIRA.12717263.1508421834000@Atlassian.JIRA>
References: <JIRA.12717263.1508421834000@Atlassian.JIRA>
	<JIRA.12717263.1508421834000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12717263.1508421834000.44854.1516023311598@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1770:
-----------------------------------
    Sprint: 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04  (was: 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02)


> More FEEL runtime cycle detection tests
> ---------------------------------------
>
>                 Key: DROOLS-1770
>                 URL: https://issues.jboss.org/browse/DROOLS-1770
>             Project: Drools
>          Issue Type: Enhancement
>          Components: dmn engine
>    Affects Versions: 7.4.1.Final
>            Reporter: Fedor Gavrilov
>            Assignee: Fedor Gavrilov
>            Priority: Minor
>
> Runtime cycle detecton lacks tests for false positive, such as deadly diamond topology:
> A depends on B and C
> B and C depend on D



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:11 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2109) [XLS Decision Table] New
 Asset Dialogue misses descriptions
In-Reply-To: <JIRA.12719362.1509700869000@Atlassian.JIRA>
References: <JIRA.12719362.1509700869000@Atlassian.JIRA>
	<JIRA.12719362.1509700869000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719362.1509700869000.44857.1516023311663@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2109:
-----------------------------------
    Sprint: 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04  (was: 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02)


> [XLS Decision Table] New Asset Dialogue misses descriptions
> -----------------------------------------------------------
>
>                 Key: DROOLS-2109
>                 URL: https://issues.jboss.org/browse/DROOLS-2109
>             Project: Drools
>          Issue Type: Bug
>          Components: XLS Decision Table Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>         Attachments: Screenshot from 2017-11-03 10-20-21.png
>
>
> The attached dialogue shows missing descriptions for table format and file selector.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:12 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2155) table editor should use
 full canvas area available
In-Reply-To: <JIRA.12722667.1511895299000@Atlassian.JIRA>
References: <JIRA.12722667.1511895299000@Atlassian.JIRA>
	<JIRA.12722667.1511895299000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722667.1511895299000.44869.1516023312026@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2155:
-----------------------------------
    Sprint: 2018 Week 01-02, 2018 Week 03-04  (was: 2018 Week 01-02)


> table editor should use full canvas area available
> --------------------------------------------------
>
>                 Key: DROOLS-2155
>                 URL: https://issues.jboss.org/browse/DROOLS-2155
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Michael Anstis
>            Priority: Minor
>              Labels: UX
>
> DMN table editor should use the full canvas width that is available (minus panels, toolbars, etc.) It should not appear as a smaller fixed size area, with scrollbars, within the canvas. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:13 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2184) UX design DRD logic table
	actions
In-Reply-To: <JIRA.12725294.1513357201000@Atlassian.JIRA>
References: <JIRA.12725294.1513357201000@Atlassian.JIRA>
	<JIRA.12725294.1513357201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725294.1513357201000.44905.1516023313478@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2184:
-----------------------------------
    Sprint: 2018 Week 01-02, 2018 Week 03-04  (was: 2018 Week 01-02)


> UX design DRD logic table actions
> ---------------------------------
>
>                 Key: DROOLS-2184
>                 URL: https://issues.jboss.org/browse/DROOLS-2184
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>
> Use case description:

 As a business user (Citizen Developer?), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.



> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 15 08:35:14 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2215) [DMN Editor] Function
 Definition is not saved
In-Reply-To: <JIRA.12726675.1515133295000@Atlassian.JIRA>
References: <JIRA.12726675.1515133295000@Atlassian.JIRA>
	<JIRA.12726675.1515133295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726675.1515133295000.44931.1516023314059@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2215:
-----------------------------------
    Sprint: 2018 Week 01-02, 2018 Week 03-04  (was: 2018 Week 01-02)


> [DMN Editor] Function Definition is not saved
> ---------------------------------------------
>
>                 Key: DROOLS-2215
>                 URL: https://issues.jboss.org/browse/DROOLS-2215
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:14 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2216) [DMN Editor] Decision Table
 Definition is not saved
In-Reply-To: <JIRA.12726676.1515133399000@Atlassian.JIRA>
References: <JIRA.12726676.1515133399000@Atlassian.JIRA>
	<JIRA.12726676.1515133399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726676.1515133399000.44935.1516023314179@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2216:
-----------------------------------
    Sprint: 2018 Week 01-02, 2018 Week 03-04  (was: 2018 Week 01-02)


> [DMN Editor] Decision Table Definition is not saved
> ---------------------------------------------------
>
>                 Key: DROOLS-2216
>                 URL: https://issues.jboss.org/browse/DROOLS-2216
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:14 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.44940.1516023314339@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2217:
-----------------------------------
    Sprint: 2018 Week 01-02, 2018 Week 03-04  (was: 2018 Week 01-02)


> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:14 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2230) Deadlock related to
 org.kie.workbench.common.services.backend.builder.core.LRUProjectDependenciesClassLoaderCache
In-Reply-To: <JIRA.12727309.1515587983000@Atlassian.JIRA>
References: <JIRA.12727309.1515587983000@Atlassian.JIRA>
	<JIRA.12727309.1515587983000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727309.1515587983000.44949.1516023314621@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2230:
-----------------------------------
    Sprint: 2018 Week 01-02, 2018 Week 03-04  (was: 2018 Week 01-02)


> Deadlock related to org.kie.workbench.common.services.backend.builder.core.LRUProjectDependenciesClassLoaderCache
> -----------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2230
>                 URL: https://issues.jboss.org/browse/DROOLS-2230
>             Project: Drools
>          Issue Type: Bug
>          Components: build
>    Affects Versions: 7.5.0.Final
>         Environment: EAP 7.1
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>            Priority: Blocker
>              Labels: reported-by-qe
>
> We have encountered a deadlock in business-central prohibiting EAP from stopping:
> Found one Java-level deadlock:
> =============================
> "Thread-848":
>   waiting to lock monitor 0x00007f3f8008f788 (object 0x000000008f743730, a org.kie.workbench.common.services.backend.builder.core.LRUProjectDependenciesClassLoaderCache$Proxy$_$$_WeldClientProxy),
>   which is held by "Thread-377"
> "Thread-377":
>   waiting to lock monitor 0x00007f3f80092228 (object 0x000000009579fac0, a org.drools.compiler.kie.builder.impl.KieFileSystemImpl),
>   which is held by "Thread-520"
> "Thread-520":
>   waiting to lock monitor 0x00007f3f8008f788 (object 0x000000008f743730, a org.kie.workbench.common.services.backend.builder.core.LRUProjectDependenciesClassLoaderCache$Proxy$_$$_WeldClientProxy),
>   which is held by "Thread-377"
> Please have a look at the full jstack output in the attachment.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:35:14 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 15 Jan 2018 08:35:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2236) Cover marshalling of
	UnaryTests
In-Reply-To: <JIRA.12727659.1515745108000@Atlassian.JIRA>
References: <JIRA.12727659.1515745108000@Atlassian.JIRA>
	<JIRA.12727659.1515745108000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727659.1515745108000.44952.1516023314692@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2236:
-----------------------------------
    Sprint: 2018 Week 01-02, 2018 Week 03-04  (was: 2018 Week 01-02)


> Cover marshalling of UnaryTests
> -------------------------------
>
>                 Key: DROOLS-2236
>                 URL: https://issues.jboss.org/browse/DROOLS-2236
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>         Attachments: index.html
>
>
> According to the attached jacoco report, the coverage of marshaling {{UnaryTests}} class should be increased.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 08:56:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Mon, 15 Jan 2018 08:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9666) ClassLoader leak in
 org.jboss.el.cache.FactoryFinderCache (Wildfly 11)
In-Reply-To: <JIRA.12727948.1515943218000@Atlassian.JIRA>
References: <JIRA.12727948.1515943218000@Atlassian.JIRA>
	<JIRA.12727948.1515943218000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727948.1515943218000.45132.1516024560330@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned WFLY-9666:
---------------------------------

    Component/s: Web (Undertow)
                     (was: Class Loading)
       Assignee: Stuart Douglas  (was: David Lloyd)


This seems like maybe some undeploy action is missing from the servlet deployer.

> ClassLoader leak in org.jboss.el.cache.FactoryFinderCache (Wildfly 11)
> ----------------------------------------------------------------------
>
>                 Key: WFLY-9666
>                 URL: https://issues.jboss.org/browse/WFLY-9666
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 11.0.0.Final
>         Environment: macOS
>            Reporter: Bruno Medeiros
>            Assignee: Stuart Douglas
>            Priority: Critical
>         Attachments: Screen Shot 2018-01-14 at 19.32.10.png
>
>
> I was investigating why my class loader was leaking and after fixing all the problems within my application classes I got the leak shown in the attachment.
>  !Screen Shot 2018-01-14 at 19.32.10.png|thumbnail! 
> This is pretty similar with https://issues.jboss.org/browse/WFLY-3365, not sure if I should have reopened that one o raised this one, sorry if I took the wrong decision.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 09:10:01 2018
From: issues at jboss.org (Jan Stourac (JIRA))
Date: Mon, 15 Jan 2018 09:10:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9673) NullPointerException with
 JDK9 + wildfly-openssl + Http2 utilized
In-Reply-To: <JIRA.12728032.1516025377000@Atlassian.JIRA>
References: <JIRA.12728032.1516025377000@Atlassian.JIRA>
	<JIRA.12728032.1516025377687@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12728032.1516025377000.45216.1516025401117@Atlassian.JIRA>

Jan Stourac created WFLY-9673:
---------------------------------

             Summary: NullPointerException with JDK9 + wildfly-openssl + Http2 utilized
                 Key: WFLY-9673
                 URL: https://issues.jboss.org/browse/WFLY-9673
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
    Affects Versions: No Release
            Reporter: Jan Stourac
            Assignee: Stuart Douglas


I can see bunch of NPEs and IllegalStateExceptions when I execute [http2 testsuite|https://github.com/summerwind/h2spec] against running Wildfly server (build from master/62583a78a850ba3fb182dda9b5ed35d99e016960 revision) running with JDK9 and wildfly-openssl (my openssl version is {{OpenSSL 1.1.0g-fips  2 Nov 2017}}):
{code}
2018-01-15 13:15:04,095 ERROR [io.undertow.request.io] (default I/O-16) UT005090: Unexpected failure: java.lang.NullPointerException
        at io.undertow.core//io.undertow.protocols.http2.Http2Channel.sendPing(Http2Channel.java:794)
        at io.undertow.core//io.undertow.protocols.http2.Http2Channel.createChannelImpl(Http2Channel.java:489)
        at io.undertow.core//io.undertow.protocols.http2.Http2Channel.createChannel(Http2Channel.java:342)
        at io.undertow.core//io.undertow.protocols.http2.Http2Channel.createChannel(Http2Channel.java:68)
        at io.undertow.core//io.undertow.server.protocol.framed.AbstractFramedChannel.receive(AbstractFramedChannel.java:451)
        at io.undertow.core//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:109)
        at io.undertow.core//io.undertow.server.protocol.http2.Http2ReceiveListener.handleEvent(Http2ReceiveListener.java:60)
        at org.jboss.xnio//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
        at io.undertow.core//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:921)
        at io.undertow.core//io.undertow.server.protocol.framed.AbstractFramedChannel$FrameReadListener.handleEvent(AbstractFramedChannel.java:902)
        at org.jboss.xnio//org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
        at org.jboss.xnio//org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
        at io.undertow.core//io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1145)
        at io.undertow.core//io.undertow.protocols.ssl.SslConduit$1.run(SslConduit.java:168)
        at org.jboss.xnio.nio//org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:612)
        at org.jboss.xnio.nio//org.xnio.nio.WorkerThread.run(WorkerThread.java:479)

14:32:23,593 ERROR [io.undertow.request] (default task-128) UT005071: Undertow request failed HttpServerExchange{ POST / request {Host=[127.0.0.1:8443]} response {Last-Modified=[Mon, 15 Jan 2018 07:43:34 GMT], X-Powered-By=[Undertow/1], Server=[WildFly/11], Content-Length=[2438], Content-Type=[text/html], Accept-Ranges=[bytes]}}: java.lang.IllegalStateException: UT000127: Response has already been sent
	at io.undertow.core//io.undertow.io.AsyncSenderImpl.send(AsyncSenderImpl.java:122)
	at io.undertow.core//io.undertow.server.handlers.resource.PathResource$1ServerTask.run(PathResource.java:184)
	at io.undertow.core//io.undertow.server.handlers.resource.PathResource.serveImpl(PathResource.java:253)
	at io.undertow.core//io.undertow.server.handlers.resource.PathResource.serve(PathResource.java:111)
	at io.undertow.core//io.undertow.server.handlers.resource.ResourceHandler$1.handleRequest(ResourceHandler.java:337)
	at io.undertow.core//io.undertow.server.Connectors.executeRootHandler(Connectors.java:332)
	at io.undertow.core//io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:830)
	at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
	at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
	at java.base/java.lang.Thread.run(Thread.java:844)
{code}

All exceptions seems to repeat. This causes 16 tests to fail. When I use JDK8 or when I switch back to JSSE ALPN instead of wildfly-openssl, no test fail at all and there are no NPEs in server.log anymore, although the IllegalStateExceptions still remains there.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 11:10:00 2018
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 15 Jan 2018 11:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9666) ClassLoader leak in
 org.jboss.el.cache.FactoryFinderCache (Wildfly 11)
In-Reply-To: <JIRA.12727948.1515943218000@Atlassian.JIRA>
References: <JIRA.12727948.1515943218000@Atlassian.JIRA>
	<JIRA.12727948.1515943218000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727948.1515943218000.46153.1516032600549@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9666?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar updated WFLY-9666:
------------------------------
    Description: 
I was investigating why my class loader was leaking and after fixing all the problems within my application classes I got the leak shown in the attachment.

 !Screen Shot 2018-01-14 at 19.32.10.png|thumbnail! 

This is pretty similar with WFLY-3365, not sure if I should have reopened that one o raised this one, sorry if I took the wrong decision.


  was:
I was investigating why my class loader was leaking and after fixing all the problems within my application classes I got the leak shown in the attachment.

 !Screen Shot 2018-01-14 at 19.32.10.png|thumbnail! 

This is pretty similar with https://issues.jboss.org/browse/WFLY-3365, not sure if I should have reopened that one o raised this one, sorry if I took the wrong decision.




> ClassLoader leak in org.jboss.el.cache.FactoryFinderCache (Wildfly 11)
> ----------------------------------------------------------------------
>
>                 Key: WFLY-9666
>                 URL: https://issues.jboss.org/browse/WFLY-9666
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 11.0.0.Final
>         Environment: macOS
>            Reporter: Bruno Medeiros
>            Assignee: Stuart Douglas
>            Priority: Critical
>         Attachments: Screen Shot 2018-01-14 at 19.32.10.png
>
>
> I was investigating why my class loader was leaking and after fixing all the problems within my application classes I got the leak shown in the attachment.
>  !Screen Shot 2018-01-14 at 19.32.10.png|thumbnail! 
> This is pretty similar with WFLY-3365, not sure if I should have reopened that one o raised this one, sorry if I took the wrong decision.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 11:13:00 2018
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 15 Jan 2018 11:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9666) ClassLoader leak in
 org.jboss.el.cache.FactoryFinderCache (Wildfly 11)
In-Reply-To: <JIRA.12727948.1515943218000@Atlassian.JIRA>
References: <JIRA.12727948.1515943218000@Atlassian.JIRA>
	<JIRA.12727948.1515943218000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727948.1515943218000.46187.1516032780462@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13517247#comment-13517247 ] 

Tomaz Cerar commented on WFLY-9666:
-----------------------------------

We do have undeploy action to cleanup this https://github.com/wildfly/wildfly/blob/master/ee/src/main/java/org/jboss/as/ee/component/deployers/EECleanUpProcessor.java#L52

But looking at this, it could not cleanup properly in EAR deployments.

[~brunojcm] how does your deployment look like?

> ClassLoader leak in org.jboss.el.cache.FactoryFinderCache (Wildfly 11)
> ----------------------------------------------------------------------
>
>                 Key: WFLY-9666
>                 URL: https://issues.jboss.org/browse/WFLY-9666
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 11.0.0.Final
>         Environment: macOS
>            Reporter: Bruno Medeiros
>            Assignee: Stuart Douglas
>            Priority: Critical
>         Attachments: Screen Shot 2018-01-14 at 19.32.10.png
>
>
> I was investigating why my class loader was leaking and after fixing all the problems within my application classes I got the leak shown in the attachment.
>  !Screen Shot 2018-01-14 at 19.32.10.png|thumbnail! 
> This is pretty similar with WFLY-3365, not sure if I should have reopened that one o raised this one, sorry if I took the wrong decision.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 11:25:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 15 Jan 2018 11:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING
 attempts to delete row too late
In-Reply-To: <JIRA.12685499.1491050677000@Atlassian.JIRA>
References: <JIRA.12685499.1491050677000@Atlassian.JIRA>
	<JIRA.12685499.1491050677000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12685499.1491050677000.46270.1516033500699@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13517258#comment-13517258 ] 

Paul Ferraro commented on WFLY-8488:
------------------------------------

Yes, the data-source attribute is new as of WF11.
e.g.
{code:xml}<jdbc-protocol type="JDBC_PING" data-source="ExampleDS"/>{code}
Prior to WF11, the protocol would need to supply a "datasource_jndi_name" property containing the JNDI name of a database.

> 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.5.0#75005)

From issues at jboss.org  Mon Jan 15 11:25:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 15 Jan 2018 11:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING
 attempts to delete row too late
In-Reply-To: <JIRA.12685499.1491050677000@Atlassian.JIRA>
References: <JIRA.12685499.1491050677000@Atlassian.JIRA>
	<JIRA.12685499.1491050677000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12685499.1491050677000.46277.1516033500871@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13517258#comment-13517258 ] 

Paul Ferraro edited comment on WFLY-8488 at 1/15/18 11:24 AM:
--------------------------------------------------------------

[~meetoblivion] Yes, the data-source attribute is new as of WF11.
e.g.
{code:xml}<jdbc-protocol type="JDBC_PING" data-source="ExampleDS"/>{code}
Prior to WF11, the protocol would need to supply a "datasource_jndi_name" property containing the JNDI name of a database.


was (Author: pferraro):
Yes, the data-source attribute is new as of WF11.
e.g.
{code:xml}<jdbc-protocol type="JDBC_PING" data-source="ExampleDS"/>{code}
Prior to WF11, the protocol would need to supply a "datasource_jndi_name" property containing the JNDI name of a database.

> 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.5.0#75005)

From issues at jboss.org  Mon Jan 15 12:05:01 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 15 Jan 2018 12:05:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3447) CLI SSL security commands.
In-Reply-To: <JIRA.12723502.1512476013000@Atlassian.JIRA>
References: <JIRA.12723502.1512476013000@Atlassian.JIRA>
	<JIRA.12723502.1512476013000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723502.1512476013000.46601.1516035901137@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise updated WFCORE-3447:
-----------------------------------------
    Summary: CLI SSL security commands.  (was: CLI security commands.)


> CLI SSL security commands.
> --------------------------
>
>                 Key: WFCORE-3447
>                 URL: https://issues.jboss.org/browse/WFCORE-3447
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> In order to help configure server side security, a set of CLI commands should be defined to drive users to realise the main use cases:
> - SSL keystore management
> - SSL/HTTPS enablement/disablement
> - SASL/HTTP authentication (based on certificate).
> Analysis docs, work in progress: https://developer.jboss.org/wiki/SSLCommandsForCLI and https://developer.jboss.org/wiki/AuthenticationCommandsForCLI



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 12:07:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 15 Jan 2018 12:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3447) CLI SSL security commands.
In-Reply-To: <JIRA.12723502.1512476013000@Atlassian.JIRA>
References: <JIRA.12723502.1512476013000@Atlassian.JIRA>
	<JIRA.12723502.1512476013000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723502.1512476013000.46610.1516036020571@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3447?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise updated WFCORE-3447:
-----------------------------------------
    Description: 
In order to help configure SSL server side security, a set of CLI commands should be defined to drive users to realise the main use cases:
- enable / disable SSL for management interfaces
- enable / disable SSL for web server.

These commands rely on the new elytron operations to manage key-store.

  was:
In order to help configure server side security, a set of CLI commands should be defined to drive users to realise the main use cases:
- SSL keystore management
- SSL/HTTPS enablement/disablement
- SASL/HTTP authentication (based on certificate).

Analysis docs, work in progress: https://developer.jboss.org/wiki/SSLCommandsForCLI and https://developer.jboss.org/wiki/AuthenticationCommandsForCLI



> CLI SSL security commands.
> --------------------------
>
>                 Key: WFCORE-3447
>                 URL: https://issues.jboss.org/browse/WFCORE-3447
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> In order to help configure SSL server side security, a set of CLI commands should be defined to drive users to realise the main use cases:
> - enable / disable SSL for management interfaces
> - enable / disable SSL for web server.
> These commands rely on the new elytron operations to manage key-store.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 15:53:00 2018
From: issues at jboss.org (Greg Jewell (JIRA))
Date: Mon, 15 Jan 2018 15:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-758) ClassNotFoundException:
	javax.sql.RowSet
In-Reply-To: <JIRA.12574995.1434379769000@Atlassian.JIRA>
References: <JIRA.12574995.1434379769000@Atlassian.JIRA>
	<JIRA.12574995.1434379769000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12574995.1434379769000.47367.1516049580216@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-758?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Greg Jewell closed WFCORE-758.
------------------------------


> ClassNotFoundException: javax.sql.RowSet
> ----------------------------------------
>
>                 Key: WFCORE-758
>                 URL: https://issues.jboss.org/browse/WFCORE-758
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Modules
>         Environment: Windows 7, Java 8u45 (64 bit)
>            Reporter: Greg Jewell
>            Assignee: David Lloyd
>             Fix For: 1.0.0.CR7, 2.0.0.Alpha5
>
>
> I downloaded the WF9 CR2 release this morning and have been testing functionality.  A new exception has appeared with this release.  This did not happen with a source release that was downloaded and built between CR1 and CR2, so was just introduced in the last week or so.
> We have a Flex application that is throwing the following exception as it's being loaded:
> [BlazeDS]javax/sql/RowSet
> {noformat}
> java.lang.NoClassDefFoundError: javax/sql/RowSet
>     at flex.messaging.io.amf.Amf3Output.writeObject(Amf3Output.java:198)
>     at flex.messaging.messages.AbstractMessage.writeExternal(AbstractMessage.java:444)
>     at flex.messaging.messages.AsyncMessage.writeExternal(AsyncMessage.java:140)
>     at flex.messaging.messages.AcknowledgeMessage.writeExternal(AcknowledgeMessage.java:94)
>     at flex.messaging.messages.AcknowledgeMessageExt.writeExternal(AcknowledgeMessageExt.java:55)
>     at flex.messaging.io.amf.Amf3Output.writePropertyProxy(Amf3Output.java:594)
>     at flex.messaging.io.amf.Amf3Output.writeCustomObject(Amf3Output.java:532)
>     at flex.messaging.io.amf.Amf3Output.writeObject(Amf3Output.java:112)
>     at flex.messaging.io.amf.Amf0Output.writeObject(Amf0Output.java:206)
>     at flex.messaging.io.amf.AmfMessageSerializer.writeObject(AmfMessageSerializer.java:196)
>     at flex.messaging.io.amf.AmfMessageSerializer.writeBody(AmfMessageSerializer.java:186)
>     at flex.messaging.io.amf.AmfMessageSerializer.writeMessage(AmfMessageSerializer.java:142)
>     at flex.messaging.endpoints.amf.SerializationFilter.invoke(SerializationFilter.java:198)
>     at flex.messaging.endpoints.BaseHTTPEndpoint.service(BaseHTTPEndpoint.java:291)
>     at flex.messaging.MessageBrokerServlet.service(MessageBrokerServlet.java:353)
>     at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
>     at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:86)
>     at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
>     at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
>     at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>     at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
>     at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>     at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
>     at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
>     at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:58)
>     at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:72)
>     at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
>     at io.undertow.security.handlers.SecurityInitialHandler.handleRequest(SecurityInitialHandler.java:76)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>     at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>     at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
>     at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:274)
>     at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:253)
>     at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:80)
>     at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:172)
>     at io.undertow.server.Connectors.executeRootHandler(Connectors.java:199)
>     at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:774)
>     at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
>     at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>     at java.lang.Thread.run(Unknown Source)
> Caused by: java.lang.ClassNotFoundException: javax.sql.RowSet from [Module "deployment.Test.ear.test.war:main" from Service Module Loader]
>     at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:205)
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:455)
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:404)
>     at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:385)
>     at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:130)
>     ... 43 more
> {noformat}
> - See more at: https://developer.jboss.org/thread/260451#sthash.LJ3DCVsa.dpuf



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 15:59:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 15 Jan 2018 15:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9674) Missing wrapper 'license' tag
 around full-feature-pack-licenses.xml entry for LGPL for
 artemis-wildfly-integration
In-Reply-To: <JIRA.12729112.1516049908000@Atlassian.JIRA>
References: <JIRA.12729112.1516049908000@Atlassian.JIRA>
	<JIRA.12729112.1516049908711@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729112.1516049908000.47380.1516049940068@Atlassian.JIRA>

Brian Stansberry created WFLY-9674:
--------------------------------------

             Summary: Missing wrapper 'license' tag around full-feature-pack-licenses.xml entry for LGPL for artemis-wildfly-integration
                 Key: WFLY-9674
                 URL: https://issues.jboss.org/browse/WFLY-9674
             Project: WildFly
          Issue Type: Bug
          Components: Build System
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor


$subject says it all. The EAP branch doesn't have this issue.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 20:29:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 15 Jan 2018 20:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFBUILD-32) Add support for hard coded
 artifact versions in module.xml
In-Reply-To: <JIRA.12729133.1516066137000@Atlassian.JIRA>
References: <JIRA.12729133.1516066137000@Atlassian.JIRA>
	<JIRA.12729133.1516066137606@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729133.1516066137000.47777.1516066140105@Atlassian.JIRA>

Stuart Douglas created WFBUILD-32:
-------------------------------------

             Summary: Add support for hard coded artifact versions in module.xml
                 Key: WFBUILD-32
                 URL: https://issues.jboss.org/browse/WFBUILD-32
             Project: WildFly Build Tools
          Issue Type: Feature Request
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 20:38:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 15 Jan 2018 20:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFBUILD-32) Add support for hard coded
 artifact versions in module.xml
In-Reply-To: <JIRA.12729133.1516066138000@Atlassian.JIRA>
References: <JIRA.12729133.1516066138000@Atlassian.JIRA>
	<JIRA.12729133.1516066138000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729133.1516066138000.47779.1516066680200@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFBUILD-32?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas resolved WFBUILD-32.
-----------------------------------
    Fix Version/s: 1.2.6.Final
       Resolution: Done


> Add support for hard coded artifact versions in module.xml
> ----------------------------------------------------------
>
>                 Key: WFBUILD-32
>                 URL: https://issues.jboss.org/browse/WFBUILD-32
>             Project: WildFly Build Tools
>          Issue Type: Feature Request
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>             Fix For: 1.2.6.Final
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 21:11:00 2018
From: issues at jboss.org (Chao Wang (JIRA))
Date: Mon, 15 Jan 2018 21:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9675) cannot disable
 'max-post-size' check for undertow listeners
In-Reply-To: <JIRA.12729135.1516068597000@Atlassian.JIRA>
References: <JIRA.12729135.1516068597000@Atlassian.JIRA>
	<JIRA.12729135.1516068597000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729135.1516068597000.47795.1516068660190@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang moved JBEAP-14096 to WFLY-9675:
-----------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-9675  (was: JBEAP-14096)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Web (Undertow)
                           (was: Web (Undertow))
    Affects Version/s: 11.0.0.Final
                           (was: 7.1.0.GA)


> cannot disable 'max-post-size' check for undertow listeners
> -----------------------------------------------------------
>
>                 Key: WFLY-9675
>                 URL: https://issues.jboss.org/browse/WFLY-9675
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 11.0.0.Final
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>
> With EAP7.1.0.GA, there has been added a validator for 'max-post-size' attribute for listeners in undertow subsystem. This validator requires positive integer values starting with value 1. That means, you cannot disable 'max-post-size' for such listener using 0 value anymore.
> In EAP6.4 and EAP7.0, it was possible to disable 'max-post-size' check with 0 value. I understand that we might not want to allow user to set this to 0 value as it might be a potentional security risk. Still, maybe we should relax this restriction as it was possible to configure it that way in previous versions of EAP.
> Also there is a [Knowledge Base article|https://access.redhat.com/solutions/714173] regarding to this feature, which we should update in case we won't reconsider our position.
> Just for the record - quoting question from mailing list:
> {quote}
> Dear Experts,
> Based on KCS, the "max-post-size" in "http-listener" from "undertow" subsystem can be disabled by setting "0" to it, it worked for EAP 6.x and 7.0 GA.
> But in EAP 7.1.0 GA, it didn't work:
> ~~~
> [standalone at localhost:9990 /] /subsystem=undertow/server=default-server/http-listener=default/:write-attribute(name=max-post-size,value=0)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0117: 0 is an invalid value for parameter max-post-size. A minimum value of 1 is required",
>     "rolled-back" => true
> }
> ~~~
> By comparing schemas:
> ~~~
> jboss-eap-7.0/docs/schema/wildfly-undertow_x_x.xsd:
> <xs:attribute name="max-post-size" type="xs:long" default="0"/>
> ---
> jboss-eap-7.1/docs/schema/wildfly-undertow_x_x.xsd:
> <xs:attribute name="max-post-size" type="xs:long" default="10485760"/>
> ~~~
> The behaviour changed.
> And I found WFLY-6437 and JBEAP-3974, but failed to open links inside those.
> So can I ask if "max-post-size" can be disabled in EAP 7.1.0 GA and the reason if possible?
> Best Regards,
> Zhang Xu
> {quote}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 21:14:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 15 Jan 2018 21:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9676) Build tools 1.2.6.Final
In-Reply-To: <JIRA.12729136.1516068806000@Atlassian.JIRA>
References: <JIRA.12729136.1516068806000@Atlassian.JIRA>
	<JIRA.12729136.1516068806799@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729136.1516068806000.47798.1516068840258@Atlassian.JIRA>

Stuart Douglas created WFLY-9676:
------------------------------------

             Summary: Build tools 1.2.6.Final
                 Key: WFLY-9676
                 URL: https://issues.jboss.org/browse/WFLY-9676
             Project: WildFly
          Issue Type: Component Upgrade
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 21:14:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 15 Jan 2018 21:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9677) Build tools 1.2.6.Final
In-Reply-To: <JIRA.12729138.1516068816000@Atlassian.JIRA>
References: <JIRA.12729138.1516068816000@Atlassian.JIRA>
	<JIRA.12729138.1516068816991@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729138.1516068816000.47805.1516068840637@Atlassian.JIRA>

Stuart Douglas created WFLY-9677:
------------------------------------

             Summary: Build tools 1.2.6.Final
                 Key: WFLY-9677
                 URL: https://issues.jboss.org/browse/WFLY-9677
             Project: WildFly
          Issue Type: Component Upgrade
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 21:14:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 15 Jan 2018 21:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3510) Build tools 1.2.6.Final
In-Reply-To: <JIRA.12729138.1516068817000@Atlassian.JIRA>
References: <JIRA.12729138.1516068817000@Atlassian.JIRA>
	<JIRA.12729138.1516068817000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729138.1516068817000.47808.1516068840764@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3510?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved WFLY-9677 to WFCORE-3510:
----------------------------------------------

    Project: WildFly Core  (was: WildFly)
        Key: WFCORE-3510  (was: WFLY-9677)


> Build tools 1.2.6.Final
> -----------------------
>
>                 Key: WFCORE-3510
>                 URL: https://issues.jboss.org/browse/WFCORE-3510
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 15 21:30:00 2018
From: issues at jboss.org (Cheng Fang (JIRA))
Date: Mon, 15 Jan 2018 21:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9610) Start of a BatchJob is called,
 but BatchJob is seems no started. Absent entries in DB tables step_execution,
 job_execution
In-Reply-To: <JIRA.12724395.1513071287000@Atlassian.JIRA>
References: <JIRA.12724395.1513071287000@Atlassian.JIRA>
	<JIRA.12724395.1513071287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724395.1513071287000.47842.1516069800269@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9610?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Cheng Fang resolved WFLY-9610.
------------------------------
    Resolution: Explained


> Start of a BatchJob is called, but BatchJob is seems no started. Absent entries in DB tables step_execution, job_execution
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9610
>                 URL: https://issues.jboss.org/browse/WFLY-9610
>             Project: WildFly
>          Issue Type: Bug
>          Components: Batch
>    Affects Versions: 9.0.1.Final
>         Environment: Cluster, standalone-full-ha
>            Reporter: Serg Pol
>            Assignee: Cheng Fang
>
> Start of a BatchJob is called and record/entry is absent sometimes in DB table "step_execution" as well as Endtime and Exitstatus in the table job_execution (there is just info about start of BatchJob). 
> There are no any error nessages.
> BatchJob is not started in this case according Log. 
> Any idea? Thanks



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 00:29:00 2018
From: issues at jboss.org (Chao Wang (JIRA))
Date: Tue, 16 Jan 2018 00:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9675) cannot disable
 'max-post-size' check for undertow listeners
In-Reply-To: <JIRA.12729135.1516068597000@Atlassian.JIRA>
References: <JIRA.12729135.1516068597000@Atlassian.JIRA>
	<JIRA.12729135.1516068597000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729135.1516068597000.47968.1516080540104@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang updated WFLY-9675:
----------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/10756


> cannot disable 'max-post-size' check for undertow listeners
> -----------------------------------------------------------
>
>                 Key: WFLY-9675
>                 URL: https://issues.jboss.org/browse/WFLY-9675
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 11.0.0.Final
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>
> With EAP7.1.0.GA, there has been added a validator for 'max-post-size' attribute for listeners in undertow subsystem. This validator requires positive integer values starting with value 1. That means, you cannot disable 'max-post-size' for such listener using 0 value anymore.
> In EAP6.4 and EAP7.0, it was possible to disable 'max-post-size' check with 0 value. I understand that we might not want to allow user to set this to 0 value as it might be a potentional security risk. Still, maybe we should relax this restriction as it was possible to configure it that way in previous versions of EAP.
> Also there is a [Knowledge Base article|https://access.redhat.com/solutions/714173] regarding to this feature, which we should update in case we won't reconsider our position.
> Just for the record - quoting question from mailing list:
> {quote}
> Dear Experts,
> Based on KCS, the "max-post-size" in "http-listener" from "undertow" subsystem can be disabled by setting "0" to it, it worked for EAP 6.x and 7.0 GA.
> But in EAP 7.1.0 GA, it didn't work:
> ~~~
> [standalone at localhost:9990 /] /subsystem=undertow/server=default-server/http-listener=default/:write-attribute(name=max-post-size,value=0)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0117: 0 is an invalid value for parameter max-post-size. A minimum value of 1 is required",
>     "rolled-back" => true
> }
> ~~~
> By comparing schemas:
> ~~~
> jboss-eap-7.0/docs/schema/wildfly-undertow_x_x.xsd:
> <xs:attribute name="max-post-size" type="xs:long" default="0"/>
> ---
> jboss-eap-7.1/docs/schema/wildfly-undertow_x_x.xsd:
> <xs:attribute name="max-post-size" type="xs:long" default="10485760"/>
> ~~~
> The behaviour changed.
> And I found WFLY-6437 and JBEAP-3974, but failed to open links inside those.
> So can I ask if "max-post-size" can be disabled in EAP 7.1.0 GA and the reason if possible?
> Best Regards,
> Zhang Xu
> {quote}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 01:27:00 2018
From: issues at jboss.org (Maxim Karavaev (JIRA))
Date: Tue, 16 Jan 2018 01:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8913) It is not possible to add
 cache store in infinispan subsystem
In-Reply-To: <JIRA.12696535.1496948075000@Atlassian.JIRA>
References: <JIRA.12696535.1496948075000@Atlassian.JIRA>
	<JIRA.12696535.1496948075000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696535.1496948075000.48006.1516084020237@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13517423#comment-13517423 ] 

Maxim Karavaev commented on WFLY-8913:
--------------------------------------

I am confused. I'm just download the last version *WildFly Full 11.0.0.Final (WildFly Core 3.0.8.Final)* and got this error:
{noformat}
[standalone at localhost:9990 /] /subsystem=infinispan/cache-container=hibernate/local-cache=foobar1:add()
{"outcome" => "success"}
[standalone at localhost:9990 /] /subsystem=infinispan/cache-container=hibernate/local-cache=foobar1/store=STORE:add(class="org.infinispan.configuration.cache.SingleFileStoreConfigurationBuilder")
{
    "outcome" => "failed",
    "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache.store.hibernate.foobar1 is already registered",
    "rolled-back" => true
}
{noformat}

Does it fixed or not? And in which version?

> It is not possible to add cache store in infinispan subsystem
> -------------------------------------------------------------
>
>                 Key: WFLY-8913
>                 URL: https://issues.jboss.org/browse/WFLY-8913
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Beta1
>
>
> Adding cache store to already created cache ends by failure even if it should succeed:
> {code}
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-container=hibernate/invalidation-cache=foobar/store=STORE:add(class="org.infinispan.configuration.cache.SingleFileStoreConfigurationBuilder")
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache.store.hibernate.foobar is already registered",
>     "rolled-back" => true
> }
> {code}
> This is a regression against 7.1.0.DR18.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 04:02:00 2018
From: issues at jboss.org (=?UTF-8?Q?Luk=C3=A1=C5=A1_Petrovick=C3=BD_=28JIRA=29?=)
Date: Tue, 16 Jan 2018 04:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2244) DMN:
 time(date("2017-08-10")) should return 00:00:00z time
In-Reply-To: <JIRA.12729186.1516093293000@Atlassian.JIRA>
References: <JIRA.12729186.1516093293000@Atlassian.JIRA>
	<JIRA.12729186.1516093293531@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729186.1516093293000.49203.1516093320706@Atlassian.JIRA>

Luk?? Petrovick? created DROOLS-2244:
----------------------------------------

             Summary: DMN: time(date("2017-08-10")) should return 00:00:00z time
                 Key: DROOLS-2244
                 URL: https://issues.jboss.org/browse/DROOLS-2244
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
    Affects Versions: 7.5.0.Final
            Reporter: Luk?? Petrovick?
            Assignee: Tibor Zim?nyi


According to the specification in section "10.3.2.3.5 date": 
"Where necessary, including the valuedt function (see 10.3.2.x.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00)."

Currently the case time(date("2017-08-10")) returns null, because the evaluation ends with DateTimeException, because internally we represent dates as LocalDate class, which doesn't have time part. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan 16 04:19:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 16 Jan 2018 04:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2155) table editor should use
 full canvas area available
In-Reply-To: <JIRA.12722667.1511895299000@Atlassian.JIRA>
References: <JIRA.12722667.1511895299000@Atlassian.JIRA>
	<JIRA.12722667.1511895299000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722667.1511895299000.49346.1516094340139@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2155:
--------------------------------
    QE Status: ON_QA  (was: NEW)


> table editor should use full canvas area available
> --------------------------------------------------
>
>                 Key: DROOLS-2155
>                 URL: https://issues.jboss.org/browse/DROOLS-2155
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Michael Anstis
>            Priority: Minor
>              Labels: UX
>
> DMN table editor should use the full canvas width that is available (minus panels, toolbars, etc.) It should not appear as a smaller fixed size area, with scrollbars, within the canvas. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 04:26:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 16 Jan 2018 04:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2155) Table editor should use
 full canvas area available
In-Reply-To: <JIRA.12722667.1511895299000@Atlassian.JIRA>
References: <JIRA.12722667.1511895299000@Atlassian.JIRA>
	<JIRA.12722667.1511895299000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722667.1511895299000.49467.1516094760667@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2155?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2155:
--------------------------------
    Summary: Table editor should use full canvas area available  (was: table editor should use full canvas area available)


> Table editor should use full canvas area available
> --------------------------------------------------
>
>                 Key: DROOLS-2155
>                 URL: https://issues.jboss.org/browse/DROOLS-2155
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Michael Anstis
>            Priority: Minor
>              Labels: UX
>
> DMN table editor should use the full canvas width that is available (minus panels, toolbars, etc.) It should not appear as a smaller fixed size area, with scrollbars, within the canvas. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 04:32:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 16 Jan 2018 04:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2245) [Guided Rule] From
 Accumulate using a List Field of a Data Object
In-Reply-To: <JIRA.12729198.1516095093000@Atlassian.JIRA>
References: <JIRA.12729198.1516095093000@Atlassian.JIRA>
	<JIRA.12729198.1516095093789@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729198.1516095093000.49560.1516095120157@Atlassian.JIRA>

Jozef Marko created DROOLS-2245:
-----------------------------------

             Summary: [Guided Rule] From Accumulate using a List Field of a Data Object
                 Key: DROOLS-2245
                 URL: https://issues.jboss.org/browse/DROOLS-2245
             Project: Drools
          Issue Type: Bug
          Components: Guided Decision Table Editor, Guided Rule Editor
    Affects Versions: 7.5.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis
         Attachments: Screenshot from 2017-11-08 10-23-50.png, Screenshot from 2017-11-08 10-31-41.png, Screenshot from 2017-11-08 10-31-58.png

There is problem if From Accumulate expression iterates over List field of a Data Object.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 04:33:01 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 16 Jan 2018 04:33:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2109) [XLS Decision Table] New
 Asset Dialogue misses descriptions
In-Reply-To: <JIRA.12719362.1509700869000@Atlassian.JIRA>
References: <JIRA.12719362.1509700869000@Atlassian.JIRA>
	<JIRA.12719362.1509700869000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719362.1509700869000.49596.1516095181604@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2109:
--------------------------------
    Priority: Optional  (was: Major)


> [XLS Decision Table] New Asset Dialogue misses descriptions
> -----------------------------------------------------------
>
>                 Key: DROOLS-2109
>                 URL: https://issues.jboss.org/browse/DROOLS-2109
>             Project: Drools
>          Issue Type: Bug
>          Components: XLS Decision Table Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>            Priority: Optional
>         Attachments: Screenshot from 2017-11-03 10-20-21.png
>
>
> The attached dialogue shows missing descriptions for table format and file selector.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 04:38:01 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 16 Jan 2018 04:38:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2246) [XLS Decision Table] New
 Asset Dialogue misses descriptions
In-Reply-To: <JIRA.12729204.1516095437000@Atlassian.JIRA>
References: <JIRA.12729204.1516095437000@Atlassian.JIRA>
	<JIRA.12729204.1516095437676@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729204.1516095437000.49661.1516095481836@Atlassian.JIRA>

Jozef Marko created DROOLS-2246:
-----------------------------------

             Summary: [XLS Decision Table] New Asset Dialogue misses descriptions
                 Key: DROOLS-2246
                 URL: https://issues.jboss.org/browse/DROOLS-2246
             Project: Drools
          Issue Type: Bug
          Components: XLS Decision Table Editor
    Affects Versions: 7.5.0.Final
            Reporter: Jozef Marko
            Assignee: Jozef Marko
            Priority: Optional
         Attachments: Screenshot from 2017-11-03 10-20-21.png

The attached dialogue shows missing descriptions for table format and file selector.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 04:39:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 16 Jan 2018 04:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2247) [Guided Decision Table] DSL
 can not contain $ in the definition
In-Reply-To: <JIRA.12729205.1516095534000@Atlassian.JIRA>
References: <JIRA.12729205.1516095534000@Atlassian.JIRA>
	<JIRA.12729205.1516095534496@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729205.1516095534000.49698.1516095540603@Atlassian.JIRA>

Jozef Marko created DROOLS-2247:
-----------------------------------

             Summary: [Guided Decision Table] DSL can not contain $ in the definition
                 Key: DROOLS-2247
                 URL: https://issues.jboss.org/browse/DROOLS-2247
             Project: Drools
          Issue Type: Bug
          Components: Guided Decision Table Editor
    Affects Versions: 7.5.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis
             Fix For: 7.6.0.Final


The DSL sentences are defined like:
- [when] *definition* = real rule

If the *definition* contains *$* character, then the DSL sentence can not be used properly in the guided decision table.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 06:40:00 2018
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Tue, 16 Jan 2018 06:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9072) @RunAs role authorization
 from the first invoker of @Singleton bean is propagated through the
 @PostConstruct method of @Singleton bean with Elytron
In-Reply-To: <JIRA.12701478.1499782344000@Atlassian.JIRA>
References: <JIRA.12701478.1499782344000@Atlassian.JIRA>
	<JIRA.12701478.1499782344000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12701478.1499782344000.50740.1516102800727@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski reassigned WFLY-9072:
----------------------------------------

    Assignee: Bartosz Baranowski  (was: David Lloyd)


> @RunAs role authorization from the first invoker of @Singleton bean is propagated through the @PostConstruct method of @Singleton bean with Elytron
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9072
>                 URL: https://issues.jboss.org/browse/WFLY-9072
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>            Reporter: Michal Jurc
>            Assignee: Bartosz Baranowski
>            Priority: Critical
>
> Suppose an environment with a chain of three bean invocations:
> {code:java|title=Bean1.java}
> @Stateless
> @Remote(WhoAmI.class)
> @RunAs("Admin")
> @SecurityDomain("other")
> public class Bean1 implements WhoAmI {
>     @EJB(beanName = "Bean2")
>     private WhoAmI singleton;
>     public String getCallerPrincipal() {
>         return singleton.getCallerPrincipal();
>     }
> }{code}
> {code:java|title=Bean2.java}@Singleton
> @Remote(WhoAmI.class)
> @SecurityDomain("other")
> public class Bean2 implements WhoAmI {
>     @EJB(beanName = "Bean3")
>     private WhoAmI bean3;
>     private String principal;
>     @PostConstruct
>     public void init() {
>         principal = bean3.getCallerPrincipal();
>     }
>     public String getCallerPrincipal() {
>         return principal;
>     }
> }
> {code}
> {code:java|title=Bean3.java}@Stateless
> @Local(WhoAmI.class)
> @RolesAllowed("Admin")
> @SecurityDomain("other")
> public class Bean3 implements WhoAmI {
>     @Resource
>     private SessionContext ctx;
>     public String getCallerPrincipal() {
>         return ctx.getCallerPrincipal().getName();
>     }
> }{code}
> The {{@RunAs("Admin")}} is propagated from {{Bean1}} through {{Bean2.init()}} to {{Bean3}} with Elytron. The EJB3.1 specification does not specify security context of {{@PostConstruct}} method for {{@Singleton}} beans, however with this approach the {{@RunAs}} authorization of initialization of any {{@Singleton}} bean will be determined by its first invoker with Elytron. With legacy security, the {{@RunAs}} authorization of {{@PostConstruct}} method for {{@Singleton}} beans was undefined.
> This is covered by {{org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testSingletonPostconstructSecurityNotPropagating}} in WildFly Integration/Basic Test Suite module.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 06:41:00 2018
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Tue, 16 Jan 2018 06:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9072) @RunAs role authorization
 from the first invoker of @Singleton bean is propagated through the
 @PostConstruct method of @Singleton bean with Elytron
In-Reply-To: <JIRA.12701478.1499782344000@Atlassian.JIRA>
References: <JIRA.12701478.1499782344000@Atlassian.JIRA>
	<JIRA.12701478.1499782344000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12701478.1499782344000.50754.1516102860862@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9072?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski resolved WFLY-9072.
--------------------------------------
    Resolution: Out of Date


Fixes it seems, same indication has been made bu reporter in downstream. Mentioned test case run and pass.

> @RunAs role authorization from the first invoker of @Singleton bean is propagated through the @PostConstruct method of @Singleton bean with Elytron
> ---------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9072
>                 URL: https://issues.jboss.org/browse/WFLY-9072
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security
>            Reporter: Michal Jurc
>            Assignee: Bartosz Baranowski
>            Priority: Critical
>
> Suppose an environment with a chain of three bean invocations:
> {code:java|title=Bean1.java}
> @Stateless
> @Remote(WhoAmI.class)
> @RunAs("Admin")
> @SecurityDomain("other")
> public class Bean1 implements WhoAmI {
>     @EJB(beanName = "Bean2")
>     private WhoAmI singleton;
>     public String getCallerPrincipal() {
>         return singleton.getCallerPrincipal();
>     }
> }{code}
> {code:java|title=Bean2.java}@Singleton
> @Remote(WhoAmI.class)
> @SecurityDomain("other")
> public class Bean2 implements WhoAmI {
>     @EJB(beanName = "Bean3")
>     private WhoAmI bean3;
>     private String principal;
>     @PostConstruct
>     public void init() {
>         principal = bean3.getCallerPrincipal();
>     }
>     public String getCallerPrincipal() {
>         return principal;
>     }
> }
> {code}
> {code:java|title=Bean3.java}@Stateless
> @Local(WhoAmI.class)
> @RolesAllowed("Admin")
> @SecurityDomain("other")
> public class Bean3 implements WhoAmI {
>     @Resource
>     private SessionContext ctx;
>     public String getCallerPrincipal() {
>         return ctx.getCallerPrincipal().getName();
>     }
> }{code}
> The {{@RunAs("Admin")}} is propagated from {{Bean1}} through {{Bean2.init()}} to {{Bean3}} with Elytron. The EJB3.1 specification does not specify security context of {{@PostConstruct}} method for {{@Singleton}} beans, however with this approach the {{@RunAs}} authorization of initialization of any {{@Singleton}} bean will be determined by its first invoker with Elytron. With legacy security, the {{@RunAs}} authorization of {{@PostConstruct}} method for {{@Singleton}} beans was undefined.
> This is covered by {{org.jboss.as.test.integration.ejb.security.RunAsPrincipalTestCase#testSingletonPostconstructSecurityNotPropagating}} in WildFly Integration/Basic Test Suite module.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 07:03:05 2018
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Tue, 16 Jan 2018 07:03:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3527) Improper noargs constructor
 assumption leads to NullPointerException
In-Reply-To: <JIRA.12544487.1403258659000@Atlassian.JIRA>
References: <JIRA.12544487.1403258659000@Atlassian.JIRA>
	<JIRA.12544487.1403258659000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544487.1403258659000.50976.1516104185591@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski reassigned WFLY-3527:
----------------------------------------

    Assignee: Bartosz Baranowski  (was: David Lloyd)


> Improper noargs constructor assumption leads to NullPointerException
> --------------------------------------------------------------------
>
>                 Key: WFLY-3527
>                 URL: https://issues.jboss.org/browse/WFLY-3527
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Final
>            Reporter: Randahl Fink Isaksen
>            Assignee: Bartosz Baranowski
>            Priority: Critical
>
> As shown in the stack trace below, I have received a NullPointerException from Wildfly. Looking at the Wildfly code, it seems to me that the class org.jboss.marshalling.reflect.SerializableClass improperly requires serializable classes to have a noargs constructor.
> The NullPointerException occurs in line 514:
> {code}
> 514: return constructor.newInstance(args);
> {code}
> so the reason for the NullPointerException is that the parameter constructor is null.
> Now, if you look at line 488, you see that the constructor parameter stems from the method invokation
> {code}
> 488: return invokeConstructorNoException(nonInitConstructor);
> {code}
> so the question is: When is nonInitConstructor defined, and why is it null?
> The answer can be found in line 160
> {code}
> 160: nonInitConstructor = lookupNonInitConstructor(subject);
> {code}
> and that method starts in line 550
> {code}
> 550 private static <T> Constructor<T> More ...lookupNonInitConstructor(final 
> ?
> 555            topConstructor = current.getDeclaredConstructor();
> 556        } catch (NoSuchMethodException e) {
> 557            return null;
> 558        }
> ?
> 563    }
> {code}
> As you can see here, the method getDeclaredConstructor is invoked with no args, so Wildfly expects to find a noargs constructor. If non such constructor exists the NoSuchMethodException is thrown, caught, and null is returned.
> All in all I conclude, that creating a perfectly valid, serializable class with no noargs constructor makes Wildfly crash, and I believe this is a serious bug.
> CLASS WHICH MAKES WILDFLY FAIL
> {code}
> public enum Validity {
> 	VALID(true),
> 	QUESTIONABLE(true),
> 	INVALID(false);
> 	private boolean valid;
> 	
> 	private Validity(boolean valid) {
> 		this.valid = valid;
> 	}
> 	
> 	public boolean isValid() {
> 		return valid;
> 	}
> }
> {code}
> Note: Any enum is also Serializable
> STACK TRACE
> {noformat}
> java.lang.reflect.InvocationTargetException
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:483)
> 	at com.intuism.ui.validation.validator.ValidationTask.call(ValidationTask.java:49)
> 	at com.intuism.ui.validation.validator.ValidationTask.call(ValidationTask.java:23)
> 	at javafx.concurrent.Task$TaskCallable.call(Task.java:1426)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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:744)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.marshalling.reflect.SerializableClass.invokeConstructorNoException(SerializableClass.java:514)
> 	at org.jboss.marshalling.reflect.SerializableClass.callNonInitConstructor(SerializableClass.java:488)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1270)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1715)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1631)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1273)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> 	at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:45)
> 	at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:103)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:202)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> 	at com.sun.proxy.$Proxy4.validateVerificationCode(Unknown Source)
> 	... 13 more
> Caused by: an exception which occurred:
> 	in object of type com.intuism.core.settings.EmbeddedSettings
> 	in field defaultSettings
> 	in object of type com.intuism.ui.validation.Validation
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan 16 07:12:00 2018
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Tue, 16 Jan 2018 07:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3527) Improper noargs constructor
 assumption leads to NullPointerException
In-Reply-To: <JIRA.12544487.1403258659000@Atlassian.JIRA>
References: <JIRA.12544487.1403258659000@Atlassian.JIRA>
	<JIRA.12544487.1403258659000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544487.1403258659000.51056.1516104720731@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski updated WFLY-3527:
-------------------------------------
    Fix Version/s: 11.0.0.Final


> Improper noargs constructor assumption leads to NullPointerException
> --------------------------------------------------------------------
>
>                 Key: WFLY-3527
>                 URL: https://issues.jboss.org/browse/WFLY-3527
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Final
>            Reporter: Randahl Fink Isaksen
>            Assignee: Bartosz Baranowski
>            Priority: Critical
>             Fix For: 11.0.0.Final
>
>
> As shown in the stack trace below, I have received a NullPointerException from Wildfly. Looking at the Wildfly code, it seems to me that the class org.jboss.marshalling.reflect.SerializableClass improperly requires serializable classes to have a noargs constructor.
> The NullPointerException occurs in line 514:
> {code}
> 514: return constructor.newInstance(args);
> {code}
> so the reason for the NullPointerException is that the parameter constructor is null.
> Now, if you look at line 488, you see that the constructor parameter stems from the method invokation
> {code}
> 488: return invokeConstructorNoException(nonInitConstructor);
> {code}
> so the question is: When is nonInitConstructor defined, and why is it null?
> The answer can be found in line 160
> {code}
> 160: nonInitConstructor = lookupNonInitConstructor(subject);
> {code}
> and that method starts in line 550
> {code}
> 550 private static <T> Constructor<T> More ...lookupNonInitConstructor(final 
> ?
> 555            topConstructor = current.getDeclaredConstructor();
> 556        } catch (NoSuchMethodException e) {
> 557            return null;
> 558        }
> ?
> 563    }
> {code}
> As you can see here, the method getDeclaredConstructor is invoked with no args, so Wildfly expects to find a noargs constructor. If non such constructor exists the NoSuchMethodException is thrown, caught, and null is returned.
> All in all I conclude, that creating a perfectly valid, serializable class with no noargs constructor makes Wildfly crash, and I believe this is a serious bug.
> CLASS WHICH MAKES WILDFLY FAIL
> {code}
> public enum Validity {
> 	VALID(true),
> 	QUESTIONABLE(true),
> 	INVALID(false);
> 	private boolean valid;
> 	
> 	private Validity(boolean valid) {
> 		this.valid = valid;
> 	}
> 	
> 	public boolean isValid() {
> 		return valid;
> 	}
> }
> {code}
> Note: Any enum is also Serializable
> STACK TRACE
> {noformat}
> java.lang.reflect.InvocationTargetException
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:483)
> 	at com.intuism.ui.validation.validator.ValidationTask.call(ValidationTask.java:49)
> 	at com.intuism.ui.validation.validator.ValidationTask.call(ValidationTask.java:23)
> 	at javafx.concurrent.Task$TaskCallable.call(Task.java:1426)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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:744)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.marshalling.reflect.SerializableClass.invokeConstructorNoException(SerializableClass.java:514)
> 	at org.jboss.marshalling.reflect.SerializableClass.callNonInitConstructor(SerializableClass.java:488)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1270)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1715)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1631)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1273)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> 	at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:45)
> 	at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:103)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:202)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> 	at com.sun.proxy.$Proxy4.validateVerificationCode(Unknown Source)
> 	... 13 more
> Caused by: an exception which occurred:
> 	in object of type com.intuism.core.settings.EmbeddedSettings
> 	in field defaultSettings
> 	in object of type com.intuism.ui.validation.Validation
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan 16 07:14:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 16 Jan 2018 07:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9678) Expand clustering test cases
 to 3-node cluster
In-Reply-To: <JIRA.12729233.1516104791000@Atlassian.JIRA>
References: <JIRA.12729233.1516104791000@Atlassian.JIRA>
	<JIRA.12729233.1516104791324@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729233.1516104791000.51065.1516104840388@Atlassian.JIRA>

Radoslav Husar created WFLY-9678:
------------------------------------

             Summary: Expand clustering test cases to 3-node cluster
                 Key: WFLY-9678
                 URL: https://issues.jboss.org/browse/WFLY-9678
             Project: WildFly
          Issue Type: Task
          Components: Clustering
    Affects Versions: 11.0.0.Final
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 07:14:00 2018
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Tue, 16 Jan 2018 07:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3527) Improper noargs constructor
 assumption leads to NullPointerException
In-Reply-To: <JIRA.12544487.1403258659000@Atlassian.JIRA>
References: <JIRA.12544487.1403258659000@Atlassian.JIRA>
	<JIRA.12544487.1403258659000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544487.1403258659000.51072.1516104840595@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski resolved WFLY-3527.
--------------------------------------
    Resolution: Done


Marshaling fix: https://github.com/jboss-remoting/jboss-marshalling/commit/243f70f5728d8a6e84a1f50a570cbd011de589a1 
Since: 2.0.0.Beta4
Present: 2.0.2.Final
Comes in WFCORE 3.0.8.Final


> Improper noargs constructor assumption leads to NullPointerException
> --------------------------------------------------------------------
>
>                 Key: WFLY-3527
>                 URL: https://issues.jboss.org/browse/WFLY-3527
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 8.0.0.Final
>            Reporter: Randahl Fink Isaksen
>            Assignee: Bartosz Baranowski
>            Priority: Critical
>             Fix For: 11.0.0.Final
>
>
> As shown in the stack trace below, I have received a NullPointerException from Wildfly. Looking at the Wildfly code, it seems to me that the class org.jboss.marshalling.reflect.SerializableClass improperly requires serializable classes to have a noargs constructor.
> The NullPointerException occurs in line 514:
> {code}
> 514: return constructor.newInstance(args);
> {code}
> so the reason for the NullPointerException is that the parameter constructor is null.
> Now, if you look at line 488, you see that the constructor parameter stems from the method invokation
> {code}
> 488: return invokeConstructorNoException(nonInitConstructor);
> {code}
> so the question is: When is nonInitConstructor defined, and why is it null?
> The answer can be found in line 160
> {code}
> 160: nonInitConstructor = lookupNonInitConstructor(subject);
> {code}
> and that method starts in line 550
> {code}
> 550 private static <T> Constructor<T> More ...lookupNonInitConstructor(final 
> ?
> 555            topConstructor = current.getDeclaredConstructor();
> 556        } catch (NoSuchMethodException e) {
> 557            return null;
> 558        }
> ?
> 563    }
> {code}
> As you can see here, the method getDeclaredConstructor is invoked with no args, so Wildfly expects to find a noargs constructor. If non such constructor exists the NoSuchMethodException is thrown, caught, and null is returned.
> All in all I conclude, that creating a perfectly valid, serializable class with no noargs constructor makes Wildfly crash, and I believe this is a serious bug.
> CLASS WHICH MAKES WILDFLY FAIL
> {code}
> public enum Validity {
> 	VALID(true),
> 	QUESTIONABLE(true),
> 	INVALID(false);
> 	private boolean valid;
> 	
> 	private Validity(boolean valid) {
> 		this.valid = valid;
> 	}
> 	
> 	public boolean isValid() {
> 		return valid;
> 	}
> }
> {code}
> Note: Any enum is also Serializable
> STACK TRACE
> {noformat}
> java.lang.reflect.InvocationTargetException
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:483)
> 	at com.intuism.ui.validation.validator.ValidationTask.call(ValidationTask.java:49)
> 	at com.intuism.ui.validation.validator.ValidationTask.call(ValidationTask.java:23)
> 	at javafx.concurrent.Task$TaskCallable.call(Task.java:1426)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	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:744)
> Caused by: java.lang.NullPointerException
> 	at org.jboss.marshalling.reflect.SerializableClass.invokeConstructorNoException(SerializableClass.java:514)
> 	at org.jboss.marshalling.reflect.SerializableClass.callNonInitConstructor(SerializableClass.java:488)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1270)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.readFields(RiverUnmarshaller.java:1715)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doInitSerializable(RiverUnmarshaller.java:1631)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadNewObject(RiverUnmarshaller.java:1273)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:276)
> 	at org.jboss.marshalling.river.RiverUnmarshaller.doReadObject(RiverUnmarshaller.java:213)
> 	at org.jboss.marshalling.AbstractObjectInput.readObject(AbstractObjectInput.java:45)
> 	at org.jboss.ejb.client.remoting.MethodInvocationResponseHandler$MethodInvocationResultProducer.getResult(MethodInvocationResponseHandler.java:103)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:272)
> 	at org.jboss.ejb.client.EJBObjectInterceptor.handleInvocationResult(EJBObjectInterceptor.java:64)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> 	at org.jboss.ejb.client.EJBHomeInterceptor.handleInvocationResult(EJBHomeInterceptor.java:88)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> 	at org.jboss.ejb.client.TransactionInterceptor.handleInvocationResult(TransactionInterceptor.java:46)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:274)
> 	at org.jboss.ejb.client.ReceiverInterceptor.handleInvocationResult(ReceiverInterceptor.java:129)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.getResult(EJBClientInvocationContext.java:262)
> 	at org.jboss.ejb.client.EJBClientInvocationContext.awaitResponse(EJBClientInvocationContext.java:437)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:202)
> 	at org.jboss.ejb.client.EJBInvocationHandler.doInvoke(EJBInvocationHandler.java:181)
> 	at org.jboss.ejb.client.EJBInvocationHandler.invoke(EJBInvocationHandler.java:144)
> 	at com.sun.proxy.$Proxy4.validateVerificationCode(Unknown Source)
> 	... 13 more
> Caused by: an exception which occurred:
> 	in object of type com.intuism.core.settings.EmbeddedSettings
> 	in field defaultSettings
> 	in object of type com.intuism.ui.validation.Validation
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan 16 07:15:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 16 Jan 2018 07:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9678) Expand clustering test cases
 to 3-node cluster
In-Reply-To: <JIRA.12729233.1516104791000@Atlassian.JIRA>
References: <JIRA.12729233.1516104791000@Atlassian.JIRA>
	<JIRA.12729233.1516104791000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729233.1516104791000.51077.1516104900912@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-9678:
---------------------------------
    Description: The core of the problem is that since all cases run against 2-node cluster a remote fetch is never tested given that numOwners defaults to 2.


> Expand clustering test cases to 3-node cluster
> ----------------------------------------------
>
>                 Key: WFLY-9678
>                 URL: https://issues.jboss.org/browse/WFLY-9678
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 11.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> The core of the problem is that since all cases run against 2-node cluster a remote fetch is never tested given that numOwners defaults to 2.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 07:24:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Tue, 16 Jan 2018 07:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9679) Duplication of TestXAResource
 under wildfly testsuite
In-Reply-To: <JIRA.12729234.1516105396000@Atlassian.JIRA>
References: <JIRA.12729234.1516105396000@Atlassian.JIRA>
	<JIRA.12729234.1516105396575@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729234.1516105396000.51149.1516105440070@Atlassian.JIRA>

Ondra Chaloupka created WFLY-9679:
-------------------------------------

             Summary: Duplication of TestXAResource under wildfly testsuite
                 Key: WFLY-9679
                 URL: https://issues.jboss.org/browse/WFLY-9679
             Project: WildFly
          Issue Type: Enhancement
          Components: Test Suite
    Affects Versions: 11.0.0.Final
            Reporter: Ondra Chaloupka
            Assignee: Ondra Chaloupka
            Priority: Trivial


The testsuite, tests checking XA transactions, contains duplicate code of test {{XAResource}}

* https://github.com/wildfly/wildfly/blob/master/testsuite/shared/src/main/java/org/jboss/as/test/integration/transactions/TestXAResource.java
* https://github.com/wildfly/wildfly/blob/master/testsuite/integration/basic/src/test/java/org/jboss/as/test/integration/ejb/transaction/exception/TestXAResource.java

are almost the same. It would be good to refactor them to reduce code duplication.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 08:09:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Tue, 16 Jan 2018 08:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3511) Improve test coverage of
 CLI feature - looping over commands/operations
In-Reply-To: <JIRA.12729242.1516108100000@Atlassian.JIRA>
References: <JIRA.12729242.1516108100000@Atlassian.JIRA>
	<JIRA.12729242.1516108100989@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729242.1516108100000.51463.1516108140327@Atlassian.JIRA>

Erich Duda created WFCORE-3511:
----------------------------------

             Summary: Improve test coverage of CLI feature - looping over commands/operations
                 Key: WFCORE-3511
                 URL: https://issues.jboss.org/browse/WFCORE-3511
             Project: WildFly Core
          Issue Type: Task
          Components: CLI
    Affects Versions: 4.0.0.Alpha5
            Reporter: Erich Duda
            Assignee: Erich Duda






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 08:21:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 16 Jan 2018 08:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2083) [Guided Decision Table] DSL
 can not contain $ in the definition
In-Reply-To: <JIRA.12718742.1509449801000@Atlassian.JIRA>
References: <JIRA.12718742.1509449801000@Atlassian.JIRA>
	<JIRA.12718742.1509449801000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718742.1509449801000.51652.1516108860378@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13517664#comment-13517664 ] 

Edson Tirelli commented on DROOLS-2083:
---------------------------------------

I am confused: is the problem in the core engine or in the decision table UI?

DSL uses regexp to match sentence fragments, so I believe the $ needs to be escaped to work... something like \$.

> [Guided Decision Table] DSL can not contain $ in the definition
> ---------------------------------------------------------------
>
>                 Key: DROOLS-2083
>                 URL: https://issues.jboss.org/browse/DROOLS-2083
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>             Fix For: 7.6.0.Final
>
>
> The DSL sentences are defined like:
> - [when] *definition* = real rule
> If the *definition* contains *$* character, then the DSL sentence can not be used properly in the guided decision table.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 08:31:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 16 Jan 2018 08:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2171) NullPointerException in
	drools core
In-Reply-To: <JIRA.12724167.1512762239000@Atlassian.JIRA>
References: <JIRA.12724167.1512762239000@Atlassian.JIRA>
	<JIRA.12724167.1512762239000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724167.1512762239000.51934.1516109460234@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2171?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13517675#comment-13517675 ] 

Edson Tirelli commented on DROOLS-2171:
---------------------------------------

Can you please provide more information and a reproducer? 

> NullPointerException in drools core 
> ------------------------------------
>
>                 Key: DROOLS-2171
>                 URL: https://issues.jboss.org/browse/DROOLS-2171
>             Project: Drools
>          Issue Type: Bug
>            Reporter: Yun Lin
>            Assignee: Mario Fusco
>            Priority: Critical
>              Labels: downstream_dependency
>
> After running for a couple hours, it got the follow NPE.
> java.lang.NullPointerException: null
> 	at org.drools.core.common.TupleSetsImpl.setNextTuple(TupleSetsImpl.java:349) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.common.TupleSetsImpl.removeUpdate(TupleSetsImpl.java:205) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.common.TupleSetsImpl.addDelete(TupleSetsImpl.java:110) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.phreak.SegmentPropagator.processPeerDeletes(SegmentPropagator.java:109) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.phreak.SegmentPropagator.processPeers(SegmentPropagator.java:48) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.phreak.SegmentPropagator.propagate(SegmentPropagator.java:41) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:347) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evaluateNetwork(RuleNetworkEvaluator.java:127) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.phreak.RuleExecutor.reEvaluateNetwork(RuleExecutor.java:212) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.phreak.RuleExecutor.evaluateNetworkAndFire(RuleExecutor.java:87) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.concurrent.AbstractRuleEvaluator.internalEvaluateAndFire(AbstractRuleEvaluator.java:34) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.concurrent.SequentialRuleEvaluator.evaluateAndFire(SequentialRuleEvaluator.java:43) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1067) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1014) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1006) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1320) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1311) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1299) ~[drools-core-7.4.1.Final.jar:7.4.1.Final]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 08:34:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 16 Jan 2018 08:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2210) Drools 7.3.0 serialization
 null pointer exceptions with sliding windows
In-Reply-To: <JIRA.12726432.1515031979000@Atlassian.JIRA>
References: <JIRA.12726432.1515031979000@Atlassian.JIRA>
	<JIRA.12726432.1515031979000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726432.1515031979000.51996.1516109640188@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2210?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13517677#comment-13517677 ] 

Edson Tirelli commented on DROOLS-2210:
---------------------------------------

[~connect.manjunath] did you check if the error still occurs with 7.5.0?

> Drools 7.3.0 serialization null pointer exceptions with sliding windows
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-2210
>                 URL: https://issues.jboss.org/browse/DROOLS-2210
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.3.0.Final
>            Reporter: Manjunath S Paramesan
>            Assignee: Mario Fusco
>            Priority: Critical
>
> We have a fairly large rule-base with temporal reasoning and sliding windows. 
> While serializing the drools session we observe random null pointer exceptions as see below:
> Exception in thread "pool-92-thread-98" java.lang.NullPointerException
> 	at org.drools.core.rule.SlidingTimeWindow$BehaviorJobContextTimerOutputMarshaller.serialize(SlidingTimeWindow.java:323)
> 	at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.writeTimers(ProtobufOutputMarshaller.java:880)
> 	at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.serializeSession(ProtobufOutputMarshaller.java:210)
> 	at org.drools.core.marshalling.impl.ProtobufOutputMarshaller.writeSession(ProtobufOutputMarshaller.java:118)
> 	at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:162)
> 	at org.drools.core.marshalling.impl.ProtobufMarshaller.marshall(ProtobufMarshaller.java:146)
> 	at com.mlnms.common.fmwk.drools.impl.DroolsClientImpl.backupKieSession(DroolsClientImpl.java:743)
> 	at com.mlnms.common.fmwk.drools.impl.DroolsClientImpl.lambda$processStatefulEvents$0(DroolsClientImpl.java:506)
> 	at java.lang.Thread.run(Thread.java:745)
> 	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)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 08:54:03 2018
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Tue, 16 Jan 2018 08:54:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3375) Upgrade jboss-logmanager
 from 2.1.0.Alpha5 to 2.1.0.Alpha6
In-Reply-To: <JIRA.12717310.1508430469000@Atlassian.JIRA>
References: <JIRA.12717310.1508430469000@Atlassian.JIRA>
	<JIRA.12717310.1508430469000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12717310.1508430469000.52213.1516110843417@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Romain Pelisse updated WFCORE-3375:
-----------------------------------
    Affects Version/s: 3.0.10.Final


> Upgrade jboss-logmanager from 2.1.0.Alpha5 to 2.1.0.Alpha6
> ----------------------------------------------------------
>
>                 Key: WFCORE-3375
>                 URL: https://issues.jboss.org/browse/WFCORE-3375
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Logging
>    Affects Versions: 3.0.9.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>              Labels: downstream_dependency
>
> The {{org.jboss.logmanager:jboss-logmanager:2.1.0.Alpha6}} will introduce a new {{CallerClassLoaderLogContextListener}} which needs to be used to ensure that modules don't create loggers on a deployments log context.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 08:54:04 2018
From: issues at jboss.org (Romain Pelisse (JIRA))
Date: Tue, 16 Jan 2018 08:54:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3375) Upgrade jboss-logmanager
 from 2.1.0.Alpha5 to 2.1.0.Alpha6
In-Reply-To: <JIRA.12717310.1508430469000@Atlassian.JIRA>
References: <JIRA.12717310.1508430469000@Atlassian.JIRA>
	<JIRA.12717310.1508430469000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12717310.1508430469000.52233.1516110844908@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Romain Pelisse updated WFCORE-3375:
-----------------------------------
    Affects Version/s: 3.0.9.Final
                           (was: 3.0.10.Final)


> Upgrade jboss-logmanager from 2.1.0.Alpha5 to 2.1.0.Alpha6
> ----------------------------------------------------------
>
>                 Key: WFCORE-3375
>                 URL: https://issues.jboss.org/browse/WFCORE-3375
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Logging
>    Affects Versions: 3.0.9.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>              Labels: downstream_dependency
>
> The {{org.jboss.logmanager:jboss-logmanager:2.1.0.Alpha6}} will introduce a new {{CallerClassLoaderLogContextListener}} which needs to be used to ensure that modules don't create loggers on a deployments log context.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 09:12:01 2018
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Tue, 16 Jan 2018 09:12:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2207) Validation and Verification
 panel is missing
In-Reply-To: <JIRA.12726386.1514992053000@Atlassian.JIRA>
References: <JIRA.12726386.1514992053000@Atlassian.JIRA>
	<JIRA.12726386.1514992053000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726386.1514992053000.52396.1516111921111@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13517704#comment-13517704 ] 

Toni Rikkola commented on DROOLS-2207:
--------------------------------------

[~tirelli] Not an issue in master, but checking 7.5.x now while looking at RHDM-224.

> Validation and Verification panel is missing
> --------------------------------------------
>
>                 Key: DROOLS-2207
>                 URL: https://issues.jboss.org/browse/DROOLS-2207
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.5.0.Final, 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Toni Rikkola
>            Priority: Critical
>
> The Validation and Verification panel is missing. The server log contains error [1], however looking into the workbench war, all v&v jars seems to be present.
> [1]
> ERROR [org.drools.workbench.services.verifier.plugin.backend.VerifierWebWorkerServlet] (default task-119) Failed to load verifier web worker.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 09:12:04 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 16 Jan 2018 09:12:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2083) [Guided Decision Table] DSL
 can not contain $ in the definition
In-Reply-To: <JIRA.12718742.1509449801000@Atlassian.JIRA>
References: <JIRA.12718742.1509449801000@Atlassian.JIRA>
	<JIRA.12718742.1509449801000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718742.1509449801000.52416.1516111924310@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2083:
-----------------------------------
    Sprint: 2018 Week 03-04


> [Guided Decision Table] DSL can not contain $ in the definition
> ---------------------------------------------------------------
>
>                 Key: DROOLS-2083
>                 URL: https://issues.jboss.org/browse/DROOLS-2083
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>             Fix For: 7.6.0.Final
>
>
> The DSL sentences are defined like:
> - [when] *definition* = real rule
> If the *definition* contains *$* character, then the DSL sentence can not be used properly in the guided decision table.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 11:28:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 16 Jan 2018 11:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2083) [Guided Decision Table] DSL
 can not contain $ in the definition
In-Reply-To: <JIRA.12718742.1509449801000@Atlassian.JIRA>
References: <JIRA.12718742.1509449801000@Atlassian.JIRA>
	<JIRA.12718742.1509449801000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718742.1509449801000.53504.1516120080322@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13517830#comment-13517830 ] 

Michael Anstis commented on DROOLS-2083:
----------------------------------------

See comments on [RHDM-281|https://issues.jboss.org/browse/RHDM-281].

> [Guided Decision Table] DSL can not contain $ in the definition
> ---------------------------------------------------------------
>
>                 Key: DROOLS-2083
>                 URL: https://issues.jboss.org/browse/DROOLS-2083
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>             Fix For: 7.6.0.Final
>
>
> The DSL sentences are defined like:
> - [when] *definition* = real rule
> If the *definition* contains *$* character, then the DSL sentence can not be used properly in the guided decision table.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 11:44:00 2018
From: issues at jboss.org (Daniel Bildhauer (JIRA))
Date: Tue, 16 Jan 2018 11:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9680) EJBs can't inherit a JDK8
 default method when default implementation is in a third interface
In-Reply-To: <JIRA.12729299.1516120995000@Atlassian.JIRA>
References: <JIRA.12729299.1516120995000@Atlassian.JIRA>
	<JIRA.12729299.1516120995969@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729299.1516120995000.53555.1516121040146@Atlassian.JIRA>

Daniel Bildhauer created WFLY-9680:
--------------------------------------

             Summary: EJBs can't inherit a JDK8 default method when default implementation is in a third interface
                 Key: WFLY-9680
                 URL: https://issues.jboss.org/browse/WFLY-9680
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 11.0.0.Final, 10.1.0.Final
            Reporter: Daniel Bildhauer
         Attachments: ejb-in-ear.zip, wildfly-ejb-in-ear-ear.ear

Given the following class/interface inheritance structure, the interface method doMagic could not be called from a remote view, even if there is a default implementation as given in the mixin interface. A local call works, but the remote call fails with a message like
{code}
org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
{code}

Example code:
{code}
@Remote
interface MyEJBInterface {
   void doMagic();
}

interface MyEJBMixin extends MyEJBInterface {
   default void doMagic() { .... }
}

@Stateless
class MyEJBBean extends MyEJBMixin {
}

{code}

The problem is inside the fix for WFLY-4354 bug, which checks only for the default method implementation in the interface declaring the method the first time but not in other interfaces. 
A example is attached and I will submitt a pull request with a fix. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 11:53:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 16 Jan 2018 11:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9675) Cannot disable
 'max-post-size' check for undertow listeners
In-Reply-To: <JIRA.12729135.1516068597000@Atlassian.JIRA>
References: <JIRA.12729135.1516068597000@Atlassian.JIRA>
	<JIRA.12729135.1516068597000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729135.1516068597000.53594.1516121580191@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9675?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-9675:
---------------------------------
    Summary: Cannot disable 'max-post-size' check for undertow listeners  (was: cannot disable 'max-post-size' check for undertow listeners)


> Cannot disable 'max-post-size' check for undertow listeners
> -----------------------------------------------------------
>
>                 Key: WFLY-9675
>                 URL: https://issues.jboss.org/browse/WFLY-9675
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 11.0.0.Final
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>
> With EAP7.1.0.GA, there has been added a validator for 'max-post-size' attribute for listeners in undertow subsystem. This validator requires positive integer values starting with value 1. That means, you cannot disable 'max-post-size' for such listener using 0 value anymore.
> In EAP6.4 and EAP7.0, it was possible to disable 'max-post-size' check with 0 value. I understand that we might not want to allow user to set this to 0 value as it might be a potentional security risk. Still, maybe we should relax this restriction as it was possible to configure it that way in previous versions of EAP.
> Also there is a [Knowledge Base article|https://access.redhat.com/solutions/714173] regarding to this feature, which we should update in case we won't reconsider our position.
> Just for the record - quoting question from mailing list:
> {quote}
> Dear Experts,
> Based on KCS, the "max-post-size" in "http-listener" from "undertow" subsystem can be disabled by setting "0" to it, it worked for EAP 6.x and 7.0 GA.
> But in EAP 7.1.0 GA, it didn't work:
> ~~~
> [standalone at localhost:9990 /] /subsystem=undertow/server=default-server/http-listener=default/:write-attribute(name=max-post-size,value=0)
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0117: 0 is an invalid value for parameter max-post-size. A minimum value of 1 is required",
>     "rolled-back" => true
> }
> ~~~
> By comparing schemas:
> ~~~
> jboss-eap-7.0/docs/schema/wildfly-undertow_x_x.xsd:
> <xs:attribute name="max-post-size" type="xs:long" default="0"/>
> ---
> jboss-eap-7.1/docs/schema/wildfly-undertow_x_x.xsd:
> <xs:attribute name="max-post-size" type="xs:long" default="10485760"/>
> ~~~
> The behaviour changed.
> And I found WFLY-6437 and JBEAP-3974, but failed to open links inside those.
> So can I ask if "max-post-size" can be disabled in EAP 7.1.0 GA and the reason if possible?
> Best Regards,
> Zhang Xu
> {quote}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 12:27:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 16 Jan 2018 12:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8913) It is not possible to add
 cache store in infinispan subsystem
In-Reply-To: <JIRA.12696535.1496948075000@Atlassian.JIRA>
References: <JIRA.12696535.1496948075000@Atlassian.JIRA>
	<JIRA.12696535.1496948075000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696535.1496948075000.53729.1516123620720@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13517858#comment-13517858 ] 

Radoslav Husar commented on WFLY-8913:
--------------------------------------

[~Maxoid] You need to run this script in a batch.

> It is not possible to add cache store in infinispan subsystem
> -------------------------------------------------------------
>
>                 Key: WFLY-8913
>                 URL: https://issues.jboss.org/browse/WFLY-8913
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Beta1
>
>
> Adding cache store to already created cache ends by failure even if it should succeed:
> {code}
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-container=hibernate/invalidation-cache=foobar/store=STORE:add(class="org.infinispan.configuration.cache.SingleFileStoreConfigurationBuilder")
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache.store.hibernate.foobar is already registered",
>     "rolled-back" => true
> }
> {code}
> This is a regression against 7.1.0.DR18.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 12:43:00 2018
From: issues at jboss.org (Chris Giddings (JIRA))
Date: Tue, 16 Jan 2018 12:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves
 Remnants in standalone.xml
In-Reply-To: <JIRA.12729305.1516124574000@Atlassian.JIRA>
References: <JIRA.12729305.1516124574000@Atlassian.JIRA>
	<JIRA.12729305.1516124574128@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729305.1516124574000.53792.1516124580099@Atlassian.JIRA>

Chris Giddings created WFLY-9681:
------------------------------------

             Summary: Deleting ExampleDS Leaves Remnants in standalone.xml
                 Key: WFLY-9681
                 URL: https://issues.jboss.org/browse/WFLY-9681
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 11.0.0.Final
            Reporter: Chris Giddings
            Assignee: Jason Greene
            Priority: Minor


h2. SUMMARY
When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".

When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.

h2. WORKAROUND
Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)

h2. BUG JUSTIFICATION
# I would expect anything labeled as "Example" to be deleted by an administrator in most environments
# I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 12:47:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 16 Jan 2018 12:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8913) It is not possible to add
 cache store in infinispan subsystem
In-Reply-To: <JIRA.12696535.1496948075000@Atlassian.JIRA>
References: <JIRA.12696535.1496948075000@Atlassian.JIRA>
	<JIRA.12696535.1496948075000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696535.1496948075000.53803.1516124820505@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13517866#comment-13517866 ] 

Paul Ferraro commented on WFLY-8913:
------------------------------------

[~Maxoid] Alternatively (to running as a batch), you can run the cache store add operation using the allow-resource-service-restart flag.

e.g.
{code}/subsystem=infinispan/cache-container=hibernate/local-cache=foobar1/store=file:add(){allow-resource-service-restart=true}{code}
N.B. The above command is the non-deprecated equivalent of the command specified in the description.

This ensure that the conflicting services are removed prior to installing the requisite file store service.

> It is not possible to add cache store in infinispan subsystem
> -------------------------------------------------------------
>
>                 Key: WFLY-8913
>                 URL: https://issues.jboss.org/browse/WFLY-8913
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Beta1
>
>
> Adding cache store to already created cache ends by failure even if it should succeed:
> {code}
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-container=hibernate/invalidation-cache=foobar/store=STORE:add(class="org.infinispan.configuration.cache.SingleFileStoreConfigurationBuilder")
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache.store.hibernate.foobar is already registered",
>     "rolled-back" => true
> }
> {code}
> This is a regression against 7.1.0.DR18.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 12:51:01 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 16 Jan 2018 12:51:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves
 Remnants in standalone.xml
In-Reply-To: <JIRA.12729305.1516124574000@Atlassian.JIRA>
References: <JIRA.12729305.1516124574000@Atlassian.JIRA>
	<JIRA.12729305.1516124574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729305.1516124574000.53807.1516125061012@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-9681:
-----------------------------------
    Component/s: JCA


> Deleting ExampleDS Leaves Remnants in standalone.xml
> ----------------------------------------------------
>
>                 Key: WFLY-9681
>                 URL: https://issues.jboss.org/browse/WFLY-9681
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Final
>            Reporter: Chris Giddings
>            Assignee: Jason Greene
>            Priority: Minor
>              Labels: JDBC
>
> h2. SUMMARY
> When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
> When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
> h2. WORKAROUND
> Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
> h2. BUG JUSTIFICATION
> # I would expect anything labeled as "Example" to be deleted by an administrator in most environments
> # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 12:51:02 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 16 Jan 2018 12:51:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves
 Remnants in standalone.xml
In-Reply-To: <JIRA.12729305.1516124574000@Atlassian.JIRA>
References: <JIRA.12729305.1516124574000@Atlassian.JIRA>
	<JIRA.12729305.1516124574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729305.1516124574000.53814.1516125062344@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned WFLY-9681:
--------------------------------------

    Assignee: Stefano Maestri  (was: Jason Greene)


> Deleting ExampleDS Leaves Remnants in standalone.xml
> ----------------------------------------------------
>
>                 Key: WFLY-9681
>                 URL: https://issues.jboss.org/browse/WFLY-9681
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Final
>            Reporter: Chris Giddings
>            Assignee: Stefano Maestri
>            Priority: Minor
>              Labels: JDBC
>
> h2. SUMMARY
> When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
> When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
> h2. WORKAROUND
> Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
> h2. BUG JUSTIFICATION
> # I would expect anything labeled as "Example" to be deleted by an administrator in most environments
> # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 12:54:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 16 Jan 2018 12:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves
 Remnants in standalone.xml
In-Reply-To: <JIRA.12729305.1516124574000@Atlassian.JIRA>
References: <JIRA.12729305.1516124574000@Atlassian.JIRA>
	<JIRA.12729305.1516124574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729305.1516124574000.53819.1516125240268@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13517867#comment-13517867 ] 

Darran Lofthouse commented on WFLY-9681:
----------------------------------------

For an issue like this it would help if in the bug report you can include the actual error message you see and also show the configuration you are referring to that is left behind.

I only find 3 uses of the word 'Example' in the default configuration, generally when an administrator removes a resource they should be updating references to that resource first.

> Deleting ExampleDS Leaves Remnants in standalone.xml
> ----------------------------------------------------
>
>                 Key: WFLY-9681
>                 URL: https://issues.jboss.org/browse/WFLY-9681
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Final
>            Reporter: Chris Giddings
>            Assignee: Stefano Maestri
>            Priority: Minor
>              Labels: JDBC
>
> h2. SUMMARY
> When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
> When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
> h2. WORKAROUND
> Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
> h2. BUG JUSTIFICATION
> # I would expect anything labeled as "Example" to be deleted by an administrator in most environments
> # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 13:14:00 2018
From: issues at jboss.org (Chris Giddings (JIRA))
Date: Tue, 16 Jan 2018 13:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves
 Remnants in standalone.xml
In-Reply-To: <JIRA.12729305.1516124574000@Atlassian.JIRA>
References: <JIRA.12729305.1516124574000@Atlassian.JIRA>
	<JIRA.12729305.1516124574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729305.1516124574000.53875.1516126440703@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13517873#comment-13517873 ] 

Chris Giddings commented on WFLY-9681:
--------------------------------------

h2. DETAILS
[~dlofthouse] Understood. This is why I included the [StackOverflow ID|https://stackoverflow.com/questions/47700782/i-deleted-the-exampleds-from-wildfly-now-i-cant-deploy-my-app-because-i-got-er], but for the sake of brevity and simplicity I understand.

Here is that StackOverflow user's error:

{code:java}
"WFLYCTL0412: Required services that are not installed:" => ["jboss.naming.context.java.jboss.datasources.ExampleDS"], "WFLYCTL0180: Services with missing/unavailable dependencies" => ["jboss.naming.context.java.module.WebJ2EE.WebJ2EE.DefaultDataSource is missing [jboss.naming.context.java.jboss.datasources.ExampleDS]"] } 18:32:10,189 INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) WFLYSRV0010: Deployed "WebJ2EE.war" (runtime-name : "WebJ2EE.war") 18:32:10,189 INFO [org.jboss.as.controller] (DeploymentScanner-threads - 2) WFLYCTL0183: Service status report WFLYCTL0184: New missing/unsatisfied dependencies: service jboss.naming.context.java.jboss.datasources.ExampleDS (missing) dependents: [service jboss.naming.context.java.module.WebJ2EE.WebJ2EE.DefaultDataSource]
{code}

This error is nearly identical to my own with exception to dates/times etc. I chose to rely upon the already existing StackOverflow request vs creating a duplicate of it, or again reproducing the issue from scratch which I have done several times now. Apologies if that's a bit lazy.

h2. RESPONSE
Yes, the default configuration contains the offending 'Example' details. Regardless of this, deleting an 'Example' item from default configuration should probably not lead to manual intervention in configuration files. I think it reasonable that any administrator may assume all references to a deleted 'Example' resource to also be removed when that resource is deleted. If the resource were required by the system (it does not appear to be), it should likely then not be labeled as 'Example'.

> Deleting ExampleDS Leaves Remnants in standalone.xml
> ----------------------------------------------------
>
>                 Key: WFLY-9681
>                 URL: https://issues.jboss.org/browse/WFLY-9681
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Final
>            Reporter: Chris Giddings
>            Assignee: Stefano Maestri
>            Priority: Minor
>              Labels: JDBC
>
> h2. SUMMARY
> When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
> When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
> h2. WORKAROUND
> Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
> h2. BUG JUSTIFICATION
> # I would expect anything labeled as "Example" to be deleted by an administrator in most environments
> # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 13:15:01 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 16 Jan 2018 13:15:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1489) FormAuthenticationMechanism
 should only create a session if an identity is being stored
In-Reply-To: <JIRA.12729311.1516126485000@Atlassian.JIRA>
References: <JIRA.12729311.1516126485000@Atlassian.JIRA>
	<JIRA.12729311.1516126485875@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729311.1516126485000.53883.1516126501086@Atlassian.JIRA>

Darran Lofthouse created ELY-1489:
-------------------------------------

             Summary: FormAuthenticationMechanism should only create a session if an identity is being stored
                 Key: ELY-1489
                 URL: https://issues.jboss.org/browse/ELY-1489
             Project: WildFly Elytron
          Issue Type: Bug
          Components: HTTP
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.2.0.Beta12


We don't need this internal method to contain the boolean argument: -

{code}
private IdentityCache createIdentityCache(HttpServerRequest request, boolean createSession) {
{code}

A subsequent call to put is sufficient for us to know a session is needed, an all other cases don't create the session.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 13:37:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 16 Jan 2018 13:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9682) ApplicationSecurityDomain in
 Undertow, doesn't need to use a method reference lambda
In-Reply-To: <JIRA.12729315.1516127761000@Atlassian.JIRA>
References: <JIRA.12729315.1516127761000@Atlassian.JIRA>
	<JIRA.12729315.1516127761336@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729315.1516127761000.53966.1516127820166@Atlassian.JIRA>

Darran Lofthouse created WFLY-9682:
--------------------------------------

             Summary: ApplicationSecurityDomain in Undertow, doesn't need to use a method reference lambda
                 Key: WFLY-9682
                 URL: https://issues.jboss.org/browse/WFLY-9682
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 12.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 13:39:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 16 Jan 2018 13:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9682) ApplicationSecurityDomain in
 EJB3, doesn't need to use a method reference lambda
In-Reply-To: <JIRA.12729315.1516127761000@Atlassian.JIRA>
References: <JIRA.12729315.1516127761000@Atlassian.JIRA>
	<JIRA.12729315.1516127761000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729315.1516127761000.53974.1516127940187@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-9682:
-----------------------------------
    Summary: ApplicationSecurityDomain in EJB3, doesn't need to use a method reference lambda  (was: ApplicationSecurityDomain in Undertow, doesn't need to use a method reference lambda)


> ApplicationSecurityDomain in EJB3, doesn't need to use a method reference lambda
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-9682
>                 URL: https://issues.jboss.org/browse/WFLY-9682
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 12.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 13:39:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Tue, 16 Jan 2018 13:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9682) ApplicationSecurityDomain in
 EJB3, doesn't need to use a method reference lambda
In-Reply-To: <JIRA.12729315.1516127761000@Atlassian.JIRA>
References: <JIRA.12729315.1516127761000@Atlassian.JIRA>
	<JIRA.12729315.1516127761000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729315.1516127761000.53977.1516127940257@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9682?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-9682:
-----------------------------------
    Component/s: EJB
                     (was: Web (Undertow))


> ApplicationSecurityDomain in EJB3, doesn't need to use a method reference lambda
> --------------------------------------------------------------------------------
>
>                 Key: WFLY-9682
>                 URL: https://issues.jboss.org/browse/WFLY-9682
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 12.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 14:20:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 16 Jan 2018 14:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8913) It is not possible to add
 cache store in infinispan subsystem
In-Reply-To: <JIRA.12696535.1496948075000@Atlassian.JIRA>
References: <JIRA.12696535.1496948075000@Atlassian.JIRA>
	<JIRA.12696535.1496948075000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696535.1496948075000.54112.1516130400441@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13519783#comment-13519783 ] 

Radoslav Husar commented on WFLY-8913:
--------------------------------------

[~Maxoid] Alternatively (to the previous 2 options) you can boot the server in the admin only mode {{--admin-only}}, run the commands which will succeed since there won't be any runtime services and then just {{reload}}.

> It is not possible to add cache store in infinispan subsystem
> -------------------------------------------------------------
>
>                 Key: WFLY-8913
>                 URL: https://issues.jboss.org/browse/WFLY-8913
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Beta1
>
>
> Adding cache store to already created cache ends by failure even if it should succeed:
> {code}
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-container=hibernate/invalidation-cache=foobar/store=STORE:add(class="org.infinispan.configuration.cache.SingleFileStoreConfigurationBuilder")
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache.store.hibernate.foobar is already registered",
>     "rolled-back" => true
> }
> {code}
> This is a regression against 7.1.0.DR18.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 17:42:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 16 Jan 2018 17:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9678) Expand clustering test cases
 to 3-node cluster
In-Reply-To: <JIRA.12729233.1516104791000@Atlassian.JIRA>
References: <JIRA.12729233.1516104791000@Atlassian.JIRA>
	<JIRA.12729233.1516104791000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729233.1516104791000.54411.1516142520121@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-9678:
---------------------------------
    Fix Version/s: 12.0.0.Alpha1


> Expand clustering test cases to 3-node cluster
> ----------------------------------------------
>
>                 Key: WFLY-9678
>                 URL: https://issues.jboss.org/browse/WFLY-9678
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 11.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 12.0.0.Alpha1
>
>
> The core of the problem is that since all cases run against 2-node cluster a remote fetch is never tested given that numOwners defaults to 2.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 18:13:00 2018
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 16 Jan 2018 18:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9680) EJBs can't inherit a JDK8
 default method when default implementation is in a third interface
In-Reply-To: <JIRA.12729299.1516120996000@Atlassian.JIRA>
References: <JIRA.12729299.1516120996000@Atlassian.JIRA>
	<JIRA.12729299.1516120996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729299.1516120996000.54435.1516144380144@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9680?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar reassigned WFLY-9680:
---------------------------------

    Assignee: Stuart Douglas


> EJBs can't inherit a JDK8 default method when default implementation is in a third interface
> --------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9680
>                 URL: https://issues.jboss.org/browse/WFLY-9680
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final, 11.0.0.Final
>            Reporter: Daniel Bildhauer
>            Assignee: Stuart Douglas
>         Attachments: ejb-in-ear.zip, wildfly-ejb-in-ear-ear.ear
>
>
> Given the following class/interface inheritance structure, the interface method doMagic could not be called from a remote view, even if there is a default implementation as given in the mixin interface. A local call works, but the remote call fails with a message like
> {code}
> org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
> {code}
> Example code:
> {code}
> @Remote
> interface MyEJBInterface {
>    void doMagic();
> }
> interface MyEJBMixin extends MyEJBInterface {
>    default void doMagic() { .... }
> }
> @Stateless
> class MyEJBBean extends MyEJBMixin {
> }
> {code}
> The problem is inside the fix for WFLY-4354 bug, which checks only for the default method implementation in the interface declaring the method the first time but not in other interfaces. 
> A example is attached and I will submitt a pull request with a fix. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 18:14:00 2018
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Tue, 16 Jan 2018 18:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves
 Remnants in standalone.xml
In-Reply-To: <JIRA.12729305.1516124574000@Atlassian.JIRA>
References: <JIRA.12729305.1516124574000@Atlassian.JIRA>
	<JIRA.12729305.1516124574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729305.1516124574000.54440.1516144440212@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13519832#comment-13519832 ] 

Tomaz Cerar commented on WFLY-9681:
-----------------------------------

This are EE default bindings. a tricky thing all in all.

> Deleting ExampleDS Leaves Remnants in standalone.xml
> ----------------------------------------------------
>
>                 Key: WFLY-9681
>                 URL: https://issues.jboss.org/browse/WFLY-9681
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Final
>            Reporter: Chris Giddings
>            Assignee: Stefano Maestri
>            Priority: Minor
>              Labels: JDBC
>
> h2. SUMMARY
> When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
> When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
> h2. WORKAROUND
> Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
> h2. BUG JUSTIFICATION
> # I would expect anything labeled as "Example" to be deleted by an administrator in most environments
> # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 21:01:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 16 Jan 2018 21:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9666) ClassLoader leak in
 org.jboss.el.cache.FactoryFinderCache (Wildfly 11)
In-Reply-To: <JIRA.12727948.1515943218000@Atlassian.JIRA>
References: <JIRA.12727948.1515943218000@Atlassian.JIRA>
	<JIRA.12727948.1515943218000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727948.1515943218000.54543.1516154460485@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9666?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13519844#comment-13519844 ] 

Stuart Douglas commented on WFLY-9666:
--------------------------------------

It should work fine for EAR deployments, I think the real issue is the ordering. If shutdown causes EL to be used at all then the ClassLoader can be re-added to the cache. [~brunojcm] do you have a simple reproducer we can use?

> ClassLoader leak in org.jboss.el.cache.FactoryFinderCache (Wildfly 11)
> ----------------------------------------------------------------------
>
>                 Key: WFLY-9666
>                 URL: https://issues.jboss.org/browse/WFLY-9666
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 11.0.0.Final
>         Environment: macOS
>            Reporter: Bruno Medeiros
>            Assignee: Stuart Douglas
>            Priority: Critical
>         Attachments: Screen Shot 2018-01-14 at 19.32.10.png
>
>
> I was investigating why my class loader was leaking and after fixing all the problems within my application classes I got the leak shown in the attachment.
>  !Screen Shot 2018-01-14 at 19.32.10.png|thumbnail! 
> This is pretty similar with WFLY-3365, not sure if I should have reopened that one o raised this one, sorry if I took the wrong decision.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 22:41:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 16 Jan 2018 22:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3512) EJBs can't inherit a JDK8
 default method when default implementation is in a third interface
In-Reply-To: <JIRA.12729299.1516120996000@Atlassian.JIRA>
References: <JIRA.12729299.1516120996000@Atlassian.JIRA>
	<JIRA.12729299.1516120996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729299.1516120996000.54589.1516160460165@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved WFLY-9680 to WFCORE-3512:
----------------------------------------------

              Project: WildFly Core  (was: WildFly)
                  Key: WFCORE-3512  (was: WFLY-9680)
          Component/s: Server
                           (was: EJB)
    Affects Version/s:     (was: 10.1.0.Final)
                           (was: 11.0.0.Final)


> EJBs can't inherit a JDK8 default method when default implementation is in a third interface
> --------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3512
>                 URL: https://issues.jboss.org/browse/WFCORE-3512
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Daniel Bildhauer
>            Assignee: Stuart Douglas
>         Attachments: ejb-in-ear.zip, wildfly-ejb-in-ear-ear.ear
>
>
> Given the following class/interface inheritance structure, the interface method doMagic could not be called from a remote view, even if there is a default implementation as given in the mixin interface. A local call works, but the remote call fails with a message like
> {code}
> org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
> {code}
> Example code:
> {code}
> @Remote
> interface MyEJBInterface {
>    void doMagic();
> }
> interface MyEJBMixin extends MyEJBInterface {
>    default void doMagic() { .... }
> }
> @Stateless
> class MyEJBBean extends MyEJBMixin {
> }
> {code}
> The problem is inside the fix for WFLY-4354 bug, which checks only for the default method implementation in the interface declaring the method the first time but not in other interfaces. 
> A example is attached and I will submitt a pull request with a fix. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 22:42:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 16 Jan 2018 22:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3512) ClassReflectionIndexUtil
 does not return default methods from findMethod
In-Reply-To: <JIRA.12729299.1516120996000@Atlassian.JIRA>
References: <JIRA.12729299.1516120996000@Atlassian.JIRA>
	<JIRA.12729299.1516120996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729299.1516120996000.54592.1516160520325@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFCORE-3512:
-----------------------------------
    Summary: ClassReflectionIndexUtil does not return default methods from findMethod  (was: EJBs can't inherit a JDK8 default method when default implementation is in a third interface)


> ClassReflectionIndexUtil does not return default methods from findMethod
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-3512
>                 URL: https://issues.jboss.org/browse/WFCORE-3512
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Daniel Bildhauer
>            Assignee: Stuart Douglas
>         Attachments: ejb-in-ear.zip, wildfly-ejb-in-ear-ear.ear
>
>
> Given the following class/interface inheritance structure, the interface method doMagic could not be called from a remote view, even if there is a default implementation as given in the mixin interface. A local call works, but the remote call fails with a message like
> {code}
> org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
> {code}
> Example code:
> {code}
> @Remote
> interface MyEJBInterface {
>    void doMagic();
> }
> interface MyEJBMixin extends MyEJBInterface {
>    default void doMagic() { .... }
> }
> @Stateless
> class MyEJBBean extends MyEJBMixin {
> }
> {code}
> The problem is inside the fix for WFLY-4354 bug, which checks only for the default method implementation in the interface declaring the method the first time but not in other interfaces. 
> A example is attached and I will submitt a pull request with a fix. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 22:42:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 16 Jan 2018 22:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3512) ClassReflectionIndexUtil
 does not return default methods from findMethod
In-Reply-To: <JIRA.12729299.1516120996000@Atlassian.JIRA>
References: <JIRA.12729299.1516120996000@Atlassian.JIRA>
	<JIRA.12729299.1516120996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729299.1516120996000.54597.1516160520637@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFCORE-3512:
-----------------------------------
    Description: 
This problem is in Wildfly Core, but manifests as an issue with EJB's in WildFly full.

Given the following class/interface inheritance structure, the interface method doMagic could not be called from a remote view, even if there is a default implementation as given in the mixin interface. A local call works, but the remote call fails with a message like
{code}
org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
{code}

Example code:
{code}
@Remote
interface MyEJBInterface {
   void doMagic();
}

interface MyEJBMixin extends MyEJBInterface {
   default void doMagic() { .... }
}

@Stateless
class MyEJBBean extends MyEJBMixin {
}

{code}

The problem is inside the fix for WFLY-4354 bug, which checks only for the default method implementation in the interface declaring the method the first time but not in other interfaces. 
A example is attached and I will submitt a pull request with a fix. 

  was:
Given the following class/interface inheritance structure, the interface method doMagic could not be called from a remote view, even if there is a default implementation as given in the mixin interface. A local call works, but the remote call fails with a message like
{code}
org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
{code}

Example code:
{code}
@Remote
interface MyEJBInterface {
   void doMagic();
}

interface MyEJBMixin extends MyEJBInterface {
   default void doMagic() { .... }
}

@Stateless
class MyEJBBean extends MyEJBMixin {
}

{code}

The problem is inside the fix for WFLY-4354 bug, which checks only for the default method implementation in the interface declaring the method the first time but not in other interfaces. 
A example is attached and I will submitt a pull request with a fix. 



> ClassReflectionIndexUtil does not return default methods from findMethod
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-3512
>                 URL: https://issues.jboss.org/browse/WFCORE-3512
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Daniel Bildhauer
>            Assignee: Stuart Douglas
>         Attachments: ejb-in-ear.zip, wildfly-ejb-in-ear-ear.ear
>
>
> This problem is in Wildfly Core, but manifests as an issue with EJB's in WildFly full.
> Given the following class/interface inheritance structure, the interface method doMagic could not be called from a remote view, even if there is a default implementation as given in the mixin interface. A local call works, but the remote call fails with a message like
> {code}
> org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
> {code}
> Example code:
> {code}
> @Remote
> interface MyEJBInterface {
>    void doMagic();
> }
> interface MyEJBMixin extends MyEJBInterface {
>    default void doMagic() { .... }
> }
> @Stateless
> class MyEJBBean extends MyEJBMixin {
> }
> {code}
> The problem is inside the fix for WFLY-4354 bug, which checks only for the default method implementation in the interface declaring the method the first time but not in other interfaces. 
> A example is attached and I will submitt a pull request with a fix. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 16 23:19:00 2018
From: issues at jboss.org (Maxim Karavaev (JIRA))
Date: Tue, 16 Jan 2018 23:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8913) It is not possible to add
 cache store in infinispan subsystem
In-Reply-To: <JIRA.12696535.1496948075000@Atlassian.JIRA>
References: <JIRA.12696535.1496948075000@Atlassian.JIRA>
	<JIRA.12696535.1496948075000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696535.1496948075000.54657.1516162740259@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13519857#comment-13519857 ] 

Maxim Karavaev commented on WFLY-8913:
--------------------------------------

Thank you guys! 
I could add additional workaround - using an offline configuration
{noformat}
embed-host-controller
embed-server
{noformat}
But in any case, the error message is absolutely confusing and disappointing. 

> It is not possible to add cache store in infinispan subsystem
> -------------------------------------------------------------
>
>                 Key: WFLY-8913
>                 URL: https://issues.jboss.org/browse/WFLY-8913
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering
>    Affects Versions: 11.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>             Fix For: 11.0.0.Beta1
>
>
> Adding cache store to already created cache ends by failure even if it should succeed:
> {code}
> [standalone at localhost:9990 /] /subsystem=infinispan/cache-container=hibernate/invalidation-cache=foobar/store=STORE:add(class="org.infinispan.configuration.cache.SingleFileStoreConfigurationBuilder")
> {
>     "outcome" => "failed",
>     "failure-description" => "WFLYCTL0158: Operation handler failed: org.jboss.msc.service.DuplicateServiceException: Service org.wildfly.clustering.infinispan.cache.store.hibernate.foobar is already registered",
>     "rolled-back" => true
> }
> {code}
> This is a regression against 7.1.0.DR18.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 00:29:00 2018
From: issues at jboss.org (jaikiran pai (JIRA))
Date: Wed, 17 Jan 2018 00:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves
 Remnants in standalone.xml
In-Reply-To: <JIRA.12729305.1516124574000@Atlassian.JIRA>
References: <JIRA.12729305.1516124574000@Atlassian.JIRA>
	<JIRA.12729305.1516124574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729305.1516124574000.54736.1516166940227@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13519865#comment-13519865 ] 

jaikiran pai commented on WFLY-9681:
------------------------------------

[~cgiddings], does that war (the one in the error message) use JPA (Java Persistence API)?


> Deleting ExampleDS Leaves Remnants in standalone.xml
> ----------------------------------------------------
>
>                 Key: WFLY-9681
>                 URL: https://issues.jboss.org/browse/WFLY-9681
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Final
>            Reporter: Chris Giddings
>            Assignee: Stefano Maestri
>            Priority: Minor
>              Labels: JDBC
>
> h2. SUMMARY
> When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
> When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
> h2. WORKAROUND
> Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
> h2. BUG JUSTIFICATION
> # I would expect anything labeled as "Example" to be deleted by an administrator in most environments
> # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 03:36:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 17 Jan 2018 03:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8488) Usage of JGroups JDBC_PING
 attempts to delete row too late
In-Reply-To: <JIRA.12685499.1491050677000@Atlassian.JIRA>
References: <JIRA.12685499.1491050677000@Atlassian.JIRA>
	<JIRA.12685499.1491050677000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12685499.1491050677000.55102.1516178160654@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-8488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar closed WFLY-8488.
--------------------------------
    Resolution: Rejected


[~meetoblivion] Reclosing the issue, but just to note, this is an issue tracker, for questions & answers best use the community forums (https://developer.jboss.org/en/wildfly).

> 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.5.0#75005)

From issues at jboss.org  Wed Jan 17 05:12:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 17 Jan 2018 05:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2083) [Guided Decision Table] DSL
 can not contain $ in the definition
In-Reply-To: <JIRA.12718742.1509449801000@Atlassian.JIRA>
References: <JIRA.12718742.1509449801000@Atlassian.JIRA>
	<JIRA.12718742.1509449801000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718742.1509449801000.55900.1516183920995@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2083?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko closed DROOLS-2083.
-------------------------------
    Resolution: Explained


> [Guided Decision Table] DSL can not contain $ in the definition
> ---------------------------------------------------------------
>
>                 Key: DROOLS-2083
>                 URL: https://issues.jboss.org/browse/DROOLS-2083
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>             Fix For: 7.6.0.Final
>
>
> The DSL sentences are defined like:
> - [when] *definition* = real rule
> If the *definition* contains *$* character, then the DSL sentence can not be used properly in the guided decision table.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 05:25:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 17 Jan 2018 05:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2207) Validation and Verification
 panel is missing
In-Reply-To: <JIRA.12726386.1514992053000@Atlassian.JIRA>
References: <JIRA.12726386.1514992053000@Atlassian.JIRA>
	<JIRA.12726386.1514992053000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726386.1514992053000.55986.1516184700197@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13519988#comment-13519988 ] 

Jozef Marko commented on DROOLS-2207:
-------------------------------------

[~Rikkola] During verification of the 7.5.x PR for RHDM-224 I saw the verification panel on the place, so I believe we can close this one.

> Validation and Verification panel is missing
> --------------------------------------------
>
>                 Key: DROOLS-2207
>                 URL: https://issues.jboss.org/browse/DROOLS-2207
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.5.0.Final, 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Toni Rikkola
>            Priority: Critical
>
> The Validation and Verification panel is missing. The server log contains error [1], however looking into the workbench war, all v&v jars seems to be present.
> [1]
> ERROR [org.drools.workbench.services.verifier.plugin.backend.VerifierWebWorkerServlet] (default task-119) Failed to load verifier web worker.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 05:45:00 2018
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Wed, 17 Jan 2018 05:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2207) Validation and Verification
 panel is missing
In-Reply-To: <JIRA.12726386.1514992053000@Atlassian.JIRA>
References: <JIRA.12726386.1514992053000@Atlassian.JIRA>
	<JIRA.12726386.1514992053000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726386.1514992053000.56137.1516185900389@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520001#comment-13520001 ] 

Toni Rikkola commented on DROOLS-2207:
--------------------------------------

[~jomarko] Great..

> Validation and Verification panel is missing
> --------------------------------------------
>
>                 Key: DROOLS-2207
>                 URL: https://issues.jboss.org/browse/DROOLS-2207
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.5.0.Final, 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Toni Rikkola
>            Priority: Critical
>
> The Validation and Verification panel is missing. The server log contains error [1], however looking into the workbench war, all v&v jars seems to be present.
> [1]
> ERROR [org.drools.workbench.services.verifier.plugin.backend.VerifierWebWorkerServlet] (default task-119) Failed to load verifier web worker.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 05:46:01 2018
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Wed, 17 Jan 2018 05:46:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2207) Validation and Verification
 panel is missing
In-Reply-To: <JIRA.12726386.1514992053000@Atlassian.JIRA>
References: <JIRA.12726386.1514992053000@Atlassian.JIRA>
	<JIRA.12726386.1514992053000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726386.1514992053000.56141.1516185961029@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2207?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toni Rikkola resolved DROOLS-2207.
----------------------------------
    Resolution: Out of Date


> Validation and Verification panel is missing
> --------------------------------------------
>
>                 Key: DROOLS-2207
>                 URL: https://issues.jboss.org/browse/DROOLS-2207
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.5.0.Final, 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Toni Rikkola
>            Priority: Critical
>
> The Validation and Verification panel is missing. The server log contains error [1], however looking into the workbench war, all v&v jars seems to be present.
> [1]
> ERROR [org.drools.workbench.services.verifier.plugin.backend.VerifierWebWorkerServlet] (default task-119) Failed to load verifier web worker.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 05:56:00 2018
From: issues at jboss.org (Ivo Bek (JIRA))
Date: Wed, 17 Jan 2018 05:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2248) Disable validation and
 verification for a specific decision table
In-Reply-To: <JIRA.12729378.1516186553000@Atlassian.JIRA>
References: <JIRA.12729378.1516186553000@Atlassian.JIRA>
	<JIRA.12729378.1516186553721@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729378.1516186553000.56180.1516186560165@Atlassian.JIRA>

Ivo Bek created DROOLS-2248:
-------------------------------

             Summary: Disable validation and verification for a specific decision table
                 Key: DROOLS-2248
                 URL: https://issues.jboss.org/browse/DROOLS-2248
             Project: Drools
          Issue Type: Enhancement
          Components: decision tables
            Reporter: Ivo Bek
            Assignee: Mario Fusco


Currently it seems it's not possible to disable verification and validation for specific decision table.

Administrator can only enable/disable verification and validation globally for the whole workbench but usually business admins need to disable verification and validation for decision tables which are complex / contain huge amount of rows and similarly.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:14:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 17 Jan 2018 06:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9683) Eliminate the forEach loop in
 Undertow ApplicationSecurityDomain
In-Reply-To: <JIRA.12729381.1516187582000@Atlassian.JIRA>
References: <JIRA.12729381.1516187582000@Atlassian.JIRA>
	<JIRA.12729381.1516187582019@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729381.1516187582000.56290.1516187640639@Atlassian.JIRA>

Darran Lofthouse created WFLY-9683:
--------------------------------------

             Summary: Eliminate the forEach loop in Undertow ApplicationSecurityDomain
                 Key: WFLY-9683
                 URL: https://issues.jboss.org/browse/WFLY-9683
             Project: WildFly
          Issue Type: Bug
          Components: Web (Undertow)
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 12.0.0.Alpha1


The use of a lambda here is just so a forEach loop can be used instead of a normal for loop.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:14:01 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:14:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9684) Provide minimalistic profile
 for Artemis backup configuration
In-Reply-To: <JIRA.12729384.1516187615000@Atlassian.JIRA>
References: <JIRA.12729384.1516187615000@Atlassian.JIRA>
	<JIRA.12729384.1516187615901@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729384.1516187615000.56302.1516187641086@Atlassian.JIRA>

Kabir Khan created WFLY-9684:
--------------------------------

             Summary: Provide minimalistic profile for Artemis backup configuration
                 Key: WFLY-9684
                 URL: https://issues.jboss.org/browse/WFLY-9684
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 10.0.0.Final
            Reporter: Miroslav Novak
            Assignee: Jeff Mesnil


If Artemis is configured as dedicated backup, no deployments like MDB,EJB,Servlets should be deployed to it. It should serve to its purpose which is to wait for Wildfly 10 with Artemis configured as live to fail.

We should provide minimalistic configuration for Wildfly serving purely as Artemis backup server.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:14:01 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:14:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9685) JMS Bridge should display
 statistics about messages that have been processed.
In-Reply-To: <JIRA.12729385.1516187624000@Atlassian.JIRA>
References: <JIRA.12729385.1516187624000@Atlassian.JIRA>
	<JIRA.12729385.1516187624132@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729385.1516187624000.56307.1516187641227@Atlassian.JIRA>

Kabir Khan created WFLY-9685:
--------------------------------

             Summary: JMS Bridge should display statistics about messages that have been processed.
                 Key: WFLY-9685
                 URL: https://issues.jboss.org/browse/WFLY-9685
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 10.0.0.Final
         Environment: JBoss EAP 7
            Reporter: Chen Maoqian
            Assignee: Chen Maoqian


The JMS bridge should show some statistics about messages that have been processed through the bridge for example:
 - number of messages successfully committed
 - number of messages aborted/rollback





--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:14:01 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:14:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9686) Allow to dump Artemis journal
 to file by CLI operation
In-Reply-To: <JIRA.12729386.1516187632000@Atlassian.JIRA>
References: <JIRA.12729386.1516187632000@Atlassian.JIRA>
	<JIRA.12729386.1516187632015@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729386.1516187632000.56314.1516187641457@Atlassian.JIRA>

Kabir Khan created WFLY-9686:
--------------------------------

             Summary: Allow to dump Artemis journal to file by CLI operation
                 Key: WFLY-9686
                 URL: https://issues.jboss.org/browse/WFLY-9686
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 10.0.0.Final
            Reporter: Miroslav Novak
            Assignee: Jeff Mesnil


For debugging and investigation purposes it would useful to have CLI operation which would dump content of Artemis journal directory. 

New CLI operation like {{print-journal-date-content}} would print content of journal to a file. 

It would do the same thing like following Artemis CLI command:
{code}
.../activemq-artemis/artemis-distribution/target/apache-artemis-1.3.0-SNAPSHOT-bin/apache-artemis-1.3.0-SNAPSHOT/bin/artemis data print  --bindings bindings --journal journal --paging paging --large-messages largemessages
{code}

This should work only in Admin only mode as dumping journal in run-time is not possible when data changes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:21:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6660) Allow to dump Artemis journal
 to file by CLI operation
In-Reply-To: <JIRA.12628559.1464605000000@Atlassian.JIRA>
References: <JIRA.12628559.1464605000000@Atlassian.JIRA>
	<JIRA.12628559.1464605000000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628559.1464605000000.56361.1516188060280@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-6660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520029#comment-13520029 ] 

Kabir Khan commented on WFLY-6660:
----------------------------------

[~mnovak] Done

> Allow to dump Artemis journal to file by CLI operation
> ------------------------------------------------------
>
>                 Key: WFLY-6660
>                 URL: https://issues.jboss.org/browse/WFLY-6660
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JMS
>    Affects Versions: 10.0.0.Final
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>         Attachments: journal.txt
>
>
> For debugging and investigation purposes it would useful to have CLI operation which would dump content of Artemis journal directory. 
> New CLI operation like {{print-journal-date-content}} would print content of journal to a file. 
> It would do the same thing like following Artemis CLI command:
> {code}
> .../activemq-artemis/artemis-distribution/target/apache-artemis-1.3.0-SNAPSHOT-bin/apache-artemis-1.3.0-SNAPSHOT/bin/artemis data print  --bindings bindings --journal journal --paging paging --large-messages largemessages
> {code}
> This should work only in Admin only mode as dumping journal in run-time is not possible when data changes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:21:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 17 Jan 2018 06:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2160) Enhance UI in Test
	Scenarios Editor
In-Reply-To: <JIRA.12723168.1512142861000@Atlassian.JIRA>
References: <JIRA.12723168.1512142861000@Atlassian.JIRA>
	<JIRA.12723168.1512142861000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723168.1512142861000.56364.1516188060347@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520030#comment-13520030 ] 

Jozef Marko commented on DROOLS-2160:
-------------------------------------

[~Ibek] [~aglass] [here|https://kie-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/drools-wb-downstream-pullrequests/112/] you should be able to download war with my changes, any comments welcome. Please have a look especially on tow new pages of the Scenario designer.

> Enhance UI in Test Scenarios Editor
> -----------------------------------
>
>                 Key: DROOLS-2160
>                 URL: https://issues.jboss.org/browse/DROOLS-2160
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Test Scenarios Editor
>            Reporter: Ivo Bek
>            Assignee: Jozef Marko
>              Labels: UX
>         Attachments: Screenshot from 2017-12-01 16-38-52.png
>
>
> Test Scenarios editor needs to be polished:
> * Delete Buttons are too small - it would be good to enlarge them.
> * Some other elements doesn't have enough space around them.
> * Please do any other small visual changes which makes sense.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:22:00 2018
From: issues at jboss.org (Ivo Bek (JIRA))
Date: Wed, 17 Jan 2018 06:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2249) Generate Decision Table
 Graph automatically
In-Reply-To: <JIRA.12729393.1516188082000@Atlassian.JIRA>
References: <JIRA.12729393.1516188082000@Atlassian.JIRA>
	<JIRA.12729393.1516188082569@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729393.1516188082000.56369.1516188120373@Atlassian.JIRA>

Ivo Bek created DROOLS-2249:
-------------------------------

             Summary: Generate Decision Table Graph automatically
                 Key: DROOLS-2249
                 URL: https://issues.jboss.org/browse/DROOLS-2249
             Project: Drools
          Issue Type: Feature Request
          Components: decision tables
            Reporter: Ivo Bek
            Assignee: Mario Fusco


We think that the user doesn't need to create multiple decision table graphs in a single project. Instead whenever user creates his/her first decision table, the graph should be generated automatically and should contain all the decision tables available in the project.

When a user opens a decision table, the editor could have a button "Display Linked Tables" which would open the graph.

Then, we could remove the Decision Table Graph from the new Asset list because there would always be just single graph generated automatically and accessible from the asset list and/or Decision Table editor.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:23:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 17 Jan 2018 06:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2249) Generate Decision Table
 Graph automatically
In-Reply-To: <JIRA.12729393.1516188083000@Atlassian.JIRA>
References: <JIRA.12729393.1516188083000@Atlassian.JIRA>
	<JIRA.12729393.1516188083000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729393.1516188083000.56375.1516188180407@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2249:
--------------------------------
    Component/s: Guided Decision Table Editor
                     (was: decision tables)


> Generate Decision Table Graph automatically
> -------------------------------------------
>
>                 Key: DROOLS-2249
>                 URL: https://issues.jboss.org/browse/DROOLS-2249
>             Project: Drools
>          Issue Type: Feature Request
>          Components: Guided Decision Table Editor
>            Reporter: Ivo Bek
>            Assignee: Michael Anstis
>              Labels: codefest
>
> We think that the user doesn't need to create multiple decision table graphs in a single project. Instead whenever user creates his/her first decision table, the graph should be generated automatically and should contain all the decision tables available in the project.
> When a user opens a decision table, the editor could have a button "Display Linked Tables" which would open the graph.
> Then, we could remove the Decision Table Graph from the new Asset list because there would always be just single graph generated automatically and accessible from the asset list and/or Decision Table editor.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:23:00 2018
From: issues at jboss.org (Ivo Bek (JIRA))
Date: Wed, 17 Jan 2018 06:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2249) Generate Decision Table
 Graph automatically
In-Reply-To: <JIRA.12729393.1516188083000@Atlassian.JIRA>
References: <JIRA.12729393.1516188083000@Atlassian.JIRA>
	<JIRA.12729393.1516188083000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729393.1516188083000.56379.1516188180492@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Bek reassigned DROOLS-2249:
-------------------------------

    Assignee: Michael Anstis  (was: Mario Fusco)


> Generate Decision Table Graph automatically
> -------------------------------------------
>
>                 Key: DROOLS-2249
>                 URL: https://issues.jboss.org/browse/DROOLS-2249
>             Project: Drools
>          Issue Type: Feature Request
>          Components: Guided Decision Table Editor
>            Reporter: Ivo Bek
>            Assignee: Michael Anstis
>              Labels: codefest
>
> We think that the user doesn't need to create multiple decision table graphs in a single project. Instead whenever user creates his/her first decision table, the graph should be generated automatically and should contain all the decision tables available in the project.
> When a user opens a decision table, the editor could have a button "Display Linked Tables" which would open the graph.
> Then, we could remove the Decision Table Graph from the new Asset list because there would always be just single graph generated automatically and accessible from the asset list and/or Decision Table editor.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:23:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9687) Apply
 InfiniteOrPositiveValidators to messaging attributes allow valid value -1
In-Reply-To: <JIRA.12729395.1516188130000@Atlassian.JIRA>
References: <JIRA.12729395.1516188130000@Atlassian.JIRA>
	<JIRA.12729395.1516188130944@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729395.1516188130000.56382.1516188180595@Atlassian.JIRA>

Kabir Khan created WFLY-9687:
--------------------------------

             Summary: Apply InfiniteOrPositiveValidators to messaging attributes allow valid value -1
                 Key: WFLY-9687
                 URL: https://issues.jboss.org/browse/WFLY-9687
             Project: WildFly
          Issue Type: Enhancement
          Components: JMS
    Affects Versions: 11.0.0.CR1
            Reporter: Chao Wang
            Assignee: Chao Wang
             Fix For: 12.0.0.Alpha1


There are several attributes defined from ActiveMQ Artemis configuration parameters in ActiveMQClient.java and ActiveMQDefaultConfiguration.java are allowed to take value -1.

As they miss proper InfiniteOrPositiveValidators, they can also take any negative values which is incorrect. 

{noformat}
ActiveMQClient.java
public static final long DEFAULT_CLIENT_FAILURE_CHECK_PERIOD_INVM = -1;
public static final long DEFAULT_CONNECTION_TTL_INVM = -1;
public static final int DEFAULT_CONSUMER_MAX_RATE = -1;
public static final int DEFAULT_CONFIRMATION_WINDOW_SIZE = -1;
public static final int DEFAULT_PRODUCER_MAX_RATE = -1;
public static final int DEFAULT_THREAD_POOL_MAX_SIZE = -1;


ActiveMQDefaultConfiguration.java
private static long DEFAULT_CONNECTION_TTL_OVERRIDE = -1;
private static int DEFAULT_JOURNAL_POOL_FILES = -1;
private static long DEFAULT_CONNECTION_TTL_OVERRIDE = -1;
private static int DEFAULT_JOURNAL_PERF_BLAST_PAGES = -1;
private static long DEFAULT_SERVER_DUMP_INTERVAL = -1;
private static long DEFAULT_MEMORY_MEASURE_INTERVAL = -1;
private static int DEFAULT_BRIDGE_INITIAL_CONNECT_ATTEMPTS = -1;
private static int DEFAULT_BRIDGE_RECONNECT_ATTEMPTS = -1;
private static int DEFAULT_BRIDGE_PRODUCER_WINDOW_SIZE = -1;
private static int DEFAULT_CLUSTER_INITIAL_CONNECT_ATTEMPTS = -1;
private static int DEFAULT_CLUSTER_RECONNECT_ATTEMPTS = -1;
private static int DEFAULT_HAPOLICY_BACKUP_REQUEST_RETRIES = -1;
private static int DEFAULT_GROUPING_HANDLER_GROUP_TIMEOUT = -1;
{noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:24:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9433) Apply
 InfiniteOrPositiveValidators to messaging attributes allow valid value -1
In-Reply-To: <JIRA.12715680.1507706013000@Atlassian.JIRA>
References: <JIRA.12715680.1507706013000@Atlassian.JIRA>
	<JIRA.12715680.1507706013000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12715680.1507706013000.56393.1516188240331@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9433?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520031#comment-13520031 ] 

Kabir Khan commented on WFLY-9433:
----------------------------------

[~mnovak] Done
[~soul2zimate] [~jmesnil] Please adjust the state of the EAP7 issue accordingly

> Apply InfiniteOrPositiveValidators to messaging attributes allow valid value -1
> -------------------------------------------------------------------------------
>
>                 Key: WFLY-9433
>                 URL: https://issues.jboss.org/browse/WFLY-9433
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 11.0.0.CR1
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>             Fix For: 12.0.0.Alpha1
>
>
> There are several attributes defined from ActiveMQ Artemis configuration parameters in ActiveMQClient.java and ActiveMQDefaultConfiguration.java are allowed to take value -1.
> As they miss proper InfiniteOrPositiveValidators, they can also take any negative values which is incorrect. 
> {noformat}
> ActiveMQClient.java
> public static final long DEFAULT_CLIENT_FAILURE_CHECK_PERIOD_INVM = -1;
> public static final long DEFAULT_CONNECTION_TTL_INVM = -1;
> public static final int DEFAULT_CONSUMER_MAX_RATE = -1;
> public static final int DEFAULT_CONFIRMATION_WINDOW_SIZE = -1;
> public static final int DEFAULT_PRODUCER_MAX_RATE = -1;
> public static final int DEFAULT_THREAD_POOL_MAX_SIZE = -1;
> ActiveMQDefaultConfiguration.java
> private static long DEFAULT_CONNECTION_TTL_OVERRIDE = -1;
> private static int DEFAULT_JOURNAL_POOL_FILES = -1;
> private static long DEFAULT_CONNECTION_TTL_OVERRIDE = -1;
> private static int DEFAULT_JOURNAL_PERF_BLAST_PAGES = -1;
> private static long DEFAULT_SERVER_DUMP_INTERVAL = -1;
> private static long DEFAULT_MEMORY_MEASURE_INTERVAL = -1;
> private static int DEFAULT_BRIDGE_INITIAL_CONNECT_ATTEMPTS = -1;
> private static int DEFAULT_BRIDGE_RECONNECT_ATTEMPTS = -1;
> private static int DEFAULT_BRIDGE_PRODUCER_WINDOW_SIZE = -1;
> private static int DEFAULT_CLUSTER_INITIAL_CONNECT_ATTEMPTS = -1;
> private static int DEFAULT_CLUSTER_RECONNECT_ATTEMPTS = -1;
> private static int DEFAULT_HAPOLICY_BACKUP_REQUEST_RETRIES = -1;
> private static int DEFAULT_GROUPING_HANDLER_GROUP_TIMEOUT = -1;
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:24:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 17 Jan 2018 06:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2249) Generate Decision Table
 Graph automatically
In-Reply-To: <JIRA.12729393.1516188083000@Atlassian.JIRA>
References: <JIRA.12729393.1516188083000@Atlassian.JIRA>
	<JIRA.12729393.1516188083000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729393.1516188083000.56398.1516188240523@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2249:
--------------------------------
    Tester: Jozef Marko


> Generate Decision Table Graph automatically
> -------------------------------------------
>
>                 Key: DROOLS-2249
>                 URL: https://issues.jboss.org/browse/DROOLS-2249
>             Project: Drools
>          Issue Type: Feature Request
>          Components: Guided Decision Table Editor
>            Reporter: Ivo Bek
>            Assignee: Michael Anstis
>              Labels: codefest
>
> We think that the user doesn't need to create multiple decision table graphs in a single project. Instead whenever user creates his/her first decision table, the graph should be generated automatically and should contain all the decision tables available in the project.
> When a user opens a decision table, the editor could have a button "Display Linked Tables" which would open the graph.
> Then, we could remove the Decision Table Graph from the new Asset list because there would always be just single graph generated automatically and accessible from the asset list and/or Decision Table editor.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:25:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9688) Messaging - default max
	client threads
In-Reply-To: <JIRA.12729396.1516188241000@Atlassian.JIRA>
References: <JIRA.12729396.1516188241000@Atlassian.JIRA>
	<JIRA.12729396.1516188241672@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729396.1516188241000.56402.1516188300526@Atlassian.JIRA>

Kabir Khan created WFLY-9688:
--------------------------------

             Summary: Messaging - default max client threads
                 Key: WFLY-9688
                 URL: https://issues.jboss.org/browse/WFLY-9688
             Project: WildFly
          Issue Type: Enhancement
          Components: JMS
    Affects Versions: 11.0.0.Final
            Reporter: Martin Styk
            Assignee: Jeff Mesnil


By default, size of client thread pool is configured as 8 * number of CPU cores.

On 1 CPU machine, with default configuration and MDB deployed on server, resource starvation is possible
On one CPU there are by default
* 8 ActiveMQ client threads (8 * CPU count)
* 4 MDB instances (mdb-strict-max-pool = 4 * CPU count)
* 15 JCA RA sessions consuming messages from queue (default value of maxSession)

Consuming of messages by MDB gets stuck because all 8 client threads are awaiting large message completion and there is no other thread to handle other tasks.

{code:title=Client thread waiting for large message completion}
"Thread-7 (ActiveMQ-client-global-threads)" #475 daemon prio=5 os_prio=0
tid=0x000000000590f000 nid=0x7c7a in Object.wait() [0x00007fda43413000]
      java.lang.Thread.State: TIMED_WAITING (on object monitor)
           at java.lang.Object.wait(Native Method)
           at
           org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.waitCompletion(LargeMessageControllerImpl.java:302)
           - locked <0x00000000b0083e88> (a
           org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
           at
           org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl.saveBuffer(LargeMessageControllerImpl.java:276)
           - locked <0x00000000b0083e88> (a
           org.apache.activemq.artemis.core.client.impl.LargeMessageControllerImpl)
           at
           org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkBuffer(ClientLargeMessageImpl.java:159)
           at
           org.apache.activemq.artemis.core.client.impl.ClientLargeMessageImpl.checkCompletion(ClientLargeMessageImpl.java:84)
           at
           org.apache.activemq.artemis.jms.client.ActiveMQMessage.doBeforeReceive(ActiveMQMessage.java:786)
           at
           org.apache.activemq.artemis.jms.client.ActiveMQTextMessage.doBeforeReceive(ActiveMQTextMessage.java:110)
           at
           org.apache.activemq.artemis.ra.inflow.ActiveMQMessageHandler.onMessage(ActiveMQMessageHandler.java:295)
           at
           org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.callOnMessage(ClientConsumerImpl.java:1001)
           at
           org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl.access$400(ClientConsumerImpl.java:49)
           at
           org.apache.activemq.artemis.core.client.impl.ClientConsumerImpl$Runner.run(ClientConsumerImpl.java:1124)
           at
           org.apache.activemq.artemis.utils.OrderedExecutorFactory$OrderedExecutor$ExecutorTask.run(OrderedExecutorFactory.java:122)
           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:748)
{code}


This can be fixed by adjusting default values for these parameters.
In this case, we need more client threads than JCA RA sessions (maxSession). 

To avoid resource starvation, number of client threads must be greater than sum of {{maxSession}} for each MDB deployed on server.
We should check number of client threads required by deployments (MDBs), and at least print warning message that size of client thread pool may be insufficient.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:26:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9689) Use WildFly thread pools in
	Artemis
In-Reply-To: <JIRA.12729397.1516188321000@Atlassian.JIRA>
References: <JIRA.12729397.1516188321000@Atlassian.JIRA>
	<JIRA.12729397.1516188321600@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729397.1516188321000.56416.1516188360295@Atlassian.JIRA>

Kabir Khan created WFLY-9689:
--------------------------------

             Summary: Use WildFly thread pools in Artemis
                 Key: WFLY-9689
                 URL: https://issues.jboss.org/browse/WFLY-9689
             Project: WildFly
          Issue Type: Enhancement
          Components: JMS
    Affects Versions: 10.0.0.CR4
            Reporter: Jeff Mesnil
            Assignee: Jeff Mesnil


Artemis provides a feature to inject its executor and scheduled executor services when a ArtemisServer is created.

WildFly could leverage that to inject these services so that their thread pools are managed by WildFly.
We would have total control on the creation and configuration of these thread pools using the org.boss.as.threads extension.

The messaging-activemq extension would be updated so that a server resource would have new children using resource definitions from the org.boss.as.threads extension to configure their pools.

{noformat}
* server
    * bounded-queue-thread-pool or unbounded-queue-thread-pool -> for executor service
    * scheduled-thread-pool -> for scheduled executor service
{noformat}

Note that this RFE would not impact the Artemis RA that does not provide such executor injection. This will be covered by another JIRA issue.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:27:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5838) Use WildFly thread pools in
	Artemis
In-Reply-To: <JIRA.12596425.1449841361000@Atlassian.JIRA>
References: <JIRA.12596425.1449841361000@Atlassian.JIRA>
	<JIRA.12596425.1449841361000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12596425.1449841361000.56433.1516188420509@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-5838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520033#comment-13520033 ] 

Kabir Khan commented on WFLY-5838:
----------------------------------

[~mnovak] Done


> Use WildFly thread pools in Artemis
> -----------------------------------
>
>                 Key: WFLY-5838
>                 URL: https://issues.jboss.org/browse/WFLY-5838
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 10.0.0.CR4
>            Reporter: Jeff Mesnil
>            Assignee: Jeff Mesnil
>
> Artemis provides a feature to inject its executor and scheduled executor services when a ArtemisServer is created.
> WildFly could leverage that to inject these services so that their thread pools are managed by WildFly.
> We would have total control on the creation and configuration of these thread pools using the org.boss.as.threads extension.
> The messaging-activemq extension would be updated so that a server resource would have new children using resource definitions from the org.boss.as.threads extension to configure their pools.
> {noformat}
> * server
>     * bounded-queue-thread-pool or unbounded-queue-thread-pool -> for executor service
>     * scheduled-thread-pool -> for scheduled executor service
> {noformat}
> Note that this RFE would not impact the Artemis RA that does not provide such executor injection. This will be covered by another JIRA issue.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:27:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 17 Jan 2018 06:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2160) Enhance UI in Test
	Scenarios Editor
In-Reply-To: <JIRA.12723168.1512142861000@Atlassian.JIRA>
References: <JIRA.12723168.1512142861000@Atlassian.JIRA>
	<JIRA.12723168.1512142861000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723168.1512142861000.56436.1516188420579@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2160:
--------------------------------
    Description: 
Test Scenarios editor needs to be polished:

* -Delete Buttons are too small - it would be good to enlarge them.- done with
* Some other elements doesn't have enough space around them.
* Please do any other small visual changes which makes sense.

  was:
Test Scenarios editor needs to be polished:

* Delete Buttons are too small - it would be good to enlarge them.
* Some other elements doesn't have enough space around them.
* Please do any other small visual changes which makes sense.



> Enhance UI in Test Scenarios Editor
> -----------------------------------
>
>                 Key: DROOLS-2160
>                 URL: https://issues.jboss.org/browse/DROOLS-2160
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Test Scenarios Editor
>            Reporter: Ivo Bek
>            Assignee: Jozef Marko
>              Labels: UX
>         Attachments: Screenshot from 2017-12-01 16-38-52.png
>
>
> Test Scenarios editor needs to be polished:
> * -Delete Buttons are too small - it would be good to enlarge them.- done with
> * Some other elements doesn't have enough space around them.
> * Please do any other small visual changes which makes sense.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:27:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9690) Inbound connection
 rebalancing does not allow failover to backup
In-Reply-To: <JIRA.12729399.1516188390000@Atlassian.JIRA>
References: <JIRA.12729399.1516188390000@Atlassian.JIRA>
	<JIRA.12729399.1516188390917@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729399.1516188390000.56440.1516188420718@Atlassian.JIRA>

Kabir Khan created WFLY-9690:
--------------------------------

             Summary: Inbound connection rebalancing does not allow failover to backup
                 Key: WFLY-9690
                 URL: https://issues.jboss.org/browse/WFLY-9690
             Project: WildFly
          Issue Type: Enhancement
          Components: JMS
    Affects Versions: 10.1.0.Final
            Reporter: Miroslav Novak
            Assignee: Justin Bertram
            Priority: Critical


If MDB contains activation config property:
@ActivationConfigProperty(propertyName = "rebalanceConnections", propertyValue = "true")

so rebalancing of inbound connections is enabled then MDB is not able to failover from live to backup if backup is cleanly shutdowned (ctrl-c).

Test scenario:
 - There are 3 EAP 7 servers. 1st has Artemis configured as live and 2nd has Artemis configured as backup server. So servers are in dedicated HA topology with replicated journal. Then there are queues InQueue and OutQueue deployed to live and backup.
 - Start live and backup and then send 2000 messages to InQueue to live server.
 - Start 3rd server which has configured Artemis RA to connect to live server. HA is enabled. 
 - Deploy MDB on 3rd server. MDB consumes messages from InQueue and sends to OutQueue in XA transaction.
 - When MDB is processing messages cleanly shutdown live server. 
 - MDB should failover to backup and process all the messages
 - Receive messages from OutQueue from backup server and check that all messages were received.

Test fails bacause MDB is not able to failover to backup.

Server 3 with MDB is logging:
{code}
15:16:02,975 ERROR [org.apache.activemq.artemis.ra] (NodeDOWN Connection Rebalancer) AMQ154003: Unable to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.apache.activemq.artemis.ra.ActiveMQResourceAdapter at 51f82f98 destination=jms/queue/InQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15): ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:777) [artemis-core-client-1.1.0.redhat-5.jar:1.1.0.redhat-5]
	at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.setup(ActiveMQActivation.java:315)
	at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.reconnect(ActiveMQActivation.java:678)
	at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation$2.run(ActiveMQActivation.java:627)
	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_51]
{code}

If rebalanceConnections=false then test passes.

How to run the test locally:
{code}
git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
cd eap-tests-hornetq/scripts/
git checkout refactoring_modules
groovy -DEAP_VERSION=7.0.0.ER4  PrepareServers7.groovy
export WORKSPACE=$PWD
export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap
export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap
export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap
export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap
cd ../jboss-hornetq-testsuite/
mvn clean test -Dtest=ReplicatedDedicatedFailoverTestWithMdb#testShutdown  -DfailIfNoTests=false  -Deap=7x  | tee log
{code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:28:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7615) Inbound connection
 rebalancing does not allow failover to backup
In-Reply-To: <JIRA.12599336.1452695738000@Atlassian.JIRA>
References: <JIRA.12599336.1452695738000@Atlassian.JIRA>
	<JIRA.12599336.1452695738000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599336.1452695738000.56462.1516188480789@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-7615?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520035#comment-13520035 ] 

Kabir Khan commented on WFLY-7615:
----------------------------------

[~mnovak] Done


> Inbound connection rebalancing does not allow failover to backup
> ----------------------------------------------------------------
>
>                 Key: WFLY-7615
>                 URL: https://issues.jboss.org/browse/WFLY-7615
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 10.1.0.Final
>            Reporter: Miroslav Novak
>            Assignee: Justin Bertram
>            Priority: Critical
>
> If MDB contains activation config property:
> @ActivationConfigProperty(propertyName = "rebalanceConnections", propertyValue = "true")
> so rebalancing of inbound connections is enabled then MDB is not able to failover from live to backup if backup is cleanly shutdowned (ctrl-c).
> Test scenario:
>  - There are 3 EAP 7 servers. 1st has Artemis configured as live and 2nd has Artemis configured as backup server. So servers are in dedicated HA topology with replicated journal. Then there are queues InQueue and OutQueue deployed to live and backup.
>  - Start live and backup and then send 2000 messages to InQueue to live server.
>  - Start 3rd server which has configured Artemis RA to connect to live server. HA is enabled. 
>  - Deploy MDB on 3rd server. MDB consumes messages from InQueue and sends to OutQueue in XA transaction.
>  - When MDB is processing messages cleanly shutdown live server. 
>  - MDB should failover to backup and process all the messages
>  - Receive messages from OutQueue from backup server and check that all messages were received.
> Test fails bacause MDB is not able to failover to backup.
> Server 3 with MDB is logging:
> {code}
> 15:16:02,975 ERROR [org.apache.activemq.artemis.ra] (NodeDOWN Connection Rebalancer) AMQ154003: Unable to reconnect org.apache.activemq.artemis.ra.inflow.ActiveMQActivationSpec(ra=org.apache.activemq.artemis.ra.ActiveMQResourceAdapter at 51f82f98 destination=jms/queue/InQueue destinationType=javax.jms.Queue ack=Auto-acknowledge durable=false clientID=null user=null maxSession=15): ActiveMQNotConnectedException[errorType=NOT_CONNECTED message=AMQ119007: Cannot connect to server(s). Tried with all available servers.]
> 	at org.apache.activemq.artemis.core.client.impl.ServerLocatorImpl.createSessionFactory(ServerLocatorImpl.java:777) [artemis-core-client-1.1.0.redhat-5.jar:1.1.0.redhat-5]
> 	at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.setup(ActiveMQActivation.java:315)
> 	at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation.reconnect(ActiveMQActivation.java:678)
> 	at org.apache.activemq.artemis.ra.inflow.ActiveMQActivation$2.run(ActiveMQActivation.java:627)
> 	at java.lang.Thread.run(Thread.java:745) [rt.jar:1.8.0_51]
> {code}
> If rebalanceConnections=false then test passes.
> How to run the test locally:
> {code}
> git clone git://git.app.eng.bos.redhat.com/jbossqe/eap-tests-hornetq.git
> cd eap-tests-hornetq/scripts/
> git checkout refactoring_modules
> groovy -DEAP_VERSION=7.0.0.ER4  PrepareServers7.groovy
> export WORKSPACE=$PWD
> export JBOSS_HOME_1=$WORKSPACE/server1/jboss-eap
> export JBOSS_HOME_2=$WORKSPACE/server2/jboss-eap
> export JBOSS_HOME_3=$WORKSPACE/server3/jboss-eap
> export JBOSS_HOME_4=$WORKSPACE/server4/jboss-eap
> cd ../jboss-hornetq-testsuite/
> mvn clean test -Dtest=ReplicatedDedicatedFailoverTestWithMdb#testShutdown  -DfailIfNoTests=false  -Deap=7x  | tee log
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:29:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9691) JMS Clients should retry any
 TX transparently (100% transparent failover)
In-Reply-To: <JIRA.12729402.1516188487000@Atlassian.JIRA>
References: <JIRA.12729402.1516188487000@Atlassian.JIRA>
	<JIRA.12729402.1516188487792@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729402.1516188487000.56466.1516188540720@Atlassian.JIRA>

Kabir Khan created WFLY-9691:
--------------------------------

             Summary: JMS Clients should retry any TX transparently (100% transparent failover)
                 Key: WFLY-9691
                 URL: https://issues.jboss.org/browse/WFLY-9691
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 10.0.0.Alpha1
            Reporter: Miroslav Novak
            Assignee: Clebert Suconic


Currently standalone JMS client throws exception (HornetQException or JMSException) to client application code during failover/failback and leaves on application programmer to handle this exception and retry the last operation.

This makes client code complex and developer must spent additional effort to handle those edge cases. This is complicated to achieve especially for consumer with transacted session of client acknowledge.

Goal of this jira is to provide exception free behaviour for standalone JMS clients. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:29:01 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 17 Jan 2018 06:29:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2160) Enhance UI in Test
	Scenarios Editor
In-Reply-To: <JIRA.12723168.1512142861000@Atlassian.JIRA>
References: <JIRA.12723168.1512142861000@Atlassian.JIRA>
	<JIRA.12723168.1512142861000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723168.1512142861000.56475.1516188541240@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2160:
--------------------------------
    Description: 
Test Scenarios editor needs to be polished:

* -Delete Buttons are too small - it would be good to enlarge them.- done with [PR|https://github.com/kiegroup/drools-wb/pull/723]
* Some other elements doesn't have enough space around them.
* Please do any other small visual changes which makes sense.
** -Introduced two new tabs. - resolved by [PR|https://github.com/kiegroup/drools-wb/pull/754]
*** One shows information about fired rules during scenario run
*** Second enables to configure, kie base/session, allowed rules, date and time used in scenario

  was:
Test Scenarios editor needs to be polished:

* -Delete Buttons are too small - it would be good to enlarge them.- done with
* Some other elements doesn't have enough space around them.
* Please do any other small visual changes which makes sense.



> Enhance UI in Test Scenarios Editor
> -----------------------------------
>
>                 Key: DROOLS-2160
>                 URL: https://issues.jboss.org/browse/DROOLS-2160
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Test Scenarios Editor
>            Reporter: Ivo Bek
>            Assignee: Jozef Marko
>              Labels: UX
>         Attachments: Screenshot from 2017-12-01 16-38-52.png
>
>
> Test Scenarios editor needs to be polished:
> * -Delete Buttons are too small - it would be good to enlarge them.- done with [PR|https://github.com/kiegroup/drools-wb/pull/723]
> * Some other elements doesn't have enough space around them.
> * Please do any other small visual changes which makes sense.
> ** -Introduced two new tabs. - resolved by [PR|https://github.com/kiegroup/drools-wb/pull/754]
> *** One shows information about fired rules during scenario run
> *** Second enables to configure, kie base/session, allowed rules, date and time used in scenario



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:29:01 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 17 Jan 2018 06:29:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2160) Enhance UI in Test
	Scenarios Editor
In-Reply-To: <JIRA.12723168.1512142861000@Atlassian.JIRA>
References: <JIRA.12723168.1512142861000@Atlassian.JIRA>
	<JIRA.12723168.1512142861000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723168.1512142861000.56483.1516188541449@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2160:
--------------------------------
    Description: 
Test Scenarios editor needs to be polished:

* -Delete Buttons are too small - it would be good to enlarge them.- done with [PR|https://github.com/kiegroup/drools-wb/pull/723]
* Some other elements doesn't have enough space around them.
* Please do any other small visual changes which makes sense.
** -Introduced two new tabs.- resolved by [PR|https://github.com/kiegroup/drools-wb/pull/754]
*** One shows information about fired rules during scenario run
*** Second enables to configure, kie base/session, allowed rules, date and time used in scenario

  was:
Test Scenarios editor needs to be polished:

* -Delete Buttons are too small - it would be good to enlarge them.- done with [PR|https://github.com/kiegroup/drools-wb/pull/723]
* Some other elements doesn't have enough space around them.
* Please do any other small visual changes which makes sense.
** -Introduced two new tabs. - resolved by [PR|https://github.com/kiegroup/drools-wb/pull/754]
*** One shows information about fired rules during scenario run
*** Second enables to configure, kie base/session, allowed rules, date and time used in scenario



> Enhance UI in Test Scenarios Editor
> -----------------------------------
>
>                 Key: DROOLS-2160
>                 URL: https://issues.jboss.org/browse/DROOLS-2160
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Test Scenarios Editor
>            Reporter: Ivo Bek
>            Assignee: Jozef Marko
>              Labels: UX
>         Attachments: Screenshot from 2017-12-01 16-38-52.png
>
>
> Test Scenarios editor needs to be polished:
> * -Delete Buttons are too small - it would be good to enlarge them.- done with [PR|https://github.com/kiegroup/drools-wb/pull/723]
> * Some other elements doesn't have enough space around them.
> * Please do any other small visual changes which makes sense.
> ** -Introduced two new tabs.- resolved by [PR|https://github.com/kiegroup/drools-wb/pull/754]
> *** One shows information about fired rules during scenario run
> *** Second enables to configure, kie base/session, allowed rules, date and time used in scenario



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:32:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9692) Provide CLI operation which
 returns used journal type - NIOxASYNCIO
In-Reply-To: <JIRA.12729405.1516188686000@Atlassian.JIRA>
References: <JIRA.12729405.1516188686000@Atlassian.JIRA>
	<JIRA.12729405.1516188686951@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729405.1516188686000.56515.1516188720621@Atlassian.JIRA>

Kabir Khan created WFLY-9692:
--------------------------------

             Summary: Provide CLI operation which returns used journal type - NIOxASYNCIO
                 Key: WFLY-9692
                 URL: https://issues.jboss.org/browse/WFLY-9692
             Project: WildFly
          Issue Type: Enhancement
          Components: JMS
    Affects Versions: 10.0.0.Beta2
            Reporter: Miroslav Novak
            Assignee: Jeff Mesnil


There is no way to get information which journal type is used using CLI as attribute journal-type provides only information which journal type is configured but not which one is actually used in runtime because Artemis falls back to NIO journal type if AIO natives are not located. New operation or attribute should be provided.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:33:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9693) If
 message-load-balancing-type is STRICT then redistribution does not work
In-Reply-To: <JIRA.12729406.1516188733000@Atlassian.JIRA>
References: <JIRA.12729406.1516188733000@Atlassian.JIRA>
	<JIRA.12729406.1516188733425@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729406.1516188733000.56525.1516188780454@Atlassian.JIRA>

Kabir Khan created WFLY-9693:
--------------------------------

             Summary: If message-load-balancing-type is STRICT then redistribution does not work
                 Key: WFLY-9693
                 URL: https://issues.jboss.org/browse/WFLY-9693
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 10.1.0.Final
            Reporter: Miroslav Novak
            Assignee: Justin Bertram


If cluster connection is configured with STRICT load-balancing policy like:
{code}<cluster-connection name="my-cluster" discovery-group="dg-group1" retry-interval="1000" connector-name="http-connector" address="jms" message-load-balancing-type="STRICT"/>
{code}

then redistribution is disabled as a side effect.  Message redistribution should be configured only by value for {{redelivery-delay}}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:33:00 2018
From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 06:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3513)
 StringIndexOutOfBoundsException if config file with wrong anme is present
 in 'standalone_xml_history/snapshot' folder
In-Reply-To: <JIRA.12729407.1516188742000@Atlassian.JIRA>
References: <JIRA.12729407.1516188742000@Atlassian.JIRA>
	<JIRA.12729407.1516188742969@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729407.1516188742000.56532.1516188780693@Atlassian.JIRA>

J?rg B?sner created WFCORE-3513:
-----------------------------------

             Summary: StringIndexOutOfBoundsException if config file with wrong anme is present in 'standalone_xml_history/snapshot' folder
                 Key: WFCORE-3513
                 URL: https://issues.jboss.org/browse/WFCORE-3513
             Project: WildFly Core
          Issue Type: Bug
          Components: Server
    Affects Versions: 3.0.8.Final
         Environment: The issue is reproduce able in 'wildfly-11.0.0.Final'
            Reporter: J?rg B?sner
            Assignee: Jason Greene


In case a file not named as _yyyyMMdd-HHmmssSSS{name.xml}_ is present in the _snapshot_ folder, the server start abort with a _StringIndexOutOfBoundsException_.

{{wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final

  JAVA: java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
java.lang.StringIndexOutOfBoundsException: String index out of range: -4
	at java.lang.String.substring(String.java:1931)
	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
	at org.jboss.as.server.Main.main(Main.java:95)
	at org.jboss.modules.Module.run(Module.java:344)
	at org.jboss.modules.Main.main(Main.java:525)
12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
}}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 06:34:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9694) Configure Artemis thread pool
 size without reload
In-Reply-To: <JIRA.12729408.1516188793000@Atlassian.JIRA>
References: <JIRA.12729408.1516188793000@Atlassian.JIRA>
	<JIRA.12729408.1516188793845@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729408.1516188793000.56541.1516188840662@Atlassian.JIRA>

Kabir Khan created WFLY-9694:
--------------------------------

             Summary: Configure Artemis thread pool size without reload
                 Key: WFLY-9694
                 URL: https://issues.jboss.org/browse/WFLY-9694
             Project: WildFly
          Issue Type: Enhancement
          Components: JMS
    Affects Versions: 10.1.0.Final
            Reporter: Martin Styk
            Assignee: Jeff Mesnil


Currently, thread pool size can not be adjusted without server reload. If server runs into performance problem caused by thread pool size, there is no way to adjust thread pool size without termination of all running tasks. Making this configurable "on fly" would prevent this scenario. 

Attribute {{thread-pool-max-size}} in {{/subsystem=messaging-activemq/server=default}} requires server reload.

Size of global client thread pools can be set only before this thread pool is created. Adjusting values of system properties which configure client thread pool size has no effect on running server (with pool already created). 




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:34:00 2018
From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 06:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3513)
 StringIndexOutOfBoundsException if config file with wrong anme is present
 in 'standalone_xml_history/snapshot' folder
In-Reply-To: <JIRA.12729407.1516188743000@Atlassian.JIRA>
References: <JIRA.12729407.1516188743000@Atlassian.JIRA>
	<JIRA.12729407.1516188743000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729407.1516188743000.56547.1516188840844@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

J?rg B?sner updated WFCORE-3513:
--------------------------------
    Description: 
In case a file not named as {{yyyyMMdd-HHmmssSSS{name.xml}}} is present in the _snapshot_ folder, the server start abort with a _StringIndexOutOfBoundsException_.

{{wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final

  JAVA: java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
java.lang.StringIndexOutOfBoundsException: String index out of range: -4
	at java.lang.String.substring(String.java:1931)
	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
	at org.jboss.as.server.Main.main(Main.java:95)
	at org.jboss.modules.Module.run(Module.java:344)
	at org.jboss.modules.Main.main(Main.java:525)
12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
}}

  was:
In case a file not named as _yyyyMMdd-HHmmssSSS{name.xml}_ is present in the _snapshot_ folder, the server start abort with a _StringIndexOutOfBoundsException_.

{{wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final

  JAVA: java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
java.lang.StringIndexOutOfBoundsException: String index out of range: -4
	at java.lang.String.substring(String.java:1931)
	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
	at org.jboss.as.server.Main.main(Main.java:95)
	at org.jboss.modules.Module.run(Module.java:344)
	at org.jboss.modules.Main.main(Main.java:525)
12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
}}



> StringIndexOutOfBoundsException if config file with wrong anme is present in 'standalone_xml_history/snapshot' folder
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3513
>                 URL: https://issues.jboss.org/browse/WFCORE-3513
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 3.0.8.Final
>         Environment: The issue is reproduce able in 'wildfly-11.0.0.Final'
>            Reporter: J?rg B?sner
>            Assignee: Jason Greene
>
> In case a file not named as {{yyyyMMdd-HHmmssSSS{name.xml}}} is present in the _snapshot_ folder, the server start abort with a _StringIndexOutOfBoundsException_.
> {{wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final
>   JAVA: java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
> java.lang.StringIndexOutOfBoundsException: String index out of range: -4
> 	at java.lang.String.substring(String.java:1931)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
> 	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
> 	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
> 	at org.jboss.as.server.Main.main(Main.java:95)
> 	at org.jboss.modules.Module.run(Module.java:344)
> 	at org.jboss.modules.Main.main(Main.java:525)
> 12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> }}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 06:34:01 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:34:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9695) Allow to dump Artemis journal
 to file by CLI operation
In-Reply-To: <JIRA.12729409.1516188825000@Atlassian.JIRA>
References: <JIRA.12729409.1516188825000@Atlassian.JIRA>
	<JIRA.12729409.1516188825884@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729409.1516188825000.56559.1516188841220@Atlassian.JIRA>

Kabir Khan created WFLY-9695:
--------------------------------

             Summary: Allow to dump Artemis journal to file by CLI operation
                 Key: WFLY-9695
                 URL: https://issues.jboss.org/browse/WFLY-9695
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 10.0.0.Final
            Reporter: Miroslav Novak
            Assignee: Jeff Mesnil


For debugging and investigation purposes it would useful to have CLI operation which would dump content of Artemis journal directory. 

New CLI operation like {{print-journal-date-content}} would print content of journal to a file. 

It would do the same thing like following Artemis CLI command:
{code}
.../activemq-artemis/artemis-distribution/target/apache-artemis-1.3.0-SNAPSHOT-bin/apache-artemis-1.3.0-SNAPSHOT/bin/artemis data print  --bindings bindings --journal journal --paging paging --large-messages largemessages
{code}

This should work only in Admin only mode as dumping journal in run-time is not possible when data changes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:34:01 2018
From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 06:34:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3513)
 StringIndexOutOfBoundsException if config file with wrong anme is present
 in 'standalone_xml_history/snapshot' folder
In-Reply-To: <JIRA.12729407.1516188743000@Atlassian.JIRA>
References: <JIRA.12729407.1516188743000@Atlassian.JIRA>
	<JIRA.12729407.1516188743000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729407.1516188743000.56564.1516188841418@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

J?rg B?sner updated WFCORE-3513:
--------------------------------
    Description: 
In case a file not named as yyyyMMdd-HHmmssSSS{name.xml} is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.

wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final

  JAVA: java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
java.lang.StringIndexOutOfBoundsException: String index out of range: -4
	at java.lang.String.substring(String.java:1931)
	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
	at org.jboss.as.server.Main.main(Main.java:95)
	at org.jboss.modules.Module.run(Module.java:344)
	at org.jboss.modules.Main.main(Main.java:525)
12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1

  was:
In case a file not named as {{yyyyMMdd-HHmmssSSS{name.xml}}} is present in the _snapshot_ folder, the server start abort with a _StringIndexOutOfBoundsException_.

{{wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final

  JAVA: java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
java.lang.StringIndexOutOfBoundsException: String index out of range: -4
	at java.lang.String.substring(String.java:1931)
	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
	at org.jboss.as.server.Main.main(Main.java:95)
	at org.jboss.modules.Module.run(Module.java:344)
	at org.jboss.modules.Main.main(Main.java:525)
12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
}}



> StringIndexOutOfBoundsException if config file with wrong anme is present in 'standalone_xml_history/snapshot' folder
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3513
>                 URL: https://issues.jboss.org/browse/WFCORE-3513
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 3.0.8.Final
>         Environment: The issue is reproduce able in 'wildfly-11.0.0.Final'
>            Reporter: J?rg B?sner
>            Assignee: Jason Greene
>
> In case a file not named as yyyyMMdd-HHmmssSSS{name.xml} is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.
> wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final
>   JAVA: java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
> java.lang.StringIndexOutOfBoundsException: String index out of range: -4
> 	at java.lang.String.substring(String.java:1931)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
> 	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
> 	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
> 	at org.jboss.as.server.Main.main(Main.java:95)
> 	at org.jboss.modules.Module.run(Module.java:344)
> 	at org.jboss.modules.Main.main(Main.java:525)
> 12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 06:35:00 2018
From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 06:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3513)
 StringIndexOutOfBoundsException if config file with wrong anme is present
 in 'standalone_xml_history/snapshot' folder
In-Reply-To: <JIRA.12729407.1516188743000@Atlassian.JIRA>
References: <JIRA.12729407.1516188743000@Atlassian.JIRA>
	<JIRA.12729407.1516188743000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729407.1516188743000.56575.1516188900611@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

J?rg B?sner updated WFCORE-3513:
--------------------------------
    Description: 
In case a file not named as yyyyMMdd-HHmmssSSS{name.xml} is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.

{noformat}
wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final

  JAVA: java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
java.lang.StringIndexOutOfBoundsException: String index out of range: -4
	at java.lang.String.substring(String.java:1931)
	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
	at org.jboss.as.server.Main.main(Main.java:95)
	at org.jboss.modules.Module.run(Module.java:344)
	at org.jboss.modules.Main.main(Main.java:525)
12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
{noformat}

  was:
In case a file not named as yyyyMMdd-HHmmssSSS{name.xml} is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.

wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final

  JAVA: java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
java.lang.StringIndexOutOfBoundsException: String index out of range: -4
	at java.lang.String.substring(String.java:1931)
	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
	at org.jboss.as.server.Main.main(Main.java:95)
	at org.jboss.modules.Module.run(Module.java:344)
	at org.jboss.modules.Main.main(Main.java:525)
12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1



> StringIndexOutOfBoundsException if config file with wrong anme is present in 'standalone_xml_history/snapshot' folder
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3513
>                 URL: https://issues.jboss.org/browse/WFCORE-3513
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 3.0.8.Final
>         Environment: The issue is reproduce able in 'wildfly-11.0.0.Final'
>            Reporter: J?rg B?sner
>            Assignee: Jason Greene
>
> In case a file not named as yyyyMMdd-HHmmssSSS{name.xml} is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.
> {noformat}
> wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final
>   JAVA: java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
> java.lang.StringIndexOutOfBoundsException: String index out of range: -4
> 	at java.lang.String.substring(String.java:1931)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
> 	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
> 	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
> 	at org.jboss.as.server.Main.main(Main.java:95)
> 	at org.jboss.modules.Module.run(Module.java:344)
> 	at org.jboss.modules.Main.main(Main.java:525)
> 12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 06:36:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9696) Provide minimalistic profile
 for Artemis backup configuration
In-Reply-To: <JIRA.12729411.1516188901000@Atlassian.JIRA>
References: <JIRA.12729411.1516188901000@Atlassian.JIRA>
	<JIRA.12729411.1516188901743@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729411.1516188901000.56582.1516188960703@Atlassian.JIRA>

Kabir Khan created WFLY-9696:
--------------------------------

             Summary: Provide minimalistic profile for Artemis backup configuration
                 Key: WFLY-9696
                 URL: https://issues.jboss.org/browse/WFLY-9696
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 10.0.0.Final
            Reporter: Miroslav Novak
            Assignee: Jeff Mesnil


If Artemis is configured as dedicated backup, no deployments like MDB,EJB,Servlets should be deployed to it. It should serve to its purpose which is to wait for Wildfly 10 with Artemis configured as live to fail.

We should provide minimalistic configuration for Wildfly serving purely as Artemis backup server.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:36:01 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 06:36:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9697) Provide minimalistic profile
 for Artemis backup configuration
In-Reply-To: <JIRA.12729413.1516188912000@Atlassian.JIRA>
References: <JIRA.12729413.1516188912000@Atlassian.JIRA>
	<JIRA.12729413.1516188912476@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729413.1516188912000.56591.1516188961617@Atlassian.JIRA>

Kabir Khan created WFLY-9697:
--------------------------------

             Summary: Provide minimalistic profile for Artemis backup configuration
                 Key: WFLY-9697
                 URL: https://issues.jboss.org/browse/WFLY-9697
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 10.0.0.Final
            Reporter: Miroslav Novak
            Assignee: Jeff Mesnil


If Artemis is configured as dedicated backup, no deployments like MDB,EJB,Servlets should be deployed to it. It should serve to its purpose which is to wait for Wildfly 10 with Artemis configured as live to fail.

We should provide minimalistic configuration for Wildfly serving purely as Artemis backup server.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:37:00 2018
From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 06:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3513)
 StringIndexOutOfBoundsException if config file with wrong anme is present
 in 'standalone_xml_history/snapshot' folder
In-Reply-To: <JIRA.12729407.1516188743000@Atlassian.JIRA>
References: <JIRA.12729407.1516188743000@Atlassian.JIRA>
	<JIRA.12729407.1516188743000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729407.1516188743000.56600.1516189020193@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

J?rg B?sner updated WFCORE-3513:
--------------------------------
    Description: 
In case a file not named as *yyyyMMdd-HHmmssSSSname.xml* is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.

{noformat}
wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final

  JAVA: java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
java.lang.StringIndexOutOfBoundsException: String index out of range: -4
	at java.lang.String.substring(String.java:1931)
	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
	at org.jboss.as.server.Main.main(Main.java:95)
	at org.jboss.modules.Module.run(Module.java:344)
	at org.jboss.modules.Main.main(Main.java:525)
12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
{noformat}

  was:
In case a file not named as yyyyMMdd-HHmmssSSS{name.xml} is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.

{noformat}
wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final

  JAVA: java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
java.lang.StringIndexOutOfBoundsException: String index out of range: -4
	at java.lang.String.substring(String.java:1931)
	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
	at org.jboss.as.server.Main.main(Main.java:95)
	at org.jboss.modules.Module.run(Module.java:344)
	at org.jboss.modules.Main.main(Main.java:525)
12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
{noformat}



> StringIndexOutOfBoundsException if config file with wrong anme is present in 'standalone_xml_history/snapshot' folder
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3513
>                 URL: https://issues.jboss.org/browse/WFCORE-3513
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 3.0.8.Final
>         Environment: The issue is reproduce able in 'wildfly-11.0.0.Final'
>            Reporter: J?rg B?sner
>            Assignee: Jason Greene
>
> In case a file not named as *yyyyMMdd-HHmmssSSSname.xml* is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.
> {noformat}
> wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final
>   JAVA: java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
> java.lang.StringIndexOutOfBoundsException: String index out of range: -4
> 	at java.lang.String.substring(String.java:1931)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
> 	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
> 	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
> 	at org.jboss.as.server.Main.main(Main.java:95)
> 	at org.jboss.modules.Module.run(Module.java:344)
> 	at org.jboss.modules.Main.main(Main.java:525)
> 12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 06:37:00 2018
From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 06:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3513)
 StringIndexOutOfBoundsException if config file with wrong anme is present
 in 'standalone_xml_history/snapshot' folder
In-Reply-To: <JIRA.12729407.1516188743000@Atlassian.JIRA>
References: <JIRA.12729407.1516188743000@Atlassian.JIRA>
	<JIRA.12729407.1516188743000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729407.1516188743000.56603.1516189020331@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

J?rg B?sner updated WFCORE-3513:
--------------------------------
    Workaround Description: File names in the _snapshot_ folder must start with the pattern *yyyyMMdd-HHmmssSSS*.  (was: File names in the _snapshot_ folder must start with the pattern 'yyyyMMdd-HHmmssSSS'.)


> StringIndexOutOfBoundsException if config file with wrong anme is present in 'standalone_xml_history/snapshot' folder
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3513
>                 URL: https://issues.jboss.org/browse/WFCORE-3513
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 3.0.8.Final
>         Environment: The issue is reproduce able in 'wildfly-11.0.0.Final'
>            Reporter: J?rg B?sner
>            Assignee: Jason Greene
>
> In case a file not named as *yyyyMMdd-HHmmssSSSname.xml* is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.
> {noformat}
> wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final
>   JAVA: java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
> java.lang.StringIndexOutOfBoundsException: String index out of range: -4
> 	at java.lang.String.substring(String.java:1931)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
> 	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
> 	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
> 	at org.jboss.as.server.Main.main(Main.java:95)
> 	at org.jboss.modules.Module.run(Module.java:344)
> 	at org.jboss.modules.Main.main(Main.java:525)
> 12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 06:39:00 2018
From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 06:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3514) [GSS](7.1.z)
 StringIndexOutOfBoundsException if config file with wrong anme is present
 in 'standalone_xml_history/snapshot' folder
In-Reply-To: <JIRA.12729415.1516189093000@Atlassian.JIRA>
References: <JIRA.12729415.1516189093000@Atlassian.JIRA>
	<JIRA.12729415.1516189093900@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729415.1516189093000.56606.1516189140370@Atlassian.JIRA>

J?rg B?sner created WFCORE-3514:
-----------------------------------

             Summary: [GSS](7.1.z) StringIndexOutOfBoundsException if config file with wrong anme is present in 'standalone_xml_history/snapshot' folder
                 Key: WFCORE-3514
                 URL: https://issues.jboss.org/browse/WFCORE-3514
             Project: WildFly Core
          Issue Type: Bug
          Components: Server
    Affects Versions: 3.0.8.Final
         Environment: The issue is reproduce able in 'wildfly-11.0.0.Final'
            Reporter: J?rg B?sner
            Assignee: Jason Greene


In case a file not named as *yyyyMMdd-HHmmssSSSname.xml* is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.

{noformat}
wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
=========================================================================

  JBoss Bootstrap Environment

  JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final

  JAVA: java

  JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true

=========================================================================

12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
java.lang.StringIndexOutOfBoundsException: String index out of range: -4
	at java.lang.String.substring(String.java:1931)
	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
	at org.jboss.as.server.Main.main(Main.java:95)
	at org.jboss.modules.Module.run(Module.java:344)
	at org.jboss.modules.Main.main(Main.java:525)
12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
{noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 06:41:01 2018
From: issues at jboss.org (=?UTF-8?Q?J=C3=B6rg_B=C3=A4sner_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 06:41:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3513)
 StringIndexOutOfBoundsException if config file with wrong name is present
 in 'standalone_xml_history/snapshot' folder
In-Reply-To: <JIRA.12729407.1516188743000@Atlassian.JIRA>
References: <JIRA.12729407.1516188743000@Atlassian.JIRA>
	<JIRA.12729407.1516188743000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729407.1516188743000.56643.1516189261624@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

J?rg B?sner updated WFCORE-3513:
--------------------------------
    Summary: StringIndexOutOfBoundsException if config file with wrong name is present in 'standalone_xml_history/snapshot' folder  (was: StringIndexOutOfBoundsException if config file with wrong anme is present in 'standalone_xml_history/snapshot' folder)


> StringIndexOutOfBoundsException if config file with wrong name is present in 'standalone_xml_history/snapshot' folder
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3513
>                 URL: https://issues.jboss.org/browse/WFCORE-3513
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 3.0.8.Final
>         Environment: The issue is reproduce able in 'wildfly-11.0.0.Final'
>            Reporter: J?rg B?sner
>            Assignee: Jason Greene
>
> In case a file not named as *yyyyMMdd-HHmmssSSSname.xml* is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.
> {noformat}
> wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final
>   JAVA: java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
> java.lang.StringIndexOutOfBoundsException: String index out of range: -4
> 	at java.lang.String.substring(String.java:1931)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
> 	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
> 	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
> 	at org.jboss.as.server.Main.main(Main.java:95)
> 	at org.jboss.modules.Module.run(Module.java:344)
> 	at org.jboss.modules.Main.main(Main.java:525)
> 12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 06:49:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Wed, 17 Jan 2018 06:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2249) Generate Decision Table
 Graph automatically
In-Reply-To: <JIRA.12729393.1516188083000@Atlassian.JIRA>
References: <JIRA.12729393.1516188083000@Atlassian.JIRA>
	<JIRA.12729393.1516188083000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729393.1516188083000.56683.1516189740354@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2249?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2249:
--------------------------------
    Labels: UX codefest  (was: codefest)


> Generate Decision Table Graph automatically
> -------------------------------------------
>
>                 Key: DROOLS-2249
>                 URL: https://issues.jboss.org/browse/DROOLS-2249
>             Project: Drools
>          Issue Type: Feature Request
>          Components: Guided Decision Table Editor
>            Reporter: Ivo Bek
>            Assignee: Michael Anstis
>              Labels: UX, codefest
>
> We think that the user doesn't need to create multiple decision table graphs in a single project. Instead whenever user creates his/her first decision table, the graph should be generated automatically and should contain all the decision tables available in the project.
> When a user opens a decision table, the editor could have a button "Display Linked Tables" which would open the graph.
> Then, we could remove the Decision Table Graph from the new Asset list because there would always be just single graph generated automatically and accessible from the asset list and/or Decision Table editor.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 06:55:00 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Wed, 17 Jan 2018 06:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3513)
 StringIndexOutOfBoundsException if config file with wrong name is present
 in 'standalone_xml_history/snapshot' folder
In-Reply-To: <JIRA.12729407.1516188743000@Atlassian.JIRA>
References: <JIRA.12729407.1516188743000@Atlassian.JIRA>
	<JIRA.12729407.1516188743000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729407.1516188743000.56739.1516190100508@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges reassigned WFCORE-3513:
------------------------------------

    Assignee: Yeray Borges  (was: Jason Greene)


> StringIndexOutOfBoundsException if config file with wrong name is present in 'standalone_xml_history/snapshot' folder
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3513
>                 URL: https://issues.jboss.org/browse/WFCORE-3513
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 3.0.8.Final
>         Environment: The issue is reproduce able in 'wildfly-11.0.0.Final'
>            Reporter: J?rg B?sner
>            Assignee: Yeray Borges
>
> In case a file not named as *yyyyMMdd-HHmmssSSSname.xml* is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.
> {noformat}
> wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final
>   JAVA: java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
> java.lang.StringIndexOutOfBoundsException: String index out of range: -4
> 	at java.lang.String.substring(String.java:1931)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
> 	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
> 	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
> 	at org.jboss.as.server.Main.main(Main.java:95)
> 	at org.jboss.modules.Module.run(Module.java:344)
> 	at org.jboss.modules.Main.main(Main.java:525)
> 12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 07:12:01 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 17 Jan 2018 07:12:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2248) Disable validation and
 verification for a specific decision table
In-Reply-To: <JIRA.12729378.1516186554000@Atlassian.JIRA>
References: <JIRA.12729378.1516186554000@Atlassian.JIRA>
	<JIRA.12729378.1516186554000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729378.1516186554000.56822.1516191121475@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis reassigned DROOLS-2248:
--------------------------------------

    Assignee: Toni Rikkola  (was: Mario Fusco)


> Disable validation and verification for a specific decision table
> -----------------------------------------------------------------
>
>                 Key: DROOLS-2248
>                 URL: https://issues.jboss.org/browse/DROOLS-2248
>             Project: Drools
>          Issue Type: Enhancement
>          Components: decision tables
>            Reporter: Ivo Bek
>            Assignee: Toni Rikkola
>              Labels: codefest
>
> Currently it seems it's not possible to disable verification and validation for specific decision table.
> Administrator can only enable/disable verification and validation globally for the whole workbench but usually business admins need to disable verification and validation for decision tables which are complex / contain huge amount of rows and similarly.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 07:28:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 07:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9698) Provide minimalistic profile
 for Artemis backup configuration
In-Reply-To: <JIRA.12729440.1516192051000@Atlassian.JIRA>
References: <JIRA.12729440.1516192051000@Atlassian.JIRA>
	<JIRA.12729440.1516192051458@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729440.1516192051000.56947.1516192080989@Atlassian.JIRA>

Kabir Khan created WFLY-9698:
--------------------------------

             Summary: Provide minimalistic profile for Artemis backup configuration
                 Key: WFLY-9698
                 URL: https://issues.jboss.org/browse/WFLY-9698
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 10.0.0.Final
            Reporter: Miroslav Novak
            Assignee: Jeff Mesnil


If Artemis is configured as dedicated backup, no deployments like MDB,EJB,Servlets should be deployed to it. It should serve to its purpose which is to wait for Wildfly 10 with Artemis configured as live to fail.

We should provide minimalistic configuration for Wildfly serving purely as Artemis backup server.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 07:29:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 07:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9698) Provide minimalistic profile
 for Artemis backup configuration
In-Reply-To: <JIRA.12729440.1516192051000@Atlassian.JIRA>
References: <JIRA.12729440.1516192051000@Atlassian.JIRA>
	<JIRA.12729440.1516192051000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729440.1516192051000.56964.1516192140634@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9698?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan deleted WFLY-9698:
-----------------------------


> Provide minimalistic profile for Artemis backup configuration
> -------------------------------------------------------------
>
>                 Key: WFLY-9698
>                 URL: https://issues.jboss.org/browse/WFLY-9698
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>
> If Artemis is configured as dedicated backup, no deployments like MDB,EJB,Servlets should be deployed to it. It should serve to its purpose which is to wait for Wildfly 10 with Artemis configured as live to fail.
> We should provide minimalistic configuration for Wildfly serving purely as Artemis backup server.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 07:29:01 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 07:29:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9696) Provide minimalistic profile
 for Artemis backup configuration
In-Reply-To: <JIRA.12729411.1516188902000@Atlassian.JIRA>
References: <JIRA.12729411.1516188902000@Atlassian.JIRA>
	<JIRA.12729411.1516188902000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729411.1516188902000.56972.1516192141065@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9696?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan deleted WFLY-9696:
-----------------------------


> Provide minimalistic profile for Artemis backup configuration
> -------------------------------------------------------------
>
>                 Key: WFLY-9696
>                 URL: https://issues.jboss.org/browse/WFLY-9696
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>
> If Artemis is configured as dedicated backup, no deployments like MDB,EJB,Servlets should be deployed to it. It should serve to its purpose which is to wait for Wildfly 10 with Artemis configured as live to fail.
> We should provide minimalistic configuration for Wildfly serving purely as Artemis backup server.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 07:30:01 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 07:30:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9699) Add attribute to model which
 will indicate that backup is synchronized with live server
In-Reply-To: <JIRA.12729443.1516192146000@Atlassian.JIRA>
References: <JIRA.12729443.1516192146000@Atlassian.JIRA>
	<JIRA.12729443.1516192146091@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729443.1516192146000.56989.1516192201128@Atlassian.JIRA>

Kabir Khan created WFLY-9699:
--------------------------------

             Summary: Add attribute to model which will indicate that backup is synchronized with live server 
                 Key: WFLY-9699
                 URL: https://issues.jboss.org/browse/WFLY-9699
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 10.0.0.Final
            Reporter: Miroslav Novak
            Assignee: Jeff Mesnil
            Priority: Critical


If HA is configured with replicated journal then it takes some time to backup to synchronize with live server.  Once backup is in sync with live then following information appears in server.log:
{code}
13:20:00,739 INFO  [org.apache.activemq.artemis.core.server] (Thread-3 (ActiveMQ-client-netty-threads-457000966)) AMQ221024: Backup server ActiveMQServerImpl::serverUUID=bc015b34-fd73-11e5-80ca-1b35f669abb8 is synchronized with live-server.
13:20:01,500 INFO  [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2 at 41f992ab-83559664)) AMQ221031: backup announced
{code}

Reading server logs to see whether backup is in sync is not convinient and user friendly way. Could we add this information to model so it can be detected through CLI command?

New attribute with name {{synchronized-with-live}} should be added to {{/subsystem=messaging-activemq/server=default/ha-policy=replication-slave}}

This information can be gathered by calling: {{SharedNothingBackupActivation.isRemoteBackupUpToDate()}}

Additionally we should provide this attribute also in replicated live server in: {{/subsystem=messaging-activemq/server=default/ha-policy=replication-master}} as Administrator might want to know whether live can be shutdown.





--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 07:30:01 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 07:30:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9700) Add attribute to model which
 will indicate that backup is synchronized with live server
In-Reply-To: <JIRA.12729444.1516192156000@Atlassian.JIRA>
References: <JIRA.12729444.1516192156000@Atlassian.JIRA>
	<JIRA.12729444.1516192156054@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729444.1516192156000.56995.1516192201533@Atlassian.JIRA>

Kabir Khan created WFLY-9700:
--------------------------------

             Summary: Add attribute to model which will indicate that backup is synchronized with live server 
                 Key: WFLY-9700
                 URL: https://issues.jboss.org/browse/WFLY-9700
             Project: WildFly
          Issue Type: Feature Request
          Components: JMS
    Affects Versions: 10.0.0.Final
            Reporter: Miroslav Novak
            Assignee: Jeff Mesnil
            Priority: Critical


If HA is configured with replicated journal then it takes some time to backup to synchronize with live server.  Once backup is in sync with live then following information appears in server.log:
{code}
13:20:00,739 INFO  [org.apache.activemq.artemis.core.server] (Thread-3 (ActiveMQ-client-netty-threads-457000966)) AMQ221024: Backup server ActiveMQServerImpl::serverUUID=bc015b34-fd73-11e5-80ca-1b35f669abb8 is synchronized with live-server.
13:20:01,500 INFO  [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2 at 41f992ab-83559664)) AMQ221031: backup announced
{code}

Reading server logs to see whether backup is in sync is not convinient and user friendly way. Could we add this information to model so it can be detected through CLI command?

New attribute with name {{synchronized-with-live}} should be added to {{/subsystem=messaging-activemq/server=default/ha-policy=replication-slave}}

This information can be gathered by calling: {{SharedNothingBackupActivation.isRemoteBackupUpToDate()}}

Additionally we should provide this attribute also in replicated live server in: {{/subsystem=messaging-activemq/server=default/ha-policy=replication-master}} as Administrator might want to know whether live can be shutdown.





--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 07:30:02 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Wed, 17 Jan 2018 07:30:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9700) Add attribute to model which
 will indicate that backup is synchronized with live server
In-Reply-To: <JIRA.12729444.1516192156000@Atlassian.JIRA>
References: <JIRA.12729444.1516192156000@Atlassian.JIRA>
	<JIRA.12729444.1516192156000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729444.1516192156000.57013.1516192202926@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9700?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kabir Khan deleted WFLY-9700:
-----------------------------


> Add attribute to model which will indicate that backup is synchronized with live server 
> ----------------------------------------------------------------------------------------
>
>                 Key: WFLY-9700
>                 URL: https://issues.jboss.org/browse/WFLY-9700
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Miroslav Novak
>            Assignee: Jeff Mesnil
>            Priority: Critical
>
> If HA is configured with replicated journal then it takes some time to backup to synchronize with live server.  Once backup is in sync with live then following information appears in server.log:
> {code}
> 13:20:00,739 INFO  [org.apache.activemq.artemis.core.server] (Thread-3 (ActiveMQ-client-netty-threads-457000966)) AMQ221024: Backup server ActiveMQServerImpl::serverUUID=bc015b34-fd73-11e5-80ca-1b35f669abb8 is synchronized with live-server.
> 13:20:01,500 INFO  [org.apache.activemq.artemis.core.server] (Thread-2 (ActiveMQ-server-org.apache.activemq.artemis.core.server.impl.ActiveMQServerImpl$2 at 41f992ab-83559664)) AMQ221031: backup announced
> {code}
> Reading server logs to see whether backup is in sync is not convinient and user friendly way. Could we add this information to model so it can be detected through CLI command?
> New attribute with name {{synchronized-with-live}} should be added to {{/subsystem=messaging-activemq/server=default/ha-policy=replication-slave}}
> This information can be gathered by calling: {{SharedNothingBackupActivation.isRemoteBackupUpToDate()}}
> Additionally we should provide this attribute also in replicated live server in: {{/subsystem=messaging-activemq/server=default/ha-policy=replication-master}} as Administrator might want to know whether live can be shutdown.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 07:57:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 17 Jan 2018 07:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2250) Align Engine hints in
 Decision Table column wizard with BAPL-708
In-Reply-To: <JIRA.12729471.1516193792000@Atlassian.JIRA>
References: <JIRA.12729471.1516193792000@Atlassian.JIRA>
	<JIRA.12729471.1516193792856@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729471.1516193792000.57157.1516193820600@Atlassian.JIRA>

Jozef Marko created DROOLS-2250:
-----------------------------------

             Summary: Align Engine hints in Decision Table column wizard with BAPL-708
                 Key: DROOLS-2250
                 URL: https://issues.jboss.org/browse/DROOLS-2250
             Project: Drools
          Issue Type: Task
          Components: Guided Decision Table Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis
         Attachments: Screenshot from 2018-01-17 13-49-51.png, Screenshot from 2018-01-17 13-50-37.png

Due to the BAPL-708 and the [doc|https://docs.google.com/spreadsheets/d/1kmK92hY3JJp7gZTvLzd0CawaZzvI2MYYv2uaLaQcMJc/edit#gid=1999150540] with new product terminology, we should update the Engine hint shown in the attached screenshots. We should use *decision engine* or *process / engine* instad of *inference engine*, *rules engine* etc.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 07:58:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 17 Jan 2018 07:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2250) Align Engine hints in
 Decision Table column wizard with BAPL-708
In-Reply-To: <JIRA.12729471.1516193793000@Atlassian.JIRA>
References: <JIRA.12729471.1516193793000@Atlassian.JIRA>
	<JIRA.12729471.1516193793000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729471.1516193793000.57166.1516193880369@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2250:
--------------------------------
    Tester: Jozef Marko


> Align Engine hints in Decision Table column wizard with BAPL-708
> ----------------------------------------------------------------
>
>                 Key: DROOLS-2250
>                 URL: https://issues.jboss.org/browse/DROOLS-2250
>             Project: Drools
>          Issue Type: Task
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: Screenshot from 2018-01-17 13-49-51.png, Screenshot from 2018-01-17 13-50-37.png
>
>
> Due to the BAPL-708 and the [doc|https://docs.google.com/spreadsheets/d/1kmK92hY3JJp7gZTvLzd0CawaZzvI2MYYv2uaLaQcMJc/edit#gid=1999150540] with new product terminology, we should update the Engine hint shown in the attached screenshots. We should use *decision engine* or *process / engine* instad of *inference engine*, *rules engine* etc.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 08:24:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 17 Jan 2018 08:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2251) Align Test Scenario KIE
 configuration with BAPL-708
In-Reply-To: <JIRA.12729482.1516195435000@Atlassian.JIRA>
References: <JIRA.12729482.1516195435000@Atlassian.JIRA>
	<JIRA.12729482.1516195435930@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729482.1516195435000.57308.1516195440462@Atlassian.JIRA>

Jozef Marko created DROOLS-2251:
-----------------------------------

             Summary: Align Test Scenario KIE configuration with BAPL-708
                 Key: DROOLS-2251
                 URL: https://issues.jboss.org/browse/DROOLS-2251
             Project: Drools
          Issue Type: Task
          Components: Test Scenarios Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Toni Rikkola


Test Scenario designer KIE configuration part should be updated to use terms *KIE base* and *KIE session* instead of the *knowledge base* and *knowledge session*.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 08:36:00 2018
From: issues at jboss.org (=?UTF-8?Q?Richard_Jan=C3=ADk_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 08:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9701) Dwm tests intermittently
 failing on Solaris
In-Reply-To: <JIRA.12729487.1516196115000@Atlassian.JIRA>
References: <JIRA.12729487.1516196115000@Atlassian.JIRA>
	<JIRA.12729487.1516196115491@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729487.1516196115000.57411.1516196160369@Atlassian.JIRA>

Richard Jan?k created WFLY-9701:
-----------------------------------

             Summary: Dwm tests intermittently failing on Solaris
                 Key: WFLY-9701
                 URL: https://issues.jboss.org/browse/WFLY-9701
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 12.0.0.Alpha1
            Reporter: Richard Jan?k
            Assignee: Richard Jan?k


I've been alerted to Dwm tests sometimes failing on Solaris. The TeamCity CI shows that this happens with PRs with unrelated fixes and happens in ~4% of runs.

Sample fail: https://ci.wildfly.org/viewLog.html?buildId=84840&tab=buildResultsDiv&buildTypeId=WF_MasterSolaris



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 08:36:01 2018
From: issues at jboss.org (=?UTF-8?Q?Richard_Jan=C3=ADk_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 08:36:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9122) Containers for distributed
 work manager tests always started in testsuite/integration/manualmode
In-Reply-To: <JIRA.12703252.1500880022000@Atlassian.JIRA>
References: <JIRA.12703252.1500880022000@Atlassian.JIRA>
	<JIRA.12703252.1500880022000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12703252.1500880022000.57422.1516196161532@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9122?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Jan?k reassigned WFLY-9122:
-----------------------------------

    Assignee: Richard Jan?k  (was: Yeray Borges)


> Containers for distributed work manager tests always started in testsuite/integration/manualmode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9122
>                 URL: https://issues.jboss.org/browse/WFLY-9122
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Richard Jan?k
>
> The Arquillian containers {{dwm-container-0}} and {{dwm-container-1}} are always started in the manualmode testsuite module. 
> It can lead to port conflicts when another test wants to use its own server configuration with port offset 200 or 300. It also adds additional time to execute single test ({{mvn test -Dtest=MyTestCase}}), because these 2 containers has to be started first.
> The {{dwm-*}} containers are used by distributed work manager tests in package {{org.jboss.as.test.manualmode.jca.workmanager.distributed}}.
> CC [~rjanik]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 08:36:01 2018
From: issues at jboss.org (=?UTF-8?Q?Richard_Jan=C3=ADk_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 08:36:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9122) Containers for distributed
 work manager tests always started in testsuite/integration/manualmode
In-Reply-To: <JIRA.12703252.1500880022000@Atlassian.JIRA>
References: <JIRA.12703252.1500880022000@Atlassian.JIRA>
	<JIRA.12703252.1500880022000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12703252.1500880022000.57425.1516196161860@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9122?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520107#comment-13520107 ] 

Richard Jan?k commented on WFLY-9122:
-------------------------------------

[~yersan] Since this is my fault, I'd like to take this one. Currently working on it as well as on WFLY-9701.

> Containers for distributed work manager tests always started in testsuite/integration/manualmode
> ------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9122
>                 URL: https://issues.jboss.org/browse/WFLY-9122
>             Project: WildFly
>          Issue Type: Bug
>          Components: Test Suite
>            Reporter: Josef Cacek
>            Assignee: Richard Jan?k
>
> The Arquillian containers {{dwm-container-0}} and {{dwm-container-1}} are always started in the manualmode testsuite module. 
> It can lead to port conflicts when another test wants to use its own server configuration with port offset 200 or 300. It also adds additional time to execute single test ({{mvn test -Dtest=MyTestCase}}), because these 2 containers has to be started first.
> The {{dwm-*}} containers are used by distributed work manager tests in package {{org.jboss.as.test.manualmode.jca.workmanager.distributed}}.
> CC [~rjanik]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 08:54:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 08:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3515) Tests for enhanced CLI to
 support Aesh Commands
In-Reply-To: <JIRA.12729495.1516197231000@Atlassian.JIRA>
References: <JIRA.12729495.1516197231000@Atlassian.JIRA>
	<JIRA.12729495.1516197231322@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729495.1516197231000.57641.1516197240310@Atlassian.JIRA>

Marek Kopeck? created WFCORE-3515:
-------------------------------------

             Summary: Tests for enhanced CLI to support Aesh Commands
                 Key: WFCORE-3515
                 URL: https://issues.jboss.org/browse/WFCORE-3515
             Project: WildFly Core
          Issue Type: Task
            Reporter: Marek Kopeck?


Tests for enhanced CLI to support Aesh Commands



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 08:54:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 08:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3515) Tests for enhanced CLI to
 support Aesh Commands
In-Reply-To: <JIRA.12729495.1516197231000@Atlassian.JIRA>
References: <JIRA.12729495.1516197231000@Atlassian.JIRA>
	<JIRA.12729495.1516197231000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729495.1516197231000.57647.1516197240563@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? reassigned WFCORE-3515:
-------------------------------------

    Assignee: Marek Kopeck?


> Tests for enhanced CLI to support Aesh Commands
> -----------------------------------------------
>
>                 Key: WFCORE-3515
>                 URL: https://issues.jboss.org/browse/WFCORE-3515
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Tests for enhanced CLI to support Aesh Commands



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 08:57:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 17 Jan 2018 08:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3487) ValueTypeCompletionTestCase
 test renaming
In-Reply-To: <JIRA.12726363.1514985022000@Atlassian.JIRA>
References: <JIRA.12726363.1514985022000@Atlassian.JIRA>
	<JIRA.12726363.1514985022000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726363.1514985022000.57709.1516197420230@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-3487:
----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/3017


> ValueTypeCompletionTestCase test renaming
> -----------------------------------------
>
>                 Key: WFCORE-3487
>                 URL: https://issues.jboss.org/browse/WFCORE-3487
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Miroslav Novak
>            Assignee: Miroslav Novak
>            Priority: Optional
>
> ValueTypeCompletionTestCase contains test names which does not imply what the test is doing. Rename those tests.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 09:05:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 17 Jan 2018 09:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9702) SSO Integration for
 Programmatic Authentication
In-Reply-To: <JIRA.12729496.1516197854000@Atlassian.JIRA>
References: <JIRA.12729496.1516197854000@Atlassian.JIRA>
	<JIRA.12729496.1516197854311@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729496.1516197854000.57759.1516197900488@Atlassian.JIRA>

Darran Lofthouse created WFLY-9702:
--------------------------------------

             Summary: SSO Integration for Programmatic Authentication
                 Key: WFLY-9702
                 URL: https://issues.jboss.org/browse/WFLY-9702
             Project: WildFly
          Issue Type: Bug
          Components: Clustering, Security, Web (Undertow)
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 12.0.0.Alpha1


At the moment the SSO integration only fully covers authentication mechanisms as they can be wrapped, we need to revisit for programmatic authentication.

In this scenario we don't have either a wrapped mechanism or a CallbackHandler.

Couple of options: -

* Can we get away with pushing in some form of IdentityCache factory the mechs can obtain from the request?  This may miss the additional notifications the SSO impl depends on.
* Can we also better support listening for the notifications without the need for wrappers?  This could cover both mechs and programmatic authentication?
* Instead do we make the programmatic authenticator pluggable, i.e. push in an SSO aware impl, it can choose how to handle it's own caching and also doesn't need the notifications as it is in control of that stage of the process.
* 





--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 09:05:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 17 Jan 2018 09:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9702) SSO Integration for
 Programmatic Authentication
In-Reply-To: <JIRA.12729496.1516197854000@Atlassian.JIRA>
References: <JIRA.12729496.1516197854000@Atlassian.JIRA>
	<JIRA.12729496.1516197854000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729496.1516197854000.57776.1516197900984@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9702?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-9702:
-----------------------------------
    Priority: Critical  (was: Major)


> SSO Integration for Programmatic Authentication
> -----------------------------------------------
>
>                 Key: WFLY-9702
>                 URL: https://issues.jboss.org/browse/WFLY-9702
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Security, Web (Undertow)
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 12.0.0.Alpha1
>
>
> At the moment the SSO integration only fully covers authentication mechanisms as they can be wrapped, we need to revisit for programmatic authentication.
> In this scenario we don't have either a wrapped mechanism or a CallbackHandler.
> Couple of options: -
> * Can we get away with pushing in some form of IdentityCache factory the mechs can obtain from the request?  This may miss the additional notifications the SSO impl depends on.
> * Can we also better support listening for the notifications without the need for wrappers?  This could cover both mechs and programmatic authentication?
> * Instead do we make the programmatic authenticator pluggable, i.e. push in an SSO aware impl, it can choose how to handle it's own caching and also doesn't need the notifications as it is in control of that stage of the process.
> * 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 09:39:01 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 17 Jan 2018 09:39:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1490) Java 9: Test fails on Oracle
 9.0.4 and later due to SHA-1 usage
In-Reply-To: <JIRA.12729511.1516199885000@Atlassian.JIRA>
References: <JIRA.12729511.1516199885000@Atlassian.JIRA>
	<JIRA.12729511.1516199885717@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729511.1516199885000.58105.1516199941479@Atlassian.JIRA>

David Lloyd created ELY-1490:
--------------------------------

             Summary: Java 9: Test fails on Oracle 9.0.4 and later due to SHA-1 usage
                 Key: ELY-1490
                 URL: https://issues.jboss.org/browse/ELY-1490
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Testsuite
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 1.2.0.Beta12


The error is:

{noformat}
[ERROR] Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.197 s <<< FAILURE! - in org.wildfly.security.asn1.DEREncoderTest
[ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.053 s  <<< ERROR!
java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
	at java.base/java.security.Signature$Delegate.init(Signature.java:1178)
	at java.base/java.security.Signature$Delegate.chooseProvider(Signature.java:1138)
	at java.base/java.security.Signature$Delegate.engineInitSign(Signature.java:1202)
	at java.base/java.security.Signature.initSign(Signature.java:545)
	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:426)
{noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 09:39:01 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 17 Jan 2018 09:39:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1490) Java 9: Test fails on Oracle
 9.0.4 and later due to SHA-1 usage
In-Reply-To: <JIRA.12729511.1516199886000@Atlassian.JIRA>
References: <JIRA.12729511.1516199886000@Atlassian.JIRA>
	<JIRA.12729511.1516199886000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729511.1516199886000.58108.1516199941561@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated ELY-1490:
-----------------------------
    Labels: Java9  (was: )


> Java 9: Test fails on Oracle 9.0.4 and later due to SHA-1 usage
> ---------------------------------------------------------------
>
>                 Key: ELY-1490
>                 URL: https://issues.jboss.org/browse/ELY-1490
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>              Labels: Java9
>             Fix For: 1.2.0.Beta12
>
>
> The error is:
> {noformat}
> [ERROR] Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.197 s <<< FAILURE! - in org.wildfly.security.asn1.DEREncoderTest
> [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.053 s  <<< ERROR!
> java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> 	at java.base/java.security.Signature$Delegate.init(Signature.java:1178)
> 	at java.base/java.security.Signature$Delegate.chooseProvider(Signature.java:1138)
> 	at java.base/java.security.Signature$Delegate.engineInitSign(Signature.java:1202)
> 	at java.base/java.security.Signature.initSign(Signature.java:545)
> 	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:426)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 09:41:00 2018
From: issues at jboss.org (Chris Giddings (JIRA))
Date: Wed, 17 Jan 2018 09:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves
 Remnants in standalone.xml
In-Reply-To: <JIRA.12729305.1516124574000@Atlassian.JIRA>
References: <JIRA.12729305.1516124574000@Atlassian.JIRA>
	<JIRA.12729305.1516124574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729305.1516124574000.58246.1516200060458@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520175#comment-13520175 ] 

Chris Giddings commented on WFLY-9681:
--------------------------------------

[~jaikiran], The error posted (from StackOverflow) is not my own, but mine is nearly identical.

For the WAR file I'm attempting to deploy myself, yes. Rather prolifically.

I'm currently running a POC to transition our applications from Tomcat 8 to Wildfly (11 Final) for easier cluster and HA management.

> Deleting ExampleDS Leaves Remnants in standalone.xml
> ----------------------------------------------------
>
>                 Key: WFLY-9681
>                 URL: https://issues.jboss.org/browse/WFLY-9681
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Final
>            Reporter: Chris Giddings
>            Assignee: Stefano Maestri
>            Priority: Minor
>              Labels: JDBC
>
> h2. SUMMARY
> When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
> When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
> h2. WORKAROUND
> Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
> h2. BUG JUSTIFICATION
> # I would expect anything labeled as "Example" to be deleted by an administrator in most environments
> # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 09:42:00 2018
From: issues at jboss.org (Chris Giddings (JIRA))
Date: Wed, 17 Jan 2018 09:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves
 Remnants in standalone.xml
In-Reply-To: <JIRA.12729305.1516124574000@Atlassian.JIRA>
References: <JIRA.12729305.1516124574000@Atlassian.JIRA>
	<JIRA.12729305.1516124574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729305.1516124574000.58263.1516200120364@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Giddings updated WFLY-9681:
---------------------------------
    Labels: JDBC JP  (was: JDBC)


> Deleting ExampleDS Leaves Remnants in standalone.xml
> ----------------------------------------------------
>
>                 Key: WFLY-9681
>                 URL: https://issues.jboss.org/browse/WFLY-9681
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Final
>            Reporter: Chris Giddings
>            Assignee: Stefano Maestri
>            Priority: Minor
>              Labels: JDBC
>
> h2. SUMMARY
> When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
> When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
> h2. WORKAROUND
> Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
> h2. BUG JUSTIFICATION
> # I would expect anything labeled as "Example" to be deleted by an administrator in most environments
> # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 09:42:00 2018
From: issues at jboss.org (Chris Giddings (JIRA))
Date: Wed, 17 Jan 2018 09:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9681) Deleting ExampleDS Leaves
 Remnants in standalone.xml
In-Reply-To: <JIRA.12729305.1516124574000@Atlassian.JIRA>
References: <JIRA.12729305.1516124574000@Atlassian.JIRA>
	<JIRA.12729305.1516124574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729305.1516124574000.58269.1516200120567@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9681?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chris Giddings updated WFLY-9681:
---------------------------------
    Labels: JDBC  (was: JDBC JP)


> Deleting ExampleDS Leaves Remnants in standalone.xml
> ----------------------------------------------------
>
>                 Key: WFLY-9681
>                 URL: https://issues.jboss.org/browse/WFLY-9681
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA
>    Affects Versions: 11.0.0.Final
>            Reporter: Chris Giddings
>            Assignee: Stefano Maestri
>            Priority: Minor
>              Labels: JDBC
>
> h2. SUMMARY
> When initially installing Wildfly 11.0.0 Final, the installation comes pre-configured with a datasource labeled "Example DS".
> When this datasource is deleted, some configuration for it remains in the standalone.xml file for the standalone server mode.
> h2. WORKAROUND
> Removing this configuration manually and restarting Wildfly in standalone mode resolves the issue. (I tested by searching for "ExampleDS" as a string match in vi and deleting the one line the match found)
> h2. BUG JUSTIFICATION
> # I would expect anything labeled as "Example" to be deleted by an administrator in most environments
> # I would expect deleted items to be fully removed upon deletion so remnant configuration couldn't cause issues with unrelated deployments (i.e. deployments which don't specifically require the deleted item)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 09:47:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 17 Jan 2018 09:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1491) Initial Build Updates for Java
	10
In-Reply-To: <JIRA.12729515.1516200365000@Atlassian.JIRA>
References: <JIRA.12729515.1516200365000@Atlassian.JIRA>
	<JIRA.12729515.1516200365949@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729515.1516200365000.58300.1516200420301@Atlassian.JIRA>

Darran Lofthouse created ELY-1491:
-------------------------------------

             Summary: Initial Build Updates for Java 10
                 Key: ELY-1491
                 URL: https://issues.jboss.org/browse/ELY-1491
             Project: WildFly Elytron
          Issue Type: Task
          Components: Build
            Reporter: Darran Lofthouse
            Assignee: Tomaz Cerar
             Fix For: 1.2.0.Beta12






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 09:59:01 2018
From: issues at jboss.org (Dmitrii Tikhomirov (JIRA))
Date: Wed, 17 Jan 2018 09:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3513)
 StringIndexOutOfBoundsException if config file with wrong name is present
 in 'standalone_xml_history/snapshot' folder
In-Reply-To: <JIRA.12729407.1516188743000@Atlassian.JIRA>
References: <JIRA.12729407.1516188743000@Atlassian.JIRA>
	<JIRA.12729407.1516188743000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729407.1516188743000.58494.1516201141632@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitrii Tikhomirov reassigned WFCORE-3513:
------------------------------------------

    Assignee: Dmitrii Tikhomirov  (was: Yeray Borges)


> StringIndexOutOfBoundsException if config file with wrong name is present in 'standalone_xml_history/snapshot' folder
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3513
>                 URL: https://issues.jboss.org/browse/WFCORE-3513
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 3.0.8.Final
>         Environment: The issue is reproduce able in 'wildfly-11.0.0.Final'
>            Reporter: J?rg B?sner
>            Assignee: Dmitrii Tikhomirov
>
> In case a file not named as *yyyyMMdd-HHmmssSSSname.xml* is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.
> {noformat}
> wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final
>   JAVA: java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
> java.lang.StringIndexOutOfBoundsException: String index out of range: -4
> 	at java.lang.String.substring(String.java:1931)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
> 	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
> 	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
> 	at org.jboss.as.server.Main.main(Main.java:95)
> 	at org.jboss.modules.Module.run(Module.java:344)
> 	at org.jboss.modules.Main.main(Main.java:525)
> 12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 10:18:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 17 Jan 2018 10:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2237) Turn on CheckStyle for dmn
	editor
In-Reply-To: <JIRA.12727749.1515756238000@Atlassian.JIRA>
References: <JIRA.12727749.1515756238000@Atlassian.JIRA>
	<JIRA.12727749.1515756238000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727749.1515756238000.58804.1516202280104@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2237:
--------------------------------
    Fix Version/s: 7.6.0.Final


> Turn on CheckStyle for dmn editor
> ---------------------------------
>
>                 Key: DROOLS-2237
>                 URL: https://issues.jboss.org/browse/DROOLS-2237
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>             Fix For: 7.6.0.Final
>
>
> Turn of the CheckStyle control of imports and licences for the dmn editor.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 10:51:01 2018
From: issues at jboss.org (kobogian hitis (JIRA))
Date: Wed, 17 Jan 2018 10:51:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9272) CDI events not clustered
In-Reply-To: <JIRA.12709002.1503926294000@Atlassian.JIRA>
References: <JIRA.12709002.1503926294000@Atlassian.JIRA>
	<JIRA.12709002.1503926294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709002.1503926294000.59024.1516204261229@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520247#comment-13520247 ] 

kobogian hitis commented on WFLY-9272:
--------------------------------------

Can Wildfly team please confirm that CDI events are not by default replicated, on full-ha profile, 
because I cannot find any documentation stating the one or another.

In my case I really want them not to be clustered in full-ha.

> CDI events not clustered
> ------------------------
>
>                 Key: WFLY-9272
>                 URL: https://issues.jboss.org/browse/WFLY-9272
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld, Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Giovanni Lovato
>
> When an EAR is deployed on a server group in full-ha profile, CDI events ({{javax.enterprise.event.Event}}) fired from a node are notified only to observer threads in the same node.
> This limits the use of CDI events in distributed application, when events fired by users balanced on one node are missed by users balanced on other nodes.
> In Payara this is already possibile for {{Serializable}} paylaods using annotations (see https://payara.gitbooks.io/payara-server/content/documentation/extended-documentation/cdi-events.html).
> It would be really useful to have this in WildFly too.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 11:04:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 17 Jan 2018 11:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3516) Provide certificate
 authority integration
In-Reply-To: <JIRA.12729545.1516205003000@Atlassian.JIRA>
References: <JIRA.12729545.1516205003000@Atlassian.JIRA>
	<JIRA.12729545.1516205003222@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729545.1516205003000.59201.1516205040742@Atlassian.JIRA>

Darran Lofthouse created WFCORE-3516:
----------------------------------------

             Summary: Provide certificate authority integration
                 Key: WFCORE-3516
                 URL: https://issues.jboss.org/browse/WFCORE-3516
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Security
    Affects Versions: 4.0.0.Alpha2
            Reporter: Darran Lofthouse
            Assignee: Farah Juma


Let's Encrypt provide API to fully automate (gain/renew) certificate retrieval using ACME protocol. Integrate this capability into wildfly.

This can simplify administrator work. No need to perform certification renewal routine tasks.

This is follow up on WFCORE-3305 and piece of bigger task "Simplify SSL configuration in wildfly". That said it is just "User experience" issue. Administrator still can work with Let's Encrypt by third party client and just reference wildfly to this certificate.

[1] Latest draft: https://tools.ietf.org/html/draft-ietf-acme-acme-09



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 11:09:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 17 Jan 2018 11:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9701) Dwm tests intermittently
 failing on Solaris
In-Reply-To: <JIRA.12729487.1516196115000@Atlassian.JIRA>
References: <JIRA.12729487.1516196115000@Atlassian.JIRA>
	<JIRA.12729487.1516196115000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729487.1516196115000.59289.1516205340442@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFLY-9701:
-----------------------------------
    Component/s: JCA


> Dwm tests intermittently failing on Solaris
> -------------------------------------------
>
>                 Key: WFLY-9701
>                 URL: https://issues.jboss.org/browse/WFLY-9701
>             Project: WildFly
>          Issue Type: Bug
>          Components: JCA, Test Suite
>    Affects Versions: 12.0.0.Alpha1
>            Reporter: Richard Jan?k
>            Assignee: Richard Jan?k
>
> I've been alerted to Dwm tests sometimes failing on Solaris. The TeamCity CI shows that this happens with PRs with unrelated fixes and happens in ~4% of runs.
> Sample fail: https://ci.wildfly.org/viewLog.html?buildId=84840&tab=buildResultsDiv&buildTypeId=WF_MasterSolaris



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 11:26:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Wed, 17 Jan 2018 11:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3513)
 StringIndexOutOfBoundsException if config file with wrong name is present
 in 'standalone_xml_history/snapshot' folder
In-Reply-To: <JIRA.12729407.1516188743000@Atlassian.JIRA>
References: <JIRA.12729407.1516188743000@Atlassian.JIRA>
	<JIRA.12729407.1516188743000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729407.1516188743000.59474.1516206360525@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3513?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3513:
-------------------------------------
    Component/s: Domain Management
                     (was: Server)


> StringIndexOutOfBoundsException if config file with wrong name is present in 'standalone_xml_history/snapshot' folder
> ---------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3513
>                 URL: https://issues.jboss.org/browse/WFCORE-3513
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.8.Final
>         Environment: The issue is reproduce able in 'wildfly-11.0.0.Final'
>            Reporter: J?rg B?sner
>            Assignee: Dmitrii Tikhomirov
>
> In case a file not named as *yyyyMMdd-HHmmssSSSname.xml* is present in the _snapshot_ folder, the server start abort with a StringIndexOutOfBoundsException.
> {noformat}
> wildfly-11.0.0.Final $ ./bin/standalone.sh --admin-only -c standalone.xml
> =========================================================================
>   JBoss Bootstrap Environment
>   JBOSS_HOME: /home/jbaesner/wildfly-nightly/wildfly-11.0.0.Final
>   JAVA: java
>   JAVA_OPTS:  -server -Xms64m -Xmx512m -XX:MetaspaceSize=96M -XX:MaxMetaspaceSize=256m -Djava.net.preferIPv4Stack=true -Djboss.modules.system.pkgs=org.jboss.byteman -Djava.awt.headless=true
> =========================================================================
> 12:21:09,710 INFO  [org.jboss.modules] (main) JBoss Modules version 1.6.1.Final
> java.lang.StringIndexOutOfBoundsException: String index out of range: -4
> 	at java.lang.String.substring(String.java:1931)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.findMainFileFromSnapshotPrefix(ConfigurationFile.java:403)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.determineMainFile(ConfigurationFile.java:312)
> 	at org.jboss.as.controller.persistence.ConfigurationFile.<init>(ConfigurationFile.java:176)
> 	at org.jboss.as.server.ServerEnvironment.<init>(ServerEnvironment.java:454)
> 	at org.jboss.as.server.Main.determineEnvironment(Main.java:339)
> 	at org.jboss.as.server.Main.main(Main.java:95)
> 	at org.jboss.modules.Module.run(Module.java:344)
> 	at org.jboss.modules.Main.main(Main.java:525)
> 12:21:10,047 FATAL [org.jboss.as.server] (main) WFLYSRV0239: Aborting with exit code 1
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 12:48:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 17 Jan 2018 12:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (SECURITY-958) JASPIC implementation in
 JBoss EAP 7.0.0 seems to contradict the javadoc of the ServerAuthModule
 interface
In-Reply-To: <JIRA.12651621.1474613717000@Atlassian.JIRA>
References: <JIRA.12651621.1474613717000@Atlassian.JIRA>
	<JIRA.12651621.1474613717000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651621.1474613717000.60014.1516211280466@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/SECURITY-958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned SECURITY-958:
-----------------------------------------

    Assignee: Darran Lofthouse  (was: Enrique Gonz?lez Mart?nez)


> JASPIC implementation in JBoss EAP 7.0.0 seems to contradict the javadoc of the ServerAuthModule interface
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: SECURITY-958
>                 URL: https://issues.jboss.org/browse/SECURITY-958
>             Project: PicketBox 
>          Issue Type: Bug
>            Reporter: Enrique Gonz?lez Mart?nez
>            Assignee: Darran Lofthouse
>
> The EAP 7.0.0 JASPIC ServerAuthModule framework passes the request policy and response policy objects as null into the initialize() method. The spec and java docs say that both must not be null.
> http://docs.oracle.com/javaee/6/api/javax/security/auth/message/module/ServerAuthModule.html
> https://docs.oracle.com/javaee/7/api/javax/security/auth/message/module/ServerAuthModule.html
> The javadoc and spec says: "The request policy and the response policy must not both be null".
> Wildfly 10.0.0.Final has the same issue.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 17 12:51:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 17 Jan 2018 12:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1490) Java 9: Test fails on Oracle
 9.0.4 and later due to SHA-1 usage
In-Reply-To: <JIRA.12729511.1516199886000@Atlassian.JIRA>
References: <JIRA.12729511.1516199886000@Atlassian.JIRA>
	<JIRA.12729511.1516199886000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729511.1516199886000.60019.1516211460138@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved ELY-1490.
------------------------------
    Resolution: Done


> Java 9: Test fails on Oracle 9.0.4 and later due to SHA-1 usage
> ---------------------------------------------------------------
>
>                 Key: ELY-1490
>                 URL: https://issues.jboss.org/browse/ELY-1490
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>              Labels: Java9
>             Fix For: 1.2.0.Beta12
>
>
> The error is:
> {noformat}
> [ERROR] Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.197 s <<< FAILURE! - in org.wildfly.security.asn1.DEREncoderTest
> [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.053 s  <<< ERROR!
> java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> 	at java.base/java.security.Signature$Delegate.init(Signature.java:1178)
> 	at java.base/java.security.Signature$Delegate.chooseProvider(Signature.java:1138)
> 	at java.base/java.security.Signature$Delegate.engineInitSign(Signature.java:1202)
> 	at java.base/java.security.Signature.initSign(Signature.java:545)
> 	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:426)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 13:19:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 17 Jan 2018 13:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9272) CDI events not clustered
In-Reply-To: <JIRA.12709002.1503926294000@Atlassian.JIRA>
References: <JIRA.12709002.1503926294000@Atlassian.JIRA>
	<JIRA.12709002.1503926294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709002.1503926294000.60127.1516213140398@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520343#comment-13520343 ] 

Radoslav Husar commented on WFLY-9272:
--------------------------------------

[~kobogianhitis] I can confirm they are not clustered.

> CDI events not clustered
> ------------------------
>
>                 Key: WFLY-9272
>                 URL: https://issues.jboss.org/browse/WFLY-9272
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld, Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Giovanni Lovato
>
> When an EAR is deployed on a server group in full-ha profile, CDI events ({{javax.enterprise.event.Event}}) fired from a node are notified only to observer threads in the same node.
> This limits the use of CDI events in distributed application, when events fired by users balanced on one node are missed by users balanced on other nodes.
> In Payara this is already possibile for {{Serializable}} paylaods using annotations (see https://payara.gitbooks.io/payara-server/content/documentation/extended-documentation/cdi-events.html).
> It would be really useful to have this in WildFly too.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 13:19:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 17 Jan 2018 13:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9272) CDI events not clustered
In-Reply-To: <JIRA.12709002.1503926294000@Atlassian.JIRA>
References: <JIRA.12709002.1503926294000@Atlassian.JIRA>
	<JIRA.12709002.1503926294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709002.1503926294000.60137.1516213140745@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro reassigned WFLY-9272:
----------------------------------

    Assignee: Paul Ferraro


> CDI events not clustered
> ------------------------
>
>                 Key: WFLY-9272
>                 URL: https://issues.jboss.org/browse/WFLY-9272
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld, Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Giovanni Lovato
>            Assignee: Paul Ferraro
>
> When an EAR is deployed on a server group in full-ha profile, CDI events ({{javax.enterprise.event.Event}}) fired from a node are notified only to observer threads in the same node.
> This limits the use of CDI events in distributed application, when events fired by users balanced on one node are missed by users balanced on other nodes.
> In Payara this is already possibile for {{Serializable}} paylaods using annotations (see https://payara.gitbooks.io/payara-server/content/documentation/extended-documentation/cdi-events.html).
> It would be really useful to have this in WildFly too.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 13:24:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 17 Jan 2018 13:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9272) CDI events not clustered
In-Reply-To: <JIRA.12709002.1503926294000@Atlassian.JIRA>
References: <JIRA.12709002.1503926294000@Atlassian.JIRA>
	<JIRA.12709002.1503926294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709002.1503926294000.60153.1516213440488@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar reassigned WFLY-9272:
------------------------------------

    Assignee: Radoslav Husar  (was: Paul Ferraro)


> CDI events not clustered
> ------------------------
>
>                 Key: WFLY-9272
>                 URL: https://issues.jboss.org/browse/WFLY-9272
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld, Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Giovanni Lovato
>            Assignee: Radoslav Husar
>
> When an EAR is deployed on a server group in full-ha profile, CDI events ({{javax.enterprise.event.Event}}) fired from a node are notified only to observer threads in the same node.
> This limits the use of CDI events in distributed application, when events fired by users balanced on one node are missed by users balanced on other nodes.
> In Payara this is already possibile for {{Serializable}} paylaods using annotations (see https://payara.gitbooks.io/payara-server/content/documentation/extended-documentation/cdi-events.html).
> It would be really useful to have this in WildFly too.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 13:24:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 17 Jan 2018 13:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9272) Support clustered CDI events
In-Reply-To: <JIRA.12709002.1503926294000@Atlassian.JIRA>
References: <JIRA.12709002.1503926294000@Atlassian.JIRA>
	<JIRA.12709002.1503926294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709002.1503926294000.60162.1516213440679@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-9272:
---------------------------------
    Summary: Support clustered CDI events  (was: CDI events not clustered)


> Support clustered CDI events
> ----------------------------
>
>                 Key: WFLY-9272
>                 URL: https://issues.jboss.org/browse/WFLY-9272
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld, Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Giovanni Lovato
>            Assignee: Radoslav Husar
>
> When an EAR is deployed on a server group in full-ha profile, CDI events ({{javax.enterprise.event.Event}}) fired from a node are notified only to observer threads in the same node.
> This limits the use of CDI events in distributed application, when events fired by users balanced on one node are missed by users balanced on other nodes.
> In Payara this is already possibile for {{Serializable}} paylaods using annotations (see https://payara.gitbooks.io/payara-server/content/documentation/extended-documentation/cdi-events.html).
> It would be really useful to have this in WildFly too.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 14:34:00 2018
From: issues at jboss.org (Wolfgang Knauf (JIRA))
Date: Wed, 17 Jan 2018 14:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9703) Improve archetype
 "wildfly-javaee7-webapp-ear-blank-archetype" to simplify upgrade to recent
 WildFly versions
In-Reply-To: <JIRA.12729574.1516217609000@Atlassian.JIRA>
References: <JIRA.12729574.1516217609000@Atlassian.JIRA>
	<JIRA.12729574.1516217609977@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729574.1516217609000.60310.1516217640062@Atlassian.JIRA>

Wolfgang Knauf created WFLY-9703:
------------------------------------

             Summary: Improve archetype "wildfly-javaee7-webapp-ear-blank-archetype" to simplify upgrade to recent WildFly versions
                 Key: WFLY-9703
                 URL: https://issues.jboss.org/browse/WFLY-9703
             Project: WildFly
          Issue Type: Bug
          Components: EE
    Affects Versions: 11.0.0.Final
            Reporter: Wolfgang Knauf
            Priority: Minor


When using this archetype, the "pom.xml" of the root project points to JBoss 8.2.1 / WildFly 9.0.0Alpha1

After changing the versions to WildFly 11, several additional changes are necessary. I suggest to add at least some comments about necessary changes. It would be even better to upgrade the archetype to a more recent WildFly version ;-).

In "pom.xml" of the root project:
* Dependeny "jboss-javaee-7.0-with-tools" has to be changed to artifactId = "wildfly-javaee7-with-tools".
* Dependency "jboss-javaee-7.0-with-hibernate" does not seem to exist any longer
So, add a comment to those dependencies about error messages when switching to a new WildFly version and about the necessary changes. This comment should contain the new snippet.

In "pom.xml" of the web project:
* Dependeny with groupId = "org.jboss.resteasy", artifactId="jaxrs-api" was changed to groupId = "org.jboss.spec.javax.ws.rs", artifactId = "jboss-jaxrs-api_2.0_spec" ([WFLY-4128|https://issues.jboss.org/browse/WFLY-4128]

Additionally, it would be helpful if the web project contains the dependencies with groupId = "org.jboss.spec.javax.ejb" and artifactId = "jboss-ejb-api_3.2_spec" (for use of the "@EJB" annotation in e.g. servlets or JFS components) and groupId = "org.jboss.spec.javax.servlet", artifactId = "jboss-servlet-api_3.1_spec" for being able to code servlets.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 14:35:00 2018
From: issues at jboss.org (Wolfgang Knauf (JIRA))
Date: Wed, 17 Jan 2018 14:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9703) Improve archetype
 "wildfly-javaee7-webapp-ear-blank-archetype" to simplify upgrade to recent
 WildFly versions
In-Reply-To: <JIRA.12729574.1516217610000@Atlassian.JIRA>
References: <JIRA.12729574.1516217610000@Atlassian.JIRA>
	<JIRA.12729574.1516217610000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729574.1516217610000.60312.1516217700061@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9703?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Wolfgang Knauf updated WFLY-9703:
---------------------------------
    Description: 
When using this archetype, the "pom.xml" of the root project points to JBoss 8.2.1 / WildFly 9.0.0Alpha1

After changing the versions to WildFly 11, several additional changes are necessary. I suggest to add at least some comments about necessary changes. It would be even better to upgrade the archetype to a more recent WildFly version ;-).

In "pom.xml" of the root project:
* Dependeny "jboss-javaee-7.0-with-tools" has to be changed to artifactId = "wildfly-javaee7-with-tools".
* Dependency "jboss-javaee-7.0-with-hibernate" does not seem to exist any longer
So, add a comment to those dependencies about error messages when switching to a new WildFly version and about the necessary changes. This comment should contain the new snippet.

In "pom.xml" of the web project:
* Dependeny with groupId = "org.jboss.resteasy", artifactId="jaxrs-api" was changed to groupId = "org.jboss.spec.javax.ws.rs", artifactId = "jboss-jaxrs-api_2.0_spec" ([WFLY-4128|https://issues.jboss.org/browse/WFLY-4128])

Additionally, it would be helpful if the web project contains the dependencies with groupId = "org.jboss.spec.javax.ejb" and artifactId = "jboss-ejb-api_3.2_spec" (for use of the "@EJB" annotation in e.g. servlets or JFS components) and groupId = "org.jboss.spec.javax.servlet", artifactId = "jboss-servlet-api_3.1_spec" for being able to code servlets.


  was:
When using this archetype, the "pom.xml" of the root project points to JBoss 8.2.1 / WildFly 9.0.0Alpha1

After changing the versions to WildFly 11, several additional changes are necessary. I suggest to add at least some comments about necessary changes. It would be even better to upgrade the archetype to a more recent WildFly version ;-).

In "pom.xml" of the root project:
* Dependeny "jboss-javaee-7.0-with-tools" has to be changed to artifactId = "wildfly-javaee7-with-tools".
* Dependency "jboss-javaee-7.0-with-hibernate" does not seem to exist any longer
So, add a comment to those dependencies about error messages when switching to a new WildFly version and about the necessary changes. This comment should contain the new snippet.

In "pom.xml" of the web project:
* Dependeny with groupId = "org.jboss.resteasy", artifactId="jaxrs-api" was changed to groupId = "org.jboss.spec.javax.ws.rs", artifactId = "jboss-jaxrs-api_2.0_spec" ([WFLY-4128|https://issues.jboss.org/browse/WFLY-4128]

Additionally, it would be helpful if the web project contains the dependencies with groupId = "org.jboss.spec.javax.ejb" and artifactId = "jboss-ejb-api_3.2_spec" (for use of the "@EJB" annotation in e.g. servlets or JFS components) and groupId = "org.jboss.spec.javax.servlet", artifactId = "jboss-servlet-api_3.1_spec" for being able to code servlets.




> Improve archetype "wildfly-javaee7-webapp-ear-blank-archetype" to simplify upgrade to recent WildFly versions
> -------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9703
>                 URL: https://issues.jboss.org/browse/WFLY-9703
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE
>    Affects Versions: 11.0.0.Final
>            Reporter: Wolfgang Knauf
>            Priority: Minor
>
> When using this archetype, the "pom.xml" of the root project points to JBoss 8.2.1 / WildFly 9.0.0Alpha1
> After changing the versions to WildFly 11, several additional changes are necessary. I suggest to add at least some comments about necessary changes. It would be even better to upgrade the archetype to a more recent WildFly version ;-).
> In "pom.xml" of the root project:
> * Dependeny "jboss-javaee-7.0-with-tools" has to be changed to artifactId = "wildfly-javaee7-with-tools".
> * Dependency "jboss-javaee-7.0-with-hibernate" does not seem to exist any longer
> So, add a comment to those dependencies about error messages when switching to a new WildFly version and about the necessary changes. This comment should contain the new snippet.
> In "pom.xml" of the web project:
> * Dependeny with groupId = "org.jboss.resteasy", artifactId="jaxrs-api" was changed to groupId = "org.jboss.spec.javax.ws.rs", artifactId = "jboss-jaxrs-api_2.0_spec" ([WFLY-4128|https://issues.jboss.org/browse/WFLY-4128])
> Additionally, it would be helpful if the web project contains the dependencies with groupId = "org.jboss.spec.javax.ejb" and artifactId = "jboss-ejb-api_3.2_spec" (for use of the "@EJB" annotation in e.g. servlets or JFS components) and groupId = "org.jboss.spec.javax.servlet", artifactId = "jboss-servlet-api_3.1_spec" for being able to code servlets.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 17:26:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 17 Jan 2018 17:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9704) Add session operations and
 details equivalent to JBossWeb's Manager mbeans
In-Reply-To: <JIRA.12729585.1516227919000@Atlassian.JIRA>
References: <JIRA.12729585.1516227919000@Atlassian.JIRA>
	<JIRA.12729585.1516227919240@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729585.1516227919000.60908.1516227960221@Atlassian.JIRA>

David Lloyd created WFLY-9704:
---------------------------------

             Summary: Add session operations and details equivalent to JBossWeb's Manager mbeans
                 Key: WFLY-9704
                 URL: https://issues.jboss.org/browse/WFLY-9704
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Aaron Ogburn
            Assignee: Stuart Douglas


JBossWeb's session Manager mbeans provide a lot of details and operations for individual sessions (listing all present ids, their creation/access times, checking particular attributes of specific sessions, etc.). It is desired for equivalent functionality to be added to EAP 7/undertow.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 17:27:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 17 Jan 2018 17:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9704) Add session operations and
 details equivalent to JBossWeb's Manager mbeans
In-Reply-To: <JIRA.12729585.1516227919000@Atlassian.JIRA>
References: <JIRA.12729585.1516227919000@Atlassian.JIRA>
	<JIRA.12729585.1516227919000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729585.1516227919000.60913.1516228020148@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9704?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd deleted WFLY-9704:
------------------------------


> Add session operations and details equivalent to JBossWeb's Manager mbeans
> --------------------------------------------------------------------------
>
>                 Key: WFLY-9704
>                 URL: https://issues.jboss.org/browse/WFLY-9704
>             Project: WildFly
>          Issue Type: Feature Request
>            Reporter: Aaron Ogburn
>            Assignee: Stuart Douglas
>
> JBossWeb's session Manager mbeans provide a lot of details and operations for individual sessions (listing all present ids, their creation/access times, checking particular attributes of specific sessions, etc.). It is desired for equivalent functionality to be added to EAP 7/undertow.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 17:28:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 17 Jan 2018 17:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9705) Add session operations and
 details equivalent to JBossWeb's Manager mbeans
In-Reply-To: <JIRA.12729586.1516228054000@Atlassian.JIRA>
References: <JIRA.12729586.1516228054000@Atlassian.JIRA>
	<JIRA.12729586.1516228054883@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729586.1516228054000.60919.1516228080320@Atlassian.JIRA>

James Perkins created WFLY-9705:
-----------------------------------

             Summary: Add session operations and details equivalent to JBossWeb's Manager mbeans
                 Key: WFLY-9705
                 URL: https://issues.jboss.org/browse/WFLY-9705
             Project: WildFly
          Issue Type: Feature Request
            Reporter: Aaron Ogburn
            Assignee: Stuart Douglas


JBossWeb's session Manager mbeans provide a lot of details and operations for individual sessions (listing all present ids, their creation/access times, checking particular attributes of specific sessions, etc.). It is desired for equivalent functionality to be added to EAP 7/undertow.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 17:53:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 17 Jan 2018 17:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2244) Use of TP.internal_pool can
 result in classloader leaks
In-Reply-To: <JIRA.12729588.1516229563000@Atlassian.JIRA>
References: <JIRA.12729588.1516229563000@Atlassian.JIRA>
	<JIRA.12729588.1516229563155@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729588.1516229563000.60979.1516229580089@Atlassian.JIRA>

Paul Ferraro created JGRP-2244:
----------------------------------

             Summary: Use of TP.internal_pool can result in classloader leaks
                 Key: JGRP-2244
                 URL: https://issues.jboss.org/browse/JGRP-2244
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 4.0
            Reporter: Paul Ferraro
            Assignee: Bela Ban


As of JGroups 4.0, the ThreadFactory of the internal thread pool cannot be overridden.  Consequently, there is no mechanism to associate newly spawned threads with a specific classloader.  If an application thread results in the spawning of an thread in this internal pool [1], the application class loader can leak to other threads used the the JGroups channel.

[1] https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/TP.java#L1369



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 20:57:00 2018
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Wed, 17 Jan 2018 20:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8858) Remove JPA container check
 for deprecated hibernate.ejb.use_class_enhancer
In-Reply-To: <JIRA.12694832.1496150977000@Atlassian.JIRA>
References: <JIRA.12694832.1496150977000@Atlassian.JIRA>
	<JIRA.12694832.1496150977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12694832.1496150977000.61272.1516240620081@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520444#comment-13520444 ] 

Scott Marlow commented on WFLY-8858:
------------------------------------

Workaround for applications that don't want to wait for this change, is to set persistence unit hint  jboss.as.jpa.classtransformer=true

> Remove JPA container check for deprecated hibernate.ejb.use_class_enhancer
> --------------------------------------------------------------------------
>
>                 Key: WFLY-8858
>                 URL: https://issues.jboss.org/browse/WFLY-8858
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 12.0.0.Alpha1
>
>
> Applications can instead use the jboss.as.jpa.classtransformer property to control whether the application can use entity class rewriting.  Starting with Hibernate ORM 5.0+, Hibernate defaults to always rewrite entity classes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 17 21:18:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Wed, 17 Jan 2018 21:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3517) Remove unnecessary
 Attribute and Element enums from JXM subsystem
In-Reply-To: <JIRA.12729627.1516241823000@Atlassian.JIRA>
References: <JIRA.12729627.1516241823000@Atlassian.JIRA>
	<JIRA.12729627.1516241823117@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729627.1516241823000.61283.1516241880124@Atlassian.JIRA>

Stuart Douglas created WFCORE-3517:
--------------------------------------

             Summary: Remove unnecessary Attribute and Element enums from JXM subsystem
                 Key: WFCORE-3517
                 URL: https://issues.jboss.org/browse/WFCORE-3517
             Project: WildFly Core
          Issue Type: Task
          Components: JMX
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas
            Priority: Minor






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 02:55:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 18 Jan 2018 02:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2244) Use of TP.internal_pool can
 result in classloader leaks
In-Reply-To: <JIRA.12729588.1516229563000@Atlassian.JIRA>
References: <JIRA.12729588.1516229563000@Atlassian.JIRA>
	<JIRA.12729588.1516229563000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729588.1516229563000.61761.1516262100207@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2244:
---------------------------
    Fix Version/s: 4.0.10


> Use of TP.internal_pool can result in classloader leaks
> -------------------------------------------------------
>
>                 Key: JGRP-2244
>                 URL: https://issues.jboss.org/browse/JGRP-2244
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0
>            Reporter: Paul Ferraro
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> As of JGroups 4.0, the ThreadFactory of the internal thread pool cannot be overridden.  Consequently, there is no mechanism to associate newly spawned threads with a specific classloader.  If an application thread results in the spawning of an thread in this internal pool [1], the application class loader can leak to other threads used the the JGroups channel.
> [1] https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/TP.java#L1369



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 03:22:01 2018
From: issues at jboss.org (Matej Novotny (JIRA))
Date: Thu, 18 Jan 2018 03:22:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9272) Support clustered CDI events
In-Reply-To: <JIRA.12709002.1503926294000@Atlassian.JIRA>
References: <JIRA.12709002.1503926294000@Atlassian.JIRA>
	<JIRA.12709002.1503926294000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709002.1503926294000.61890.1516263721238@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520500#comment-13520500 ] 

Matej Novotny commented on WFLY-9272:
-------------------------------------

If case you need a hand from Weld-side of things while implementing this, me or [~mkouba] can help out.

> Support clustered CDI events
> ----------------------------
>
>                 Key: WFLY-9272
>                 URL: https://issues.jboss.org/browse/WFLY-9272
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: CDI / Weld, Clustering
>    Affects Versions: 10.1.0.Final
>            Reporter: Giovanni Lovato
>            Assignee: Radoslav Husar
>
> When an EAR is deployed on a server group in full-ha profile, CDI events ({{javax.enterprise.event.Event}}) fired from a node are notified only to observer threads in the same node.
> This limits the use of CDI events in distributed application, when events fired by users balanced on one node are missed by users balanced on other nodes.
> In Payara this is already possibile for {{Serializable}} paylaods using annotations (see https://payara.gitbooks.io/payara-server/content/documentation/extended-documentation/cdi-events.html).
> It would be really useful to have this in WildFly too.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 03:44:00 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Thu, 18 Jan 2018 03:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6661) Bean level lock type not
	applied
In-Reply-To: <JIRA.12628729.1464697462000@Atlassian.JIRA>
References: <JIRA.12628729.1464697462000@Atlassian.JIRA>
	<JIRA.12628729.1464697462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12628729.1464697462000.61965.1516265040225@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges resolved WFLY-6661.
--------------------------------
    Fix Version/s: 12.0.0.Alpha1
       Resolution: Duplicate Issue


> Bean level lock type not applied
> --------------------------------
>
>                 Key: WFLY-6661
>                 URL: https://issues.jboss.org/browse/WFLY-6661
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final
>            Reporter: Keio Kraaner
>             Fix For: 12.0.0.Alpha1
>
>
> A singleton EJB has @Lock(LockType.READ) annotation declared on the class level.
> The bean is accessed using a local (defined by @Local annotation) or remote (defined by @Remote annotation) EJB interface.
> SingletonComponent::getLockType returns wrong value (LockType.WRITE) because the beanLevelLockType map does not contain a key equal to the local or remote interface class name. It contains a key equal to the EJB class name that implements those interfaces.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 05:45:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 18 Jan 2018 05:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9128) Upgrade Apache CXF to 3.2
In-Reply-To: <JIRA.12704639.1500992195000@Atlassian.JIRA>
References: <JIRA.12704639.1500992195000@Atlassian.JIRA>
	<JIRA.12704639.1500992195000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12704639.1500992195000.62901.1516272300604@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9128:
--------------------------------
    Summary: Upgrade Apache CXF to 3.2  (was: Upgrade Apache CXF to 3.1.13)


> Upgrade Apache CXF to 3.2
> -------------------------
>
>                 Key: WFLY-9128
>                 URL: https://issues.jboss.org/browse/WFLY-9128
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Services
>            Reporter: Ivo Studensky
>            Assignee: Alessio Soldano
>              Labels: downstream_dependency
>
> Upgrade Apache CXF to 3.1.13.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 05:45:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 18 Jan 2018 05:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9128) Upgrade to JAXB 2.3 / JBossWS
 5.2 / CXF 3.2
In-Reply-To: <JIRA.12704639.1500992195000@Atlassian.JIRA>
References: <JIRA.12704639.1500992195000@Atlassian.JIRA>
	<JIRA.12704639.1500992195000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12704639.1500992195000.62915.1516272300946@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9128:
--------------------------------
    Summary: Upgrade to JAXB 2.3 / JBossWS 5.2 / CXF 3.2  (was: Upgrade Apache CXF to 3.2)


> Upgrade to JAXB 2.3 / JBossWS 5.2 / CXF 3.2
> -------------------------------------------
>
>                 Key: WFLY-9128
>                 URL: https://issues.jboss.org/browse/WFLY-9128
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Services
>            Reporter: Ivo Studensky
>            Assignee: Alessio Soldano
>              Labels: downstream_dependency
>
> Upgrade Apache CXF to 3.1.13.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 05:46:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 18 Jan 2018 05:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9128) Upgrade to JAXB 2.3 / JBossWS
 5.2 / CXF 3.2
In-Reply-To: <JIRA.12704639.1500992195000@Atlassian.JIRA>
References: <JIRA.12704639.1500992195000@Atlassian.JIRA>
	<JIRA.12704639.1500992195000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12704639.1500992195000.62921.1516272360590@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9128?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9128:
--------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/10604  (was: https://github.com/wildfly/wildfly/pull/10751)


> Upgrade to JAXB 2.3 / JBossWS 5.2 / CXF 3.2
> -------------------------------------------
>
>                 Key: WFLY-9128
>                 URL: https://issues.jboss.org/browse/WFLY-9128
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web Services
>            Reporter: Ivo Studensky
>            Assignee: Alessio Soldano
>              Labels: downstream_dependency
>
> Upgrade Apache CXF to 3.1.13.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 06:51:00 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Thu, 18 Jan 2018 06:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1279) principal-query attribute of
 jdbc-realm is required but description says false
In-Reply-To: <JIRA.12700605.1499185654000@Atlassian.JIRA>
References: <JIRA.12700605.1499185654000@Atlassian.JIRA>
	<JIRA.12700605.1499185654000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12700605.1499185654000.63404.1516276260375@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1279?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges reassigned ELY-1279:
---------------------------------

    Assignee: Yeray Borges


> principal-query attribute of jdbc-realm is required but description says false
> ------------------------------------------------------------------------------
>
>                 Key: ELY-1279
>                 URL: https://issues.jboss.org/browse/ELY-1279
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Claudio Miranda
>            Assignee: Yeray Borges
>
> jdbc-realm description, for principal-query attribute says it is required=false, nillable=true, but that is false, because a jdbc-realm cannot be added without a principal-query.
> {code}
>  /profile=full/subsystem=elytron/jdbc-realm=*:read-resource-description
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("profile" => "full"),
>             ("subsystem" => "elytron"),
>             ("jdbc-realm" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => "A security realm definition backed by database using JDBC.",
>             "capabilities" => [{
>                 "name" => "org.wildfly.security.security-realm",
>                 "dynamic" => true
>             }],
>             "access-constraints" => {
>                 "sensitive" => {"elytron-security" => {"type" => "elytron"}},
>                 "application" => {"elytron-security" => {"type" => "elytron"}}
>             },
>             "attributes" => {"principal-query" => {
>                 "type" => LIST,
>                 "description" => "The authentication query used to authenticate users based on specific key types.",
>                 "expressions-allowed" => false,
>                 "required" => false,
>                 "nillable" => true,
>                 "value-type" => {
> {code}
> The add operation with no principal-query
> {code}
> /profile=full/subsystem=elytron/jdbc-realm=jdbc2:add
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0155: 'principal-query' may not be null"},
>     "rolled-back" => true
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 06:53:00 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Thu, 18 Jan 2018 06:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3518) principal-query attribute
 of jdbc-realm is required but description says false
In-Reply-To: <JIRA.12700605.1499185654000@Atlassian.JIRA>
References: <JIRA.12700605.1499185654000@Atlassian.JIRA>
	<JIRA.12700605.1499185654000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12700605.1499185654000.63433.1516276380555@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3518?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges moved ELY-1279 to WFCORE-3518:
-------------------------------------------

    Project: WildFly Core  (was: WildFly Elytron)
        Key: WFCORE-3518  (was: ELY-1279)


> principal-query attribute of jdbc-realm is required but description says false
> ------------------------------------------------------------------------------
>
>                 Key: WFCORE-3518
>                 URL: https://issues.jboss.org/browse/WFCORE-3518
>             Project: WildFly Core
>          Issue Type: Bug
>            Reporter: Claudio Miranda
>            Assignee: Yeray Borges
>
> jdbc-realm description, for principal-query attribute says it is required=false, nillable=true, but that is false, because a jdbc-realm cannot be added without a principal-query.
> {code}
>  /profile=full/subsystem=elytron/jdbc-realm=*:read-resource-description
> {
>     "outcome" => "success",
>     "result" => [{
>         "address" => [
>             ("profile" => "full"),
>             ("subsystem" => "elytron"),
>             ("jdbc-realm" => "*")
>         ],
>         "outcome" => "success",
>         "result" => {
>             "description" => "A security realm definition backed by database using JDBC.",
>             "capabilities" => [{
>                 "name" => "org.wildfly.security.security-realm",
>                 "dynamic" => true
>             }],
>             "access-constraints" => {
>                 "sensitive" => {"elytron-security" => {"type" => "elytron"}},
>                 "application" => {"elytron-security" => {"type" => "elytron"}}
>             },
>             "attributes" => {"principal-query" => {
>                 "type" => LIST,
>                 "description" => "The authentication query used to authenticate users based on specific key types.",
>                 "expressions-allowed" => false,
>                 "required" => false,
>                 "nillable" => true,
>                 "value-type" => {
> {code}
> The add operation with no principal-query
> {code}
> /profile=full/subsystem=elytron/jdbc-realm=jdbc2:add
> {
>     "outcome" => "failed",
>     "failure-description" => {"domain-failure-description" => "WFLYCTL0155: 'principal-query' may not be null"},
>     "rolled-back" => true
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 06:54:01 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Thu, 18 Jan 2018 06:54:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9706) Newly added
 InfiniteOrPositiveValidators to messaging attributes should just print
 warning if negative values is not -1
In-Reply-To: <JIRA.12729721.1516276400000@Atlassian.JIRA>
References: <JIRA.12729721.1516276400000@Atlassian.JIRA>
	<JIRA.12729721.1516276400964@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729721.1516276400000.63462.1516276441674@Atlassian.JIRA>

Erich Duda created WFLY-9706:
--------------------------------

             Summary: Newly added InfiniteOrPositiveValidators to messaging attributes should just print warning if negative values is not -1
                 Key: WFLY-9706
                 URL: https://issues.jboss.org/browse/WFLY-9706
             Project: WildFly
          Issue Type: Bug
          Components: JMS
    Affects Versions: 12.0.0.Alpha1
            Reporter: Erich Duda
            Assignee: Jeff Mesnil
            Priority: Blocker


This Jira is reaction to WFLY-9433.

The WFLY-9433 makes validator rules more strict for some attributes in messaging subsystem. Although there is no reason to use these values (which are newly considered as invalid), it was possible to configure them and they worked with Wildfly 11 and previous releases.

As it is proposed in JBEAP-14110, this change should be done in 2 steps:
* only WARN the user if the parameter is not valid (a negative value other than -1)
* in next release, reject the parameter

I am setting priority as Blocker, because this fix must be included in Wildfly 12 release. It makes no sense to do it later.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 06:56:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Thu, 18 Jan 2018 06:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9706) Newly added
 InfiniteOrPositiveValidators to messaging attributes should just print
 warning if negative values are not -1
In-Reply-To: <JIRA.12729721.1516276401000@Atlassian.JIRA>
References: <JIRA.12729721.1516276401000@Atlassian.JIRA>
	<JIRA.12729721.1516276401000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729721.1516276401000.63492.1516276560182@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9706?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Erich Duda updated WFLY-9706:
-----------------------------
    Summary: Newly added InfiniteOrPositiveValidators to messaging attributes should just print warning if negative values are not -1  (was: Newly added InfiniteOrPositiveValidators to messaging attributes should just print warning if negative values is not -1)


> Newly added InfiniteOrPositiveValidators to messaging attributes should just print warning if negative values are not -1
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9706
>                 URL: https://issues.jboss.org/browse/WFLY-9706
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 12.0.0.Alpha1
>            Reporter: Erich Duda
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> This Jira is reaction to WFLY-9433.
> The WFLY-9433 makes validator rules more strict for some attributes in messaging subsystem. Although there is no reason to use these values (which are newly considered as invalid), it was possible to configure them and they worked with Wildfly 11 and previous releases.
> As it is proposed in JBEAP-14110, this change should be done in 2 steps:
> * only WARN the user if the parameter is not valid (a negative value other than -1)
> * in next release, reject the parameter
> I am setting priority as Blocker, because this fix must be included in Wildfly 12 release. It makes no sense to do it later.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 06:57:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 18 Jan 2018 06:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3515) Tests for enhanced CLI to
 support Aesh Commands
In-Reply-To: <JIRA.12729495.1516197231000@Atlassian.JIRA>
References: <JIRA.12729495.1516197231000@Atlassian.JIRA>
	<JIRA.12729495.1516197231000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729495.1516197231000.63497.1516276620288@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3515?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-3515:
----------------------------------
    Component/s: CLI


> Tests for enhanced CLI to support Aesh Commands
> -----------------------------------------------
>
>                 Key: WFCORE-3515
>                 URL: https://issues.jboss.org/browse/WFCORE-3515
>             Project: WildFly Core
>          Issue Type: Task
>          Components: CLI
>            Reporter: Marek Kopeck?
>            Assignee: Marek Kopeck?
>
> Tests for enhanced CLI to support Aesh Commands



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 18 06:58:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 18 Jan 2018 06:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9620)
 ServletContext.getResourceAsStream,
 for deployments which have (Java EE) servlet overlays,
 serves files which are outside of the deployment
In-Reply-To: <JIRA.12725560.1513662272000@Atlassian.JIRA>
References: <JIRA.12725560.1513662272000@Atlassian.JIRA>
	<JIRA.12725560.1513662272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725560.1513662272000.63518.1516276680706@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-9620:
---------------------------------
    Security:     (was: Security Issue)


> ServletContext.getResourceAsStream, for deployments which have (Java EE) servlet overlays, serves files which are outside of the deployment
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9620
>                 URL: https://issues.jboss.org/browse/WFLY-9620
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 9.0.2.Final, 10.1.0.Final, 11.0.0.Final
>            Reporter: Laurent ROUSSEL
>            Assignee: Stuart Douglas
>            Priority: Critical
>             Fix For: 12.0.0.Alpha1
>
>
> A user has reported in the forums that there appears to be an issue (since 9.0.x till present 11.0.0 WildFly releases) where files like `/etc/passwd` are served by the web container to the clients, when the client requests a crafted URL against a Java EE deployment which has (Java EE) servlet overlays. Please see the referenced forum thread[1] for more details.
> Although, the steps noted in that thread involves Spring framework and gets triggered in a very specific way, the root cause appears to be the call to `ServletContext.getResourceAsInputStream` (which is what the spring framework ends up calling with a path like "/../../../../../../../..//etc/passwd", ends up actually serving the resource even if the path is outside the scope of the deployment to which the servlet context belongs.
> I could reproduce this against the latest WildFly in a simple test case that's here [2]
> [1] https://developer.jboss.org/thread/276826
> [2] https://github.com/jaikiran/wildfly/commit/ed05258aa824ab91a52ef6554e9707531a2cc83b
> P.S: The credit for reporting this issue should go to Laurent Roussel who reported this in the forum thread, but I don't have access to change the "Reporter" field of the JIRA



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 07:42:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 18 Jan 2018 07:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3519) Add JASPI Module
In-Reply-To: <JIRA.12729731.1516279300000@Atlassian.JIRA>
References: <JIRA.12729731.1516279300000@Atlassian.JIRA>
	<JIRA.12729731.1516279300759@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729731.1516279300000.63936.1516279320437@Atlassian.JIRA>

Darran Lofthouse created WFCORE-3519:
----------------------------------------

             Summary: Add JASPI Module
                 Key: WFCORE-3519
                 URL: https://issues.jboss.org/browse/WFCORE-3519
             Project: WildFly Core
          Issue Type: Task
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 4.0.0.Alpha6


(Copy from WildFly)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 07:45:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 18 Jan 2018 07:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9707) Remove JASPI module
In-Reply-To: <JIRA.12729733.1516279470000@Atlassian.JIRA>
References: <JIRA.12729733.1516279470000@Atlassian.JIRA>
	<JIRA.12729733.1516279470028@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729733.1516279470000.63959.1516279500718@Atlassian.JIRA>

Darran Lofthouse created WFLY-9707:
--------------------------------------

             Summary: Remove JASPI module
                 Key: WFLY-9707
                 URL: https://issues.jboss.org/browse/WFLY-9707
             Project: WildFly
          Issue Type: Task
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 12.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 07:50:00 2018
From: issues at jboss.org (Luis Canales (JIRA))
Date: Thu, 18 Jan 2018 07:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279794000@Atlassian.JIRA>
References: <JIRA.12729735.1516279794000@Atlassian.JIRA>
	<JIRA.12729735.1516279794771@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279794000.64009.1516279800190@Atlassian.JIRA>

Luis Canales created WFLY-9708:
----------------------------------

             Summary: Wildfly 11.0.0.Final JSF 1.2 configuration error
                 Key: WFLY-9708
                 URL: https://issues.jboss.org/browse/WFLY-9708
             Project: WildFly
          Issue Type: Bug
          Components: CDI / Weld, JSF
    Affects Versions: 11.0.0.Final
            Reporter: Luis Canales
            Assignee: Martin Kouba
            Priority: Optional
         Attachments: log.txt

Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF 2.0 so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) an deploy a JSF1.2 application, I get this error:

java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper

If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 07:52:00 2018
From: issues at jboss.org (Luis Canales (JIRA))
Date: Thu, 18 Jan 2018 07:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279795000@Atlassian.JIRA>
References: <JIRA.12729735.1516279795000@Atlassian.JIRA>
	<JIRA.12729735.1516279795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279795000.64022.1516279920779@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Canales updated WFLY-9708:
-------------------------------
    Description: 
Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF 2.0 so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:

java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper

If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.

  was:
Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF 2.0 so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) an deploy a JSF1.2 application, I get this error:

java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper

If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



> Wildfly 11.0.0.Final JSF 1.2 configuration error
> ------------------------------------------------
>
>                 Key: WFLY-9708
>                 URL: https://issues.jboss.org/browse/WFLY-9708
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 11.0.0.Final
>            Reporter: Luis Canales
>            Assignee: Martin Kouba
>            Priority: Optional
>         Attachments: log.txt
>
>
> Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF 2.0 so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:
> java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper
> If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 07:52:00 2018
From: issues at jboss.org (Luis Canales (JIRA))
Date: Thu, 18 Jan 2018 07:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279795000@Atlassian.JIRA>
References: <JIRA.12729735.1516279795000@Atlassian.JIRA>
	<JIRA.12729735.1516279795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279795000.64027.1516279920906@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Canales updated WFLY-9708:
-------------------------------
    Description: 
Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF 2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:

java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper

If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.

  was:
Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF 2.0 so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:

java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper

If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



> Wildfly 11.0.0.Final JSF 1.2 configuration error
> ------------------------------------------------
>
>                 Key: WFLY-9708
>                 URL: https://issues.jboss.org/browse/WFLY-9708
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 11.0.0.Final
>            Reporter: Luis Canales
>            Assignee: Martin Kouba
>            Priority: Optional
>         Attachments: log.txt
>
>
> Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF 2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:
> java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper
> If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 07:53:00 2018
From: issues at jboss.org (Luis Canales (JIRA))
Date: Thu, 18 Jan 2018 07:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279795000@Atlassian.JIRA>
References: <JIRA.12729735.1516279795000@Atlassian.JIRA>
	<JIRA.12729735.1516279795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279795000.64035.1516279980414@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Canales updated WFLY-9708:
-------------------------------
    Description: 
Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF 2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:

_java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_

If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.

  was:
Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF 2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:

java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper

If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



> Wildfly 11.0.0.Final JSF 1.2 configuration error
> ------------------------------------------------
>
>                 Key: WFLY-9708
>                 URL: https://issues.jboss.org/browse/WFLY-9708
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 11.0.0.Final
>            Reporter: Luis Canales
>            Assignee: Martin Kouba
>            Priority: Optional
>         Attachments: log.txt
>
>
> Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF 2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:
> _java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_
> If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 07:56:00 2018
From: issues at jboss.org (Luis Canales (JIRA))
Date: Thu, 18 Jan 2018 07:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279795000@Atlassian.JIRA>
References: <JIRA.12729735.1516279795000@Atlassian.JIRA>
	<JIRA.12729735.1516279795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279795000.64064.1516280160946@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Canales updated WFLY-9708:
-------------------------------
    Description: 
Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:

_java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_

If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.

  was:
Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF 2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:

_java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_

If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



> Wildfly 11.0.0.Final JSF 1.2 configuration error
> ------------------------------------------------
>
>                 Key: WFLY-9708
>                 URL: https://issues.jboss.org/browse/WFLY-9708
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 11.0.0.Final
>            Reporter: Luis Canales
>            Assignee: Martin Kouba
>            Priority: Optional
>         Attachments: log.txt
>
>
> Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:
> _java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_
> If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 08:07:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 18 Jan 2018 08:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9671) Upgrade Narayana to
	5.5.31.Final
In-Reply-To: <JIRA.12727980.1516011234000@Atlassian.JIRA>
References: <JIRA.12727980.1516011234000@Atlassian.JIRA>
	<JIRA.12727980.1516011234000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727980.1516011234000.64135.1516280820332@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9671:
--------------------------------
    Labels: downstream_dependency  (was: )


> Upgrade Narayana to 5.5.31.Final
> --------------------------------
>
>                 Key: WFLY-9671
>                 URL: https://issues.jboss.org/browse/WFLY-9671
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>              Labels: downstream_dependency
>
> https://issues.jboss.org/secure/ReleaseNote.jspa?projectId=12310200&version=12336596



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 08:07:00 2018
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 18 Jan 2018 08:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279795000@Atlassian.JIRA>
References: <JIRA.12729735.1516279795000@Atlassian.JIRA>
	<JIRA.12729735.1516279795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279795000.64140.1516280820448@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520756#comment-13520756 ] 

Martin Kouba commented on WFLY-9708:
------------------------------------

Weld 2.x (Java EE 7) is not supposed to work with JSF 1.2 (Java EE 5). Do you use CDI in your application? If not, you may disable CDI completely:
1. If your app does not contain any {{beans.xml}}, it is possible to [suppress implicit bean archives|https://docs.jboss.org/author/display/WFLY/CDI+Reference#CDIReference-Suppressingimplicitbeanarchives]
2. Otherwise use {{jboss-deployment-structure}} to exclude the Weld subsystem (like in [this example|https://developer.jboss.org/people/mkouba/blog/2014/03/04/lighten-the-deployment-of-a-cdi-application-on-wildfly])

> Wildfly 11.0.0.Final JSF 1.2 configuration error
> ------------------------------------------------
>
>                 Key: WFLY-9708
>                 URL: https://issues.jboss.org/browse/WFLY-9708
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 11.0.0.Final
>            Reporter: Luis Canales
>            Assignee: Martin Kouba
>            Priority: Optional
>         Attachments: log.txt
>
>
> Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:
> _java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_
> If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 08:13:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 18 Jan 2018 08:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6263) Apostrophe in an attribute
 with multiple EL parts breaks function lookup
In-Reply-To: <JIRA.12607431.1456247382000@Atlassian.JIRA>
References: <JIRA.12607431.1456247382000@Atlassian.JIRA>
	<JIRA.12607431.1456247382000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12607431.1456247382000.64177.1516281180463@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-6263:
--------------------------------
    Labels: downstream_dependency  (was: )


> Apostrophe in an attribute with multiple EL parts breaks function lookup
> ------------------------------------------------------------------------
>
>                 Key: WFLY-6263
>                 URL: https://issues.jboss.org/browse/WFLY-6263
>             Project: WildFly
>          Issue Type: Bug
>          Components: EE, Web (Undertow)
>    Affects Versions: 10.0.0.Final
>            Reporter: Paul Pogonyshev
>            Assignee: Tomaz Cerar
>            Priority: Critical
>              Labels: downstream_dependency
>         Attachments: jastow-bug.war.zip, jastow.diff
>
>
> Certain EL pieces result in unexplained org.apache.jasper.JasperException "contains invalid expression(s)" (the exception _does not_ explain what is invalid). After lots of tries, I have narrowed it down: 1) there must be several EL pieces in one string; 2) there must be an apostrophe in between.
> This looks very similar to bug WFLY-4455. It breaks several pages in our application, blocking upgrade to WildFly 10.
> Example is attached.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 09:02:01 2018
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Thu, 18 Jan 2018 09:02:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7647) Configure Artemis thread pool
 size without reload
In-Reply-To: <JIRA.12663013.1479807983000@Atlassian.JIRA>
References: <JIRA.12663013.1479807983000@Atlassian.JIRA>
	<JIRA.12663013.1479807983000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663013.1479807983000.64535.1516284121055@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak closed WFLY-7647.
--------------------------------
    Resolution: Done


> Configure Artemis thread pool size without reload
> -------------------------------------------------
>
>                 Key: WFLY-7647
>                 URL: https://issues.jboss.org/browse/WFLY-7647
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 10.1.0.Final
>            Reporter: Martin Styk
>            Assignee: Jeff Mesnil
>
> Currently, thread pool size can not be adjusted without server reload. If server runs into performance problem caused by thread pool size, there is no way to adjust thread pool size without termination of all running tasks. Making this configurable "on fly" would prevent this scenario. 
> Attribute {{thread-pool-max-size}} in {{/subsystem=messaging-activemq/server=default}} requires server reload.
> Size of global client thread pools can be set only before this thread pool is created. Adjusting values of system properties which configure client thread pool size has no effect on running server (with pool already created). 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 09:02:01 2018
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Thu, 18 Jan 2018 09:02:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7647) Configure Artemis thread pool
 size without reload
In-Reply-To: <JIRA.12663013.1479807983000@Atlassian.JIRA>
References: <JIRA.12663013.1479807983000@Atlassian.JIRA>
	<JIRA.12663013.1479807983000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663013.1479807983000.64545.1516284121324@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak reopened WFLY-7647:
----------------------------------


> Configure Artemis thread pool size without reload
> -------------------------------------------------
>
>                 Key: WFLY-7647
>                 URL: https://issues.jboss.org/browse/WFLY-7647
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 10.1.0.Final
>            Reporter: Martin Styk
>            Assignee: Jeff Mesnil
>
> Currently, thread pool size can not be adjusted without server reload. If server runs into performance problem caused by thread pool size, there is no way to adjust thread pool size without termination of all running tasks. Making this configurable "on fly" would prevent this scenario. 
> Attribute {{thread-pool-max-size}} in {{/subsystem=messaging-activemq/server=default}} requires server reload.
> Size of global client thread pools can be set only before this thread pool is created. Adjusting values of system properties which configure client thread pool size has no effect on running server (with pool already created). 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 09:02:01 2018
From: issues at jboss.org (Miroslav Novak (JIRA))
Date: Thu, 18 Jan 2018 09:02:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7647) Configure Artemis thread pool
 size without reload
In-Reply-To: <JIRA.12663013.1479807983000@Atlassian.JIRA>
References: <JIRA.12663013.1479807983000@Atlassian.JIRA>
	<JIRA.12663013.1479807983000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663013.1479807983000.64551.1516284121469@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Miroslav Novak closed WFLY-7647.
--------------------------------
    Resolution: Won't Fix


> Configure Artemis thread pool size without reload
> -------------------------------------------------
>
>                 Key: WFLY-7647
>                 URL: https://issues.jboss.org/browse/WFLY-7647
>             Project: WildFly
>          Issue Type: Enhancement
>          Components: JMS
>    Affects Versions: 10.1.0.Final
>            Reporter: Martin Styk
>            Assignee: Jeff Mesnil
>
> Currently, thread pool size can not be adjusted without server reload. If server runs into performance problem caused by thread pool size, there is no way to adjust thread pool size without termination of all running tasks. Making this configurable "on fly" would prevent this scenario. 
> Attribute {{thread-pool-max-size}} in {{/subsystem=messaging-activemq/server=default}} requires server reload.
> Size of global client thread pools can be set only before this thread pool is created. Adjusting values of system properties which configure client thread pool size has no effect on running server (with pool already created). 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 09:23:00 2018
From: issues at jboss.org (=?UTF-8?Q?Jan_Bliz=C5=88=C3=A1k_=28JIRA=29?=)
Date: Thu, 18 Jan 2018 09:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3520) Better naming in tests for
	WFCORE-3363
In-Reply-To: <JIRA.12729766.1516285332000@Atlassian.JIRA>
References: <JIRA.12729766.1516285332000@Atlassian.JIRA>
	<JIRA.12729766.1516285332147@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729766.1516285332000.64710.1516285380999@Atlassian.JIRA>

Jan Bliz??k created WFCORE-3520:
-----------------------------------

             Summary: Better naming in tests for WFCORE-3363
                 Key: WFCORE-3520
                 URL: https://issues.jboss.org/browse/WFCORE-3520
             Project: WildFly Core
          Issue Type: Enhancement
          Components: CLI
    Affects Versions: 4.0.0.Alpha5
            Reporter: Jan Bliz??k
            Priority: Minor


There were some tests added within WFCORE-3363, this jira is just about give them better names instead of testXXX1, testXXX2 etc.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 18 09:52:01 2018
From: issues at jboss.org (=?UTF-8?Q?Jan_Bliz=C5=88=C3=A1k_=28JIRA=29?=)
Date: Thu, 18 Jan 2018 09:52:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3520) Better naming in tests for
	WFCORE-3363
In-Reply-To: <JIRA.12729766.1516285332000@Atlassian.JIRA>
References: <JIRA.12729766.1516285332000@Atlassian.JIRA>
	<JIRA.12729766.1516285332000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729766.1516285332000.65060.1516287121655@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3520?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Bliz??k reassigned WFCORE-3520:
-----------------------------------

    Assignee: Jan Bliz??k


> Better naming in tests for WFCORE-3363
> --------------------------------------
>
>                 Key: WFCORE-3520
>                 URL: https://issues.jboss.org/browse/WFCORE-3520
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Jan Bliz??k
>            Assignee: Jan Bliz??k
>            Priority: Minor
>
> There were some tests added within WFCORE-3363, this jira is just about give them better names instead of testXXX1, testXXX2 etc.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 18 10:01:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 18 Jan 2018 10:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9706) Newly added
 InfiniteOrPositiveValidators to messaging attributes should just print
 warning if negative values are not -1
In-Reply-To: <JIRA.12729721.1516276401000@Atlassian.JIRA>
References: <JIRA.12729721.1516276401000@Atlassian.JIRA>
	<JIRA.12729721.1516276401000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729721.1516276401000.65247.1516287660532@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520859#comment-13520859 ] 

Brian Stansberry commented on WFLY-9706:
----------------------------------------

If a negative value other than -1 was allowed before but we don't want to allow it any more, then use a ParameterCorrector to correct it.

> Newly added InfiniteOrPositiveValidators to messaging attributes should just print warning if negative values are not -1
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9706
>                 URL: https://issues.jboss.org/browse/WFLY-9706
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 12.0.0.Alpha1
>            Reporter: Erich Duda
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> This Jira is reaction to WFLY-9433.
> The WFLY-9433 makes validator rules more strict for some attributes in messaging subsystem. Although there is no reason to use these values (which are newly considered as invalid), it was possible to configure them and they worked with Wildfly 11 and previous releases.
> As it is proposed in JBEAP-14110, this change should be done in 2 steps:
> * only WARN the user if the parameter is not valid (a negative value other than -1)
> * in next release, reject the parameter
> I am setting priority as Blocker, because this fix must be included in Wildfly 12 release. It makes no sense to do it later.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 10:42:01 2018
From: issues at jboss.org (Nuno Godinho de Matos (JIRA))
Date: Thu, 18 Jan 2018 10:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9542) Iron JAC Amar is being told
 to create more KeyConnectionAssociation under CachedConnectionManagerImpl
 then actual JTA transactions open (Reproducible with NESTED EJB calls)
In-Reply-To: <JIRA.12720207.1510223589000@Atlassian.JIRA>
References: <JIRA.12720207.1510223589000@Atlassian.JIRA>
	<JIRA.12720207.1510223589000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720207.1510223589000.65814.1516290121049@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520938#comment-13520938 ] 

Nuno Godinho de Matos commented on WFLY-9542:
---------------------------------------------

NOTE:

On the topic of this issue the following should be added.
1. The sample application - has two small issues to being built with mvn clean install
(a) Right now it refers a eclipselink library 2.6.6.0.2 that was assembled on my machine and therefore can not be found externally of my local repository
(b) the Sub-modules have a copy paste mistake where the paren-pom still refers to a different sample project and should be remapped to the Root project name.
I will in the upcoming days fix this.

The more important points is that we have determined that the CachedConnection manager that is reporting this exception can be tweaked to no being used, if in the data source configuration we delared us-ccm="false".
So in fact, without needing to modify any source code, the exception can really be made to disappear trivially.

This of course does not imply that Wildfly ironjacamar layer does not have an issue when nested EJB calls are taking place and the jta transaction is remaining the same.

For now, we will limit ourselves to disable the use-ccm flag, since the documentation from wildfly indicates that this is a debug feature. We will assume this is a sufficient fix and that the bug is in the cached connection manager code itself.

Many thanks.

> Iron JAC Amar is being told to create more KeyConnectionAssociation under CachedConnectionManagerImpl then actual JTA transactions open (Reproducible with NESTED EJB calls)
> ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9542
>                 URL: https://issues.jboss.org/browse/WFLY-9542
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.1.0.Final
>            Reporter: Nuno Godinho de Matos
>              Labels: Arjuna, IronJacamar, JTA
>
> I have been trying to understand for what reason we sometimes are seing the exception:
> {panel}
> IJ000311: Throwable from unregister connection: java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 2021ff6.
> {panel}
> I have now created a sample application that allows the exception to be reproduced:
> https://github.com/99sono/wildlfly-ironjacamar-unregisterconnection/
> To summarize:
> If we start a JTA transaction T1 by invoking an @EJB with TransacitonAttirbute RequiresNew.
> And then this EJB calls a second EJB with TransacitonAttirbute Supports.
> Then we will have the problem that if the First JDBC access is done on the nested EJB, the connection handed over to the JPA layer (eclipselink) will be popped out of the
> org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.currentObjects
> As soon as we come out of the Nested EJB call.
> I do not know how serious this is.
> If somehow the popped out connection continues in fact locked to the ongoing JTA transaction or if might be going back to the connection pool and potentially be up for grabs.
> This I do not know how... I lack the knowledge to say how crucial it is to have a good synchrinization between the connections being managed under the:
> org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl
> And the JPA layer.
> But intuitively, I would say: quite important.
> So whenever a Stack gets popped with connections being managed, I would intuitively say: one of the parties has done something wrong. Either:
> (a) ARJUNA is asking JAC AMAR to open stacks when the JTA transaction is the same and it shouldn't, or
> (b) It does not really matter that the conneciton is popped out - somehow JAC AMAR still knows that the connection it popped out is still bound to the JTA transaction and the problem is logically strange but of low impact...
> What appears to be true, is that eclipselink is doing something logicla, in the sense that it is only asking for the conneciton to be closed/unregistered at the end of the JTA transaction.
> NOTE:
> In fact the error that we see when we get the stack trace, could also happen and no stack trance be logged by jac AMAR. 
> This is the scenario when JAC  leaves the unregister conneciton via:
> org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl would be going out via the:
> {panel}
> CopyOnWriteArrayList<ConnectionRecord> conns = cmToConnectionsMap.get(cm);
>       // Can happen if connections are "passed" between contexts
>       if (conns == null)
>          return; 
> {panel}
> But in my oppinion this exit path deserves the exact same stack trace.
> The sample application is to be found here:
> https://github.com/99sono/wildlfly-ironjacamar-unregisterconnection/
> This sample application is not as simple to deploy because one needs to hava a data source configured.
> In any case the sample application has in src/test/resources my standalone.xml.
> It should be realtively easy to fix the JDBC drivers configured in the atnadlone.xml.
> And it should be relatively simple to fix the persistence.xml to search for eclipselink in the appropriate moduel.
> I will no copy paste bellow the LOG of the exception of the sample application.
> {panel}
> 2017-11-09 10:20:00,918 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) 
> --------------------------------------
> -- STARTING TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING >: observing the CDI event StartupEventToTryToReproduceIJ000311Issue  
> --------------------------------------
> 2017-11-09 10:20:00,919 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Doing a fetch ALL query. just to bind the connection manager to the KEY of stack level 1.
> 2017-11-09 10:20:01,033 FINE  [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) Eclipselink connected (jndiName: java:/jdbc/SAMPLE_DS)- obtaining connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 1d5b3a43. Eclipselink Server session is: ServerSession(
> 	DatabaseAccessor(connected)
> 	PostgreSQLPlatform)   
> 2017-11-09 10:20:01,057 FINE  [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) EclipseLink - Closing connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 1d5b3a43
> 2017-11-09 10:20:01,063 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) At this point the org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl will have  registered on stack1 the connection used by eclipselink, and unregistered as well.
>  However, this temporary register/de-register is sufficient to add to the current key.getCMToConnectionsMap()  and entry for the JDBC connection manger.
>   This is fundamental, because without this step the exception that we will later see would be hidden away - even though the logical problem would be there no exception would be logged.  By taking this magical step here, we have ensured that we will be able to reproduce the excpetion later. 
>    To summarize what has happend so far.
>  1. We have forced eclipselink to register and unregister a connection due to are fetch id query 
>  2. The JTA transaction ID TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING >  continues healthy and running without any problem 3. Meanwhile internally, our CachedConnectionManagerImpl, for this thread, has a single task of keys in its currentObjects field 
>   4. The leading key on this stack does not hold any connectionrecords (eclipselink returned the connecton to the pool) but it does have a KEY for the JDBC connection manager 5. Point 4 is the magical step to allow us to see the stack trace but not the core of the issue - just the core of seing the stack trace 
> 2017-11-09 10:20:01,066 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) START: executoreSynchronousSameJta 
> 2017-11-09 10:20:01,066 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Right now we are within the same JTA transaction. But on a NESTED EJB call.
>   What technically has happened at this point is that IRON JAC AMAR now has a second stack (keyAssociation)
>   in the currentObjects. We add in stacks each time we go through an EJB evne if we keep the JTA transaction
>   and this is the BUG. But we will see more about this later.
>  
> 2017-11-09 10:20:01,066 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) STARTING 3: observing the CDI event StartupEventToTryToReproduceIJ000311Issue - The current transaction id is: TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING > 
> 2017-11-09 10:20:01,066 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Going to create 50 entities on the database
> 2017-11-09 10:20:01,067 FINE  [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) Eclipselink connected (jndiName: jdbc/SAMPLE_NON_JTA_DS)- obtaining connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 4be2573e. Eclipselink Server session is: ClientSession({})   
> 2017-11-09 10:20:01,073 FINE  [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) EclipseLink - Closing connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 4be2573e
> 2017-11-09 10:20:01,078 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) 50 entities should have been created: 
> 2017-11-09 10:20:01,078 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) Now we want to flush - we want to force eclipselink to have to acquire the java:/jdbc/SAMPLE_DS and not be allowed to close the connection yet. 
> 2017-11-09 10:20:01,085 FINE  [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) Eclipselink connected (jndiName: java:/jdbc/SAMPLE_DS)- obtaining connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 2021ff6. Eclipselink Server session is: ClientSession({default=DatabaseAccessor(connected)})   
> 2017-11-09 10:20:01,101 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) The flush has been done. We expec that the log now shows us that java:/jdbc/SAMPLE_DS connection was acquired but not yet closed by eclipselink. 
> 2017-11-09 10:20:01,101 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) ENDING TransactionImple < ac, BasicAction: 0:ffffac140c58:634ef22a:5a041dbd:15 status: ActionStatus.RUNNING >: finishing to observer. The current transaction id is: {} 
> 2017-11-09 10:20:01,101 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) OK. Now we are about to leave our nested EJB call. What is happening now is very important. 
> 1. We will leave a nested EJB call but not the JTA transaction 2. Wildfly will go to the cachedConnectonManagerImpl and tell it to pop a stack (BUG) 3. The stack that goes away is actually holding the JDBC connection thta has been given to ECLIPSELINK and thta eclipselink will later try to close 4. When we leave this call we go back to STACK 1, where no connections are being managed
> 2017-11-09 10:20:01,102 INFO  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73)  FINISH: executoreSynchronousSameJta:
>  
> 2017-11-09 10:20:01,102 WARN  [startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb] (ServerService Thread Pool -- 73) NOW we are out of our nested EJB call. We are bout to leave the main EJB transaction call. 
> In short we are about to reproduce the stack trace. 
> What will now happen is the following. 
> 1. Wildfly will tell eclipselink that the transaction is at an end and it should commit if it can 
> 2. Eclipselink does its job of committing the changes and takes the JTA connection it was given and tries to close it 
> 3. IRON JAC AMAR will log the stack trace we wanted to reproduce saying it has not idea what connection we are trying to return to the pool. 
> 4. The reason the CachedConnectionManagerImpl does not know about the connection is because it was managed under STACK 2 but was popped out of existence after the nested transaction 
>  5. Now it is very important to keep in mind that even if we were not seing the stack trace  the error would be there (the moment we popped a key stack that had still connections) 6. Keep in mind that if we were to modify the source code  and disable our reproduceBugService.fetchAlIds() call we would see no stack trace but the same issue would be present.7. The difference that doing the reproduceBugService.fetchAlIds() does is whether or not CachedConnectionManagerImpl during unregister connection leaves via the if conns == null return null or if goes further into the if (!ignoreConnections)
>  8. OK - Now that we understand what is happening behind the scenes we can let eclipselink try to close the JDBC connection at the end of the JTA transaction
>  
> 2017-11-09 10:20:01,106 FINE  [org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor] (ServerService Thread Pool -- 73) EclipseLink - Closing connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 2021ff6
> 2017-11-09 10:20:01,107 INFO  [org.jboss.jca.core.connectionmanager.listener.TxConnectionListener] (ServerService Thread Pool -- 73) IJ000311: Throwable from unregister connection: java.lang.IllegalStateException: IJ000152: Trying to return an unknown connection: org.jboss.jca.adapters.jdbc.jdk7.WrappedConnectionJDK7 at 2021ff6
> 	at org.jboss.jca.core.connectionmanager.ccm.CachedConnectionManagerImpl.unregisterConnection(CachedConnectionManagerImpl.java:408)
> 	at org.jboss.jca.core.connectionmanager.listener.TxConnectionListener.connectionClosed(TxConnectionListener.java:645)
> 	at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.returnHandle(BaseWrapperManagedConnection.java:596)
> 	at org.jboss.jca.adapters.jdbc.BaseWrapperManagedConnection.closeHandle(BaseWrapperManagedConnection.java:541)
> 	at org.jboss.jca.adapters.jdbc.WrappedConnection.returnConnection(WrappedConnection.java:298)
> 	at org.jboss.jca.adapters.jdbc.WrappedConnection.close(WrappedConnection.java:256)
> 	at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.closeDatasourceConnection(DatabaseAccessor.java:522)
> 	at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.closeConnection(DatasourceAccessor.java:537)
> 	at org.eclipse.persistence.internal.databaseaccess.DatabaseAccessor.closeConnection(DatabaseAccessor.java:545)
> 	at org.eclipse.persistence.internal.databaseaccess.DatasourceAccessor.closeJTSConnection(DatasourceAccessor.java:188)
> 	at org.eclipse.persistence.sessions.server.ClientSession.releaseJTSConnection(ClientSession.java:171)
> 	at org.eclipse.persistence.transaction.AbstractSynchronizationListener.beforeCompletion(AbstractSynchronizationListener.java:175)
> 	at org.eclipse.persistence.transaction.JTASynchronizationListener.beforeCompletion(JTASynchronizationListener.java:68)
> 	at org.jboss.as.txn.service.internal.tsr.JCAOrderedLastSynchronizationList.beforeCompletion(JCAOrderedLastSynchronizationList.java:116)
> 	at com.arjuna.ats.internal.jta.resources.arjunacore.SynchronizationImple.beforeCompletion(SynchronizationImple.java:76)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.beforeCompletion(TwoPhaseCoordinator.java:368)
> 	at com.arjuna.ats.arjuna.coordinator.TwoPhaseCoordinator.end(TwoPhaseCoordinator.java:91)
> 	at com.arjuna.ats.arjuna.AtomicAction.commit(AtomicAction.java:162)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.TransactionImple.commitAndDisassociate(TransactionImple.java:1200)
> 	at com.arjuna.ats.internal.jta.transaction.arjunacore.BaseTransaction.commit(BaseTransaction.java:126)
> 	at com.arjuna.ats.jbossatx.BaseTransactionManagerDelegate.commit(BaseTransactionManagerDelegate.java:89)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.endTransaction(CMTTxInterceptor.java:91)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:279)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.requiresNew(CMTTxInterceptor.java:349)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:241)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.deployment.processors.StartupAwaitInterceptor.processInvocation(StartupAwaitInterceptor.java:22)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.ejb3.concurrency.ContainerManagedConcurrencyInterceptor.processInvocation(ContainerManagedConcurrencyInterceptor.java:110)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:67)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:198)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb$$$view9.observeStartupEventToTryToReproduceIJ000311Issue(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:433)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:128)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at startupconnectionproblem.observer.EventObserverNestedJtaTransactionEjb$Proxy$_$$_Weld$EnterpriseProxy$.observeStartupEventToTryToReproduceIJ000311Issue(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
> 	at org.jboss.weld.injection.MethodInvocationStrategy$SimpleMethodInvocationStrategy.invoke(MethodInvocationStrategy.java:129)
> 	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:313)
> 	at org.jboss.weld.event.ObserverMethodImpl.sendEvent(ObserverMethodImpl.java:291)
> 	at org.jboss.weld.event.ObserverMethodImpl.notify(ObserverMethodImpl.java:269)
> 	at org.jboss.weld.event.ObserverNotifier.notifySyncObservers(ObserverNotifier.java:302)
> 	at org.jboss.weld.event.ObserverNotifier.notify(ObserverNotifier.java:291)
> 	at org.jboss.weld.event.EventImpl.fire(EventImpl.java:89)
> 	at startupconnectionproblem.event.FireStartupEventsServiceImpl.fireStartupCDIEvents(FireStartupEventsServiceImpl.java:41)
> 	at startupconnectionproblem.event.FireStartupEventsServiceImpl$Proxy$_$$_WeldClientProxy.fireStartupCDIEvents(Unknown Source)
> 	at startupconnectionproblem.event.StartupSingletonLocalEjb.postConstrcut(StartupSingletonLocalEjb.java:38)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.jboss.as.ee.component.ManagedReferenceLifecycleMethodInterceptor.processInvocation(ManagedReferenceLifecycleMethodInterceptor.java:96)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doLifecycleInterception(Jsr299BindingsInterceptor.java:114)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:103)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:73)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:53)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.notSupported(LifecycleCMTTxInterceptor.java:87)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.singleton.StartupCountDownInterceptor.processInvocation(StartupCountDownInterceptor.java:25)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.getComponentInstance(SingletonComponent.java:124)
> 	at org.jboss.as.ejb3.component.singleton.SingletonComponent.start(SingletonComponent.java:138)
> 	at org.jboss.as.ee.component.ComponentStartService$1.run(ComponentStartService.java:54)
> 	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> 	at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 2017-11-09 10:20:01,114 INFO  [startupconnectionproblem.event.FireStartupEventsServiceImpl] (ServerService Thread Pool -- 73) FIINSH: StartupEventToTryToReproduceIJ000311Issue 
> 2017-11-09 10:20:01,114 INFO  [startupconnectionproblem.event.StartupSingletonLocalEjb] (ServerService Thread Pool -- 73) ENDING 1: Post construct of startup bean singleton ending
> 2017-11-09 10:20:01,240 INFO  [javax.enterprise.resource.webcontainer.jsf.config] (ServerService Thread Pool -- 73) Initializing Mojarra 2.2.13.SP1 20160303-1204 for context '/app'
> 2017-11-09 10:20:02,098 INFO  [org.primefaces.webapp.PostConstructA
> {panel}
> Thanks for considering this issue.
> I do not know how much impact this issue can actually have.
> We have many hundred different types of JTA business transactions, and we see this sample application happening on system tests and stress tests relatively often.
> Now that I have better understand of the issue, I can in some cases rework the code to dodge this problem to avoid nested calls of EJBS on the same transaciton - but this will not always be possible.
> And I would be quite afraid of this issue, if means that our connectons still in the hands of ElcipseLInk are going back to the pool.
> This would explain some strange errors we have had only on stress test application, that we do not see when using a different app server.
> I must say it was extremelly difficult to be able to make the stack trace reproducible.
> There are many tricky points to be able to lead the code to go precisely through the code path that leads to the excpetion.
> But it is relatively trivial to make the code leave through the "silent bug iron jac amar code path".
> Many thanks for all the help on this.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 10:58:00 2018
From: issues at jboss.org (Ken Wills (JIRA))
Date: Thu, 18 Jan 2018 10:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-938) Embedded host controller
 doesn't support --admin-mode=false option
In-Reply-To: <JIRA.12583214.1441008844000@Atlassian.JIRA>
References: <JIRA.12583214.1441008844000@Atlassian.JIRA>
	<JIRA.12583214.1441008844000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583214.1441008844000.66057.1516291080674@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-938?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills reassigned WFCORE-938:
--------------------------------

    Assignee: ehsavoie Hugonnet  (was: Ken Wills)


> Embedded host controller doesn't support --admin-mode=false option
> ------------------------------------------------------------------
>
>                 Key: WFCORE-938
>                 URL: https://issues.jboss.org/browse/WFCORE-938
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI, Domain Management
>    Affects Versions: 2.0.0.Beta4
>            Reporter: Petr Kremensky
>            Assignee: ehsavoie Hugonnet
>              Labels: domain-mode
>
> Embedded standalone instance supports two running modes depending on a value of admin-only option (true is default).
> * *true*
> ** only start services related to server administration
> ** do not start other services or accept end user requests.
> ** embedded instance will not be visible to remote management clients
> * *false*
> ** all services are started
> ** embedded instance is visible to remote management clients (e.g. EAP can be configured via admin console)
> Embedded host controller doesn't offer such a option and is started using --admin-only=true mode by default. Option to run embedded host controller instance with --admin-only=false should be available as well.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 10:58:00 2018
From: issues at jboss.org (Ken Wills (JIRA))
Date: Thu, 18 Jan 2018 10:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1187) Embedded server start /
 stop / start with new --jboss-home continues to refer to previous
 server.log
In-Reply-To: <JIRA.12595438.1449268036000@Atlassian.JIRA>
References: <JIRA.12595438.1449268036000@Atlassian.JIRA>
	<JIRA.12595438.1449268036000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12595438.1449268036000.66063.1516291080805@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills reassigned WFCORE-1187:
---------------------------------

    Assignee: ehsavoie Hugonnet  (was: Ken Wills)


> Embedded server start / stop / start with new --jboss-home continues to refer to previous server.log
> ----------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1187
>                 URL: https://issues.jboss.org/browse/WFCORE-1187
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Ken Wills
>            Assignee: ehsavoie Hugonnet
>
> - start-embedded-server --jboss-home=/foo/bar1
> - stop-embedded-server
> - start-embedded-server --jboss-home=/foo/bar2
> -- server.log in /foo/bar1/standalone/logs/server.log is still written to.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 10:58:00 2018
From: issues at jboss.org (Ken Wills (JIRA))
Date: Thu, 18 Jan 2018 10:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3103) Embedded server doesn't
 close open file handles
In-Reply-To: <JIRA.12704699.1501008359000@Atlassian.JIRA>
References: <JIRA.12704699.1501008359000@Atlassian.JIRA>
	<JIRA.12704699.1501008359000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12704699.1501008359000.66069.1516291080937@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3103?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills reassigned WFCORE-3103:
---------------------------------

    Assignee: ehsavoie Hugonnet  (was: Ken Wills)


> Embedded server doesn't close open file handles
> -----------------------------------------------
>
>                 Key: WFCORE-3103
>                 URL: https://issues.jboss.org/browse/WFCORE-3103
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Modules
>            Reporter: Jan Bliz??k
>            Assignee: ehsavoie Hugonnet
>
> When embedded server is started programatically (eg. via CLI wrapper) with specified jboss home, JARs from that path are opened via classloader. But these open handles are never released even after embedded server is stopped. 
> This causes problem in situation eg. when you want to delete that jboss home. This is exactly one of the scenarios used in EAP installer, you are not allowed to delete open files on Windows - see JBEAP-1404.
> I created a simple project that reproduce the issue with arbitrary EAP/WF distribution https://github.com/jbliznak/embedded-server-filelocking
> Run it with:
> mvn clean test "-Dwildfly.home=C:\dev\jboss-eap-7.1" "-Denforcer.skip" -Dtest=ModulesFileLockingTestCase
> Manual steps to reproduce in Java code:
> * start a CLI wrapper
> * start embed-server from given server path
> * stop embed-server
> * terminate CLI wrapper
> * try to delete given server path



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 18 10:59:01 2018
From: issues at jboss.org (Ken Wills (JIRA))
Date: Thu, 18 Jan 2018 10:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3409) embed-server doesn't honor
 "module.path" system property
In-Reply-To: <JIRA.12719889.1510072464000@Atlassian.JIRA>
References: <JIRA.12719889.1510072464000@Atlassian.JIRA>
	<JIRA.12719889.1510072464000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719889.1510072464000.66085.1516291141841@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills reassigned WFCORE-3409:
---------------------------------

    Assignee: ehsavoie Hugonnet  (was: Ken Wills)


> embed-server doesn't honor "module.path" system property
> --------------------------------------------------------
>
>                 Key: WFCORE-3409
>                 URL: https://issues.jboss.org/browse/WFCORE-3409
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 4.0.0.Alpha2
>            Reporter: Tomaz Cerar
>            Assignee: ehsavoie Hugonnet
>
> Every other parts of server and launchers (including embed-host-controller) honor the "module.path" system property for setting modules path.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 11:00:00 2018
From: issues at jboss.org (Ken Wills (JIRA))
Date: Thu, 18 Jan 2018 11:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1186) Isolate embedded server /
 host-controller module loading when starting new server(s)
In-Reply-To: <JIRA.12595437.1449267847000@Atlassian.JIRA>
References: <JIRA.12595437.1449267847000@Atlassian.JIRA>
	<JIRA.12595437.1449267847000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12595437.1449267847000.66090.1516291200147@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills closed WFCORE-1186.
-----------------------------
    Resolution: Out of Date


> Isolate embedded server / host-controller module loading when starting new server(s)
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1186
>                 URL: https://issues.jboss.org/browse/WFCORE-1186
>             Project: WildFly Core
>          Issue Type: Enhancement
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>
> Currently starting an embedded server obtains a single ModuleLoader instance, which is then statically initialized with specific pointers to certain filesystem directories & paths (server.log and module.path etc).
> It would be ideal if each embedded instance could use it's own ModuleLoader, as it would allow all of these properties to be managed separately, and potentially multiple servers to be started at the same time.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 11:01:00 2018
From: issues at jboss.org (Ken Wills (JIRA))
Date: Thu, 18 Jan 2018 11:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2857) Usage of
 wildfly.sasl.local-user.default-user in core configuration files
In-Reply-To: <JIRA.12693496.1495471003000@Atlassian.JIRA>
References: <JIRA.12693496.1495471003000@Atlassian.JIRA>
	<JIRA.12693496.1495471003000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12693496.1495471003000.66092.1516291260191@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2857?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ken Wills closed WFCORE-2857.
-----------------------------
    Resolution: Out of Date


> Usage of wildfly.sasl.local-user.default-user in core configuration files
> -------------------------------------------------------------------------
>
>                 Key: WFCORE-2857
>                 URL: https://issues.jboss.org/browse/WFCORE-2857
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Test Suite
>            Reporter: Ken Wills
>            Assignee: Ken Wills
>             Fix For: 4.0.0.Alpha6
>
>
> The property wildfly.sasl.local-user.default-user is present in some, commented out on other, and absent from some default configuation files in core. (the default host-slave.xml for example has it, but it appears to have no effect if removed). There is uneven usage of it throughout the testsuite config files.
> We should review and make the usage (or non-usage) consistent.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 11:01:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 18 Jan 2018 11:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9706) Newly added
 InfiniteOrPositiveValidators to messaging attributes should just print
 warning if negative values are not -1
In-Reply-To: <JIRA.12729721.1516276401000@Atlassian.JIRA>
References: <JIRA.12729721.1516276401000@Atlassian.JIRA>
	<JIRA.12729721.1516276401000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729721.1516276401000.66097.1516291260371@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520859#comment-13520859 ] 

Brian Stansberry edited comment on WFLY-9706 at 1/18/18 11:00 AM:
------------------------------------------------------------------

If a negative value other than -1 was allowed before but we don't want to allow it any more, then use a ParameterCorrector to correct it.

I don't know if a WARN is worth it. We need to control our metaspace and the odds that someone is doing this wrong seems low.


was (Author: brian.stansberry):
If a negative value other than -1 was allowed before but we don't want to allow it any more, then use a ParameterCorrector to correct it.

> Newly added InfiniteOrPositiveValidators to messaging attributes should just print warning if negative values are not -1
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9706
>                 URL: https://issues.jboss.org/browse/WFLY-9706
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 12.0.0.Alpha1
>            Reporter: Erich Duda
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> This Jira is reaction to WFLY-9433.
> The WFLY-9433 makes validator rules more strict for some attributes in messaging subsystem. Although there is no reason to use these values (which are newly considered as invalid), it was possible to configure them and they worked with Wildfly 11 and previous releases.
> As it is proposed in JBEAP-14110, this change should be done in 2 steps:
> * only WARN the user if the parameter is not valid (a negative value other than -1)
> * in next release, reject the parameter
> I am setting priority as Blocker, because this fix must be included in Wildfly 12 release. It makes no sense to do it later.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 11:02:00 2018
From: issues at jboss.org (Vojtech Prusa (JIRA))
Date: Thu, 18 Jan 2018 11:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (HAWKULARQE-153) [QE] - INV-008 View
 Relationships between EAP servers and VMs that run a Linux OS and navigate
 across the relationships
In-Reply-To: <JIRA.12705536.1501538875000@Atlassian.JIRA>
References: <JIRA.12705536.1501538875000@Atlassian.JIRA>
	<JIRA.12705536.1501538875000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12705536.1501538875000.66099.1516291320222@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/HAWKULARQE-153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vojtech Prusa closed HAWKULARQE-153.
------------------------------------
    Resolution: Out of Date


> [QE] - INV-008 View Relationships between EAP servers and VMs that run a Linux OS and navigate across the relationships
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: HAWKULARQE-153
>                 URL: https://issues.jboss.org/browse/HAWKULARQE-153
>             Project: Hawkular QE
>          Issue Type: Task
>         Environment: Need instances CFME, RHEVM, HS and EAP monitored by this HS when EAP is running on VM under RHEVM.
>            Reporter: Vojtech Prusa
>            Assignee: Vojtech Prusa
>
> Manually tested. 
> Automate https://trello.com/c/oBeMkciI/254-inv-008-view-relationships-between-eap-servers-and-vms-that-run-a-linux-os-and-navigate-across-the-relationships
> Use JON QE RHEVMs test user.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 11:08:00 2018
From: issues at jboss.org (Luis Canales (JIRA))
Date: Thu, 18 Jan 2018 11:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279795000@Atlassian.JIRA>
References: <JIRA.12729735.1516279795000@Atlassian.JIRA>
	<JIRA.12729735.1516279795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279795000.66153.1516291680265@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520981#comment-13520981 ] 

Luis Canales commented on WFLY-9708:
------------------------------------

Hi Martin,
I have this in my jboss-all.xml (I'm not using CDI in my application):

_<jboss umlns="urn:jboss:1.0">
    <weld xmlns="urn:jboss:weld:1.0" require-bean-descriptor="true"/>
</jboss>_

The same application runs in Wildfly 10.1.0. I've build the 3 JSF1.2 modules (jsf-api, jsf-impl and jsf-injection) for both Wildfly (10.1.0, 11.0.0) according to the tutorial.

I think "WeldApplication" is bean instantiated when the module is loaded. In Wildfly 10.1.0 "WeldApplication" extends from "ForwardingApplication" and this class is included inside the module. However, in Wildfly 11.0.0 it extends from "ApplicationWrapper" (dependent from JSF2.0).

> Wildfly 11.0.0.Final JSF 1.2 configuration error
> ------------------------------------------------
>
>                 Key: WFLY-9708
>                 URL: https://issues.jboss.org/browse/WFLY-9708
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 11.0.0.Final
>            Reporter: Luis Canales
>            Assignee: Martin Kouba
>            Priority: Optional
>         Attachments: log.txt
>
>
> Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:
> _java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_
> If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 11:15:00 2018
From: issues at jboss.org (Luis Canales (JIRA))
Date: Thu, 18 Jan 2018 11:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279795000@Atlassian.JIRA>
References: <JIRA.12729735.1516279795000@Atlassian.JIRA>
	<JIRA.12729735.1516279795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279795000.66172.1516292100471@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13520981#comment-13520981 ] 

Luis Canales edited comment on WFLY-9708 at 1/18/18 11:14 AM:
--------------------------------------------------------------

Hi Martin,
I have this in my jboss-all.xml (I'm not using CDI in my application):

_<jboss umlns="urn:jboss:1.0">
    <weld xmlns="urn:jboss:weld:1.0" require-bean-descriptor="true"/>
</jboss>_

The same application runs in Wildfly 10.1.0. I've build the 3 JSF1.2 modules (jsf-api, jsf-impl and jsf-injection) for both Wildfly (10.1.0, 11.0.0) according to the tutorial.

I think "WeldApplication" is bean instantiated when the module is loaded. In Wildfly 10.1.0 "WeldApplication" extends from "ForwardingApplication" and this class is included inside the module. However, in Wildfly 11.0.0 it extends from "ApplicationWrapper" (dependent from JSF2.0).


was (Author: lcanales):
Hi Martin,
I have this in my jboss-all.xml (I'm not using CDI in my application):

_<jboss umlns="urn:jboss:1.0">
    <weld xmlns="urn:jboss:weld:1.0" require-bean-descriptor="true"/>
</jboss>_

The same application runs in Wildfly 10.1.0. I've build the 3 JSF1.2 modules (jsf-api, jsf-impl and jsf-injection) for both Wildfly (10.1.0, 11.0.0) according to the tutorial.

I think "WeldApplication" is bean instantiated when the module is loaded. In Wildfly 10.1.0 "WeldApplication" extends from "ForwardingApplication" and this class is included inside the module. However, in Wildfly 11.0.0 it extends from "ApplicationWrapper" (dependent from JSF2.0).

> Wildfly 11.0.0.Final JSF 1.2 configuration error
> ------------------------------------------------
>
>                 Key: WFLY-9708
>                 URL: https://issues.jboss.org/browse/WFLY-9708
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 11.0.0.Final
>            Reporter: Luis Canales
>            Assignee: Martin Kouba
>            Priority: Optional
>         Attachments: log.txt
>
>
> Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:
> _java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_
> If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 11:44:00 2018
From: issues at jboss.org (ehsavoie Hugonnet (JIRA))
Date: Thu, 18 Jan 2018 11:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3521) Display dynamic
 capabilities with a pattern
In-Reply-To: <JIRA.12729796.1516293794000@Atlassian.JIRA>
References: <JIRA.12729796.1516293794000@Atlassian.JIRA>
	<JIRA.12729796.1516293794793@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729796.1516293794000.66359.1516293840324@Atlassian.JIRA>

ehsavoie Hugonnet created WFCORE-3521:
-----------------------------------------

             Summary: Display dynamic capabilities with a pattern
                 Key: WFCORE-3521
                 URL: https://issues.jboss.org/browse/WFCORE-3521
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management
    Affects Versions: 4.0.0.Alpha5
            Reporter: ehsavoie Hugonnet
            Assignee: ehsavoie Hugonnet


Currently when we describe a resource or an attribute with dynamic capabilities we show only the static part of the name. The goal of this enhancement is to display a dynamic 'pattern' of this capability name using $dynamic_part for each part.
Thus we would have :"org.wildfly.undertow.host.$default-server.$default-virtual-host" for the "org.wildfly.undertow.host" capability in undertow subsystem for example.
We would be using another key in order not to break tools relying on the old format.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 13:56:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 18 Jan 2018 13:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2252) "Unable to expand" error
 with acculumate in Guided Rule Editor with DSL
In-Reply-To: <JIRA.12729819.1516301721000@Atlassian.JIRA>
References: <JIRA.12729819.1516301721000@Atlassian.JIRA>
	<JIRA.12729819.1516301721000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729819.1516301721000.66786.1516301760694@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis moved RHDM-284 to DROOLS-2252:
---------------------------------------------

              Project: Drools  (was: Red Hat Decision Manager)
                  Key: DROOLS-2252  (was: RHDM-284)
             Workflow: GIT Pull Request workflow   (was: CDW with docs v1)
       Docs QE Status: NEW
          Component/s: Guided Rule Editor
                           (was: Decision Central)
    Affects Version/s: 7.5.0.Final
                           (was: 6.x.x)
            QE Status: NEW


> "Unable to expand" error with acculumate in Guided Rule Editor with DSL
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-2252
>                 URL: https://issues.jboss.org/browse/DROOLS-2252
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Rule Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>              Labels: support
>
> In Guided Rule Editor with DSL option, you can add "From Accumulate" but "Function"/"Custom Code" gets an error "Unable to expand".
> Reproduce steps:
> - Unzip the attached reproducer-repo.zip
> - Clone the repo via business-central "Administration" > "Repositories" > "Clone Repository"
> - Go to Project Explorer, choose the repo, choose "project1"
> - Go to package org > kie > example > project1. You will find DataObject 'Person,' DSL, Test Scenario
> - Create a new Guided Rule. Check "Use Domain Specific Language (DSL)" option
> - Add conditions (See guidedrule01.png)
> -- DSL "There is a person whose age is 20"
> -- "From Accumulate ..."
> --- Choose "Number" for the first "click to add pattern..."
> --- Choose "Person" for the second "click to add pattern..."
> --- Configure Variable name "$p" for "All Person with"
> -- Write "count($p)" in Function
> - Save
> - Press "Validate"
> - You will get an error "Unable to expand" (See error01.png)
> This is because "count($p)" line doesn't have preceding ">".
> {noformat}
> rule "gr1"
>         dialect "mvel"
>         when
>                 There is a person whose age is 20
>                 >Number( ) from accumulate ( $p : Person( ),
>                         count($p))
>         then
> end
> {noformat}
> - If you add ">" at the begging of Function (See guidedrule02.png), you don't get the error.
> - But if you close the Editor and reopen the rdslr, the condition is rendered as free form DRL (See guidedrule03.png). So it cannot be a workaround.
> - "Custom Code" has the same problem as "Function". Furthermore, "Custom Code" cannot use ">" because ">" wouldn't be placed at the beginning of the line.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 13:57:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 18 Jan 2018 13:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2252) "Unable to expand" error
 with acculumate in Guided Rule Editor with DSL
In-Reply-To: <JIRA.12729819.1516301721000@Atlassian.JIRA>
References: <JIRA.12729819.1516301721000@Atlassian.JIRA>
	<JIRA.12729819.1516301721000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729819.1516301721000.66788.1516301820096@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2252:
-----------------------------------
    Sprint: 2018 Week 03-04


> "Unable to expand" error with acculumate in Guided Rule Editor with DSL
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-2252
>                 URL: https://issues.jboss.org/browse/DROOLS-2252
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Rule Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>              Labels: support
>
> In Guided Rule Editor with DSL option, you can add "From Accumulate" but "Function"/"Custom Code" gets an error "Unable to expand".
> Reproduce steps:
> - Unzip the attached reproducer-repo.zip
> - Clone the repo via business-central "Administration" > "Repositories" > "Clone Repository"
> - Go to Project Explorer, choose the repo, choose "project1"
> - Go to package org > kie > example > project1. You will find DataObject 'Person,' DSL, Test Scenario
> - Create a new Guided Rule. Check "Use Domain Specific Language (DSL)" option
> - Add conditions (See guidedrule01.png)
> -- DSL "There is a person whose age is 20"
> -- "From Accumulate ..."
> --- Choose "Number" for the first "click to add pattern..."
> --- Choose "Person" for the second "click to add pattern..."
> --- Configure Variable name "$p" for "All Person with"
> -- Write "count($p)" in Function
> - Save
> - Press "Validate"
> - You will get an error "Unable to expand" (See error01.png)
> This is because "count($p)" line doesn't have preceding ">".
> {noformat}
> rule "gr1"
>         dialect "mvel"
>         when
>                 There is a person whose age is 20
>                 >Number( ) from accumulate ( $p : Person( ),
>                         count($p))
>         then
> end
> {noformat}
> - If you add ">" at the begging of Function (See guidedrule02.png), you don't get the error.
> - But if you close the Editor and reopen the rdslr, the condition is rendered as free form DRL (See guidedrule03.png). So it cannot be a workaround.
> - "Custom Code" has the same problem as "Function". Furthermore, "Custom Code" cannot use ">" because ">" wouldn't be placed at the beginning of the line.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 14:44:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 18 Jan 2018 14:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-134) Add module name,
 module version fields to ExtLogRecord
In-Reply-To: <JIRA.12615832.1461091721000@Atlassian.JIRA>
References: <JIRA.12615832.1461091721000@Atlassian.JIRA>
	<JIRA.12615832.1461091721000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12615832.1461091721000.66877.1516304640227@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-134?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned LOGMGR-134:
------------------------------------

    Assignee: David Lloyd


> Add module name, module version fields to ExtLogRecord
> ------------------------------------------------------
>
>                 Key: LOGMGR-134
>                 URL: https://issues.jboss.org/browse/LOGMGR-134
>             Project: JBoss Log Manager
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 2.1.0.Alpha6
>
>
> It will be necessary for ExtLogRecord to carry additional fields for Java 9 module name and module version.  The serialization impact should be analyzed.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 14:44:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 18 Jan 2018 14:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-185) The
 ConsoleHandler.setTarget() doesn't allow for a null value to be passed
In-Reply-To: <JIRA.12723833.1512587321000@Atlassian.JIRA>
References: <JIRA.12723833.1512587321000@Atlassian.JIRA>
	<JIRA.12723833.1512587321000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723833.1512587321000.66879.1516304640312@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-185:
---------------------------------
    Fix Version/s: 2.1.0.Alpha6


> The ConsoleHandler.setTarget() doesn't allow for a null value to be passed
> --------------------------------------------------------------------------
>
>                 Key: LOGMGR-185
>                 URL: https://issues.jboss.org/browse/LOGMGR-185
>             Project: JBoss Log Manager
>          Issue Type: Bug
>    Affects Versions: 2.1.0.Alpha5
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 2.1.0.Alpha6
>
>
> If the {{ConsoleHandler}} is reset as a result of LOGMGR-178 a {{null}} value may be passed to the {{ConsoleHandler.setTarget()}} method which should handle a {{null}} value.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 14:45:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 18 Jan 2018 14:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-185) The
 ConsoleHandler.setTarget() doesn't allow for a null value to be passed
In-Reply-To: <JIRA.12723833.1512587321000@Atlassian.JIRA>
References: <JIRA.12723833.1512587321000@Atlassian.JIRA>
	<JIRA.12723833.1512587321000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723833.1512587321000.66882.1516304700277@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-185:
---------------------------------
    Priority: Blocker  (was: Major)


> The ConsoleHandler.setTarget() doesn't allow for a null value to be passed
> --------------------------------------------------------------------------
>
>                 Key: LOGMGR-185
>                 URL: https://issues.jboss.org/browse/LOGMGR-185
>             Project: JBoss Log Manager
>          Issue Type: Bug
>    Affects Versions: 2.1.0.Alpha5
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Blocker
>             Fix For: 2.1.0.Alpha6
>
>
> If the {{ConsoleHandler}} is reset as a result of LOGMGR-178 a {{null}} value may be passed to the {{ConsoleHandler.setTarget()}} method which should handle a {{null}} value.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 16:02:00 2018
From: issues at jboss.org (Ken Finnigan (JIRA))
Date: Thu, 18 Jan 2018 16:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3522) Module dependency order for
 a deployment is wrong
In-Reply-To: <JIRA.12729825.1516309261000@Atlassian.JIRA>
References: <JIRA.12729825.1516309261000@Atlassian.JIRA>
	<JIRA.12729825.1516309261505@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729825.1516309261000.67033.1516309320283@Atlassian.JIRA>

Ken Finnigan created WFCORE-3522:
------------------------------------

             Summary: Module dependency order for a deployment is wrong
                 Key: WFCORE-3522
                 URL: https://issues.jboss.org/browse/WFCORE-3522
             Project: WildFly Core
          Issue Type: Bug
    Affects Versions: 3.0.8.Final
            Reporter: Ken Finnigan
            Priority: Blocker


Within WildFly Swarm we need the ability to override the `javax.ws.rs.client.ClientBuilder` service file for a deployment to provide custom handling for implementing Eclipse MicroProfile.

With a service file present in the deployment, the existing RESTEasy service file is always found first because the deployment module is added as a dependency after other non local dependencies. See https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/module/ModuleSpecProcessor.java#L241-L250

After discussing with [~dmlloyd] on IRC, he agreed this was a bug and a better solution was for the deployment's dependency to always be first if `isLocalLast()` is false, and instead remove any spec packages that might be present on the deployment path instead.

He explained the purpose of this ordering was to prevent a user deploying `javax.servlet.api` and breaking things, but it appears this can be achieved by alternative methods.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 16:26:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 18 Jan 2018 16:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3522) Module dependency order for
 a deployment is wrong
In-Reply-To: <JIRA.12729825.1516309262000@Atlassian.JIRA>
References: <JIRA.12729825.1516309262000@Atlassian.JIRA>
	<JIRA.12729825.1516309262000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729825.1516309262000.67067.1516310760346@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3522?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521103#comment-13521103 ] 

David Lloyd commented on WFCORE-3522:
-------------------------------------

This is another example of why parent-first class loading is always wrong.  We should instead be excluding the set of packages in deployment resource loaders that are found in dependencies that we want to flag (along with a hefty warning or error message).

> Module dependency order for a deployment is wrong
> -------------------------------------------------
>
>                 Key: WFCORE-3522
>                 URL: https://issues.jboss.org/browse/WFCORE-3522
>             Project: WildFly Core
>          Issue Type: Bug
>    Affects Versions: 3.0.8.Final
>            Reporter: Ken Finnigan
>            Priority: Blocker
>
> Within WildFly Swarm we need the ability to override the `javax.ws.rs.client.ClientBuilder` service file for a deployment to provide custom handling for implementing Eclipse MicroProfile.
> With a service file present in the deployment, the existing RESTEasy service file is always found first because the deployment module is added as a dependency after other non local dependencies. See https://github.com/wildfly/wildfly-core/blob/master/server/src/main/java/org/jboss/as/server/deployment/module/ModuleSpecProcessor.java#L241-L250
> After discussing with [~dmlloyd] on IRC, he agreed this was a bug and a better solution was for the deployment's dependency to always be first if `isLocalLast()` is false, and instead remove any spec packages that might be present on the deployment path instead.
> He explained the purpose of this ordering was to prevent a user deploying `javax.servlet.api` and breaking things, but it appears this can be achieved by alternative methods.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 16:37:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 18 Jan 2018 16:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-188) Allow the configuration API
 to not persist properties when writing a configuration file
In-Reply-To: <JIRA.12729826.1516311402000@Atlassian.JIRA>
References: <JIRA.12729826.1516311402000@Atlassian.JIRA>
	<JIRA.12729826.1516311402935@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729826.1516311402000.67083.1516311420167@Atlassian.JIRA>

James Perkins created LOGMGR-188:
------------------------------------

             Summary: Allow the configuration API to not persist properties when writing a configuration file
                 Key: LOGMGR-188
                 URL: https://issues.jboss.org/browse/LOGMGR-188
             Project: JBoss Log Manager
          Issue Type: Feature Request
            Reporter: James Perkins
            Assignee: James Perkins


With the introduction of the [{{DelayedHandler}}|LOGMGR-177] it may be desirable for configurations not to persist some data to the {{logging.properties}} configuration file. This should include all generic properties plus child handler names. The level, filter, encoding, formatter and error manager will always be persisted.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 17:23:00 2018
From: issues at jboss.org (Sibin Karnavar (JIRA))
Date: Thu, 18 Jan 2018 17:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not
 clearing the crashed members
In-Reply-To: <JIRA.12729827.1516314139000@Atlassian.JIRA>
References: <JIRA.12729827.1516314139000@Atlassian.JIRA>
	<JIRA.12729827.1516314139933@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729827.1516314139000.67161.1516314180125@Atlassian.JIRA>

Sibin Karnavar created JGRP-2245:
------------------------------------

             Summary: JGroup JDBC_PING is not clearing the crashed members
                 Key: JGRP-2245
                 URL: https://issues.jboss.org/browse/JGRP-2245
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 4.0.8
            Reporter: Sibin Karnavar
            Assignee: Bela Ban
            Priority: Critical


1) In AWS cloud environments, IP address will be different when a node crashes and when a new node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused when other nodes restarts.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.

I think the issue is 


handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.

 // remove all files which are not from the current members
    protected void handleView(View new_view, View old_view, boolean coord_changed) {
        if(is_coord) {
            if(coord_changed) {
                if(remove_all_data_on_view_change)
                    removeAll(cluster_name);
                else if(remove_old_coords_on_view_change) {
                    Address old_coord=old_view != null? old_view.getCreator() : null;
                    if(old_coord != null)
                        remove(cluster_name, old_coord);
                }
            }
            if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
                writeAll();
                if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
                    startInfoWriter();
            }
        }
        else if(coord_changed) // I'm no longer the coordinator
            remove(cluster_name, local_addr);
    }

4) because of the crashed members non existing ip address

sendToMembers of TP is trying to send messages to old crashed members and writing error logs.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 17:25:00 2018
From: issues at jboss.org (Sibin Karnavar (JIRA))
Date: Thu, 18 Jan 2018 17:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not
 clearing the crashed members
In-Reply-To: <JIRA.12729827.1516314140000@Atlassian.JIRA>
References: <JIRA.12729827.1516314140000@Atlassian.JIRA>
	<JIRA.12729827.1516314140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729827.1516314140000.67164.1516314300109@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sibin Karnavar updated JGRP-2245:
---------------------------------
    Description: 
1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.

I think the issue is 


handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.

 // remove all files which are not from the current members
    protected void handleView(View new_view, View old_view, boolean coord_changed) {
        if(is_coord) {
            if(coord_changed) {
                if(remove_all_data_on_view_change)
                    removeAll(cluster_name);
                else if(remove_old_coords_on_view_change) {
                    Address old_coord=old_view != null? old_view.getCreator() : null;
                    if(old_coord != null)
                        remove(cluster_name, old_coord);
                }
            }
            if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
                writeAll();
                if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
                    startInfoWriter();
            }
        }
        else if(coord_changed) // I'm no longer the coordinator
            remove(cluster_name, local_addr);
    }

4) because of the crashed members non existing ip address

sendToMembers of TP is trying to send messages to old crashed members and writing error logs.


  was:
1) In AWS cloud environments, IP address will be different when a node crashes and when a new node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused when other nodes restarts.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.

I think the issue is 


handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.

 // remove all files which are not from the current members
    protected void handleView(View new_view, View old_view, boolean coord_changed) {
        if(is_coord) {
            if(coord_changed) {
                if(remove_all_data_on_view_change)
                    removeAll(cluster_name);
                else if(remove_old_coords_on_view_change) {
                    Address old_coord=old_view != null? old_view.getCreator() : null;
                    if(old_coord != null)
                        remove(cluster_name, old_coord);
                }
            }
            if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
                writeAll();
                if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
                    startInfoWriter();
            }
        }
        else if(coord_changed) // I'm no longer the coordinator
            remove(cluster_name, local_addr);
    }

4) because of the crashed members non existing ip address

sendToMembers of TP is trying to send messages to old crashed members and writing error logs.




> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
>                 Key: JGRP-2245
>                 URL: https://issues.jboss.org/browse/JGRP-2245
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.8
>            Reporter: Sibin Karnavar
>            Assignee: Bela Ban
>            Priority: Critical
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is 
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
>  // remove all files which are not from the current members
>     protected void handleView(View new_view, View old_view, boolean coord_changed) {
>         if(is_coord) {
>             if(coord_changed) {
>                 if(remove_all_data_on_view_change)
>                     removeAll(cluster_name);
>                 else if(remove_old_coords_on_view_change) {
>                     Address old_coord=old_view != null? old_view.getCreator() : null;
>                     if(old_coord != null)
>                         remove(cluster_name, old_coord);
>                 }
>             }
>             if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
>                 writeAll();
>                 if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
>                     startInfoWriter();
>             }
>         }
>         else if(coord_changed) // I'm no longer the coordinator
>             remove(cluster_name, local_addr);
>     }
> 4) because of the crashed members non existing ip address
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 17:26:00 2018
From: issues at jboss.org (Sibin Karnavar (JIRA))
Date: Thu, 18 Jan 2018 17:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not
 clearing the crashed members
In-Reply-To: <JIRA.12729827.1516314140000@Atlassian.JIRA>
References: <JIRA.12729827.1516314140000@Atlassian.JIRA>
	<JIRA.12729827.1516314140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729827.1516314140000.67167.1516314360165@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sibin Karnavar updated JGRP-2245:
---------------------------------
    Description: 
1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.

I think the issue is 


handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.

 // remove all files which are not from the current members
    protected void handleView(View new_view, View old_view, boolean coord_changed) {
        if(is_coord) {
            if(coord_changed) {
                if(remove_all_data_on_view_change)
                    removeAll(cluster_name);
                else if(remove_old_coords_on_view_change) {
                    Address old_coord=old_view != null? old_view.getCreator() : null;
                    if(old_coord != null)
                        remove(cluster_name, old_coord);
                }
            }
            if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
                writeAll();
                if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
                    startInfoWriter();
            }
        }
        else if(coord_changed) // I'm no longer the coordinator
            remove(cluster_name, local_addr);
    }

4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts

sendToMembers of TP is trying to send messages to old crashed members and writing error logs.


  was:
1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.

I think the issue is 


handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.

 // remove all files which are not from the current members
    protected void handleView(View new_view, View old_view, boolean coord_changed) {
        if(is_coord) {
            if(coord_changed) {
                if(remove_all_data_on_view_change)
                    removeAll(cluster_name);
                else if(remove_old_coords_on_view_change) {
                    Address old_coord=old_view != null? old_view.getCreator() : null;
                    if(old_coord != null)
                        remove(cluster_name, old_coord);
                }
            }
            if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
                writeAll();
                if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
                    startInfoWriter();
            }
        }
        else if(coord_changed) // I'm no longer the coordinator
            remove(cluster_name, local_addr);
    }

4) because of the crashed members non existing ip address

sendToMembers of TP is trying to send messages to old crashed members and writing error logs.




> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
>                 Key: JGRP-2245
>                 URL: https://issues.jboss.org/browse/JGRP-2245
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.8
>            Reporter: Sibin Karnavar
>            Assignee: Bela Ban
>            Priority: Critical
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is 
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
>  // remove all files which are not from the current members
>     protected void handleView(View new_view, View old_view, boolean coord_changed) {
>         if(is_coord) {
>             if(coord_changed) {
>                 if(remove_all_data_on_view_change)
>                     removeAll(cluster_name);
>                 else if(remove_old_coords_on_view_change) {
>                     Address old_coord=old_view != null? old_view.getCreator() : null;
>                     if(old_coord != null)
>                         remove(cluster_name, old_coord);
>                 }
>             }
>             if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
>                 writeAll();
>                 if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
>                     startInfoWriter();
>             }
>         }
>         else if(coord_changed) // I'm no longer the coordinator
>             remove(cluster_name, local_addr);
>     }
> 4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 17:26:00 2018
From: issues at jboss.org (Sibin Karnavar (JIRA))
Date: Thu, 18 Jan 2018 17:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not
 clearing the crashed members
In-Reply-To: <JIRA.12729827.1516314140000@Atlassian.JIRA>
References: <JIRA.12729827.1516314140000@Atlassian.JIRA>
	<JIRA.12729827.1516314140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729827.1516314140000.67171.1516314360336@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sibin Karnavar updated JGRP-2245:
---------------------------------
    Description: 
1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.

I think the issue is 


handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.

 // remove all files which are not from the current members
    protected void handleView(View new_view, View old_view, boolean coord_changed) {
        if(is_coord) {
            if(coord_changed) {
                if(remove_all_data_on_view_change)
                    removeAll(cluster_name);
                else if(remove_old_coords_on_view_change) {
                    Address old_coord=old_view != null? old_view.getCreator() : null;
                    if(old_coord != null)
                        remove(cluster_name, old_coord);
                }
            }
            if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
                writeAll();
                if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
                    startInfoWriter();
            }
        }
        else if(coord_changed) // I'm no longer the coordinator
            remove(cluster_name, local_addr);
    }

4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts

sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.


  was:
1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.

I think the issue is 


handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.

 // remove all files which are not from the current members
    protected void handleView(View new_view, View old_view, boolean coord_changed) {
        if(is_coord) {
            if(coord_changed) {
                if(remove_all_data_on_view_change)
                    removeAll(cluster_name);
                else if(remove_old_coords_on_view_change) {
                    Address old_coord=old_view != null? old_view.getCreator() : null;
                    if(old_coord != null)
                        remove(cluster_name, old_coord);
                }
            }
            if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
                writeAll();
                if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
                    startInfoWriter();
            }
        }
        else if(coord_changed) // I'm no longer the coordinator
            remove(cluster_name, local_addr);
    }

4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts

sendToMembers of TP is trying to send messages to old crashed members and writing error logs.




> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
>                 Key: JGRP-2245
>                 URL: https://issues.jboss.org/browse/JGRP-2245
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.8
>            Reporter: Sibin Karnavar
>            Assignee: Bela Ban
>            Priority: Critical
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is 
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
>  // remove all files which are not from the current members
>     protected void handleView(View new_view, View old_view, boolean coord_changed) {
>         if(is_coord) {
>             if(coord_changed) {
>                 if(remove_all_data_on_view_change)
>                     removeAll(cluster_name);
>                 else if(remove_old_coords_on_view_change) {
>                     Address old_coord=old_view != null? old_view.getCreator() : null;
>                     if(old_coord != null)
>                         remove(cluster_name, old_coord);
>                 }
>             }
>             if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
>                 writeAll();
>                 if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
>                     startInfoWriter();
>             }
>         }
>         else if(coord_changed) // I'm no longer the coordinator
>             remove(cluster_name, local_addr);
>     }
> 4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 17:31:00 2018
From: issues at jboss.org (Sibin Karnavar (JIRA))
Date: Thu, 18 Jan 2018 17:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not
 clearing the crashed members
In-Reply-To: <JIRA.12729827.1516314140000@Atlassian.JIRA>
References: <JIRA.12729827.1516314140000@Atlassian.JIRA>
	<JIRA.12729827.1516314140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729827.1516314140000.67174.1516314660167@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521120#comment-13521120 ] 

Sibin Karnavar commented on JGRP-2245:
--------------------------------------

Will you be able to make J GROUP writes only its own address to DB or just the new view or latest

> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
>                 Key: JGRP-2245
>                 URL: https://issues.jboss.org/browse/JGRP-2245
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.8
>            Reporter: Sibin Karnavar
>            Assignee: Bela Ban
>            Priority: Critical
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is 
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
>  // remove all files which are not from the current members
>     protected void handleView(View new_view, View old_view, boolean coord_changed) {
>         if(is_coord) {
>             if(coord_changed) {
>                 if(remove_all_data_on_view_change)
>                     removeAll(cluster_name);
>                 else if(remove_old_coords_on_view_change) {
>                     Address old_coord=old_view != null? old_view.getCreator() : null;
>                     if(old_coord != null)
>                         remove(cluster_name, old_coord);
>                 }
>             }
>             if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
>                 writeAll();
>                 if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
>                     startInfoWriter();
>             }
>         }
>         else if(coord_changed) // I'm no longer the coordinator
>             remove(cluster_name, local_addr);
>     }
> 4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 17:48:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 18 Jan 2018 17:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3523) Don't initialize extension
 parsers on a domain server
In-Reply-To: <JIRA.12729828.1516315678000@Atlassian.JIRA>
References: <JIRA.12729828.1516315678000@Atlassian.JIRA>
	<JIRA.12729828.1516315678289@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729828.1516315678000.67176.1516315680078@Atlassian.JIRA>

Brian Stansberry created WFCORE-3523:
----------------------------------------

             Summary: Don't initialize extension parsers on a domain server
                 Key: WFCORE-3523
                 URL: https://issues.jboss.org/browse/WFCORE-3523
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry
            Priority: Minor


The Extension.initializeParsers calls is pointless on a domain server, as that kind of process does not parse. So skip it and save the execution cost and the metaspace associated with the parsers.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 19:39:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 18 Jan 2018 19:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9709) Replace unnecessary Attribute
 and Element classes in mail subsystem parser
In-Reply-To: <JIRA.12729831.1516322301000@Atlassian.JIRA>
References: <JIRA.12729831.1516322301000@Atlassian.JIRA>
	<JIRA.12729831.1516322301525@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729831.1516322301000.67330.1516322340062@Atlassian.JIRA>

Stuart Douglas created WFLY-9709:
------------------------------------

             Summary: Replace unnecessary Attribute and Element classes in mail subsystem parser
                 Key: WFLY-9709
                 URL: https://issues.jboss.org/browse/WFLY-9709
             Project: WildFly
          Issue Type: Task
          Components: Mail
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 19:41:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 18 Jan 2018 19:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3524) Attempt to initialize the
 latest Extension parser if that has been registered are suppliers
In-Reply-To: <JIRA.12729832.1516322440000@Atlassian.JIRA>
References: <JIRA.12729832.1516322440000@Atlassian.JIRA>
	<JIRA.12729832.1516322440510@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729832.1516322440000.67332.1516322460221@Atlassian.JIRA>

Brian Stansberry created WFCORE-3524:
----------------------------------------

             Summary: Attempt to initialize the latest Extension parser if that has been registered are suppliers
                 Key: WFCORE-3524
                 URL: https://issues.jboss.org/browse/WFCORE-3524
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


The ExtensionParsingContext.setSubsystemXmlMapping(String subsystemName, String namespaceUri, Supplier<XMLElementReader<List<ModelNode>>> supplier) method may save memory space by deferring construction of the parser, but it also may mean that the management model classloading and definition initialization work that often is done by the parser is deferred until parsing begins. And parsing is a single-threaded part of boot, so deferring this work out of the concurrent extension initialization work until parsing slows down boot.

I'd been asking people to use the non-supplier ExtensionParsingContext.setSubsystemXmlMapping variant for the latest parser, but that's unintuitive and requires further unintuitive work every time a new parser is added.

To limit the need for that, instead the ExtensionRegistry, if it sees that only suppliers have been registered, will attempt to construct the "latest" parser (by calling its supplier). It will determine the "latest" supplier by lexicographic comparison of the registered namespaces.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 20:21:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 18 Jan 2018 20:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9709) Replace unnecessary Attribute
 and Element classes in mail subsystem parser
In-Reply-To: <JIRA.12729831.1516322302000@Atlassian.JIRA>
References: <JIRA.12729831.1516322302000@Atlassian.JIRA>
	<JIRA.12729831.1516322302000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729831.1516322302000.67337.1516324860146@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9709?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFLY-9709:
---------------------------------
    Priority: Minor  (was: Major)


> Replace unnecessary Attribute and Element classes in mail subsystem parser
> --------------------------------------------------------------------------
>
>                 Key: WFLY-9709
>                 URL: https://issues.jboss.org/browse/WFLY-9709
>             Project: WildFly
>          Issue Type: Task
>          Components: Mail
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>            Priority: Minor
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 22:26:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 18 Jan 2018 22:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9710) Add Undertow buffer pools as
 a preferred alternative to the deprecated XNIO ones
In-Reply-To: <JIRA.12729835.1516332317000@Atlassian.JIRA>
References: <JIRA.12729835.1516332317000@Atlassian.JIRA>
	<JIRA.12729835.1516332317049@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729835.1516332317000.67446.1516332360099@Atlassian.JIRA>

Stuart Douglas created WFLY-9710:
------------------------------------

             Summary: Add Undertow buffer pools as a preferred alternative to the deprecated XNIO ones
                 Key: WFLY-9710
                 URL: https://issues.jboss.org/browse/WFLY-9710
             Project: WildFly
          Issue Type: Enhancement
          Components: Web (Undertow)
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 22:31:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 18 Jan 2018 22:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3525) Expose Xnio buffer pools as
 an Undertow ByteBufferPool capability for compatibility
In-Reply-To: <JIRA.12729836.1516332645000@Atlassian.JIRA>
References: <JIRA.12729836.1516332645000@Atlassian.JIRA>
	<JIRA.12729836.1516332645659@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729836.1516332645000.67449.1516332660085@Atlassian.JIRA>

Stuart Douglas created WFCORE-3525:
--------------------------------------

             Summary: Expose Xnio buffer pools as an Undertow ByteBufferPool capability for compatibility
                 Key: WFCORE-3525
                 URL: https://issues.jboss.org/browse/WFCORE-3525
             Project: WildFly Core
          Issue Type: Enhancement
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 18 23:34:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Thu, 18 Jan 2018 23:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9711) Move web tests in
	integration/web
In-Reply-To: <JIRA.12729838.1516336411000@Atlassian.JIRA>
References: <JIRA.12729838.1516336411000@Atlassian.JIRA>
	<JIRA.12729838.1516336411406@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729838.1516336411000.67508.1516336440068@Atlassian.JIRA>

Stuart Douglas created WFLY-9711:
------------------------------------

             Summary: Move web tests in integration/web
                 Key: WFLY-9711
                 URL: https://issues.jboss.org/browse/WFLY-9711
             Project: WildFly
          Issue Type: Task
          Components: Test Suite
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas


At the moment web tests are split between integration/basic and integration/web, they should only be in integration/web



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 00:17:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 19 Jan 2018 00:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9712) Add test for WFCORE-3512
In-Reply-To: <JIRA.12729839.1516338984000@Atlassian.JIRA>
References: <JIRA.12729839.1516338984000@Atlassian.JIRA>
	<JIRA.12729839.1516338984234@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729839.1516338984000.67562.1516339020059@Atlassian.JIRA>

Stuart Douglas created WFLY-9712:
------------------------------------

             Summary: Add test for WFCORE-3512
                 Key: WFLY-9712
                 URL: https://issues.jboss.org/browse/WFLY-9712
             Project: WildFly
          Issue Type: Task
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas


Even though this is a WFCORE issue it only really manifests via EJB.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 02:45:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Fri, 19 Jan 2018 02:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9706) Newly added
 InfiniteOrPositiveValidators to messaging attributes should just print
 warning if negative values are not -1
In-Reply-To: <JIRA.12729721.1516276401000@Atlassian.JIRA>
References: <JIRA.12729721.1516276401000@Atlassian.JIRA>
	<JIRA.12729721.1516276401000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729721.1516276401000.67936.1516347900737@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9706?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521191#comment-13521191 ] 

Erich Duda commented on WFLY-9706:
----------------------------------

I agree that it is unlikely that someone uses e.g. -2 instead of -1. Additionally if someone really does, the fix is easy and straightforward.

I don't have any opinion how this should be handled. I think all proposed solutions (corrector, warning, do nothing) are OK. [~jmesnil] wdyt?

> Newly added InfiniteOrPositiveValidators to messaging attributes should just print warning if negative values are not -1
> ------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9706
>                 URL: https://issues.jboss.org/browse/WFLY-9706
>             Project: WildFly
>          Issue Type: Bug
>          Components: JMS
>    Affects Versions: 12.0.0.Alpha1
>            Reporter: Erich Duda
>            Assignee: Jeff Mesnil
>            Priority: Blocker
>
> This Jira is reaction to WFLY-9433.
> The WFLY-9433 makes validator rules more strict for some attributes in messaging subsystem. Although there is no reason to use these values (which are newly considered as invalid), it was possible to configure them and they worked with Wildfly 11 and previous releases.
> As it is proposed in JBEAP-14110, this change should be done in 2 steps:
> * only WARN the user if the parameter is not valid (a negative value other than -1)
> * in next release, reject the parameter
> I am setting priority as Blocker, because this fix must be included in Wildfly 12 release. It makes no sense to do it later.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 03:10:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 19 Jan 2018 03:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2252) "Unable to expand" error
 with acculumate in Guided Rule Editor with DSL
In-Reply-To: <JIRA.12729819.1516301721000@Atlassian.JIRA>
References: <JIRA.12729819.1516301721000@Atlassian.JIRA>
	<JIRA.12729819.1516301721000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729819.1516301721000.67994.1516349400103@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2252?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2252:
--------------------------------
    Tester: Jozef Marko  (was: Jan Hrcek)


> "Unable to expand" error with acculumate in Guided Rule Editor with DSL
> -----------------------------------------------------------------------
>
>                 Key: DROOLS-2252
>                 URL: https://issues.jboss.org/browse/DROOLS-2252
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Rule Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>              Labels: support
>
> In Guided Rule Editor with DSL option, you can add "From Accumulate" but "Function"/"Custom Code" gets an error "Unable to expand".
> Reproduce steps:
> - Unzip the attached reproducer-repo.zip
> - Clone the repo via business-central "Administration" > "Repositories" > "Clone Repository"
> - Go to Project Explorer, choose the repo, choose "project1"
> - Go to package org > kie > example > project1. You will find DataObject 'Person,' DSL, Test Scenario
> - Create a new Guided Rule. Check "Use Domain Specific Language (DSL)" option
> - Add conditions (See guidedrule01.png)
> -- DSL "There is a person whose age is 20"
> -- "From Accumulate ..."
> --- Choose "Number" for the first "click to add pattern..."
> --- Choose "Person" for the second "click to add pattern..."
> --- Configure Variable name "$p" for "All Person with"
> -- Write "count($p)" in Function
> - Save
> - Press "Validate"
> - You will get an error "Unable to expand" (See error01.png)
> This is because "count($p)" line doesn't have preceding ">".
> {noformat}
> rule "gr1"
>         dialect "mvel"
>         when
>                 There is a person whose age is 20
>                 >Number( ) from accumulate ( $p : Person( ),
>                         count($p))
>         then
> end
> {noformat}
> - If you add ">" at the begging of Function (See guidedrule02.png), you don't get the error.
> - But if you close the Editor and reopen the rdslr, the condition is rendered as free form DRL (See guidedrule03.png). So it cannot be a workaround.
> - "Custom Code" has the same problem as "Function". Furthermore, "Custom Code" cannot use ">" because ">" wouldn't be placed at the beginning of the line.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 03:32:00 2018
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 19 Jan 2018 03:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279795000@Atlassian.JIRA>
References: <JIRA.12729735.1516279795000@Atlassian.JIRA>
	<JIRA.12729735.1516279795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279795000.68112.1516350720396@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521204#comment-13521204 ] 

Martin Kouba commented on WFLY-9708:
------------------------------------

It seems that {{org.jboss.as.jsf.injection.weld.WeldApplication}} is loaded because {{org.jboss.as.jsf.injection.weld.WeldApplicationFactory}} is declared in the {{faces-config.xml}} of the {{org.jboss.as.jsf-injection}} module. [~ssilvert] Is the injection module always added to the deployment? I cannot find the place where this dependency is added.

> Wildfly 11.0.0.Final JSF 1.2 configuration error
> ------------------------------------------------
>
>                 Key: WFLY-9708
>                 URL: https://issues.jboss.org/browse/WFLY-9708
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 11.0.0.Final
>            Reporter: Luis Canales
>            Assignee: Martin Kouba
>            Priority: Optional
>         Attachments: log.txt
>
>
> Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:
> _java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_
> If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 03:41:00 2018
From: issues at jboss.org (Daniel Bildhauer (JIRA))
Date: Fri, 19 Jan 2018 03:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3512) ClassReflectionIndexUtil
 does not return default methods from findMethod
In-Reply-To: <JIRA.12729299.1516120996000@Atlassian.JIRA>
References: <JIRA.12729299.1516120996000@Atlassian.JIRA>
	<JIRA.12729299.1516120996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729299.1516120996000.68163.1516351260278@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521207#comment-13521207 ] 

Daniel Bildhauer commented on WFCORE-3512:
------------------------------------------

Hi,

[~swd847] is there any chance to get this fix also back to the version that will be in Wildfly 11.1? 

Best regards

Daniel

> ClassReflectionIndexUtil does not return default methods from findMethod
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-3512
>                 URL: https://issues.jboss.org/browse/WFCORE-3512
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Daniel Bildhauer
>            Assignee: Stuart Douglas
>             Fix For: 4.0.0.Alpha6
>
>         Attachments: ejb-in-ear.zip, wildfly-ejb-in-ear-ear.ear
>
>
> This problem is in Wildfly Core, but manifests as an issue with EJB's in WildFly full.
> Given the following class/interface inheritance structure, the interface method doMagic could not be called from a remote view, even if there is a default implementation as given in the mixin interface. A local call works, but the remote call fails with a message like
> {code}
> org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
> {code}
> Example code:
> {code}
> @Remote
> interface MyEJBInterface {
>    void doMagic();
> }
> interface MyEJBMixin extends MyEJBInterface {
>    default void doMagic() { .... }
> }
> @Stateless
> class MyEJBBean extends MyEJBMixin {
> }
> {code}
> The problem is inside the fix for WFLY-4354 bug, which checks only for the default method implementation in the interface declaring the method the first time but not in other interfaces. 
> A example is attached and I will submitt a pull request with a fix. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 05:05:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 19 Jan 2018 05:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2250) Align Engine hints in
 Decision Table column wizard with BAPL-708
In-Reply-To: <JIRA.12729471.1516193793000@Atlassian.JIRA>
References: <JIRA.12729471.1516193793000@Atlassian.JIRA>
	<JIRA.12729471.1516193793000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729471.1516193793000.68721.1516356300796@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2250:
-----------------------------------
    Sprint: 2018 Week 03-04


> Align Engine hints in Decision Table column wizard with BAPL-708
> ----------------------------------------------------------------
>
>                 Key: DROOLS-2250
>                 URL: https://issues.jboss.org/browse/DROOLS-2250
>             Project: Drools
>          Issue Type: Task
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: Screenshot from 2018-01-17 13-49-51.png, Screenshot from 2018-01-17 13-50-37.png
>
>
> Due to the BAPL-708 and the [doc|https://docs.google.com/spreadsheets/d/1kmK92hY3JJp7gZTvLzd0CawaZzvI2MYYv2uaLaQcMJc/edit#gid=1999150540] with new product terminology, we should update the Engine hint shown in the attached screenshots. We should use *decision engine* or *process / engine* instad of *inference engine*, *rules engine* etc.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 05:14:00 2018
From: issues at jboss.org (Dmitry Volodin (JIRA))
Date: Fri, 19 Jan 2018 05:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2253) Upgrade protobuf-java from
 2.6.0 to 2.6.1
In-Reply-To: <JIRA.12729860.1516356829000@Atlassian.JIRA>
References: <JIRA.12729860.1516356829000@Atlassian.JIRA>
	<JIRA.12729860.1516356829839@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729860.1516356829000.68753.1516356840414@Atlassian.JIRA>

Dmitry Volodin created DROOLS-2253:
--------------------------------------

             Summary: Upgrade protobuf-java from 2.6.0 to 2.6.1
                 Key: DROOLS-2253
                 URL: https://issues.jboss.org/browse/DROOLS-2253
             Project: Drools
          Issue Type: Task
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Dmitry Volodin
            Assignee: Dmitry Volodin
            Priority: Minor
             Fix For: 7.6.0.Final


This update requires for automate protobuf builds with Maven Protocol Buffers Plugin as starting version 2.6.1 Google publish protoc utility in the maven repository for all major releases and further change will rebuild .proto files depends on version or source changes.
The prorobuf versions 2.6.0 and 2.6.1 are fully binary and source compatible.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 05:49:00 2018
From: issues at jboss.org (Dmitry Volodin (JIRA))
Date: Fri, 19 Jan 2018 05:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2254) Automate .proto files rebuld
In-Reply-To: <JIRA.12729876.1516358909000@Atlassian.JIRA>
References: <JIRA.12729876.1516358909000@Atlassian.JIRA>
	<JIRA.12729876.1516358909216@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729876.1516358909000.68929.1516358940412@Atlassian.JIRA>

Dmitry Volodin created DROOLS-2254:
--------------------------------------

             Summary: Automate .proto files rebuld
                 Key: DROOLS-2254
                 URL: https://issues.jboss.org/browse/DROOLS-2254
             Project: Drools
          Issue Type: Task
          Components: tools
    Affects Versions: 7.5.0.Final
            Reporter: Dmitry Volodin
            Assignee: Dmitry Volodin
            Priority: Minor
             Fix For: 7.6.0.Final


According to contribution guide, any .proto file or protobuf version changes it's necessary to download protoc utility and regenerate Java classes based on .proto files.
This will add automation for downloading protoc utility and Java classes generation based on Maven Protocol Buffers Plugin. There is no timestamps and other build related info inside generated Java files and no changes will be added on each new build.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 05:54:00 2018
From: issues at jboss.org (Dmitry Volodin (JIRA))
Date: Fri, 19 Jan 2018 05:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2254) Automate .proto files
	rebuild
In-Reply-To: <JIRA.12729876.1516358909000@Atlassian.JIRA>
References: <JIRA.12729876.1516358909000@Atlassian.JIRA>
	<JIRA.12729876.1516358909000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729876.1516358909000.68957.1516359240357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitry Volodin updated DROOLS-2254:
-----------------------------------
    Summary: Automate .proto files rebuild  (was: Automate .proto files rebuld)


> Automate .proto files rebuild
> -----------------------------
>
>                 Key: DROOLS-2254
>                 URL: https://issues.jboss.org/browse/DROOLS-2254
>             Project: Drools
>          Issue Type: Task
>          Components: tools
>    Affects Versions: 7.5.0.Final
>            Reporter: Dmitry Volodin
>            Assignee: Dmitry Volodin
>            Priority: Minor
>             Fix For: 7.6.0.Final
>
>
> According to contribution guide, any .proto file or protobuf version changes it's necessary to download protoc utility and regenerate Java classes based on .proto files.
> This will add automation for downloading protoc utility and Java classes generation based on Maven Protocol Buffers Plugin. There is no timestamps and other build related info inside generated Java files and no changes will be added on each new build.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 05:55:00 2018
From: issues at jboss.org (Dmitry Volodin (JIRA))
Date: Fri, 19 Jan 2018 05:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2254) Automate .proto files
	rebuild in maven
In-Reply-To: <JIRA.12729876.1516358909000@Atlassian.JIRA>
References: <JIRA.12729876.1516358909000@Atlassian.JIRA>
	<JIRA.12729876.1516358909000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729876.1516358909000.68959.1516359300063@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitry Volodin updated DROOLS-2254:
-----------------------------------
    Summary: Automate .proto files rebuild in maven  (was: Automate .proto files rebuild)


> Automate .proto files rebuild in maven
> --------------------------------------
>
>                 Key: DROOLS-2254
>                 URL: https://issues.jboss.org/browse/DROOLS-2254
>             Project: Drools
>          Issue Type: Task
>          Components: tools
>    Affects Versions: 7.5.0.Final
>            Reporter: Dmitry Volodin
>            Assignee: Dmitry Volodin
>            Priority: Minor
>             Fix For: 7.6.0.Final
>
>
> According to contribution guide, any .proto file or protobuf version changes it's necessary to download protoc utility and regenerate Java classes based on .proto files.
> This will add automation for downloading protoc utility and Java classes generation based on Maven Protocol Buffers Plugin. There is no timestamps and other build related info inside generated Java files and no changes will be added on each new build.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 06:05:00 2018
From: issues at jboss.org (Dmitry Volodin (JIRA))
Date: Fri, 19 Jan 2018 06:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2254) Automate .proto files
	rebuild in pom.xml
In-Reply-To: <JIRA.12729876.1516358909000@Atlassian.JIRA>
References: <JIRA.12729876.1516358909000@Atlassian.JIRA>
	<JIRA.12729876.1516358909000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729876.1516358909000.68977.1516359900201@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2254?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dmitry Volodin updated DROOLS-2254:
-----------------------------------
    Summary: Automate .proto files rebuild in pom.xml  (was: Automate .proto files rebuild in maven)


> Automate .proto files rebuild in pom.xml
> ----------------------------------------
>
>                 Key: DROOLS-2254
>                 URL: https://issues.jboss.org/browse/DROOLS-2254
>             Project: Drools
>          Issue Type: Task
>          Components: tools
>    Affects Versions: 7.5.0.Final
>            Reporter: Dmitry Volodin
>            Assignee: Dmitry Volodin
>            Priority: Minor
>             Fix For: 7.6.0.Final
>
>
> According to contribution guide, any .proto file or protobuf version changes it's necessary to download protoc utility and regenerate Java classes based on .proto files.
> This will add automation for downloading protoc utility and Java classes generation based on Maven Protocol Buffers Plugin. There is no timestamps and other build related info inside generated Java files and no changes will be added on each new build.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 06:13:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 19 Jan 2018 06:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2255) [DMN designer] Node labels
 move between savings
In-Reply-To: <JIRA.12729882.1516360348000@Atlassian.JIRA>
References: <JIRA.12729882.1516360348000@Atlassian.JIRA>
	<JIRA.12729882.1516360348788@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729882.1516360348000.69040.1516360380313@Atlassian.JIRA>

Jozef Marko created DROOLS-2255:
-----------------------------------

             Summary: [DMN designer] Node labels move between savings
                 Key: DROOLS-2255
                 URL: https://issues.jboss.org/browse/DROOLS-2255
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis
            Priority: Minor
         Attachments: after-save.png, before-save.png

The attachments shows DMN diagram before and after saving, it can be seen that node labels moved.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 06:23:00 2018
From: issues at jboss.org (chandra shaker (JIRA))
Date: Fri, 19 Jan 2018 06:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3526) deployement is failing in
 wildlfy10.0.1 final version
In-Reply-To: <JIRA.12729888.1516360936000@Atlassian.JIRA>
References: <JIRA.12729888.1516360936000@Atlassian.JIRA>
	<JIRA.12729888.1516360936801@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729888.1516360936000.69090.1516360980782@Atlassian.JIRA>

chandra shaker created WFCORE-3526:
--------------------------------------

             Summary: deployement is failing in wildlfy10.0.1 final version
                 Key: WFCORE-3526
                 URL: https://issues.jboss.org/browse/WFCORE-3526
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Server
            Reporter: chandra shaker
            Assignee: Jason Greene






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 06:33:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 19 Jan 2018 06:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3526) deployement is failing in
 wildlfy10.0.1 final version
In-Reply-To: <JIRA.12729888.1516360937000@Atlassian.JIRA>
References: <JIRA.12729888.1516360937000@Atlassian.JIRA>
	<JIRA.12729888.1516360937000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729888.1516360937000.69154.1516361580386@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved WFCORE-3526.
--------------------------------------
      Assignee:     (was: Jason Greene)
    Resolution: Rejected


If you are looking for assistance please use the user forums http://wildfly.org/gethelp/ 

> deployement is failing in wildlfy10.0.1 final version
> -----------------------------------------------------
>
>                 Key: WFCORE-3526
>                 URL: https://issues.jboss.org/browse/WFCORE-3526
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Server
>            Reporter: chandra shaker
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 06:55:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 19 Jan 2018 06:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2255) [DMN designer] Node labels
 move between savings
In-Reply-To: <JIRA.12729882.1516360349000@Atlassian.JIRA>
References: <JIRA.12729882.1516360349000@Atlassian.JIRA>
	<JIRA.12729882.1516360349000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729882.1516360349000.69476.1516362900377@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis reassigned DROOLS-2255:
--------------------------------------

    Assignee: Roger Mart?nez  (was: Michael Anstis)


> [DMN designer] Node labels move between savings
> -----------------------------------------------
>
>                 Key: DROOLS-2255
>                 URL: https://issues.jboss.org/browse/DROOLS-2255
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Roger Mart?nez
>            Priority: Minor
>         Attachments: after-save.png, before-save.png
>
>
> The attachments shows DMN diagram before and after saving, it can be seen that node labels moved.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 06:56:03 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 19 Jan 2018 06:56:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2255) [DMN designer] Node labels
 move between savings
In-Reply-To: <JIRA.12729882.1516360349000@Atlassian.JIRA>
References: <JIRA.12729882.1516360349000@Atlassian.JIRA>
	<JIRA.12729882.1516360349000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729882.1516360349000.69495.1516362963851@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521326#comment-13521326 ] 

Michael Anstis commented on DROOLS-2255:
----------------------------------------

[~jomarko] Sorry, I thought you meant the whole {{Node}} moved.. Just the label is a Stunner issue.

> [DMN designer] Node labels move between savings
> -----------------------------------------------
>
>                 Key: DROOLS-2255
>                 URL: https://issues.jboss.org/browse/DROOLS-2255
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Roger Mart?nez
>            Priority: Minor
>         Attachments: after-save.png, before-save.png
>
>
> The attachments shows DMN diagram before and after saving, it can be seen that node labels moved.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 07:06:00 2018
From: issues at jboss.org (Kirill Gaevskii (JIRA))
Date: Fri, 19 Jan 2018 07:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2255) [DMN designer] Node labels
 move between savings
In-Reply-To: <JIRA.12729882.1516360349000@Atlassian.JIRA>
References: <JIRA.12729882.1516360349000@Atlassian.JIRA>
	<JIRA.12729882.1516360349000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729882.1516360349000.69794.1516363560363@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kirill Gaevskii updated DROOLS-2255:
------------------------------------
    Labels: Stunner  (was: )


> [DMN designer] Node labels move between savings
> -----------------------------------------------
>
>                 Key: DROOLS-2255
>                 URL: https://issues.jboss.org/browse/DROOLS-2255
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Roger Mart?nez
>            Priority: Minor
>              Labels: Stunner
>         Attachments: after-save.png, before-save.png
>
>
> The attachments shows DMN diagram before and after saving, it can be seen that node labels moved.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 08:04:00 2018
From: issues at jboss.org (Stan Silvert (JIRA))
Date: Fri, 19 Jan 2018 08:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279795000@Atlassian.JIRA>
References: <JIRA.12729735.1516279795000@Atlassian.JIRA>
	<JIRA.12729735.1516279795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279795000.70350.1516367040223@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521382#comment-13521382 ] 

Stan Silvert commented on WFLY-9708:
------------------------------------

It's been a very long time since I worked on that code.  The person to ask would be [~fjuma].

> Wildfly 11.0.0.Final JSF 1.2 configuration error
> ------------------------------------------------
>
>                 Key: WFLY-9708
>                 URL: https://issues.jboss.org/browse/WFLY-9708
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 11.0.0.Final
>            Reporter: Luis Canales
>            Assignee: Martin Kouba
>            Priority: Optional
>         Attachments: log.txt
>
>
> Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:
> _java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_
> If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 08:37:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 19 Jan 2018 08:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2250) Align Engine hints in
 Decision Table column wizard with BAPL-708
In-Reply-To: <JIRA.12729471.1516193793000@Atlassian.JIRA>
References: <JIRA.12729471.1516193793000@Atlassian.JIRA>
	<JIRA.12729471.1516193793000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729471.1516193793000.70583.1516369020290@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2250:
--------------------------------
    Attachment: Screenshot from 2018-01-19 14-35-50.png


> Align Engine hints in Decision Table column wizard with BAPL-708
> ----------------------------------------------------------------
>
>                 Key: DROOLS-2250
>                 URL: https://issues.jboss.org/browse/DROOLS-2250
>             Project: Drools
>          Issue Type: Task
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: Screenshot from 2018-01-17 13-49-51.png, Screenshot from 2018-01-17 13-50-37.png, Screenshot from 2018-01-19 14-35-50.png
>
>
> Due to the BAPL-708 and the [doc|https://docs.google.com/spreadsheets/d/1kmK92hY3JJp7gZTvLzd0CawaZzvI2MYYv2uaLaQcMJc/edit#gid=1999150540] with new product terminology, we should update the Engine hint shown in the attached screenshots. We should use *decision engine* or *process / engine* instad of *inference engine*, *rules engine* etc.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 08:38:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 19 Jan 2018 08:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2250) Align Engine hints in
 Decision Table column wizard with BAPL-708
In-Reply-To: <JIRA.12729471.1516193793000@Atlassian.JIRA>
References: <JIRA.12729471.1516193793000@Atlassian.JIRA>
	<JIRA.12729471.1516193793000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729471.1516193793000.70589.1516369080748@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2250:
--------------------------------
    Description: 
Due to the BAPL-708 and the [doc|https://docs.google.com/spreadsheets/d/1kmK92hY3JJp7gZTvLzd0CawaZzvI2MYYv2uaLaQcMJc/edit#gid=1999150540] with new product terminology, we should update the Engine hint shown in the attached screenshots. We should use *decision engine* or *process / engine* instad of *inference engine*, *rules engine* etc.

[edited]
Also the Data Object designer affected, see the role hint.  !Screenshot from 2018-01-19 14-35-50.png|thumbnail! 

  was:Due to the BAPL-708 and the [doc|https://docs.google.com/spreadsheets/d/1kmK92hY3JJp7gZTvLzd0CawaZzvI2MYYv2uaLaQcMJc/edit#gid=1999150540] with new product terminology, we should update the Engine hint shown in the attached screenshots. We should use *decision engine* or *process / engine* instad of *inference engine*, *rules engine* etc.



> Align Engine hints in Decision Table column wizard with BAPL-708
> ----------------------------------------------------------------
>
>                 Key: DROOLS-2250
>                 URL: https://issues.jboss.org/browse/DROOLS-2250
>             Project: Drools
>          Issue Type: Task
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: Screenshot from 2018-01-17 13-49-51.png, Screenshot from 2018-01-17 13-50-37.png, Screenshot from 2018-01-19 14-35-50.png
>
>
> Due to the BAPL-708 and the [doc|https://docs.google.com/spreadsheets/d/1kmK92hY3JJp7gZTvLzd0CawaZzvI2MYYv2uaLaQcMJc/edit#gid=1999150540] with new product terminology, we should update the Engine hint shown in the attached screenshots. We should use *decision engine* or *process / engine* instad of *inference engine*, *rules engine* etc.
> [edited]
> Also the Data Object designer affected, see the role hint.  !Screenshot from 2018-01-19 14-35-50.png|thumbnail! 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 08:38:02 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 19 Jan 2018 08:38:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2250) Align Engine hints in
 Decision Table column wizard with BAPL-708
In-Reply-To: <JIRA.12729471.1516193793000@Atlassian.JIRA>
References: <JIRA.12729471.1516193793000@Atlassian.JIRA>
	<JIRA.12729471.1516193793000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729471.1516193793000.70602.1516369082153@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2250?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2250:
--------------------------------
    Description: 
Due to the BAPL-708 and the [doc|https://docs.google.com/spreadsheets/d/1kmK92hY3JJp7gZTvLzd0CawaZzvI2MYYv2uaLaQcMJc/edit#gid=1999150540] with new product terminology, we should update the Engine hint shown in the attached screenshots. We should use *decision engine* or *process / engine* instad of *inference engine*, *rules engine* etc.

[edited]
Also the Data Object designer affected, see the role hint.
!Screenshot from 2018-01-19 14-35-50.png|thumbnail! 

  was:
Due to the BAPL-708 and the [doc|https://docs.google.com/spreadsheets/d/1kmK92hY3JJp7gZTvLzd0CawaZzvI2MYYv2uaLaQcMJc/edit#gid=1999150540] with new product terminology, we should update the Engine hint shown in the attached screenshots. We should use *decision engine* or *process / engine* instad of *inference engine*, *rules engine* etc.

[edited]
Also the Data Object designer affected, see the role hint.  !Screenshot from 2018-01-19 14-35-50.png|thumbnail! 



> Align Engine hints in Decision Table column wizard with BAPL-708
> ----------------------------------------------------------------
>
>                 Key: DROOLS-2250
>                 URL: https://issues.jboss.org/browse/DROOLS-2250
>             Project: Drools
>          Issue Type: Task
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: Screenshot from 2018-01-17 13-49-51.png, Screenshot from 2018-01-17 13-50-37.png, Screenshot from 2018-01-19 14-35-50.png
>
>
> Due to the BAPL-708 and the [doc|https://docs.google.com/spreadsheets/d/1kmK92hY3JJp7gZTvLzd0CawaZzvI2MYYv2uaLaQcMJc/edit#gid=1999150540] with new product terminology, we should update the Engine hint shown in the attached screenshots. We should use *decision engine* or *process / engine* instad of *inference engine*, *rules engine* etc.
> [edited]
> Also the Data Object designer affected, see the role hint.
> !Screenshot from 2018-01-19 14-35-50.png|thumbnail! 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 08:45:00 2018
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 19 Jan 2018 08:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9711) Move web tests in
	integration/web
In-Reply-To: <JIRA.12729838.1516336411000@Atlassian.JIRA>
References: <JIRA.12729838.1516336411000@Atlassian.JIRA>
	<JIRA.12729838.1516336411000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729838.1516336411000.70702.1516369500679@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9711?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521406#comment-13521406 ] 

Tomaz Cerar commented on WFLY-9711:
-----------------------------------

It should be other way around. 
We should eliminate web testsuite completely and move everything to basic testsuite.

> Move web tests in integration/web
> ---------------------------------
>
>                 Key: WFLY-9711
>                 URL: https://issues.jboss.org/browse/WFLY-9711
>             Project: WildFly
>          Issue Type: Task
>          Components: Test Suite
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>
> At the moment web tests are split between integration/basic and integration/web, they should only be in integration/web



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 08:49:01 2018
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Fri, 19 Jan 2018 08:49:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1481) Coverity,
 Explicit null dereferenced in FileSystemSecurityRealm
In-Reply-To: <JIRA.12726445.1515055992000@Atlassian.JIRA>
References: <JIRA.12726445.1515055992000@Atlassian.JIRA>
	<JIRA.12726445.1515055992000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726445.1515055992000.70769.1516369741002@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1481?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ilia Vassilev reassigned ELY-1481:
----------------------------------

    Assignee: Ilia Vassilev


> Coverity, Explicit null dereferenced in FileSystemSecurityRealm
> ---------------------------------------------------------------
>
>                 Key: ELY-1481
>                 URL: https://issues.jboss.org/browse/ELY-1481
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>
> There are 2 occurences of call to PasswordFactory.getInstance(algorithm) in FileSystemSecurityRealm where algorithm can be null, because algorithm is optional in wildfly-config.xml
> {code:xml|title=elytron-1_0_1.xsd}
>     <xsd:complexType name="credential-type">
>         <xsd:simpleContent>
>             <xsd:extension base="xsd:string">
>                 <xsd:attribute name="algorithm" type="xsd:string" use="optional"/>
>                 <xsd:attribute name="format" type="xsd:string" use="optional"/>
>             </xsd:extension>
>         </xsd:simpleContent>
>     </xsd:complexType>
>     <xsd:complexType name="otp-credential-type">
>         <xsd:simpleContent>
>             <xsd:extension base="xsd:string">
>                 <xsd:attribute name="algorithm" type="xsd:string" use="optional"/>
>                 <xsd:attribute name="hash" type="xsd:string" use="optional"/>
>                 <xsd:attribute name="seed" type="xsd:string" use="optional"/>
>                 <xsd:attribute name="sequence" type="xsd:string" use="optional"/>
>             </xsd:extension>
>         </xsd:simpleContent>
>     </xsd:complexType>
> {code}
> Algorithm is dereferenced in PasswordFactory.getInstance(algorithm) down in 
> {code:java|title=java.security.Provider$ServiceKey.java}
>         private ServiceKey(String type, String algorithm, boolean intern) {
>             this.type = type;
>             this.originalAlgorithm = algorithm;
>             algorithm = algorithm.toUpperCase(ENGLISH);
>             this.algorithm = intern ? algorithm.intern() : algorithm;
>         }
> {code}
> [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847809&defectInstanceId=9457601&mergedDefectId=1463442
> [2] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847809&defectInstanceId=9457602&mergedDefectId=1463441



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 08:57:00 2018
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 19 Jan 2018 08:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3512) ClassReflectionIndexUtil
 does not return default methods from findMethod
In-Reply-To: <JIRA.12729299.1516120996000@Atlassian.JIRA>
References: <JIRA.12729299.1516120996000@Atlassian.JIRA>
	<JIRA.12729299.1516120996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729299.1516120996000.70866.1516370220650@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521414#comment-13521414 ] 

Tomaz Cerar commented on WFCORE-3512:
-------------------------------------

Next version is 12, which should be released soon.
Currently there is no plan for 11.1.

> ClassReflectionIndexUtil does not return default methods from findMethod
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-3512
>                 URL: https://issues.jboss.org/browse/WFCORE-3512
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Daniel Bildhauer
>            Assignee: Stuart Douglas
>             Fix For: 4.0.0.Alpha6
>
>         Attachments: ejb-in-ear.zip, wildfly-ejb-in-ear-ear.ear
>
>
> This problem is in Wildfly Core, but manifests as an issue with EJB's in WildFly full.
> Given the following class/interface inheritance structure, the interface method doMagic could not be called from a remote view, even if there is a default implementation as given in the mixin interface. A local call works, but the remote call fails with a message like
> {code}
> org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
> {code}
> Example code:
> {code}
> @Remote
> interface MyEJBInterface {
>    void doMagic();
> }
> interface MyEJBMixin extends MyEJBInterface {
>    default void doMagic() { .... }
> }
> @Stateless
> class MyEJBBean extends MyEJBMixin {
> }
> {code}
> The problem is inside the fix for WFLY-4354 bug, which checks only for the default method implementation in the interface declaring the method the first time but not in other interfaces. 
> A example is attached and I will submitt a pull request with a fix. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 09:32:03 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 19 Jan 2018 09:32:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2256) [DMN Designer] Scrollbars
 in full screen mode
In-Reply-To: <JIRA.12729965.1516372301000@Atlassian.JIRA>
References: <JIRA.12729965.1516372301000@Atlassian.JIRA>
	<JIRA.12729965.1516372301864@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729965.1516372301000.71228.1516372323778@Atlassian.JIRA>

Jozef Marko created DROOLS-2256:
-----------------------------------

             Summary: [DMN Designer] Scrollbars in full screen mode 
                 Key: DROOLS-2256
                 URL: https://issues.jboss.org/browse/DROOLS-2256
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis
         Attachments: Screenshot from 2018-01-19 13-39-20.png, Screenshot from 2018-01-19 13-39-52.png

The scroll bars doesn't work in some cases during full screen mode is in action.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 09:34:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 19 Jan 2018 09:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2256) [DMN Designer] Scrollbars
 in full screen mode
In-Reply-To: <JIRA.12729965.1516372302000@Atlassian.JIRA>
References: <JIRA.12729965.1516372302000@Atlassian.JIRA>
	<JIRA.12729965.1516372302000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729965.1516372302000.71273.1516372440494@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2256:
--------------------------------
    Priority: Minor  (was: Major)


> [DMN Designer] Scrollbars in full screen mode 
> ----------------------------------------------
>
>                 Key: DROOLS-2256
>                 URL: https://issues.jboss.org/browse/DROOLS-2256
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>            Priority: Minor
>              Labels: Stunner
>         Attachments: Screenshot from 2018-01-19 13-39-20.png, Screenshot from 2018-01-19 13-39-52.png
>
>
> The scroll bars doesn't work in some cases during full screen mode is in action.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 09:47:00 2018
From: issues at jboss.org (Farah Juma (JIRA))
Date: Fri, 19 Jan 2018 09:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279795000@Atlassian.JIRA>
References: <JIRA.12729735.1516279795000@Atlassian.JIRA>
	<JIRA.12729735.1516279795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279795000.71365.1516373220795@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521461#comment-13521461 ] 

Farah Juma commented on WFLY-9708:
----------------------------------

The injection module is currently always added to the deployment by {{org.jboss.as.jsf.deployment.JSFDependencyProcessor}}:

https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/java/org/jboss/as/jsf/deployment/JSFDependencyProcessor.java#L91

> Wildfly 11.0.0.Final JSF 1.2 configuration error
> ------------------------------------------------
>
>                 Key: WFLY-9708
>                 URL: https://issues.jboss.org/browse/WFLY-9708
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 11.0.0.Final
>            Reporter: Luis Canales
>            Assignee: Martin Kouba
>            Priority: Optional
>         Attachments: log.txt
>
>
> Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:
> _java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_
> If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 09:55:00 2018
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 19 Jan 2018 09:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279795000@Atlassian.JIRA>
References: <JIRA.12729735.1516279795000@Atlassian.JIRA>
	<JIRA.12729735.1516279795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279795000.71411.1516373700419@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521468#comment-13521468 ] 

Martin Kouba commented on WFLY-9708:
------------------------------------

Thanks [~fjuma]. Then it seems the only way to run JSF 1.2 app on WildFly 11.0.0.Final is to bundle the JSF impl?

> Wildfly 11.0.0.Final JSF 1.2 configuration error
> ------------------------------------------------
>
>                 Key: WFLY-9708
>                 URL: https://issues.jboss.org/browse/WFLY-9708
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 11.0.0.Final
>            Reporter: Luis Canales
>            Assignee: Martin Kouba
>            Priority: Optional
>         Attachments: log.txt
>
>
> Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:
> _java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_
> If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 10:06:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 19 Jan 2018 10:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2246) Internal thread pool not
 created if default thread pool is injected
In-Reply-To: <JIRA.12729969.1516374337000@Atlassian.JIRA>
References: <JIRA.12729969.1516374337000@Atlassian.JIRA>
	<JIRA.12729969.1516374337391@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729969.1516374337000.71514.1516374360129@Atlassian.JIRA>

Paul Ferraro created JGRP-2246:
----------------------------------

             Summary: Internal thread pool not created if default thread pool is injected
                 Key: JGRP-2246
                 URL: https://issues.jboss.org/browse/JGRP-2246
             Project: JGroups
          Issue Type: Bug
    Affects Versions: 4.0.9
            Reporter: Paul Ferraro
            Assignee: Bela Ban


WildFly injects a custom thread pool into its JGroups transports.  However, in JGroups 4.0.x, only the default thread pool exposes a setThreadPool(...) method.  The internal thread pool does not.  However, the logic within TP.init() will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly.
Can we restore the TP.setInternalThreadPool(...) method?



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 10:15:02 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Fri, 19 Jan 2018 10:15:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2246) Internal thread pool not
 created if default thread pool is injected
In-Reply-To: <JIRA.12729969.1516374337000@Atlassian.JIRA>
References: <JIRA.12729969.1516374337000@Atlassian.JIRA>
	<JIRA.12729969.1516374337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729969.1516374337000.71587.1516374902440@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro updated JGRP-2246:
-------------------------------
    Description: 
WildFly injects a custom thread pool into its JGroups transports.  However, in JGroups 4.0.x, only the default thread pool exposes a setThreadPool(...) method.  The internal thread pool does not.  However, the logic within TP.init() will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly.
Can we restore the TP.setInternalThreadPool(...) method?  Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when thread_pool_enabled is true? 

  was:
WildFly injects a custom thread pool into its JGroups transports.  However, in JGroups 4.0.x, only the default thread pool exposes a setThreadPool(...) method.  The internal thread pool does not.  However, the logic within TP.init() will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly.
Can we restore the TP.setInternalThreadPool(...) method?



> Internal thread pool not created if default thread pool is injected
> -------------------------------------------------------------------
>
>                 Key: JGRP-2246
>                 URL: https://issues.jboss.org/browse/JGRP-2246
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.9
>            Reporter: Paul Ferraro
>            Assignee: Bela Ban
>
> WildFly injects a custom thread pool into its JGroups transports.  However, in JGroups 4.0.x, only the default thread pool exposes a setThreadPool(...) method.  The internal thread pool does not.  However, the logic within TP.init() will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly.
> Can we restore the TP.setInternalThreadPool(...) method?  Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when thread_pool_enabled is true? 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 10:38:01 2018
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Fri, 19 Jan 2018 10:38:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279795000@Atlassian.JIRA>
References: <JIRA.12729735.1516279795000@Atlassian.JIRA>
	<JIRA.12729735.1516279795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279795000.71664.1516376281177@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Kouba reassigned WFLY-9708:
----------------------------------

    Assignee:     (was: Martin Kouba)


> Wildfly 11.0.0.Final JSF 1.2 configuration error
> ------------------------------------------------
>
>                 Key: WFLY-9708
>                 URL: https://issues.jboss.org/browse/WFLY-9708
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 11.0.0.Final
>            Reporter: Luis Canales
>            Priority: Optional
>         Attachments: log.txt
>
>
> Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:
> _java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_
> If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 10:43:00 2018
From: issues at jboss.org (Farah Juma (JIRA))
Date: Fri, 19 Jan 2018 10:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9708) Wildfly 11.0.0.Final JSF 1.2
 configuration error
In-Reply-To: <JIRA.12729735.1516279795000@Atlassian.JIRA>
References: <JIRA.12729735.1516279795000@Atlassian.JIRA>
	<JIRA.12729735.1516279795000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729735.1516279795000.71718.1516376580692@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9708?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521497#comment-13521497 ] 

Farah Juma commented on WFLY-9708:
----------------------------------

[~mkouba] Yes, it seems so. The only other option might be to manually update the injection module after using the multi-jsf installer so it contains the working version of {{WeldApplication}}.

> Wildfly 11.0.0.Final JSF 1.2 configuration error
> ------------------------------------------------
>
>                 Key: WFLY-9708
>                 URL: https://issues.jboss.org/browse/WFLY-9708
>             Project: WildFly
>          Issue Type: Bug
>          Components: CDI / Weld, JSF
>    Affects Versions: 11.0.0.Final
>            Reporter: Luis Canales
>            Priority: Optional
>         Attachments: log.txt
>
>
> Since WFLY-8815, the class WeldApplication extends ApplicationWrapper. The class "ApplicationWrapper" was created in JSF2.0, so when I try to build JSF1.2 modules (see https://developer.jboss.org/wiki/StepsToAddAnyNewJSFImplementationOrVersionToWildFly) and deploy a JSF1.2 application, I get this error:
> _java.lang.NoClassDefFoundError: Failed to link org/jboss/as/jsf/injection/weld/WeldApplication (Module "org.jboss.as.jsf-injection:mojarra-1.2_15" from local module loader @3aa9e816 (finder: local module finder @17d99928 (roots: C:\Java\wildfly-11.0.0.Final.gts\modules,C:\Java\wildfly-11.0.0.Final.gts\modules\system\layers\base))): javax/faces/application/ApplicationWrapper_
> If I change WeldApplication extends to ForwardingApplication and rebuild modules, the application runs OK.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 11:03:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 11:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3524) Attempt to initialize the
 latest Extension parser if that has been registered are suppliers
In-Reply-To: <JIRA.12729832.1516322441000@Atlassian.JIRA>
References: <JIRA.12729832.1516322441000@Atlassian.JIRA>
	<JIRA.12729832.1516322441000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729832.1516322441000.71863.1516377780338@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3524?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3524:
-------------------------------------
    Description: 
The ExtensionParsingContext.setSubsystemXmlMapping(String subsystemName, String namespaceUri, Supplier<XMLElementReader<List<ModelNode>>> supplier) method may save memory space by deferring construction of the parser, but it also may mean that the management model classloading and definition initialization work that often is done by the parser is deferred until parsing begins. And parsing is a single-threaded part of boot, so deferring this work out of the concurrent extension initialization work until parsing slows down boot.

I'd been asking people to use the non-supplier ExtensionParsingContext.setSubsystemXmlMapping variant for the latest parser, but that's unintuitive and requires further unintuitive work every time a new parser is added.

To limit the need for that, instead the ExtensionRegistry, if it sees that only suppliers have been registered, will attempt to construct the "latest" parser (by calling its supplier). It will determine the "latest" supplier by lexicographic comparison of the registered namespaces.

See the discussion on https://github.com/wildfly/wildfly-core/pull/3035

  was:
The ExtensionParsingContext.setSubsystemXmlMapping(String subsystemName, String namespaceUri, Supplier<XMLElementReader<List<ModelNode>>> supplier) method may save memory space by deferring construction of the parser, but it also may mean that the management model classloading and definition initialization work that often is done by the parser is deferred until parsing begins. And parsing is a single-threaded part of boot, so deferring this work out of the concurrent extension initialization work until parsing slows down boot.

I'd been asking people to use the non-supplier ExtensionParsingContext.setSubsystemXmlMapping variant for the latest parser, but that's unintuitive and requires further unintuitive work every time a new parser is added.

To limit the need for that, instead the ExtensionRegistry, if it sees that only suppliers have been registered, will attempt to construct the "latest" parser (by calling its supplier). It will determine the "latest" supplier by lexicographic comparison of the registered namespaces.



> Attempt to initialize the latest Extension parser if that has been registered are suppliers
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3524
>                 URL: https://issues.jboss.org/browse/WFCORE-3524
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> The ExtensionParsingContext.setSubsystemXmlMapping(String subsystemName, String namespaceUri, Supplier<XMLElementReader<List<ModelNode>>> supplier) method may save memory space by deferring construction of the parser, but it also may mean that the management model classloading and definition initialization work that often is done by the parser is deferred until parsing begins. And parsing is a single-threaded part of boot, so deferring this work out of the concurrent extension initialization work until parsing slows down boot.
> I'd been asking people to use the non-supplier ExtensionParsingContext.setSubsystemXmlMapping variant for the latest parser, but that's unintuitive and requires further unintuitive work every time a new parser is added.
> To limit the need for that, instead the ExtensionRegistry, if it sees that only suppliers have been registered, will attempt to construct the "latest" parser (by calling its supplier). It will determine the "latest" supplier by lexicographic comparison of the registered namespaces.
> See the discussion on https://github.com/wildfly/wildfly-core/pull/3035



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 11:09:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 11:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3523) Don't initialize extension
 parsers on a domain server
In-Reply-To: <JIRA.12729828.1516315678000@Atlassian.JIRA>
References: <JIRA.12729828.1516315678000@Atlassian.JIRA>
	<JIRA.12729828.1516315678000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729828.1516315678000.71934.1516378140342@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFCORE-3523.
--------------------------------------
    Resolution: Won't Do


A simple attempt at this (see https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCORE-3523 until I someday delete it) produced testsuite failures. Probably harmless ones (e.g. reading the management API from domain servers to determine xml namespaces no longer provides any), but just thinking about / getting rid of them takes the effort here beyond what I think it's worth.

> Don't initialize extension parsers on a domain server
> -----------------------------------------------------
>
>                 Key: WFCORE-3523
>                 URL: https://issues.jboss.org/browse/WFCORE-3523
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> The Extension.initializeParsers calls is pointless on a domain server, as that kind of process does not parse. So skip it and save the execution cost and the metaspace associated with the parsers.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 11:12:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 11:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3523) Don't initialize extension
 parsers on a domain server
In-Reply-To: <JIRA.12729828.1516315678000@Atlassian.JIRA>
References: <JIRA.12729828.1516315678000@Atlassian.JIRA>
	<JIRA.12729828.1516315678000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729828.1516315678000.71939.1516378320398@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3523?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521520#comment-13521520 ] 

Brian Stansberry edited comment on WFCORE-3523 at 1/19/18 11:11 AM:
--------------------------------------------------------------------

A simple attempt at this[1] produced testsuite failures. Probably harmless ones (e.g. reading the management API from domain servers to determine xml namespaces no longer provides any), but just thinking about / getting rid of them takes the effort here beyond what I think it's worth.

[1] see https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCORE-3523 until I someday delete it


was (Author: brian.stansberry):
A simple attempt at this (see https://github.com/wildfly/wildfly-core/compare/master...bstansberry:WFCORE-3523 until I someday delete it) produced testsuite failures. Probably harmless ones (e.g. reading the management API from domain servers to determine xml namespaces no longer provides any), but just thinking about / getting rid of them takes the effort here beyond what I think it's worth.

> Don't initialize extension parsers on a domain server
> -----------------------------------------------------
>
>                 Key: WFCORE-3523
>                 URL: https://issues.jboss.org/browse/WFCORE-3523
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> The Extension.initializeParsers calls is pointless on a domain server, as that kind of process does not parse. So skip it and save the execution cost and the metaspace associated with the parsers.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 11:15:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Fri, 19 Jan 2018 11:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3527) Remove OSGi obsolete code
In-Reply-To: <JIRA.12729983.1516378481000@Atlassian.JIRA>
References: <JIRA.12729983.1516378481000@Atlassian.JIRA>
	<JIRA.12729983.1516378481299@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729983.1516378481000.71966.1516378500286@Atlassian.JIRA>

Richard Opalka created WFCORE-3527:
--------------------------------------

             Summary: Remove OSGi obsolete code
                 Key: WFCORE-3527
                 URL: https://issues.jboss.org/browse/WFCORE-3527
             Project: WildFly Core
          Issue Type: Enhancement
          Components: Server
    Affects Versions: 4.0.0.Alpha5
            Reporter: Richard Opalka
            Assignee: Richard Opalka
             Fix For: 4.0.0.Alpha6






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 12:04:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 19 Jan 2018 12:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9713) Test suite tests using
 shrinkwrap are creating many duplicated classes
In-Reply-To: <JIRA.12729986.1516381384000@Atlassian.JIRA>
References: <JIRA.12729986.1516381384000@Atlassian.JIRA>
	<JIRA.12729986.1516381384961@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729986.1516381384000.72131.1516381440115@Atlassian.JIRA>

David Lloyd created WFLY-9713:
---------------------------------

             Summary: Test suite tests using shrinkwrap are creating many duplicated classes
                 Key: WFLY-9713
                 URL: https://issues.jboss.org/browse/WFLY-9713
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
            Reporter: David Lloyd


The test suite uses shrinkwrap rather extensively to generate archives.  It seems that there is a lot of fast-and-loose archive generation going on though: in many cases, the same class is being included in multiple archives in the same deployment.

The result is that if you change the class loading order so that the deployment loader comes first, you get errors like this:

{noformat}
Caused by: java.util.ServiceConfigurationError: org.jboss.msc.service.ServiceActivator: Provider org.jboss.as.test.integration.logging.LoggingServiceActivator not a subtype
{noformat}

Or this:

{noformat}
org.jboss.as.test.integration.jca.poolattributes.DatasourcePoolAttributesTestCase.testModifyNonReloadAttributes: java.lang.ClassCastException: org.jboss.as.connector.subsystems.datasources.WildFlyDataSource cannot be cast to org.jboss.as.connector.subsystems.datasources.WildFlyDataSource
{noformat}

This is related to other problems, whose JIRAs I will link presently.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 12:12:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 19 Jan 2018 12:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3528) Detect conflicting packages
 in deployments
In-Reply-To: <JIRA.12729987.1516381860000@Atlassian.JIRA>
References: <JIRA.12729987.1516381860000@Atlassian.JIRA>
	<JIRA.12729987.1516381860129@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729987.1516381860000.72185.1516381920216@Atlassian.JIRA>

David Lloyd created WFCORE-3528:
-----------------------------------

             Summary: Detect conflicting packages in deployments
                 Key: WFCORE-3528
                 URL: https://issues.jboss.org/browse/WFCORE-3528
             Project: WildFly Core
          Issue Type: Enhancement
            Reporter: David Lloyd


We should have a deployment processor which detects package conflicts within deployments.  It should ensure that no deployment package is exported by any module provided by the application server (the {{ModuleSpecification#getSystemDependencies}} set) (excluding {{META-INF/**}} and the empty package from consideration, and maybe one or two others).  The processor could either raise an error, or it could introduce a PathFilter to block the offending packages and print a warning to that effect.

We could also add other checks - like warning if the same package is present in more than one archive within the deployment that have visibility to each other, for example - but it's somewhat harder to establish hard rules about these cases that are always correct.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 12:22:00 2018
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 19 Jan 2018 12:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3529) Cleanup capability API
In-Reply-To: <JIRA.12729988.1516382493000@Atlassian.JIRA>
References: <JIRA.12729988.1516382493000@Atlassian.JIRA>
	<JIRA.12729988.1516382493851@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729988.1516382493000.72227.1516382520400@Atlassian.JIRA>

Tomaz Cerar created WFCORE-3529:
-----------------------------------

             Summary: Cleanup capability API
                 Key: WFCORE-3529
                 URL: https://issues.jboss.org/browse/WFCORE-3529
             Project: WildFly Core
          Issue Type: Task
          Components: Domain Management
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


We have few deprecated methods and methods that ware there just for binary comparability.

we should be able to remove them now.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 12:59:00 2018
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 19 Jan 2018 12:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-8858) Remove JPA container check
 for deprecated hibernate.ejb.use_class_enhancer
In-Reply-To: <JIRA.12694832.1496150977000@Atlassian.JIRA>
References: <JIRA.12694832.1496150977000@Atlassian.JIRA>
	<JIRA.12694832.1496150977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12694832.1496150977000.72328.1516384740080@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-8858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521569#comment-13521569 ] 

Scott Marlow commented on WFLY-8858:
------------------------------------

Also note that Hibernate doesn't rewrite entity classes by default, as per discussion on [http://lists.jboss.org/pipermail/hibernate-dev/2018-January/017072.html]

> Remove JPA container check for deprecated hibernate.ejb.use_class_enhancer
> --------------------------------------------------------------------------
>
>                 Key: WFLY-8858
>                 URL: https://issues.jboss.org/browse/WFLY-8858
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 12.0.0.Alpha1
>
>
> Applications can instead use the jboss.as.jpa.classtransformer property to control whether the application can use entity class rewriting.  Starting with Hibernate ORM 5.0+, Hibernate defaults to always rewrite entity classes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 13:47:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 19 Jan 2018 13:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-185) Wrong class loading strategy
 used in jboss-jaxrs-api_spec
In-Reply-To: <JIRA.12729994.1516387566000@Atlassian.JIRA>
References: <JIRA.12729994.1516387566000@Atlassian.JIRA>
	<JIRA.12729994.1516387566850@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729994.1516387566000.72391.1516387620241@Atlassian.JIRA>

David Lloyd created JBEE-185:
--------------------------------

             Summary: Wrong class loading strategy used in jboss-jaxrs-api_spec
                 Key: JBEE-185
                 URL: https://issues.jboss.org/browse/JBEE-185
             Project: JBoss JavaEE Spec APIs
          Issue Type: Bug
          Components: jboss-jaxrs-api
            Reporter: David Lloyd
            Assignee: Scott Marlow


The commit here: https://github.com/jboss/jboss-jaxrs-api_spec/commit/b578e70dd99a427758df7991c6456e40298d1dd0

...contains a wrong strategy for locating an API's implementation module.  The strategy used is to use reflection to try and find a fixed module name from a module repository, but this is brittle and unnecessary.

The correct strategy is to use your own class loader, like this:

{code:java}
// allowed with secmgr check because caller is the class in question
ClassLoader myClassLoader = MyClass.class.getClassLoader();
try (InputStream is = myClassLoader.getResourceAsStream(serviceId)) {
    // ...
} catch (IOException ex) {
    // ...
}
{code}

In the WildFly code, the JAX-RS API module should depend on the implementation module (probably with {{services="import"}}).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 13:47:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 19 Jan 2018 13:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBEE-185) Wrong class loading strategy
 used in jboss-jaxrs-api_spec
In-Reply-To: <JIRA.12729994.1516387567000@Atlassian.JIRA>
References: <JIRA.12729994.1516387567000@Atlassian.JIRA>
	<JIRA.12729994.1516387567000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729994.1516387567000.72396.1516387620341@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JBEE-185?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned JBEE-185:
--------------------------------

    Assignee: Alessio Soldano  (was: Scott Marlow)


> Wrong class loading strategy used in jboss-jaxrs-api_spec
> ---------------------------------------------------------
>
>                 Key: JBEE-185
>                 URL: https://issues.jboss.org/browse/JBEE-185
>             Project: JBoss JavaEE Spec APIs
>          Issue Type: Bug
>          Components: jboss-jaxrs-api
>            Reporter: David Lloyd
>            Assignee: Alessio Soldano
>
> The commit here: https://github.com/jboss/jboss-jaxrs-api_spec/commit/b578e70dd99a427758df7991c6456e40298d1dd0
> ...contains a wrong strategy for locating an API's implementation module.  The strategy used is to use reflection to try and find a fixed module name from a module repository, but this is brittle and unnecessary.
> The correct strategy is to use your own class loader, like this:
> {code:java}
> // allowed with secmgr check because caller is the class in question
> ClassLoader myClassLoader = MyClass.class.getClassLoader();
> try (InputStream is = myClassLoader.getResourceAsStream(serviceId)) {
>     // ...
> } catch (IOException ex) {
>     // ...
> }
> {code}
> In the WildFly code, the JAX-RS API module should depend on the implementation module (probably with {{services="import"}}).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 14:29:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Fri, 19 Jan 2018 14:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2409) Intermittent failures in
 SessionClusterDbPersistenceTestCase
In-Reply-To: <JIRA.12509093.1383137843000@Atlassian.JIRA>
References: <JIRA.12509093.1383137843000@Atlassian.JIRA>
	<JIRA.12509093.1383137843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509093.1383137843000.72626.1516390140272@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-2409:
---------------------------------
    Fix Version/s: 12.0.0.Alpha1


> Intermittent failures in SessionClusterDbPersistenceTestCase
> ------------------------------------------------------------
>
>                 Key: WFLY-2409
>                 URL: https://issues.jboss.org/browse/WFLY-2409
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>    Affects Versions: JBoss AS7 7.1.1.Final
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>             Fix For: 12.0.0.Alpha1
>
>
> &amp;#27;[0m&amp;#27;[31m08:43:00,006 ERROR [org.infinispan.persistence.jdbc.binary.JdbcBinaryStore] (default task-7) ISPN008012: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=35 bytes, valueBytes=270 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value={test=1}, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos; &apos;, -1)&quot;; SQL statement:
> INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:171)
> 	at org.h2.message.DbException.get(DbException.java:148)
> 	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
> 	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
> 	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
> 	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
> 	at org.h2.command.dml.Insert.update(Insert.java:86)
> 	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
> 	at org.h2.command.Command.executeUpdate(Command.java:235)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> &amp;#27;[0m&amp;#27;[31m08:43:00,018 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-7) ISPN000136: Execution error: org.infinispan.persistence.CacheLoaderException: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=35 bytes, valueBytes=270 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value={test=1}, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:411)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos; &apos;, -1)&quot;; SQL statement:
> INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:171)
> 	at org.h2.message.DbException.get(DbException.java:148)
> 	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
> 	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
> 	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
> 	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
> 	at org.h2.command.dml.Insert.update(Insert.java:86)
> 	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
> 	at org.h2.command.Command.executeUpdate(Command.java:235)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
> 	... 77 more
> &amp;#27;[0m&amp;#27;[31m08:43:00,023 ERROR [org.infinispan.transaction.TransactionCoordinator] (default task-7) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.persistence.CacheLoaderException: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=35 bytes, valueBytes=270 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value={test=1}, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:411)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos; &apos;, -1)&quot;; SQL statement:
> INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:171)
> 	at org.h2.message.DbException.get(DbException.java:148)
> 	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
> 	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
> 	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
> 	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
> 	at org.h2.command.dml.Insert.update(Insert.java:86)
> 	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
> 	at org.h2.command.Command.executeUpdate(Command.java:235)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
> 	... 77 more
> &amp;#27;[0m&amp;#27;[31m08:43:00,028 ERROR [org.infinispan.transaction.tm.DummyTransaction] (default task-7) ISPN000111: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, lockedKeys=null, backupKeyLocks=null, topologyId=2, isFromStateTransfer=false} org.infinispan.transaction.synchronization.SyncLocalTransaction at 13} org.infinispan.transaction.synchronization.SynchronizationAdapter at 32: org.infinispan.commons.CacheException: Could not commit.
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:60) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: javax.transaction.xa.XAException
> 	at org.infinispan.transaction.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:204) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:156) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	... 23 more
> &amp;#27;[0m08:43:00,032 INFO  [org.jboss.as.test.clustering.cluster.ClusterAbstractTestCase] (main) Requested http://127.0.0.1:8080/session-db-cluster/simple, got 1.
> &amp;#27;[31m08:43:00,038 ERROR [org.infinispan.persistence.jdbc.binary.JdbcBinaryStore] (default task-8) ISPN008012: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=29 bytes, valueBytes=27 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value=org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionCacheEntry at 415e75b5, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos;0301fe030200013e18374b4d465247426b6c6c335f6e3542594f305533552d30630369036a1d0301fe3e18374b4d465247426b6c6c335f6e3542594f305533552d3063036a1b0301fe03ff80020000014209636c440000014209636c4500000708036a190301fe0368ffffffffffffffffffffffffffffffff03620001&apos;, -1)&quot;; SQL statement:
> INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:171)
> 	at org.h2.message.DbException.get(DbException.java:148)
> 	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
> 	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
> 	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
> 	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
> 	at org.h2.command.dml.Insert.update(Insert.java:86)
> 	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
> 	at org.h2.command.Command.executeUpdate(Command.java:235)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> &amp;#27;[0m&amp;#27;[31m08:43:00,043 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-8) ISPN000136: Execution error: org.infinispan.persistence.CacheLoaderException: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=29 bytes, valueBytes=27 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value=org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionCacheEntry at 415e75b5, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:411)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos;0301fe030200013e18374b4d465247426b6c6c335f6e3542594f305533552d30630369036a1d0301fe3e18374b4d465247426b6c6c335f6e3542594f305533552d3063036a1b0301fe03ff80020000014209636c440000014209636c4500000708036a190301fe0368ffffffffffffffffffffffffffffffff03620001&apos;, -1)&quot;; SQL statement:
> INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:171)
> 	at org.h2.message.DbException.get(DbException.java:148)
> 	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
> 	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
> 	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
> 	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
> 	at org.h2.command.dml.Insert.update(Insert.java:86)
> 	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
> 	at org.h2.command.Command.executeUpdate(Command.java:235)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
> 	... 77 more
> &amp;#27;[0m&amp;#27;[31m08:43:00,067 ERROR [org.infinispan.transaction.TransactionCoordinator] (default task-8) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.persistence.CacheLoaderException: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=29 bytes, valueBytes=27 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value=org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionCacheEntry at 415e75b5, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:411)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos;0301fe030200013e18374b4d465247426b6c6c335f6e3542594f305533552d30630369036a1d0301fe3e18374b4d465247426b6c6c335f6e3542594f305533552d3063036a1b0301fe03ff80020000014209636c440000014209636c4500000708036a190301fe0368ffffffffffffffffffffffffffffffff03620001&apos;, -1)&quot;; SQL statement:
> INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:171)
> 	at org.h2.message.DbException.get(DbException.java:148)
> 	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
> 	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
> 	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
> 	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
> 	at org.h2.command.dml.Insert.update(Insert.java:86)
> 	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
> 	at org.h2.command.Command.executeUpdate(Command.java:235)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
> 	... 77 more
> &amp;#27;[0m&amp;#27;[31m08:43:00,072 ERROR [org.infinispan.transaction.tm.DummyTransaction] (default task-8) ISPN000111: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, lockedKeys=null, backupKeyLocks=null, topologyId=2, isFromStateTransfer=false} org.infinispan.transaction.synchronization.SyncLocalTransaction at 16} org.infinispan.transaction.synchronization.SynchronizationAdapter at 35: org.infinispan.commons.CacheException: Could not commit.
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:60) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: javax.transaction.xa.XAException
> 	at org.infinispan.transaction.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:204) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:156) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	... 23 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 15:23:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 19 Jan 2018 15:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2184) UX design DRD logic table
	actions
In-Reply-To: <JIRA.12725294.1513357201000@Atlassian.JIRA>
References: <JIRA.12725294.1513357201000@Atlassian.JIRA>
	<JIRA.12725294.1513357201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725294.1513357201000.72743.1516393380247@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2184:
--------------------------------
    Attachment: DMN Editor UX - Logic_ 2184 - Google Docs.pdf


> UX design DRD logic table actions
> ---------------------------------
>
>                 Key: DROOLS-2184
>                 URL: https://issues.jboss.org/browse/DROOLS-2184
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png
>
>
> Use case description:

 As a business user (Citizen Developer?), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.



> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 15:23:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 19 Jan 2018 15:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2184) UX design DRD logic table
	actions
In-Reply-To: <JIRA.12725294.1513357201000@Atlassian.JIRA>
References: <JIRA.12725294.1513357201000@Atlassian.JIRA>
	<JIRA.12725294.1513357201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725294.1513357201000.72747.1516393380342@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2184:
--------------------------------
    Attachment: Screen Shot 2018-01-19 at 3.22.25 PM.png


> UX design DRD logic table actions
> ---------------------------------
>
>                 Key: DROOLS-2184
>                 URL: https://issues.jboss.org/browse/DROOLS-2184
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png
>
>
> Use case description:

 As a business user (Citizen Developer?), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.



> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 15:23:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 19 Jan 2018 15:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2184) UX design DRD logic table
	actions
In-Reply-To: <JIRA.12725294.1513357201000@Atlassian.JIRA>
References: <JIRA.12725294.1513357201000@Atlassian.JIRA>
	<JIRA.12725294.1513357201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725294.1513357201000.72750.1516393380419@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2184:
--------------------------------
    Attachment: Screen Shot 2018-01-19 at 3.22.15 PM.png


> UX design DRD logic table actions
> ---------------------------------
>
>                 Key: DROOLS-2184
>                 URL: https://issues.jboss.org/browse/DROOLS-2184
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png
>
>
> Use case description:

 As a business user (Citizen Developer?), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.



> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 15:24:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 19 Jan 2018 15:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2184) UX design DRD logic table
	actions
In-Reply-To: <JIRA.12725294.1513357201000@Atlassian.JIRA>
References: <JIRA.12725294.1513357201000@Atlassian.JIRA>
	<JIRA.12725294.1513357201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725294.1513357201000.72753.1516393440144@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2184:
--------------------------------
    Attachment: Screen Shot 2018-01-19 at 3.23.31 PM.png


> UX design DRD logic table actions
> ---------------------------------
>
>                 Key: DROOLS-2184
>                 URL: https://issues.jboss.org/browse/DROOLS-2184
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png, Screen Shot 2018-01-19 at 3.23.31 PM.png
>
>
> Use case description:

 As a business user (Citizen Developer?), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.



> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 15:27:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 19 Jan 2018 15:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2184) UX design DRD logic table
	actions
In-Reply-To: <JIRA.12725294.1513357201000@Atlassian.JIRA>
References: <JIRA.12725294.1513357201000@Atlassian.JIRA>
	<JIRA.12725294.1513357201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725294.1513357201000.72792.1516393620197@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521615#comment-13521615 ] 

Liz Clayton commented on DROOLS-2184:
-------------------------------------

[~manstis] [~tirelli] I posted design logic design proposals here, and plan to mark this jira as resolved. 

> UX design DRD logic table actions
> ---------------------------------
>
>                 Key: DROOLS-2184
>                 URL: https://issues.jboss.org/browse/DROOLS-2184
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png, Screen Shot 2018-01-19 at 3.23.31 PM.png
>
>
> Use case description:

 As a business user (Citizen Developer?), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.



> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 15:30:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 19 Jan 2018 15:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2184) UX design DRD logic table
	actions
In-Reply-To: <JIRA.12725294.1513357201000@Atlassian.JIRA>
References: <JIRA.12725294.1513357201000@Atlassian.JIRA>
	<JIRA.12725294.1513357201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725294.1513357201000.72800.1516393800113@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521616#comment-13521616 ] 

Liz Clayton commented on DROOLS-2184:
-------------------------------------

Google doc is posted at: https://drive.google.com/open?id=1DkM_we3l5hOHP5zEaJYogwzsyQ4G4wPFCoe3yeKbpiQ

> UX design DRD logic table actions
> ---------------------------------
>
>                 Key: DROOLS-2184
>                 URL: https://issues.jboss.org/browse/DROOLS-2184
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png, Screen Shot 2018-01-19 at 3.23.31 PM.png
>
>
> Use case description:

 As a business user (Citizen Developer?), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.



> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 15:31:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 19 Jan 2018 15:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2154) Design navigation between
 the DRG and DRD's
In-Reply-To: <JIRA.12722654.1511888546000@Atlassian.JIRA>
References: <JIRA.12722654.1511888546000@Atlassian.JIRA>
	<JIRA.12722654.1511888546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722654.1511888546000.72804.1516393860130@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13510121#comment-13510121 ] 

Liz Clayton edited comment on DROOLS-2154 at 1/19/18 3:30 PM:
--------------------------------------------------------------

Designs documented at: https://drive.google.com/open?id=14pnw6QUTj5BsUJyz4uP_ozLLkYBvCYGXd1VIaK6jFHQ


was (Author: uxdlc):
Designs documented at: https://docs.google.com/document/d/14pnw6QUTj5BsUJyz4uP_ozLLkYBvCYGXd1VIaK6jFHQ/edit?ts=5a4feb47

> Design navigation between the DRG and DRD's
> -------------------------------------------
>
>                 Key: DROOLS-2154
>                 URL: https://issues.jboss.org/browse/DROOLS-2154
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: Screen Shot 2018-01-05 at 2.26.30 PM.png, Screen Shot 2018-01-05 at 2.56.09 PM.png, Screen Shot 2018-01-05 at 3.12.08 PM.png
>
>
> *Use case description:
*
> As a business user (Citizen Developer?), I want to navigate between the DRG and the DRDs, and the content of each node, to model business decision logic.
> *Requirements:*
> * Diagram modeling must be absolutely consistent with Process Modeler: Process Designer and DMN editors should provide the same features, support the same interactions and appear visually similar in all aspects to one and other at "Level 1". Divergence may exist at "Level 2".
> *Verification Conditions*
> * The user of this feature is able to understand that the the DRDs are subsets of the whole DRG model/file.
> * The user of this feature can seamlessly navigate between the diagrams and the content of the nodes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 15:33:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 19 Jan 2018 15:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2154) Design navigation between
 the DRG and DRD's
In-Reply-To: <JIRA.12722654.1511888546000@Atlassian.JIRA>
References: <JIRA.12722654.1511888546000@Atlassian.JIRA>
	<JIRA.12722654.1511888546000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722654.1511888546000.72808.1516393980146@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2154?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton updated DROOLS-2154:
--------------------------------
    Attachment: DMN Editor UX_ 2154 - Google Docs.pdf


> Design navigation between the DRG and DRD's
> -------------------------------------------
>
>                 Key: DROOLS-2154
>                 URL: https://issues.jboss.org/browse/DROOLS-2154
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: DMN Editor UX_ 2154 - Google Docs.pdf, Screen Shot 2018-01-05 at 2.26.30 PM.png, Screen Shot 2018-01-05 at 2.56.09 PM.png, Screen Shot 2018-01-05 at 3.12.08 PM.png
>
>
> *Use case description:
*
> As a business user (Citizen Developer?), I want to navigate between the DRG and the DRDs, and the content of each node, to model business decision logic.
> *Requirements:*
> * Diagram modeling must be absolutely consistent with Process Modeler: Process Designer and DMN editors should provide the same features, support the same interactions and appear visually similar in all aspects to one and other at "Level 1". Divergence may exist at "Level 2".
> *Verification Conditions*
> * The user of this feature is able to understand that the the DRDs are subsets of the whole DRG model/file.
> * The user of this feature can seamlessly navigate between the diagrams and the content of the nodes.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 15:34:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 19 Jan 2018 15:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2184) UX design DRD logic table
	actions
In-Reply-To: <JIRA.12725294.1513357201000@Atlassian.JIRA>
References: <JIRA.12725294.1513357201000@Atlassian.JIRA>
	<JIRA.12725294.1513357201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725294.1513357201000.72811.1516394040237@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521617#comment-13521617 ] 

Liz Clayton commented on DROOLS-2184:
-------------------------------------

[~mstevens1] fyi ^^

> UX design DRD logic table actions
> ---------------------------------
>
>                 Key: DROOLS-2184
>                 URL: https://issues.jboss.org/browse/DROOLS-2184
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png, Screen Shot 2018-01-19 at 3.23.31 PM.png
>
>
> Use case description:

 As a business user (Citizen Developer?), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.



> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 15:34:00 2018
From: issues at jboss.org (Liz Clayton (JIRA))
Date: Fri, 19 Jan 2018 15:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2184) UX design DRD logic table
	actions
In-Reply-To: <JIRA.12725294.1513357201000@Atlassian.JIRA>
References: <JIRA.12725294.1513357201000@Atlassian.JIRA>
	<JIRA.12725294.1513357201000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725294.1513357201000.72814.1516394040351@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2184?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Liz Clayton resolved DROOLS-2184.
---------------------------------
    Resolution: Done


> UX design DRD logic table actions
> ---------------------------------
>
>                 Key: DROOLS-2184
>                 URL: https://issues.jboss.org/browse/DROOLS-2184
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Liz Clayton
>            Assignee: Liz Clayton
>              Labels: UX, UXTeam
>         Attachments: DMN Editor UX - Logic_ 2184 - Google Docs.pdf, Screen Shot 2018-01-19 at 3.22.15 PM.png, Screen Shot 2018-01-19 at 3.22.25 PM.png, Screen Shot 2018-01-19 at 3.23.31 PM.png
>
>
> Use case description:

 As a business user (Citizen Developer?), I want to easily create, edit, and refine business decision logic (tables, expressions, boxed expression, etc.) Note: Using inline controls and employ autocomplete capabilities where possible.



> Verification Conditions
> * The user of this feature is able to easily/quickly perform key actions (Add, Remove, Edit) in logic tables, boxed expressions, and the like. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 19 15:37:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 19 Jan 2018 15:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2256) [DMN Designer] Scrollbars
 in full screen mode
In-Reply-To: <JIRA.12729965.1516372302000@Atlassian.JIRA>
References: <JIRA.12729965.1516372302000@Atlassian.JIRA>
	<JIRA.12729965.1516372302000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729965.1516372302000.72832.1516394220149@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521619#comment-13521619 ] 

Michael Anstis commented on DROOLS-2256:
----------------------------------------

The issue is caused by [this|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-stunner/kie-wb-common-stunner-client/kie-wb-common-stunner-widgets/src/main/java/org/kie/workbench/common/stunner/client/widgets/presenters/session/impl/SessionEditorPresenter.java#L75]. When the panel is maximised or minimised an event is raised and the observer forces the Palette to become visible. The "grid" editor of the DMN Editor hides the Palette as it is not needed however the described mechanism is re-showing it.

See https://github.com/kiegroup/kie-wb-common/pull/1119

> [DMN Designer] Scrollbars in full screen mode 
> ----------------------------------------------
>
>                 Key: DROOLS-2256
>                 URL: https://issues.jboss.org/browse/DROOLS-2256
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>            Priority: Minor
>              Labels: Stunner
>         Attachments: Screenshot from 2018-01-19 13-39-20.png, Screenshot from 2018-01-19 13-39-52.png
>
>
> The scroll bars doesn't work in some cases during full screen mode is in action.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 16:45:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Fri, 19 Jan 2018 16:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2256) [DMN Designer] Scrollbars
 in full screen mode
In-Reply-To: <JIRA.12729965.1516372302000@Atlassian.JIRA>
References: <JIRA.12729965.1516372302000@Atlassian.JIRA>
	<JIRA.12729965.1516372302000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729965.1516372302000.72966.1516398300126@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2256?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2256:
-----------------------------------
    Sprint: 2018 Week 03-04


> [DMN Designer] Scrollbars in full screen mode 
> ----------------------------------------------
>
>                 Key: DROOLS-2256
>                 URL: https://issues.jboss.org/browse/DROOLS-2256
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>            Priority: Minor
>              Labels: Stunner
>         Attachments: Screenshot from 2018-01-19 13-39-20.png, Screenshot from 2018-01-19 13-39-52.png
>
>
> The scroll bars doesn't work in some cases during full screen mode is in action.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 17:04:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 19 Jan 2018 17:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3530) Remove unnecessary Element
 and Attribute class from deployment scanner
In-Reply-To: <JIRA.12730004.1516399425000@Atlassian.JIRA>
References: <JIRA.12730004.1516399425000@Atlassian.JIRA>
	<JIRA.12730004.1516399425939@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730004.1516399425000.72991.1516399440055@Atlassian.JIRA>

Stuart Douglas created WFCORE-3530:
--------------------------------------

             Summary: Remove unnecessary Element and Attribute class from deployment scanner
                 Key: WFCORE-3530
                 URL: https://issues.jboss.org/browse/WFCORE-3530
             Project: WildFly Core
          Issue Type: Task
            Reporter: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 17:05:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 19 Jan 2018 17:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3530) Remove unnecessary Element
 and Attribute class from deployment scanner
In-Reply-To: <JIRA.12730004.1516399426000@Atlassian.JIRA>
References: <JIRA.12730004.1516399426000@Atlassian.JIRA>
	<JIRA.12730004.1516399426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730004.1516399426000.72993.1516399500213@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reassigned WFCORE-3530:
--------------------------------------

    Assignee: Stuart Douglas


> Remove unnecessary Element and Attribute class from deployment scanner
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-3530
>                 URL: https://issues.jboss.org/browse/WFCORE-3530
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 17:05:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Fri, 19 Jan 2018 17:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3530) Remove unnecessary Element
 and Attribute class from deployment scanner
In-Reply-To: <JIRA.12730004.1516399426000@Atlassian.JIRA>
References: <JIRA.12730004.1516399426000@Atlassian.JIRA>
	<JIRA.12730004.1516399426000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730004.1516399426000.72997.1516399500320@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3530?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFCORE-3530:
-----------------------------------
    Component/s: Deployment Scanner


> Remove unnecessary Element and Attribute class from deployment scanner
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-3530
>                 URL: https://issues.jboss.org/browse/WFCORE-3530
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Deployment Scanner
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 17:09:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 19 Jan 2018 17:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-189) Allow the instances to be
 exposed from the configuration API
In-Reply-To: <JIRA.12730005.1516399688000@Atlassian.JIRA>
References: <JIRA.12730005.1516399688000@Atlassian.JIRA>
	<JIRA.12730005.1516399688545@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730005.1516399688000.73009.1516399740231@Atlassian.JIRA>

James Perkins created LOGMGR-189:
------------------------------------

             Summary: Allow the instances to be exposed from the configuration API
                 Key: LOGMGR-189
                 URL: https://issues.jboss.org/browse/LOGMGR-189
             Project: JBoss Log Manager
          Issue Type: Feature Request
            Reporter: James Perkins
            Assignee: James Perkins


The configuration API should return the instance created via the API. This will allow LOGMGR-188 to be reverted and simplify how the persisted configuration will be written.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 17:09:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 19 Jan 2018 17:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-188) Allow the configuration API
 to not persist properties when writing a configuration file
In-Reply-To: <JIRA.12729826.1516311403000@Atlassian.JIRA>
References: <JIRA.12729826.1516311403000@Atlassian.JIRA>
	<JIRA.12729826.1516311403000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729826.1516311403000.73011.1516399740425@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-188?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reopened LOGMGR-188:
----------------------------------


This commit is going to be reverted. See LOGMGR-189 for details.

> Allow the configuration API to not persist properties when writing a configuration file
> ---------------------------------------------------------------------------------------
>
>                 Key: LOGMGR-188
>                 URL: https://issues.jboss.org/browse/LOGMGR-188
>             Project: JBoss Log Manager
>          Issue Type: Feature Request
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 2.1.0.Alpha6
>
>
> With the introduction of the [{{DelayedHandler}}|LOGMGR-177] it may be desirable for configurations not to persist some data to the {{logging.properties}} configuration file. This should include all generic properties plus child handler names. The level, filter, encoding, formatter and error manager will always be persisted.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 17:19:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 19 Jan 2018 17:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-189) Allow the instances to be
 exposed from the configuration API
In-Reply-To: <JIRA.12730005.1516399689000@Atlassian.JIRA>
References: <JIRA.12730005.1516399689000@Atlassian.JIRA>
	<JIRA.12730005.1516399689000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730005.1516399689000.73013.1516400340104@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-189?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-189:
---------------------------------
    Description: 
The configuration API should return the instance created via the API. This will allow LOGMGR-188 to be reverted and simplify how the persisted configuration will be written. Changes to the object instance will not be reflected in the configuration API. This is however the desired behavior for properties that should not be written to the configuration file.

An example use case of this will be for WildFly. A {{SocketHandler}} may be created based on an {{SSLContext}} configured in Elytron. This handler can be created without the configuration API and the handler will be set on a {{DelayedHandler}} instance that will be created via the configuration API.

  was:The configuration API should return the instance created via the API. This will allow LOGMGR-188 to be reverted and simplify how the persisted configuration will be written.



> Allow the instances to be exposed from the configuration API
> ------------------------------------------------------------
>
>                 Key: LOGMGR-189
>                 URL: https://issues.jboss.org/browse/LOGMGR-189
>             Project: JBoss Log Manager
>          Issue Type: Feature Request
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> The configuration API should return the instance created via the API. This will allow LOGMGR-188 to be reverted and simplify how the persisted configuration will be written. Changes to the object instance will not be reflected in the configuration API. This is however the desired behavior for properties that should not be written to the configuration file.
> An example use case of this will be for WildFly. A {{SocketHandler}} may be created based on an {{SSLContext}} configured in Elytron. This handler can be created without the configuration API and the handler will be set on a {{DelayedHandler}} instance that will be created via the configuration API.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 17:24:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 19 Jan 2018 17:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-151) SyslogHandler should allow
 to set custom SSLSocketFactory
In-Reply-To: <JIRA.12687238.1491916523000@Atlassian.JIRA>
References: <JIRA.12687238.1491916523000@Atlassian.JIRA>
	<JIRA.12687238.1491916523000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12687238.1491916523000.73020.1516400640094@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-151?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins reassigned LOGMGR-151:
------------------------------------

    Assignee: James Perkins


> SyslogHandler should allow to set custom SSLSocketFactory
> ---------------------------------------------------------
>
>                 Key: LOGMGR-151
>                 URL: https://issues.jboss.org/browse/LOGMGR-151
>             Project: JBoss Log Manager
>          Issue Type: Enhancement
>    Affects Versions: 2.0.5.Final
>            Reporter: Jan Kalina
>            Assignee: James Perkins
>
> As part of Wildfly Elytron integration would be useful to allow to put custom *SSLSocketFactory* into *SyslogHandler*.
> It would allow to use *ssl-context* defined in elytron (with custom configuration of CAs, truststore, keystore) for syslog over TLS.
> (SyslogHandler is used for syslog audit logging in Elytron too - and currently no way to put elytron ssl-context into)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 17:25:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 19 Jan 2018 17:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-190) The SocketFactory should be
 allowed to be set on the SocketHandler
In-Reply-To: <JIRA.12730006.1516400695000@Atlassian.JIRA>
References: <JIRA.12730006.1516400695000@Atlassian.JIRA>
	<JIRA.12730006.1516400695917@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730006.1516400695000.73023.1516400700141@Atlassian.JIRA>

James Perkins created LOGMGR-190:
------------------------------------

             Summary: The SocketFactory should be allowed to be set on the SocketHandler
                 Key: LOGMGR-190
                 URL: https://issues.jboss.org/browse/LOGMGR-190
             Project: JBoss Log Manager
          Issue Type: Enhancement
            Reporter: James Perkins
            Assignee: James Perkins


The {{SocketHandler}} should allow for the {{SocketFactory}} to be set. This will be useful in WildFly where a {{SocketFactory}} may be a capability of another subsystem.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 17:29:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 19 Jan 2018 17:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-190) The SocketFactory should be
 allowed to be set on the SocketHandler
In-Reply-To: <JIRA.12730006.1516400696000@Atlassian.JIRA>
References: <JIRA.12730006.1516400696000@Atlassian.JIRA>
	<JIRA.12730006.1516400696000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730006.1516400696000.73025.1516400940120@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-190?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-190:
---------------------------------
    Fix Version/s: 2.1.0.Alpha6


> The SocketFactory should be allowed to be set on the SocketHandler
> ------------------------------------------------------------------
>
>                 Key: LOGMGR-190
>                 URL: https://issues.jboss.org/browse/LOGMGR-190
>             Project: JBoss Log Manager
>          Issue Type: Enhancement
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 2.1.0.Alpha6
>
>
> The {{SocketHandler}} should allow for the {{SocketFactory}} to be set. This will be useful in WildFly where a {{SocketFactory}} may be a capability of another subsystem.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 17:35:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 19 Jan 2018 17:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGMGR-82)
 PeriodicSizeRotatingFileHandlerTests rotation tests are a bit dodgy
In-Reply-To: <JIRA.12499410.1377550045000@Atlassian.JIRA>
References: <JIRA.12499410.1377550045000@Atlassian.JIRA>
	<JIRA.12499410.1377550045000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12499410.1377550045000.73033.1516401300088@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/LOGMGR-82?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated LOGMGR-82:
--------------------------------
    Fix Version/s:     (was: 2.1.0.Alpha6)


> PeriodicSizeRotatingFileHandlerTests rotation tests are a bit dodgy 
> --------------------------------------------------------------------
>
>                 Key: LOGMGR-82
>                 URL: https://issues.jboss.org/browse/LOGMGR-82
>             Project: JBoss Log Manager
>          Issue Type: Bug
>            Reporter: James Perkins
>            Assignee: James Perkins
>
> The rotation tests seem to fail at random days and times. The test {{testPeriodicAndSizeRotate}} needs to be looked at before re-enabling it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:02 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3527) Remove OSGi obsolete code
In-Reply-To: <JIRA.12729983.1516378481000@Atlassian.JIRA>
References: <JIRA.12729983.1516378481000@Atlassian.JIRA>
	<JIRA.12729983.1516378481000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729983.1516378481000.73096.1516410482732@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3527:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Remove OSGi obsolete code
> -------------------------
>
>                 Key: WFCORE-3527
>                 URL: https://issues.jboss.org/browse/WFCORE-3527
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Server
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Alpha7
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:02 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3519) Add JASPI Module
In-Reply-To: <JIRA.12729731.1516279301000@Atlassian.JIRA>
References: <JIRA.12729731.1516279301000@Atlassian.JIRA>
	<JIRA.12729731.1516279301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729731.1516279301000.73103.1516410482951@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3519:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Add JASPI Module
> ----------------
>
>                 Key: WFCORE-3519
>                 URL: https://issues.jboss.org/browse/WFCORE-3519
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha7
>
>
> (Copy from WildFly)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3457) Reduce class loading of
 Elytron subsystem
In-Reply-To: <JIRA.12724639.1513168462000@Atlassian.JIRA>
References: <JIRA.12724639.1513168462000@Atlassian.JIRA>
	<JIRA.12724639.1513168462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724639.1513168462000.73110.1516410483214@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3457:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Reduce class loading of Elytron subsystem
> -----------------------------------------
>
>                 Key: WFCORE-3457
>                 URL: https://issues.jboss.org/browse/WFCORE-3457
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha7
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3424) Replace MSC listeners with
 stability monitors
In-Reply-To: <JIRA.12721337.1510844543000@Atlassian.JIRA>
References: <JIRA.12721337.1510844543000@Atlassian.JIRA>
	<JIRA.12721337.1510844543000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721337.1510844543000.73113.1516410483274@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3424:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Replace MSC listeners with stability monitors
> ---------------------------------------------
>
>                 Key: WFCORE-3424
>                 URL: https://issues.jboss.org/browse/WFCORE-3424
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Server
>    Affects Versions: 4.0.0.Alpha2
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Alpha7
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3397) Integrate improved thread
 pool implementation
In-Reply-To: <JIRA.12718985.1509548610000@Atlassian.JIRA>
References: <JIRA.12718985.1509548610000@Atlassian.JIRA>
	<JIRA.12718985.1509548610000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718985.1509548610000.73118.1516410483377@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3397?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3397:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Integrate improved thread pool implementation
> ---------------------------------------------
>
>                 Key: WFCORE-3397
>                 URL: https://issues.jboss.org/browse/WFCORE-3397
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI, Domain Management, IO, Server, Test Suite
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>             Fix For: 4.0.0.Alpha7
>
>
> Introduce new thread pool implementation with separate core/max size and configurable parameters, and reuse-idle-thread behavior.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3386) Add configuration required
 to support JASPIC to the Elytron subsystem
In-Reply-To: <JIRA.12718363.1509034738000@Atlassian.JIRA>
References: <JIRA.12718363.1509034738000@Atlassian.JIRA>
	<JIRA.12718363.1509034738000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718363.1509034738000.73125.1516410483563@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3386:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Add configuration required to support JASPIC to the Elytron subsystem
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-3386
>                 URL: https://issues.jboss.org/browse/WFCORE-3386
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha7
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3382) Further Enhance Elytron
 Permission Configuration
In-Reply-To: <JIRA.12718138.1508950408000@Atlassian.JIRA>
References: <JIRA.12718138.1508950408000@Atlassian.JIRA>
	<JIRA.12718138.1508950408000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718138.1508950408000.73133.1516410483801@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3382:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Further Enhance Elytron Permission Configuration
> ------------------------------------------------
>
>                 Key: WFCORE-3382
>                 URL: https://issues.jboss.org/browse/WFCORE-3382
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Alpha7
>
>
> This has currently been simplified to a single resource for the out of the box configuration, however this brings issues as now permissions are duplicated so modifications need to be replicated instead of to a single location.
> Finding a way for the default required permissions to be defined in one location could help eliminate the duplication.
> We could also consider going one step further and subsystems register the default permissions that should be granted.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3360) Eliminate
 org.wildfly.extension.elytron.ProviderUtil
In-Reply-To: <JIRA.12716717.1508231768000@Atlassian.JIRA>
References: <JIRA.12716717.1508231768000@Atlassian.JIRA>
	<JIRA.12716717.1508231768000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12716717.1508231768000.73140.1516410483972@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3360:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Eliminate org.wildfly.extension.elytron.ProviderUtil
> ----------------------------------------------------
>
>                 Key: WFCORE-3360
>                 URL: https://issues.jboss.org/browse/WFCORE-3360
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha7
>
>
> WildFly Elytron contains a public utility class org.wildfly.security.util.ProviderUtil for the same purpose, we should use the code within WildFly Elytron and not custom code within the subsystem.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3255) Complex type
 AttributeDefinition variants don't handle ParameterCorrector properly
In-Reply-To: <JIRA.12710526.1504748362000@Atlassian.JIRA>
References: <JIRA.12710526.1504748362000@Atlassian.JIRA>
	<JIRA.12710526.1504748362000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12710526.1504748362000.73142.1516410484008@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3255:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Complex type AttributeDefinition variants don't handle ParameterCorrector properly
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-3255
>                 URL: https://issues.jboss.org/browse/WFCORE-3255
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.1.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 4.0.0.Alpha7
>
>
> If a field in a complex attribute (i.e. one that uses Object...AttributeDefinition) has a ParameterCorrector configured, that corrector never gets called. That's because only a corrector on the top level attribute gets called.
> These classes should automatically use an internal corrector that first calls any corrector configured for fields, and then, if one is present, calls any top level corrector.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3181) Review
 CustomCredentialSecurityFactoryTestCase
In-Reply-To: <JIRA.12707010.1502379745000@Atlassian.JIRA>
References: <JIRA.12707010.1502379745000@Atlassian.JIRA>
	<JIRA.12707010.1502379745000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12707010.1502379745000.73149.1516410484162@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3181:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Review CustomCredentialSecurityFactoryTestCase
> ----------------------------------------------
>
>                 Key: WFCORE-3181
>                 URL: https://issues.jboss.org/browse/WFCORE-3181
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security, Test Suite
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Alpha7
>
>
> The test case CustomCredentialSecurityFactoryTestCase appears to be testing that the 'code does what it does' rather than testing the 'code is doing what it should'.
> The test is testing a custom credential security factory can be called but the test is using HTTP Basic authentication and relying on SPNEGO authentication being triggered as this is the only mechanism that currently uses this factory.
> Should a minor change be required to the SPNEGO authentication mechanism which affects when this credential factory is called this test case could subsequently fail.
> If possible it would be better to convert this test to be a SPNEGO test and then test the behaviour of the credential security factory affects the mechanism as expected.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3167) option to filter out aged
 out patches from the patching history
In-Reply-To: <JIRA.12706634.1502219553000@Atlassian.JIRA>
References: <JIRA.12706634.1502219553000@Atlassian.JIRA>
	<JIRA.12706634.1502219553000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12706634.1502219553000.73154.1516410484306@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3167:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> option to filter out aged out patches from the patching history
> ---------------------------------------------------------------
>
>                 Key: WFCORE-3167
>                 URL: https://issues.jboss.org/browse/WFCORE-3167
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI, Patching 
>    Affects Versions: 3.0.0.Beta30
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 4.0.0.Alpha7
>
>
> show-history management operation (and patch history cli command) returns all the patches that have been applied to the installation even if some of them have been aged out by executing ageout-history management operation.
> In some cases it would be useful to filter out the aged out patches from the result, leaving only the patches that can actually be rolled back by a user.
> That could be achieved by adding an optional boolean parameter exclude-agedout (with default value false to preserve the current behavior) to show-history operation.
> The high level CLI command patch history could include an equivalent --exclude-agedout argument.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3107) Allow slave hosts to ignore
 missing RBAC config resources
In-Reply-To: <JIRA.12704736.1501032152000@Atlassian.JIRA>
References: <JIRA.12704736.1501032152000@Atlassian.JIRA>
	<JIRA.12704736.1501032152000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12704736.1501032152000.73156.1516410484350@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3107:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Allow slave hosts to ignore missing RBAC config resources
> ---------------------------------------------------------
>
>                 Key: WFCORE-3107
>                 URL: https://issues.jboss.org/browse/WFCORE-3107
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 4.0.0.Alpha7
>
>
> Part of parent issue whereby slaves can ignore missing RBAC constraint resources for write requests coming from the DC.
> If the DC sent the request, then the address is ok overall. So if it's missing on the slave that means the slave doesn't have that constraint registered and doesn't need to handle the op.
> This fix could possibly be backported to the 2.1.x and to EAP 6.4.x in lieu of adding transformers as part of the parent issue. In the case of 2.1.x it also allows slaves to ignore the related extension even if the code for it is present (which is only a minor benefit.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3073) Handle Shutdown via TERM
	gracefully
In-Reply-To: <JIRA.12700921.1499443726000@Atlassian.JIRA>
References: <JIRA.12700921.1499443726000@Atlassian.JIRA>
	<JIRA.12700921.1499443726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12700921.1499443726000.73166.1516410484565@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3073:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Handle Shutdown via TERM gracefully
> -----------------------------------
>
>                 Key: WFCORE-3073
>                 URL: https://issues.jboss.org/browse/WFCORE-3073
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Ben Parees
>            Assignee: Brian Stansberry
>             Fix For: 4.0.0.Alpha7
>
>
> The wildfly server currently -terminates immediately- performs a standard (non-graceful) shutdown in response to a TERM signal.  To achieve a -clean- graceful shutdown requires invoking the CLI tooling.  This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved. 
> While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
> Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3019) The bin/product.conf and
 the org.jboss.as.product:wildfly-core module should come in via an FP
In-Reply-To: <JIRA.12699548.1498596551000@Atlassian.JIRA>
References: <JIRA.12699548.1498596551000@Atlassian.JIRA>
	<JIRA.12699548.1498596551000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12699548.1498596551000.73169.1516410484629@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3019:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3019
>                 URL: https://issues.jboss.org/browse/WFCORE-3019
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Server
>            Reporter: Brian Stansberry
>            Assignee: James Perkins
>             Fix For: 4.0.0.Alpha7
>
>
> For WFLY-4692 we moved the "product" stuff out of core-feature-pack and into dist. But this means it doesn't end up in the skinny dist produced by the "build" module. Plus it makes the "dist" a kind of FP of its own.
> The stuff in dist/src/distribution should be its own FP. That one *perhaps* depends on core-feature-pack. Then build and dist use the new FP in addition to or instead of core-feature-pack.
> So, core-feature-pack is independently usable, in other dists, but our offiical build/dist, which has our official product module, picks up the new FP.
> Whether the new "product" FP depends on core-feature-pack depends on how we want to use it; i.e. can this bin/product.conf and module be used in some other flavor of dist.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2746) Move elytron management
 security tests from full to core
In-Reply-To: <JIRA.12690293.1493753754000@Atlassian.JIRA>
References: <JIRA.12690293.1493753754000@Atlassian.JIRA>
	<JIRA.12690293.1493753754000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12690293.1493753754000.73177.1516410484847@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2746:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Move elytron management security tests from full to core
> --------------------------------------------------------
>
>                 Key: WFCORE-2746
>                 URL: https://issues.jboss.org/browse/WFCORE-2746
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security, Test Suite
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Alpha7
>
>
> Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
> Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723
> There are a number of aspects to this, for which I'll create subtasks.
> Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
> -org.jboss.as.test.integration.security.perimeter.* [2]-
> -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase-
> -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
> -org.jboss.as.test.integration.security.credentialreference [2]-
> integration/elytron/
> [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
> [2] Currently using Arquillian.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2589) Eliminate MSC OPTIONAL
 dependencies usage
In-Reply-To: <JIRA.12684776.1490708029000@Atlassian.JIRA>
References: <JIRA.12684776.1490708029000@Atlassian.JIRA>
	<JIRA.12684776.1490708029000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12684776.1490708029000.73180.1516410484907@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2589:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Eliminate MSC OPTIONAL dependencies usage
> -----------------------------------------
>
>                 Key: WFCORE-2589
>                 URL: https://issues.jboss.org/browse/WFCORE-2589
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Alpha7
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2497) Convert
 *-authentication-factory resources to be child resources of security-domain
In-Reply-To: <JIRA.12678139.1487691523000@Atlassian.JIRA>
References: <JIRA.12678139.1487691523000@Atlassian.JIRA>
	<JIRA.12678139.1487691523000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678139.1487691523000.73188.1516410485122@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2497:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Convert *-authentication-factory resources to be child resources of security-domain
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-2497
>                 URL: https://issues.jboss.org/browse/WFCORE-2497
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Alpha7
>
>
> This is a good example of where child resources work.
> The authentication factory resources have a mandatory dependency on a single security domain.
> The configuration within the factory is related to it's security domain.
> There is only a single resource that can provide security domains.
> The behaviour of the parent is unaffected by the existence or configuration of the child.
> The parent and child manage their own services independently with the child's service depending on the parent's service.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2365) Review
 custom-modifiable-realm resource in Elytron subsystem
In-Reply-To: <JIRA.12651212.1474463004000@Atlassian.JIRA>
References: <JIRA.12651212.1474463004000@Atlassian.JIRA>
	<JIRA.12651212.1474463004000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651212.1474463004000.73194.1516410485245@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2365:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Review custom-modifiable-realm resource in Elytron subsystem
> ------------------------------------------------------------
>
>                 Key: WFCORE-2365
>                 URL: https://issues.jboss.org/browse/WFCORE-2365
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>             Fix For: 4.0.0.Alpha7
>
>
> See description of JBEAP-6100 for more details.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2349) Add
 RemoteManagementPermission and RemoteJMXPermission checks for remote
 clients.
In-Reply-To: <JIRA.12679810.1488466192000@Atlassian.JIRA>
References: <JIRA.12679810.1488466192000@Atlassian.JIRA>
	<JIRA.12679810.1488466192000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679810.1488466192000.73201.1516410485385@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2349:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients.
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-2349
>                 URL: https://issues.jboss.org/browse/WFCORE-2349
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Alpha7
>
>
> Other services such as EJB and transactions have a Remote*Permission to verify the remote client has the required permission to use that service - this should be repeated for the management related services to control what a remote client can and can not connect to.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2336) Remove
	ModelController.createClient
In-Reply-To: <JIRA.12679023.1488205057000@Atlassian.JIRA>
References: <JIRA.12679023.1488205057000@Atlassian.JIRA>
	<JIRA.12679023.1488205057000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679023.1488205057000.73203.1516410485419@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2336:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Remove ModelController.createClient
> -----------------------------------
>
>                 Key: WFCORE-2336
>                 URL: https://issues.jboss.org/browse/WFCORE-2336
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Alpha7
>
>
> Follow up on WFCORE-1507 by removing ModelController.createClient and any use of it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1960) Get rid of attributes of
 type LIST of PROPERTY; use OBJECT of STRING
In-Reply-To: <JIRA.12660236.1478622756000@Atlassian.JIRA>
References: <JIRA.12660236.1478622756000@Atlassian.JIRA>
	<JIRA.12660236.1478622756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660236.1478622756000.73206.1516410485550@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1960:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING
> --------------------------------------------------------------------
>
>                 Key: WFCORE-1960
>                 URL: https://issues.jboss.org/browse/WFCORE-1960
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Ken Wills
>             Fix For: 4.0.0.Alpha7
>
>         Attachments: rrd.txt
>
>
> A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap<String, String>, with ordering based on insertion. So such a description is fine for a path address attribute. 
> I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model) so removing the only usage of it will help.
> We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1944) Convert domain-management
 tests to reference Elytron SecurityRealm and remove old CallbackHandler
 code.
In-Reply-To: <JIRA.12659650.1478461931000@Atlassian.JIRA>
References: <JIRA.12659650.1478461931000@Atlassian.JIRA>
	<JIRA.12659650.1478461931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659650.1478461931000.73213.1516410485699@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1944:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1944
>                 URL: https://issues.jboss.org/browse/WFCORE-1944
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Alpha7
>
>
> The important pieces of code within the legacy security realms are being wrapped using Elytron components, items like the legacy CallbackHandlers can be removed but existing tests need porting to call Elytron APIs.
> The legacy tests do need to be retained as they offer a good level of regression testing for the legacy realms.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1649) RBAC constraint config
 modifications will fail in a mixed domain if the modified constraint is not
 present in the legacy slave
In-Reply-To: <JIRA.12638588.1468361977000@Atlassian.JIRA>
References: <JIRA.12638588.1468361977000@Atlassian.JIRA>
	<JIRA.12638588.1468361977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638588.1468361977000.73217.1516410485821@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1649:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1649
>                 URL: https://issues.jboss.org/browse/WFCORE-1649
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>              Labels: domain-mode
>             Fix For: 4.0.0.Alpha7
>
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1489) Expose
 (un)registerNotificationHandler() on OperationContext
In-Reply-To: <JIRA.12616058.1461163906000@Atlassian.JIRA>
References: <JIRA.12616058.1461163906000@Atlassian.JIRA>
	<JIRA.12616058.1461163906000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616058.1461163906000.73221.1516410485908@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1489:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> Expose (un)registerNotificationHandler() on OperationContext
> ------------------------------------------------------------
>
>                 Key: WFCORE-1489
>                 URL: https://issues.jboss.org/browse/WFCORE-1489
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Jeff Mesnil
>             Fix For: 4.0.0.Alpha7
>
>
> Currently the only way to (un)register notifications is via the NotificationHandlerRegistration exposed by ModelController.getNotificationRegistry(). It would be nice to not have to install a service whose only purpose is to get hold of the ModelController from OSH's.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 19 20:08:06 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 19 Jan 2018 20:08:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1307) jboss-cli returns success
 when WFLYCTL0009: Failed to store configuration occurred
In-Reply-To: <JIRA.12599757.1452996122000@Atlassian.JIRA>
References: <JIRA.12599757.1452996122000@Atlassian.JIRA>
	<JIRA.12599757.1452996122000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599757.1452996122000.73231.1516410486125@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1307:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha6)


> jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-1307
>                 URL: https://issues.jboss.org/browse/WFCORE-1307
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.7.Final
>            Reporter: Brad Maxwell
>            Assignee: Ken Wills
>             Fix For: 4.0.0.Alpha7
>
>
> If the server is started, and a cli call is made that fails to persist to the standalone.xml returns success even though it failed. 
> Start the server.
> Simple way to reproduce is to change the permissions on the configuration directory then run some cli commands such as shown below:
> {code}
> $ ./bin/jboss-cli.sh -c
> [standalone at localhost:9990 /] /system-property=foo1:add(value=bar1)
> {"outcome" => "success"}
> [standalone at localhost:9999 /] /subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
> {"outcome" => "success"}
> {code}
> {code}
> 19:53:17,823 ERROR [stderr] (management-handler-thread - 1) java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) 	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) 	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) 	at java.nio.file.Files.newByteChannel(Files.java:361)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) 	at java.nio.file.Files.createFile(Files.java:632)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:125)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) 	at java.security.AccessController.doPrivileged(Native Method)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) 	at java.lang.Thread.run(Thread.java:745)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 19:53:17,831 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0009: Failed to store configuration to standalone.xml: java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> 	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 	at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> 	at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> 	at java.nio.file.Files.deleteIfExists(Files.java:1165)
> 	at java.nio.file.Files.copy(Files.java:3004)
> 	at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:109)
> 	at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> 	at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> 	at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> 	at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 	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)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 20 07:37:00 2018
From: issues at jboss.org (Gonzalo Alonso (JIRA))
Date: Sat, 20 Jan 2018 07:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4296) remove _ds.xml deployment
	support
In-Reply-To: <JIRA.12561960.1422519388000@Atlassian.JIRA>
References: <JIRA.12561960.1422519388000@Atlassian.JIRA>
	<JIRA.12561960.1422519388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561960.1422519388000.73359.1516451820756@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13336815#comment-13336815 ] 

Gonzalo Alonso edited comment on WFLY-4296 at 1/20/18 7:36 AM:
---------------------------------------------------------------

once read arguments for and against this to be deprecated, +I also disagree+ to suppress this feature because it implies removing some advantages over other application servers. Because of safety and maintanibility, I think its more sensible to mantain each datasource for an application just writting a specificfile for that application (-ds.xml), much better than making changes in a big file where we must remember each change and how that affects to each application.


was (Author: albus):
once read arguments for and against this to be deprecated, +I also disagree+ with suppress this feature because it implies removing some advantages over other application servers. Because of safety and maintanibility, I think its more sensible to mantain each datasource for an application just writting a specificfile for that application (-ds.xml), much better than making changes in a big file where we must remember each change and how that affects to each application.

> remove _ds.xml deployment support
> ---------------------------------
>
>                 Key: WFLY-4296
>                 URL: https://issues.jboss.org/browse/WFLY-4296
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Stefano Maestri
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 20 07:39:00 2018
From: issues at jboss.org (Gonzalo Alonso (JIRA))
Date: Sat, 20 Jan 2018 07:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-4296) remove _ds.xml deployment
	support
In-Reply-To: <JIRA.12561960.1422519388000@Atlassian.JIRA>
References: <JIRA.12561960.1422519388000@Atlassian.JIRA>
	<JIRA.12561960.1422519388000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12561960.1422519388000.73376.1516451940868@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-4296?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13336815#comment-13336815 ] 

Gonzalo Alonso edited comment on WFLY-4296 at 1/20/18 7:38 AM:
---------------------------------------------------------------

once read arguments for and against this to be deprecated, +I also disagree+ to suppress this feature because it implies removing some advantages over other application servers. Because of safety and maintanibility, I think its more sensible to mantain each datasource for an application just writting a specific file for that application (-ds.xml), much better than making changes in a big file where we must remember each change and how that affects to each application.


was (Author: albus):
once read arguments for and against this to be deprecated, +I also disagree+ to suppress this feature because it implies removing some advantages over other application servers. Because of safety and maintanibility, I think its more sensible to mantain each datasource for an application just writting a specificfile for that application (-ds.xml), much better than making changes in a big file where we must remember each change and how that affects to each application.

> remove _ds.xml deployment support
> ---------------------------------
>
>                 Key: WFLY-4296
>                 URL: https://issues.jboss.org/browse/WFLY-4296
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: JCA
>            Reporter: Stefano Maestri
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 20 14:12:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Sat, 20 Jan 2018 14:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-2409) Intermittent failures in
 SessionClusterDbPersistenceTestCase
In-Reply-To: <JIRA.12509093.1383137843000@Atlassian.JIRA>
References: <JIRA.12509093.1383137843000@Atlassian.JIRA>
	<JIRA.12509093.1383137843000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12509093.1383137843000.73460.1516475520316@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-2409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521671#comment-13521671 ] 

Radoslav Husar commented on WFLY-2409:
--------------------------------------

The test has been reworked to actually use invalidation cache backed by shared (H2) database.

> Intermittent failures in SessionClusterDbPersistenceTestCase
> ------------------------------------------------------------
>
>                 Key: WFLY-2409
>                 URL: https://issues.jboss.org/browse/WFLY-2409
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, Test Suite
>    Affects Versions: JBoss AS7 7.1.1.Final
>            Reporter: Paul Ferraro
>            Assignee: Radoslav Husar
>             Fix For: 12.0.0.Alpha1
>
>
> &amp;#27;[0m&amp;#27;[31m08:43:00,006 ERROR [org.infinispan.persistence.jdbc.binary.JdbcBinaryStore] (default task-7) ISPN008012: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=35 bytes, valueBytes=270 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value={test=1}, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos; &apos;, -1)&quot;; SQL statement:
> INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:171)
> 	at org.h2.message.DbException.get(DbException.java:148)
> 	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
> 	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
> 	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
> 	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
> 	at org.h2.command.dml.Insert.update(Insert.java:86)
> 	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
> 	at org.h2.command.Command.executeUpdate(Command.java:235)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> &amp;#27;[0m&amp;#27;[31m08:43:00,018 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-7) ISPN000136: Execution error: org.infinispan.persistence.CacheLoaderException: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=35 bytes, valueBytes=270 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value={test=1}, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:411)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos; &apos;, -1)&quot;; SQL statement:
> INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:171)
> 	at org.h2.message.DbException.get(DbException.java:148)
> 	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
> 	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
> 	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
> 	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
> 	at org.h2.command.dml.Insert.update(Insert.java:86)
> 	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
> 	at org.h2.command.Command.executeUpdate(Command.java:235)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
> 	... 77 more
> &amp;#27;[0m&amp;#27;[31m08:43:00,023 ERROR [org.infinispan.transaction.TransactionCoordinator] (default task-7) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.persistence.CacheLoaderException: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=35 bytes, valueBytes=270 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value={test=1}, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:411)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos; &apos;, -1)&quot;; SQL statement:
> INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:171)
> 	at org.h2.message.DbException.get(DbException.java:148)
> 	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
> 	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
> 	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
> 	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
> 	at org.h2.command.dml.Insert.update(Insert.java:86)
> 	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
> 	at org.h2.command.Command.executeUpdate(Command.java:235)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
> 	... 77 more
> &amp;#27;[0m&amp;#27;[31m08:43:00,028 ERROR [org.infinispan.transaction.tm.DummyTransaction] (default task-7) ISPN000111: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, lockedKeys=null, backupKeyLocks=null, topologyId=2, isFromStateTransfer=false} org.infinispan.transaction.synchronization.SyncLocalTransaction at 13} org.infinispan.transaction.synchronization.SynchronizationAdapter at 32: org.infinispan.commons.CacheException: Could not commit.
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:60) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: javax.transaction.xa.XAException
> 	at org.infinispan.transaction.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:204) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:156) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	... 23 more
> &amp;#27;[0m08:43:00,032 INFO  [org.jboss.as.test.clustering.cluster.ClusterAbstractTestCase] (main) Requested http://127.0.0.1:8080/session-db-cluster/simple, got 1.
> &amp;#27;[31m08:43:00,038 ERROR [org.infinispan.persistence.jdbc.binary.JdbcBinaryStore] (default task-8) ISPN008012: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=29 bytes, valueBytes=27 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value=org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionCacheEntry at 415e75b5, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos;0301fe030200013e18374b4d465247426b6c6c335f6e3542594f305533552d30630369036a1d0301fe3e18374b4d465247426b6c6c335f6e3542594f305533552d3063036a1b0301fe03ff80020000014209636c440000014209636c4500000708036a190301fe0368ffffffffffffffffffffffffffffffff03620001&apos;, -1)&quot;; SQL statement:
> INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:171)
> 	at org.h2.message.DbException.get(DbException.java:148)
> 	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
> 	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
> 	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
> 	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
> 	at org.h2.command.dml.Insert.update(Insert.java:86)
> 	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
> 	at org.h2.command.Command.executeUpdate(Command.java:235)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> &amp;#27;[0m&amp;#27;[31m08:43:00,043 ERROR [org.infinispan.interceptors.InvocationContextInterceptor] (default task-8) ISPN000136: Execution error: org.infinispan.persistence.CacheLoaderException: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=29 bytes, valueBytes=27 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value=org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionCacheEntry at 415e75b5, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:411)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos;0301fe030200013e18374b4d465247426b6c6c335f6e3542594f305533552d30630369036a1d0301fe3e18374b4d465247426b6c6c335f6e3542594f305533552d3063036a1b0301fe03ff80020000014209636c440000014209636c4500000708036a190301fe0368ffffffffffffffffffffffffffffffff03620001&apos;, -1)&quot;; SQL statement:
> INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:171)
> 	at org.h2.message.DbException.get(DbException.java:148)
> 	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
> 	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
> 	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
> 	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
> 	at org.h2.command.dml.Insert.update(Insert.java:86)
> 	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
> 	at org.h2.command.Command.executeUpdate(Command.java:235)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
> 	... 77 more
> &amp;#27;[0m&amp;#27;[31m08:43:00,067 ERROR [org.infinispan.transaction.TransactionCoordinator] (default task-8) ISPN000097: Error while processing a prepare in a single-phase transaction: org.infinispan.persistence.CacheLoaderException: Sql failure while inserting bucket: Bucket{entries={7KMFRGBkll3_n5BYO0U3U-0c=MarshalledEntryImpl{keyBytes=29 bytes, valueBytes=27 bytes, metadataBytes=25 bytes, key=7KMFRGBkll3_n5BYO0U3U-0c, value=org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionCacheEntry at 415e75b5, metadata=InternalMetadataImpl{actual=EmbeddedMetadata{version=null}, created=-1, lastUsed=-1}, marshaller=org.infinispan.marshall.core.CacheMarshaller at 5b081828}}, bucketId=&apos;865627136&apos;}
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:411)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.storeInBucket(JdbcBinaryStore.java:519)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.write(JdbcBinaryStore.java:122)
> 	at org.infinispan.persistence.manager.PersistenceManagerImpl.writeToAllStores(PersistenceManagerImpl.java:432) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitSingleStore(CacheWriterInterceptor.java:306) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor$Updater.visitPutKeyValueCommand(CacheWriterInterceptor.java:250) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.write.PutKeyValueCommand.acceptVisitor(PutKeyValueCommand.java:62) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.store(CacheWriterInterceptor.java:212) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.commitCommand(CacheWriterInterceptor.java:115) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.CacheWriterInterceptor.visitPrepareCommand(CacheWriterInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.EntryWrappingInterceptor.visitPrepareCommand(EntryWrappingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.AbstractTxLockingInterceptor.invokeNextAndCommitIf1Pc(AbstractTxLockingInterceptor.java:93) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.locking.PessimisticLockingInterceptor.visitPrepareCommand(PessimisticLockingInterceptor.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.NotificationInterceptor.visitPrepareCommand(NotificationInterceptor.java:36) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.invokeNextInterceptorAndVerifyTransaction(TxInterceptor.java:114) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.TxInterceptor.visitPrepareCommand(TxInterceptor.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.TransactionSynchronizerInterceptor.visitPrepareCommand(TransactionSynchronizerInterceptor.java:42) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTopologyAffectedCommand(StateTransferInterceptor.java:253) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.handleTxCommand(StateTransferInterceptor.java:184) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.statetransfer.StateTransferInterceptor.visitPrepareCommand(StateTransferInterceptor.java:89) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.handleDefault(CommandInterceptor.java:112) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleAll(InvocationContextInterceptor.java:106) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InvocationContextInterceptor.handleDefault(InvocationContextInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.base.CommandInterceptor.invokeNextInterceptor(CommandInterceptor.java:98) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.BatchingInterceptor.handleDefault(BatchingInterceptor.java:70) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.AbstractVisitor.visitPrepareCommand(AbstractVisitor.java:96) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.commands.tx.PrepareCommand.acceptVisitor(PrepareCommand.java:125) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.interceptors.InterceptorChain.invoke(InterceptorChain.java:321) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:154) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: org.h2.jdbc.JdbcSQLException: Unique index or primary key violation: &quot;PRIMARY_KEY_A ON PUBLIC.&quot;&quot;binarybased_default_host_session_db_cluster&quot;&quot;(ID) VALUES ( /* key:2 */ &apos;865627136&apos;, X&apos;0301fe030200013e18374b4d465247426b6c6c335f6e3542594f305533552d30630369036a1d0301fe3e18374b4d465247426b6c6c335f6e3542594f305533552d3063036a1b0301fe03ff80020000014209636c440000014209636c4500000708036a190301fe0368ffffffffffffffffffffffffffffffff03620001&apos;, -1)&quot;; SQL statement:
> INSERT INTO &quot;binarybased_default_host_session_db_cluster&quot; (datum, version, id) VALUES(?,?,?) [23505-173]
> 	at org.h2.message.DbException.getJdbcSQLException(DbException.java:331)
> 	at org.h2.message.DbException.get(DbException.java:171)
> 	at org.h2.message.DbException.get(DbException.java:148)
> 	at org.h2.index.BaseIndex.getDuplicateKeyException(BaseIndex.java:101)
> 	at org.h2.index.TreeIndex.add(TreeIndex.java:68)
> 	at org.h2.table.RegularTable.addRow(RegularTable.java:125)
> 	at org.h2.command.dml.Insert.insertRows(Insert.java:127)
> 	at org.h2.command.dml.Insert.update(Insert.java:86)
> 	at org.h2.command.CommandContainer.update(CommandContainer.java:79)
> 	at org.h2.command.Command.executeUpdate(Command.java:235)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdateInternal(JdbcPreparedStatement.java:154)
> 	at org.h2.jdbc.JdbcPreparedStatement.executeUpdate(JdbcPreparedStatement.java:140)
> 	at org.jboss.jca.adapters.jdbc.WrappedPreparedStatement.executeUpdate(WrappedPreparedStatement.java:493)
> 	at org.infinispan.persistence.jdbc.binary.JdbcBinaryStore.insertBucket(JdbcBinaryStore.java:405)
> 	... 77 more
> &amp;#27;[0m&amp;#27;[31m08:43:00,072 ERROR [org.infinispan.transaction.tm.DummyTransaction] (default task-8) ISPN000111: afterCompletion() failed for SynchronizationAdapter{localTransaction=LocalTransaction{remoteLockedNodes=null, isMarkedForRollback=false, lockedKeys=null, backupKeyLocks=null, topologyId=2, isFromStateTransfer=false} org.infinispan.transaction.synchronization.SyncLocalTransaction at 16} org.infinispan.transaction.synchronization.SynchronizationAdapter at 35: org.infinispan.commons.CacheException: Could not commit.
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:60) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.notifyAfterCompletion(DummyTransaction.java:263) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.runCommitTx(DummyTransaction.java:312) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyTransaction.commit(DummyTransaction.java:69) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.tm.DummyBaseTransactionManager.commit(DummyBaseTransactionManager.java:80) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.resolveTransaction(BatchContainer.java:101) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:83) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.batch.BatchContainer.endBatch(BatchContainer.java:64) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.CacheImpl.endBatch(CacheImpl.java:768) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.AbstractDelegatingCache.endBatch(AbstractDelegatingCache.java:53) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.end(InfinispanSessionManager.java:151)
> 	at org.wildfly.clustering.web.infinispan.session.InfinispanSessionManager$1.close(InfinispanSessionManager.java:141)
> 	at org.wildfly.clustering.web.undertow.session.SessionAdapter.requestDone(SessionAdapter.java:69)
> 	at io.undertow.servlet.spec.ServletContextImpl.updateSessionAccessTime(ServletContextImpl.java:708) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.spec.HttpServletResponseImpl.responseDone(HttpServletResponseImpl.java:501) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:258) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:205) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:69) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:134) [undertow-servlet-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:138) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:622) [undertow-core-1.0.0.Beta20.jar:1.0.0.Beta20]
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_25]
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_25]
> 	at java.lang.Thread.run(Thread.java:724) [rt.jar:1.7.0_25]
> Caused by: javax.transaction.xa.XAException
> 	at org.infinispan.transaction.TransactionCoordinator.handleCommitFailure(TransactionCoordinator.java:204) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.TransactionCoordinator.commit(TransactionCoordinator.java:156) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	at org.infinispan.transaction.synchronization.SynchronizationAdapter.afterCompletion(SynchronizationAdapter.java:58) [infinispan-core-6.0.0-SNAPSHOT.jar:6.0.0-SNAPSHOT]
> 	... 23 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Sun Jan 21 17:27:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 21 Jan 2018 17:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9563) Integrate KUBE_PING discovery
	protocol
In-Reply-To: <JIRA.12721993.1511360492000@Atlassian.JIRA>
References: <JIRA.12721993.1511360492000@Atlassian.JIRA>
	<JIRA.12721993.1511360492000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721993.1511360492000.73699.1516573620331@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521696#comment-13521696 ] 

Kabir Khan commented on WFLY-9563:
----------------------------------

+1 this looks like it has started, so we should have dev analysis (I believe Jason set it up so Paul should have permissions to clone it now)

> Integrate KUBE_PING discovery protocol
> --------------------------------------
>
>                 Key: WFLY-9563
>                 URL: https://issues.jboss.org/browse/WFLY-9563
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 11.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 12.0.0.Alpha1
>
>
> https://github.com/jgroups-extras/jgroups-kubernetes



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 21 17:27:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Sun, 21 Jan 2018 17:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9563) Integrate KUBE_PING discovery
	protocol
In-Reply-To: <JIRA.12721993.1511360492000@Atlassian.JIRA>
References: <JIRA.12721993.1511360492000@Atlassian.JIRA>
	<JIRA.12721993.1511360492000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721993.1511360492000.73705.1516573620494@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521696#comment-13521696 ] 

Kabir Khan edited comment on WFLY-9563 at 1/21/18 5:26 PM:
-----------------------------------------------------------

+1 this looks like it has started, so we should have dev analysis (I believe Jason set it up so Paul should have permissions to clone to EAP7 now)


was (Author: kabirkhan):
+1 this looks like it has started, so we should have dev analysis (I believe Jason set it up so Paul should have permissions to clone it now)

> Integrate KUBE_PING discovery protocol
> --------------------------------------
>
>                 Key: WFLY-9563
>                 URL: https://issues.jboss.org/browse/WFLY-9563
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 11.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 12.0.0.Alpha1
>
>
> https://github.com/jgroups-extras/jgroups-kubernetes



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 21 19:40:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 21 Jan 2018 19:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3512) ClassReflectionIndexUtil
 does not return default methods from findMethod
In-Reply-To: <JIRA.12729299.1516120996000@Atlassian.JIRA>
References: <JIRA.12729299.1516120996000@Atlassian.JIRA>
	<JIRA.12729299.1516120996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729299.1516120996000.73814.1516581600365@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas reopened WFCORE-3512:
------------------------------------


> ClassReflectionIndexUtil does not return default methods from findMethod
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-3512
>                 URL: https://issues.jboss.org/browse/WFCORE-3512
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Daniel Bildhauer
>            Assignee: Stuart Douglas
>         Attachments: ejb-in-ear.zip, wildfly-ejb-in-ear-ear.ear
>
>
> This problem is in Wildfly Core, but manifests as an issue with EJB's in WildFly full.
> Given the following class/interface inheritance structure, the interface method doMagic could not be called from a remote view, even if there is a default implementation as given in the mixin interface. A local call works, but the remote call fails with a message like
> {code}
> org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
> {code}
> Example code:
> {code}
> @Remote
> interface MyEJBInterface {
>    void doMagic();
> }
> interface MyEJBMixin extends MyEJBInterface {
>    default void doMagic() { .... }
> }
> @Stateless
> class MyEJBBean extends MyEJBMixin {
> }
> {code}
> The problem is inside the fix for WFLY-4354 bug, which checks only for the default method implementation in the interface declaring the method the first time but not in other interfaces. 
> A example is attached and I will submitt a pull request with a fix. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 21 19:40:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 21 Jan 2018 19:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3512) ClassReflectionIndexUtil
 does not return default methods from findMethod
In-Reply-To: <JIRA.12729299.1516120996000@Atlassian.JIRA>
References: <JIRA.12729299.1516120996000@Atlassian.JIRA>
	<JIRA.12729299.1516120996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729299.1516120996000.73818.1516581600546@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas updated WFCORE-3512:
-----------------------------------
    Fix Version/s:     (was: 4.0.0.Alpha6)


> ClassReflectionIndexUtil does not return default methods from findMethod
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-3512
>                 URL: https://issues.jboss.org/browse/WFCORE-3512
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Daniel Bildhauer
>            Assignee: Stuart Douglas
>         Attachments: ejb-in-ear.zip, wildfly-ejb-in-ear-ear.ear
>
>
> This problem is in Wildfly Core, but manifests as an issue with EJB's in WildFly full.
> Given the following class/interface inheritance structure, the interface method doMagic could not be called from a remote view, even if there is a default implementation as given in the mixin interface. A local call works, but the remote call fails with a message like
> {code}
> org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
> {code}
> Example code:
> {code}
> @Remote
> interface MyEJBInterface {
>    void doMagic();
> }
> interface MyEJBMixin extends MyEJBInterface {
>    default void doMagic() { .... }
> }
> @Stateless
> class MyEJBBean extends MyEJBMixin {
> }
> {code}
> The problem is inside the fix for WFLY-4354 bug, which checks only for the default method implementation in the interface declaring the method the first time but not in other interfaces. 
> A example is attached and I will submitt a pull request with a fix. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 21 19:41:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Sun, 21 Jan 2018 19:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3512) ClassReflectionIndexUtil
 does not return default methods from findMethod
In-Reply-To: <JIRA.12729299.1516120996000@Atlassian.JIRA>
References: <JIRA.12729299.1516120996000@Atlassian.JIRA>
	<JIRA.12729299.1516120996000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729299.1516120996000.73822.1516581660165@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3512?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521706#comment-13521706 ] 

Stuart Douglas commented on WFCORE-3512:
----------------------------------------

Previous commit had an issue where the returned Method could vary depending on Set iteration order, https://github.com/wildfly/wildfly-core/pull/3054 should fix it.

> ClassReflectionIndexUtil does not return default methods from findMethod
> ------------------------------------------------------------------------
>
>                 Key: WFCORE-3512
>                 URL: https://issues.jboss.org/browse/WFCORE-3512
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Server
>            Reporter: Daniel Bildhauer
>            Assignee: Stuart Douglas
>         Attachments: ejb-in-ear.zip, wildfly-ejb-in-ear-ear.ear
>
>
> This problem is in Wildfly Core, but manifests as an issue with EJB's in WildFly full.
> Given the following class/interface inheritance structure, the interface method doMagic could not be called from a remote view, even if there is a default implementation as given in the mixin interface. A local call works, but the remote call fails with a message like
> {code}
> org.jboss.invocation.CannotProceedException: INV000002: Invocation cannot proceed (end of interceptor chain has been hit)
> {code}
> Example code:
> {code}
> @Remote
> interface MyEJBInterface {
>    void doMagic();
> }
> interface MyEJBMixin extends MyEJBInterface {
>    default void doMagic() { .... }
> }
> @Stateless
> class MyEJBBean extends MyEJBMixin {
> }
> {code}
> The problem is inside the fix for WFLY-4354 bug, which checks only for the default method implementation in the interface declaring the method the first time but not in other interfaces. 
> A example is attached and I will submitt a pull request with a fix. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 01:32:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 22 Jan 2018 01:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1492)
 java.nio.file.InvalidPathException: Illegal char ':' at krb5.conf
In-Reply-To: <JIRA.12730034.1516602708000@Atlassian.JIRA>
References: <JIRA.12730034.1516602708000@Atlassian.JIRA>
	<JIRA.12730034.1516602708827@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730034.1516602708000.73906.1516602720211@Atlassian.JIRA>

Martin Choma created ELY-1492:
---------------------------------

             Summary: java.nio.file.InvalidPathException: Illegal char ':' at krb5.conf
                 Key: ELY-1492
                 URL: https://issues.jboss.org/browse/ELY-1492
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Testsuite
    Affects Versions: 1.2.0.Beta11
            Reporter: Martin Choma


This occures in TS on JDK9 on Windows in tests:
* org.wildfly.security.sasl.gssapi.CommunicationSuiteChild
* org.wildfly.security.sasl.gs2.Gs2SuiteChild

{noformat}
javax.security.auth.login.LoginException: 
java.nio.file.InvalidPathException: Illegal char <:> at index 2: /W:/workspace/wildfly-elytron-unit-tests/4ad7c91f/wildfly-elytron/target/test-classes/krb5.conf
	at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
	at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
	at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
	at java.base/java.nio.file.Paths.get(Paths.java:84)
	at java.security.jgss/sun.security.krb5.Config.lambda$loadConfigFile$0(Config.java:639)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:429)
	at java.security.jgss/sun.security.krb5.Config.loadConfigFile(Config.java:638)
	at java.security.jgss/sun.security.krb5.Config.<init>(Config.java:176)
	at java.security.jgss/sun.security.krb5.Config.refresh(Config.java:115)
	at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:528)
	at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726)
	at java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
	at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
	at org.wildfly.security.sasl.gssapi.JaasUtil.login(JaasUtil.java:71)
	at org.wildfly.security.sasl.gssapi.JaasUtil.loginClient(JaasUtil.java:53)
	at org.wildfly.security.sasl.gs2.Gs2SuiteChild.init(Gs2SuiteChild.java:102)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeClassMethod(JUnit4TestRunnerDecorator.java:92)
	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:30)
	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.junit.runners.Suite.runChild(Suite.java:128)
	at org.junit.runners.Suite.runChild(Suite.java:27)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)

	at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:821)
	at java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
	at java.base/java.security.AccessController.doPrivileged(Native Method)
	at java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
	at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
	at org.wildfly.security.sasl.gssapi.JaasUtil.login(JaasUtil.java:71)
	at org.wildfly.security.sasl.gssapi.JaasUtil.loginClient(JaasUtil.java:53)
	at org.wildfly.security.sasl.gs2.Gs2SuiteChild.init(Gs2SuiteChild.java:102)
{noformat}

[1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/41/jdk=jdk1.9,label=eap-sustaining&&w2k12r2&&x86_64/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 01:42:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 22 Jan 2018 01:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1493)
 java.util.concurrent.TimeoutException on slow machines
In-Reply-To: <JIRA.12730035.1516603287000@Atlassian.JIRA>
References: <JIRA.12730035.1516603287000@Atlassian.JIRA>
	<JIRA.12730035.1516603287045@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730035.1516603287000.73908.1516603320353@Atlassian.JIRA>

Martin Choma created ELY-1493:
---------------------------------

             Summary: java.util.concurrent.TimeoutException on slow machines
                 Key: ELY-1493
                 URL: https://issues.jboss.org/browse/ELY-1493
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Testsuite
    Affects Versions: 1.2.0.Beta11
            Reporter: Martin Choma


On solaris 10 (slow machine) there occured timeout for task task2Future.get(1, TimeUnit.SECONDS) on line 492. 

Prolong timeout will probably reduce occurences. 

{noformat}
java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException
         at  org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:459)
         at  org.wildfly.security.credential.store.KeystorePasswordStoreTest.testParallelAccessToCS(KeystorePasswordStoreTest.java:439)
Caused by: java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException
        at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
        at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:205)
         at  org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:457)
        ... 1 more
Caused by: java.util.concurrent.TimeoutException
        at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
        at org.wildfly.security.credential.store.KeystorePasswordStoreTest$1.call(KeystorePasswordStoreTest.java:492)
        at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
        at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
        at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
        at java.base/java.lang.Thread.run(Thread.java:844)
{noformat}


[1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/40/jdk=java18_default,label=eap-sustaining&&solaris10&&sparc/testReport/




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 02:02:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 22 Jan 2018 02:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1494) SecurityException: JCE cannot
 authenticate the provider WildFlyElytron
In-Reply-To: <JIRA.12730037.1516604502000@Atlassian.JIRA>
References: <JIRA.12730037.1516604502000@Atlassian.JIRA>
	<JIRA.12730037.1516604502773@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730037.1516604502000.73950.1516604520198@Atlassian.JIRA>

Martin Choma created ELY-1494:
---------------------------------

             Summary: SecurityException: JCE cannot authenticate the provider WildFlyElytron
                 Key: ELY-1494
                 URL: https://issues.jboss.org/browse/ELY-1494
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Testsuite
    Affects Versions: 1.2.0.Beta11
            Reporter: Martin Choma


This happens on HP-UX. It probably related to ELY-1295 fix. Fix have to take HP-UX JDK in account as well.
 
Btw. Isn't there more elegant way how to enable tests for PKCS12. Necessary hack seems to be problematic.

{noformat}
java.lang.SecurityException: JCE cannot authenticate the provider WildFlyElytron
        at javax.crypto.JceSecurity.getInstance(JceSecurity.java:118)
        at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:244)
        at  org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:117)
Caused  by: java.lang.SecurityException: Cannot verify  jar:file:/hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes/!/
        at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:448)
        at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:363)
        at javax.crypto.JarVerifier.verify(JarVerifier.java:289)
        at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:164)
        at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:190)
        at javax.crypto.JceSecurity.getInstance(JceSecurity.java:114)
        ... 2 more
Caused  by: java.security.PrivilegedActionException:  java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:426)
        ... 7 more
Caused  by: java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(ZipFile.java:225)
        at java.util.zip.ZipFile.<init>(ZipFile.java:155)
        at java.util.jar.JarFile.<init>(JarFile.java:166)
        at java.util.jar.JarFile.<init>(JarFile.java:103)
        at javax.crypto.JarVerifier$2.run(JarVerifier.java:440)
        at javax.crypto.JarVerifier$2.run(JarVerifier.java:427)
        ... 9 more
{noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 02:04:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 22 Jan 2018 02:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1494) SecurityException: JCE cannot
 authenticate the provider WildFlyElytron
In-Reply-To: <JIRA.12730037.1516604503000@Atlassian.JIRA>
References: <JIRA.12730037.1516604503000@Atlassian.JIRA>
	<JIRA.12730037.1516604503000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730037.1516604503000.73952.1516604640065@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1494:
------------------------------
    Description: 
This happens on HP-UX in KeyStoreCredentialStoreTest. It probably related to ELY-1295 fix. Fix have to take HP-UX JDK in account as well.
 
Btw. Isn't there more elegant way how to enable tests for PKCS12. Necessary hack seems to be problematic.

{noformat}
java.lang.SecurityException: JCE cannot authenticate the provider WildFlyElytron
        at javax.crypto.JceSecurity.getInstance(JceSecurity.java:118)
        at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:244)
        at  org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:117)
Caused  by: java.lang.SecurityException: Cannot verify  jar:file:/hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes/!/
        at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:448)
        at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:363)
        at javax.crypto.JarVerifier.verify(JarVerifier.java:289)
        at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:164)
        at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:190)
        at javax.crypto.JceSecurity.getInstance(JceSecurity.java:114)
        ... 2 more
Caused  by: java.security.PrivilegedActionException:  java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:426)
        ... 7 more
Caused  by: java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(ZipFile.java:225)
        at java.util.zip.ZipFile.<init>(ZipFile.java:155)
        at java.util.jar.JarFile.<init>(JarFile.java:166)
        at java.util.jar.JarFile.<init>(JarFile.java:103)
        at javax.crypto.JarVerifier$2.run(JarVerifier.java:440)
        at javax.crypto.JarVerifier$2.run(JarVerifier.java:427)
        ... 9 more
{noformat}

[1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/40/jdk=jdk1.8_hpux,label=eap-sustaining&&hpux11v3/testReport/

  was:
This happens on HP-UX. It probably related to ELY-1295 fix. Fix have to take HP-UX JDK in account as well.
 
Btw. Isn't there more elegant way how to enable tests for PKCS12. Necessary hack seems to be problematic.

{noformat}
java.lang.SecurityException: JCE cannot authenticate the provider WildFlyElytron
        at javax.crypto.JceSecurity.getInstance(JceSecurity.java:118)
        at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:244)
        at  org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:117)
Caused  by: java.lang.SecurityException: Cannot verify  jar:file:/hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes/!/
        at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:448)
        at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:363)
        at javax.crypto.JarVerifier.verify(JarVerifier.java:289)
        at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:164)
        at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:190)
        at javax.crypto.JceSecurity.getInstance(JceSecurity.java:114)
        ... 2 more
Caused  by: java.security.PrivilegedActionException:  java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
        at java.security.AccessController.doPrivileged(Native Method)
        at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:426)
        ... 7 more
Caused  by: java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
        at java.util.zip.ZipFile.open(Native Method)
        at java.util.zip.ZipFile.<init>(ZipFile.java:225)
        at java.util.zip.ZipFile.<init>(ZipFile.java:155)
        at java.util.jar.JarFile.<init>(JarFile.java:166)
        at java.util.jar.JarFile.<init>(JarFile.java:103)
        at javax.crypto.JarVerifier$2.run(JarVerifier.java:440)
        at javax.crypto.JarVerifier$2.run(JarVerifier.java:427)
        ... 9 more
{noformat}



> SecurityException: JCE cannot authenticate the provider WildFlyElytron
> ----------------------------------------------------------------------
>
>                 Key: ELY-1494
>                 URL: https://issues.jboss.org/browse/ELY-1494
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>
> This happens on HP-UX in KeyStoreCredentialStoreTest. It probably related to ELY-1295 fix. Fix have to take HP-UX JDK in account as well.
>  
> Btw. Isn't there more elegant way how to enable tests for PKCS12. Necessary hack seems to be problematic.
> {noformat}
> java.lang.SecurityException: JCE cannot authenticate the provider WildFlyElytron
>         at javax.crypto.JceSecurity.getInstance(JceSecurity.java:118)
>         at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:244)
>         at  org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:117)
> Caused  by: java.lang.SecurityException: Cannot verify  jar:file:/hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes/!/
>         at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:448)
>         at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:363)
>         at javax.crypto.JarVerifier.verify(JarVerifier.java:289)
>         at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:164)
>         at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:190)
>         at javax.crypto.JceSecurity.getInstance(JceSecurity.java:114)
>         ... 2 more
> Caused  by: java.security.PrivilegedActionException:  java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:426)
>         ... 7 more
> Caused  by: java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
>         at java.util.zip.ZipFile.open(Native Method)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:225)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:155)
>         at java.util.jar.JarFile.<init>(JarFile.java:166)
>         at java.util.jar.JarFile.<init>(JarFile.java:103)
>         at javax.crypto.JarVerifier$2.run(JarVerifier.java:440)
>         at javax.crypto.JarVerifier$2.run(JarVerifier.java:427)
>         ... 9 more
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/40/jdk=jdk1.8_hpux,label=eap-sustaining&&hpux11v3/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 02:28:00 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Mon, 22 Jan 2018 02:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3531)
 EnumValidator.validateParameter should check toStringMap first to reduce
 the possibility of IllegalArgumentException creation
In-Reply-To: <JIRA.12730040.1516606001000@Atlassian.JIRA>
References: <JIRA.12730040.1516606001000@Atlassian.JIRA>
	<JIRA.12730040.1516606001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730040.1516606001000.73976.1516606080139@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao moved JBEAP-14117 to WFCORE-3531:
-----------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-3531  (was: JBEAP-14117)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Domain Management
                       JMX
                           (was: JMX)
    Affects Version/s:     (was: 6.4.0.GA)


> EnumValidator.validateParameter should check toStringMap first to reduce the possibility of IllegalArgumentException creation
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3531
>                 URL: https://issues.jboss.org/browse/WFCORE-3531
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, JMX
>         Environment: JBoss EAP 6.4.16,6.4.18
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> 1. Proposed title of this feature request
> Enum is misspelled causing java.lang.IllegalArgumentException 
> 2. Who is the customer behind the request?
> Account: Hamburg S?damerikanische Dampfschifffahrts-Ge, 5651756 
> 3. What is the nature and description of the request?
> Enum is misspelled causing java.lang.IllegalArgumentException 
> 5. How would the customer like to achieve this? (List the functional requirements here)
> In such way, it should not throw Exception and spelled correctly.
> ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
> Location Where Enum is Used :
> jboss-as-jmx module:
> ./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java
> Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());
> it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.
> Stacktrace Attached.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 22 02:34:00 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Mon, 22 Jan 2018 02:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3531)
 EnumValidator.validateParameter should check toStringMap first to reduce
 the possibility of IllegalArgumentException creation
In-Reply-To: <JIRA.12730040.1516606001000@Atlassian.JIRA>
References: <JIRA.12730040.1516606001000@Atlassian.JIRA>
	<JIRA.12730040.1516606001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730040.1516606001000.74010.1516606440057@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao updated WFCORE-3531:
----------------------------
    Description: 
{panel:title=Description of downstream issue}
1. Proposed title of this feature request
Enum is misspelled causing java.lang.IllegalArgumentException 
2. Who is the customer behind the request?
Account: Hamburg S?damerikanische Dampfschifffahrts-Ge, 5651756 
3. What is the nature and description of the request?
Enum is misspelled causing java.lang.IllegalArgumentException 
5. How would the customer like to achieve this? (List the functional requirements here)
In such way, it should not throw Exception and spelled correctly.

ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
Location Where Enum is Used :

jboss-as-jmx module:

./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java

Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());

it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.

Stacktrace Attached.
{panel}

----

{panel:title=Description}

+EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.

However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.

{panel}


  was:
1. Proposed title of this feature request
Enum is misspelled causing java.lang.IllegalArgumentException 
2. Who is the customer behind the request?
Account: Hamburg S?damerikanische Dampfschifffahrts-Ge, 5651756 
3. What is the nature and description of the request?
Enum is misspelled causing java.lang.IllegalArgumentException 
5. How would the customer like to achieve this? (List the functional requirements here)
In such way, it should not throw Exception and spelled correctly.

ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
Location Where Enum is Used :

jboss-as-jmx module:

./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java

Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());

it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.

Stacktrace Attached.



> EnumValidator.validateParameter should check toStringMap first to reduce the possibility of IllegalArgumentException creation
> -----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3531
>                 URL: https://issues.jboss.org/browse/WFCORE-3531
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, JMX
>         Environment: JBoss EAP 6.4.16,6.4.18
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> {panel:title=Description of downstream issue}
> 1. Proposed title of this feature request
> Enum is misspelled causing java.lang.IllegalArgumentException 
> 2. Who is the customer behind the request?
> Account: Hamburg S?damerikanische Dampfschifffahrts-Ge, 5651756 
> 3. What is the nature and description of the request?
> Enum is misspelled causing java.lang.IllegalArgumentException 
> 5. How would the customer like to achieve this? (List the functional requirements here)
> In such way, it should not throw Exception and spelled correctly.
> ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
> Location Where Enum is Used :
> jboss-as-jmx module:
> ./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java
> Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());
> it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.
> Stacktrace Attached.
> {panel}
> ----
> {panel:title=Description}
> +EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.
> However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.
> {panel}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 22 02:50:00 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Mon, 22 Jan 2018 02:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3531)
 EnumValidator.validateParameter should check toStringMap first to reduce
 the times of IllegalArgumentException creation
In-Reply-To: <JIRA.12730040.1516606001000@Atlassian.JIRA>
References: <JIRA.12730040.1516606001000@Atlassian.JIRA>
	<JIRA.12730040.1516606001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730040.1516606001000.74041.1516607400056@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao updated WFCORE-3531:
----------------------------
    Summary: EnumValidator.validateParameter should check toStringMap first to reduce the times of IllegalArgumentException creation  (was: EnumValidator.validateParameter should check toStringMap first to reduce the possibility of IllegalArgumentException creation)


> EnumValidator.validateParameter should check toStringMap first to reduce the times of IllegalArgumentException creation
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3531
>                 URL: https://issues.jboss.org/browse/WFCORE-3531
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, JMX
>         Environment: JBoss EAP 6.4.16,6.4.18
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> {panel:title=Description of downstream issue}
> 1. Proposed title of this feature request
> Enum is misspelled causing java.lang.IllegalArgumentException 
> 2. Who is the customer behind the request?
> Account: Hamburg S?damerikanische Dampfschifffahrts-Ge, 5651756 
> 3. What is the nature and description of the request?
> Enum is misspelled causing java.lang.IllegalArgumentException 
> 5. How would the customer like to achieve this? (List the functional requirements here)
> In such way, it should not throw Exception and spelled correctly.
> ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
> Location Where Enum is Used :
> jboss-as-jmx module:
> ./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java
> Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());
> it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.
> Stacktrace Attached.
> {panel}
> ----
> {panel:title=Description}
> +EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.
> However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.
> {panel}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 22 02:51:00 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Mon, 22 Jan 2018 02:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3531)
 EnumValidator.validateParameter should check toStringMap first to reduce
 the times of IllegalArgumentException creation
In-Reply-To: <JIRA.12730040.1516606001000@Atlassian.JIRA>
References: <JIRA.12730040.1516606001000@Atlassian.JIRA>
	<JIRA.12730040.1516606001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730040.1516606001000.74044.1516607460190@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao updated WFCORE-3531:
----------------------------
    Labels: downstream_dependency  (was: )


> EnumValidator.validateParameter should check toStringMap first to reduce the times of IllegalArgumentException creation
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3531
>                 URL: https://issues.jboss.org/browse/WFCORE-3531
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, JMX
>         Environment: JBoss EAP 6.4.16,6.4.18
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>              Labels: downstream_dependency
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> {panel:title=Description of downstream issue}
> 1. Proposed title of this feature request
> Enum is misspelled causing java.lang.IllegalArgumentException 
> 2. Who is the customer behind the request?
> Account: Hamburg S?damerikanische Dampfschifffahrts-Ge, 5651756 
> 3. What is the nature and description of the request?
> Enum is misspelled causing java.lang.IllegalArgumentException 
> 5. How would the customer like to achieve this? (List the functional requirements here)
> In such way, it should not throw Exception and spelled correctly.
> ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
> Location Where Enum is Used :
> jboss-as-jmx module:
> ./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java
> Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());
> it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.
> Stacktrace Attached.
> {panel}
> ----
> {panel:title=Description}
> +EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.
> However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.
> {panel}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 22 03:02:00 2018
From: issues at jboss.org (Lin Gao (JIRA))
Date: Mon, 22 Jan 2018 03:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3531)
 EnumValidator.validateParameter should check toStringMap first to reduce
 the times of IllegalArgumentException creation
In-Reply-To: <JIRA.12730040.1516606001000@Atlassian.JIRA>
References: <JIRA.12730040.1516606001000@Atlassian.JIRA>
	<JIRA.12730040.1516606001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730040.1516606001000.74093.1516608120058@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Lin Gao updated WFCORE-3531:
----------------------------
    Labels: downstream_dependency performace  (was: downstream_dependency)


> EnumValidator.validateParameter should check toStringMap first to reduce the times of IllegalArgumentException creation
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3531
>                 URL: https://issues.jboss.org/browse/WFCORE-3531
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management, JMX
>         Environment: JBoss EAP 6.4.16,6.4.18
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>              Labels: downstream_dependency, performace
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> {panel:title=Description of downstream issue}
> 1. Proposed title of this feature request
> Enum is misspelled causing java.lang.IllegalArgumentException 
> 2. Who is the customer behind the request?
> Account: Hamburg S?damerikanische Dampfschifffahrts-Ge, 5651756 
> 3. What is the nature and description of the request?
> Enum is misspelled causing java.lang.IllegalArgumentException 
> 5. How would the customer like to achieve this? (List the functional requirements here)
> In such way, it should not throw Exception and spelled correctly.
> ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
> Location Where Enum is Used :
> jboss-as-jmx module:
> ./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java
> Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());
> it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.
> Stacktrace Attached.
> {panel}
> ----
> {panel:title=Description}
> +EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.
> However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.
> {panel}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 22 03:18:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 22 Jan 2018 03:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2246) Internal thread pool not
 created if default thread pool is injected
In-Reply-To: <JIRA.12729969.1516374337000@Atlassian.JIRA>
References: <JIRA.12729969.1516374337000@Atlassian.JIRA>
	<JIRA.12729969.1516374337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729969.1516374337000.74252.1516609080305@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2246:
---------------------------
    Fix Version/s: 4.0.10


> Internal thread pool not created if default thread pool is injected
> -------------------------------------------------------------------
>
>                 Key: JGRP-2246
>                 URL: https://issues.jboss.org/browse/JGRP-2246
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.9
>            Reporter: Paul Ferraro
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> WildFly injects a custom thread pool into its JGroups transports.  However, in JGroups 4.0.x, only the default thread pool exposes a setThreadPool(...) method.  The internal thread pool does not.  However, the logic within TP.init() will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly.
> Can we restore the TP.setInternalThreadPool(...) method?  Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when thread_pool_enabled is true? 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 03:38:00 2018
From: issues at jboss.org (=?UTF-8?Q?=E4=B8=B9=E4=B8=B9_=E7=8E=8B_=28JIRA=29?=)
Date: Mon, 22 Jan 2018 03:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2257) Error evaluating constraint
In-Reply-To: <JIRA.12730049.1516610224000@Atlassian.JIRA>
References: <JIRA.12730049.1516610224000@Atlassian.JIRA>
	<JIRA.12730049.1516610224080@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730049.1516610224000.74399.1516610280263@Atlassian.JIRA>

?? ? created DROOLS-2257:
----------------------------

             Summary: Error evaluating constraint
                 Key: DROOLS-2257
                 URL: https://issues.jboss.org/browse/DROOLS-2257
             Project: Drools
          Issue Type: Feature Request
          Components: docker images
    Affects Versions: 7.0.0.Final
            Reporter: ?? ?
            Assignee: Roger Mart?nez


code?

{code:java}
 //?????
rule "???????"
    when
        $materialDecision: SearchDrools(nodeCode.equals(CallActivityEnum.BU_DONG_CHAN_JU_BIAN_GENG.getCode()))
    then
        logger.info("access rule: ???????");
end


rule "???????????" extends "???????"
    when
    then
        logger.info("access rule: ???????????");
        $materialDecision.getMaterialResultList().add(new Material().setCode(MaterialCodeConstants.FANG_CHAN_ZHENG).setCopy(0).setNum(1));
        $materialDecision.getMaterialResultList().add(new Material().setCode(MaterialCodeConstants.JIA_FANG_SHEN_FEN_ZHENG).setCopy(0).setNum(1));
        $materialDecision.getMaterialResultList().add(new Material().setCode(MaterialCodeConstants.FANG_CHAN_ZHENG).setCopy(1).setNum(1));
        $materialDecision.getMaterialResultList().add(new Material().setCode(MaterialCodeConstants.JIA_FANG_SHEN_FEN_ZHENG).setCopy(1).setNum(1));
        $materialDecision.getMaterialResultList().add(new Material().setCode(MaterialCodeConstants.BIAN_GENG_SHOU_LI_TONG_ZHI_SHU).setCopy(0).setNum(1));
        logger.info("access rule: ?????????????");
        logger.info("$materialDecision = {}", JSON.toJSON($materialDecision.getMaterialResultList()));
end

rule "???????????????" extends "???????"
    when
        SearchDrools(
        $biangengqingkuang: contractData[TradeDataConstants.BIAN_GENG_QING_KUANG];
        $biangengqingkuang != null
        && (($biangengqingkuang instanceof String && $biangengqingkuang.equals("????"))
            || ($biangengqingkuang instanceof List && $biangengqingkuang contains "????"))
        )
    then
        logger.info("access rule: ???????????????");
        $materialDecision.getMaterialResultList().add(new Material().setCode(MaterialCodeConstants.JIA_FANG_HUN_YIN_ZHENG_MING).setCopy(0).setNum(1));
        logger.info("access rule: ?????????????????");
        logger.info("$materialDecision = {}", JSON.toJSON($materialDecision.getMaterialResultList()));
end
{code}

local? everything is ok
server? error message is belowing. but, when i restart server, everything is ok.


{panel:title=My title}
Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.RuntimeException: Error evaluating constraint '($biangengqingkuang instanceof String && $biangengqingkuang.equals("????")) || ($biangengqingkuang instanceof List && $biangengqingkuang contains "????")' in [Rule "???????????????" in BOOT-xxx.drl]] with root cause

java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Collection
	at ConditionEvaluator403561e24141452a9c4005ea91e84986.evaluate(Unknown Source)
	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:261)
	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:216)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:131)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1056)
	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1019)
	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1011)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1321)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1312)
	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1296)
	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:269)
	at com.zhhl.trade.service.impl.ContractMaterialDroolsServiceImpl.getMaterialResultBeanByDrools(ContractMaterialDroolsServiceImpl.java:85)
	at com.zhhl.trade.service.impl.ContractMaterialDroolsServiceImpl$$FastClassBySpringCGLIB$$3874772b.invoke(<generated>)
	at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
	at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:280)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
	at com.zhhl.trade.service.impl.ContractMaterialDroolsServiceImpl$$EnhancerBySpringCGLIB$$fb2491d0.getMaterialResultBeanByDrools(<generated>)
	at com.zhhl.trade.service.impl.ContractMaterialResultServiceImpl.computeMaterial(ContractMaterialResultServiceImpl.java:51)
	at com.zhhl.trade.service.impl.ContractMaterialResultServiceImpl.computeMaterial(ContractMaterialResultServiceImpl.java:80)
	at com.zhhl.trade.service.impl.ContractMaterialResultServiceImpl$$FastClassBySpringCGLIB$$e7a85f03.invoke(<generated>)
	at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
	at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:280)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
	at com.zhhl.trade.service.impl.ContractMaterialResultServiceImpl$$EnhancerBySpringCGLIB$$8423f058.computeMaterial(<generated>)
	at com.zhhl.trade.service.impl.ReservationServiceImpl.setExplanation(ReservationServiceImpl.java:486)
	at com.zhhl.trade.service.impl.ReservationServiceImpl.calcExplanation(ReservationServiceImpl.java:392)
	at com.zhhl.trade.service.impl.ReservationServiceImpl$$FastClassBySpringCGLIB$$84603545.invoke(<generated>)
	at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
	at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:280)
	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
	at com.zhhl.trade.service.impl.ReservationServiceImpl$$EnhancerBySpringCGLIB$$96fa6c5e.calcExplanation(<generated>)
	at com.zhhl.trade.controller.ReservationControllerV1.explanations(ReservationControllerV1.java:161)
	at sun.reflect.GeneratedMethodAccessor668.invoke(Unknown Source)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
	at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136)
	at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:114)
	at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827)
	at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738)
	at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
	at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:963)
	at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:897)
	at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
	at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:872)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
	at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
	at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.springframework.boot.web.filter.ApplicationContextHeaderFilter.doFilterInternal(ApplicationContextHeaderFilter.java:55)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:105)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:317)
	at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:127)
	at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:91)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:115)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:137)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:111)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:169)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:63)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.oauth2.provider.authentication.OAuth2AuthenticationProcessingFilter.doFilter(OAuth2AuthenticationProcessingFilter.java:176)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:121)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.header.HeaderWriterFilter.doFilterInternal(HeaderWriterFilter.java:66)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:105)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:56)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
	at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:214)
	at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:177)
	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
	at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.springframework.security.oauth2.client.filter.OAuth2ClientContextFilter.doFilter(OAuth2ClientContextFilter.java:60)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:87)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:77)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:197)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.springframework.boot.actuate.autoconfigure.MetricsFilter.doFilterInternal(MetricsFilter.java:106)
	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474)
	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:798)
	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434)
	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
	at java.lang.Thread.run(Thread.java:745)
{panel}







--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 22 04:52:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 22 Jan 2018 04:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.74756.1516614720532@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521799#comment-13521799 ] 

Matteo Mortari commented on DROOLS-2217:
----------------------------------------

This is a duplicate and was already fixed on master. [~jomarko] can you kindly check please, because I would close this JIRA accordingly.

> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 04:54:01 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 22 Jan 2018 04:54:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2215) [DMN Editor] Function
 Definition is not saved
In-Reply-To: <JIRA.12726675.1515133295000@Atlassian.JIRA>
References: <JIRA.12726675.1515133295000@Atlassian.JIRA>
	<JIRA.12726675.1515133295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726675.1515133295000.74779.1516614841002@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521803#comment-13521803 ] 

Matteo Mortari commented on DROOLS-2215:
----------------------------------------

As per https://github.com/kiegroup/kie-wb-common/pull/1338 this was solved within the oustanding work on [DROOLS-1959].

> [DMN Editor] Function Definition is not saved
> ---------------------------------------------
>
>                 Key: DROOLS-2215
>                 URL: https://issues.jboss.org/browse/DROOLS-2215
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 04:54:01 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 22 Jan 2018 04:54:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2215) [DMN Editor] Function
 Definition is not saved
In-Reply-To: <JIRA.12726675.1515133295000@Atlassian.JIRA>
References: <JIRA.12726675.1515133295000@Atlassian.JIRA>
	<JIRA.12726675.1515133295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726675.1515133295000.74801.1516614841583@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari resolved DROOLS-2215.
------------------------------------
    Resolution: Duplicate Issue


As per https://github.com/kiegroup/kie-wb-common/pull/1338 this was solved within the oustanding work on [DROOLS-1959].

> [DMN Editor] Function Definition is not saved
> ---------------------------------------------
>
>                 Key: DROOLS-2215
>                 URL: https://issues.jboss.org/browse/DROOLS-2215
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 04:56:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Mon, 22 Jan 2018 04:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2258) NullPointerException in
 TupleSetsImpl.setNextTuple when the right memory of a shared subnetwork
 contains more than one tuple
In-Reply-To: <JIRA.12730094.1516614912000@Atlassian.JIRA>
References: <JIRA.12730094.1516614912000@Atlassian.JIRA>
	<JIRA.12730094.1516614912097@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730094.1516614912000.74809.1516614960153@Atlassian.JIRA>

Mario Fusco created DROOLS-2258:
-----------------------------------

             Summary: NullPointerException in TupleSetsImpl.setNextTuple when the right memory of a shared subnetwork contains more than one tuple
                 Key: DROOLS-2258
                 URL: https://issues.jboss.org/browse/DROOLS-2258
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Mario Fusco
            Assignee: Mario Fusco






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 05:39:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 22 Jan 2018 05:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1493)
 java.util.concurrent.TimeoutException on slow machines
In-Reply-To: <JIRA.12730035.1516603287000@Atlassian.JIRA>
References: <JIRA.12730035.1516603287000@Atlassian.JIRA>
	<JIRA.12730035.1516603287000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730035.1516603287000.75108.1516617540593@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1493?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-1493:
-------------------------------

    Assignee: Jan Kalina


> java.util.concurrent.TimeoutException on slow machines
> ------------------------------------------------------
>
>                 Key: ELY-1493
>                 URL: https://issues.jboss.org/browse/ELY-1493
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>
> On solaris 10 (slow machine) there occured timeout for task task2Future.get(1, TimeUnit.SECONDS) on line 492. 
> Prolong timeout will probably reduce occurences. 
> {noformat}
> java.lang.RuntimeException: java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException
>          at  org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:459)
>          at  org.wildfly.security.credential.store.KeystorePasswordStoreTest.testParallelAccessToCS(KeystorePasswordStoreTest.java:439)
> Caused by: java.util.concurrent.ExecutionException: java.util.concurrent.TimeoutException
>         at java.base/java.util.concurrent.FutureTask.report(FutureTask.java:122)
>         at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:205)
>          at  org.wildfly.security.credential.store.KeystorePasswordStoreTest.testAccessFromMultipleCredentialStores(KeystorePasswordStoreTest.java:457)
>         ... 1 more
> Caused by: java.util.concurrent.TimeoutException
>         at java.base/java.util.concurrent.FutureTask.get(FutureTask.java:204)
>         at org.wildfly.security.credential.store.KeystorePasswordStoreTest$1.call(KeystorePasswordStoreTest.java:492)
>         at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
>         at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1167)
>         at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:641)
>         at java.base/java.lang.Thread.run(Thread.java:844)
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/40/jdk=java18_default,label=eap-sustaining&&solaris10&&sparc/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 05:55:00 2018
From: issues at jboss.org (pavan dittakavi (JIRA))
Date: Mon, 22 Jan 2018 05:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9714) Configuring Server cipher
 order in JBoss 7.1.0 AS
In-Reply-To: <JIRA.12730022.1516482348000@Atlassian.JIRA>
References: <JIRA.12730022.1516482348000@Atlassian.JIRA>
	<JIRA.12730022.1516482348000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730022.1516482348000.75203.1516618500365@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

pavan dittakavi updated WFLY-9714:
----------------------------------
    Security:     (was: Security Issue)


> Configuring Server cipher order in JBoss 7.1.0 AS 
> --------------------------------------------------
>
>                 Key: WFLY-9714
>                 URL: https://issues.jboss.org/browse/WFLY-9714
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: JBoss AS7 7.1.1.Final
>         Environment: All operating systems.
>            Reporter: pavan dittakavi
>            Assignee: Darran Lofthouse
>
> Hello Everyone, looks like the JBoss 7.1.0 AS Final version does not have an option to fix the cipher order that is determined by the server. In other words, the SSLHonorCipherOrder attribute does not work. 
> https://developer.jboss.org/thread/276787
> Request you to add this feature.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 06:00:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 22 Jan 2018 06:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2216) [DMN Editor] Decision Table
 Definition is not saved
In-Reply-To: <JIRA.12726676.1515133399000@Atlassian.JIRA>
References: <JIRA.12726676.1515133399000@Atlassian.JIRA>
	<JIRA.12726676.1515133399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726676.1515133399000.75208.1516618800326@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko resolved DROOLS-2216.
---------------------------------
    Resolution: Duplicate Issue


> [DMN Editor] Decision Table Definition is not saved
> ---------------------------------------------------
>
>                 Key: DROOLS-2216
>                 URL: https://issues.jboss.org/browse/DROOLS-2216
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 06:20:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 22 Jan 2018 06:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1494) SecurityException: JCE cannot
 authenticate the provider WildFlyElytron
In-Reply-To: <JIRA.12730037.1516604503000@Atlassian.JIRA>
References: <JIRA.12730037.1516604503000@Atlassian.JIRA>
	<JIRA.12730037.1516604503000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730037.1516604503000.75267.1516620000396@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521840#comment-13521840 ] 

Jan Kalina commented on ELY-1494:
---------------------------------

Less hacky way would to be ensure generating JAR, its signing and running JUnit tests against it - but I has not find way to do it by reasonable way yet...
(currently no signing, surefire runs tests against directory of classes, not against generated jar - jar is generated after tests run)

> SecurityException: JCE cannot authenticate the provider WildFlyElytron
> ----------------------------------------------------------------------
>
>                 Key: ELY-1494
>                 URL: https://issues.jboss.org/browse/ELY-1494
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>
> This happens on HP-UX in KeyStoreCredentialStoreTest. It probably related to ELY-1295 fix. Fix have to take HP-UX JDK in account as well.
>  
> Btw. Isn't there more elegant way how to enable tests for PKCS12. Necessary hack seems to be problematic.
> {noformat}
> java.lang.SecurityException: JCE cannot authenticate the provider WildFlyElytron
>         at javax.crypto.JceSecurity.getInstance(JceSecurity.java:118)
>         at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:244)
>         at  org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:117)
> Caused  by: java.lang.SecurityException: Cannot verify  jar:file:/hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes/!/
>         at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:448)
>         at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:363)
>         at javax.crypto.JarVerifier.verify(JarVerifier.java:289)
>         at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:164)
>         at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:190)
>         at javax.crypto.JceSecurity.getInstance(JceSecurity.java:114)
>         ... 2 more
> Caused  by: java.security.PrivilegedActionException:  java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:426)
>         ... 7 more
> Caused  by: java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
>         at java.util.zip.ZipFile.open(Native Method)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:225)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:155)
>         at java.util.jar.JarFile.<init>(JarFile.java:166)
>         at java.util.jar.JarFile.<init>(JarFile.java:103)
>         at javax.crypto.JarVerifier$2.run(JarVerifier.java:440)
>         at javax.crypto.JarVerifier$2.run(JarVerifier.java:427)
>         ... 9 more
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/40/jdk=jdk1.8_hpux,label=eap-sustaining&&hpux11v3/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 06:29:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 22 Jan 2018 06:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.75448.1516620540251@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2217:
--------------------------------
    Attachment: error.log


> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>         Attachments: error.log
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 06:30:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 22 Jan 2018 06:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.75454.1516620600377@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2217:
--------------------------------
    Steps to Reproduce: 
# Create new DMN diagram
# Add Decision node
# Open Decision node properties
# Configure this Decision node as Context Entry
# Save DMN diagram
# Reopen the DMN Diagram
# Check the Decision node properties
# The Decision node won't be configured as a Context Entry more
# Check server log, there will be:  [^error.log] 

  was:
# Create new DMN diagram
# Add Decision node
# Open Decision node properties
# Configure this Decision node as Context Entry
# Save DMN diagram
# Reopen the DMN Diagram
# Check the Decision node properties
# The Decision node won't be configured as a Context Entry more



> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>         Attachments: error.log
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 06:30:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 22 Jan 2018 06:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.75460.1516620600639@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2217:
--------------------------------
    Steps to Reproduce: 
# Create new DMN diagram
# Add Decision node
# Open Decision node properties
# Configure this Decision node as Context Entry
# Save DMN diagram
# Check server log, there will be:  [^error.log] 
# Reopen the DMN Diagram
# Check the Decision node properties
# The Decision node won't be configured as a Context Entry more

  was:
# Create new DMN diagram
# Add Decision node
# Open Decision node properties
# Configure this Decision node as Context Entry
# Save DMN diagram
# Reopen the DMN Diagram
# Check the Decision node properties
# The Decision node won't be configured as a Context Entry more
# Check server log, there will be:  [^error.log] 



> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>         Attachments: error.log
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 06:31:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 22 Jan 2018 06:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.75467.1516620660395@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521845#comment-13521845 ] 

Jozef Marko commented on DROOLS-2217:
-------------------------------------

[~tari_manga] Hi, I checked this with your latest changes done in DROOLS-1956, but this issue is still reproducible, I updated the steps for reproduce.

> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>         Attachments: error.log
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 06:33:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 22 Jan 2018 06:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2215) [DMN Editor] Function
 Definition is not saved
In-Reply-To: <JIRA.12726675.1515133295000@Atlassian.JIRA>
References: <JIRA.12726675.1515133295000@Atlassian.JIRA>
	<JIRA.12726675.1515133295000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726675.1515133295000.75477.1516620780164@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2215?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2215:
--------------------------------
    QE Status: VERIFIED  (was: ON_QA)


> [DMN Editor] Function Definition is not saved
> ---------------------------------------------
>
>                 Key: DROOLS-2215
>                 URL: https://issues.jboss.org/browse/DROOLS-2215
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 06:34:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 22 Jan 2018 06:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2216) [DMN Editor] Decision Table
 Definition is not saved
In-Reply-To: <JIRA.12726676.1515133399000@Atlassian.JIRA>
References: <JIRA.12726676.1515133399000@Atlassian.JIRA>
	<JIRA.12726676.1515133399000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726676.1515133399000.75480.1516620840321@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2216?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2216:
--------------------------------
    QE Status: VERIFIED  (was: ON_QA)


> [DMN Editor] Decision Table Definition is not saved
> ---------------------------------------------------
>
>                 Key: DROOLS-2216
>                 URL: https://issues.jboss.org/browse/DROOLS-2216
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 06:57:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 22 Jan 2018 06:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not
 clearing the crashed members
In-Reply-To: <JIRA.12729827.1516314140000@Atlassian.JIRA>
References: <JIRA.12729827.1516314140000@Atlassian.JIRA>
	<JIRA.12729827.1516314140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729827.1516314140000.75630.1516622220160@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2245:
---------------------------
    Fix Version/s: 4.0.10


> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
>                 Key: JGRP-2245
>                 URL: https://issues.jboss.org/browse/JGRP-2245
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.8
>            Reporter: Sibin Karnavar
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 4.0.10
>
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is 
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
>  // remove all files which are not from the current members
>     protected void handleView(View new_view, View old_view, boolean coord_changed) {
>         if(is_coord) {
>             if(coord_changed) {
>                 if(remove_all_data_on_view_change)
>                     removeAll(cluster_name);
>                 else if(remove_old_coords_on_view_change) {
>                     Address old_coord=old_view != null? old_view.getCreator() : null;
>                     if(old_coord != null)
>                         remove(cluster_name, old_coord);
>                 }
>             }
>             if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
>                 writeAll();
>                 if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
>                     startInfoWriter();
>             }
>         }
>         else if(coord_changed) // I'm no longer the coordinator
>             remove(cluster_name, local_addr);
>     }
> 4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 07:39:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 22 Jan 2018 07:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1492)
 java.nio.file.InvalidPathException: Illegal char ':' at krb5.conf
In-Reply-To: <JIRA.12730034.1516602709000@Atlassian.JIRA>
References: <JIRA.12730034.1516602709000@Atlassian.JIRA>
	<JIRA.12730034.1516602709000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730034.1516602709000.75878.1516624740941@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-1492:
-------------------------------

    Assignee: Jan Kalina


> java.nio.file.InvalidPathException: Illegal char ':' at krb5.conf
> -----------------------------------------------------------------
>
>                 Key: ELY-1492
>                 URL: https://issues.jboss.org/browse/ELY-1492
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>
> This occures in TS on JDK9 on Windows in tests:
> * org.wildfly.security.sasl.gssapi.CommunicationSuiteChild
> * org.wildfly.security.sasl.gs2.Gs2SuiteChild
> {noformat}
> javax.security.auth.login.LoginException: 
> java.nio.file.InvalidPathException: Illegal char <:> at index 2: /W:/workspace/wildfly-elytron-unit-tests/4ad7c91f/wildfly-elytron/target/test-classes/krb5.conf
> 	at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> 	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> 	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> 	at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
> 	at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
> 	at java.base/java.nio.file.Paths.get(Paths.java:84)
> 	at java.security.jgss/sun.security.krb5.Config.lambda$loadConfigFile$0(Config.java:639)
> 	at java.base/java.security.AccessController.doPrivileged(Native Method)
> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:429)
> 	at java.security.jgss/sun.security.krb5.Config.loadConfigFile(Config.java:638)
> 	at java.security.jgss/sun.security.krb5.Config.<init>(Config.java:176)
> 	at java.security.jgss/sun.security.krb5.Config.refresh(Config.java:115)
> 	at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:528)
> 	at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726)
> 	at java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
> 	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> 	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> 	at java.base/java.security.AccessController.doPrivileged(Native Method)
> 	at java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> 	at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.login(JaasUtil.java:71)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.loginClient(JaasUtil.java:53)
> 	at org.wildfly.security.sasl.gs2.Gs2SuiteChild.init(Gs2SuiteChild.java:102)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeClassMethod(JUnit4TestRunnerDecorator.java:92)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:30)
> 	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runners.Suite.runChild(Suite.java:128)
> 	at org.junit.runners.Suite.runChild(Suite.java:27)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> 	at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:821)
> 	at java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
> 	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> 	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> 	at java.base/java.security.AccessController.doPrivileged(Native Method)
> 	at java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> 	at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.login(JaasUtil.java:71)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.loginClient(JaasUtil.java:53)
> 	at org.wildfly.security.sasl.gs2.Gs2SuiteChild.init(Gs2SuiteChild.java:102)
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/41/jdk=jdk1.9,label=eap-sustaining&&w2k12r2&&x86_64/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 08:03:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 22 Jan 2018 08:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.76052.1516626180628@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2217:
--------------------------------
    Attachment: Screenshot from 2018-01-22 14-02-13.png
                Screenshot from 2018-01-22 14-01-38.png


> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>         Attachments: Screenshot from 2018-01-22 14-01-38.png, Screenshot from 2018-01-22 14-02-13.png, error.log
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 08:06:00 2018
From: issues at jboss.org (rokk ebol (JIRA))
Date: Mon, 22 Jan 2018 08:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2247) RPC does not invoke
 interface's default methods inherited
In-Reply-To: <JIRA.12730182.1516626311000@Atlassian.JIRA>
References: <JIRA.12730182.1516626311000@Atlassian.JIRA>
	<JIRA.12730182.1516626311818@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730182.1516626311000.76066.1516626360504@Atlassian.JIRA>

rokk ebol created JGRP-2247:
-------------------------------

             Summary: RPC does not invoke interface's default methods inherited
                 Key: JGRP-2247
                 URL: https://issues.jboss.org/browse/JGRP-2247
             Project: JGroups
          Issue Type: Feature Request
    Affects Versions: 4.0.8
         Environment: jgroups 4.0.8.Final

java version "1.8.0_151"
Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)

on win 10
            Reporter: rokk ebol
            Assignee: Bela Ban


org.jgroups.blocks.MethodCall#getAllMethods looks for methods up there in superclasses but not in interfaces, which can contain default methods since java 8



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 08:07:05 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 22 Jan 2018 08:07:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.76088.1516626425441@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2217:
--------------------------------
    Steps to Reproduce: 
# Create new DMN diagram
# Add Decision node
# Open Decision node properties
# Configure this Decision node as Context Entry
##  !Screenshot from 2018-01-22 14-01-38.png|thumbnail! 
# Save DMN diagram
# Check server log, there will be:  [^error.log] 
# Reopen the DMN Diagram
# Check the Decision node properties
# The Decision node won't be configured as a Context Entry more

Please notice that the issue is not reproducible if you use context entry shown as below:
 !Screenshot from 2018-01-22 14-02-13.png|thumbnail! 

  was:
# Create new DMN diagram
# Add Decision node
# Open Decision node properties
# Configure this Decision node as Context Entry
# Save DMN diagram
# Check server log, there will be:  [^error.log] 
# Reopen the DMN Diagram
# Check the Decision node properties
# The Decision node won't be configured as a Context Entry more



> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>         Attachments: Screenshot from 2018-01-22 14-01-38.png, Screenshot from 2018-01-22 14-02-13.png, error.log
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 08:12:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 22 Jan 2018 08:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.76106.1516626720339@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari reassigned DROOLS-2217:
--------------------------------------

    Assignee: Michael Anstis  (was: Matteo Mortari)


> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: Screenshot from 2018-01-22 14-01-38.png, Screenshot from 2018-01-22 14-02-13.png, error.log
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 08:13:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 22 Jan 2018 08:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.76116.1516626780514@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521906#comment-13521906 ] 

Matteo Mortari commented on DROOLS-2217:
----------------------------------------

As suggested I believe this should be handled from UI side with the policy discussed in the email thread. 
Hence reassigned.
If the suggestion is not feasible or not applicable, kindly to assign back. 

> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: Screenshot from 2018-01-22 14-01-38.png, Screenshot from 2018-01-22 14-02-13.png, error.log
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 08:25:05 2018
From: issues at jboss.org (Ingo Weiss (JIRA))
Date: Mon, 22 Jan 2018 08:25:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3450) CLI - avoid required
 attributes to be hard to see when using tab completion
In-Reply-To: <JIRA.12723673.1512545604000@Atlassian.JIRA>
References: <JIRA.12723673.1512545604000@Atlassian.JIRA>
	<JIRA.12723673.1512545604000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723673.1512545604000.76200.1516627505829@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3450?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ingo Weiss reassigned WFCORE-3450:
----------------------------------

    Assignee: Ingo Weiss  (was: Jean-Francois Denise)


> CLI - avoid required attributes to be hard to see when using tab completion 
> ----------------------------------------------------------------------------
>
>                 Key: WFCORE-3450
>                 URL: https://issues.jboss.org/browse/WFCORE-3450
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Miroslav Novak
>            Assignee: Ingo Weiss
>
> This is follow up for WFCORE-2283 which marked required attributes by "*" when using tab completion. Still if there are many attributes, it's hard to see all required attributes, for example in:
> {code}
> [standalone at localhost:9990 /] /subsystem=messaging-activemq/server=default/cluster-connection=my-cluster:add(
> !                              check-period                   connector-name*                max-retry-interval             notification-interval          retry-interval-multiplier
> allow-direct-connections-only  cluster-connection-address*    discovery-group*               message-load-balancing-type    producer-window-size           static-connectors*
> call-failover-timeout          confirmation-window-size       initial-connect-attempts       min-large-message-size         reconnect-attempts             use-duplicate-detection
> call-timeout                   connection-ttl                 max-hops                       notification-attempts          retry-interval  
> {code}
> it's not clear at the first look how many required attributes there are.
> Suggestion is to group required attributes together and then provide list of other attributes, for example on the next line. Another options might be considered as well. For example to show required attributes when double pressing <tab>.
> Discussed on https://developer.jboss.org/wiki/CLI-BetterCompletionForArguments?et=watches.email.document_comment#comment-16622 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 08:26:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 22 Jan 2018 08:26:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1494) SecurityException: JCE cannot
 authenticate the provider WildFlyElytron
In-Reply-To: <JIRA.12730037.1516604503000@Atlassian.JIRA>
References: <JIRA.12730037.1516604503000@Atlassian.JIRA>
	<JIRA.12730037.1516604503000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730037.1516604503000.76263.1516627561720@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-1494:
-------------------------------

    Assignee: Jan Kalina


> SecurityException: JCE cannot authenticate the provider WildFlyElytron
> ----------------------------------------------------------------------
>
>                 Key: ELY-1494
>                 URL: https://issues.jboss.org/browse/ELY-1494
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>
> This happens on HP-UX in KeyStoreCredentialStoreTest. It probably related to ELY-1295 fix. Fix have to take HP-UX JDK in account as well.
>  
> Btw. Isn't there more elegant way how to enable tests for PKCS12. Necessary hack seems to be problematic.
> {noformat}
> java.lang.SecurityException: JCE cannot authenticate the provider WildFlyElytron
>         at javax.crypto.JceSecurity.getInstance(JceSecurity.java:118)
>         at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:244)
>         at  org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:117)
> Caused  by: java.lang.SecurityException: Cannot verify  jar:file:/hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes/!/
>         at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:448)
>         at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:363)
>         at javax.crypto.JarVerifier.verify(JarVerifier.java:289)
>         at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:164)
>         at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:190)
>         at javax.crypto.JceSecurity.getInstance(JceSecurity.java:114)
>         ... 2 more
> Caused  by: java.security.PrivilegedActionException:  java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:426)
>         ... 7 more
> Caused  by: java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
>         at java.util.zip.ZipFile.open(Native Method)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:225)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:155)
>         at java.util.jar.JarFile.<init>(JarFile.java:166)
>         at java.util.jar.JarFile.<init>(JarFile.java:103)
>         at javax.crypto.JarVerifier$2.run(JarVerifier.java:440)
>         at javax.crypto.JarVerifier$2.run(JarVerifier.java:427)
>         ... 9 more
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/40/jdk=jdk1.8_hpux,label=eap-sustaining&&hpux11v3/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 08:31:00 2018
From: issues at jboss.org (Nuno Godinho de Matos (JIRA))
Date: Mon, 22 Jan 2018 08:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3387) MBeanServer - not returning
 ManagedBean jboss.as:deployment=* during deployment
In-Reply-To: <JIRA.12718435.1509098486000@Atlassian.JIRA>
References: <JIRA.12718435.1509098486000@Atlassian.JIRA>
	<JIRA.12718435.1509098486000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718435.1509098486000.76280.1516627860346@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521916#comment-13521916 ] 

Nuno Godinho de Matos commented on WFCORE-3387:
-----------------------------------------------

Hi Brian,

I would like to comment on your recommendation.
The approach to register the NotificationListener on "JMImplementation:type=MBeanServerDelegate" instead of "jboss.as:deployment=war-name.war"

works like a charm.

I am very sorry to only have given you feedback now, but I could not give priority to this problem.

Please close this Issue, the MBeanServerDelegate works perfectly.

Kindest regards.

> MBeanServer - not returning ManagedBean jboss.as:deployment=* during deployment
> -------------------------------------------------------------------------------
>
>                 Key: WFCORE-3387
>                 URL: https://issues.jboss.org/browse/WFCORE-3387
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 3.0.8.Final
>            Reporter: Nuno Godinho de Matos
>            Priority: Minor
>
> In wildfly, there is a class of managed beans that are particularly useful to have available during application deployment.
> In partocular beans with Object name (e.g. jboss.as:deployment=someapp-war.war)
> This type of beans can for example sned a JMX Notification that the corresponding application has been deployed.
> While trying to refactor a mechanism that fires an "ApplicationDeployed" event, a mechanism that was blinding registering a Listener on a hard coded ObjectName stopped working consistently once I generalized to hunt for the generalized beans.
> The problem is the following.
> 1. HARD CODED APPROACH:
> If when an application is deploying, during the @Startup logic of an EJB I blindly do something like:
> {panel}
>  MBeanServer mBeanServer = createMBeanServer();
>             ObjectName targetObject = new ObjectName(objectName);
>             mBeanServer.addNotificationListener(targetObject, listener, filter, handback);
> {panel}
> I can successfully register my Listener, without any problem.
> This will work 100% of the time, and after the deployment goes through I can send my notification to the application that the deployment is done.
> I just need to blindly register the listener on:
> jboss.as:deployment=someapp-war.war
> 2. PROBLEM - GENERALIZED APPORACH - QUERY MBEANS
> The Problem now is that once I try to generalize the mechanism, instead of directly doing something like jumping at the "registration", first I need to run a JMX query to hunt of beans:
> jboss.as:deployment=*
> Now I have the problem that I am coming out empty handed, no results.
> Better said, the current approach has two possible behaviors.
> Behavior 1 - Mechanism works:
> - Wildfly is stopped
> - on eclipse I drag and drop the WAR file to the APP server.
> - I start wildfly.
> In this case, the jboss.as:deployment=* will give me the deployed applications.
> The generic mechanism works.
> Behavior 2 - Query comes with no results
> - Wildfly is running
> - no deployments
> - I drag and drop the APP,
> then I get no results.
> Here is a Log snippet from the application when running on apporach 2.
> What you is multiple fluent wait queries.
> You have N tries loop where the query * and hard-coded object name is run. In both scenarios I get no results.
> But i still managed to register a listener If I want and I know the war name.
> {panel}
> ####2017-10-27 11:44:10,171 ThreadId:512 INFO  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,246 ThreadId:512 WARN  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,253 ThreadId:512 INFO  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,328 ThreadId:512 WARN  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,332 ThreadId:512 INFO  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,406 ThreadId:512 WARN  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,409 ThreadId:512 INFO  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,490 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,494 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,569 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,574 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,649 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,653 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,726 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,729 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,802 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,804 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,884 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,893 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,967 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,970 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,044 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,050 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,129 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,138 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,217 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,227 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,304 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,312 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,386 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,393 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,472 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,480 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,559 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,568 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,646 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,656 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,736 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,744 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,822 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,831 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,904 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,907 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,985 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - JMX Query to search for app deployments yielded: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - No WAR deployment could be found on the managed bean server. The applicatin runtimes that could be found were: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,992 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - Going to add notification listerner using HARD CODED deployment JMX object name <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,992 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Going to register a jmx notification listener on the status of the deployed application: jboss.as:deployment=someapp-war.war  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,994 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - Skipping registration of NotificationLister on WAR application runtime, managed bean could not be found.This has the implication that the application ready event will not be fired after the deployment completes.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,995 ThreadId:512 INFO  [WildflyJmxAppDeploymentNotificationListenerRegistration] - <- WildflyJmxAppDeploymentNotificationListenerRegistration.registerNotificationLister {2092 ms}  <LogContext:Facade> <ServerService Thread Pool -- 339>
> {panel}
> I can try to create a sample application to reproduce this.
> I would expect that before the @Startup logic is triggered on any EJB, I consistenly will have on the MBean server the deployment managemend bean for the WAR whose deployment is currently ongoing - regardless of whether I start the APP serer with the WAr already in or if I have just added the WAr file.
> And in effect, since the "registration mechanims of a listener always works - if you already know the WAR file name ... then it kind means that the Managed bean is in effect in the MBean serer but somehow not visible.
> Many thanks for any help on this.
> I will try to give you a sample application for analysis.
> Kindest regards.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 08:44:02 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Mon, 22 Jan 2018 08:44:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2233) DMN:
 time(date("2017-08-10")) should return 00:00:00z time
In-Reply-To: <JIRA.12727497.1515672063000@Atlassian.JIRA>
References: <JIRA.12727497.1515672063000@Atlassian.JIRA>
	<JIRA.12727497.1515672063000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727497.1515672063000.76412.1516628642005@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli updated DROOLS-2233:
----------------------------------
    Sprint: 2018 Week 03-04


> DMN: time(date("2017-08-10")) should return 00:00:00z time
> ----------------------------------------------------------
>
>                 Key: DROOLS-2233
>                 URL: https://issues.jboss.org/browse/DROOLS-2233
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Tibor Zim?nyi
>
> According to the specification in section "10.3.2.3.5 date": 
> "Where necessary, including the valuedt function (see 10.3.2.x.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00)."
> Currently the case time(date("2017-08-10")) returns null, because the evaluation ends with DateTimeException, because internally we represent dates as LocalDate class, which doesn't have time part. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 22 09:31:01 2018
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Mon, 22 Jan 2018 09:31:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1491) Initial Build Updates for Java
	10
In-Reply-To: <JIRA.12729515.1516200366000@Atlassian.JIRA>
References: <JIRA.12729515.1516200366000@Atlassian.JIRA>
	<JIRA.12729515.1516200366000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729515.1516200366000.76715.1516631461255@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1491?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tomaz Cerar resolved ELY-1491.
------------------------------
    Resolution: Done


> Initial Build Updates for Java 10
> ---------------------------------
>
>                 Key: ELY-1491
>                 URL: https://issues.jboss.org/browse/ELY-1491
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Build
>            Reporter: Darran Lofthouse
>            Assignee: Tomaz Cerar
>             Fix For: 1.2.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 09:34:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 22 Jan 2018 09:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1492)
 java.nio.file.InvalidPathException: Illegal char ':' at krb5.conf
In-Reply-To: <JIRA.12730034.1516602709000@Atlassian.JIRA>
References: <JIRA.12730034.1516602709000@Atlassian.JIRA>
	<JIRA.12730034.1516602709000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730034.1516602709000.76750.1516631640357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1492:
----------------------------
    Labels: tests windows  (was: )


> java.nio.file.InvalidPathException: Illegal char ':' at krb5.conf
> -----------------------------------------------------------------
>
>                 Key: ELY-1492
>                 URL: https://issues.jboss.org/browse/ELY-1492
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>              Labels: tests, windows
>
> This occures in TS on JDK9 on Windows in tests:
> * org.wildfly.security.sasl.gssapi.CommunicationSuiteChild
> * org.wildfly.security.sasl.gs2.Gs2SuiteChild
> {noformat}
> javax.security.auth.login.LoginException: 
> java.nio.file.InvalidPathException: Illegal char <:> at index 2: /W:/workspace/wildfly-elytron-unit-tests/4ad7c91f/wildfly-elytron/target/test-classes/krb5.conf
> 	at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
> 	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
> 	at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
> 	at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
> 	at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
> 	at java.base/java.nio.file.Paths.get(Paths.java:84)
> 	at java.security.jgss/sun.security.krb5.Config.lambda$loadConfigFile$0(Config.java:639)
> 	at java.base/java.security.AccessController.doPrivileged(Native Method)
> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:429)
> 	at java.security.jgss/sun.security.krb5.Config.loadConfigFile(Config.java:638)
> 	at java.security.jgss/sun.security.krb5.Config.<init>(Config.java:176)
> 	at java.security.jgss/sun.security.krb5.Config.refresh(Config.java:115)
> 	at jdk.security.auth/com.sun.security.auth.module.Krb5LoginModule.login(Krb5LoginModule.java:528)
> 	at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:726)
> 	at java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
> 	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> 	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> 	at java.base/java.security.AccessController.doPrivileged(Native Method)
> 	at java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> 	at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.login(JaasUtil.java:71)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.loginClient(JaasUtil.java:53)
> 	at org.wildfly.security.sasl.gs2.Gs2SuiteChild.init(Gs2SuiteChild.java:102)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:564)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeClassMethod(JUnit4TestRunnerDecorator.java:92)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:30)
> 	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:24)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runners.Suite.runChild(Suite.java:128)
> 	at org.junit.runners.Suite.runChild(Suite.java:27)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> 	at java.base/javax.security.auth.login.LoginContext.invoke(LoginContext.java:821)
> 	at java.base/javax.security.auth.login.LoginContext.access$000(LoginContext.java:194)
> 	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:665)
> 	at java.base/javax.security.auth.login.LoginContext$4.run(LoginContext.java:663)
> 	at java.base/java.security.AccessController.doPrivileged(Native Method)
> 	at java.base/javax.security.auth.login.LoginContext.invokePriv(LoginContext.java:663)
> 	at java.base/javax.security.auth.login.LoginContext.login(LoginContext.java:574)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.login(JaasUtil.java:71)
> 	at org.wildfly.security.sasl.gssapi.JaasUtil.loginClient(JaasUtil.java:53)
> 	at org.wildfly.security.sasl.gs2.Gs2SuiteChild.init(Gs2SuiteChild.java:102)
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/41/jdk=jdk1.9,label=eap-sustaining&&w2k12r2&&x86_64/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 09:34:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 22 Jan 2018 09:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1494) SecurityException: JCE cannot
 authenticate the provider WildFlyElytron
In-Reply-To: <JIRA.12730037.1516604503000@Atlassian.JIRA>
References: <JIRA.12730037.1516604503000@Atlassian.JIRA>
	<JIRA.12730037.1516604503000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730037.1516604503000.76761.1516631640654@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1494:
----------------------------
    Labels: hp-ux tests  (was: )


> SecurityException: JCE cannot authenticate the provider WildFlyElytron
> ----------------------------------------------------------------------
>
>                 Key: ELY-1494
>                 URL: https://issues.jboss.org/browse/ELY-1494
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>              Labels: hp-ux, tests
>
> This happens on HP-UX in KeyStoreCredentialStoreTest. It probably related to ELY-1295 fix. Fix have to take HP-UX JDK in account as well.
>  
> Btw. Isn't there more elegant way how to enable tests for PKCS12. Necessary hack seems to be problematic.
> {noformat}
> java.lang.SecurityException: JCE cannot authenticate the provider WildFlyElytron
>         at javax.crypto.JceSecurity.getInstance(JceSecurity.java:118)
>         at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:244)
>         at  org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:117)
> Caused  by: java.lang.SecurityException: Cannot verify  jar:file:/hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes/!/
>         at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:448)
>         at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:363)
>         at javax.crypto.JarVerifier.verify(JarVerifier.java:289)
>         at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:164)
>         at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:190)
>         at javax.crypto.JceSecurity.getInstance(JceSecurity.java:114)
>         ... 2 more
> Caused  by: java.security.PrivilegedActionException:  java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:426)
>         ... 7 more
> Caused  by: java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
>         at java.util.zip.ZipFile.open(Native Method)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:225)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:155)
>         at java.util.jar.JarFile.<init>(JarFile.java:166)
>         at java.util.jar.JarFile.<init>(JarFile.java:103)
>         at javax.crypto.JarVerifier$2.run(JarVerifier.java:440)
>         at javax.crypto.JarVerifier$2.run(JarVerifier.java:427)
>         ... 9 more
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/40/jdk=jdk1.8_hpux,label=eap-sustaining&&hpux11v3/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 09:49:00 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 22 Jan 2018 09:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9715) Upgrade Narayana to
	5.7.2.Final
In-Reply-To: <JIRA.12730201.1516632534000@Atlassian.JIRA>
References: <JIRA.12730201.1516632534000@Atlassian.JIRA>
	<JIRA.12730201.1516632534790@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730201.1516632534000.76902.1516632540616@Atlassian.JIRA>

Tom Jenkinson created WFLY-9715:
-----------------------------------

             Summary: Upgrade Narayana to 5.7.2.Final
                 Key: WFLY-9715
                 URL: https://issues.jboss.org/browse/WFLY-9715
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Transactions
            Reporter: Tom Jenkinson
            Assignee: Tom Jenkinson






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 09:50:01 2018
From: issues at jboss.org (Tom Jenkinson (JIRA))
Date: Mon, 22 Jan 2018 09:50:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9715) Upgrade Narayana to
	5.7.2.Final
In-Reply-To: <JIRA.12730201.1516632535000@Atlassian.JIRA>
References: <JIRA.12730201.1516632535000@Atlassian.JIRA>
	<JIRA.12730201.1516632535000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730201.1516632535000.76911.1516632601201@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9715?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tom Jenkinson closed WFLY-9715.
-------------------------------
    Resolution: Deferred


> Upgrade Narayana to 5.7.2.Final
> -------------------------------
>
>                 Key: WFLY-9715
>                 URL: https://issues.jboss.org/browse/WFLY-9715
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Transactions
>            Reporter: Tom Jenkinson
>            Assignee: Tom Jenkinson
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 09:56:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 22 Jan 2018 09:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Context Entry
 Definition is not saved
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.77021.1516632960927@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari reassigned DROOLS-2217:
--------------------------------------

    Assignee: Matteo Mortari  (was: Michael Anstis)


> [DMN Editor] Context Entry Definition is not saved
> --------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>         Attachments: Screenshot from 2018-01-22 14-01-38.png, Screenshot from 2018-01-22 14-02-13.png, error.log
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 10:00:00 2018
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Mon, 22 Jan 2018 10:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2259) Improve error message
 "Comparison operation requires compatible types." to clearly distingish
 between expected and resolved type.
In-Reply-To: <JIRA.12730205.1516633150000@Atlassian.JIRA>
References: <JIRA.12730205.1516633150000@Atlassian.JIRA>
	<JIRA.12730205.1516633150508@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730205.1516633150000.77112.1516633200971@Atlassian.JIRA>

Geoffrey De Smet created DROOLS-2259:
----------------------------------------

             Summary: Improve error message "Comparison operation requires compatible types." to clearly distingish between expected and resolved type.
                 Key: DROOLS-2259
                 URL: https://issues.jboss.org/browse/DROOLS-2259
             Project: Drools
          Issue Type: Enhancement
          Components: core engine
            Reporter: Geoffrey De Smet
            Assignee: Mario Fusco
            Priority: Minor


Exception in thread "AWT-EventQueue-0" java.lang.IllegalStateException: There are errors in a score DRL:
Error Messages:
Message [id=1, kieBase=defaultKieBase, level=ERROR, path=org/optaplanner/examples/cheaptime/solver/cheapTimeScoreRules.drl, line=-1, column=0
   text=Unable to Analyse Expression period > $lastActivePeriod:
[Error: Comparison operation requires compatible types. Found int and interface java.lang.Comparable]
[Near : {... period > $lastActivePeriod ....}]
                      ^]
                      
                      
This error message doesn't distingish between the 2 sides (left and right, input and output, up and down):                      
   Error: Comparison operation requires compatible types. Found int and interface java.lang.Comparable
Should be:
Error: Comparison operation requires compatible types with expected type (int) and resolved type (interface java.lang.Comparable).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 10:36:00 2018
From: issues at jboss.org (Mohamed DAOUDA (JIRA))
Date: Mon, 22 Jan 2018 10:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3594) Wildfly showing the war file
 status as Failed after restart the server
In-Reply-To: <JIRA.12545790.1404797136000@Atlassian.JIRA>
References: <JIRA.12545790.1404797136000@Atlassian.JIRA>
	<JIRA.12545790.1404797136000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545790.1404797136000.77368.1516635360838@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522030#comment-13522030 ] 

Mohamed DAOUDA commented on WFLY-3594:
--------------------------------------

i have the same issue. how did you solved this issue ?? 

> Wildfly showing the war file status as Failed after restart the server
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3594
>                 URL: https://issues.jboss.org/browse/WFLY-3594
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Final
>         Environment: windows server 2003 32 bit O.S,Java 7,flex, Apache axis web services
>            Reporter: shaik masthan
>            Assignee: Bartosz Baranowski
>            Priority: Minor
>              Labels: restarting
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> after successful deployment , war file status is deployed. When i restart the server , war files status is showing as failed. there were no errors in the logs  and i am able to access the the application without any problems.  
> After some time happen , again i restart the server this time war file status is deployed.  
> intermittently i am viewing this weird behavior with war files  w.r. t  restarting the server.
> let me know any workaround or fix for this.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 10:50:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 22 Jan 2018 10:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3387) MBeanServer - not returning
 ManagedBean jboss.as:deployment=* during deployment
In-Reply-To: <JIRA.12718435.1509098486000@Atlassian.JIRA>
References: <JIRA.12718435.1509098486000@Atlassian.JIRA>
	<JIRA.12718435.1509098486000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718435.1509098486000.77484.1516636200553@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3387:
-------------------------------------
    Workaround Description: 
Registering a listener with the MBeanServerDelegate to get notifications of additions and removals of mbeans:

https://docs.oracle.com/javase/8/docs/api/javax/management/MBeanServerDelegate.html#addNotificationListener-javax.management.NotificationListener-javax.management.NotificationFilter-java.lang.Object-

                Workaround: Workaround Exists


> MBeanServer - not returning ManagedBean jboss.as:deployment=* during deployment
> -------------------------------------------------------------------------------
>
>                 Key: WFCORE-3387
>                 URL: https://issues.jboss.org/browse/WFCORE-3387
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 3.0.8.Final
>            Reporter: Nuno Godinho de Matos
>            Priority: Minor
>
> In wildfly, there is a class of managed beans that are particularly useful to have available during application deployment.
> In partocular beans with Object name (e.g. jboss.as:deployment=someapp-war.war)
> This type of beans can for example sned a JMX Notification that the corresponding application has been deployed.
> While trying to refactor a mechanism that fires an "ApplicationDeployed" event, a mechanism that was blinding registering a Listener on a hard coded ObjectName stopped working consistently once I generalized to hunt for the generalized beans.
> The problem is the following.
> 1. HARD CODED APPROACH:
> If when an application is deploying, during the @Startup logic of an EJB I blindly do something like:
> {panel}
>  MBeanServer mBeanServer = createMBeanServer();
>             ObjectName targetObject = new ObjectName(objectName);
>             mBeanServer.addNotificationListener(targetObject, listener, filter, handback);
> {panel}
> I can successfully register my Listener, without any problem.
> This will work 100% of the time, and after the deployment goes through I can send my notification to the application that the deployment is done.
> I just need to blindly register the listener on:
> jboss.as:deployment=someapp-war.war
> 2. PROBLEM - GENERALIZED APPORACH - QUERY MBEANS
> The Problem now is that once I try to generalize the mechanism, instead of directly doing something like jumping at the "registration", first I need to run a JMX query to hunt of beans:
> jboss.as:deployment=*
> Now I have the problem that I am coming out empty handed, no results.
> Better said, the current approach has two possible behaviors.
> Behavior 1 - Mechanism works:
> - Wildfly is stopped
> - on eclipse I drag and drop the WAR file to the APP server.
> - I start wildfly.
> In this case, the jboss.as:deployment=* will give me the deployed applications.
> The generic mechanism works.
> Behavior 2 - Query comes with no results
> - Wildfly is running
> - no deployments
> - I drag and drop the APP,
> then I get no results.
> Here is a Log snippet from the application when running on apporach 2.
> What you is multiple fluent wait queries.
> You have N tries loop where the query * and hard-coded object name is run. In both scenarios I get no results.
> But i still managed to register a listener If I want and I know the war name.
> {panel}
> ####2017-10-27 11:44:10,171 ThreadId:512 INFO  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,246 ThreadId:512 WARN  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,253 ThreadId:512 INFO  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,328 ThreadId:512 WARN  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,332 ThreadId:512 INFO  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,406 ThreadId:512 WARN  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,409 ThreadId:512 INFO  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,490 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,494 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,569 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,574 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,649 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,653 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,726 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,729 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,802 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,804 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,884 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,893 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,967 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,970 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,044 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,050 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,129 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,138 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,217 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,227 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,304 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,312 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,386 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,393 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,472 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,480 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,559 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,568 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,646 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,656 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,736 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,744 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,822 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,831 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,904 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,907 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,985 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - JMX Query to search for app deployments yielded: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - No WAR deployment could be found on the managed bean server. The applicatin runtimes that could be found were: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,992 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - Going to add notification listerner using HARD CODED deployment JMX object name <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,992 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Going to register a jmx notification listener on the status of the deployed application: jboss.as:deployment=someapp-war.war  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,994 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - Skipping registration of NotificationLister on WAR application runtime, managed bean could not be found.This has the implication that the application ready event will not be fired after the deployment completes.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,995 ThreadId:512 INFO  [WildflyJmxAppDeploymentNotificationListenerRegistration] - <- WildflyJmxAppDeploymentNotificationListenerRegistration.registerNotificationLister {2092 ms}  <LogContext:Facade> <ServerService Thread Pool -- 339>
> {panel}
> I can try to create a sample application to reproduce this.
> I would expect that before the @Startup logic is triggered on any EJB, I consistenly will have on the MBean server the deployment managemend bean for the WAR whose deployment is currently ongoing - regardless of whether I start the APP serer with the WAr already in or if I have just added the WAr file.
> And in effect, since the "registration mechanims of a listener always works - if you already know the WAR file name ... then it kind means that the Managed bean is in effect in the MBean serer but somehow not visible.
> Many thanks for any help on this.
> I will try to give you a sample application for analysis.
> Kindest regards.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 10:52:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 22 Jan 2018 10:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3387) MBeanServer - not returning
 ManagedBean jboss.as:deployment=* during deployment
In-Reply-To: <JIRA.12718435.1509098486000@Atlassian.JIRA>
References: <JIRA.12718435.1509098486000@Atlassian.JIRA>
	<JIRA.12718435.1509098486000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718435.1509098486000.77505.1516636320386@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFCORE-3387.
--------------------------------------
      Assignee: Brian Stansberry
    Resolution: Won't Fix


That's great! Thanks for the feedback, and it's fine you took your time. I've had plenty to do in the meantime. :)

> MBeanServer - not returning ManagedBean jboss.as:deployment=* during deployment
> -------------------------------------------------------------------------------
>
>                 Key: WFCORE-3387
>                 URL: https://issues.jboss.org/browse/WFCORE-3387
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: JMX
>    Affects Versions: 3.0.8.Final
>            Reporter: Nuno Godinho de Matos
>            Assignee: Brian Stansberry
>            Priority: Minor
>
> In wildfly, there is a class of managed beans that are particularly useful to have available during application deployment.
> In partocular beans with Object name (e.g. jboss.as:deployment=someapp-war.war)
> This type of beans can for example sned a JMX Notification that the corresponding application has been deployed.
> While trying to refactor a mechanism that fires an "ApplicationDeployed" event, a mechanism that was blinding registering a Listener on a hard coded ObjectName stopped working consistently once I generalized to hunt for the generalized beans.
> The problem is the following.
> 1. HARD CODED APPROACH:
> If when an application is deploying, during the @Startup logic of an EJB I blindly do something like:
> {panel}
>  MBeanServer mBeanServer = createMBeanServer();
>             ObjectName targetObject = new ObjectName(objectName);
>             mBeanServer.addNotificationListener(targetObject, listener, filter, handback);
> {panel}
> I can successfully register my Listener, without any problem.
> This will work 100% of the time, and after the deployment goes through I can send my notification to the application that the deployment is done.
> I just need to blindly register the listener on:
> jboss.as:deployment=someapp-war.war
> 2. PROBLEM - GENERALIZED APPORACH - QUERY MBEANS
> The Problem now is that once I try to generalize the mechanism, instead of directly doing something like jumping at the "registration", first I need to run a JMX query to hunt of beans:
> jboss.as:deployment=*
> Now I have the problem that I am coming out empty handed, no results.
> Better said, the current approach has two possible behaviors.
> Behavior 1 - Mechanism works:
> - Wildfly is stopped
> - on eclipse I drag and drop the WAR file to the APP server.
> - I start wildfly.
> In this case, the jboss.as:deployment=* will give me the deployed applications.
> The generic mechanism works.
> Behavior 2 - Query comes with no results
> - Wildfly is running
> - no deployments
> - I drag and drop the APP,
> then I get no results.
> Here is a Log snippet from the application when running on apporach 2.
> What you is multiple fluent wait queries.
> You have N tries loop where the query * and hard-coded object name is run. In both scenarios I get no results.
> But i still managed to register a listener If I want and I know the war name.
> {panel}
> ####2017-10-27 11:44:10,171 ThreadId:512 INFO  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,246 ThreadId:512 WARN  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,253 ThreadId:512 INFO  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,328 ThreadId:512 WARN  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,332 ThreadId:512 INFO  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,406 ThreadId:512 WARN  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,409 ThreadId:512 INFO  [logger: .impl.jmx.AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,490 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,494 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,569 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,574 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,649 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,653 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,726 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,729 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,802 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,804 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,884 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,893 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,967 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:10,970 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,044 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,050 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,129 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,138 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,217 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,227 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,304 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,312 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,386 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,393 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,472 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,480 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,559 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,568 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,646 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,656 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,736 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,744 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,822 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,831 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,904 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,907 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,985 ThreadId:512 WARN  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Query jmx query: jboss.as:deployment=* yielded no results.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Using HARD_CODED_DIRTY_QUERY: jboss.as:deployment=someapp-war.war -  returned: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - JMX Query to search for app deployments yielded: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,991 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - No WAR deployment could be found on the managed bean server. The applicatin runtimes that could be found were: []  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,992 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - Going to add notification listerner using HARD CODED deployment JMX object name <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,992 ThreadId:512 INFO  [AbstractJmxAppDeploymentNotificationListenerRegistration] - Going to register a jmx notification listener on the status of the deployed application: jboss.as:deployment=someapp-war.war  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,994 ThreadId:512 ERROR [AbstractJmxAppDeploymentNotificationListenerRegistration] - Skipping registration of NotificationLister on WAR application runtime, managed bean could not be found.This has the implication that the application ready event will not be fired after the deployment completes.  <LogContext:Facade> <ServerService Thread Pool -- 339>
> ####2017-10-27 11:44:11,995 ThreadId:512 INFO  [WildflyJmxAppDeploymentNotificationListenerRegistration] - <- WildflyJmxAppDeploymentNotificationListenerRegistration.registerNotificationLister {2092 ms}  <LogContext:Facade> <ServerService Thread Pool -- 339>
> {panel}
> I can try to create a sample application to reproduce this.
> I would expect that before the @Startup logic is triggered on any EJB, I consistenly will have on the MBean server the deployment managemend bean for the WAR whose deployment is currently ongoing - regardless of whether I start the APP serer with the WAr already in or if I have just added the WAr file.
> And in effect, since the "registration mechanims of a listener always works - if you already know the WAR file name ... then it kind means that the Managed bean is in effect in the MBean serer but somehow not visible.
> Many thanks for any help on this.
> I will try to give you a sample application for analysis.
> Kindest regards.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 11:04:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 22 Jan 2018 11:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2007) [Test Scenario] Upgrade UI
 to gwt-bootstrap-3 components
In-Reply-To: <JIRA.12710256.1504637241000@Atlassian.JIRA>
References: <JIRA.12710256.1504637241000@Atlassian.JIRA>
	<JIRA.12710256.1504637241000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12710256.1504637241000.77594.1516637040081@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2007?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko closed DROOLS-2007.
-------------------------------
    Resolution: Out of Date


> [Test Scenario] Upgrade UI to gwt-bootstrap-3 components
> --------------------------------------------------------
>
>                 Key: DROOLS-2007
>                 URL: https://issues.jboss.org/browse/DROOLS-2007
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Test Scenarios Editor
>    Affects Versions: 7.2.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 11:22:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Mon, 22 Jan 2018 11:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2247) RPC does not invoke
 interface's default methods inherited
In-Reply-To: <JIRA.12730182.1516626312000@Atlassian.JIRA>
References: <JIRA.12730182.1516626312000@Atlassian.JIRA>
	<JIRA.12730182.1516626312000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730182.1516626312000.77748.1516638120540@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2247:
---------------------------
    Fix Version/s: 4.0.10


> RPC does not invoke interface's default methods inherited
> ---------------------------------------------------------
>
>                 Key: JGRP-2247
>                 URL: https://issues.jboss.org/browse/JGRP-2247
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 4.0.8
>         Environment: jgroups 4.0.8.Final
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
> on win 10
>            Reporter: rokk ebol
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> org.jgroups.blocks.MethodCall#getAllMethods looks for methods up there in superclasses but not in interfaces, which can contain default methods since java 8



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 11:39:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 22 Jan 2018 11:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1494) SecurityException: JCE cannot
 authenticate the provider WildFlyElytron
In-Reply-To: <JIRA.12730037.1516604503000@Atlassian.JIRA>
References: <JIRA.12730037.1516604503000@Atlassian.JIRA>
	<JIRA.12730037.1516604503000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730037.1516604503000.77838.1516639140244@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522084#comment-13522084 ] 

Jan Kalina commented on ELY-1494:
---------------------------------

It would be necessary to prepare similar workaround like for IBM and Oracle already exists.
However, this workaround is not already needed for Oracle in latest versions (of JKD 8 and JDK 9 too), and it si not sufficient for IBM JDK (where the custom data storing in PKCS12 is not possible at all).

As it looks this workaround is a relic of the past, I dont see reasonable to port it to another JDK and I will remove it at all.

> SecurityException: JCE cannot authenticate the provider WildFlyElytron
> ----------------------------------------------------------------------
>
>                 Key: ELY-1494
>                 URL: https://issues.jboss.org/browse/ELY-1494
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>              Labels: hp-ux, tests
>
> This happens on HP-UX in KeyStoreCredentialStoreTest. It probably related to ELY-1295 fix. Fix have to take HP-UX JDK in account as well.
>  
> Btw. Isn't there more elegant way how to enable tests for PKCS12. Necessary hack seems to be problematic.
> {noformat}
> java.lang.SecurityException: JCE cannot authenticate the provider WildFlyElytron
>         at javax.crypto.JceSecurity.getInstance(JceSecurity.java:118)
>         at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:244)
>         at  org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:117)
> Caused  by: java.lang.SecurityException: Cannot verify  jar:file:/hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes/!/
>         at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:448)
>         at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:363)
>         at javax.crypto.JarVerifier.verify(JarVerifier.java:289)
>         at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:164)
>         at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:190)
>         at javax.crypto.JceSecurity.getInstance(JceSecurity.java:114)
>         ... 2 more
> Caused  by: java.security.PrivilegedActionException:  java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:426)
>         ... 7 more
> Caused  by: java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
>         at java.util.zip.ZipFile.open(Native Method)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:225)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:155)
>         at java.util.jar.JarFile.<init>(JarFile.java:166)
>         at java.util.jar.JarFile.<init>(JarFile.java:103)
>         at javax.crypto.JarVerifier$2.run(JarVerifier.java:440)
>         at javax.crypto.JarVerifier$2.run(JarVerifier.java:427)
>         ... 9 more
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/40/jdk=jdk1.8_hpux,label=eap-sustaining&&hpux11v3/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 11:40:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 22 Jan 2018 11:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1494) SecurityException: JCE cannot
 authenticate the provider WildFlyElytron
In-Reply-To: <JIRA.12730037.1516604503000@Atlassian.JIRA>
References: <JIRA.12730037.1516604503000@Atlassian.JIRA>
	<JIRA.12730037.1516604503000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730037.1516604503000.77849.1516639200616@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1494?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522084#comment-13522084 ] 

Jan Kalina edited comment on ELY-1494 at 1/22/18 11:39 AM:
-----------------------------------------------------------

It would be necessary to prepare similar workaround like for IBM and Oracle already exists. (ELY-926)
However, this workaround is not already needed for Oracle in latest versions (of JKD 8 and JDK 9 too), and it si not sufficient for IBM JDK (where the custom data storing in PKCS12 is not possible at all).

As it looks this workaround is a relic of the past, I dont see reasonable to port it to another JDK and I will remove it at all.


was (Author: honza889):
It would be necessary to prepare similar workaround like for IBM and Oracle already exists.
However, this workaround is not already needed for Oracle in latest versions (of JKD 8 and JDK 9 too), and it si not sufficient for IBM JDK (where the custom data storing in PKCS12 is not possible at all).

As it looks this workaround is a relic of the past, I dont see reasonable to port it to another JDK and I will remove it at all.

> SecurityException: JCE cannot authenticate the provider WildFlyElytron
> ----------------------------------------------------------------------
>
>                 Key: ELY-1494
>                 URL: https://issues.jboss.org/browse/ELY-1494
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>              Labels: hp-ux, tests
>
> This happens on HP-UX in KeyStoreCredentialStoreTest. It probably related to ELY-1295 fix. Fix have to take HP-UX JDK in account as well.
>  
> Btw. Isn't there more elegant way how to enable tests for PKCS12. Necessary hack seems to be problematic.
> {noformat}
> java.lang.SecurityException: JCE cannot authenticate the provider WildFlyElytron
>         at javax.crypto.JceSecurity.getInstance(JceSecurity.java:118)
>         at javax.crypto.SecretKeyFactory.getInstance(SecretKeyFactory.java:244)
>         at  org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:117)
> Caused  by: java.lang.SecurityException: Cannot verify  jar:file:/hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes/!/
>         at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:448)
>         at javax.crypto.JarVerifier.verifyJars(JarVerifier.java:363)
>         at javax.crypto.JarVerifier.verify(JarVerifier.java:289)
>         at javax.crypto.JceSecurity.verifyProviderJar(JceSecurity.java:164)
>         at javax.crypto.JceSecurity.getVerificationResult(JceSecurity.java:190)
>         at javax.crypto.JceSecurity.getInstance(JceSecurity.java:114)
>         ... 2 more
> Caused  by: java.security.PrivilegedActionException:  java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
>         at java.security.AccessController.doPrivileged(Native Method)
>         at javax.crypto.JarVerifier.verifySingleJar(JarVerifier.java:426)
>         ... 7 more
> Caused  by: java.io.FileNotFoundException:  /hudson_workspace/workspace/wildfly-elytron-unit-tests/8cc93d85/wildfly-elytron/target/classes  (Is a directory)
>         at java.util.zip.ZipFile.open(Native Method)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:225)
>         at java.util.zip.ZipFile.<init>(ZipFile.java:155)
>         at java.util.jar.JarFile.<init>(JarFile.java:166)
>         at java.util.jar.JarFile.<init>(JarFile.java:103)
>         at javax.crypto.JarVerifier$2.run(JarVerifier.java:440)
>         at javax.crypto.JarVerifier$2.run(JarVerifier.java:427)
>         ... 9 more
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/40/jdk=jdk1.8_hpux,label=eap-sustaining&&hpux11v3/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 12:38:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 22 Jan 2018 12:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3531)
 EnumValidator.validateParameter should check toStringMap first to reduce
 the times of IllegalArgumentException creation
In-Reply-To: <JIRA.12730040.1516606001000@Atlassian.JIRA>
References: <JIRA.12730040.1516606001000@Atlassian.JIRA>
	<JIRA.12730040.1516606001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730040.1516606001000.78164.1516642680630@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3531:
-------------------------------------
    Issue Type: Enhancement  (was: Bug)


> EnumValidator.validateParameter should check toStringMap first to reduce the times of IllegalArgumentException creation
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3531
>                 URL: https://issues.jboss.org/browse/WFCORE-3531
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, JMX
>         Environment: JBoss EAP 6.4.16,6.4.18
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>              Labels: downstream_dependency, performace
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> {panel:title=Description of downstream issue}
> 1. Proposed title of this feature request
> Enum is misspelled causing java.lang.IllegalArgumentException 
> 2. Who is the customer behind the request?
> Account: Hamburg S?damerikanische Dampfschifffahrts-Ge, 5651756 
> 3. What is the nature and description of the request?
> Enum is misspelled causing java.lang.IllegalArgumentException 
> 5. How would the customer like to achieve this? (List the functional requirements here)
> In such way, it should not throw Exception and spelled correctly.
> ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
> Location Where Enum is Used :
> jboss-as-jmx module:
> ./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java
> Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());
> it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.
> Stacktrace Attached.
> {panel}
> ----
> {panel:title=Description}
> +EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.
> However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.
> {panel}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 22 12:42:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 22 Jan 2018 12:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9126) Deployment fails when
 application domain names referrencing one Elytron domain are different in
 Undertow and EJB subsystems
In-Reply-To: <JIRA.12704556.1500980695000@Atlassian.JIRA>
References: <JIRA.12704556.1500980695000@Atlassian.JIRA>
	<JIRA.12704556.1500980695000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12704556.1500980695000.78191.1516642920736@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9126?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed WFLY-9126.
----------------------------
    Resolution: Rejected


> Deployment fails when application domain names referrencing one Elytron domain are different in Undertow and EJB subsystems
> ---------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9126
>                 URL: https://issues.jboss.org/browse/WFLY-9126
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB, Security, Web (Undertow)
>            Reporter: Josef Cacek
>            Assignee: Jan Kalina
>            Priority: Critical
>
> The WAR deployment fails when it contains EJBs and Servlets with security domains mapped under different names (application-security-domain). The underlying Elytron domain is the same for both subsystems.
> EJB subsystem tries to search also for the domain name which is used in {{jboss-web.xml}} and this lookup fails.
> Sample configuration:
> {code:xml|title=jboss-ejb3.xml}
> <jboss:ejb-jar>
> 	<assembly-descriptor><s:security>
> 		<ejb-name>*</ejb-name>
> 		<s:security-domain>seccontext-whoami</s:security-domain>
> 	</s:security></assembly-descriptor>
> </jboss:ejb-jar>
> {code}
> {code:xml|title=jboss-web.xml}
> <jboss-web>
> 	<security-domain>seccontext-web</security-domain>
> </jboss-web>
> {code}
> {code:title=application-security-domain-mapping.cli}
> /subsystem=ejb3/application-security-domain=seccontext-whoami:add( \
>     security-domain=ApplicationDomain)
> /subsystem=undertow/application-security-domain=seccontext-web:add( \
>     http-authentication-factory=application-http-authentication)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 13:26:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 22 Jan 2018 13:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3532) Add JSON formatter
 resources to the logging subsystem
In-Reply-To: <JIRA.12730257.1516645559000@Atlassian.JIRA>
References: <JIRA.12730257.1516645559000@Atlassian.JIRA>
	<JIRA.12730257.1516645559328@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730257.1516645559000.78380.1516645560525@Atlassian.JIRA>

James Perkins created WFCORE-3532:
-------------------------------------

             Summary: Add JSON formatter resources to the logging subsystem
                 Key: WFCORE-3532
                 URL: https://issues.jboss.org/browse/WFCORE-3532
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
             Fix For: 4.0.0.Beta1


The logging subsystem should include resources for a {{json-formatter}} -and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires-.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 13:27:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 22 Jan 2018 13:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9716) Integrate KUBE_PING discovery
	protocol
In-Reply-To: <JIRA.12730258.1516645582000@Atlassian.JIRA>
References: <JIRA.12730258.1516645582000@Atlassian.JIRA>
	<JIRA.12730258.1516645582107@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730258.1516645582000.78384.1516645620204@Atlassian.JIRA>

Paul Ferraro created WFLY-9716:
----------------------------------

             Summary: Integrate KUBE_PING discovery protocol
                 Key: WFLY-9716
                 URL: https://issues.jboss.org/browse/WFLY-9716
             Project: WildFly
          Issue Type: Feature Request
          Components: Clustering
    Affects Versions: 11.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Radoslav Husar
             Fix For: 12.0.0.Alpha1


https://github.com/jgroups-extras/jgroups-kubernetes



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 13:29:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 22 Jan 2018 13:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3533) Add a socket-handler
 resource to the logging subsystem
In-Reply-To: <JIRA.12730260.1516645711000@Atlassian.JIRA>
References: <JIRA.12730260.1516645711000@Atlassian.JIRA>
	<JIRA.12730260.1516645711168@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730260.1516645711000.78398.1516645740131@Atlassian.JIRA>

James Perkins created WFCORE-3533:
-------------------------------------

             Summary: Add a socket-handler resource to the logging subsystem
                 Key: WFCORE-3533
                 URL: https://issues.jboss.org/browse/WFCORE-3533
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
             Fix For: 4.0.0.Beta1


The logging subsystem should include a resource for a {{socket-handler}}. This will be useful for structured formatters, such as the [{{json-formatter}}|WFCORE-2951].



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 13:31:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 22 Jan 2018 13:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3534) Add an XML formatter
 resources to the logging subsystem
In-Reply-To: <JIRA.12730261.1516645857000@Atlassian.JIRA>
References: <JIRA.12730261.1516645857000@Atlassian.JIRA>
	<JIRA.12730261.1516645857720@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730261.1516645857000.78414.1516645860464@Atlassian.JIRA>

James Perkins created WFCORE-3534:
-------------------------------------

             Summary: Add an XML formatter resources to the logging subsystem
                 Key: WFCORE-3534
                 URL: https://issues.jboss.org/browse/WFCORE-3534
             Project: WildFly Core
          Issue Type: Feature Request
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins
             Fix For: 4.0.0.Beta1


The logging subsystem should include a resource for a {{xml-formatter}}.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 13:34:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 22 Jan 2018 13:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9717) Integrate NATIVE_S3_PING
 discovery protocol
In-Reply-To: <JIRA.12730262.1516646009000@Atlassian.JIRA>
References: <JIRA.12730262.1516646009000@Atlassian.JIRA>
	<JIRA.12730262.1516646009016@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730262.1516646009000.78423.1516646040212@Atlassian.JIRA>

Paul Ferraro created WFLY-9717:
----------------------------------

             Summary: Integrate NATIVE_S3_PING discovery protocol
                 Key: WFLY-9717
                 URL: https://issues.jboss.org/browse/WFLY-9717
             Project: WildFly
          Issue Type: Feature Request
          Components: Clustering
    Affects Versions: 11.0.0.Alpha1
            Reporter: Paul Ferraro
            Assignee: Radoslav Husar


The original S3_PING is being deprecated given how low quality the code is.

Going forward, we need to integrate NATIVE_S3_PING from https://github.com/jgroups-extras/native-s3-ping to keep supporting EC2-specific discovery mechanism.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 13:35:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Mon, 22 Jan 2018 13:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9718) Integrate GOOGLE_PING2
	discovery protocol
In-Reply-To: <JIRA.12730263.1516646047000@Atlassian.JIRA>
References: <JIRA.12730263.1516646047000@Atlassian.JIRA>
	<JIRA.12730263.1516646047170@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730263.1516646047000.78429.1516646100195@Atlassian.JIRA>

Paul Ferraro created WFLY-9718:
----------------------------------

             Summary: Integrate GOOGLE_PING2 discovery protocol
                 Key: WFLY-9718
                 URL: https://issues.jboss.org/browse/WFLY-9718
             Project: WildFly
          Issue Type: Feature Request
          Components: Clustering
    Affects Versions: 11.0.0.Alpha1
            Reporter: Paul Ferraro
            Assignee: Radoslav Husar


The original GOOGLE_PING is being deprecated given how low quality the code is.

Going forward, we need to integrate https://github.com/jgroups-extras/jgroups-google to keep supporting Google Cloud Platform-specific discovery mechanism.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 13:55:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Mon, 22 Jan 2018 13:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2951) Add JSON formatter
 resources to the logging subsystem
In-Reply-To: <JIRA.12697304.1497373185000@Atlassian.JIRA>
References: <JIRA.12697304.1497373185000@Atlassian.JIRA>
	<JIRA.12697304.1497373185000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12697304.1497373185000.78541.1516647300231@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-2951?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522137#comment-13522137 ] 

Brian Stansberry commented on WFCORE-2951:
------------------------------------------

I think the analysis of this should make how it's going to be used on OpenShift a first class concern. We're now responsible for our OS images, and our images already have things in place related to this.[1] Features whose use cases are heavily cloud-driven are going to need to start factoring the use on OS into the plan.

[1] See https://github.com/jboss-openshift/cct_module/blob/master/os-eap71-openshift/added/standalone-openshift.xml#L111 and also https://issues.jboss.org/browse/CLOUD-1517 and the key PR for that, https://github.com/jboss-openshift/cct_module/pull/99/files

> Add JSON formatter resources to the logging subsystem
> -----------------------------------------------------
>
>                 Key: WFCORE-2951
>                 URL: https://issues.jboss.org/browse/WFCORE-2951
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>             Fix For: 4.0.0.Beta1
>
>
> The logging subsystem should include resources for a {{json-formatter}} -and probably a {{logstash-formatter}}. The {{logstash-formatter}} is likely just an extension of the {{json-formatter}} with some predefined attributes that logstash requires-.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 14:02:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 22 Jan 2018 14:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Allow DMN
 persistence for an incomplete, still being authored, DMN model
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.78566.1516647720564@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Matteo Mortari updated DROOLS-2217:
-----------------------------------
    Summary: [DMN Editor] Allow DMN persistence for an incomplete, still being authored, DMN model  (was: [DMN Editor] Context Entry Definition is not saved)


> [DMN Editor] Allow DMN persistence for an incomplete, still being authored, DMN model
> -------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>         Attachments: Screenshot from 2018-01-22 14-01-38.png, Screenshot from 2018-01-22 14-02-13.png, error.log
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 14:03:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 22 Jan 2018 14:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Allow DMN
 persistence for an incomplete, still being authored, DMN model
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.78570.1516647780242@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522141#comment-13522141 ] 

Matteo Mortari commented on DROOLS-2217:
----------------------------------------

This JIRA can be considered a special case for more generally allowing DMN persistence for an incomplete, still being authored, DMN model.
JIRA renamed accordingly.

> [DMN Editor] Allow DMN persistence for an incomplete, still being authored, DMN model
> -------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>         Attachments: Screenshot from 2018-01-22 14-01-38.png, Screenshot from 2018-01-22 14-02-13.png, error.log
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 14:05:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 22 Jan 2018 14:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Allow DMN
 persistence for an incomplete, still being authored, DMN model
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.78581.1516647900488@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522142#comment-13522142 ] 

Matteo Mortari commented on DROOLS-2217:
----------------------------------------

with the premise than from XSD and the spec:
- a context entry must have a "value", being an expression

on DMN side:
consider a LiteralExpression with "text" being null, as a special case representing a missing expression altogether

on Stunner side:
use null to represent missing expression, when there should be one

> [DMN Editor] Allow DMN persistence for an incomplete, still being authored, DMN model
> -------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>         Attachments: Screenshot from 2018-01-22 14-01-38.png, Screenshot from 2018-01-22 14-02-13.png, error.log
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 16:04:00 2018
From: issues at jboss.org (pavan dittakavi (JIRA))
Date: Mon, 22 Jan 2018 16:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9714) Configuring Server cipher
 order in JBoss 7.1.0 AS
In-Reply-To: <JIRA.12730022.1516482348000@Atlassian.JIRA>
References: <JIRA.12730022.1516482348000@Atlassian.JIRA>
	<JIRA.12730022.1516482348000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730022.1516482348000.78940.1516655040277@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522172#comment-13522172 ] 

pavan dittakavi commented on WFLY-9714:
---------------------------------------

Thanks guys. Can you please tell us which JBoss EAP version would help us in having this feature?. This is becoming very crucial to us and so we wanted to know if this is already addressed in an JBoss EAP version. Please share your views.

> Configuring Server cipher order in JBoss 7.1.0 AS 
> --------------------------------------------------
>
>                 Key: WFLY-9714
>                 URL: https://issues.jboss.org/browse/WFLY-9714
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: JBoss AS7 7.1.1.Final
>         Environment: All operating systems.
>            Reporter: pavan dittakavi
>            Assignee: Darran Lofthouse
>
> Hello Everyone, looks like the JBoss 7.1.0 AS Final version does not have an option to fix the cipher order that is determined by the server. In other words, the SSLHonorCipherOrder attribute does not work. 
> https://developer.jboss.org/thread/276787
> Request you to add this feature.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 16:11:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Mon, 22 Jan 2018 16:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9714) Configuring Server cipher
 order in JBoss 7.1.0 AS
In-Reply-To: <JIRA.12730022.1516482348000@Atlassian.JIRA>
References: <JIRA.12730022.1516482348000@Atlassian.JIRA>
	<JIRA.12730022.1516482348000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730022.1516482348000.78953.1516655460712@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522175#comment-13522175 ] 

Martin Choma commented on WFLY-9714:
------------------------------------

WFLY 11, EAP 7.1 

> Configuring Server cipher order in JBoss 7.1.0 AS 
> --------------------------------------------------
>
>                 Key: WFLY-9714
>                 URL: https://issues.jboss.org/browse/WFLY-9714
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>    Affects Versions: JBoss AS7 7.1.1.Final
>         Environment: All operating systems.
>            Reporter: pavan dittakavi
>            Assignee: Darran Lofthouse
>
> Hello Everyone, looks like the JBoss 7.1.0 AS Final version does not have an option to fix the cipher order that is determined by the server. In other words, the SSLHonorCipherOrder attribute does not work. 
> https://developer.jboss.org/thread/276787
> Request you to add this feature.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 16:14:00 2018
From: issues at jboss.org (David White (JIRA))
Date: Mon, 22 Jan 2018 16:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2234) Unlocked locks stay locked
	forever
In-Reply-To: <JIRA.12720903.1510650064000@Atlassian.JIRA>
References: <JIRA.12720903.1510650064000@Atlassian.JIRA>
	<JIRA.12720903.1510650064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720903.1510650064000.78970.1516655640144@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522178#comment-13522178 ] 

David White commented on JGRP-2234:
-----------------------------------

Wow - I'm glad someone else has run into this issue and has been able to replicate a stand-alone test case.  I too was desperately trying to figure out if this was just a configuration issue, or a bug in JGroups.  We have a 5 node cluster using the CENTRAL_LOCK with the Lock Service and one backup node. All 5 nodes are competing for access for the same resource to lock.

We see a similar scenario where if the Coordinator and backup nodes leave the cluster, sometimes the unlock request from a node is "successfully" processed but yet a dirty lock state is transferred to the node becoming the new coordinator. Subsequently, that resource is permanently locked.

It looks like Bela has fixed this in version 4.0.10. Hopefully, our issue is the same one that has now been fixed.

> Unlocked locks stay locked forever
> ----------------------------------
>
>                 Key: JGRP-2234
>                 URL: https://issues.jboss.org/browse/JGRP-2234
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bram Klein Gunnewiek
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>         Attachments: ClusterSplitLockTest.java, jg_clusterlock_output_testfail.txt
>
>
> As discussed in the mailing list we have issues where locks from the central lock protocol stay locked forever when the coordinator of the cluster disconnects. We can reproduce this with the attached ClusterSplitLockTest.java. Its a race condition and we need to run the test a lot of times (sometimes > 20) before we encounter a failure. 
> What we think is happening: 
> In a three node cluster (node A, B and C where node A is the coordinator) unlock requests from B and/or C can be missed when node A leaves and B and/or C don't have the new view installed yet. When, for example, node B takes over coordination it creates the lock table based on the back-ups. Lets say node C has locked the lock with name 'lockX'. Node C performs an unlock of 'lockX' just after node A (gracefully) leaves and sends the unlock request to node A since node C doesn't have the correct view installed yet. Node B has and recreated the lock table where 'lockX' is locked by Node C. Node C doesn't resend the unlock request so 'lockX' gets locked forever.
> Attached is the testng test we wrote and the output of a test failure.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 16:38:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 22 Jan 2018 16:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9719) ProxyListValidator should not
 do DNS validation
In-Reply-To: <JIRA.12730276.1516657027000@Atlassian.JIRA>
References: <JIRA.12730276.1516657027000@Atlassian.JIRA>
	<JIRA.12730276.1516657027097@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730276.1516657027000.79020.1516657080082@Atlassian.JIRA>

Stuart Douglas created WFLY-9719:
------------------------------------

             Summary: ProxyListValidator should not do DNS validation
                 Key: WFLY-9719
                 URL: https://issues.jboss.org/browse/WFLY-9719
             Project: WildFly
          Issue Type: Bug
          Components: mod_cluster
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 16:59:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 22 Jan 2018 16:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3535) TEST, TO DELETE
In-Reply-To: <JIRA.12730280.1516658312000@Atlassian.JIRA>
References: <JIRA.12730280.1516658312000@Atlassian.JIRA>
	<JIRA.12730280.1516658312162@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730280.1516658312000.79051.1516658340254@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-3535:
--------------------------------------------

             Summary: TEST, TO DELETE
                 Key: WFCORE-3535
                 URL: https://issues.jboss.org/browse/WFCORE-3535
             Project: WildFly Core
          Issue Type: Feature Request
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 17:00:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Mon, 22 Jan 2018 17:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3535) TEST, TO DELETE
In-Reply-To: <JIRA.12730280.1516658312000@Atlassian.JIRA>
References: <JIRA.12730280.1516658312000@Atlassian.JIRA>
	<JIRA.12730280.1516658312000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730280.1516658312000.79054.1516658400127@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3535?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise deleted WFCORE-3535:
-----------------------------------------


> TEST, TO DELETE
> ---------------
>
>                 Key: WFCORE-3535
>                 URL: https://issues.jboss.org/browse/WFCORE-3535
>             Project: WildFly Core
>          Issue Type: Feature Request
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 17:44:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Mon, 22 Jan 2018 17:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707798000@Atlassian.JIRA>
References: <JIRA.12725669.1513707798000@Atlassian.JIRA>
	<JIRA.12725669.1513707798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707798000.79078.1516661040404@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522190#comment-13522190 ] 

James Perkins commented on LOGTOOL-132:
---------------------------------------

Do we also have concerns on distribution size? We currently do not ship any of the {{*.properties}} in WildFly and these changes would likely require those to be shipped. That being said the classes themselves will likely be smaller in general.

> Support low-metaspace bundles/classes
> -------------------------------------
>
>                 Key: LOGTOOL-132
>                 URL: https://issues.jboss.org/browse/LOGTOOL-132
>             Project: Log Tool
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 22 23:40:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Mon, 22 Jan 2018 23:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3536) Upgrade JBoss modules to
	1.7.0.Beta3
In-Reply-To: <JIRA.12730289.1516682355000@Atlassian.JIRA>
References: <JIRA.12730289.1516682355000@Atlassian.JIRA>
	<JIRA.12730289.1516682355890@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730289.1516682355000.79605.1516682400078@Atlassian.JIRA>

Stuart Douglas created WFCORE-3536:
--------------------------------------

             Summary: Upgrade JBoss modules to 1.7.0.Beta3
                 Key: WFCORE-3536
                 URL: https://issues.jboss.org/browse/WFCORE-3536
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: Stuart Douglas
            Assignee: Stuart Douglas


This is necessary for the EE8 work to begin



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 01:20:00 2018
From: issues at jboss.org (Osamu Nagano (JIRA))
Date: Tue, 23 Jan 2018 01:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9720)
 org.jboss.as.jpa.hibernate5.management.QueryName.displayable() consumes
 high amount of CPU
In-Reply-To: <JIRA.12730293.1516688373000@Atlassian.JIRA>
References: <JIRA.12730293.1516688373000@Atlassian.JIRA>
	<JIRA.12730293.1516688373002@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730293.1516688373000.79632.1516688400112@Atlassian.JIRA>

Osamu Nagano created WFLY-9720:
----------------------------------

             Summary: org.jboss.as.jpa.hibernate5.management.QueryName.displayable() consumes high amount of CPU
                 Key: WFLY-9720
                 URL: https://issues.jboss.org/browse/WFLY-9720
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
            Reporter: Osamu Nagano
            Assignee: Scott Marlow


JIPI-32 is fixed in the following classes:
{code}
jpa/hibernate4_1/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java
jpa/hibernate4_3/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java
{code}
But not in the following class:
{code}
jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/management/QueryName.java
{code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 02:09:00 2018
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Tue, 23 Jan 2018 02:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-3594) Wildfly showing the war file
 status as Failed after restart the server
In-Reply-To: <JIRA.12545790.1404797136000@Atlassian.JIRA>
References: <JIRA.12545790.1404797136000@Atlassian.JIRA>
	<JIRA.12545790.1404797136000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12545790.1404797136000.79762.1516691340420@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-3594?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522245#comment-13522245 ] 

Bartosz Baranowski commented on WFLY-3594:
------------------------------------------

[~daoudam] - I did not, was not able to reproduce in any way. Are you using latest master? if you do, can you please post exact steps/config and example app? ( and reopen)

> Wildfly showing the war file status as Failed after restart the server
> ----------------------------------------------------------------------
>
>                 Key: WFLY-3594
>                 URL: https://issues.jboss.org/browse/WFLY-3594
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 8.0.0.Final
>         Environment: windows server 2003 32 bit O.S,Java 7,flex, Apache axis web services
>            Reporter: shaik masthan
>            Assignee: Bartosz Baranowski
>            Priority: Minor
>              Labels: restarting
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> after successful deployment , war file status is deployed. When i restart the server , war files status is showing as failed. there were no errors in the logs  and i am able to access the the application without any problems.  
> After some time happen , again i restart the server this time war file status is deployed.  
> intermittently i am viewing this weird behavior with war files  w.r. t  restarting the server.
> let me know any workaround or fix for this.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 03:06:00 2018
From: issues at jboss.org (Denis Shklyaev (JIRA))
Date: Tue, 23 Jan 2018 03:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9721) AsyncInvocationTask.get()
 throws CancellationException
In-Reply-To: <JIRA.12730294.1516694724000@Atlassian.JIRA>
References: <JIRA.12730294.1516694724000@Atlassian.JIRA>
	<JIRA.12730294.1516694724610@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730294.1516694724000.79865.1516694760118@Atlassian.JIRA>

Denis Shklyaev created WFLY-9721:
------------------------------------

             Summary: AsyncInvocationTask.get() throws CancellationException
                 Key: WFLY-9721
                 URL: https://issues.jboss.org/browse/WFLY-9721
             Project: WildFly
          Issue Type: Bug
          Components: EJB
    Affects Versions: 11.0.0.Final
            Reporter: Denis Shklyaev
            Priority: Optional


AsyncInvocationTask.get() on cancelled task in Wildfly 11 throws CancellationException via EjbLogger, but the behavior is not declared in method signature:

{{    public synchronized Object get() throws InterruptedException, ExecutionException {
        for (;;) switch (status) {
            case ST_RUNNING: wait(); break;
            *case ST_CANCELLED: throw EjbLogger.ROOT_LOGGER.taskWasCancelled();*
            case ST_FAILED: throw new ExecutionException(failed);
            case ST_DONE: return result;
            default: throw Assert.impossibleSwitchCase(status);
        }
    }
}}

Wildfly 10.01.0 code is different:

{{    public synchronized Object get() throws InterruptedException, ExecutionException {
        while (!isDone()) {
            wait();
        }
        if (failed != null) {
            throw new ExecutionException(failed);
        }
        return result;
    } 
}}
It throws InterruptedException instead as declared.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:00:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Tue, 23 Jan 2018 04:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9663) Remove OSGi obsolete code
In-Reply-To: <JIRA.12727619.1515712424000@Atlassian.JIRA>
References: <JIRA.12727619.1515712424000@Atlassian.JIRA>
	<JIRA.12727619.1515712424000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727619.1515712424000.80526.1516698000973@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reopened WFLY-9663:
----------------------------------


> Remove OSGi obsolete code
> -------------------------
>
>                 Key: WFLY-9663
>                 URL: https://issues.jboss.org/browse/WFLY-9663
>             Project: WildFly
>          Issue Type: Task
>          Components: OSGi
>    Affects Versions: 11.0.0.Final
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 12.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:14:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 04:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2260) [DMN Designer] Background
 Color change throws an Exception
In-Reply-To: <JIRA.12730299.1516698782000@Atlassian.JIRA>
References: <JIRA.12730299.1516698782000@Atlassian.JIRA>
	<JIRA.12730299.1516698782405@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730299.1516698782000.80648.1516698840272@Atlassian.JIRA>

Jozef Marko created DROOLS-2260:
-----------------------------------

             Summary: [DMN Designer] Background Color change throws an Exception
                 Key: DROOLS-2260
                 URL: https://issues.jboss.org/browse/DROOLS-2260
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis
         Attachments: Screenshot from 2018-01-23 09-04-01.png

If user click on the background color picker, the attached exception is thrown.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:29:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 04:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2261) [DMN Designer] DND Column
 width is not preserved
In-Reply-To: <JIRA.12730305.1516699707000@Atlassian.JIRA>
References: <JIRA.12730305.1516699707000@Atlassian.JIRA>
	<JIRA.12730305.1516699707104@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730305.1516699707000.80838.1516699740649@Atlassian.JIRA>

Jozef Marko created DROOLS-2261:
-----------------------------------

             Summary: [DMN Designer] DND Column width is not preserved
                 Key: DROOLS-2261
                 URL: https://issues.jboss.org/browse/DROOLS-2261
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis
         Attachments: after-reopen.png, non-saved.png

The DND Grid Columns don't preserve column width between savings.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:37:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 23 Jan 2018 04:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2234) Unlocked locks stay locked
	forever
In-Reply-To: <JIRA.12720903.1510650064000@Atlassian.JIRA>
References: <JIRA.12720903.1510650064000@Atlassian.JIRA>
	<JIRA.12720903.1510650064000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720903.1510650064000.80951.1516700220396@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522315#comment-13522315 ] 

Bela Ban commented on JGRP-2234:
--------------------------------

No, I haven't fixed this yet. As per my other comment on a related issue, I'm not too happy about {{CENTRAL_LOCK}}, as it doesn't handle network partitions (split brain scenarios) properly...
I've been thinking to replace / complement the backups with a reconciliation protocol after the coordinator leaves, where the new coord fetches lock information from all lock holders and builds its lock table from that information. This means it would take a bit longer to serve lock requests after a coord change, but we wouldn't need to send requests from the coord to all backups.

OTOH, this doesn't solve the issue of split brain scenarios and the {{Lock}} abstraction, which is a bad abstraction to take locks away from someone (after a split heals) and allows for multiple holders of the same lock during the split...

> Unlocked locks stay locked forever
> ----------------------------------
>
>                 Key: JGRP-2234
>                 URL: https://issues.jboss.org/browse/JGRP-2234
>             Project: JGroups
>          Issue Type: Bug
>            Reporter: Bram Klein Gunnewiek
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>         Attachments: ClusterSplitLockTest.java, jg_clusterlock_output_testfail.txt
>
>
> As discussed in the mailing list we have issues where locks from the central lock protocol stay locked forever when the coordinator of the cluster disconnects. We can reproduce this with the attached ClusterSplitLockTest.java. Its a race condition and we need to run the test a lot of times (sometimes > 20) before we encounter a failure. 
> What we think is happening: 
> In a three node cluster (node A, B and C where node A is the coordinator) unlock requests from B and/or C can be missed when node A leaves and B and/or C don't have the new view installed yet. When, for example, node B takes over coordination it creates the lock table based on the back-ups. Lets say node C has locked the lock with name 'lockX'. Node C performs an unlock of 'lockX' just after node A (gracefully) leaves and sends the unlock request to node A since node C doesn't have the correct view installed yet. Node B has and recreated the lock table where 'lockX' is locked by Node C. Node C doesn't resend the unlock request so 'lockX' gets locked forever.
> Attached is the testng test we wrote and the output of a test failure.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:43:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Tue, 23 Jan 2018 04:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9663) Remove OSGi obsolete code
In-Reply-To: <JIRA.12727619.1515712424000@Atlassian.JIRA>
References: <JIRA.12727619.1515712424000@Atlassian.JIRA>
	<JIRA.12727619.1515712424000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727619.1515712424000.80999.1516700580304@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated WFLY-9663:
---------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/10738, https://github.com/wildfly/wildfly/pull/10783  (was: https://github.com/wildfly/wildfly/pull/10738, https://github.com/wildfly/wildfly/pull/10782)


> Remove OSGi obsolete code
> -------------------------
>
>                 Key: WFLY-9663
>                 URL: https://issues.jboss.org/browse/WFLY-9663
>             Project: WildFly
>          Issue Type: Task
>          Components: OSGi
>    Affects Versions: 11.0.0.Final
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 12.0.0.Alpha1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:43:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 04:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2236) Cover marshalling of
	UnaryTests
In-Reply-To: <JIRA.12727659.1515745108000@Atlassian.JIRA>
References: <JIRA.12727659.1515745108000@Atlassian.JIRA>
	<JIRA.12727659.1515745108000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727659.1515745108000.81011.1516700580625@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2236:
--------------------------------
    Attachment: org.kie.workbench.common.dmn.backend.definition.v1_1.html


> Cover marshalling of UnaryTests
> -------------------------------
>
>                 Key: DROOLS-2236
>                 URL: https://issues.jboss.org/browse/DROOLS-2236
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>         Attachments: index.html, org.kie.workbench.common.dmn.backend.definition.v1_1.html
>
>
> According to the attached jacoco report, the coverage of marshaling {{UnaryTests}} class should be increased.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:44:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 04:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2236) Cover marshalling of
	UnaryTests
In-Reply-To: <JIRA.12727659.1515745108000@Atlassian.JIRA>
References: <JIRA.12727659.1515745108000@Atlassian.JIRA>
	<JIRA.12727659.1515745108000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727659.1515745108000.81013.1516700640151@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522320#comment-13522320 ] 

Jozef Marko commented on DROOLS-2236:
-------------------------------------

To coverage increased enough, after marshaling of decision tables was implemented, see:
-  [^org.kie.workbench.common.dmn.backend.definition.v1_1.html] 

> Cover marshalling of UnaryTests
> -------------------------------
>
>                 Key: DROOLS-2236
>                 URL: https://issues.jboss.org/browse/DROOLS-2236
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>             Fix For: 7.6.0.Final
>
>         Attachments: index.html, org.kie.workbench.common.dmn.backend.definition.v1_1.html
>
>
> According to the attached jacoco report, the coverage of marshaling {{UnaryTests}} class should be increased.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:44:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 04:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2236) Cover marshalling of
	UnaryTests
In-Reply-To: <JIRA.12727659.1515745108000@Atlassian.JIRA>
References: <JIRA.12727659.1515745108000@Atlassian.JIRA>
	<JIRA.12727659.1515745108000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727659.1515745108000.81016.1516700640210@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko resolved DROOLS-2236.
---------------------------------
    Fix Version/s: 7.6.0.Final
       Resolution: Done


> Cover marshalling of UnaryTests
> -------------------------------
>
>                 Key: DROOLS-2236
>                 URL: https://issues.jboss.org/browse/DROOLS-2236
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>             Fix For: 7.6.0.Final
>
>         Attachments: index.html, org.kie.workbench.common.dmn.backend.definition.v1_1.html
>
>
> According to the attached jacoco report, the coverage of marshaling {{UnaryTests}} class should be increased.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:47:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 04:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1956) [DMN Editor] Introduce unit
 test for Converters
In-Reply-To: <JIRA.12710539.1504764350000@Atlassian.JIRA>
References: <JIRA.12710539.1504764350000@Atlassian.JIRA>
	<JIRA.12710539.1504764350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12710539.1504764350000.81032.1516700820448@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-1956:
--------------------------------
    Attachment: org.kie.workbench.common.dmn.backend.definition.v1_1.html


> [DMN Editor] Introduce unit test for Converters
> -----------------------------------------------
>
>                 Key: DROOLS-1956
>                 URL: https://issues.jboss.org/browse/DROOLS-1956
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>    Affects Versions: 7.2.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>             Fix For: 7.6.0.Final
>
>         Attachments: org.kie.workbench.common.dmn.backend.definition.v1_1.html
>
>
> Cover the classes below with unit tests.
> - FontSetPropertyConverter
> - InformationItemPropertyConverter
> - InputDataConverter



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:47:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 04:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1956) [DMN Editor] Introduce unit
 test for Converters
In-Reply-To: <JIRA.12710539.1504764350000@Atlassian.JIRA>
References: <JIRA.12710539.1504764350000@Atlassian.JIRA>
	<JIRA.12710539.1504764350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12710539.1504764350000.81034.1516700820498@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522323#comment-13522323 ] 

Jozef Marko commented on DROOLS-1956:
-------------------------------------

Covered enough, see:
-  [^org.kie.workbench.common.dmn.backend.definition.v1_1.html] 

> [DMN Editor] Introduce unit test for Converters
> -----------------------------------------------
>
>                 Key: DROOLS-1956
>                 URL: https://issues.jboss.org/browse/DROOLS-1956
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>    Affects Versions: 7.2.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>             Fix For: 7.6.0.Final
>
>         Attachments: org.kie.workbench.common.dmn.backend.definition.v1_1.html
>
>
> Cover the classes below with unit tests.
> - FontSetPropertyConverter
> - InformationItemPropertyConverter
> - InputDataConverter



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:47:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 04:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1956) [DMN Editor] Introduce unit
 test for Converters
In-Reply-To: <JIRA.12710539.1504764350000@Atlassian.JIRA>
References: <JIRA.12710539.1504764350000@Atlassian.JIRA>
	<JIRA.12710539.1504764350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12710539.1504764350000.81044.1516700820858@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1956?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko resolved DROOLS-1956.
---------------------------------
    Fix Version/s: 7.6.0.Final
       Resolution: Out of Date


> [DMN Editor] Introduce unit test for Converters
> -----------------------------------------------
>
>                 Key: DROOLS-1956
>                 URL: https://issues.jboss.org/browse/DROOLS-1956
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>    Affects Versions: 7.2.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>             Fix For: 7.6.0.Final
>
>         Attachments: org.kie.workbench.common.dmn.backend.definition.v1_1.html
>
>
> Cover the classes below with unit tests.
> - FontSetPropertyConverter
> - InformationItemPropertyConverter
> - InputDataConverter



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:51:01 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 23 Jan 2018 04:51:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2261) [DMN Designer] DND Column
 width is not preserved
In-Reply-To: <JIRA.12730305.1516699707000@Atlassian.JIRA>
References: <JIRA.12730305.1516699707000@Atlassian.JIRA>
	<JIRA.12730305.1516699707000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730305.1516699707000.81082.1516701061512@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522327#comment-13522327 ] 

Michael Anstis commented on DROOLS-2261:
----------------------------------------

[~jomarko] Your screen shots show a different issue; the bottom "outer default text" {{LiteralExpression}} editor has not been sized to fill it's parent.

You do however raise the issue that column sizes are not persisted (indeed, if you'd resized the top level "My name" column - the column containing "default" - and re-opened you'd notice the column's width was not preserved...). [~tirelli] [~tari_manga] What do you want to do? I'm sure we could store the widths in the DMN1.1 extensions (as we do for node colour etc). IDK if DMN1.2 supports persistence of other visual meta-data like column width etc.

> [DMN Designer] DND Column width is not preserved
> ------------------------------------------------
>
>                 Key: DROOLS-2261
>                 URL: https://issues.jboss.org/browse/DROOLS-2261
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: after-reopen.png, non-saved.png
>
>
> The DND Grid Columns don't preserve column width between savings.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:58:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 04:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2261) [DMN Designer] DND Column
 width does not fill parent
In-Reply-To: <JIRA.12730305.1516699707000@Atlassian.JIRA>
References: <JIRA.12730305.1516699707000@Atlassian.JIRA>
	<JIRA.12730305.1516699707000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730305.1516699707000.81110.1516701480388@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2261:
--------------------------------
    Summary: [DMN Designer] DND Column width does not fill parent  (was: [DMN Designer] DND Column width is not preserved)


> [DMN Designer] DND Column width does not fill parent
> ----------------------------------------------------
>
>                 Key: DROOLS-2261
>                 URL: https://issues.jboss.org/browse/DROOLS-2261
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: after-reopen.png, non-saved.png
>
>
> The DND Grid Columns don't preserve column width between savings.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:59:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 04:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2261) [DMN Designer] Context
 Entry Default Value Column width does not fill parent
In-Reply-To: <JIRA.12730305.1516699707000@Atlassian.JIRA>
References: <JIRA.12730305.1516699707000@Atlassian.JIRA>
	<JIRA.12730305.1516699707000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730305.1516699707000.81117.1516701540449@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2261:
--------------------------------
    Summary: [DMN Designer] Context Entry Default Value Column width does not fill parent  (was: [DMN Designer] DND Column width does not fill parent)


> [DMN Designer] Context Entry Default Value Column width does not fill parent
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-2261
>                 URL: https://issues.jboss.org/browse/DROOLS-2261
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: after-reopen.png, non-saved.png
>
>
> The DND Grid Columns don't preserve column width between savings.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 04:59:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 04:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2261) [DMN Designer] Context
 Entry Default Value Column width does not fill parent
In-Reply-To: <JIRA.12730305.1516699707000@Atlassian.JIRA>
References: <JIRA.12730305.1516699707000@Atlassian.JIRA>
	<JIRA.12730305.1516699707000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730305.1516699707000.81121.1516701540574@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2261:
--------------------------------
    Steps to Reproduce: 
# Create new DMN Diagram
# Add decision node
# Open DND of the decision node
# Model as:
--   !non-saved.png|thumbnail! 
# Save and reopen
# You will in situation like:
--  !after-reopen.png|thumbnail! 

  was:
# Create new DMN Diagram
# Add decision ndoe
# Open DND of the decision node
# Model as:
--   !non-saved.png|thumbnail! 
# Save and reopen
# You will in situation like:
--  !after-reopen.png|thumbnail! 



> [DMN Designer] Context Entry Default Value Column width does not fill parent
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-2261
>                 URL: https://issues.jboss.org/browse/DROOLS-2261
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: after-reopen.png, non-saved.png
>
>
> The DND Grid Columns don't preserve column width between savings.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 05:00:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 05:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2261) [DMN Designer] Context
 Entry Default Value Column width does not fill parent
In-Reply-To: <JIRA.12730305.1516699707000@Atlassian.JIRA>
References: <JIRA.12730305.1516699707000@Atlassian.JIRA>
	<JIRA.12730305.1516699707000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730305.1516699707000.81128.1516701600229@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2261:
--------------------------------
    Description: Context Entry Default Value Column width does not fill parent. Width is fixed if some small resizing is done in grid.  (was: The DND Grid Columns don't preserve column width between savings.)


> [DMN Designer] Context Entry Default Value Column width does not fill parent
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-2261
>                 URL: https://issues.jboss.org/browse/DROOLS-2261
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: after-reopen.png, non-saved.png
>
>
> Context Entry Default Value Column width does not fill parent. Width is fixed if some small resizing is done in grid.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 05:04:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 05:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2262) [DMN Designer] DND Grid
 Column width is not preserved
In-Reply-To: <JIRA.12730319.1516701816000@Atlassian.JIRA>
References: <JIRA.12730319.1516701816000@Atlassian.JIRA>
	<JIRA.12730319.1516701816872@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730319.1516701816000.81143.1516701840198@Atlassian.JIRA>

Jozef Marko created DROOLS-2262:
-----------------------------------

             Summary: [DMN Designer] DND Grid Column width is not preserved
                 Key: DROOLS-2262
                 URL: https://issues.jboss.org/browse/DROOLS-2262
             Project: Drools
          Issue Type: Bug
          Components: DMN Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis


DND Grid Column don't preserve the width.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 05:06:00 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Tue, 23 Jan 2018 05:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9620)
 ServletContext.getResourceAsStream,
 for deployments which have (Java EE) servlet overlays,
 serves files which are outside of the deployment
In-Reply-To: <JIRA.12725560.1513662272000@Atlassian.JIRA>
References: <JIRA.12725560.1513662272000@Atlassian.JIRA>
	<JIRA.12725560.1513662272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725560.1513662272000.81150.1516701960416@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges reopened WFLY-9620:
--------------------------------
      Assignee: Yeray Borges  (was: Stuart Douglas)


> ServletContext.getResourceAsStream, for deployments which have (Java EE) servlet overlays, serves files which are outside of the deployment
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9620
>                 URL: https://issues.jboss.org/browse/WFLY-9620
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 9.0.2.Final, 10.1.0.Final, 11.0.0.Final
>            Reporter: Laurent ROUSSEL
>            Assignee: Yeray Borges
>            Priority: Critical
>             Fix For: 12.0.0.Alpha1
>
>
> A user has reported in the forums that there appears to be an issue (since 9.0.x till present 11.0.0 WildFly releases) where files like `/etc/passwd` are served by the web container to the clients, when the client requests a crafted URL against a Java EE deployment which has (Java EE) servlet overlays. Please see the referenced forum thread[1] for more details.
> Although, the steps noted in that thread involves Spring framework and gets triggered in a very specific way, the root cause appears to be the call to `ServletContext.getResourceAsInputStream` (which is what the spring framework ends up calling with a path like "/../../../../../../../..//etc/passwd", ends up actually serving the resource even if the path is outside the scope of the deployment to which the servlet context belongs.
> I could reproduce this against the latest WildFly in a simple test case that's here [2]
> [1] https://developer.jboss.org/thread/276826
> [2] https://github.com/jaikiran/wildfly/commit/ed05258aa824ab91a52ef6554e9707531a2cc83b
> P.S: The credit for reporting this issue should go to Laurent Roussel who reported this in the forum thread, but I don't have access to change the "Reporter" field of the JIRA



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 05:13:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 23 Jan 2018 05:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9563) Integrate KUBE_PING discovery
	protocol
In-Reply-To: <JIRA.12721993.1511360492000@Atlassian.JIRA>
References: <JIRA.12721993.1511360492000@Atlassian.JIRA>
	<JIRA.12721993.1511360492000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721993.1511360492000.81190.1516702380180@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9563?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-9563:
---------------------------------
    Fix Version/s:     (was: 12.0.0.Alpha1)


> Integrate KUBE_PING discovery protocol
> --------------------------------------
>
>                 Key: WFLY-9563
>                 URL: https://issues.jboss.org/browse/WFLY-9563
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Clustering
>    Affects Versions: 11.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> https://github.com/jgroups-extras/jgroups-kubernetes



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 05:34:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 23 Jan 2018 05:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2261) [DMN Designer] Context
 Entry Default Value Column width does not fill parent
In-Reply-To: <JIRA.12730305.1516699707000@Atlassian.JIRA>
References: <JIRA.12730305.1516699707000@Atlassian.JIRA>
	<JIRA.12730305.1516699707000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730305.1516699707000.81279.1516703640597@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522353#comment-13522353 ] 

Matteo Mortari commented on DROOLS-2261:
----------------------------------------

my 2c, I would keep simple and not store more than necessary, unless DMN1.2 specify it.
Moreover on our side I canNOT store width of column because they don't receive DMN IDs.
If the UI can auto-size to a sensible degree, it would be preferable I think.

> [DMN Designer] Context Entry Default Value Column width does not fill parent
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-2261
>                 URL: https://issues.jboss.org/browse/DROOLS-2261
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: after-reopen.png, non-saved.png
>
>
> Context Entry Default Value Column width does not fill parent. Width is fixed if some small resizing is done in grid.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 05:40:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Tue, 23 Jan 2018 05:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2261) [DMN Designer] Context
 Entry Default Value Column width does not fill parent
In-Reply-To: <JIRA.12730305.1516699707000@Atlassian.JIRA>
References: <JIRA.12730305.1516699707000@Atlassian.JIRA>
	<JIRA.12730305.1516699707000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730305.1516699707000.81313.1516704000608@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522360#comment-13522360 ] 

Jozef Marko commented on DROOLS-2261:
-------------------------------------

Well feel free to close if we will support DMN1.2 and that standard doesn't allow to store such UI data.

> [DMN Designer] Context Entry Default Value Column width does not fill parent
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-2261
>                 URL: https://issues.jboss.org/browse/DROOLS-2261
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: after-reopen.png, non-saved.png
>
>
> Context Entry Default Value Column width does not fill parent. Width is fixed if some small resizing is done in grid.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 05:46:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Tue, 23 Jan 2018 05:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2258) NullPointerException in
 TupleSetsImpl.setNextTuple when the right memory of a shared subnetwork
 contains more than one tuple
In-Reply-To: <JIRA.12730094.1516614912000@Atlassian.JIRA>
References: <JIRA.12730094.1516614912000@Atlassian.JIRA>
	<JIRA.12730094.1516614912000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730094.1516614912000.81328.1516704360097@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2258?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522362#comment-13522362 ] 

Mario Fusco commented on DROOLS-2258:
-------------------------------------

Fix cherry-picked to branch 7.5.x with https://github.com/kiegroup/drools/commit/44be5377e75668cc1f89177d0bf2666c4bf8e3fa

> NullPointerException in TupleSetsImpl.setNextTuple when the right memory of a shared subnetwork contains more than one tuple
> ----------------------------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2258
>                 URL: https://issues.jboss.org/browse/DROOLS-2258
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>            Reporter: Mario Fusco
>            Assignee: Mario Fusco
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 06:18:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Tue, 23 Jan 2018 06:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3537) Add support for testing of
 CLI multi page output
In-Reply-To: <JIRA.12730335.1516706277000@Atlassian.JIRA>
References: <JIRA.12730335.1516706277000@Atlassian.JIRA>
	<JIRA.12730335.1516706277100@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730335.1516706277000.81464.1516706280447@Atlassian.JIRA>

Erich Duda created WFCORE-3537:
----------------------------------

             Summary: Add support for testing of CLI multi page output
                 Key: WFCORE-3537
                 URL: https://issues.jboss.org/browse/WFCORE-3537
             Project: WildFly Core
          Issue Type: Task
          Components: CLI
    Affects Versions: 4.0.0.Alpha6
            Reporter: Erich Duda
            Assignee: Jean-Francois Denise


For testing of WFCORE-426 feature, it would help to have a method which forces paging of output even if the CLI does not run in system terminal.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 06:21:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Tue, 23 Jan 2018 06:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3538) Improve test coverage of
	WFCORE-426
In-Reply-To: <JIRA.12730336.1516706430000@Atlassian.JIRA>
References: <JIRA.12730336.1516706430000@Atlassian.JIRA>
	<JIRA.12730336.1516706430991@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730336.1516706430000.81473.1516706460148@Atlassian.JIRA>

Erich Duda created WFCORE-3538:
----------------------------------

             Summary: Improve test coverage of WFCORE-426
                 Key: WFCORE-3538
                 URL: https://issues.jboss.org/browse/WFCORE-3538
             Project: WildFly Core
          Issue Type: Task
          Components: CLI
    Affects Versions: 4.0.0.Alpha6
            Reporter: Erich Duda
            Assignee: Erich Duda


There should be automatic tests which verifies that long output is paged and that CLI reacts on keys SPACE, ENTER, KEY DOWN.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 06:26:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 23 Jan 2018 06:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3537) Add support for testing of
 CLI multi page output
In-Reply-To: <JIRA.12730335.1516706277000@Atlassian.JIRA>
References: <JIRA.12730335.1516706277000@Atlassian.JIRA>
	<JIRA.12730335.1516706277000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730335.1516706277000.81488.1516706760462@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3537?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522380#comment-13522380 ] 

Jean-Francois Denise commented on WFCORE-3537:
----------------------------------------------

In order to emulate an interactive session, we plan to add some test only methods:
ReadlineConsole 
public boolean isPagingOutputEnabled()
public void forcePagingOutput(boolean forcePaging)

Console is made available through CommandContextImpl: ReadlineConsole getConsole()



> Add support for testing of CLI multi page output
> ------------------------------------------------
>
>                 Key: WFCORE-3537
>                 URL: https://issues.jboss.org/browse/WFCORE-3537
>             Project: WildFly Core
>          Issue Type: Task
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Erich Duda
>            Assignee: Jean-Francois Denise
>
> For testing of WFCORE-426 feature, it would help to have a method which forces paging of output even if the CLI does not run in system terminal.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 06:57:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 23 Jan 2018 06:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2243) Provide a protocol to inject
 arbitrary view on nodes
In-Reply-To: <JIRA.12725932.1513888720000@Atlassian.JIRA>
References: <JIRA.12725932.1513888720000@Atlassian.JIRA>
	<JIRA.12725932.1513888720000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725932.1513888720000.81643.1516708620400@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2243.
----------------------------
    Resolution: Done


{{INJECT_VIEW}}

> Provide a protocol to inject arbitrary view on nodes
> ----------------------------------------------------
>
>                 Key: JGRP-2243
>                 URL: https://issues.jboss.org/browse/JGRP-2243
>             Project: JGroups
>          Issue Type: Enhancement
>            Reporter: andrea tarocchi
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 07:36:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Tue, 23 Jan 2018 07:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3527) Remove OSGi obsolete code
In-Reply-To: <JIRA.12729983.1516378481000@Atlassian.JIRA>
References: <JIRA.12729983.1516378481000@Atlassian.JIRA>
	<JIRA.12729983.1516378481000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729983.1516378481000.81984.1516710960249@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reopened WFCORE-3527:
------------------------------------


> Remove OSGi obsolete code
> -------------------------
>
>                 Key: WFCORE-3527
>                 URL: https://issues.jboss.org/browse/WFCORE-3527
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Server
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Alpha7
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 08:04:00 2018
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Tue, 23 Jan 2018 08:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2263) [GSS] (6.4.z) Unexpected
 results in GDST when using enumerations with commas
In-Reply-To: <JIRA.12730351.1516712572000@Atlassian.JIRA>
References: <JIRA.12730351.1516712572000@Atlassian.JIRA>
	<JIRA.12730351.1516712572000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730351.1516712572000.82127.1516712640322@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toni Rikkola moved RHBRMS-3064 to DROOLS-2263:
----------------------------------------------

              Project: Drools  (was: JBoss BRMS Platform)
                  Key: DROOLS-2263  (was: RHBRMS-3064)
             Workflow: GIT Pull Request workflow   (was: CDW with docs v1)
       Docs QE Status: NEW
          Component/s: Guided Decision Table Editor
                           (was: Business Central)
    Affects Version/s:     (was: 6.4.1.GA)
            QE Status: NEW


> [GSS] (6.4.z) Unexpected results in GDST when using enumerations with commas
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-2263
>                 URL: https://issues.jboss.org/browse/DROOLS-2263
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>            Reporter: Toni Rikkola
>            Assignee: Toni Rikkola
>
> When using enumerations where the values itself contain a comma, the rules generated by a GDST are unexpected, as the "contains in" operator splits those values in the enumerations. Example enumeration:
> {noformat}
>    fact: person
>    field: city
>    context: ['paris','london','new york,boston']
> {noformat}
> Note: see the 'new york, boston' sample.
> The code generated will be:
> {noformat}
> rule "Row 1 personGDT"
>     dialect "mvel"
>     when
>         p : person( city in ( "new york", "boston" ) )
>     then
> end
> {noformat}
> Basically "paris" and "new york,boston" will be treated by the DSL parser as 3 strings in the DRL generation and will produce someting simiular to
>    p : person( city in ( "paris", "new york", "boston" ) )
> But what the customer expects is the following
>    p : person( city in ( "paris", "new york,boston" ) )



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 08:20:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 23 Jan 2018 08:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-423) No way to grep/more or find
 a line in the CLI
In-Reply-To: <JIRA.12452284.1321372350000@Atlassian.JIRA>
References: <JIRA.12452284.1321372350000@Atlassian.JIRA>
	<JIRA.12452284.1321372350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12452284.1321372350000.82239.1516713600307@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-423?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522458#comment-13522458 ] 

Jean-Francois Denise commented on WFCORE-423:
---------------------------------------------

That is implemented by  WFCORE-3221 and WFCORE-426. Paging of output is enabled by default. In addition "| grep" can be used to find content such as:
:read-resource | grep undefined

> No way to grep/more or find a line in the CLI
> ---------------------------------------------
>
>                 Key: WFCORE-423
>                 URL: https://issues.jboss.org/browse/WFCORE-423
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jim Tyrrell
>            Assignee: Jean-Francois Denise
>              Labels: eap6-ux
>
> In the CLI I should be able to page through the pages of information that are presenting using | more or equivalent.  By the same token I should be able to grep to find the one line that I am looking for, when I know what it is I am looking for.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 08:21:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 23 Jan 2018 08:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-423) No way to grep/more or find
 a line in the CLI
In-Reply-To: <JIRA.12452284.1321372350000@Atlassian.JIRA>
References: <JIRA.12452284.1321372350000@Atlassian.JIRA>
	<JIRA.12452284.1321372350000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12452284.1321372350000.82248.1516713660642@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise closed WFCORE-423.
---------------------------------------
    Resolution: Duplicate Issue


> No way to grep/more or find a line in the CLI
> ---------------------------------------------
>
>                 Key: WFCORE-423
>                 URL: https://issues.jboss.org/browse/WFCORE-423
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jim Tyrrell
>            Assignee: Jean-Francois Denise
>              Labels: eap6-ux
>
> In the CLI I should be able to page through the pages of information that are presenting using | more or equivalent.  By the same token I should be able to grep to find the one line that I am looking for, when I know what it is I am looking for.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 08:31:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 23 Jan 2018 08:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2566) Subsystem parsing tests
 ignores wrong END_ELEMENT
In-Reply-To: <JIRA.12683605.1490099072000@Atlassian.JIRA>
References: <JIRA.12683605.1490099072000@Atlassian.JIRA>
	<JIRA.12683605.1490099072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12683605.1490099072000.82342.1516714260570@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed WFCORE-2566.
------------------------------
    Resolution: Rejected


PersistentResourceXMLDescription already used everywhere in elytron - closing

> Subsystem parsing tests ignores wrong END_ELEMENT
> -------------------------------------------------
>
>                 Key: WFCORE-2566
>                 URL: https://issues.jboss.org/browse/WFCORE-2566
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 3.0.0.Beta9
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Minor
>
> Tests based on *AbstractSubsystemBaseTest* ignores bugs like excessive {code}requireNoContent(reader);{code}
> Tests will fail only if some next element follows - its parsing fails in such case correctly.
> Would be better to add same check in the end of *<test>* parsing, which would check not only there is END_ELEMENT, but also that its name really equals *test*.
> Because this can stay bugs like https://github.com/wildfly-security-incubator/wildfly-core/pull/85/files unnoticed.
> Probably can be added into org.jboss.as.subsystem.test.SubsystemTestDelegate#parse(org.jboss.as.subsystem.test.AdditionalParsers, java.lang.String)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 08:33:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 23 Jan 2018 08:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3048)
 PersistentResourceXMLDescription for parsing/marshaling of Elytron
In-Reply-To: <JIRA.12661835.1479223138000@Atlassian.JIRA>
References: <JIRA.12661835.1479223138000@Atlassian.JIRA>
	<JIRA.12661835.1479223138000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12661835.1479223138000.82358.1516714380596@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3048?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed WFCORE-3048.
------------------------------
    Resolution: Duplicate Issue


> PersistentResourceXMLDescription for parsing/marshaling of Elytron
> ------------------------------------------------------------------
>
>                 Key: WFCORE-3048
>                 URL: https://issues.jboss.org/browse/WFCORE-3048
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Security
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Optional
>
> Using PersistentResourceXMLDescription for parsing/marshaling of Elytron subsystem model parts would simplify code of the subsystem.
> (as an example can be used https://github.com/wildfly-security/elytron-subsystem/pull/290/files or RealmParser)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 08:43:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 23 Jan 2018 08:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-409) Intermittent connection
 TimeOut with CLI using https-remoting
In-Reply-To: <JIRA.12539707.1399035429000@Atlassian.JIRA>
References: <JIRA.12539707.1399035429000@Atlassian.JIRA>
	<JIRA.12539707.1399035429000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539707.1399035429000.82451.1516714980453@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522475#comment-13522475 ] 

Jean-Francois Denise commented on WFCORE-409:
---------------------------------------------

A lot of fixing occurred in remoting to handle timeout when using https. I am closing this issue, if you still see this problem using 7.1 (WF-CORE 3.0), feel free to re-open.

> Intermittent connection TimeOut with CLI using https-remoting
> -------------------------------------------------------------
>
>                 Key: WFCORE-409
>                 URL: https://issues.jboss.org/browse/WFCORE-409
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Filip Bogyai
>            Assignee: Jean-Francois Denise
>
> When the management http-interface is secured to use https and the CLI is using https-remoting to connect, sometimes it hangs which leads to connection timeout. This occurs approximately in 1 out of 10 times if you try to connect with CLI in a short time. 
> {code}
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278)
> 	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
> 	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.modules.Module.run(Module.java:312)
> 	at org.jboss.modules.Main.main(Main.java:460)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9993
> 	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:840)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:819)
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276)
> 	... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> 	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1005)
> 	... 11 more
> Caused by: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
> 	at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> 	at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	... 13 more
> {code}
> This problem also causes intermittent test failures in testsuite, for example: 
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameId=-1990154013938634315&tab=testDetails



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 08:44:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 23 Jan 2018 08:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-409) Intermittent connection
 TimeOut with CLI using https-remoting
In-Reply-To: <JIRA.12539707.1399035429000@Atlassian.JIRA>
References: <JIRA.12539707.1399035429000@Atlassian.JIRA>
	<JIRA.12539707.1399035429000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12539707.1399035429000.82458.1516715040320@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise resolved WFCORE-409.
-----------------------------------------
    Fix Version/s: 3.0.0.Final
       Resolution: Done


> Intermittent connection TimeOut with CLI using https-remoting
> -------------------------------------------------------------
>
>                 Key: WFCORE-409
>                 URL: https://issues.jboss.org/browse/WFCORE-409
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Filip Bogyai
>            Assignee: Jean-Francois Denise
>             Fix For: 3.0.0.Final
>
>
> When the management http-interface is secured to use https and the CLI is using https-remoting to connect, sometimes it hangs which leads to connection timeout. This occurs approximately in 1 out of 10 times if you try to connect with CLI in a short time. 
> {code}
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:278)
> 	at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:253)
> 	at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:606)
> 	at org.jboss.modules.Module.run(Module.java:312)
> 	at org.jboss.modules.Main.main(Main.java:460)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:9993
> 	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1028)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:840)
> 	at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:819)
> 	at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:276)
> 	... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> 	at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:1005)
> 	... 11 more
> Caused by: java.net.ConnectException: JBAS012144: Could not connect to https-remoting://localhost:9993. The connection timed out
> 	at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:119)
> 	at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> 	at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> 	at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:169)
> 	at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:129)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> 	at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> 	at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> 	... 13 more
> {code}
> This problem also causes intermittent test failures in testsuite, for example: 
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameId=-1990154013938634315&tab=testDetails



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 08:46:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 23 Jan 2018 08:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707798000@Atlassian.JIRA>
References: <JIRA.12725669.1513707798000@Atlassian.JIRA>
	<JIRA.12725669.1513707798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707798000.82483.1516715160412@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522479#comment-13522479 ] 

David Lloyd commented on LOGTOOL-132:
-------------------------------------

I think the distribution size should be approximately equal for all approaches, though we'd have to test to be sure.

> Support low-metaspace bundles/classes
> -------------------------------------
>
>                 Key: LOGTOOL-132
>                 URL: https://issues.jboss.org/browse/LOGTOOL-132
>             Project: Log Tool
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 09:11:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 23 Jan 2018 09:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707798000@Atlassian.JIRA>
References: <JIRA.12725669.1513707798000@Atlassian.JIRA>
	<JIRA.12725669.1513707798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707798000.82786.1516716660254@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522495#comment-13522495 ] 

James Perkins commented on LOGTOOL-132:
---------------------------------------

I'll do some experimenting today. I kind of wonder how much metaspace we'll really save by removing the {{*$str()}} methods. By removing those methods there's definitely going to be more I/O happening.

By removing the static strings and just returning the string from the {{*$str()}} method as well as creating a static method in jboss-logging to trim the stack trace I was able to save some metaspace.

*Before Change*
||Index||Super||Total||ClassName||
|604|5115|136592|org.jboss.as.server.logging.ServerLogger_$logger|
|602|5104|127624|org.jboss.as.server.logging.ServerLogger_$logger

*After Change*
||Index||Super||Total||ClassName||
|1561|5115|97312|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|
|1562|5104|91152|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|

> Support low-metaspace bundles/classes
> -------------------------------------
>
>                 Key: LOGTOOL-132
>                 URL: https://issues.jboss.org/browse/LOGTOOL-132
>             Project: Log Tool
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 09:11:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 23 Jan 2018 09:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707798000@Atlassian.JIRA>
References: <JIRA.12725669.1513707798000@Atlassian.JIRA>
	<JIRA.12725669.1513707798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707798000.82790.1516716660411@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522495#comment-13522495 ] 

James Perkins edited comment on LOGTOOL-132 at 1/23/18 9:10 AM:
----------------------------------------------------------------

I'll do some experimenting today. I kind of wonder how much metaspace we'll really save by removing the {{*$str()}} methods. By removing those methods there's definitely going to be more I/O happening.

By removing the static strings and just returning the string from the {{*$str()}} method as well as creating a static method in jboss-logging to trim the stack trace I was able to save some metaspace.

*Before Change*
||Index||Super||Total||ClassName||
|604|5115|136592|org.jboss.as.server.logging.ServerLogger_$logger|
|1561|5115|97312|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|

*After Change*
||Index||Super||Total||ClassName||
|602|5104|127624|org.jboss.as.server.logging.ServerLogger_$logger
|1562|5104|91152|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|


was (Author: jamezp):
I'll do some experimenting today. I kind of wonder how much metaspace we'll really save by removing the {{*$str()}} methods. By removing those methods there's definitely going to be more I/O happening.

By removing the static strings and just returning the string from the {{*$str()}} method as well as creating a static method in jboss-logging to trim the stack trace I was able to save some metaspace.

*Before Change*
||Index||Super||Total||ClassName||
|604|5115|136592|org.jboss.as.server.logging.ServerLogger_$logger|
|602|5104|127624|org.jboss.as.server.logging.ServerLogger_$logger

*After Change*
||Index||Super||Total||ClassName||
|1561|5115|97312|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|
|1562|5104|91152|org.jboss.as.domain.management.logging.DomainManagementLogger_$logger|

> Support low-metaspace bundles/classes
> -------------------------------------
>
>                 Key: LOGTOOL-132
>                 URL: https://issues.jboss.org/browse/LOGTOOL-132
>             Project: Log Tool
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 09:21:00 2018
From: issues at jboss.org (Fedor Gavrilov (JIRA))
Date: Tue, 23 Jan 2018 09:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2264) An option to enable strict
 conformance mode
In-Reply-To: <JIRA.12730379.1516717213000@Atlassian.JIRA>
References: <JIRA.12730379.1516717213000@Atlassian.JIRA>
	<JIRA.12730379.1516717213643@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730379.1516717213000.82875.1516717260270@Atlassian.JIRA>

Fedor Gavrilov created DROOLS-2264:
--------------------------------------

             Summary: An option to enable strict conformance mode
                 Key: DROOLS-2264
                 URL: https://issues.jboss.org/browse/DROOLS-2264
             Project: Drools
          Issue Type: Enhancement
            Reporter: Fedor Gavrilov
            Assignee: Edson Tirelli


Strict conformance mode should be enabled by default for tck profile or by using org.kie.dmn.strictConformance system property or kmodule property.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 09:21:00 2018
From: issues at jboss.org (Fedor Gavrilov (JIRA))
Date: Tue, 23 Jan 2018 09:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2264) An option to enable strict
 conformance mode
In-Reply-To: <JIRA.12730379.1516717214000@Atlassian.JIRA>
References: <JIRA.12730379.1516717214000@Atlassian.JIRA>
	<JIRA.12730379.1516717214000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730379.1516717214000.82878.1516717260356@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fedor Gavrilov reassigned DROOLS-2264:
--------------------------------------

    Assignee: Fedor Gavrilov  (was: Edson Tirelli)


> An option to enable strict conformance mode
> -------------------------------------------
>
>                 Key: DROOLS-2264
>                 URL: https://issues.jboss.org/browse/DROOLS-2264
>             Project: Drools
>          Issue Type: Enhancement
>            Reporter: Fedor Gavrilov
>            Assignee: Fedor Gavrilov
>
> Strict conformance mode should be enabled by default for tck profile or by using org.kie.dmn.strictConformance system property or kmodule property.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 09:40:01 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 23 Jan 2018 09:40:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2260) [DMN Designer] Background
 Color change throws an Exception
In-Reply-To: <JIRA.12730299.1516698782000@Atlassian.JIRA>
References: <JIRA.12730299.1516698782000@Atlassian.JIRA>
	<JIRA.12730299.1516698782000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730299.1516698782000.83024.1516718401261@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2260?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2260:
-----------------------------------
    Sprint: 2018 Week 03-04


> [DMN Designer] Background Color change throws an Exception
> ----------------------------------------------------------
>
>                 Key: DROOLS-2260
>                 URL: https://issues.jboss.org/browse/DROOLS-2260
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: Screenshot from 2018-01-23 09-04-01.png
>
>
> If user click on the background color picker, the attached exception is thrown.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 10:01:04 2018
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Tue, 23 Jan 2018 10:01:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9720)
 org.jboss.as.jpa.hibernate5.management.QueryName.displayable() consumes
 high amount of CPU
In-Reply-To: <JIRA.12730293.1516688373000@Atlassian.JIRA>
References: <JIRA.12730293.1516688373000@Atlassian.JIRA>
	<JIRA.12730293.1516688373000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730293.1516688373000.83226.1516719664532@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow updated WFLY-9720:
-------------------------------
    Fix Version/s: 12.0.0.Alpha1


> org.jboss.as.jpa.hibernate5.management.QueryName.displayable() consumes high amount of CPU
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9720
>                 URL: https://issues.jboss.org/browse/WFLY-9720
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Osamu Nagano
>            Assignee: Scott Marlow
>              Labels: regression
>             Fix For: 12.0.0.Alpha1
>
>
> JIPI-32 is fixed in the following classes:
> {code}
> jpa/hibernate4_1/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java
> jpa/hibernate4_3/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java
> {code}
> But not in the following class:
> {code}
> jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/management/QueryName.java
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 11:24:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 23 Jan 2018 11:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3539) Flunky controller tests
In-Reply-To: <JIRA.12730420.1516724595000@Atlassian.JIRA>
References: <JIRA.12730420.1516724595000@Atlassian.JIRA>
	<JIRA.12730420.1516724595939@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730420.1516724595000.84401.1516724640733@Atlassian.JIRA>

Jan Kalina created WFCORE-3539:
----------------------------------

             Summary: Flunky controller tests
                 Key: WFCORE-3539
                 URL: https://issues.jboss.org/browse/WFCORE-3539
             Project: WildFly Core
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 4.0.0.Alpha6
            Reporter: Jan Kalina
            Assignee: Jan Kalina


Following combination of tests will fail sometime on "Address already in use: bind" on windows:

{code}
mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
{code}

{code}
[Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
[21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
[21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
[21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
[21:41:55]
[testCancelBeforePrepared] java.net.BindException: Address already in use: bind
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
{code}

This happens pretty often on windows CI:
https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 11:25:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 23 Jan 2018 11:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1952) [DMN Editor] Introduce
 marshalling test in the way DMN - String - DMN
In-Reply-To: <JIRA.12709371.1504084484000@Atlassian.JIRA>
References: <JIRA.12709371.1504084484000@Atlassian.JIRA>
	<JIRA.12709371.1504084484000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709371.1504084484000.84416.1516724700804@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522606#comment-13522606 ] 

Michael Anstis commented on DROOLS-1952:
----------------------------------------

[~jomarko] [~tari_manga] Did you want to consider this resolved?

> [DMN Editor] Introduce marshalling test in the way DMN - String - DMN
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-1952
>                 URL: https://issues.jboss.org/browse/DROOLS-1952
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>    Affects Versions: 7.2.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>
> Currently marshaling test assumes as the initial input a *.dmn file that is consequently converted to Graph, next this Graph is converted to XML and finally the XML is transformed to Graph that is asserted for required properties.
> This task should introduce test that will assume as an initial input Graph, that will be converted to JSON, this JSON will be converted again to Graph and finally this Graph will be asserted for required properties.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 11:25:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 23 Jan 2018 11:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3539) Flunky controller tests on
 Windows: Address already in use
In-Reply-To: <JIRA.12730420.1516724596000@Atlassian.JIRA>
References: <JIRA.12730420.1516724596000@Atlassian.JIRA>
	<JIRA.12730420.1516724596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730420.1516724596000.84419.1516724700917@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFCORE-3539:
-------------------------------
    Summary: Flunky controller tests on Windows: Address already in use  (was: Flunky controller tests)


> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
>                 Key: WFCORE-3539
>                 URL: https://issues.jboss.org/browse/WFCORE-3539
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> Following combination of tests will fail sometime on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> 	at sun.nio.ch.Net.bind0(Native Method)
> 	at sun.nio.ch.Net.bind(Net.java:433)
> 	at sun.nio.ch.Net.bind(Net.java:425)
> 	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> 	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> 	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> 	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> 	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> 	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 11:25:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 23 Jan 2018 11:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3539) Flunky controller tests on
 Windows: Address already in use
In-Reply-To: <JIRA.12730420.1516724596000@Atlassian.JIRA>
References: <JIRA.12730420.1516724596000@Atlassian.JIRA>
	<JIRA.12730420.1516724596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730420.1516724596000.84421.1516724700957@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFCORE-3539:
-------------------------------
    Description: 
Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:

{code}
mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
{code}

{code}
[Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
[21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
[21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
[21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
[21:41:55]
[testCancelBeforePrepared] java.net.BindException: Address already in use: bind
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
{code}

This happens pretty often on windows CI:
https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails

  was:
Following combination of tests will fail sometime on "Address already in use: bind" on windows:

{code}
mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
{code}

{code}
[Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
[21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
[21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
[21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
[21:41:55]
[testCancelBeforePrepared] java.net.BindException: Address already in use: bind
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
{code}

This happens pretty often on windows CI:
https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails



> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
>                 Key: WFCORE-3539
>                 URL: https://issues.jboss.org/browse/WFCORE-3539
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> 	at sun.nio.ch.Net.bind0(Native Method)
> 	at sun.nio.ch.Net.bind(Net.java:433)
> 	at sun.nio.ch.Net.bind(Net.java:425)
> 	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> 	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> 	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> 	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> 	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> 	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 11:25:01 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Tue, 23 Jan 2018 11:25:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2261) [DMN Designer] Context
 Entry Default Value Column width does not fill parent
In-Reply-To: <JIRA.12730305.1516699707000@Atlassian.JIRA>
References: <JIRA.12730305.1516699707000@Atlassian.JIRA>
	<JIRA.12730305.1516699707000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730305.1516699707000.84425.1516724701082@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2261:
-----------------------------------
    Sprint: 2018 Week 03-04


> [DMN Designer] Context Entry Default Value Column width does not fill parent
> ----------------------------------------------------------------------------
>
>                 Key: DROOLS-2261
>                 URL: https://issues.jboss.org/browse/DROOLS-2261
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>         Attachments: after-reopen.png, non-saved.png
>
>
> Context Entry Default Value Column width does not fill parent. Width is fixed if some small resizing is done in grid.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 11:25:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 23 Jan 2018 11:25:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3539) Flunky controller tests on
 Windows: Address already in use
In-Reply-To: <JIRA.12730420.1516724596000@Atlassian.JIRA>
References: <JIRA.12730420.1516724596000@Atlassian.JIRA>
	<JIRA.12730420.1516724596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730420.1516724596000.84437.1516724701496@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFCORE-3539:
-------------------------------
    Description: 
Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:

{code}
mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
{code}

{code}
[Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
[21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
[21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
[21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
[21:41:55]
[testCancelBeforePrepared] java.net.BindException: Address already in use: bind
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
{code}

This happens pretty often on windows CI:
https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails

But it is sufficient to run combination of tests above on Windows to reproduce.

  was:
Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:

{code}
mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
{code}

{code}
[Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
[21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
[21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
[21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
[21:41:55]
[testCancelBeforePrepared] java.net.BindException: Address already in use: bind
	at sun.nio.ch.Net.bind0(Native Method)
	at sun.nio.ch.Net.bind(Net.java:433)
	at sun.nio.ch.Net.bind(Net.java:425)
	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
{code}

This happens pretty often on windows CI:
https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails



> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
>                 Key: WFCORE-3539
>                 URL: https://issues.jboss.org/browse/WFCORE-3539
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> 	at sun.nio.ch.Net.bind0(Native Method)
> 	at sun.nio.ch.Net.bind(Net.java:433)
> 	at sun.nio.ch.Net.bind(Net.java:425)
> 	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> 	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> 	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> 	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> 	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> 	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails
> But it is sufficient to run combination of tests above on Windows to reproduce.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 11:35:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jan 2018 11:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3539) Flunky controller tests on
 Windows: Address already in use
In-Reply-To: <JIRA.12730420.1516724596000@Atlassian.JIRA>
References: <JIRA.12730420.1516724596000@Atlassian.JIRA>
	<JIRA.12730420.1516724596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730420.1516724596000.84543.1516725300238@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry resolved WFCORE-3539.
--------------------------------------
    Resolution: Duplicate Issue


This is a dup of WFCORE-3302, caused by REM3-303. If you have any ideas beyond the hacky https://github.com/wildfly/wildfly-core/pull/3039 I'd welcome them.

> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
>                 Key: WFCORE-3539
>                 URL: https://issues.jboss.org/browse/WFCORE-3539
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> 	at sun.nio.ch.Net.bind0(Native Method)
> 	at sun.nio.ch.Net.bind(Net.java:433)
> 	at sun.nio.ch.Net.bind(Net.java:425)
> 	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> 	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> 	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> 	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> 	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> 	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails
> But it is sufficient to run combination of tests above on Windows to reproduce.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 11:43:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 23 Jan 2018 11:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2264) An option to enable strict
 conformance mode
In-Reply-To: <JIRA.12730379.1516717214000@Atlassian.JIRA>
References: <JIRA.12730379.1516717214000@Atlassian.JIRA>
	<JIRA.12730379.1516717214000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730379.1516717214000.84613.1516725780545@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli updated DROOLS-2264:
----------------------------------
    Affects Version/s: 7.5.0.Final


> An option to enable strict conformance mode
> -------------------------------------------
>
>                 Key: DROOLS-2264
>                 URL: https://issues.jboss.org/browse/DROOLS-2264
>             Project: Drools
>          Issue Type: Enhancement
>    Affects Versions: 7.5.0.Final
>            Reporter: Fedor Gavrilov
>            Assignee: Fedor Gavrilov
>
> Strict conformance mode should be enabled by default for tck profile or by using org.kie.dmn.strictConformance system property or kmodule property.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 11:43:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 23 Jan 2018 11:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2264) An option to enable strict
 conformance mode
In-Reply-To: <JIRA.12730379.1516717214000@Atlassian.JIRA>
References: <JIRA.12730379.1516717214000@Atlassian.JIRA>
	<JIRA.12730379.1516717214000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730379.1516717214000.84615.1516725780588@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli updated DROOLS-2264:
----------------------------------
    Component/s: dmn engine


> An option to enable strict conformance mode
> -------------------------------------------
>
>                 Key: DROOLS-2264
>                 URL: https://issues.jboss.org/browse/DROOLS-2264
>             Project: Drools
>          Issue Type: Enhancement
>          Components: dmn engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Fedor Gavrilov
>            Assignee: Fedor Gavrilov
>
> Strict conformance mode should be enabled by default for tck profile or by using org.kie.dmn.strictConformance system property or kmodule property.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 11:44:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Tue, 23 Jan 2018 11:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2265) An option to enable strict
 conformance mode
In-Reply-To: <JIRA.12730429.1516725799000@Atlassian.JIRA>
References: <JIRA.12730429.1516725799000@Atlassian.JIRA>
	<JIRA.12730429.1516725799426@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730429.1516725799000.84631.1516725840261@Atlassian.JIRA>

Edson Tirelli created DROOLS-2265:
-------------------------------------

             Summary: An option to enable strict conformance mode
                 Key: DROOLS-2265
                 URL: https://issues.jboss.org/browse/DROOLS-2265
             Project: Drools
          Issue Type: Enhancement
          Components: dmn engine
    Affects Versions: 7.5.0.Final
            Reporter: Fedor Gavrilov
            Assignee: Fedor Gavrilov
             Fix For: 7.6.0.Final


Strict conformance mode should be enabled by default for tck profile or by using org.kie.dmn.strictConformance system property or kmodule property.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 11:54:00 2018
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Tue, 23 Jan 2018 11:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3531)
 EnumValidator.validateParameter should check toStringMap first to reduce
 the times of IllegalArgumentException creation
In-Reply-To: <JIRA.12730040.1516606001000@Atlassian.JIRA>
References: <JIRA.12730040.1516606001000@Atlassian.JIRA>
	<JIRA.12730040.1516606001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730040.1516606001000.84777.1516726440240@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated WFCORE-3531:
---------------------------------
    Description: 
{panel:title=Description of downstream issue}
Enum is misspelled causing java.lang.IllegalArgumentException 

What is the nature and description of the request?
Enum is misspelled causing java.lang.IllegalArgumentException 

How would the customer like to achieve this? (List the functional requirements here)
In such way, it should not throw Exception and spelled correctly.

ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
Location Where Enum is Used :

jboss-as-jmx module:

./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java

Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());

it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.

Stacktrace Attached.
{panel}

----

{panel:title=Description}

+EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.

However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.

{panel}


  was:
{panel:title=Description of downstream issue}
1. Proposed title of this feature request
Enum is misspelled causing java.lang.IllegalArgumentException 
2. Who is the customer behind the request?
Account: Hamburg S?damerikanische Dampfschifffahrts-Ge, 5651756 
3. What is the nature and description of the request?
Enum is misspelled causing java.lang.IllegalArgumentException 
5. How would the customer like to achieve this? (List the functional requirements here)
In such way, it should not throw Exception and spelled correctly.

ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
Location Where Enum is Used :

jboss-as-jmx module:

./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java

Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());

it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.

Stacktrace Attached.
{panel}

----

{panel:title=Description}

+EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.

However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.

{panel}




> EnumValidator.validateParameter should check toStringMap first to reduce the times of IllegalArgumentException creation
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3531
>                 URL: https://issues.jboss.org/browse/WFCORE-3531
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, JMX
>         Environment: JBoss EAP 6.4.16,6.4.18
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>              Labels: downstream_dependency, performace
>             Fix For: 4.0.0.Alpha7
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> {panel:title=Description of downstream issue}
> Enum is misspelled causing java.lang.IllegalArgumentException 
> What is the nature and description of the request?
> Enum is misspelled causing java.lang.IllegalArgumentException 
> How would the customer like to achieve this? (List the functional requirements here)
> In such way, it should not throw Exception and spelled correctly.
> ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
> Location Where Enum is Used :
> jboss-as-jmx module:
> ./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java
> Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());
> it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.
> Stacktrace Attached.
> {panel}
> ----
> {panel:title=Description}
> +EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.
> However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.
> {panel}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan 23 11:58:00 2018
From: issues at jboss.org (Brad Maxwell (JIRA))
Date: Tue, 23 Jan 2018 11:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3531)
 EnumValidator.validateParameter should check toStringMap first to reduce
 the times of IllegalArgumentException creation
In-Reply-To: <JIRA.12730040.1516606001000@Atlassian.JIRA>
References: <JIRA.12730040.1516606001000@Atlassian.JIRA>
	<JIRA.12730040.1516606001000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730040.1516606001000.84797.1516726680123@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3531?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brad Maxwell updated WFCORE-3531:
---------------------------------
    Labels: downstream_dependency performace performance  (was: downstream_dependency performace)


> EnumValidator.validateParameter should check toStringMap first to reduce the times of IllegalArgumentException creation
> -----------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3531
>                 URL: https://issues.jboss.org/browse/WFCORE-3531
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, JMX
>         Environment: JBoss EAP 6.4.16,6.4.18
>            Reporter: Lin Gao
>            Assignee: Lin Gao
>              Labels: downstream_dependency, performace, performance
>             Fix For: 4.0.0.Alpha7
>
>   Original Estimate: 2 days
>  Remaining Estimate: 2 days
>
> {panel:title=Description of downstream issue}
> Enum is misspelled causing java.lang.IllegalArgumentException 
> What is the nature and description of the request?
> Enum is misspelled causing java.lang.IllegalArgumentException 
> How would the customer like to achieve this? (List the functional requirements here)
> In such way, it should not throw Exception and spelled correctly.
> ENUM : "ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS"
> Location Where Enum is Used :
> jboss-as-jmx module:
> ./jmx/src/main/java/org/jboss/as/jmx/model/ResourceAccessControlUtil.java
> Code : op.get(ACCESS_CONTROL).set(ReadResourceDescriptionHandler.AccessControl.TRIM_DESCRIPTONS.toModelNode());
> it's a general internal jboss issue for all queries that somehow involve the JMX related ResourceAccessControlUtil.
> Stacktrace Attached.
> {panel}
> ----
> {panel:title=Description}
> +EnumValidator.validateParameter+ is now trying to call +Enum.valueOf()+ first and fall back to +toStringMap.get(tuString)+ on +IllegalArgumentException+.
> However, +toStringMap+ contains necessary Enum values in most cases, so switch the way to get the +enumValue+ can reduce the times of IllegalArgumentException creation. And Exception creation may affect performance.
> {panel}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 12:39:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 23 Jan 2018 12:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3539) Flunky controller tests on
 Windows: Address already in use
In-Reply-To: <JIRA.12730420.1516724596000@Atlassian.JIRA>
References: <JIRA.12730420.1516724596000@Atlassian.JIRA>
	<JIRA.12730420.1516724596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730420.1516724596000.85279.1516729140600@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522675#comment-13522675 ] 

Jan Kalina commented on WFCORE-3539:
------------------------------------

By debug output port is closed correctly by application - it looks windows just does not release it for new use fast enough.
Will resolve by using different ports by different tests.

> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
>                 Key: WFCORE-3539
>                 URL: https://issues.jboss.org/browse/WFCORE-3539
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> 	at sun.nio.ch.Net.bind0(Native Method)
> 	at sun.nio.ch.Net.bind(Net.java:433)
> 	at sun.nio.ch.Net.bind(Net.java:425)
> 	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> 	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> 	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> 	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> 	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> 	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails
> But it is sufficient to run combination of tests above on Windows to reproduce.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 12:42:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 23 Jan 2018 12:42:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3539) Flunky controller tests on
 Windows: Address already in use
In-Reply-To: <JIRA.12730420.1516724596000@Atlassian.JIRA>
References: <JIRA.12730420.1516724596000@Atlassian.JIRA>
	<JIRA.12730420.1516724596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730420.1516724596000.85300.1516729321543@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522678#comment-13522678 ] 

Jan Kalina commented on WFCORE-3539:
------------------------------------

[~brian.stansberry] ok, would not be using different ports by different tests better solution? (it would remove extra time needed for waiting for port releasing)

> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
>                 Key: WFCORE-3539
>                 URL: https://issues.jboss.org/browse/WFCORE-3539
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> 	at sun.nio.ch.Net.bind0(Native Method)
> 	at sun.nio.ch.Net.bind(Net.java:433)
> 	at sun.nio.ch.Net.bind(Net.java:425)
> 	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> 	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> 	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> 	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> 	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> 	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails
> But it is sufficient to run combination of tests above on Windows to reproduce.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 12:49:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 23 Jan 2018 12:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3539) Flunky controller tests on
 Windows: Address already in use
In-Reply-To: <JIRA.12730420.1516724596000@Atlassian.JIRA>
References: <JIRA.12730420.1516724596000@Atlassian.JIRA>
	<JIRA.12730420.1516724596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730420.1516724596000.85343.1516729740196@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFCORE-3539:
-------------------------------
    Comment: was deleted

(was: By debug output port is closed correctly by application - it looks windows just does not release it for new use fast enough.
Will resolve by using different ports by different tests.)


> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
>                 Key: WFCORE-3539
>                 URL: https://issues.jboss.org/browse/WFCORE-3539
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> 	at sun.nio.ch.Net.bind0(Native Method)
> 	at sun.nio.ch.Net.bind(Net.java:433)
> 	at sun.nio.ch.Net.bind(Net.java:425)
> 	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> 	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> 	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> 	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> 	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> 	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails
> But it is sufficient to run combination of tests above on Windows to reproduce.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 13:25:01 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Tue, 23 Jan 2018 13:25:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9722) Add support for configuring
 scattered caches
In-Reply-To: <JIRA.12730446.1516731897000@Atlassian.JIRA>
References: <JIRA.12730446.1516731897000@Atlassian.JIRA>
	<JIRA.12730446.1516731897967@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730446.1516731897000.85539.1516731901060@Atlassian.JIRA>

Paul Ferraro created WFLY-9722:
----------------------------------

             Summary: Add support for configuring scattered caches
                 Key: WFLY-9722
                 URL: https://issues.jboss.org/browse/WFLY-9722
             Project: WildFly
          Issue Type: Enhancement
          Components: Clustering
    Affects Versions: 11.0.0.Final
            Reporter: Paul Ferraro
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 14:02:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Tue, 23 Jan 2018 14:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1423) Elytron/Remoting/EJB -
 Exception from failed authentication differs depending on previous calls
In-Reply-To: <JIRA.12717386.1508496365000@Atlassian.JIRA>
References: <JIRA.12717386.1508496365000@Atlassian.JIRA>
	<JIRA.12717386.1508496365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12717386.1508496365000.85744.1516734120083@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1423?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed ELY-1423.
---------------------------
    Resolution: Rejected


No change in elytron needed.

> Elytron/Remoting/EJB - Exception from failed authentication differs depending on previous calls
> -----------------------------------------------------------------------------------------------
>
>                 Key: ELY-1423
>                 URL: https://issues.jboss.org/browse/ELY-1423
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>    Affects Versions: 1.2.0.Beta8
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>
> Exception presented to a client when EJB authentication fails should be the same for first authentication and subsequent authentications.
> I have following scenario:
> {noformat}
> EJB Client -> EntryBean (server1) -> WhoAmIBean (server2)
> {noformat}
> the Client provides correct credentials to server 1 and EntryBean makes reauthentication to server2.
> When I use??wrong credentials for server2 in EntryBean, the call fails with:
> {noformat}
> org.jboss.ejb.client.RequestSendFailedException: javax.security.sasl.SaslException: Authentication failed: all available authentication mechanisms failed
> {noformat}
> When I run the scenario twice and use a correct credentials in EntryBean first and wrong in the second run, then the Exception is different:
> {noformat}
> org.jboss.ejb.client.RequestSendFailedException: org.wildfly.security.auth.AuthenticationException: JBREM000308: Authentication failed (no mechanisms left)
> {noformat}
> From a client POV the exception should be the same in every call:
> * to allow safer exception handling in client code
> * to avoid disclosure shared connection details



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan 23 14:11:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jan 2018 14:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3539) Flunky controller tests on
 Windows: Address already in use
In-Reply-To: <JIRA.12730420.1516724596000@Atlassian.JIRA>
References: <JIRA.12730420.1516724596000@Atlassian.JIRA>
	<JIRA.12730420.1516724596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730420.1516724596000.85754.1516734660224@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522714#comment-13522714 ] 

Brian Stansberry commented on WFCORE-3539:
------------------------------------------

[~honza889] Sure, that would be better, particularly if it is easy to set up and avoids conflicts with random other stuff that may be on the machine. Note that it's different ports per test method not per test class. The failures are usually within the same class.

> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
>                 Key: WFCORE-3539
>                 URL: https://issues.jboss.org/browse/WFCORE-3539
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> 	at sun.nio.ch.Net.bind0(Native Method)
> 	at sun.nio.ch.Net.bind(Net.java:433)
> 	at sun.nio.ch.Net.bind(Net.java:425)
> 	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> 	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> 	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> 	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> 	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> 	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails
> But it is sufficient to run combination of tests above on Windows to reproduce.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 15:13:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 23 Jan 2018 15:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707798000@Atlassian.JIRA>
References: <JIRA.12725669.1513707798000@Atlassian.JIRA>
	<JIRA.12725669.1513707798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707798000.85812.1516738380497@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522724#comment-13522724 ] 

David Lloyd commented on LOGTOOL-132:
-------------------------------------

Any I/O that happens only one time on construction should acceptable because it is only done once, and it is loading from the JAR as the class itself.

> Support low-metaspace bundles/classes
> -------------------------------------
>
>                 Key: LOGTOOL-132
>                 URL: https://issues.jboss.org/browse/LOGTOOL-132
>             Project: Log Tool
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 15:35:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jan 2018 15:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3539) Flunky controller tests on
 Windows: Address already in use
In-Reply-To: <JIRA.12730420.1516724596000@Atlassian.JIRA>
References: <JIRA.12730420.1516724596000@Atlassian.JIRA>
	<JIRA.12730420.1516724596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730420.1516724596000.85839.1516739700145@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522714#comment-13522714 ] 

Brian Stansberry edited comment on WFCORE-3539 at 1/23/18 3:34 PM:
-------------------------------------------------------------------

[~honza889] Sure, that would be better, particularly if it is easy to set up and avoids conflicts with random other stuff that may be on the machine. Note that it's different ports per test method not just per test class. The failures are usually within the same class.

Also, I thought about looping through a set of expected-to-be ok ports (rather than just blindly incrementing and hoping you don't hit a conflict) but a caveat is I've observed that just a 50 ms sleep still produced failures. 100 ms seemed ok, at least on ci.wildfly.org. So any set of "ok ports" would have to be big enough to allow enough tests to run and time to pass before starting over.


was (Author: brian.stansberry):
[~honza889] Sure, that would be better, particularly if it is easy to set up and avoids conflicts with random other stuff that may be on the machine. Note that it's different ports per test method not per test class. The failures are usually within the same class.

> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
>                 Key: WFCORE-3539
>                 URL: https://issues.jboss.org/browse/WFCORE-3539
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> 	at sun.nio.ch.Net.bind0(Native Method)
> 	at sun.nio.ch.Net.bind(Net.java:433)
> 	at sun.nio.ch.Net.bind(Net.java:425)
> 	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> 	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> 	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> 	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> 	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> 	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails
> But it is sufficient to run combination of tests above on Windows to reproduce.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 16:06:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Tue, 23 Jan 2018 16:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707798000@Atlassian.JIRA>
References: <JIRA.12725669.1513707798000@Atlassian.JIRA>
	<JIRA.12725669.1513707798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707798000.85904.1516741560924@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522739#comment-13522739 ] 

James Perkins commented on LOGTOOL-132:
---------------------------------------

For loggers there is potential for it to happen many times. A mapping of log messages can't be static on a logger as there is a {{Logger.getMessageLogger(Class<T>, String, Locale)}} option so if the user doesn't use a static logger each instantiation will read a properties file.

I guess the real question is going to be is the metaspace size of having a mapping of messages vs having each string having a method going to significantly decrease the size. My gut is for English only maybe not that much. For other languages it may be a lot more significant.

Anyway, I'll give it a test. Removing the static strings and adding a method in jboss-logging to remove the stack trace entry for exceptions only saves about 6% on English interfaces.

> Support low-metaspace bundles/classes
> -------------------------------------
>
>                 Key: LOGTOOL-132
>                 URL: https://issues.jboss.org/browse/LOGTOOL-132
>             Project: Log Tool
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 17:57:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 23 Jan 2018 17:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707798000@Atlassian.JIRA>
References: <JIRA.12725669.1513707798000@Atlassian.JIRA>
	<JIRA.12725669.1513707798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707798000.86659.1516748220224@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522790#comment-13522790 ] 

David Lloyd commented on LOGTOOL-132:
-------------------------------------

Ah, well the bulk of the metaspace reduction should come from the fact that most of the internal structures that are consuming substantial metaspace can be deleted if the methods are final based on an analysis that Andrew Dinn has done.

Also, moving the strings out of the class moves that memory overhead to the heap out of metaspace, but the point of doing this is really because it's the only practical way I know of to allow the class to be final.

> Support low-metaspace bundles/classes
> -------------------------------------
>
>                 Key: LOGTOOL-132
>                 URL: https://issues.jboss.org/browse/LOGTOOL-132
>             Project: Log Tool
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 18:18:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 23 Jan 2018 18:18:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2230) Multiple discovery protocols
 without MULTI_PING
In-Reply-To: <JIRA.12717974.1508915049000@Atlassian.JIRA>
References: <JIRA.12717974.1508915049000@Atlassian.JIRA>
	<JIRA.12717974.1508915049000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12717974.1508915049000.86772.1516749480648@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522801#comment-13522801 ] 

Radoslav Husar commented on JGRP-2230:
--------------------------------------

It should be possible to introduce a new API already in 4.x that protocols themselves can already (i.e. optionally) implement so they can be ready for 5.x when the time comes without code changes.

> Multiple discovery protocols without MULTI_PING
> -----------------------------------------------
>
>                 Key: JGRP-2230
>                 URL: https://issues.jboss.org/browse/JGRP-2230
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 5.0
>
>
> Currently, {{MULTI_PING}} is needed to forward discovery requests to multiple discovery protocols. If we change the API in 5.0, and pass a {{Responses}} object down to the discovery protocols, and each discovery protocol forwards discovery requests down (and responses up), and they all add responses to the same {{Responses}} object, then we would not need {{MULTI_PING}} any longer.
> However, this is an API change, so can be done only in 5.0.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 18:29:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 23 Jan 2018 18:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9723) Multiple discovery protocols
 - add MULTI_PING automatically
In-Reply-To: <JIRA.12730470.1516750082000@Atlassian.JIRA>
References: <JIRA.12730470.1516750082000@Atlassian.JIRA>
	<JIRA.12730470.1516750082481@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730470.1516750082000.86800.1516750140117@Atlassian.JIRA>

Radoslav Husar created WFLY-9723:
------------------------------------

             Summary: Multiple discovery protocols - add MULTI_PING automatically
                 Key: WFLY-9723
                 URL: https://issues.jboss.org/browse/WFLY-9723
             Project: WildFly
          Issue Type: Feature Request
          Components: Clustering
    Affects Versions: 11.0.0.Final
            Reporter: Radoslav Husar
            Assignee: Paul Ferraro


Previously, only one discovery protocol could have been used per stack. To allow for multiple discovery protocols in JGroups, MULTI_PING (JGRP-2224) protocol was implemented which did not require all protocols to be modified to support the change (especially since many protocols now reside outside the main jgroups project).

Though, this is a temporary measure which is planned to be remedied in JGroups 5.x with JGRP-2230 where MULTI_PING will no longer be required.

To remedy the inconvenience, we could add MULTI_PING automatically for JGroups 4.x release (in somewhat similar fashion FORK is added).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 18:32:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jan 2018 18:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9720)
 org.jboss.as.jpa.hibernate5.management.QueryName.displayable() consumes
 high amount of CPU
In-Reply-To: <JIRA.12730293.1516688373000@Atlassian.JIRA>
References: <JIRA.12730293.1516688373000@Atlassian.JIRA>
	<JIRA.12730293.1516688373000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730293.1516688373000.86805.1516750320266@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9720?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry reassigned WFLY-9720:
--------------------------------------

      Assignee: Osamu Nagano  (was: Scott Marlow)
    Resolution: Done


> org.jboss.as.jpa.hibernate5.management.QueryName.displayable() consumes high amount of CPU
> ------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9720
>                 URL: https://issues.jboss.org/browse/WFLY-9720
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>            Reporter: Osamu Nagano
>            Assignee: Osamu Nagano
>              Labels: regression
>             Fix For: 12.0.0.Alpha1
>
>
> JIPI-32 is fixed in the following classes:
> {code}
> jpa/hibernate4_1/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java
> jpa/hibernate4_3/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java
> {code}
> But not in the following class:
> {code}
> jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/management/QueryName.java
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 20:29:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Tue, 23 Jan 2018 20:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3539) Flunky controller tests on
 Windows: Address already in use
In-Reply-To: <JIRA.12730420.1516724596000@Atlassian.JIRA>
References: <JIRA.12730420.1516724596000@Atlassian.JIRA>
	<JIRA.12730420.1516724596000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730420.1516724596000.86965.1516757340152@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3539?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522823#comment-13522823 ] 

Brian Stansberry commented on WFCORE-3539:
------------------------------------------

The crappy workaround is merged, but I'll be happy to see it reverted if there's a better way.

> Flunky controller tests on Windows: Address already in use
> ----------------------------------------------------------
>
>                 Key: WFCORE-3539
>                 URL: https://issues.jboss.org/browse/WFCORE-3539
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Test Suite
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> Following combination of tests will fail *sometimes* on "Address already in use: bind" on windows:
> {code}
> mvn test -Dtest=org.jboss.as.controller.test.RemoteChannelProxyControllerTestCase,org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> {code}
> {code}
> [Step 2/3] org.jboss.as.controller.test.TransactionalProtocolClientTestCase
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testSequentialGroup
> [21:41:55][org.jboss.as.controller.test.TransactionalProtocolClientTestCase] testCancelBeforePrepared
> [21:41:55][testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> [21:41:55]
> [testCancelBeforePrepared] java.net.BindException: Address already in use: bind
> 	at sun.nio.ch.Net.bind0(Native Method)
> 	at sun.nio.ch.Net.bind(Net.java:433)
> 	at sun.nio.ch.Net.bind(Net.java:425)
> 	at sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74)
> 	at sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:67)
> 	at org.xnio.nio.NioXnioWorker.createTcpConnectionServer(NioXnioWorker.java:181)
> 	at org.xnio.XnioWorker.createStreamConnectionServer(XnioWorker.java:310)
> 	at org.jboss.remoting3.remote.RemoteConnectionProvider$ProviderInterface.createServer(RemoteConnectionProvider.java:372)
> 	at org.jboss.as.controller.support.ChannelServer.create(ChannelServer.java:93)
> 	at org.jboss.as.controller.test.TransactionalProtocolClientTestCase.startChannelServer(TransactionalProtocolClientTestCase.java:108)
> {code}
> This happens pretty often on windows CI:
> https://ci.wildfly.org/project.html?projectId=WildFlyCore_PullRequest&testNameId=-1770791349410974648&tab=testDetails
> But it is sufficient to run combination of tests above on Windows to reproduce.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 23 23:54:00 2018
From: issues at jboss.org (Stuart Douglas (JIRA))
Date: Tue, 23 Jan 2018 23:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9724) [GSS](7.1.z) Undertow does
 not allow UTF-8 characters in URLs
In-Reply-To: <JIRA.12730475.1516769608000@Atlassian.JIRA>
References: <JIRA.12730475.1516769608000@Atlassian.JIRA>
	<JIRA.12730475.1516769608000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730475.1516769608000.87073.1516769640605@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Stuart Douglas moved JBEAP-14128 to WFLY-9724:
----------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-9724  (was: JBEAP-14128)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Web (Undertow)
                           (was: Web (Undertow))
    Affects Version/s:     (was: 7.1.0.CR3)
        Fix Version/s:     (was: 7.1.1.GA)


> [GSS](7.1.z) Undertow does not allow UTF-8 characters in URLs
> -------------------------------------------------------------
>
>                 Key: WFLY-9724
>                 URL: https://issues.jboss.org/browse/WFLY-9724
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>            Reporter: Stuart Douglas
>            Assignee: Stuart Douglas
>              Labels: downstream_dependency, qe-pre-ack
>
> We receive a 400 response code if using UTF-8 characters for a request, due to this check:
> https://github.com/undertow-io/undertow/blob/master/core/src/main/java/io/undertow/server/protocol/http/HttpRequestParser.java#L375
> This was introduced in UNDERTOW-1101. We want to understand why it is necessary for the CVE/CWE regarding request smuggling, but this ticket is to at least make this check optional as it goes against the URL_ENCODING UndertowOption when set to UTF-8 (default).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 03:25:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 24 Jan 2018 03:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2266) [DMN Designer] Override
 newSizeHandler for DMNSVGShapeDefImpl
In-Reply-To: <JIRA.12730485.1516782240000@Atlassian.JIRA>
References: <JIRA.12730485.1516782240000@Atlassian.JIRA>
	<JIRA.12730485.1516782240331@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730485.1516782240000.87547.1516782300172@Atlassian.JIRA>

Jozef Marko created DROOLS-2266:
-----------------------------------

             Summary: [DMN Designer] Override newSizeHandler for DMNSVGShapeDefImpl
                 Key: DROOLS-2266
                 URL: https://issues.jboss.org/browse/DROOLS-2266
             Project: Drools
          Issue Type: Enhancement
          Components: DMN Editor
    Affects Versions: 7.6.0.Final
            Reporter: Jozef Marko
            Assignee: Michael Anstis


Due to changes in JBPM-6512, we should override the _newSizeHandler_ in the class [DMNSVGShapeDefImpl.java|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-dmn/kie-wb-common-dmn-client/src/main/java/org/kie/workbench/common/dmn/client/shape/def/DMNSVGShapeDefImpl.java] to introduce the same approach in min/max size constraint handling through Stunner, DMN and Forms.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 03:39:00 2018
From: issues at jboss.org (Chao Wang (JIRA))
Date: Wed, 24 Jan 2018 03:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3540) In non interactive mode,
 ls -l table format output is bad if any element in return contents
 is longer than terminal width
In-Reply-To: <JIRA.12730487.1516783052000@Atlassian.JIRA>
References: <JIRA.12730487.1516783052000@Atlassian.JIRA>
	<JIRA.12730487.1516783052000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730487.1516783052000.87623.1516783140415@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang moved JBEAP-14131 to WFCORE-3540:
-------------------------------------------

              Project: WildFly Core  (was: JBoss Enterprise Application Platform)
                  Key: WFCORE-3540  (was: JBEAP-14131)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: CLI
                           (was: CLI)
    Affects Version/s: 4.0.0.Alpha6
                           (was: 7.1.0.DR18)


> In non interactive mode, ls -l  table format output is bad if any element in return contents is longer than terminal width
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3540
>                 URL: https://issues.jboss.org/browse/WFCORE-3540
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>              Labels: eap7.1.0-defer
>
> 1. create commands in file command.cli which contains "ls -l /subsystem=elytron/provider-loader=elytron"
> 2. start EAP server.
> 3 execute command in CLI non interactive mode jboss-cli.sh -c --file=command.cli.
> See the table output is malformat



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 03:54:02 2018
From: issues at jboss.org (Chao Wang (JIRA))
Date: Wed, 24 Jan 2018 03:54:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3540) In non interactive mode,
 ls -l table format output is bad if any element in return contents
 is longer than terminal width
In-Reply-To: <JIRA.12730487.1516783052000@Atlassian.JIRA>
References: <JIRA.12730487.1516783052000@Atlassian.JIRA>
	<JIRA.12730487.1516783052000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730487.1516783052000.87731.1516784042070@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3540?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chao Wang updated WFCORE-3540:
------------------------------
    Labels:   (was: eap7.1.0-defer)


> In non interactive mode, ls -l  table format output is bad if any element in return contents is longer than terminal width
> --------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3540
>                 URL: https://issues.jboss.org/browse/WFCORE-3540
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Chao Wang
>            Assignee: Chao Wang
>            Priority: Minor
>
> 1. create commands in file command.cli which contains "ls -l /subsystem=elytron/provider-loader=elytron"
> 2. start EAP server.
> 3 execute command in CLI non interactive mode jboss-cli.sh -c --file=command.cli.
> See the table output is malformat



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 04:24:00 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Wed, 24 Jan 2018 04:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9620)
 ServletContext.getResourceAsStream,
 for deployments which have (Java EE) servlet overlays,
 serves files which are outside of the deployment
In-Reply-To: <JIRA.12725560.1513662272000@Atlassian.JIRA>
References: <JIRA.12725560.1513662272000@Atlassian.JIRA>
	<JIRA.12725560.1513662272000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725560.1513662272000.88074.1516785840593@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9620?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges updated WFLY-9620:
-------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/10748, https://github.com/wildfly/wildfly/pull/10784


> ServletContext.getResourceAsStream, for deployments which have (Java EE) servlet overlays, serves files which are outside of the deployment
> -------------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9620
>                 URL: https://issues.jboss.org/browse/WFLY-9620
>             Project: WildFly
>          Issue Type: Bug
>          Components: Web (Undertow)
>    Affects Versions: 9.0.2.Final, 10.1.0.Final, 11.0.0.Final
>            Reporter: Laurent ROUSSEL
>            Assignee: Yeray Borges
>            Priority: Critical
>             Fix For: 12.0.0.Alpha1
>
>
> A user has reported in the forums that there appears to be an issue (since 9.0.x till present 11.0.0 WildFly releases) where files like `/etc/passwd` are served by the web container to the clients, when the client requests a crafted URL against a Java EE deployment which has (Java EE) servlet overlays. Please see the referenced forum thread[1] for more details.
> Although, the steps noted in that thread involves Spring framework and gets triggered in a very specific way, the root cause appears to be the call to `ServletContext.getResourceAsInputStream` (which is what the spring framework ends up calling with a path like "/../../../../../../../..//etc/passwd", ends up actually serving the resource even if the path is outside the scope of the deployment to which the servlet context belongs.
> I could reproduce this against the latest WildFly in a simple test case that's here [2]
> [1] https://developer.jboss.org/thread/276826
> [2] https://github.com/jaikiran/wildfly/commit/ed05258aa824ab91a52ef6554e9707531a2cc83b
> P.S: The credit for reporting this issue should go to Laurent Roussel who reported this in the forum thread, but I don't have access to change the "Reporter" field of the JIRA



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 04:40:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Wed, 24 Jan 2018 04:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9725) Error during transaction
 manager commit of non-XA resource does not provokes exception being thrown
In-Reply-To: <JIRA.12730507.1516786784000@Atlassian.JIRA>
References: <JIRA.12730507.1516786784000@Atlassian.JIRA>
	<JIRA.12730507.1516786784292@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730507.1516786784000.88257.1516786800076@Atlassian.JIRA>

Ondra Chaloupka created WFLY-9725:
-------------------------------------

             Summary: Error during transaction manager commit of non-XA resource does not provokes exception being thrown
                 Key: WFLY-9725
                 URL: https://issues.jboss.org/browse/WFLY-9725
             Project: WildFly
          Issue Type: Bug
          Components: Transactions
    Affects Versions: 11.0.0.Final
            Reporter: Ondra Chaloupka
            Assignee: Ondra Chaloupka


In case that an exception is thrown during one-phase commit of non-XA transaction participant the error is swallowed and not returned to the caller

This can happend for example when transaction manager calls commit to the e.g. database resource and connection crash happens. Then jdbc driver returns {{XAException}} with error code like {{XAER_RMFAIL}}. This fact is not reflected by exception being thrown to the caller (e.g. EJB bean).

This causes to the fact that user think the work was committed (e.g. INSERT to database) but in fact connection failure happened and nothing was done.

The fix is part of the Narayana at issue https://issues.jboss.org/browse/JBTM-2983 and it should be released with Narayana 5.7.3.Final



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 04:41:01 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 24 Jan 2018 04:41:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2247) RPC does not invoke
 interface's default methods inherited
In-Reply-To: <JIRA.12730182.1516626312000@Atlassian.JIRA>
References: <JIRA.12730182.1516626312000@Atlassian.JIRA>
	<JIRA.12730182.1516626312000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730182.1516626312000.88290.1516786861517@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2247.
----------------------------
    Resolution: Done


Default methods in interfaces are now found as well

> RPC does not invoke interface's default methods inherited
> ---------------------------------------------------------
>
>                 Key: JGRP-2247
>                 URL: https://issues.jboss.org/browse/JGRP-2247
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 4.0.8
>         Environment: jgroups 4.0.8.Final
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
> on win 10
>            Reporter: rokk ebol
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> org.jgroups.blocks.MethodCall#getAllMethods looks for methods up there in superclasses but not in interfaces, which can contain default methods since java 8



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 04:48:00 2018
From: issues at jboss.org (Ondra Chaloupka (JIRA))
Date: Wed, 24 Jan 2018 04:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9725) Error during transaction
 manager commit of non-XA resource does not provokes exception being thrown
In-Reply-To: <JIRA.12730507.1516786784000@Atlassian.JIRA>
References: <JIRA.12730507.1516786784000@Atlassian.JIRA>
	<JIRA.12730507.1516786784000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730507.1516786784000.88318.1516787280244@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ondra Chaloupka updated WFLY-9725:
----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/10789


> Error during transaction manager commit of non-XA resource does not provokes exception being thrown
> ---------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9725
>                 URL: https://issues.jboss.org/browse/WFLY-9725
>             Project: WildFly
>          Issue Type: Bug
>          Components: Transactions
>    Affects Versions: 11.0.0.Final
>            Reporter: Ondra Chaloupka
>            Assignee: Ondra Chaloupka
>
> In case that an exception is thrown during one-phase commit of non-XA transaction participant the error is swallowed and not returned to the caller
> This can happend for example when transaction manager calls commit to the e.g. database resource and connection crash happens. Then jdbc driver returns {{XAException}} with error code like {{XAER_RMFAIL}}. This fact is not reflected by exception being thrown to the caller (e.g. EJB bean).
> This causes to the fact that user think the work was committed (e.g. INSERT to database) but in fact connection failure happened and nothing was done.
> The fix is part of the Narayana at issue https://issues.jboss.org/browse/JBTM-2983 and it should be released with Narayana 5.7.3.Final



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 05:05:00 2018
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Wed, 24 Jan 2018 05:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFBUILD-33) Support non-jar artifacts
	properly
In-Reply-To: <JIRA.12730515.1516788245000@Atlassian.JIRA>
References: <JIRA.12730515.1516788245000@Atlassian.JIRA>
	<JIRA.12730515.1516788245076@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730515.1516788245000.88415.1516788300926@Atlassian.JIRA>

Peter Palaga created WFBUILD-33:
-----------------------------------

             Summary: Support non-jar artifacts properly
                 Key: WFBUILD-33
                 URL: https://issues.jboss.org/browse/WFBUILD-33
             Project: WildFly Build Tools
          Issue Type: Bug
            Reporter: Peter Palaga
            Assignee: Peter Palaga


The immediate impetus for reporting this is the fact that after upgrading from 1.1.6.Final to 1.2.6.Final our 

{code}
<copy-artifact artifact="io.hawt:hawtio-wildfly" to-location="standalone/deployments/"/>
{code}

stopped working for the FP plugin. Changing it to 

{code}<copy-artifact artifact="io.hawt:hawtio-wildfly:war" to-location="standalone/deployments/"/>{code}

by adding :war made the FP plugin happy, but it made the provisioning plugin fail with an NPE.

It looks like the code parsing and the rendering the groupId:artifactId:type:classifier:version strings is scattered over several methods whose behavior is not 100% consistent.

The current objective is:

(1) Write a few integration tests to pin the behavior before the change, identifying the broken cases

(2) Write the actual fix in such a way that the plugins stay as backwards compatible as possible.

I have a fix that works for me, I just need to ensure, my changes keep the plugins backwards compatible.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 05:05:01 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Wed, 24 Jan 2018 05:05:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9726) Upgrade JSF based on Mojarra
	2.2.13.SP5
In-Reply-To: <JIRA.12730516.1516788266000@Atlassian.JIRA>
References: <JIRA.12730516.1516788266000@Atlassian.JIRA>
	<JIRA.12730516.1516788266795@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730516.1516788266000.88423.1516788301174@Atlassian.JIRA>

Ivo Studensky created WFLY-9726:
-----------------------------------

             Summary: Upgrade JSF based on Mojarra 2.2.13.SP5
                 Key: WFLY-9726
                 URL: https://issues.jboss.org/browse/WFLY-9726
             Project: WildFly
          Issue Type: Component Upgrade
          Components: JSF
            Reporter: Ivo Studensky
            Assignee: Bartosz Spyrko-?mietanko
             Fix For: 11.0.0.Beta1


Upgrade JSF based on Mojarra 2.2.13.SP4. This incorporates the patch for JBEAP-10758/[JAVASERVERFACES-4240 | https://java.net/jira/browse/JAVASERVERFACES-4240]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 24 05:05:01 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Wed, 24 Jan 2018 05:05:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9726) Upgrade JSF based on Mojarra
	2.2.13.SP5
In-Reply-To: <JIRA.12730516.1516788267000@Atlassian.JIRA>
References: <JIRA.12730516.1516788267000@Atlassian.JIRA>
	<JIRA.12730516.1516788267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730516.1516788267000.88432.1516788301440@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9726:
--------------------------------
    Fix Version/s:     (was: 11.0.0.Beta1)


> Upgrade JSF based on Mojarra 2.2.13.SP5
> ---------------------------------------
>
>                 Key: WFLY-9726
>                 URL: https://issues.jboss.org/browse/WFLY-9726
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JSF
>            Reporter: Ivo Studensky
>            Assignee: Bartosz Spyrko-?mietanko
>
> Upgrade JSF based on Mojarra 2.2.13.SP4. This incorporates the patch for JBEAP-10758/[JAVASERVERFACES-4240 | https://java.net/jira/browse/JAVASERVERFACES-4240]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 24 05:05:01 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Wed, 24 Jan 2018 05:05:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9726) Upgrade JSF based on Mojarra
	2.2.13.SP5
In-Reply-To: <JIRA.12730516.1516788267000@Atlassian.JIRA>
References: <JIRA.12730516.1516788267000@Atlassian.JIRA>
	<JIRA.12730516.1516788267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730516.1516788267000.88438.1516788301625@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9726:
--------------------------------
    Git Pull Request:   (was: https://github.com/wildfly/wildfly/pull/10196)


> Upgrade JSF based on Mojarra 2.2.13.SP5
> ---------------------------------------
>
>                 Key: WFLY-9726
>                 URL: https://issues.jboss.org/browse/WFLY-9726
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JSF
>            Reporter: Ivo Studensky
>            Assignee: Bartosz Spyrko-?mietanko
>
> Upgrade JSF based on Mojarra 2.2.13.SP4. This incorporates the patch for JBEAP-10758/[JAVASERVERFACES-4240 | https://java.net/jira/browse/JAVASERVERFACES-4240]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 24 05:07:00 2018
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Wed, 24 Jan 2018 05:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFBUILD-33) Support non-jar artifacts
	properly
In-Reply-To: <JIRA.12730515.1516788245000@Atlassian.JIRA>
References: <JIRA.12730515.1516788245000@Atlassian.JIRA>
	<JIRA.12730515.1516788245000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730515.1516788245000.88460.1516788420552@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFBUILD-33?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522917#comment-13522917 ] 

Peter Palaga commented on WFBUILD-33:
-------------------------------------

Work in progress https://github.com/ppalaga/wildfly-build-tools/commits/WFBUILD-33

> Support non-jar artifacts properly
> ----------------------------------
>
>                 Key: WFBUILD-33
>                 URL: https://issues.jboss.org/browse/WFBUILD-33
>             Project: WildFly Build Tools
>          Issue Type: Bug
>            Reporter: Peter Palaga
>            Assignee: Peter Palaga
>
> The immediate impetus for reporting this is the fact that after upgrading from 1.1.6.Final to 1.2.6.Final our 
> {code}
> <copy-artifact artifact="io.hawt:hawtio-wildfly" to-location="standalone/deployments/"/>
> {code}
> stopped working for the FP plugin. Changing it to 
> {code}<copy-artifact artifact="io.hawt:hawtio-wildfly:war" to-location="standalone/deployments/"/>{code}
> by adding :war made the FP plugin happy, but it made the provisioning plugin fail with an NPE.
> It looks like the code parsing and the rendering the groupId:artifactId:type:classifier:version strings is scattered over several methods whose behavior is not 100% consistent.
> The current objective is:
> (1) Write a few integration tests to pin the behavior before the change, identifying the broken cases
> (2) Write the actual fix in such a way that the plugins stay as backwards compatible as possible.
> I have a fix that works for me, I just need to ensure, my changes keep the plugins backwards compatible.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 05:08:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Wed, 24 Jan 2018 05:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9726) Upgrade JSF based on Mojarra
	2.2.13.SP5
In-Reply-To: <JIRA.12730516.1516788267000@Atlassian.JIRA>
References: <JIRA.12730516.1516788267000@Atlassian.JIRA>
	<JIRA.12730516.1516788267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730516.1516788267000.88465.1516788480269@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9726:
--------------------------------
    Description: Upgrade JSF based on Mojarra 2.2.13.SP. This incorporates the patch for WFLY-8573 / [JAVASERVERFACES_SPEC_PUBLIC-671 | https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-671]  (was: Upgrade JSF based on Mojarra 2.2.13.SP4. This incorporates the patch for JBEAP-10758/[JAVASERVERFACES-4240 | https://java.net/jira/browse/JAVASERVERFACES-4240])


> Upgrade JSF based on Mojarra 2.2.13.SP5
> ---------------------------------------
>
>                 Key: WFLY-9726
>                 URL: https://issues.jboss.org/browse/WFLY-9726
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JSF
>            Reporter: Ivo Studensky
>            Assignee: Bartosz Spyrko-?mietanko
>
> Upgrade JSF based on Mojarra 2.2.13.SP. This incorporates the patch for WFLY-8573 / [JAVASERVERFACES_SPEC_PUBLIC-671 | https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-671]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 24 05:58:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 24 Jan 2018 05:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2244) Use of TP.internal_pool can
 result in classloader leaks
In-Reply-To: <JIRA.12729588.1516229563000@Atlassian.JIRA>
References: <JIRA.12729588.1516229563000@Atlassian.JIRA>
	<JIRA.12729588.1516229563000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729588.1516229563000.88833.1516791480567@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2244?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2244.
----------------------------
    Resolution: Done


Added methods to get and set both the internal pool itself and the associated thread pool factory. You may want to use {{setInternalThreadPool()}} directly...

> Use of TP.internal_pool can result in classloader leaks
> -------------------------------------------------------
>
>                 Key: JGRP-2244
>                 URL: https://issues.jboss.org/browse/JGRP-2244
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0
>            Reporter: Paul Ferraro
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> As of JGroups 4.0, the ThreadFactory of the internal thread pool cannot be overridden.  Consequently, there is no mechanism to associate newly spawned threads with a specific classloader.  If an application thread results in the spawning of an thread in this internal pool [1], the application class loader can leak to other threads used the the JGroups channel.
> [1] https://github.com/belaban/JGroups/blob/master/src/org/jgroups/protocols/TP.java#L1369



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 06:02:00 2018
From: issues at jboss.org (Richard Bourner (JIRA))
Date: Wed, 24 Jan 2018 06:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2267) Scope of enumeration
In-Reply-To: <JIRA.12730522.1516791691000@Atlassian.JIRA>
References: <JIRA.12730522.1516791691000@Atlassian.JIRA>
	<JIRA.12730522.1516791691839@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730522.1516791691000.88862.1516791720374@Atlassian.JIRA>

Richard Bourner created DROOLS-2267:
---------------------------------------

             Summary: Scope of enumeration
                 Key: DROOLS-2267
                 URL: https://issues.jboss.org/browse/DROOLS-2267
             Project: Drools
          Issue Type: Enhancement
          Components: decision tables, Enumerations Editor
    Affects Versions: 6.5.0.Final
         Environment: Business Central / BRMS 6
            Reporter: Richard Bourner
            Assignee: Mario Fusco
            Priority: Minor


Currently the scope of an enumeration file is per package. It would be nice to expand the scope in order to avoir duplicating all enumerations in each package of one project.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 06:07:00 2018
From: issues at jboss.org (Richard Bourner (JIRA))
Date: Wed, 24 Jan 2018 06:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2268) Add more fine-grained
 control on all assets
In-Reply-To: <JIRA.12730525.1516792018000@Atlassian.JIRA>
References: <JIRA.12730525.1516792018000@Atlassian.JIRA>
	<JIRA.12730525.1516792018775@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730525.1516792018000.88900.1516792020135@Atlassian.JIRA>

Richard Bourner created DROOLS-2268:
---------------------------------------

             Summary: Add more fine-grained control on all assets
                 Key: DROOLS-2268
                 URL: https://issues.jboss.org/browse/DROOLS-2268
             Project: Drools
          Issue Type: Enhancement
          Components: Artifact Repository
    Affects Versions: 6.5.0.Final
            Reporter: Richard Bourner
            Assignee: Michael Anstis
            Priority: Minor


Currently, permissions within Business Central are only at projects level.
It would be interesting to be able to enable permissions at a more fine-grained level.
For instance, in a single project of one repository, having some people with read-only access on some assets, and other people have read/write access to the same assets.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 06:11:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 24 Jan 2018 06:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2268) Add more fine-grained
 control on all assets
In-Reply-To: <JIRA.12730525.1516792019000@Atlassian.JIRA>
References: <JIRA.12730525.1516792019000@Atlassian.JIRA>
	<JIRA.12730525.1516792019000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730525.1516792019000.88933.1516792260264@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522959#comment-13522959 ] 

Michael Anstis commented on DROOLS-2268:
----------------------------------------

[~rbourner] I thought you could also assign permissions to roles/groups (of Users)?

[~davidredhat] This is true is it not?

> Add more fine-grained control on all assets
> -------------------------------------------
>
>                 Key: DROOLS-2268
>                 URL: https://issues.jboss.org/browse/DROOLS-2268
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Artifact Repository
>    Affects Versions: 6.5.0.Final
>            Reporter: Richard Bourner
>            Assignee: Michael Anstis
>            Priority: Minor
>
> Currently, permissions within Business Central are only at projects level.
> It would be interesting to be able to enable permissions at a more fine-grained level.
> For instance, in a single project of one repository, having some people with read-only access on some assets, and other people have read/write access to the same assets.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 06:15:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 24 Jan 2018 06:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2266) [DMN Designer] Override
 newSizeHandler for DMNSVGShapeDefImpl
In-Reply-To: <JIRA.12730485.1516782240000@Atlassian.JIRA>
References: <JIRA.12730485.1516782240000@Atlassian.JIRA>
	<JIRA.12730485.1516782240000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730485.1516782240000.88962.1516792500272@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2266:
-----------------------------------
    Sprint: 2018 Week 03-04


> [DMN Designer] Override newSizeHandler for DMNSVGShapeDefImpl
> -------------------------------------------------------------
>
>                 Key: DROOLS-2266
>                 URL: https://issues.jboss.org/browse/DROOLS-2266
>             Project: Drools
>          Issue Type: Enhancement
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>
> Due to changes in JBPM-6512, we should override the _newSizeHandler_ in the class [DMNSVGShapeDefImpl.java|https://github.com/kiegroup/kie-wb-common/blob/master/kie-wb-common-dmn/kie-wb-common-dmn-client/src/main/java/org/kie/workbench/common/dmn/client/shape/def/DMNSVGShapeDefImpl.java] to introduce the same approach in min/max size constraint handling through Stunner, DMN and Forms.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 06:27:00 2018
From: issues at jboss.org (Richard Bourner (JIRA))
Date: Wed, 24 Jan 2018 06:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2268) Add more fine-grained
 control on all assets
In-Reply-To: <JIRA.12730525.1516792019000@Atlassian.JIRA>
References: <JIRA.12730525.1516792019000@Atlassian.JIRA>
	<JIRA.12730525.1516792019000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730525.1516792019000.89047.1516793220131@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522967#comment-13522967 ] 

Richard Bourner commented on DROOLS-2268:
-----------------------------------------

My understanding is that you can indeed assign permissions to roles/groups (using the kie-cli with V6 or the UI in V7) but only at project level, not at rules (or other assets) level.

> Add more fine-grained control on all assets
> -------------------------------------------
>
>                 Key: DROOLS-2268
>                 URL: https://issues.jboss.org/browse/DROOLS-2268
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Artifact Repository
>    Affects Versions: 6.5.0.Final
>            Reporter: Richard Bourner
>            Assignee: Michael Anstis
>            Priority: Minor
>
> Currently, permissions within Business Central are only at projects level.
> It would be interesting to be able to enable permissions at a more fine-grained level.
> For instance, in a single project of one repository, having some people with read-only access on some assets, and other people have read/write access to the same assets.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 06:32:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 24 Jan 2018 06:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2268) Add more fine-grained
 control on all assets
In-Reply-To: <JIRA.12730525.1516792019000@Atlassian.JIRA>
References: <JIRA.12730525.1516792019000@Atlassian.JIRA>
	<JIRA.12730525.1516792019000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730525.1516792019000.89055.1516793520339@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522969#comment-13522969 ] 

Michael Anstis commented on DROOLS-2268:
----------------------------------------

[~rbourner] Ah, my mistake, you're after permissions per file.

[~porcelli] Thoughts?

> Add more fine-grained control on all assets
> -------------------------------------------
>
>                 Key: DROOLS-2268
>                 URL: https://issues.jboss.org/browse/DROOLS-2268
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Artifact Repository
>    Affects Versions: 6.5.0.Final
>            Reporter: Richard Bourner
>            Assignee: Michael Anstis
>            Priority: Minor
>
> Currently, permissions within Business Central are only at projects level.
> It would be interesting to be able to enable permissions at a more fine-grained level.
> For instance, in a single project of one repository, having some people with read-only access on some assets, and other people have read/write access to the same assets.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 06:33:00 2018
From: issues at jboss.org (Richard Bourner (JIRA))
Date: Wed, 24 Jan 2018 06:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2269) Retrieve all rules
 associated to a ruleflow-group
In-Reply-To: <JIRA.12730529.1516793560000@Atlassian.JIRA>
References: <JIRA.12730529.1516793560000@Atlassian.JIRA>
	<JIRA.12730529.1516793560983@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730529.1516793560000.89074.1516793580945@Atlassian.JIRA>

Richard Bourner created DROOLS-2269:
---------------------------------------

             Summary: Retrieve all rules associated to a ruleflow-group
                 Key: DROOLS-2269
                 URL: https://issues.jboss.org/browse/DROOLS-2269
             Project: Drools
          Issue Type: Enhancement
            Reporter: Richard Bourner
            Assignee: Edson Tirelli
            Priority: Minor


It would be very useful to be able to retrieve the list of all business rules associated to a ruleflow-group when editing a ruleflow (ie process) and clicking a RuleTask.
Maybe another way to do it would be via a search using metadata (such as ruleflow-group).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 06:34:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 24 Jan 2018 06:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2246) Internal thread pool not
 created if default thread pool is injected
In-Reply-To: <JIRA.12729969.1516374337000@Atlassian.JIRA>
References: <JIRA.12729969.1516374337000@Atlassian.JIRA>
	<JIRA.12729969.1516374337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729969.1516374337000.89089.1516793640616@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2246:
---------------------------
    Description: 
WildFly injects a custom thread pool into its JGroups transports.

However, in JGroups 4.0.x, only the default thread pool exposes a {{setThreadPool(...)}} method.  The internal thread pool does not.  However, the logic within {{TP.init()}} will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly.

Can we restore the {{TP.setInternalThreadPool(...)}} method?  Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when {{thread_pool_enabled}} is true? 

  was:
WildFly injects a custom thread pool into its JGroups transports.  However, in JGroups 4.0.x, only the default thread pool exposes a setThreadPool(...) method.  The internal thread pool does not.  However, the logic within TP.init() will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly.
Can we restore the TP.setInternalThreadPool(...) method?  Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when thread_pool_enabled is true? 



> Internal thread pool not created if default thread pool is injected
> -------------------------------------------------------------------
>
>                 Key: JGRP-2246
>                 URL: https://issues.jboss.org/browse/JGRP-2246
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.9
>            Reporter: Paul Ferraro
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> WildFly injects a custom thread pool into its JGroups transports.
> However, in JGroups 4.0.x, only the default thread pool exposes a {{setThreadPool(...)}} method.  The internal thread pool does not.  However, the logic within {{TP.init()}} will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly.
> Can we restore the {{TP.setInternalThreadPool(...)}} method?  Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when {{thread_pool_enabled}} is true? 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 06:36:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 24 Jan 2018 06:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2246) Internal thread pool not
 created if default thread pool is injected
In-Reply-To: <JIRA.12729969.1516374337000@Atlassian.JIRA>
References: <JIRA.12729969.1516374337000@Atlassian.JIRA>
	<JIRA.12729969.1516374337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729969.1516374337000.89104.1516793760395@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522970#comment-13522970 ] 

Bela Ban commented on JGRP-2246:
--------------------------------

I added method {{setInternalThreadPool()}} in JGRP-2244. I assume this resolved your issue?

> Internal thread pool not created if default thread pool is injected
> -------------------------------------------------------------------
>
>                 Key: JGRP-2246
>                 URL: https://issues.jboss.org/browse/JGRP-2246
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.9
>            Reporter: Paul Ferraro
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> WildFly injects a custom thread pool into its JGroups transports.
> However, in JGroups 4.0.x, only the default thread pool exposes a {{setThreadPool(...)}} method.  The internal thread pool does not.  However, the logic within {{TP.init()}} will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly.
> Can we restore the {{TP.setInternalThreadPool(...)}} method?  Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when {{thread_pool_enabled}} is true? 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 06:37:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 24 Jan 2018 06:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2246) Internal thread pool not
 created if default thread pool is injected
In-Reply-To: <JIRA.12729969.1516374337000@Atlassian.JIRA>
References: <JIRA.12729969.1516374337000@Atlassian.JIRA>
	<JIRA.12729969.1516374337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729969.1516374337000.89112.1516793820575@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522970#comment-13522970 ] 

Bela Ban edited comment on JGRP-2246 at 1/24/18 6:36 AM:
---------------------------------------------------------

I added method {{setInternalThreadPool()}} in JGRP-2244. I assume this resolved your issue?

And, no, I don't want to create the internal thread pool is {{thread_pool_enabled}} is {{false}}, as this attribute governs the creation of both pools.


was (Author: belaban):
I added method {{setInternalThreadPool()}} in JGRP-2244. I assume this resolved your issue?

> Internal thread pool not created if default thread pool is injected
> -------------------------------------------------------------------
>
>                 Key: JGRP-2246
>                 URL: https://issues.jboss.org/browse/JGRP-2246
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.9
>            Reporter: Paul Ferraro
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> WildFly injects a custom thread pool into its JGroups transports.
> However, in JGroups 4.0.x, only the default thread pool exposes a {{setThreadPool(...)}} method.  The internal thread pool does not.  However, the logic within {{TP.init()}} will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly.
> Can we restore the {{TP.setInternalThreadPool(...)}} method?  Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when {{thread_pool_enabled}} is true? 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 06:37:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 24 Jan 2018 06:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2246) Internal thread pool not
 created if default thread pool is injected
In-Reply-To: <JIRA.12729969.1516374337000@Atlassian.JIRA>
References: <JIRA.12729969.1516374337000@Atlassian.JIRA>
	<JIRA.12729969.1516374337000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729969.1516374337000.89119.1516793820858@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2246?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2246.
----------------------------
    Resolution: Duplicate Issue


Please re-open if needed!

> Internal thread pool not created if default thread pool is injected
> -------------------------------------------------------------------
>
>                 Key: JGRP-2246
>                 URL: https://issues.jboss.org/browse/JGRP-2246
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.9
>            Reporter: Paul Ferraro
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> WildFly injects a custom thread pool into its JGroups transports.
> However, in JGroups 4.0.x, only the default thread pool exposes a {{setThreadPool(...)}} method.  The internal thread pool does not.  However, the logic within {{TP.init()}} will not create an internal thread pool if the default thread pool already exists (and is not shutdown), which is the case in WildFly.
> Can we restore the {{TP.setInternalThreadPool(...)}} method?  Alternatively, assuming JGRP-2244 is fixed, can we fix this logic such that the internal thread pool is always created when {{thread_pool_enabled}} is true? 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 06:39:00 2018
From: issues at jboss.org (rokk ebol (JIRA))
Date: Wed, 24 Jan 2018 06:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2247) RPC does not invoke
 interface's default methods inherited
In-Reply-To: <JIRA.12730182.1516626312000@Atlassian.JIRA>
References: <JIRA.12730182.1516626312000@Atlassian.JIRA>
	<JIRA.12730182.1516626312000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730182.1516626312000.89131.1516793940530@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522973#comment-13522973 ] 

rokk ebol commented on JGRP-2247:
---------------------------------

Great! Thanks
Didn't expect this to be done so fast

> RPC does not invoke interface's default methods inherited
> ---------------------------------------------------------
>
>                 Key: JGRP-2247
>                 URL: https://issues.jboss.org/browse/JGRP-2247
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 4.0.8
>         Environment: jgroups 4.0.8.Final
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
> on win 10
>            Reporter: rokk ebol
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> org.jgroups.blocks.MethodCall#getAllMethods looks for methods up there in superclasses but not in interfaces, which can contain default methods since java 8



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 07:01:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 24 Jan 2018 07:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2247) RPC does not invoke
 interface's default methods inherited
In-Reply-To: <JIRA.12730182.1516626312000@Atlassian.JIRA>
References: <JIRA.12730182.1516626312000@Atlassian.JIRA>
	<JIRA.12730182.1516626312000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730182.1516626312000.89300.1516795260694@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2247?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13522986#comment-13522986 ] 

Bela Ban commented on JGRP-2247:
--------------------------------

No problem! I'm known to be fast! :-)

> RPC does not invoke interface's default methods inherited
> ---------------------------------------------------------
>
>                 Key: JGRP-2247
>                 URL: https://issues.jboss.org/browse/JGRP-2247
>             Project: JGroups
>          Issue Type: Feature Request
>    Affects Versions: 4.0.8
>         Environment: jgroups 4.0.8.Final
> java version "1.8.0_151"
> Java(TM) SE Runtime Environment (build 1.8.0_151-b12)
> Java HotSpot(TM) 64-Bit Server VM (build 25.151-b12, mixed mode)
> on win 10
>            Reporter: rokk ebol
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> org.jgroups.blocks.MethodCall#getAllMethods looks for methods up there in superclasses but not in interfaces, which can contain default methods since java 8



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 07:28:01 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 24 Jan 2018 07:28:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2270) [DMN Editor] Replace
 "Return to DRG" button with Link
In-Reply-To: <JIRA.12730536.1516796869000@Atlassian.JIRA>
References: <JIRA.12730536.1516796869000@Atlassian.JIRA>
	<JIRA.12730536.1516796869487@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730536.1516796869000.89557.1516796881226@Atlassian.JIRA>

Michael Anstis created DROOLS-2270:
--------------------------------------

             Summary: [DMN Editor] Replace "Return to DRG" button with Link
                 Key: DROOLS-2270
                 URL: https://issues.jboss.org/browse/DROOLS-2270
             Project: Drools
          Issue Type: Feature Request
          Components: DMN Editor
    Affects Versions: 7.5.0.Final
            Reporter: Michael Anstis
            Assignee: Michael Anstis


The "Return to DRG" button should be replaced with a "<< Back to XXX" link.

XXX should be the name of the DRG from whence the User came.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 07:29:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 24 Jan 2018 07:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old
 members doesn't seem to get removed
In-Reply-To: <JIRA.12718955.1509544557000@Atlassian.JIRA>
References: <JIRA.12718955.1509544557000@Atlassian.JIRA>
	<JIRA.12718955.1509544557000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718955.1509544557000.89562.1516796940483@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2232:
---------------------------
    Description: 
According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).

Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
967 elements:
{noformat}
i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
...
{noformat}

  was:
According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).

Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
967 elements:
i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
...



> Using NATIVE_S3_PING old members doesn't seem to get removed
> ------------------------------------------------------------
>
>                 Key: JGRP-2232
>                 URL: https://issues.jboss.org/browse/JGRP-2232
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.7
>         Environment: Spring Boot / Boxfuse / AWS
>            Reporter: Jesper Blomquist
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0.10
>
>
> According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
> Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).
> Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
> 967 elements:
> {noformat}
> i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
> i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
> i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
> i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
> i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
> i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
> i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
> i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
> i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
> i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
> i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
> i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 07:29:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 24 Jan 2018 07:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2270) [DMN Editor] Replace
 "Return to DRG" button with Link
In-Reply-To: <JIRA.12730536.1516796869000@Atlassian.JIRA>
References: <JIRA.12730536.1516796869000@Atlassian.JIRA>
	<JIRA.12730536.1516796869000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730536.1516796869000.89566.1516796940598@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2270:
-----------------------------------
    Tester: Jozef Marko


> [DMN Editor] Replace "Return to DRG" button with Link
> -----------------------------------------------------
>
>                 Key: DROOLS-2270
>                 URL: https://issues.jboss.org/browse/DROOLS-2270
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> The "Return to DRG" button should be replaced with a "<< Back to XXX" link.
> XXX should be the name of the DRG from whence the User came.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 07:30:01 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 24 Jan 2018 07:30:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old
 members doesn't seem to get removed
In-Reply-To: <JIRA.12718955.1509544557000@Atlassian.JIRA>
References: <JIRA.12718955.1509544557000@Atlassian.JIRA>
	<JIRA.12718955.1509544557000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718955.1509544557000.89587.1516797001072@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484666#comment-13484666 ] 

Bela Ban edited comment on JGRP-2232 at 1/24/18 7:29 AM:
---------------------------------------------------------

Try reducing {{logical_addr_cache_max_size}} (default: 2000). E.g. set it to 10 0r 20.


was (Author: belaban):
Try reducing {{logical_addr_cache_max_size}} (default: 2000). 

> Using NATIVE_S3_PING old members doesn't seem to get removed
> ------------------------------------------------------------
>
>                 Key: JGRP-2232
>                 URL: https://issues.jboss.org/browse/JGRP-2232
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.7
>         Environment: Spring Boot / Boxfuse / AWS
>            Reporter: Jesper Blomquist
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0.10
>
>
> According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
> Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).
> Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
> 967 elements:
> {noformat}
> i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
> i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
> i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
> i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
> i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
> i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
> i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
> i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
> i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
> i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
> i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
> i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 07:48:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 24 Jan 2018 07:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3075) KeyStore password as
 default KeyManager password
In-Reply-To: <JIRA.12702571.1500456781000@Atlassian.JIRA>
References: <JIRA.12702571.1500456781000@Atlassian.JIRA>
	<JIRA.12702571.1500456781000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702571.1500456781000.89674.1516798080669@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3075?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFCORE-3075:
-------------------------------
    Issue Type: Enhancement  (was: Bug)


> KeyStore password as default KeyManager password
> ------------------------------------------------
>
>                 Key: WFCORE-3075
>                 URL: https://issues.jboss.org/browse/WFCORE-3075
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Security
>            Reporter: Jan Kalina
>            Priority: Critical
>              Labels: keymanager, keystore, trustmanager
>
> In Elytron, there is keystore password (key-store resource) and key password (key-managers resource) required. 
> However in theory there could be cases, where no password can be intended
> - key-store resource for truststore purposes (reading truststore) (but in legacy is password required)
> - PKCS12 can be created without key password (but keystore password in legacy is required)
> - you can create JKS programatically without keystore password
> - *in legacy key password is optional (which mean keystore password is used)*
> From discussion: We can make the password optional on the KeyManager so if no password is specified on the KeyManager we assume it is the one from the KeyStore.
> Created analysis document for this: https://developer.jboss.org/wiki/AnalysisDesign-KeyStorePasswordAsDefaultKeyManagerPassword



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 07:52:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 24 Jan 2018 07:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3541) Missing password types
 set-password operation of modifiable realms
In-Reply-To: <JIRA.12730540.1516798317000@Atlassian.JIRA>
References: <JIRA.12730540.1516798317000@Atlassian.JIRA>
	<JIRA.12730540.1516798317405@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730540.1516798317000.89695.1516798320240@Atlassian.JIRA>

Jan Kalina created WFCORE-3541:
----------------------------------

             Summary: Missing password types set-password operation of modifiable realms
                 Key: WFCORE-3541
                 URL: https://issues.jboss.org/browse/WFCORE-3541
             Project: WildFly Core
          Issue Type: Bug
          Components: Security
    Affects Versions: 4.0.0.Alpha6
            Reporter: Jan Kalina
            Assignee: Jan Kalina
            Priority: Critical


Not all password types are covered by *set-password* operation in ModifiableRealmDecorator.

At least *ScramDigestPassword* is not available.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 07:53:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 24 Jan 2018 07:53:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3541) Missing password types
 set-password operation of modifiable realms
In-Reply-To: <JIRA.12730540.1516798317000@Atlassian.JIRA>
References: <JIRA.12730540.1516798317000@Atlassian.JIRA>
	<JIRA.12730540.1516798317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730540.1516798317000.89714.1516798381133@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFCORE-3541:
-------------------------------
    Labels: elytron  (was: )


> Missing password types set-password operation of modifiable realms
> ------------------------------------------------------------------
>
>                 Key: WFCORE-3541
>                 URL: https://issues.jboss.org/browse/WFCORE-3541
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: elytron
>
> Not all password types are covered by *set-password* operation in ModifiableRealmDecorator.
> At least *ScramDigestPassword* is not available.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 07:53:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 24 Jan 2018 07:53:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3541) Missing password types in
 set-password operation of modifiable realms
In-Reply-To: <JIRA.12730540.1516798317000@Atlassian.JIRA>
References: <JIRA.12730540.1516798317000@Atlassian.JIRA>
	<JIRA.12730540.1516798317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730540.1516798317000.89725.1516798381381@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated WFCORE-3541:
-------------------------------
    Summary: Missing password types in set-password operation of modifiable realms  (was: Missing password types set-password operation of modifiable realms)


> Missing password types in set-password operation of modifiable realms
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-3541
>                 URL: https://issues.jboss.org/browse/WFCORE-3541
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: elytron
>
> Not all password types are covered by *set-password* operation in ModifiableRealmDecorator.
> At least *ScramDigestPassword* is not available.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 07:54:01 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 24 Jan 2018 07:54:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old
 members doesn't seem to get removed
In-Reply-To: <JIRA.12718955.1509544557000@Atlassian.JIRA>
References: <JIRA.12718955.1509544557000@Atlassian.JIRA>
	<JIRA.12718955.1509544557000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718955.1509544557000.89740.1516798441007@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13484666#comment-13484666 ] 

Bela Ban edited comment on JGRP-2232 at 1/24/18 7:53 AM:
---------------------------------------------------------

Try reducing {{logical_addr_cache_max_size}} (default: 2000). E.g. set it to 10 or 20.


was (Author: belaban):
Try reducing {{logical_addr_cache_max_size}} (default: 2000). E.g. set it to 10 0r 20.

> Using NATIVE_S3_PING old members doesn't seem to get removed
> ------------------------------------------------------------
>
>                 Key: JGRP-2232
>                 URL: https://issues.jboss.org/browse/JGRP-2232
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.7
>         Environment: Spring Boot / Boxfuse / AWS
>            Reporter: Jesper Blomquist
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0.10
>
>
> According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
> Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).
> Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
> 967 elements:
> {noformat}
> i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
> i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
> i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
> i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
> i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
> i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
> i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
> i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
> i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
> i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
> i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
> i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 07:54:01 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 24 Jan 2018 07:54:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old
 members doesn't seem to get removed
In-Reply-To: <JIRA.12718955.1509544557000@Atlassian.JIRA>
References: <JIRA.12718955.1509544557000@Atlassian.JIRA>
	<JIRA.12718955.1509544557000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718955.1509544557000.89750.1516798441234@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523020#comment-13523020 ] 

Bela Ban commented on JGRP-2232:
--------------------------------

OK, I can reproduce this even with {{FILE_PING}}, working on it...

> Using NATIVE_S3_PING old members doesn't seem to get removed
> ------------------------------------------------------------
>
>                 Key: JGRP-2232
>                 URL: https://issues.jboss.org/browse/JGRP-2232
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.7
>         Environment: Spring Boot / Boxfuse / AWS
>            Reporter: Jesper Blomquist
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0.10
>
>
> According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
> Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).
> Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
> 967 elements:
> {noformat}
> i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
> i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
> i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
> i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
> i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
> i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
> i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
> i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
> i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
> i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
> i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
> i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 07:57:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Wed, 24 Jan 2018 07:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2270) [DMN Editor] Replace
 "Return to DRG" button with Link
In-Reply-To: <JIRA.12730536.1516796869000@Atlassian.JIRA>
References: <JIRA.12730536.1516796869000@Atlassian.JIRA>
	<JIRA.12730536.1516796869000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730536.1516796869000.89772.1516798620284@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2270:
--------------------------------
    QE Status: ON_QA  (was: NEW)


> [DMN Editor] Replace "Return to DRG" button with Link
> -----------------------------------------------------
>
>                 Key: DROOLS-2270
>                 URL: https://issues.jboss.org/browse/DROOLS-2270
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> The "Return to DRG" button should be replaced with a "<< Back to XXX" link.
> XXX should be the name of the DRG from whence the User came.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 08:59:01 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Wed, 24 Jan 2018 08:59:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2269) Retrieve all rules
 associated to a ruleflow-group
In-Reply-To: <JIRA.12730529.1516793561000@Atlassian.JIRA>
References: <JIRA.12730529.1516793561000@Atlassian.JIRA>
	<JIRA.12730529.1516793561000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730529.1516793561000.90389.1516802341113@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli updated DROOLS-2269:
----------------------------------
    Affects Version/s: 7.5.0.Final


> Retrieve all rules associated to a ruleflow-group
> -------------------------------------------------
>
>                 Key: DROOLS-2269
>                 URL: https://issues.jboss.org/browse/DROOLS-2269
>             Project: Drools
>          Issue Type: Enhancement
>    Affects Versions: 7.5.0.Final
>            Reporter: Richard Bourner
>            Assignee: Edson Tirelli
>            Priority: Minor
>
> It would be very useful to be able to retrieve the list of all business rules associated to a ruleflow-group when editing a ruleflow (ie process) and clicking a RuleTask.
> Maybe another way to do it would be via a search using metadata (such as ruleflow-group).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 09:00:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Wed, 24 Jan 2018 09:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2269) Retrieve all rules
 associated to a ruleflow-group
In-Reply-To: <JIRA.12730529.1516793561000@Atlassian.JIRA>
References: <JIRA.12730529.1516793561000@Atlassian.JIRA>
	<JIRA.12730529.1516793561000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730529.1516793561000.90406.1516802400489@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli updated DROOLS-2269:
----------------------------------
    Component/s: core engine


> Retrieve all rules associated to a ruleflow-group
> -------------------------------------------------
>
>                 Key: DROOLS-2269
>                 URL: https://issues.jboss.org/browse/DROOLS-2269
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Richard Bourner
>            Assignee: Edson Tirelli
>            Priority: Minor
>
> It would be very useful to be able to retrieve the list of all business rules associated to a ruleflow-group when editing a ruleflow (ie process) and clicking a RuleTask.
> Maybe another way to do it would be via a search using metadata (such as ruleflow-group).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 09:00:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Wed, 24 Jan 2018 09:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2269) Retrieve all rules
 associated to a ruleflow-group
In-Reply-To: <JIRA.12730529.1516793561000@Atlassian.JIRA>
References: <JIRA.12730529.1516793561000@Atlassian.JIRA>
	<JIRA.12730529.1516793561000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730529.1516793561000.90412.1516802400649@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned DROOLS-2269:
-------------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)


> Retrieve all rules associated to a ruleflow-group
> -------------------------------------------------
>
>                 Key: DROOLS-2269
>                 URL: https://issues.jboss.org/browse/DROOLS-2269
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Richard Bourner
>            Assignee: Mario Fusco
>            Priority: Minor
>
> It would be very useful to be able to retrieve the list of all business rules associated to a ruleflow-group when editing a ruleflow (ie process) and clicking a RuleTask.
> Maybe another way to do it would be via a search using metadata (such as ruleflow-group).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 09:03:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Wed, 24 Jan 2018 09:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2269) Retrieve all rules
 associated to a ruleflow-group
In-Reply-To: <JIRA.12730529.1516793561000@Atlassian.JIRA>
References: <JIRA.12730529.1516793561000@Atlassian.JIRA>
	<JIRA.12730529.1516793561000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730529.1516793561000.90431.1516802580824@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523074#comment-13523074 ] 

Edson Tirelli commented on DROOLS-2269:
---------------------------------------

There are two sides to this requirement. One is in core, to which [~mfusco] can take a look, but the other one is in the workbench. 

I will clone the ticket for that.


> Retrieve all rules associated to a ruleflow-group
> -------------------------------------------------
>
>                 Key: DROOLS-2269
>                 URL: https://issues.jboss.org/browse/DROOLS-2269
>             Project: Drools
>          Issue Type: Enhancement
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Richard Bourner
>            Assignee: Mario Fusco
>            Priority: Minor
>
> It would be very useful to be able to retrieve the list of all business rules associated to a ruleflow-group when editing a ruleflow (ie process) and clicking a RuleTask.
> Maybe another way to do it would be via a search using metadata (such as ruleflow-group).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 09:03:01 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Wed, 24 Jan 2018 09:03:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2271) Retrieve all rules
 associated to a ruleflow-group
In-Reply-To: <JIRA.12730559.1516802566000@Atlassian.JIRA>
References: <JIRA.12730559.1516802566000@Atlassian.JIRA>
	<JIRA.12730559.1516802566049@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730559.1516802566000.90447.1516802581363@Atlassian.JIRA>

Edson Tirelli created DROOLS-2271:
-------------------------------------

             Summary: Retrieve all rules associated to a ruleflow-group
                 Key: DROOLS-2271
                 URL: https://issues.jboss.org/browse/DROOLS-2271
             Project: Drools
          Issue Type: Enhancement
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Richard Bourner
            Assignee: Mario Fusco
            Priority: Minor


It would be very useful to be able to retrieve the list of all business rules associated to a ruleflow-group when editing a ruleflow (ie process) and clicking a RuleTask.
Maybe another way to do it would be via a search using metadata (such as ruleflow-group).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 09:56:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 24 Jan 2018 09:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3542) Elytron JDBC realm password
 mapping is not consistent with underlying implementation
In-Reply-To: <JIRA.12730594.1516805740000@Atlassian.JIRA>
References: <JIRA.12730594.1516805740000@Atlassian.JIRA>
	<JIRA.12730594.1516805740855@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730594.1516805740000.91255.1516805760218@Atlassian.JIRA>

David Lloyd created WFCORE-3542:
-----------------------------------

             Summary: Elytron JDBC realm password mapping is not consistent with underlying implementation
                 Key: WFCORE-3542
                 URL: https://issues.jboss.org/browse/WFCORE-3542
             Project: WildFly Core
          Issue Type: Bug
          Components: Security
            Reporter: David Lloyd
            Assignee: Darran Lofthouse
             Fix For: 4.0.0.Alpha7


There is no way to configure the JDBC realm to use modular crypt in WildFly, even though the underlying realm does support it.

The problem is that the {{salt-index}} and {{itereration-count-index}} attributes should be optional, and if they not given, a value of {{-1}} should be passed to the mapper.  By omitting both of these values, the database column values will then be recognized as modular-crypt strings.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 09:57:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 24 Jan 2018 09:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3542) Elytron JDBC realm password
 mapping is not consistent with underlying implementation
In-Reply-To: <JIRA.12730594.1516805741000@Atlassian.JIRA>
References: <JIRA.12730594.1516805741000@Atlassian.JIRA>
	<JIRA.12730594.1516805741000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730594.1516805741000.91277.1516805820889@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFCORE-3542:
--------------------------------
    Forum Reference: https://developer.jboss.org/message/979730#979730


> Elytron JDBC realm password mapping is not consistent with underlying implementation
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3542
>                 URL: https://issues.jboss.org/browse/WFCORE-3542
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha7
>
>
> There is no way to configure the JDBC realm to use modular crypt in WildFly, even though the underlying realm does support it.
> The problem is that the {{salt-index}} and {{itereration-count-index}} attributes should be optional, and if they not given, a value of {{-1}} should be passed to the mapper.  By omitting both of these values, the database column values will then be recognized as modular-crypt strings.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 10:13:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 24 Jan 2018 10:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1495) Stack overflow in
 WildFlySecurityManager#checkPermission(Permission, AccessControlContext)
In-Reply-To: <JIRA.12730600.1516806763000@Atlassian.JIRA>
References: <JIRA.12730600.1516806763000@Atlassian.JIRA>
	<JIRA.12730600.1516806763422@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730600.1516806763000.91396.1516806780187@Atlassian.JIRA>

David Lloyd created ELY-1495:
--------------------------------

             Summary: Stack overflow in WildFlySecurityManager#checkPermission(Permission, AccessControlContext)
                 Key: ELY-1495
                 URL: https://issues.jboss.org/browse/ELY-1495
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Security Manager
    Affects Versions: 1.2.0.Beta11
            Reporter: David Lloyd
            Assignee: David Lloyd
            Priority: Blocker
             Fix For: 1.2.0.Beta12


Maybe use Unsafe instead.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 10:22:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 24 Jan 2018 10:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2270) [DMN Editor] Replace
 'Return to DRG' button with Link
In-Reply-To: <JIRA.12730536.1516796869000@Atlassian.JIRA>
References: <JIRA.12730536.1516796869000@Atlassian.JIRA>
	<JIRA.12730536.1516796869000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730536.1516796869000.91429.1516807320142@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2270:
-----------------------------------
    Summary: [DMN Editor] Replace 'Return to DRG' button with Link  (was: [DMN Editor] Replace "Return to DRG" button with Link)


> [DMN Editor] Replace 'Return to DRG' button with Link
> -----------------------------------------------------
>
>                 Key: DROOLS-2270
>                 URL: https://issues.jboss.org/browse/DROOLS-2270
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> The "Return to DRG" button should be replaced with a "<< Back to XXX" link.
> XXX should be the name of the DRG from whence the User came.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 10:52:01 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 24 Jan 2018 10:52:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707798000@Atlassian.JIRA>
References: <JIRA.12725669.1513707798000@Atlassian.JIRA>
	<JIRA.12725669.1513707798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707798000.91646.1516809121020@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523187#comment-13523187 ] 

James Perkins commented on LOGTOOL-132:
---------------------------------------

I'll see what making the class final does (I'll have to read what Andrew wrote about it again too). 

On my preliminary test, not having a final test but loading properties for translations, the metaspace size for the classes decreases about 11%, but the total metaspace size increased by about 1%. I'll test making it final and see what the difference is. I've not tested performance at all yet, but I'll definitely test that too. I do have no doubt there will be a performance impact, but hopefully we can keep it at a minimum.

One option *might* be we have a flag which will generate the original implementation for performance or lookups if metaspace is the concern.

> Support low-metaspace bundles/classes
> -------------------------------------
>
>                 Key: LOGTOOL-132
>                 URL: https://issues.jboss.org/browse/LOGTOOL-132
>             Project: Log Tool
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 11:03:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 24 Jan 2018 11:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707798000@Atlassian.JIRA>
References: <JIRA.12725669.1513707798000@Atlassian.JIRA>
	<JIRA.12725669.1513707798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707798000.91750.1516809780780@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523196#comment-13523196 ] 

David Lloyd commented on LOGTOOL-132:
-------------------------------------

I don't think we'll see a huge drop in performance in the single-logger case: you're still reading the same number of bytes out of the zip file.  The biggest question in my mind is, how do we cache the set of strings so they can be shared across instances?  Having a single-entry cache that has a locale+string array would probably be good enough.  We don't change locales often (well, ever, really) but if we do, I'd expect that it's OK to take a perf hit in that case.

> Support low-metaspace bundles/classes
> -------------------------------------
>
>                 Key: LOGTOOL-132
>                 URL: https://issues.jboss.org/browse/LOGTOOL-132
>             Project: Log Tool
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 11:22:01 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 24 Jan 2018 11:22:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2272) [DMN Editor] Move Editor
	controls inline
In-Reply-To: <JIRA.12730630.1516810899000@Atlassian.JIRA>
References: <JIRA.12730630.1516810899000@Atlassian.JIRA>
	<JIRA.12730630.1516810899959@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730630.1516810899000.92091.1516810921149@Atlassian.JIRA>

Michael Anstis created DROOLS-2272:
--------------------------------------

             Summary: [DMN Editor] Move Editor controls inline
                 Key: DROOLS-2272
                 URL: https://issues.jboss.org/browse/DROOLS-2272
             Project: Drools
          Issue Type: Feature Request
          Components: DMN Editor
    Affects Versions: 7.5.0.Final
            Reporter: Michael Anstis
            Assignee: Michael Anstis


Expression Editors have a row of controls to add row, column, change Hit Policy etc.

These all need moving "inline" into the editor itself. The content of the new context menu will be driven by the cell in the Expression grid that was (single) clicked. Double click continues to edit the cell.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 11:25:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Wed, 24 Jan 2018 11:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2272) [DMN Editor] Move Editor
	controls inline
In-Reply-To: <JIRA.12730630.1516810900000@Atlassian.JIRA>
References: <JIRA.12730630.1516810900000@Atlassian.JIRA>
	<JIRA.12730630.1516810900000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730630.1516810900000.92137.1516811100677@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2272:
-----------------------------------
    Tester: Jozef Marko


> [DMN Editor] Move Editor controls inline
> ----------------------------------------
>
>                 Key: DROOLS-2272
>                 URL: https://issues.jboss.org/browse/DROOLS-2272
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> Expression Editors have a row of controls to add row, column, change Hit Policy etc.
> These all need moving "inline" into the editor itself. The content of the new context menu will be driven by the cell in the Expression grid that was (single) clicked. Double click continues to edit the cell.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 11:27:01 2018
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Wed, 24 Jan 2018 11:27:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-7263) Upgrade HttpClient to 4.5.2
In-Reply-To: <JIRA.12653233.1475608404000@Atlassian.JIRA>
References: <JIRA.12653233.1475608404000@Atlassian.JIRA>
	<JIRA.12653233.1475608404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12653233.1475608404000.92170.1516811221114@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-7263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano resolved WFLY-7263.
-----------------------------------
    Resolution: Out of Date


This is now out-of-date (actually, WildFly 11.0.0.Final shipped with HttpClient 4.5.2).

> Upgrade HttpClient to 4.5.2
> ---------------------------
>
>                 Key: WFLY-7263
>                 URL: https://issues.jboss.org/browse/WFLY-7263
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: REST, Web Services
>            Reporter: James Netherton
>            Assignee: Alessio Soldano
>
> HttpClient 4.5.2 has been available for a while now. Various projects have started to make use of it. It'd be good if WildFly can upgrade. It'd help with integrating some Camel functionality:
> https://github.com/wildfly-extras/wildfly-camel/issues/1357



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 11:29:01 2018
From: issues at jboss.org (Alessio Soldano (JIRA))
Date: Wed, 24 Jan 2018 11:29:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9646) Wsconsume is not able to
 generate jar file from wsdl
In-Reply-To: <JIRA.12726113.1514878188000@Atlassian.JIRA>
References: <JIRA.12726113.1514878188000@Atlassian.JIRA>
	<JIRA.12726113.1514878188000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726113.1514878188000.92239.1516811341279@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Alessio Soldano reassigned WFLY-9646:
-------------------------------------

    Assignee: R Searls  (was: Alessio Soldano)


> Wsconsume is not able to generate jar file from wsdl
> ----------------------------------------------------
>
>                 Key: WFLY-9646
>                 URL: https://issues.jboss.org/browse/WFLY-9646
>             Project: WildFly
>          Issue Type: Bug
>          Components: Scripts, Web Services
>            Reporter: Marek Kopeck?
>            Assignee: R Searls
>            Priority: Blocker
>             Fix For: 12.0.0.Alpha1
>
>
> *Description:*
> Wsconsume is able to generate jar file from wsdl on WildFly 11. On WildFly master, wsconsume doesn't create any files in "out" folder. It leads to Exception from wsdl2java tool.
> *Steps to reproduce:*
> # cd $\{JBOSS_HOME\}/bin
> # # download Echo1.wsdl, Echo1Service.wsdl and Echo1Service_schema1.xsd files, these files are attached to this jira
> # mkdir out
> # ./wsconsume.sh -j wsClientShort.jar -p org.jboss.test.script -o out Echo1Service.wsdl
> *Actual results:*
> {noformat}
> [mkopecky at dhcp-10-40-4-226 bin]$ ./wsconsume.sh -j wsClientShort.jar -p org.jboss.test.script -o out Echo1Service.wsdl
> Could not find log4j.properties or log4j.xml configuration, logging to console.
> Loading FrontEnd jaxws ...
> Loading DataBinding jaxb ...
> wsdl2java -clientjar wsClientShort.jar -compile -exsh false -p org.jboss.test.script -d /home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583 -verbose -classdir /home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out -allowElementReferences file:/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/Echo1Service.wsdl
> wsdl2java - Apache CXF 3.1.12
> JBWS024002: Failed to invoke org.apache.cxf.tools.wsdlto.WSDLToJava
> org.apache.cxf.tools.common.ToolException: java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583/org/jboss/test/script/package-info.java" "read")
> 	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:423)
> 	at org.apache.cxf.tools.common.toolspec.ToolRunner.runTool(ToolRunner.java:105)
> 	at org.apache.cxf.tools.wsdlto.WSDLToJava.run(WSDLToJava.java:113)
> 	at org.jboss.wsf.stack.cxf.tools.CXFConsumerImpl.consume(CXFConsumerImpl.java:313)
> 	at org.jboss.ws.tools.cmd.WSConsume.importServices(WSConsume.java:298)
> 	at org.jboss.ws.tools.cmd.WSConsume.mainInternal(WSConsume.java:108)
> 	at org.jboss.ws.tools.cmd.WSConsume.main(WSConsume.java:96)
> 	at org.jboss.modules.Module.run(Module.java:344)
> 	at org.jboss.modules.Main.main(Main.java:525)
> Caused by: java.security.AccessControlException: access denied ("java.io.FilePermission" "/home/mkopecky/playground/wf/wfly.08/wfly.08/bin/out/tmp3507583/org/jboss/test/script/package-info.java" "read")
> 	at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
> 	at java.security.AccessController.checkPermission(AccessController.java:884)
> 	at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
> 	at java.lang.SecurityManager.checkRead(SecurityManager.java:888)
> 	at java.io.File.isDirectory(File.java:844)
> 	at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:69)
> 	at com.sun.tools.javac.file.RegularFileObject.<init>(RegularFileObject.java:64)
> 	at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromFiles(JavacFileManager.java:785)
> 	at com.sun.tools.javac.file.JavacFileManager.getJavaFileObjectsFromStrings(JavacFileManager.java:185)
> 	at org.apache.cxf.common.util.Compiler.useJava6Compiler(Compiler.java:192)
> 	at org.apache.cxf.common.util.Compiler.compileFiles(Compiler.java:141)
> 	at org.apache.cxf.tools.common.ClassUtils.compile(ClassUtils.java:123)
> 	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.processWsdl(WSDLToJavaContainer.java:306)
> 	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:164)
> 	at org.apache.cxf.tools.wsdlto.WSDLToJavaContainer.execute(WSDLToJavaContainer.java:415)
> 	... 8 more
> [mkopecky at dhcp-10-40-4-226 bin]$ ll out/
> total 0
> [mkopecky at dhcp-10-40-4-226 bin]$
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 24 11:46:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 24 Jan 2018 11:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707798000@Atlassian.JIRA>
References: <JIRA.12725669.1513707798000@Atlassian.JIRA>
	<JIRA.12725669.1513707798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707798000.92442.1516812360266@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523251#comment-13523251 ] 

James Perkins commented on LOGTOOL-132:
---------------------------------------

What I have now is just a simple holder type of class in jboss-logging using a {{HashMap}}. For WildFly we shouldn't see too much of a performance impact since loggers are static. Non-static loggers might see a performance impact though.

A locale prepended key is an interesting idea. That would likely help with fallback messages too.

> Support low-metaspace bundles/classes
> -------------------------------------
>
>                 Key: LOGTOOL-132
>                 URL: https://issues.jboss.org/browse/LOGTOOL-132
>             Project: Log Tool
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 11:49:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 24 Jan 2018 11:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old
 members doesn't seem to get removed
In-Reply-To: <JIRA.12718955.1509544557000@Atlassian.JIRA>
References: <JIRA.12718955.1509544557000@Atlassian.JIRA>
	<JIRA.12718955.1509544557000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718955.1509544557000.92447.1516812540237@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2232.
----------------------------
    Resolution: Done


I fixed the issue, let me know if this works for you

> Using NATIVE_S3_PING old members doesn't seem to get removed
> ------------------------------------------------------------
>
>                 Key: JGRP-2232
>                 URL: https://issues.jboss.org/browse/JGRP-2232
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.7
>         Environment: Spring Boot / Boxfuse / AWS
>            Reporter: Jesper Blomquist
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0.10
>
>
> According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
> Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).
> Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
> 967 elements:
> {noformat}
> i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
> i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
> i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
> i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
> i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
> i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
> i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
> i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
> i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
> i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
> i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
> i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 12:05:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 24 Jan 2018 12:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1496) Test PKCS12
	KeystoreCredentialStore
In-Reply-To: <JIRA.12730635.1516813497000@Atlassian.JIRA>
References: <JIRA.12730635.1516813497000@Atlassian.JIRA>
	<JIRA.12730635.1516813497184@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730635.1516813497000.92526.1516813500200@Atlassian.JIRA>

Jan Kalina created ELY-1496:
-------------------------------

             Summary: Test PKCS12 KeystoreCredentialStore
                 Key: ELY-1496
                 URL: https://issues.jboss.org/browse/ELY-1496
             Project: WildFly Elytron
          Issue Type: Task
          Components: Credential Store
    Affects Versions: 1.2.0.Beta11
            Reporter: Jan Kalina
            Priority: Minor


As part of ELY-1494 was disabled testing with PKCS12 KeyStore on non-oracle JDKs, because following problems:

* IBM and HP (and some older Oracle too) requires provider in signed JAR, which fails on directory of classes used by surefire/junit elytron tests (see ELY-1494)
* * IBM does not allow storing custom objects in PKCS12 KeyStore - allows predefined set of specs/algorithms - this cannot be workarounded currently

This testing should be re-enabled if this will be fixed in mentioned JDKs.

The first problem can be solved on our side too:
* rework junit testing to operate on generated (and possibly signed) elytron JAR
* test this from different module, outside of elytron - when elytron is dependency, it is packed in JAR



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 12:07:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Wed, 24 Jan 2018 12:07:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1496) Test PKCS12
 KeystoreCredentialStore on non-Oracle JDKs
In-Reply-To: <JIRA.12730635.1516813497000@Atlassian.JIRA>
References: <JIRA.12730635.1516813497000@Atlassian.JIRA>
	<JIRA.12730635.1516813497000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730635.1516813497000.92534.1516813621031@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1496:
----------------------------
    Summary: Test PKCS12 KeystoreCredentialStore on non-Oracle JDKs  (was: Test PKCS12 KeystoreCredentialStore)


> Test PKCS12 KeystoreCredentialStore on non-Oracle JDKs
> ------------------------------------------------------
>
>                 Key: ELY-1496
>                 URL: https://issues.jboss.org/browse/ELY-1496
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Credential Store
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Priority: Minor
>
> As part of ELY-1494 was disabled testing with PKCS12 KeyStore on non-oracle JDKs, because following problems:
> * IBM and HP (and some older Oracle too) requires provider in signed JAR, which fails on directory of classes used by surefire/junit elytron tests (see ELY-1494)
> * * IBM does not allow storing custom objects in PKCS12 KeyStore - allows predefined set of specs/algorithms - this cannot be workarounded currently
> This testing should be re-enabled if this will be fixed in mentioned JDKs.
> The first problem can be solved on our side too:
> * rework junit testing to operate on generated (and possibly signed) elytron JAR
> * test this from different module, outside of elytron - when elytron is dependency, it is packed in JAR



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 12:10:00 2018
From: issues at jboss.org (Tom Stiemerling (JIRA))
Date: Wed, 24 Jan 2018 12:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1497) Support Modular Crypt Format
 (MCF) password in Bcrypt mapper
In-Reply-To: <JIRA.12730641.1516813759000@Atlassian.JIRA>
References: <JIRA.12730641.1516813759000@Atlassian.JIRA>
	<JIRA.12730641.1516813759947@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730641.1516813759000.92572.1516813800200@Atlassian.JIRA>

Tom Stiemerling created ELY-1497:
------------------------------------

             Summary: Support Modular Crypt Format (MCF) password in Bcrypt mapper
                 Key: ELY-1497
                 URL: https://issues.jboss.org/browse/ELY-1497
             Project: WildFly Elytron
          Issue Type: Enhancement
          Components: Passwords
    Affects Versions: 1.1.7.Final
            Reporter: Tom Stiemerling


Currently BCrypt mapper for DB realm does not support MCF format passwords (which does not require explicit salt or iterations):

17:42:28,328 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 3) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("jdbc-realm" => "DatabaseRealm")
]) - failure description: "WFLYCTL0155: 'salt-index' may not be null"

Support should be added to support MCF password so only single column needed in DB.

Logic:

if (password && !salt && !iterations)
   assume MCF format password
else if (password && salt && iterations)
  assume BCrypt (b64) password, etc
else
  error




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 12:12:00 2018
From: issues at jboss.org (Tom Stiemerling (JIRA))
Date: Wed, 24 Jan 2018 12:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1497) Support Modular Crypt Format
 (MCF) password in Bcrypt mapper
In-Reply-To: <JIRA.12730641.1516813760000@Atlassian.JIRA>
References: <JIRA.12730641.1516813760000@Atlassian.JIRA>
	<JIRA.12730641.1516813760000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730641.1516813760000.92579.1516813920211@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523273#comment-13523273 ] 

Tom Stiemerling commented on ELY-1497:
--------------------------------------

Discussion thread: https://developer.jboss.org/thread/277056

> Support Modular Crypt Format (MCF) password in Bcrypt mapper
> ------------------------------------------------------------
>
>                 Key: ELY-1497
>                 URL: https://issues.jboss.org/browse/ELY-1497
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Passwords
>    Affects Versions: 1.1.7.Final
>            Reporter: Tom Stiemerling
>
> Currently BCrypt mapper for DB realm does not support MCF format passwords (which does not require explicit salt or iterations):
> 17:42:28,328 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 3) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("jdbc-realm" => "DatabaseRealm")
> ]) - failure description: "WFLYCTL0155: 'salt-index' may not be null"
> Support should be added to support MCF password so only single column needed in DB.
> Logic:
> if (password && !salt && !iterations)
>    assume MCF format password
> else if (password && salt && iterations)
>   assume BCrypt (b64) password, etc
> else
>   error



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 12:15:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 24 Jan 2018 12:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1498) Release WildFly Elytron
	1.2.0.Beta12
In-Reply-To: <JIRA.12730642.1516814071000@Atlassian.JIRA>
References: <JIRA.12730642.1516814071000@Atlassian.JIRA>
	<JIRA.12730642.1516814071770@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730642.1516814071000.92629.1516814100717@Atlassian.JIRA>

Darran Lofthouse created ELY-1498:
-------------------------------------

             Summary: Release WildFly Elytron 1.2.0.Beta12
                 Key: ELY-1498
                 URL: https://issues.jboss.org/browse/ELY-1498
             Project: WildFly Elytron
          Issue Type: Release
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.2.0.Beta12






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 12:37:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 24 Jan 2018 12:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3496) Upgrade WildFly Elytron to
	1.2.0.Beta13
In-Reply-To: <JIRA.12727151.1515509860000@Atlassian.JIRA>
References: <JIRA.12727151.1515509860000@Atlassian.JIRA>
	<JIRA.12727151.1515509860000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727151.1515509860000.92826.1516815420676@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFCORE-3496:
-------------------------------------
    Summary: Upgrade WildFly Elytron to 1.2.0.Beta13  (was: Upgrade WildFly Elytron to 1.2.0.Beta12)


> Upgrade WildFly Elytron to 1.2.0.Beta13
> ---------------------------------------
>
>                 Key: WFCORE-3496
>                 URL: https://issues.jboss.org/browse/WFCORE-3496
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Security
>            Reporter: Ivo Studensky
>            Assignee: Darran Lofthouse
>              Labels: downstream_dependency
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 12:37:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 24 Jan 2018 12:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3543) Upgrade WildFly Elytron to
	1.2.0.Beta12
In-Reply-To: <JIRA.12730664.1516815396000@Atlassian.JIRA>
References: <JIRA.12730664.1516815396000@Atlassian.JIRA>
	<JIRA.12730664.1516815396011@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730664.1516815396000.92829.1516815420780@Atlassian.JIRA>

Darran Lofthouse created WFCORE-3543:
----------------------------------------

             Summary: Upgrade WildFly Elytron to 1.2.0.Beta12
                 Key: WFCORE-3543
                 URL: https://issues.jboss.org/browse/WFCORE-3543
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 4.0.0.Alpha7






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 12:39:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Wed, 24 Jan 2018 12:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3544) Upgrade Elytron Web to
	1.1.0.Beta1
In-Reply-To: <JIRA.12730665.1516815512000@Atlassian.JIRA>
References: <JIRA.12730665.1516815512000@Atlassian.JIRA>
	<JIRA.12730665.1516815512420@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730665.1516815512000.92845.1516815540325@Atlassian.JIRA>

Darran Lofthouse created WFCORE-3544:
----------------------------------------

             Summary: Upgrade Elytron Web to 1.1.0.Beta1
                 Key: WFCORE-3544
                 URL: https://issues.jboss.org/browse/WFCORE-3544
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 4.0.0.Alpha7






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 13:43:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Wed, 24 Jan 2018 13:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707798000@Atlassian.JIRA>
References: <JIRA.12725669.1513707798000@Atlassian.JIRA>
	<JIRA.12725669.1513707798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707798000.92970.1516819380113@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523334#comment-13523334 ] 

James Perkins commented on LOGTOOL-132:
---------------------------------------

Taking a second look I was still generating the generating the {{*$str()}} methods in the implementation. Removing those did significantly reduce the metaspace size of the loggers by about 50%. Marking the implementation as final didn't really change the size that much. Only by about 8 bytes per implementation.

One side question is should we maintain compatibility with older versions of {{jboss-logging}}? If we want to do this I think it would be possible and we could slightly decrease the metaspace size by just removing the static strings.

> Support low-metaspace bundles/classes
> -------------------------------------
>
>                 Key: LOGTOOL-132
>                 URL: https://issues.jboss.org/browse/LOGTOOL-132
>             Project: Log Tool
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 15:44:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 24 Jan 2018 15:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707798000@Atlassian.JIRA>
References: <JIRA.12725669.1513707798000@Atlassian.JIRA>
	<JIRA.12725669.1513707798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707798000.93513.1516826640208@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523380#comment-13523380 ] 

David Lloyd commented on LOGTOOL-132:
-------------------------------------

Re-reading the analysis, I guess that the vtable/itable savings would only occur if we actually rewrote the interface itself into a final class so that there is no inheritance going on at all.

We could retain basic compatibility with older {{jboss-logging}} just by providing a constructor which accepts only a Logger and assumes Locale.ROOT.  It would defeat I18n in this case but I think that's OK: when running with an older {{jboss-logging}} than what the project was compiled for, one must expect problems.

> Support low-metaspace bundles/classes
> -------------------------------------
>
>                 Key: LOGTOOL-132
>                 URL: https://issues.jboss.org/browse/LOGTOOL-132
>             Project: Log Tool
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 16:03:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 24 Jan 2018 16:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1495) Stack overflow in
 WildFlySecurityManager#checkPermission(Permission, AccessControlContext)
In-Reply-To: <JIRA.12730600.1516806763000@Atlassian.JIRA>
References: <JIRA.12730600.1516806763000@Atlassian.JIRA>
	<JIRA.12730600.1516806763000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730600.1516806763000.93585.1516827780680@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1495?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved ELY-1495.
------------------------------
    Resolution: Done


> Stack overflow in WildFlySecurityManager#checkPermission(Permission, AccessControlContext)
> ------------------------------------------------------------------------------------------
>
>                 Key: ELY-1495
>                 URL: https://issues.jboss.org/browse/ELY-1495
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Security Manager
>    Affects Versions: 1.2.0.Beta11
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>            Priority: Blocker
>             Fix For: 1.2.0.Beta12
>
>
> Maybe use Unsafe instead.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 16:53:00 2018
From: issues at jboss.org (Daniel Wiseman (JIRA))
Date: Wed, 24 Jan 2018 16:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9727) WildFly Randomly Terminates
 after 5-10 minutes
In-Reply-To: <JIRA.12730697.1516830752000@Atlassian.JIRA>
References: <JIRA.12730697.1516830752000@Atlassian.JIRA>
	<JIRA.12730697.1516830752671@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730697.1516830752000.93913.1516830780400@Atlassian.JIRA>

Daniel Wiseman created WFLY-9727:
------------------------------------

             Summary: WildFly Randomly Terminates after 5-10 minutes
                 Key: WFLY-9727
                 URL: https://issues.jboss.org/browse/WFLY-9727
             Project: WildFly
          Issue Type: Bug
          Components: Server
    Affects Versions: 10.0.0.Final
         Environment: Running WildFly 10.x from within Eclipse Oxygen (4.7.2) on 2015 MacBook Pro running OS X El Capitan (10.11.6)
            Reporter: Daniel Wiseman
            Assignee: Jason Greene
            Priority: Blocker


I've been experiencing an odd intermittent issue on my WildFly server that has been running on my local system. Every other day or so my server will shutdown, without warning, after running for five to ten minutes from launch. The WildFly server logs contain no errors but the Eclipse logs output these two stack identical stack traces every time:

{{Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
	at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
	at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
	at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
	at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
	at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
	at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)
Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
	at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
	at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
	at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
	at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
	at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
	at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)}}

This issue will occur on every server start for an entire day and then the next day it won't happen at all. However, when it happens it makes debugging the software I write that runs of the server near impossible. Does anyone have any ideas what could be causing this issue? Let me know if you need more details, thanks!



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 17:20:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 24 Jan 2018 17:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9727) WildFly Randomly Terminates
 after 5-10 minutes
In-Reply-To: <JIRA.12730697.1516830753000@Atlassian.JIRA>
References: <JIRA.12730697.1516830753000@Atlassian.JIRA>
	<JIRA.12730697.1516830753000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730697.1516830753000.94122.1516832400145@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523426#comment-13523426 ] 

David Lloyd commented on WFLY-9727:
-----------------------------------

I don't know why the whole server would terminate if Eclipse wasn't terminating it.  As for the exception though, that happens when the NIO selector "goes bad", as it does in some JDKs.  To confirm this problem, you could start the server with the flag {{-Dxnio.nio.selector.provider=sun.nio.ch.PollSelectorProvider}} to see if that solves the issue.

> WildFly Randomly Terminates after 5-10 minutes
> ----------------------------------------------
>
>                 Key: WFLY-9727
>                 URL: https://issues.jboss.org/browse/WFLY-9727
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 10.0.0.Final
>         Environment: Running WildFly 10.x from within Eclipse Oxygen (4.7.2) on 2015 MacBook Pro running OS X El Capitan (10.11.6)
>            Reporter: Daniel Wiseman
>            Assignee: Jason Greene
>            Priority: Blocker
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> I've been experiencing an odd intermittent issue on my WildFly server that has been running on my local system. Every other day or so my server will shutdown, without warning, after running for five to ten minutes from launch. The WildFly server logs contain no errors but the Eclipse logs output these two stack identical stack traces every time:
> {{Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
> 	at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
> 	at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
> 	at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
> 	at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
> 	at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
> 	at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)
> Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
> 	at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
> 	at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
> 	at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
> 	at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
> 	at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
> 	at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)}}
> This issue will occur on every server start for an entire day and then the next day it won't happen at all. However, when it happens it makes debugging the software I write that runs of the server near impossible. Does anyone have any ideas what could be causing this issue? Let me know if you need more details, thanks!



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 18:32:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Wed, 24 Jan 2018 18:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9728) Upgrade jgroups-azure to
	1.2.0.Final
In-Reply-To: <JIRA.12730707.1516836685000@Atlassian.JIRA>
References: <JIRA.12730707.1516836685000@Atlassian.JIRA>
	<JIRA.12730707.1516836685724@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730707.1516836685000.94355.1516836720172@Atlassian.JIRA>

Radoslav Husar created WFLY-9728:
------------------------------------

             Summary: Upgrade jgroups-azure to 1.2.0.Final
                 Key: WFLY-9728
                 URL: https://issues.jboss.org/browse/WFLY-9728
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Clustering
            Reporter: Radoslav Husar
            Assignee: Radoslav Husar
             Fix For: 12.0.0.Alpha1


Upgrade for jgroups 4.0.x and upgrade azure storage client to 6.1.0.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 21:43:00 2018
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Wed, 24 Jan 2018 21:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-47) Failure to get results out of
	ResultSetWrapper
In-Reply-To: <JIRA.12730711.1516848161000@Atlassian.JIRA>
References: <JIRA.12730711.1516848161000@Atlassian.JIRA>
	<JIRA.12730711.1516848161437@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730711.1516848161000.94511.1516848180167@Atlassian.JIRA>

Luis Barreiro created AG-47:
-------------------------------

             Summary: Failure to get results out of ResultSetWrapper
                 Key: AG-47
                 URL: https://issues.jboss.org/browse/AG-47
             Project: Agroal
          Issue Type: Bug
          Components: pool
    Affects Versions: 0.3
            Reporter: Luis Barreiro
            Assignee: Luis Barreiro
            Priority: Critical
             Fix For: 0.4






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 21:50:00 2018
From: issues at jboss.org (Luis Barreiro (JIRA))
Date: Wed, 24 Jan 2018 21:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (AG-47) Failure to get results out of
	ResultSetWrapper
In-Reply-To: <JIRA.12730711.1516848161000@Atlassian.JIRA>
References: <JIRA.12730711.1516848161000@Atlassian.JIRA>
	<JIRA.12730711.1516848161000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730711.1516848161000.94514.1516848600181@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/AG-47?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Luis Barreiro resolved AG-47.
-----------------------------
    Resolution: Done


> Failure to get results out of ResultSetWrapper
> ----------------------------------------------
>
>                 Key: AG-47
>                 URL: https://issues.jboss.org/browse/AG-47
>             Project: Agroal
>          Issue Type: Bug
>          Components: pool
>    Affects Versions: 0.3
>            Reporter: Luis Barreiro
>            Assignee: Luis Barreiro
>            Priority: Critical
>             Fix For: 0.4
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 24 23:36:00 2018
From: issues at jboss.org (jaikiran pai (JIRA))
Date: Wed, 24 Jan 2018 23:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9721) AsyncInvocationTask.get()
 throws CancellationException
In-Reply-To: <JIRA.12730294.1516694725000@Atlassian.JIRA>
References: <JIRA.12730294.1516694725000@Atlassian.JIRA>
	<JIRA.12730294.1516694725000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730294.1516694725000.94561.1516854960105@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523466#comment-13523466 ] 

jaikiran pai commented on WFLY-9721:
------------------------------------

The javadoc of {{Future}} does note that the {{get}} will throw an {{CancellationException}} (runtime) exception if the task was cancelled https://docs.oracle.com/javase/7/docs/api/java/util/concurrent/Future.html#get()



> AsyncInvocationTask.get() throws CancellationException
> ------------------------------------------------------
>
>                 Key: WFLY-9721
>                 URL: https://issues.jboss.org/browse/WFLY-9721
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 11.0.0.Final
>            Reporter: Denis Shklyaev
>            Priority: Optional
>
> AsyncInvocationTask.get() on cancelled task in Wildfly 11 throws CancellationException via EjbLogger, but the behavior is not declared in method signature:
> {{    public synchronized Object get() throws InterruptedException, ExecutionException {
>         for (;;) switch (status) {
>             case ST_RUNNING: wait(); break;
>             *case ST_CANCELLED: throw EjbLogger.ROOT_LOGGER.taskWasCancelled();*
>             case ST_FAILED: throw new ExecutionException(failed);
>             case ST_DONE: return result;
>             default: throw Assert.impossibleSwitchCase(status);
>         }
>     }
> }}
> Wildfly 10.01.0 code is different:
> {{    public synchronized Object get() throws InterruptedException, ExecutionException {
>         while (!isDone()) {
>             wait();
>         }
>         if (failed != null) {
>             throw new ExecutionException(failed);
>         }
>         return result;
>     } 
> }}
> It throws InterruptedException instead as declared.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 02:49:00 2018
From: issues at jboss.org (Osamu Nagano (JIRA))
Date: Thu, 25 Jan 2018 02:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9729) [GSS](7.2.0)
 org.jboss.as.jpa.hibernate5.management.QueryName.displayable() consumes
 high amount of CPU
In-Reply-To: <JIRA.12730722.1516866518000@Atlassian.JIRA>
References: <JIRA.12730722.1516866518000@Atlassian.JIRA>
	<JIRA.12730722.1516866518059@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730722.1516866518000.94838.1516866540068@Atlassian.JIRA>

Osamu Nagano created WFLY-9729:
----------------------------------

             Summary: [GSS](7.2.0) org.jboss.as.jpa.hibernate5.management.QueryName.displayable() consumes high amount of CPU
                 Key: WFLY-9729
                 URL: https://issues.jboss.org/browse/WFLY-9729
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
            Reporter: Osamu Nagano
            Assignee: Osamu Nagano
             Fix For: 12.0.0.Alpha1


JIPI-32 is fixed in the following classes:
{code}
jpa/hibernate4_1/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java
jpa/hibernate4_3/src/main/java/org/jboss/as/jpa/hibernate4/management/QueryName.java
{code}
But not in the following class:
{code}
jpa/hibernate5/src/main/java/org/jboss/as/jpa/hibernate5/management/QueryName.java
{code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 03:02:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Thu, 25 Jan 2018 03:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old
 members doesn't seem to get removed
In-Reply-To: <JIRA.12718955.1509544557000@Atlassian.JIRA>
References: <JIRA.12718955.1509544557000@Atlassian.JIRA>
	<JIRA.12718955.1509544557000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718955.1509544557000.94928.1516867320646@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban reopened JGRP-2232:
----------------------------


Crashed members still re-appear after they've been removed... need to revisit the issue.

> Using NATIVE_S3_PING old members doesn't seem to get removed
> ------------------------------------------------------------
>
>                 Key: JGRP-2232
>                 URL: https://issues.jboss.org/browse/JGRP-2232
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.7
>         Environment: Spring Boot / Boxfuse / AWS
>            Reporter: Jesper Blomquist
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0.10
>
>
> According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
> Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).
> Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
> 967 elements:
> {noformat}
> i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
> i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
> i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
> i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
> i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
> i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
> i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
> i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
> i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
> i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
> i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
> i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 03:07:00 2018
From: issues at jboss.org (Peter Palaga (JIRA))
Date: Thu, 25 Jan 2018 03:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFBUILD-34) Use the same
 groupId:artifactId[:type[:classifier[:version]]] format everywhere
In-Reply-To: <JIRA.12730723.1516867578000@Atlassian.JIRA>
References: <JIRA.12730723.1516867578000@Atlassian.JIRA>
	<JIRA.12730723.1516867578676@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730723.1516867578000.94943.1516867620855@Atlassian.JIRA>

Peter Palaga created WFBUILD-34:
-----------------------------------

             Summary: Use the same groupId:artifactId[:type[:classifier[:version]]] format everywhere
                 Key: WFBUILD-34
                 URL: https://issues.jboss.org/browse/WFBUILD-34
             Project: WildFly Build Tools
          Issue Type: Enhancement
            Reporter: Peter Palaga
            Assignee: Peter Palaga


This both a usability issue and a feature request.

On the usability side, the artifact formats in module.xml files vs. in feature-pack-build.xml files are not the same:

* `{{groupId:artifactId\[:version\[:classifier]]}}` in module.xml files
* `{{groupId:artifactId\[:type\[:classifier]]}}` in feature-pack-build.xml files

The missing feature is the impossibility to define type/extension in module.xml files and the impossibility to had code version in  feature-pack-build.xml files

The current proposal is to use the same {{groupId:artifactId\[:type\[:classifier\[:version]]]}} format in both kinds of files.

The proposal is backwards incompatible for module.xml files. But given that the support for hardcoded versions in module.xml files was added just 11 days ago, this will probably impact just a few users.

I am not sure what artifact format is used by JBoss modules. Maybe `{{groupId:artifactId\[:version\[:classifier]]}}` is taken from there?

WDYT [~swd847]?



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 03:20:01 2018
From: issues at jboss.org (=?UTF-8?Q?=E4=B8=B9=E4=B8=B9_=E7=8E=8B_=28JIRA=29?=)
Date: Thu, 25 Jan 2018 03:20:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2257) Error evaluating constraint
In-Reply-To: <JIRA.12730049.1516610224000@Atlassian.JIRA>
References: <JIRA.12730049.1516610224000@Atlassian.JIRA>
	<JIRA.12730049.1516610224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730049.1516610224000.95013.1516868401900@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523518#comment-13523518 ] 

?? ? commented on DROOLS-2257:
------------------------------

pom.xml
<camunda.version>7.6.0</camunda.version>
<kie.version>7.0.0.Final</kie.version>

> Error evaluating constraint
> ---------------------------
>
>                 Key: DROOLS-2257
>                 URL: https://issues.jboss.org/browse/DROOLS-2257
>             Project: Drools
>          Issue Type: Feature Request
>          Components: docker images
>    Affects Versions: 7.0.0.Final
>            Reporter: ?? ?
>            Assignee: Roger Mart?nez
>
> code?
> {code:java}
>  //?????
> rule "???????"
>     when
>         $materialDecision: SearchDrools(nodeCode.equals(CallActivityEnum.BU_DONG_CHAN_JU_BIAN_GENG.getCode()))
>     then
>         logger.info("access rule: ???????");
> end
> rule "???????????" extends "???????"
>     when
>     then
>         logger.info("access rule: ???????????");
>         $materialDecision.getMaterialResultList().add(new Material().setCode(MaterialCodeConstants.FANG_CHAN_ZHENG).setCopy(0).setNum(1));
>         $materialDecision.getMaterialResultList().add(new Material().setCode(MaterialCodeConstants.JIA_FANG_SHEN_FEN_ZHENG).setCopy(0).setNum(1));
>         $materialDecision.getMaterialResultList().add(new Material().setCode(MaterialCodeConstants.FANG_CHAN_ZHENG).setCopy(1).setNum(1));
>         $materialDecision.getMaterialResultList().add(new Material().setCode(MaterialCodeConstants.JIA_FANG_SHEN_FEN_ZHENG).setCopy(1).setNum(1));
>         $materialDecision.getMaterialResultList().add(new Material().setCode(MaterialCodeConstants.BIAN_GENG_SHOU_LI_TONG_ZHI_SHU).setCopy(0).setNum(1));
>         logger.info("access rule: ?????????????");
>         logger.info("$materialDecision = {}", JSON.toJSON($materialDecision.getMaterialResultList()));
> end
> rule "???????????????" extends "???????"
>     when
>         SearchDrools(
>         $biangengqingkuang: contractData[TradeDataConstants.BIAN_GENG_QING_KUANG];
>         $biangengqingkuang != null
>         && (($biangengqingkuang instanceof String && $biangengqingkuang.equals("????"))
>             || ($biangengqingkuang instanceof List && $biangengqingkuang contains "????"))
>         )
>     then
>         logger.info("access rule: ???????????????");
>         $materialDecision.getMaterialResultList().add(new Material().setCode(MaterialCodeConstants.JIA_FANG_HUN_YIN_ZHENG_MING).setCopy(0).setNum(1));
>         logger.info("access rule: ?????????????????");
>         logger.info("$materialDecision = {}", JSON.toJSON($materialDecision.getMaterialResultList()));
> end
> {code}
> local? everything is ok
> server? error message is belowing. but, when i restart server, everything is ok.
> {panel:title=My title}
> Servlet.service() for servlet [dispatcherServlet] in context with path [] threw exception [Request processing failed; nested exception is java.lang.RuntimeException: Error evaluating constraint '($biangengqingkuang instanceof String && $biangengqingkuang.equals("????")) || ($biangengqingkuang instanceof List && $biangengqingkuang contains "????")' in [Rule "???????????????" in BOOT-xxx.drl]] with root cause
> java.lang.ClassCastException: java.lang.String cannot be cast to java.util.Collection
> 	at ConditionEvaluator403561e24141452a9c4005ea91e84986.evaluate(Unknown Source)
> 	at org.drools.core.rule.constraint.MvelConstraint.evaluate(MvelConstraint.java:261)
> 	at org.drools.core.rule.constraint.MvelConstraint.isAllowed(MvelConstraint.java:216)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:131)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.AlphaNode.assertObject(AlphaNode.java:134)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.doPropagateAssertObject(CompositeObjectSinkAdapter.java:487)
> 	at org.drools.core.reteoo.CompositeObjectSinkAdapter.propagateAssertObject(CompositeObjectSinkAdapter.java:385)
> 	at org.drools.core.reteoo.ObjectTypeNode.propagateAssert(ObjectTypeNode.java:320)
> 	at org.drools.core.phreak.PropagationEntry$Insert.propagate(PropagationEntry.java:161)
> 	at org.drools.core.phreak.PropagationEntry$Insert.execute(PropagationEntry.java:166)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:96)
> 	at org.drools.core.phreak.SynchronizedPropagationList.flush(SynchronizedPropagationList.java:91)
> 	at org.drools.core.common.DefaultAgenda.fireLoop(DefaultAgenda.java:1056)
> 	at org.drools.core.common.DefaultAgenda.internalFireAllRules(DefaultAgenda.java:1019)
> 	at org.drools.core.common.DefaultAgenda.fireAllRules(DefaultAgenda.java:1011)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.internalFireAllRules(StatefulKnowledgeSessionImpl.java:1321)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1312)
> 	at org.drools.core.impl.StatefulKnowledgeSessionImpl.fireAllRules(StatefulKnowledgeSessionImpl.java:1296)
> 	at org.drools.core.impl.StatelessKnowledgeSessionImpl.execute(StatelessKnowledgeSessionImpl.java:269)
> 	at com.zhhl.trade.service.impl.ContractMaterialDroolsServiceImpl.getMaterialResultBeanByDrools(ContractMaterialDroolsServiceImpl.java:85)
> 	at com.zhhl.trade.service.impl.ContractMaterialDroolsServiceImpl$$FastClassBySpringCGLIB$$3874772b.invoke(<generated>)
> 	at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
> 	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
> 	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> 	at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
> 	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:280)
> 	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> 	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> 	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
> 	at com.zhhl.trade.service.impl.ContractMaterialDroolsServiceImpl$$EnhancerBySpringCGLIB$$fb2491d0.getMaterialResultBeanByDrools(<generated>)
> 	at com.zhhl.trade.service.impl.ContractMaterialResultServiceImpl.computeMaterial(ContractMaterialResultServiceImpl.java:51)
> 	at com.zhhl.trade.service.impl.ContractMaterialResultServiceImpl.computeMaterial(ContractMaterialResultServiceImpl.java:80)
> 	at com.zhhl.trade.service.impl.ContractMaterialResultServiceImpl$$FastClassBySpringCGLIB$$e7a85f03.invoke(<generated>)
> 	at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
> 	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
> 	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> 	at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
> 	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:280)
> 	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> 	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> 	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
> 	at com.zhhl.trade.service.impl.ContractMaterialResultServiceImpl$$EnhancerBySpringCGLIB$$8423f058.computeMaterial(<generated>)
> 	at com.zhhl.trade.service.impl.ReservationServiceImpl.setExplanation(ReservationServiceImpl.java:486)
> 	at com.zhhl.trade.service.impl.ReservationServiceImpl.calcExplanation(ReservationServiceImpl.java:392)
> 	at com.zhhl.trade.service.impl.ReservationServiceImpl$$FastClassBySpringCGLIB$$84603545.invoke(<generated>)
> 	at org.springframework.cglib.proxy.MethodProxy.invoke(MethodProxy.java:204)
> 	at org.springframework.aop.framework.CglibAopProxy$CglibMethodInvocation.invokeJoinpoint(CglibAopProxy.java:720)
> 	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:157)
> 	at org.springframework.transaction.interceptor.TransactionInterceptor$1.proceedWithInvocation(TransactionInterceptor.java:99)
> 	at org.springframework.transaction.interceptor.TransactionAspectSupport.invokeWithinTransaction(TransactionAspectSupport.java:280)
> 	at org.springframework.transaction.interceptor.TransactionInterceptor.invoke(TransactionInterceptor.java:96)
> 	at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:179)
> 	at org.springframework.aop.framework.CglibAopProxy$DynamicAdvisedInterceptor.intercept(CglibAopProxy.java:655)
> 	at com.zhhl.trade.service.impl.ReservationServiceImpl$$EnhancerBySpringCGLIB$$96fa6c5e.calcExplanation(<generated>)
> 	at com.zhhl.trade.controller.ReservationControllerV1.explanations(ReservationControllerV1.java:161)
> 	at sun.reflect.GeneratedMethodAccessor668.invoke(Unknown Source)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.springframework.web.method.support.InvocableHandlerMethod.doInvoke(InvocableHandlerMethod.java:221)
> 	at org.springframework.web.method.support.InvocableHandlerMethod.invokeForRequest(InvocableHandlerMethod.java:136)
> 	at org.springframework.web.servlet.mvc.method.annotation.ServletInvocableHandlerMethod.invokeAndHandle(ServletInvocableHandlerMethod.java:114)
> 	at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.invokeHandlerMethod(RequestMappingHandlerAdapter.java:827)
> 	at org.springframework.web.servlet.mvc.method.annotation.RequestMappingHandlerAdapter.handleInternal(RequestMappingHandlerAdapter.java:738)
> 	at org.springframework.web.servlet.mvc.method.AbstractHandlerMethodAdapter.handle(AbstractHandlerMethodAdapter.java:85)
> 	at org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:963)
> 	at org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:897)
> 	at org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:970)
> 	at org.springframework.web.servlet.FrameworkServlet.doPost(FrameworkServlet.java:872)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:648)
> 	at org.springframework.web.servlet.FrameworkServlet.service(FrameworkServlet.java:846)
> 	at javax.servlet.http.HttpServlet.service(HttpServlet.java:729)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:230)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> 	at org.apache.tomcat.websocket.server.WsFilter.doFilter(WsFilter.java:52)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> 	at org.springframework.boot.web.filter.ApplicationContextHeaderFilter.doFilterInternal(ApplicationContextHeaderFilter.java:55)
> 	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> 	at org.springframework.boot.actuate.trace.WebRequestTraceFilter.doFilterInternal(WebRequestTraceFilter.java:105)
> 	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> 	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:317)
> 	at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.invoke(FilterSecurityInterceptor.java:127)
> 	at org.springframework.security.web.access.intercept.FilterSecurityInterceptor.doFilter(FilterSecurityInterceptor.java:91)
> 	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> 	at org.springframework.security.web.access.ExceptionTranslationFilter.doFilter(ExceptionTranslationFilter.java:115)
> 	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> 	at org.springframework.security.web.session.SessionManagementFilter.doFilter(SessionManagementFilter.java:137)
> 	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> 	at org.springframework.security.web.authentication.AnonymousAuthenticationFilter.doFilter(AnonymousAuthenticationFilter.java:111)
> 	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> 	at org.springframework.security.web.servletapi.SecurityContextHolderAwareRequestFilter.doFilter(SecurityContextHolderAwareRequestFilter.java:169)
> 	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> 	at org.springframework.security.web.savedrequest.RequestCacheAwareFilter.doFilter(RequestCacheAwareFilter.java:63)
> 	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> 	at org.springframework.security.oauth2.provider.authentication.OAuth2AuthenticationProcessingFilter.doFilter(OAuth2AuthenticationProcessingFilter.java:176)
> 	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> 	at org.springframework.security.web.authentication.logout.LogoutFilter.doFilter(LogoutFilter.java:121)
> 	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> 	at org.springframework.security.web.header.HeaderWriterFilter.doFilterInternal(HeaderWriterFilter.java:66)
> 	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> 	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> 	at org.springframework.security.web.context.SecurityContextPersistenceFilter.doFilter(SecurityContextPersistenceFilter.java:105)
> 	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> 	at org.springframework.security.web.context.request.async.WebAsyncManagerIntegrationFilter.doFilterInternal(WebAsyncManagerIntegrationFilter.java:56)
> 	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> 	at org.springframework.security.web.FilterChainProxy$VirtualFilterChain.doFilter(FilterChainProxy.java:331)
> 	at org.springframework.security.web.FilterChainProxy.doFilterInternal(FilterChainProxy.java:214)
> 	at org.springframework.security.web.FilterChainProxy.doFilter(FilterChainProxy.java:177)
> 	at org.springframework.web.filter.DelegatingFilterProxy.invokeDelegate(DelegatingFilterProxy.java:346)
> 	at org.springframework.web.filter.DelegatingFilterProxy.doFilter(DelegatingFilterProxy.java:262)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> 	at org.springframework.web.filter.RequestContextFilter.doFilterInternal(RequestContextFilter.java:99)
> 	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> 	at org.springframework.security.oauth2.client.filter.OAuth2ClientContextFilter.doFilter(OAuth2ClientContextFilter.java:60)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> 	at org.springframework.web.filter.HttpPutFormContentFilter.doFilterInternal(HttpPutFormContentFilter.java:87)
> 	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> 	at org.springframework.web.filter.HiddenHttpMethodFilter.doFilterInternal(HiddenHttpMethodFilter.java:77)
> 	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> 	at org.springframework.web.filter.CharacterEncodingFilter.doFilterInternal(CharacterEncodingFilter.java:197)
> 	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> 	at org.springframework.boot.actuate.autoconfigure.MetricsFilter.doFilterInternal(MetricsFilter.java:106)
> 	at org.springframework.web.filter.OncePerRequestFilter.doFilter(OncePerRequestFilter.java:107)
> 	at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:192)
> 	at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:165)
> 	at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:198)
> 	at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:96)
> 	at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:474)
> 	at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:140)
> 	at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:79)
> 	at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:87)
> 	at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:349)
> 	at org.apache.coyote.http11.Http11Processor.service(Http11Processor.java:783)
> 	at org.apache.coyote.AbstractProcessorLight.process(AbstractProcessorLight.java:66)
> 	at org.apache.coyote.AbstractProtocol$ConnectionHandler.process(AbstractProtocol.java:798)
> 	at org.apache.tomcat.util.net.NioEndpoint$SocketProcessor.doRun(NioEndpoint.java:1434)
> 	at org.apache.tomcat.util.net.SocketProcessorBase.run(SocketProcessorBase.java:49)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 	at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61)
> 	at java.lang.Thread.run(Thread.java:745)
> {panel}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 03:55:00 2018
From: issues at jboss.org (Bartosz Baranowski (JIRA))
Date: Thu, 25 Jan 2018 03:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6960) SFSB concurrent access
 timeout when the bean defines CDI producer for another SFSB
In-Reply-To: <JIRA.12643553.1471352454000@Atlassian.JIRA>
References: <JIRA.12643553.1471352454000@Atlassian.JIRA>
	<JIRA.12643553.1471352454000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12643553.1471352454000.95327.1516870500999@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bartosz Baranowski reassigned WFLY-6960:
----------------------------------------

    Assignee:     (was: JBoss SET)


> SFSB concurrent access timeout when the bean defines CDI producer for another SFSB
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-6960
>                 URL: https://issues.jboss.org/browse/WFLY-6960
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 10.0.0.Final, 10.1.0.CR1
>            Reporter: Tomas Remes
>         Attachments: 0001-Use-EJB-as-opposed-to-Inject.patch, test-case.zip
>
>
> In the given scenario there are two calls to {{org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor#processInvocation}} in the same thread. In the first call the {{OwnableReentrantLock}} is obtained but it couldn't be reentered in the second call. This results to:
> {noformat}
> 14:54:21,184 ERROR [org.jboss.as.ejb3.invocation] (pool-2-thread-2) WFLYEJB0034: EJB Invocation failed on component SFBean1 for method public org.jboss.weld.tests.ejb.stateful.producer.Foo org.jboss.weld.tests.ejb.stateful.producer.SFBean1.produceString(): javax.ejb.ConcurrentAccessTimeoutException: WFLYEJB0228: EJB 3.1 FR 4.3.14.1 concurrent access timeout on SFBean1 - could not obtain lock within 5000 MILLISECONDS
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:86)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$$$view5.produceString(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean1$Proxy$_$$_Weld$EnterpriseProxy$.produceString(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:88)
> 	at org.jboss.weld.injection.StaticMethodInjectionPoint.invoke(StaticMethodInjectionPoint.java:78)
> 	at org.jboss.weld.injection.producer.ProducerMethodProducer.produce(ProducerMethodProducer.java:99)
> 	at org.jboss.weld.injection.producer.AbstractMemberProducer.produce(AbstractMemberProducer.java:161)
> 	at org.jboss.weld.bean.AbstractProducerBean.create(AbstractProducerBean.java:181)
> 	at org.jboss.weld.context.unbound.DependentContextImpl.get(DependentContextImpl.java:70)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> 	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> 	at org.jboss.weld.manager.BeanManagerImpl.getReference(BeanManagerImpl.java:742)
> 	at org.jboss.weld.manager.BeanManagerImpl.getInjectableReference(BeanManagerImpl.java:842)
> 	at org.jboss.weld.injection.FieldInjectionPoint.inject(FieldInjectionPoint.java:92)
> 	at org.jboss.weld.util.Beans.injectBoundFields(Beans.java:378)
> 	at org.jboss.weld.util.Beans.injectFieldsAndInitializers(Beans.java:389)
> 	at org.jboss.weld.injection.producer.DefaultInjector$1.proceed(DefaultInjector.java:71)
> 	at org.jboss.weld.injection.InjectionContextImpl.run(InjectionContextImpl.java:48)
> 	at org.jboss.weld.injection.producer.DefaultInjector.inject(DefaultInjector.java:73)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanInjectionTarget.inject(SessionBeanInjectionTarget.java:140)
> 	at org.jboss.as.weld.injection.WeldInjectionContext.inject(WeldInjectionContext.java:39)
> 	at org.jboss.as.weld.injection.WeldInjectionInterceptor.processInvocation(WeldInjectionInterceptor.java:51)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.AroundConstructInterceptorFactory$1.processInvocation(AroundConstructInterceptorFactory.java:28)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInterceptorInjectionInterceptor.processInvocation(WeldInterceptorInjectionInterceptor.java:56)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsCreateInterceptor.processInvocation(Jsr299BindingsCreateInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInNoTx(CMTTxInterceptor.java:263)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.notSupported(CMTTxInterceptor.java:308)
> 	at org.jboss.as.ejb3.tx.LifecycleCMTTxInterceptor.processInvocation(LifecycleCMTTxInterceptor.java:62)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBPreCreateInterceptor.processInvocation(SFSBPreCreateInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.weld.injection.WeldInjectionContextInterceptor.processInvocation(WeldInjectionContextInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:161)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:150)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.constructComponentInstance(BasicComponent.java:134)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:145)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.constructComponentInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ee.component.BasicComponent.createInstance(BasicComponent.java:88)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:135)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createInstance(StatefulSessionComponent.java:75)
> 	at org.jboss.as.ejb3.cache.simple.SimpleCache.create(SimpleCache.java:118)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionComponent.createSession(StatefulSessionComponent.java:238)
> 	at org.jboss.as.weld.ejb.StatefulSessionObjectReferenceImpl.<init>(StatefulSessionObjectReferenceImpl.java:70)
> 	at org.jboss.as.weld.services.bootstrap.WeldEjbServices.resolveEjb(WeldEjbServices.java:53)
> 	at org.jboss.weld.bean.SessionBean.createReference(SessionBean.java:230)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:83)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.<init>(EnterpriseBeanProxyMethodHandler.java:63)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.createEnterpriseTargetBeanInstance(SessionBeanProxyInstantiator.java:80)
> 	at org.jboss.weld.injection.producer.ejb.SessionBeanProxyInstantiator.newInstance(SessionBeanProxyInstantiator.java:61)
> 	at org.jboss.weld.bean.SessionBean.create(SessionBean.java:149)
> 	at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:96)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$DefaultContextualInstanceStrategy.get(ContextualInstanceStrategy.java:101)
> 	at org.jboss.weld.bean.ContextualInstanceStrategy$CachingContextualInstanceStrategy.get(ContextualInstanceStrategy.java:178)
> 	at org.jboss.weld.bean.ContextualInstance.get(ContextualInstance.java:50)
> 	at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:99)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.getInstance(ProxyMethodHandler.java:125)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean2$Proxy$_$$_WeldClientProxy.foo(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3.ping(SFBean3.java:19)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.as.ee.component.ManagedReferenceMethodInterceptor.processInvocation(ManagedReferenceMethodInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.doMethodInterception(Jsr299BindingsInterceptor.java:82)
> 	at org.jboss.as.weld.ejb.Jsr299BindingsInterceptor.processInvocation(Jsr299BindingsInterceptor.java:93)
> 	at org.jboss.as.ee.component.interceptors.UserInterceptorFactory$1.processInvocation(UserInterceptorFactory.java:63)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.ExecutionTimeInterceptor.processInvocation(ExecutionTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SBInvocationInterceptor.processInvocation(SBInvocationInterceptor.java:47)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.jpa.interceptor.SFSBInvocationInterceptor.processInvocation(SFSBInvocationInterceptor.java:57)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulSessionSynchronizationInterceptor.processInvocation(StatefulSessionSynchronizationInterceptor.java:125)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext$Invocation.proceed(InterceptorContext.java:437)
> 	at org.jboss.weld.ejb.AbstractEJBRequestScopeActivationInterceptor.aroundInvoke(AbstractEJBRequestScopeActivationInterceptor.java:64)
> 	at org.jboss.as.weld.ejb.EjbRequestScopeActivationInterceptor.processInvocation(EjbRequestScopeActivationInterceptor.java:83)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.concurrent.ConcurrentContextInterceptor.processInvocation(ConcurrentContextInterceptor.java:45)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InitialInterceptor.processInvocation(InitialInterceptor.java:21)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.interceptors.ComponentDispatcherInterceptor.processInvocation(ComponentDispatcherInterceptor.java:52)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.stateful.StatefulComponentInstanceInterceptor.processInvocation(StatefulComponentInstanceInterceptor.java:65)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.invokeInOurTx(CMTTxInterceptor.java:275)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.required(CMTTxInterceptor.java:327)
> 	at org.jboss.as.ejb3.tx.CMTTxInterceptor.processInvocation(CMTTxInterceptor.java:239)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.CurrentInvocationContextInterceptor.processInvocation(CurrentInvocationContextInterceptor.java:41)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.invocationmetrics.WaitTimeInterceptor.processInvocation(WaitTimeInterceptor.java:43)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.security.SecurityContextInterceptor.processInvocation(SecurityContextInterceptor.java:100)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.ShutDownInterceptorFactory$1.processInvocation(ShutDownInterceptorFactory.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.LoggingInterceptor.processInvocation(LoggingInterceptor.java:66)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ee.component.NamespaceContextInterceptor.processInvocation(NamespaceContextInterceptor.java:50)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.as.ejb3.component.interceptors.AdditionalSetupInterceptor.processInvocation(AdditionalSetupInterceptor.java:54)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ContextClassLoaderInterceptor.processInvocation(ContextClassLoaderInterceptor.java:64)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:636)
> 	at org.jboss.invocation.AccessCheckingInterceptor.processInvocation(AccessCheckingInterceptor.java:61)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.InterceptorContext.run(InterceptorContext.java:356)
> 	at org.jboss.invocation.PrivilegedWithCombinerInterceptor.processInvocation(PrivilegedWithCombinerInterceptor.java:80)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ViewService$View.invoke(ViewService.java:195)
> 	at org.jboss.as.ee.component.ViewDescription$1.processInvocation(ViewDescription.java:185)
> 	at org.jboss.invocation.InterceptorContext.proceed(InterceptorContext.java:340)
> 	at org.jboss.invocation.ChainedInterceptor.processInvocation(ChainedInterceptor.java:61)
> 	at org.jboss.as.ee.component.ProxyInvocationHandler.invoke(ProxyInvocationHandler.java:73)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$$$view6.ping(Unknown Source)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:497)
> 	at org.jboss.weld.util.reflection.Reflections.invokeAndUnwrap(Reflections.java:436)
> 	at org.jboss.weld.bean.proxy.EnterpriseBeanProxyMethodHandler.invoke(EnterpriseBeanProxyMethodHandler.java:127)
> 	at org.jboss.weld.bean.proxy.EnterpriseTargetBeanInstance.invoke(EnterpriseTargetBeanInstance.java:56)
> 	at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:100)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_Weld$EnterpriseProxy$.ping(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.SFBean3$Proxy$_$$_WeldClientProxy.ping(Unknown Source)
> 	at org.jboss.weld.tests.ejb.stateful.producer.ConcurrentAccessTest.test(ConcurrentAccessTest.java:31)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 04:01:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 25 Jan 2018 04:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1952) [DMN Editor] Introduce
 marshalling test in the way DMN - String - DMN
In-Reply-To: <JIRA.12709371.1504084484000@Atlassian.JIRA>
References: <JIRA.12709371.1504084484000@Atlassian.JIRA>
	<JIRA.12709371.1504084484000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12709371.1504084484000.95360.1516870860776@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523550#comment-13523550 ] 

Jozef Marko commented on DROOLS-1952:
-------------------------------------

[~manstis] thanks for bringing this into front, I have to check current tests.

> [DMN Editor] Introduce marshalling test in the way DMN - String - DMN
> ---------------------------------------------------------------------
>
>                 Key: DROOLS-1952
>                 URL: https://issues.jboss.org/browse/DROOLS-1952
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>    Affects Versions: 7.2.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>
> Currently marshaling test assumes as the initial input a *.dmn file that is consequently converted to Graph, next this Graph is converted to XML and finally the XML is transformed to Graph that is asserted for required properties.
> This task should introduce test that will assume as an initial input Graph, that will be converted to JSON, this JSON will be converted again to Graph and finally this Graph will be asserted for required properties.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 04:07:00 2018
From: issues at jboss.org (Marek Marusic (JIRA))
Date: Thu, 25 Jan 2018 04:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3187) add-user.sh tool prints
 unexpected characters if arrow keys are pushed during interactive mode
In-Reply-To: <JIRA.12707667.1502875109000@Atlassian.JIRA>
References: <JIRA.12707667.1502875109000@Atlassian.JIRA>
	<JIRA.12707667.1502875109000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12707667.1502875109000.95400.1516871220777@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3187?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Marusic updated WFCORE-3187:
----------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2715, https://github.com/wildfly/wildfly-core/pull/3064  (was: https://github.com/wildfly/wildfly-core/pull/2715)


> add-user.sh tool prints unexpected characters if arrow keys are pushed during interactive mode
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3187
>                 URL: https://issues.jboss.org/browse/WFCORE-3187
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Security
>    Affects Versions: 3.0.0.Beta29
>            Reporter: Marek Marusic
>            Assignee: Marek Marusic
>            Priority: Minor
>
> *Description of problem:*
> add-user.sh tool prints unexpected characters if arrow keys are pushed during interactive mode.
> *How reproducible:*
> Always
> *Steps to Reproduce:*
> # ./add-user.sh 
> # press  ?,?,?,? keys
> *Actual results:*
> {noformat}
> [mkopecky at localhost bin]$ ./add-user.sh 
> What type of user do you wish to add? 
>  a) Management User (mgmt-users.properties) 
>  b) Application User (application-users.properties)
> (a): ^[[D^[[A^[[C^[[B
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 04:22:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 25 Jan 2018 04:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1497) Support Modular Crypt Format
 (MCF) password in Bcrypt mapper
In-Reply-To: <JIRA.12730641.1516813760000@Atlassian.JIRA>
References: <JIRA.12730641.1516813760000@Atlassian.JIRA>
	<JIRA.12730641.1516813760000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730641.1516813760000.95550.1516872120340@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1497:
------------------------------
    Description: 
Currently BCrypt mapper for DB realm does not support MCF format passwords (which does not require explicit salt or iterations):
{noformat}
17:42:28,328 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 3) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("jdbc-realm" => "DatabaseRealm")
]) - failure description: "WFLYCTL0155: 'salt-index' may not be null"
{noformat}
Support should be added to support MCF password so only single column needed in DB.

Logic:
{code}
if (password && !salt && !iterations)
   assume MCF format password
else if (password && salt && iterations)
  assume BCrypt (b64) password, etc
else
  error
{code}

  was:
Currently BCrypt mapper for DB realm does not support MCF format passwords (which does not require explicit salt or iterations):

17:42:28,328 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 3) WFLYCTL0013: Operation ("add") failed - address: ([
    ("subsystem" => "elytron"),
    ("jdbc-realm" => "DatabaseRealm")
]) - failure description: "WFLYCTL0155: 'salt-index' may not be null"

Support should be added to support MCF password so only single column needed in DB.

Logic:

if (password && !salt && !iterations)
   assume MCF format password
else if (password && salt && iterations)
  assume BCrypt (b64) password, etc
else
  error




> Support Modular Crypt Format (MCF) password in Bcrypt mapper
> ------------------------------------------------------------
>
>                 Key: ELY-1497
>                 URL: https://issues.jboss.org/browse/ELY-1497
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Passwords
>    Affects Versions: 1.1.7.Final
>            Reporter: Tom Stiemerling
>
> Currently BCrypt mapper for DB realm does not support MCF format passwords (which does not require explicit salt or iterations):
> {noformat}
> 17:42:28,328 ERROR [org.jboss.as.controller.management-operation] (ServerService Thread Pool -- 3) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "elytron"),
>     ("jdbc-realm" => "DatabaseRealm")
> ]) - failure description: "WFLYCTL0155: 'salt-index' may not be null"
> {noformat}
> Support should be added to support MCF password so only single column needed in DB.
> Logic:
> {code}
> if (password && !salt && !iterations)
>    assume MCF format password
> else if (password && salt && iterations)
>   assume BCrypt (b64) password, etc
> else
>   error
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 04:51:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Thu, 25 Jan 2018 04:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2272) [DMN Editor] Move Editor
	controls inline
In-Reply-To: <JIRA.12730630.1516810900000@Atlassian.JIRA>
References: <JIRA.12730630.1516810900000@Atlassian.JIRA>
	<JIRA.12730630.1516810900000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730630.1516810900000.95740.1516873860833@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2272?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2272:
--------------------------------
    QE Status: ON_QA  (was: NEW)


> [DMN Editor] Move Editor controls inline
> ----------------------------------------
>
>                 Key: DROOLS-2272
>                 URL: https://issues.jboss.org/browse/DROOLS-2272
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> Expression Editors have a row of controls to add row, column, change Hit Policy etc.
> These all need moving "inline" into the editor itself. The content of the new context menu will be driven by the cell in the Expression grid that was (single) clicked. Double click continues to edit the cell.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 05:26:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 25 Jan 2018 05:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9730) Upgrade FasterXML Jackson to
	2.8.12
In-Reply-To: <JIRA.12730748.1516875890000@Atlassian.JIRA>
References: <JIRA.12730748.1516875890000@Atlassian.JIRA>
	<JIRA.12730748.1516875890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730748.1516875890000.96128.1516875960645@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9730:
--------------------------------
    Security:     (was: Red Hat Internal)


> Upgrade FasterXML Jackson to 2.8.12
> -----------------------------------
>
>                 Key: WFLY-9730
>                 URL: https://issues.jboss.org/browse/WFLY-9730
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Server
>            Reporter: Ivo Studensky
>            Assignee: Jason Greene
>              Labels: downstream_dependency
>
> diff between the current version and the proposed one:
> https://github.com/FasterXML/jackson-databind/compare/jackson-databind-2.8.9...jackson-databind-2.8.11



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 05:28:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 25 Jan 2018 05:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9730) Upgrade FasterXML Jackson to
	2.8.12
In-Reply-To: <JIRA.12730748.1516875890000@Atlassian.JIRA>
References: <JIRA.12730748.1516875890000@Atlassian.JIRA>
	<JIRA.12730748.1516875890000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730748.1516875890000.96156.1516876080648@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9730?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9730:
--------------------------------
    Description: Upgrade FasterXML in order to include https://github.com/FasterXML/jackson-databind/issues/1899.  (was: diff between the current version and the proposed one:
https://github.com/FasterXML/jackson-databind/compare/jackson-databind-2.8.9...jackson-databind-2.8.11)


> Upgrade FasterXML Jackson to 2.8.12
> -----------------------------------
>
>                 Key: WFLY-9730
>                 URL: https://issues.jboss.org/browse/WFLY-9730
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Server
>            Reporter: Ivo Studensky
>            Assignee: Jason Greene
>              Labels: downstream_dependency
>
> Upgrade FasterXML in order to include https://github.com/FasterXML/jackson-databind/issues/1899.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 05:43:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 25 Jan 2018 05:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2270) [DMN Editor] Replace
 'Return to DRG' button with Link
In-Reply-To: <JIRA.12730536.1516796869000@Atlassian.JIRA>
References: <JIRA.12730536.1516796869000@Atlassian.JIRA>
	<JIRA.12730536.1516796869000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730536.1516796869000.96253.1516876980398@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Michael Anstis updated DROOLS-2270:
-----------------------------------
    Attachment: DROOLS-2270.png


> [DMN Editor] Replace 'Return to DRG' button with Link
> -----------------------------------------------------
>
>                 Key: DROOLS-2270
>                 URL: https://issues.jboss.org/browse/DROOLS-2270
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>         Attachments: DROOLS-2270.png
>
>
> The "Return to DRG" button should be replaced with a "<< Back to XXX" link.
> XXX should be the name of the DRG from whence the User came.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:04:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1498) Release WildFly Elytron
	1.2.0.Beta12
In-Reply-To: <JIRA.12730642.1516814072000@Atlassian.JIRA>
References: <JIRA.12730642.1516814072000@Atlassian.JIRA>
	<JIRA.12730642.1516814072000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730642.1516814072000.96809.1516881840355@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1498?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse resolved ELY-1498.
-----------------------------------
    Resolution: Done


> Release WildFly Elytron 1.2.0.Beta12
> ------------------------------------
>
>                 Key: ELY-1498
>                 URL: https://issues.jboss.org/browse/ELY-1498
>             Project: WildFly Elytron
>          Issue Type: Release
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta12
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:01 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Thu, 25 Jan 2018 07:05:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2273) [DMN Editor] Contextual
 selection - Hover state
In-Reply-To: <JIRA.12730777.1516881868000@Atlassian.JIRA>
References: <JIRA.12730777.1516881868000@Atlassian.JIRA>
	<JIRA.12730777.1516881868443@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730777.1516881868000.96817.1516881901448@Atlassian.JIRA>

Michael Anstis created DROOLS-2273:
--------------------------------------

             Summary: [DMN Editor] Contextual selection - Hover state
                 Key: DROOLS-2273
                 URL: https://issues.jboss.org/browse/DROOLS-2273
             Project: Drools
          Issue Type: Feature Request
          Components: DMN Editor
            Reporter: Michael Anstis
            Assignee: Michael Anstis


Elements within a logic table that offer contextual actions will present a hover state on focus. Examples of elements that might offer actions include: Rows, cells, columns, table? Or in context terms: Rules, Inputs/Outputs, Context row, etc



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 07:05:01 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1489) FormAuthenticationMechanism
 should only create a session if an identity is being stored
In-Reply-To: <JIRA.12729311.1516126486000@Atlassian.JIRA>
References: <JIRA.12729311.1516126486000@Atlassian.JIRA>
	<JIRA.12729311.1516126486000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729311.1516126486000.96820.1516881901557@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1489:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> FormAuthenticationMechanism should only create a session if an identity is being stored
> ---------------------------------------------------------------------------------------
>
>                 Key: ELY-1489
>                 URL: https://issues.jboss.org/browse/ELY-1489
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta13
>
>
> We don't need this internal method to contain the boolean argument: -
> {code}
> private IdentityCache createIdentityCache(HttpServerRequest request, boolean createSession) {
> {code}
> A subsequent call to put is sufficient for us to know a session is needed, an all other cases don't create the session.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:01 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.96825.1516881901728@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1483:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta13
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:
> {noformat}
> [ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
> {noformat}
> But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?
> False positives because packages asn/x500 were not public in 1.1.7.final :
> - removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:01 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1475) Empty username for
 FormAuthenticationMechanism causes IllegalArgumentException
In-Reply-To: <JIRA.12726352.1514982408000@Atlassian.JIRA>
References: <JIRA.12726352.1514982408000@Atlassian.JIRA>
	<JIRA.12726352.1514982408000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726352.1514982408000.96829.1516881901808@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1475:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> Empty username for FormAuthenticationMechanism causes IllegalArgumentException
> ------------------------------------------------------------------------------
>
>                 Key: ELY-1475
>                 URL: https://issues.jboss.org/browse/ELY-1475
>             Project: WildFly Elytron
>          Issue Type: Bug
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Ondrej Lukas
>            Assignee: Ilia Vassilev
>             Fix For: 1.2.0.Beta13
>
>
> In case when empty username is passed to FormAuthenticationMechanism.attemptAuthentication then IllegalArgumentException is thrown from constructor of NameCallback. This happens in cases when form is sent with empty value for j_username.
> See exception:
> {code}
> ERROR [io.undertow.request] (default task-18) UT005023: Exception handling request to /depForm/j_security_check: java.lang.IllegalArgumentException
> 	at javax.security.auth.callback.NameCallback.<init>(NameCallback.java:90)
> 	at org.wildfly.security.http.impl.UsernamePasswordAuthenticationMechanism.authenticate(UsernamePasswordAuthenticationMechanism.java:60)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.attemptAuthentication(FormAuthenticationMechanism.java:172)
> 	at org.wildfly.security.http.impl.FormAuthenticationMechanism.evaluateRequest(FormAuthenticationMechanism.java:106)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> 	at java.lang.Thread.run(Thread.java:748)
> {code}
> It seems that [1] should also check {{username.length() == 0}}.
> [1] https://github.com/wildfly-security/wildfly-elytron/blob/32ff7c17965b3ecae6be7ce1c9b96ab642ddc4ad/src/main/java/org/wildfly/security/http/impl/FormAuthenticationMechanism.java#L165



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:01 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1474) GssapiCompatibilitySuiteChild
 fails on solaris
In-Reply-To: <JIRA.12726223.1514900643000@Atlassian.JIRA>
References: <JIRA.12726223.1514900643000@Atlassian.JIRA>
	<JIRA.12726223.1514900643000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726223.1514900643000.96833.1516881901906@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1474:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> GssapiCompatibilitySuiteChild fails on solaris
> ----------------------------------------------
>
>                 Key: ELY-1474
>                 URL: https://issues.jboss.org/browse/ELY-1474
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta13
>
>
> - On same java (Oracle java) test does not fail on other OS
> - We don't test other javas on solaris OS
> Problem is on line comparing expected sasl message witch actual.
> {code:java|title=GssapiCompatibilitySuiteChild}
> exchange = evaluateByClient(exchange);
>         assertEquals(" ", ByteIterator.ofBytes(exchange).hexEncode().drainToString());
> {code}
> Stacktrace
> {noformat}
> org.junit.ComparisonFailure: expected:<...03020110a281bf0481bc[ ]> but was:<...03020110a281bf0481bc[ ]>
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:121)
> {noformat}
> Log
> {noformat}
> 19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:52> loginClient
> Debug is  true storeKey true useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is true principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
> Refreshing Kerberos configuration
> 		[Krb5LoginModule] user entered username: jduke
> principal is jduke at WILDFLY.ORG
> EncryptionKey: keyType=16 keyBytes (hex dump)=0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
> 0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;
> Added server's keyKerberos Principal jduke at WILDFLY.ORGKey Version 0key EncryptionKey: keyType=16 keyBytes (hex dump)=
> 0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
> 0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;
> 		[Krb5LoginModule] added Krb5Principal  jduke at WILDFLY.ORG to Subject
> Commit Succeeded 
> 19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:57> loginServer
> Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator false KeyTab is /mnt/hudson_workspace/workspace/wildfly-elytron-unit-tests/20ff21f6/wildfly-elytron/./target/apache-ds/working/serverKeyTab refreshKrb5Config is true principal is sasl/test_server_1 tryFirstPass is false useFirstPass is false storePass is false clearPass is false
> Refreshing Kerberos configuration
> principal is sasl/test_server_1 at WILDFLY.ORG
> Will use keytab
> Commit Succeeded 
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:68> Acceptor Name 'sasl at test_server_1'
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:100> CallbackHandler does not support CredentialCallback: javax.security.auth.callback.UnsupportedCallbackException
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$NoCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:421)
> 	at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:120)
> 	at org.wildfly.security.sasl.gssapi.GssapiClient.<init>(GssapiClient.java:93)
> 	at org.wildfly.security.sasl.gssapi.GssapiClientFactory.createSaslClient(GssapiClientFactory.java:42)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$0(GssapiCompatibilitySuiteChild.java:103)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:97)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
> 	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runners.Suite.runChild(Suite.java:128)
> 	at org.junit.runners.Suite.runChild(Suite.java:27)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:119> Delegating credential = false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:140> Setting requering mutual authentication to true
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:74> Obtaining GSSCredential for the service from callback handler...
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:80> Unable to obtain GSSCredential from CallbackHandler: javax.security.auth.callback.UnsupportedCallbackException
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$AuthorizeOnlyCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:413)
> 	at org.wildfly.security.sasl.gssapi.GssapiServer.<init>(GssapiServer.java:75)
> 	at org.wildfly.security.sasl.gssapi.GssapiServerFactory.createSaslServer(GssapiServerFactory.java:44)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$1(GssapiCompatibilitySuiteChild.java:111)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:106)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
> 	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runners.Suite.runChild(Suite.java:128)
> 	at org.junit.runners.Suite.runChild(Suite.java:27)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:87> Our name 'sasl at test_server_1'
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:229> GSSContext not established, expecting subsequent exchanges.
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/jdk=java18_default,label=eap-sustaining&&solaris11&&x86_64/testReport/-sustaining&&solaris10&&sparc/testReport
> [2] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 07:05:02 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1471) Reduce Class Loading overhead
 of WildFly Elytron Provider
In-Reply-To: <JIRA.12725844.1513860905000@Atlassian.JIRA>
References: <JIRA.12725844.1513860905000@Atlassian.JIRA>
	<JIRA.12725844.1513860905000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725844.1513860905000.96837.1516881902009@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1471?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1471:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> Reduce Class Loading overhead of WildFly Elytron Provider
> ---------------------------------------------------------
>
>                 Key: ELY-1471
>                 URL: https://issues.jboss.org/browse/ELY-1471
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta13
>
>
> We currently load every single implementation class just to identify it's name.
> Whilst this makes refactoring easier it causes a heavy hit to the ClassLoader just to install the provider even though only a small subset of it's services tend to be used at once.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:02 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1467) Support for RFC8053
 Optional-WWW-Authenticate
In-Reply-To: <JIRA.12724916.1513256838000@Atlassian.JIRA>
References: <JIRA.12724916.1513256838000@Atlassian.JIRA>
	<JIRA.12724916.1513256838000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724916.1513256838000.96840.1516881902119@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1467:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> Support for RFC8053 Optional-WWW-Authenticate
> ---------------------------------------------
>
>                 Key: ELY-1467
>                 URL: https://issues.jboss.org/browse/ELY-1467
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta13
>
>
> https://tools.ietf.org/html/rfc8053



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:02 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1466) Add configuration option to
 BASIC mechanism to switch off challenging
In-Reply-To: <JIRA.12724717.1513182505000@Atlassian.JIRA>
References: <JIRA.12724717.1513182505000@Atlassian.JIRA>
	<JIRA.12724717.1513182505000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724717.1513182505000.96846.1516881902290@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1466?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1466:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> Add configuration option to BASIC mechanism to switch off challenging
> ---------------------------------------------------------------------
>
>                 Key: ELY-1466
>                 URL: https://issues.jboss.org/browse/ELY-1466
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta13
>
>
> This may be desirable where paired with FORM auth so users can use FORM auth and other clients use BASIC.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:02 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1464) Programatic authentication
 should be caching the SecurityIdentity not the name of the identity
In-Reply-To: <JIRA.12724648.1513168931000@Atlassian.JIRA>
References: <JIRA.12724648.1513168931000@Atlassian.JIRA>
	<JIRA.12724648.1513168931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724648.1513168931000.96849.1516881902361@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1464?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1464:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> Programatic authentication should be caching the SecurityIdentity not the name of the identity
> ----------------------------------------------------------------------------------------------
>
>                 Key: ELY-1464
>                 URL: https://issues.jboss.org/browse/ELY-1464
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta13
>
>
> By only caching the name of the identity the server authentication context -> security domain -> security realm chain is called for each subsequent request when we should have been able to re-use an existing identity.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:02 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1455) DB query seen for each request
 using programatic authentication
In-Reply-To: <JIRA.12722890.1512034978000@Atlassian.JIRA>
References: <JIRA.12722890.1512034978000@Atlassian.JIRA>
	<JIRA.12722890.1512034978000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722890.1512034978000.96854.1516881902504@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1455?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1455:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


>  DB query seen for each request using programatic authentication
> ----------------------------------------------------------------
>
>                 Key: ELY-1455
>                 URL: https://issues.jboss.org/browse/ELY-1455
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Mechanisms
>    Affects Versions: 1.2.0.Beta10
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.2.0.Beta13
>
>         Attachments: elytron-bug.zip, server.log, standalone-full-ha.xml
>
>
> User is complaining, that DB is accessed on each request. 
> Jdbc-realm + FORM authentication
> {noformat}
> <jdbc-realm name="myappRealm">
>                     <principal-query sql="SELECT r.role, u.password FROM user u join user_role_auth r on r.email = u.email where u.email=?" data-source="myds">
>                         <attribute-mapping>
>                             <attribute to="Roles" index="1"/>
>                         </attribute-mapping>
>                         <simple-digest-mapper password-index="2"/>
>                     </principal-query>
>                 </jdbc-realm>
> {noformat}
> {noformat}
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Principal assigning: [alberto at myapp.com], pre-realm rewritten: [alberto at myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto at myapp.com], realm rewritten: [alberto at myapp.com]
> 2017-11-30 09:31:04,049 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto at myapp.com
> 2017-11-30 09:31:04,051 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto at myapp.com
> 2017-11-30 09:31:04,052 TRACE [org.wildfly.security] (default task-124) Executing principalQuery select password from user where email = ? with value alberto at myapp.com
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto at myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing principal alberto at myapp.com.
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Permission mapping: identity [alberto at myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Authorization succeed
> 2017-11-30 09:31:04,053 TRACE [org.wildfly.security] (default task-124) Role mapping: principal [alberto at myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,017 TRACE [org.wildfly.security] (default task-125) Principal assigning: [alberto at myapp.com], pre-realm rewritten: [alberto at myapp.com], realm name: [wmtRealm], post-realm rewritten: [alberto at myapp.com], realm rewritten: [alberto at myapp.com]
> 2017-11-30 09:31:07,018 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto at myapp.com
> 2017-11-30 09:31:07,019 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select role, 'Roles' from user_role_auth where email = ? with value alberto at myapp.com
> 2017-11-30 09:31:07,021 TRACE [org.wildfly.security] (default task-125) Executing principalQuery select password from user where email = ? with value alberto at myapp.com
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto at myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> 2017-11-30 09:31:07,022 TRACE [org.wildfly.security] (default task-125) Authorizing principal alberto at myapp.com.
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorizing against the following attributes: [roles] => [Administrator]
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Permission mapping: identity [alberto at myapp.com] with roles [Administrator] implies ("org.wildfly.security.auth.permission.LoginPermission" "") = true
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Authorization succeed
> 2017-11-30 09:31:07,023 TRACE [org.wildfly.security] (default task-125) Role mapping: principal [alberto at myapp.com] -> decoded roles [Administrator] -> realm mapped roles [Administrator] -> domain mapped roles [Administrator]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:02 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1444) Jdbc-realm with simple digest
	mapper
In-Reply-To: <JIRA.12720828.1510591139000@Atlassian.JIRA>
References: <JIRA.12720828.1510591139000@Atlassian.JIRA>
	<JIRA.12720828.1510591139000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720828.1510591139000.96858.1516881902586@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1444?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1444:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> Jdbc-realm with simple digest mapper
> ------------------------------------
>
>                 Key: ELY-1444
>                 URL: https://issues.jboss.org/browse/ELY-1444
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Passwords
>    Affects Versions: 1.2.0.Beta9
>            Reporter: Martin Choma
>             Fix For: 1.2.0.Beta13
>
>
> This is inspired by ELY-1435, but in this case trying simple digest hash.
> In db is stored this sha-256 password hash: 5E884898DA28047151D0E56F8DC6292773603D0D6AABBDD62A11EF721D1542D8
> I get these values by http://passwordsgenerator.net/sha256-hash-generator/
> {noformat}
> 17:30:50,211 DEBUG [org.wildfly.security] (default task-3) Using UsernamePasswordAuthenticationMechanism for username authentication. Realm: [Some Realm], Username: [correctUser].
> 17:30:50,211 TRACE [org.wildfly.security] (default task-3) Handling RealmCallback: selected = [Some Realm]
> 17:30:50,212 TRACE [org.wildfly.security] (default task-3) Handling NameCallback: authenticationName = correctUser
> 17:30:50,212 TRACE [org.wildfly.security] (default task-3) Principal assigning: [correctUser], pre-realm rewritten: [correctUser], realm name: [jdbc-realm], post-realm rewritten: [correctUser], realm rewritten: [correctUser]
> 17:30:50,215 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser
> 17:30:50,301 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT roles.name FROM users, roles, users_roles WHERE users.name=? AND users.id = users_roles.userid AND roles.id = users_roles.roleid with value correctUser
> 17:30:50,306 TRACE [org.wildfly.security] (default task-3) Executing principalQuery SELECT PASSWORD FROM USERS WHERE NAME = ? with value correctUser
> 17:30:50,324 DEBUG [org.wildfly.security] (default task-3) User correctUser authentication failed.
> 17:30:50,324 TRACE [org.wildfly.security] (default task-3) Handling AuthenticationCompleteCallback: fail
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:02 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1440) FlexibleIdentityAssociation
 should runAs the known SecurityIdentity before associating itself.
In-Reply-To: <JIRA.12720443.1510315640000@Atlassian.JIRA>
References: <JIRA.12720443.1510315640000@Atlassian.JIRA>
	<JIRA.12720443.1510315640000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720443.1510315640000.96861.1516881902689@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1440?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1440:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> FlexibleIdentityAssociation should runAs the known SecurityIdentity before associating itself.
> ----------------------------------------------------------------------------------------------
>
>                 Key: ELY-1440
>                 URL: https://issues.jboss.org/browse/ELY-1440
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: API / SPI
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta13
>
>
> This API was introduced to cover the case where authentication happens late in a request, generally that is quite a rare event.
> Even though the API may be popular it would likely happen once for a session and all future requests for that session the identity would be known in advance.
> At the moment by not running as the existing identity we are loosing all automatic identity outflow opportunities as calls pass from the servlet container to the EJB container.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:02 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1436) Log jdbc-realm key-mapper
	processing
In-Reply-To: <JIRA.12719794.1510048725000@Atlassian.JIRA>
References: <JIRA.12719794.1510048725000@Atlassian.JIRA>
	<JIRA.12719794.1510048725000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719794.1510048725000.96865.1516881902781@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1436?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1436:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> Log jdbc-realm key-mapper processing
> ------------------------------------
>
>                 Key: ELY-1436
>                 URL: https://issues.jboss.org/browse/ELY-1436
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Martin Choma
>            Assignee: Ilia Vassilev
>             Fix For: 1.2.0.Beta13
>
>
> User reported problem with getting work jdbc_realm with bcrypt mapper. He had configured org.wildfly.security to log TRACE messages, but log does not provide any useful information regarding mapping password from DB.
> In this case seems problem was in mixing base64 vs. modular crypt format.
> Looking into PasswordKeyMapper there is a lot of logic and lot of steps which can get wrong. So logging some TRACE messages can hint user what is going on and what went wrong.
> Also I have noticed there is unhandled exception. Please at least log some TRACE message.
> {code:java|title=PasswordKeyMapper.java}
> } catch (InvalidKeySpecException e) {
> 	// fall out (unlikely but possible)
> }
> {code}
> [1] https://developer.jboss.org/message/977727



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:02 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1425) Add support for JASPIC /
	JSR-196
In-Reply-To: <JIRA.12718362.1509034607000@Atlassian.JIRA>
References: <JIRA.12718362.1509034607000@Atlassian.JIRA>
	<JIRA.12718362.1509034607000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718362.1509034607000.96868.1516881902884@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1425?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1425:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> Add support for JASPIC / JSR-196
> --------------------------------
>
>                 Key: ELY-1425
>                 URL: https://issues.jboss.org/browse/ELY-1425
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta13
>
>
> This is an overall tracking task for changes required to WildFly Elytron to support JASPIC.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:02 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1409) Update HTTP authentication
 mechanism API to support re-use of response handlers
In-Reply-To: <JIRA.12716799.1508241804000@Atlassian.JIRA>
References: <JIRA.12716799.1508241804000@Atlassian.JIRA>
	<JIRA.12716799.1508241804000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12716799.1508241804000.96871.1516881902998@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1409?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1409:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> Update HTTP authentication mechanism API to support re-use of response handlers
> -------------------------------------------------------------------------------
>
>                 Key: ELY-1409
>                 URL: https://issues.jboss.org/browse/ELY-1409
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: HTTP
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 1.2.0.Beta13
>
>
> At the moment the response handler can only access the response, it can not access anything from the request unless created with access to the request.
> Making the scopes available should allow for state to be transferred on the request scope.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:05:03 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 07:05:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1405) The password attribute of
 resource owner credentials should support a credential store reference
In-Reply-To: <JIRA.12716640.1508172318000@Atlassian.JIRA>
References: <JIRA.12716640.1508172318000@Atlassian.JIRA>
	<JIRA.12716640.1508172318000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12716640.1508172318000.96877.1516881903247@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1405?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1405:
----------------------------------
    Fix Version/s: 1.2.0.Beta13
                       (was: 1.2.0.Beta12)


> The password attribute of resource owner credentials should support a credential store reference
> ------------------------------------------------------------------------------------------------
>
>                 Key: ELY-1405
>                 URL: https://issues.jboss.org/browse/ELY-1405
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>            Assignee: Martin Mazanek
>             Fix For: 1.2.0.Beta13
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:09:00 2018
From: issues at jboss.org (Fedor Gavrilov (JIRA))
Date: Thu, 25 Jan 2018 07:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1767) FEEL: add compile-time
	cycle detection
In-Reply-To: <JIRA.12716806.1508243245000@Atlassian.JIRA>
References: <JIRA.12716806.1508243245000@Atlassian.JIRA>
	<JIRA.12716806.1508243245000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12716806.1508243245000.96903.1516882140786@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1767?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fedor Gavrilov resolved DROOLS-1767.
------------------------------------
    Resolution: Done


> FEEL: add compile-time cycle detection 
> ---------------------------------------
>
>                 Key: DROOLS-1767
>                 URL: https://issues.jboss.org/browse/DROOLS-1767
>             Project: Drools
>          Issue Type: Enhancement
>          Components: dmn engine
>    Affects Versions: 7.4.1.Final
>            Reporter: Fedor Gavrilov
>            Assignee: Fedor Gavrilov
>            Priority: Minor
>
> Similar to what's done in https://issues.jboss.org/browse/DROOLS-1730 but during validation stage



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 07:26:00 2018
From: issues at jboss.org (Fedor Gavrilov (JIRA))
Date: Thu, 25 Jan 2018 07:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2274) "?" special variable support
In-Reply-To: <JIRA.12730783.1516883119000@Atlassian.JIRA>
References: <JIRA.12730783.1516883119000@Atlassian.JIRA>
	<JIRA.12730783.1516883119389@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730783.1516883119000.97028.1516883160564@Atlassian.JIRA>

Fedor Gavrilov created DROOLS-2274:
--------------------------------------

             Summary: "?" special variable support
                 Key: DROOLS-2274
                 URL: https://issues.jboss.org/browse/DROOLS-2274
             Project: Drools
          Issue Type: Enhancement
            Reporter: Fedor Gavrilov
            Assignee: Fedor Gavrilov
            Priority: Minor






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 08:04:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 08:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3541) Missing password types in
 set-password operation of modifiable realms
In-Reply-To: <JIRA.12730540.1516798317000@Atlassian.JIRA>
References: <JIRA.12730540.1516798317000@Atlassian.JIRA>
	<JIRA.12730540.1516798317000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730540.1516798317000.97516.1516885440328@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3541?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523764#comment-13523764 ] 

Jan Kalina commented on WFCORE-3541:
------------------------------------

By discussion, reworking of password management API is in plan, so adding all passwords types into current one would not be much useful.
But scram will be added, as we want SCRAM to be preferred authentication mechanism.

> Missing password types in set-password operation of modifiable realms
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-3541
>                 URL: https://issues.jboss.org/browse/WFCORE-3541
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>            Priority: Critical
>              Labels: elytron
>
> Not all password types are covered by *set-password* operation in ModifiableRealmDecorator.
> At least *ScramDigestPassword* is not available.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 08:39:02 2018
From: issues at jboss.org (Peter Skopek (JIRA))
Date: Thu, 25 Jan 2018 08:39:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9731) The fix for WFLY-4625 breaks
 PolicyContext("javax.security.auth.subject.container") in CXF web service
 with STS
In-Reply-To: <JIRA.12697710.1497598048000@Atlassian.JIRA>
References: <JIRA.12697710.1497598048000@Atlassian.JIRA>
	<JIRA.12697710.1497598048000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12697710.1497598048000.98118.1516887542031@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Peter Skopek moved PLINK-772 to WFLY-9731:
------------------------------------------

        Project: WildFly  (was: PicketLink)
            Key: WFLY-9731  (was: PLINK-772)
       Workflow: GIT Pull Request workflow   (was: classic default workflow)
    Component/s: Security
                     (was: BASE)


> The fix for WFLY-4625 breaks PolicyContext("javax.security.auth.subject.container") in CXF web service with STS
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9731
>                 URL: https://issues.jboss.org/browse/WFLY-9731
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Petr Jurak
>            Assignee: Pedro Igor
>
> Web service with STS (Picketlink) returns wrong subject with PolicyContext("javax.security.auth.subject.container"). 
> It seems that configured login modules are not called since SecurityContext was created by SAML2Handler for the same security domain and are skipped because of WFLY-4625.
> Reproducer is attached in BZ-1352418.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 08:40:00 2018
From: issues at jboss.org (Petr Jurak (JIRA))
Date: Thu, 25 Jan 2018 08:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9731) The fix for WFLY-4625 breaks
 PolicyContext("javax.security.auth.subject.container") in CXF web service
 with STS
In-Reply-To: <JIRA.12697710.1497598048000@Atlassian.JIRA>
References: <JIRA.12697710.1497598048000@Atlassian.JIRA>
	<JIRA.12697710.1497598048000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12697710.1497598048000.98129.1516887600720@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9731?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Petr Jurak reassigned WFLY-9731:
--------------------------------

    Assignee: Petr Jurak  (was: Pedro Igor)


> The fix for WFLY-4625 breaks PolicyContext("javax.security.auth.subject.container") in CXF web service with STS
> ---------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9731
>                 URL: https://issues.jboss.org/browse/WFLY-9731
>             Project: WildFly
>          Issue Type: Bug
>          Components: Security
>            Reporter: Petr Jurak
>            Assignee: Petr Jurak
>
> Web service with STS (Picketlink) returns wrong subject with PolicyContext("javax.security.auth.subject.container"). 
> It seems that configured login modules are not called since SecurityContext was created by SAML2Handler for the same security domain and are skipped because of WFLY-4625.
> Reproducer is attached in BZ-1352418.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 08:51:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Thu, 25 Jan 2018 08:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3545) Composed keys don't have to
 be recognized by CLI
In-Reply-To: <JIRA.12730797.1516888208000@Atlassian.JIRA>
References: <JIRA.12730797.1516888208000@Atlassian.JIRA>
	<JIRA.12730797.1516888208454@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730797.1516888208000.98230.1516888260276@Atlassian.JIRA>

Erich Duda created WFCORE-3545:
----------------------------------

             Summary: Composed keys don't have to be recognized by CLI
                 Key: WFCORE-3545
                 URL: https://issues.jboss.org/browse/WFCORE-3545
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
    Affects Versions: 4.0.0.Alpha6
            Reporter: Erich Duda
            Assignee: Jean-Francois Denise


Some keys like key down are composed from multiple characters. Normally when the key down is pushed, 3 characters are written into stdin. These 3 characters are read by InputStream::read operation at once and then decoded to the Key.DOWN constant.

However there is no guarantee that InputStream::read operation returns all the 3 characters at once. It can return only first character and then remaining two. This actually happens in one test on Solaris and HPUX, where stdin is emulated by PipedInputStream.

If the aforementioned situation happens, pushing of key down is decoded as pushing of two maybe three keys - ESC and some other key(s).

The issue has low priority, because this behavior wasn't observed in real terminal with real input. It affects only testing.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 08:55:00 2018
From: issues at jboss.org (Erich Duda (JIRA))
Date: Thu, 25 Jan 2018 08:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3546) Update MoreTestCase to hide
 failures caused by WFCORE-3545
In-Reply-To: <JIRA.12730800.1516888482000@Atlassian.JIRA>
References: <JIRA.12730800.1516888482000@Atlassian.JIRA>
	<JIRA.12730800.1516888482935@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730800.1516888482000.98249.1516888500413@Atlassian.JIRA>

Erich Duda created WFCORE-3546:
----------------------------------

             Summary: Update MoreTestCase to hide failures caused by WFCORE-3545
                 Key: WFCORE-3546
                 URL: https://issues.jboss.org/browse/WFCORE-3546
             Project: WildFly Core
          Issue Type: Task
          Components: CLI
    Affects Versions: 4.0.0.Alpha6
            Reporter: Erich Duda
            Assignee: Erich Duda


The MoreTestCase fails on Solaris and HPUX because of the WFCORE-3545.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 09:03:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 25 Jan 2018 09:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9721) AsyncInvocationTask.get()
 throws CancellationException
In-Reply-To: <JIRA.12730294.1516694725000@Atlassian.JIRA>
References: <JIRA.12730294.1516694725000@Atlassian.JIRA>
	<JIRA.12730294.1516694725000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730294.1516694725000.98330.1516888980576@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9721?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFLY-9721:
------------------------------
    Description: 
AsyncInvocationTask.get() on cancelled task in Wildfly 11 throws CancellationException via EjbLogger, but the behavior is not declared in method signature:

{code:java}
    public synchronized Object get() throws InterruptedException, ExecutionException {
        for (;;) switch (status) {
            case ST_RUNNING: wait(); break;
            *case ST_CANCELLED: throw EjbLogger.ROOT_LOGGER.taskWasCancelled();*
            case ST_FAILED: throw new ExecutionException(failed);
            case ST_DONE: return result;
            default: throw Assert.impossibleSwitchCase(status);
        }
    }
{code}

Wildfly 10.01.0 code is different:

{code:java}
    public synchronized Object get() throws InterruptedException, ExecutionException {
        while (!isDone()) {
            wait();
        }
        if (failed != null) {
            throw new ExecutionException(failed);
        }
        return result;
    } 
{code}
It throws InterruptedException instead as declared.

  was:
AsyncInvocationTask.get() on cancelled task in Wildfly 11 throws CancellationException via EjbLogger, but the behavior is not declared in method signature:

{{    public synchronized Object get() throws InterruptedException, ExecutionException {
        for (;;) switch (status) {
            case ST_RUNNING: wait(); break;
            *case ST_CANCELLED: throw EjbLogger.ROOT_LOGGER.taskWasCancelled();*
            case ST_FAILED: throw new ExecutionException(failed);
            case ST_DONE: return result;
            default: throw Assert.impossibleSwitchCase(status);
        }
    }
}}

Wildfly 10.01.0 code is different:

{{    public synchronized Object get() throws InterruptedException, ExecutionException {
        while (!isDone()) {
            wait();
        }
        if (failed != null) {
            throw new ExecutionException(failed);
        }
        return result;
    } 
}}
It throws InterruptedException instead as declared.



> AsyncInvocationTask.get() throws CancellationException
> ------------------------------------------------------
>
>                 Key: WFLY-9721
>                 URL: https://issues.jboss.org/browse/WFLY-9721
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 11.0.0.Final
>            Reporter: Denis Shklyaev
>            Priority: Optional
>
> AsyncInvocationTask.get() on cancelled task in Wildfly 11 throws CancellationException via EjbLogger, but the behavior is not declared in method signature:
> {code:java}
>     public synchronized Object get() throws InterruptedException, ExecutionException {
>         for (;;) switch (status) {
>             case ST_RUNNING: wait(); break;
>             *case ST_CANCELLED: throw EjbLogger.ROOT_LOGGER.taskWasCancelled();*
>             case ST_FAILED: throw new ExecutionException(failed);
>             case ST_DONE: return result;
>             default: throw Assert.impossibleSwitchCase(status);
>         }
>     }
> {code}
> Wildfly 10.01.0 code is different:
> {code:java}
>     public synchronized Object get() throws InterruptedException, ExecutionException {
>         while (!isDone()) {
>             wait();
>         }
>         if (failed != null) {
>             throw new ExecutionException(failed);
>         }
>         return result;
>     } 
> {code}
> It throws InterruptedException instead as declared.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 09:04:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Thu, 25 Jan 2018 09:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9721) AsyncInvocationTask.get()
 throws CancellationException
In-Reply-To: <JIRA.12730294.1516694725000@Atlassian.JIRA>
References: <JIRA.12730294.1516694725000@Atlassian.JIRA>
	<JIRA.12730294.1516694725000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730294.1516694725000.98350.1516889040846@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9721?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523815#comment-13523815 ] 

David Lloyd commented on WFLY-9721:
-----------------------------------

The {{get()}} method should throw {{InterruptedException}} if and only if the thread calling {{get()}} was interrupted before the result was ready.  If the asynchronous task itself was cancelled (which might or might not entail interruption), then {{CancellationException}} is the correct exception.

> AsyncInvocationTask.get() throws CancellationException
> ------------------------------------------------------
>
>                 Key: WFLY-9721
>                 URL: https://issues.jboss.org/browse/WFLY-9721
>             Project: WildFly
>          Issue Type: Bug
>          Components: EJB
>    Affects Versions: 11.0.0.Final
>            Reporter: Denis Shklyaev
>            Priority: Optional
>
> AsyncInvocationTask.get() on cancelled task in Wildfly 11 throws CancellationException via EjbLogger, but the behavior is not declared in method signature:
> {code:java}
>     public synchronized Object get() throws InterruptedException, ExecutionException {
>         for (;;) switch (status) {
>             case ST_RUNNING: wait(); break;
>             *case ST_CANCELLED: throw EjbLogger.ROOT_LOGGER.taskWasCancelled();*
>             case ST_FAILED: throw new ExecutionException(failed);
>             case ST_DONE: return result;
>             default: throw Assert.impossibleSwitchCase(status);
>         }
>     }
> {code}
> Wildfly 10.01.0 code is different:
> {code:java}
>     public synchronized Object get() throws InterruptedException, ExecutionException {
>         while (!isDone()) {
>             wait();
>         }
>         if (failed != null) {
>             throw new ExecutionException(failed);
>         }
>         return result;
>     } 
> {code}
> It throws InterruptedException instead as declared.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 09:12:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 25 Jan 2018 09:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1499) Coverity,
 Resource leak in HttpAuthenticator
In-Reply-To: <JIRA.12730807.1516889489000@Atlassian.JIRA>
References: <JIRA.12730807.1516889489000@Atlassian.JIRA>
	<JIRA.12730807.1516889489383@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730807.1516889489000.98418.1516889520509@Atlassian.JIRA>

Martin Choma created ELY-1499:
---------------------------------

             Summary: Coverity, Resource leak in HttpAuthenticator
                 Key: ELY-1499
                 URL: https://issues.jboss.org/browse/ELY-1499
             Project: WildFly Elytron
          Issue Type: Bug
          Components: HTTP
    Affects Versions: 1.2.0.Beta12
            Reporter: Martin Choma
            Priority: Critical


Despite ServerAuthenticationContext is AutoClosable. Newly created instance in HttpAuthenticator#login() is not closed and no reference is passed outside of method, so is left unclosed forever. 

[1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=46513446&defectInstanceId=9767772&mergedDefectId=1464362



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 09:12:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 25 Jan 2018 09:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3547) ExceptionInInitializerError
 during create of CLI object on client app
In-Reply-To: <JIRA.12730808.1516889509000@Atlassian.JIRA>
References: <JIRA.12730808.1516889509000@Atlassian.JIRA>
	<JIRA.12730808.1516889509771@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730808.1516889509000.98421.1516889520650@Atlassian.JIRA>

Marek Kopeck? created WFCORE-3547:
-------------------------------------

             Summary: ExceptionInInitializerError during create of CLI object on client app
                 Key: WFCORE-3547
                 URL: https://issues.jboss.org/browse/WFCORE-3547
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Marek Kopeck?
            Assignee: Jean-Francois Denise


ExceptionInInitializerError during create of CLI object on client app.

*Steps to reproduce:*
# create simple CLI client app, for example: {code:java}public class App {
    public static void main(String[] args) throws Exception {
        CLI cli = CLI.newInstance();
    }
} {code}
# start this application

*Actual results:*
{noformat}
Exception in thread "main" java.lang.ExceptionInInitializerError
    at org.jboss.as.cli.impl.aesh.AeshCommands.<init>(AeshCommands.java:197)
    at org.jboss.as.cli.impl.aesh.AeshCommands.<init>(AeshCommands.java:174)
    at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:352)
    at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:44)
    at org.jboss.as.cli.scriptsupport.CLI.initOfflineContext(CLI.java:278)
    at org.jboss.as.cli.scriptsupport.CLI.<init>(CLI.java:53)
    at org.jboss.as.cli.scriptsupport.CLI.newInstance(CLI.java:62)
    at com.client.test.App.main(App.java:9)
Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
    at org.jboss.logmanager.Logger.getLogger(Logger.java:57)
    at org.jboss.as.cli.impl.aesh.CLICompletionHandler.<clinit>(CLICompletionHandler.java:45)
    ... 8 more 
{noformat}

*Expected results:*
No errors

*Additional info:*
See attached application:
{noformat}
# old client
mvn clean
mvn package  -Dversion.client=3.0.10.Final
java -jar target/ClientApplication.jar # works correctly with old client

# new client
mvn clean
mvn package  -Dversion.client=4.0.0.Alpha7-SNAPSHOT
java -jar target/ClientApplication.jar # throws ExceptionInInitializerError
java -Djava.util.logging.manager=org.jboss.logmanager.LogManager -jar target/ClientApplication.jar  # no exception 
{noformat}






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 09:13:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 25 Jan 2018 09:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1499) Coverity,
 Resource leak in HttpAuthenticator
In-Reply-To: <JIRA.12730807.1516889489000@Atlassian.JIRA>
References: <JIRA.12730807.1516889489000@Atlassian.JIRA>
	<JIRA.12730807.1516889489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730807.1516889489000.98424.1516889580612@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1499:
------------------------------
    Description: 
Despite the fact ServerAuthenticationContext is AutoClosable. Newly created instance in HttpAuthenticator#login() is not closed and no reference is passed outside of method, so is left unclosed forever. 

[1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=46513446&defectInstanceId=9767772&mergedDefectId=1464362

  was:
Despite ServerAuthenticationContext is AutoClosable. Newly created instance in HttpAuthenticator#login() is not closed and no reference is passed outside of method, so is left unclosed forever. 

[1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=46513446&defectInstanceId=9767772&mergedDefectId=1464362



> Coverity, Resource leak in HttpAuthenticator
> --------------------------------------------
>
>                 Key: ELY-1499
>                 URL: https://issues.jboss.org/browse/ELY-1499
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.2.0.Beta12
>            Reporter: Martin Choma
>            Priority: Critical
>
> Despite the fact ServerAuthenticationContext is AutoClosable. Newly created instance in HttpAuthenticator#login() is not closed and no reference is passed outside of method, so is left unclosed forever. 
> [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=46513446&defectInstanceId=9767772&mergedDefectId=1464362



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 09:13:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 25 Jan 2018 09:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3547) ExceptionInInitializerError
 during create of CLI object on client app
In-Reply-To: <JIRA.12730808.1516889510000@Atlassian.JIRA>
References: <JIRA.12730808.1516889510000@Atlassian.JIRA>
	<JIRA.12730808.1516889510000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730808.1516889510000.98428.1516889580724@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-3547:
----------------------------------
    Attachment: single-client.zip


> ExceptionInInitializerError during create of CLI object on client app
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-3547
>                 URL: https://issues.jboss.org/browse/WFCORE-3547
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Marek Kopeck?
>            Assignee: Jean-Francois Denise
>         Attachments: single-client.zip
>
>
> ExceptionInInitializerError during create of CLI object on client app.
> *Steps to reproduce:*
> # create simple CLI client app, for example: {code:java}public class App {
>     public static void main(String[] args) throws Exception {
>         CLI cli = CLI.newInstance();
>     }
> } {code}
> # start this application
> *Actual results:*
> {noformat}
> Exception in thread "main" java.lang.ExceptionInInitializerError
>     at org.jboss.as.cli.impl.aesh.AeshCommands.<init>(AeshCommands.java:197)
>     at org.jboss.as.cli.impl.aesh.AeshCommands.<init>(AeshCommands.java:174)
>     at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:352)
>     at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:44)
>     at org.jboss.as.cli.scriptsupport.CLI.initOfflineContext(CLI.java:278)
>     at org.jboss.as.cli.scriptsupport.CLI.<init>(CLI.java:53)
>     at org.jboss.as.cli.scriptsupport.CLI.newInstance(CLI.java:62)
>     at com.client.test.App.main(App.java:9)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
>     at org.jboss.logmanager.Logger.getLogger(Logger.java:57)
>     at org.jboss.as.cli.impl.aesh.CLICompletionHandler.<clinit>(CLICompletionHandler.java:45)
>     ... 8 more 
> {noformat}
> *Expected results:*
> No errors
> *Additional info:*
> See attached application:
> {noformat}
> # old client
> mvn clean
> mvn package  -Dversion.client=3.0.10.Final
> java -jar target/ClientApplication.jar # works correctly with old client
> # new client
> mvn clean
> mvn package  -Dversion.client=4.0.0.Alpha7-SNAPSHOT
> java -jar target/ClientApplication.jar # throws ExceptionInInitializerError
> java -Djava.util.logging.manager=org.jboss.logmanager.LogManager -jar target/ClientApplication.jar  # no exception 
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 09:13:01 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 25 Jan 2018 09:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3547) ExceptionInInitializerError
 during create of CLI object on client app
In-Reply-To: <JIRA.12730808.1516889510000@Atlassian.JIRA>
References: <JIRA.12730808.1516889510000@Atlassian.JIRA>
	<JIRA.12730808.1516889510000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730808.1516889510000.98439.1516889581056@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-3547:
----------------------------------
    Description: 
ExceptionInInitializerError during create of CLI object on client app.

*Steps to reproduce:*
# create simple CLI client app, for example: {code:java}public class App {
    public static void main(String[] args) throws Exception {
        CLI cli = CLI.newInstance();
    }
} {code}
# start this application

*Actual results:*
{noformat}
Exception in thread "main" java.lang.ExceptionInInitializerError
    at org.jboss.as.cli.impl.aesh.AeshCommands.<init>(AeshCommands.java:197)
    at org.jboss.as.cli.impl.aesh.AeshCommands.<init>(AeshCommands.java:174)
    at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:352)
    at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:44)
    at org.jboss.as.cli.scriptsupport.CLI.initOfflineContext(CLI.java:278)
    at org.jboss.as.cli.scriptsupport.CLI.<init>(CLI.java:53)
    at org.jboss.as.cli.scriptsupport.CLI.newInstance(CLI.java:62)
    at com.client.test.App.main(App.java:9)
Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
    at org.jboss.logmanager.Logger.getLogger(Logger.java:57)
    at org.jboss.as.cli.impl.aesh.CLICompletionHandler.<clinit>(CLICompletionHandler.java:45)
    ... 8 more 
{noformat}

*Expected results:*
No errors

*Additional info:*
See attached application  [^single-client.zip] :
{noformat}
# old client
mvn clean
mvn package  -Dversion.client=3.0.10.Final
java -jar target/ClientApplication.jar # works correctly with old client

# new client
mvn clean
mvn package  -Dversion.client=4.0.0.Alpha7-SNAPSHOT
java -jar target/ClientApplication.jar # throws ExceptionInInitializerError
java -Djava.util.logging.manager=org.jboss.logmanager.LogManager -jar target/ClientApplication.jar  # no exception 
{noformat}




  was:
ExceptionInInitializerError during create of CLI object on client app.

*Steps to reproduce:*
# create simple CLI client app, for example: {code:java}public class App {
    public static void main(String[] args) throws Exception {
        CLI cli = CLI.newInstance();
    }
} {code}
# start this application

*Actual results:*
{noformat}
Exception in thread "main" java.lang.ExceptionInInitializerError
    at org.jboss.as.cli.impl.aesh.AeshCommands.<init>(AeshCommands.java:197)
    at org.jboss.as.cli.impl.aesh.AeshCommands.<init>(AeshCommands.java:174)
    at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:352)
    at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:44)
    at org.jboss.as.cli.scriptsupport.CLI.initOfflineContext(CLI.java:278)
    at org.jboss.as.cli.scriptsupport.CLI.<init>(CLI.java:53)
    at org.jboss.as.cli.scriptsupport.CLI.newInstance(CLI.java:62)
    at com.client.test.App.main(App.java:9)
Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
    at org.jboss.logmanager.Logger.getLogger(Logger.java:57)
    at org.jboss.as.cli.impl.aesh.CLICompletionHandler.<clinit>(CLICompletionHandler.java:45)
    ... 8 more 
{noformat}

*Expected results:*
No errors

*Additional info:*
See attached application:
{noformat}
# old client
mvn clean
mvn package  -Dversion.client=3.0.10.Final
java -jar target/ClientApplication.jar # works correctly with old client

# new client
mvn clean
mvn package  -Dversion.client=4.0.0.Alpha7-SNAPSHOT
java -jar target/ClientApplication.jar # throws ExceptionInInitializerError
java -Djava.util.logging.manager=org.jboss.logmanager.LogManager -jar target/ClientApplication.jar  # no exception 
{noformat}






> ExceptionInInitializerError during create of CLI object on client app
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-3547
>                 URL: https://issues.jboss.org/browse/WFCORE-3547
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Marek Kopeck?
>            Assignee: Jean-Francois Denise
>         Attachments: single-client.zip
>
>
> ExceptionInInitializerError during create of CLI object on client app.
> *Steps to reproduce:*
> # create simple CLI client app, for example: {code:java}public class App {
>     public static void main(String[] args) throws Exception {
>         CLI cli = CLI.newInstance();
>     }
> } {code}
> # start this application
> *Actual results:*
> {noformat}
> Exception in thread "main" java.lang.ExceptionInInitializerError
>     at org.jboss.as.cli.impl.aesh.AeshCommands.<init>(AeshCommands.java:197)
>     at org.jboss.as.cli.impl.aesh.AeshCommands.<init>(AeshCommands.java:174)
>     at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:352)
>     at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:44)
>     at org.jboss.as.cli.scriptsupport.CLI.initOfflineContext(CLI.java:278)
>     at org.jboss.as.cli.scriptsupport.CLI.<init>(CLI.java:53)
>     at org.jboss.as.cli.scriptsupport.CLI.newInstance(CLI.java:62)
>     at com.client.test.App.main(App.java:9)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
>     at org.jboss.logmanager.Logger.getLogger(Logger.java:57)
>     at org.jboss.as.cli.impl.aesh.CLICompletionHandler.<clinit>(CLICompletionHandler.java:45)
>     ... 8 more 
> {noformat}
> *Expected results:*
> No errors
> *Additional info:*
> See attached application  [^single-client.zip] :
> {noformat}
> # old client
> mvn clean
> mvn package  -Dversion.client=3.0.10.Final
> java -jar target/ClientApplication.jar # works correctly with old client
> # new client
> mvn clean
> mvn package  -Dversion.client=4.0.0.Alpha7-SNAPSHOT
> java -jar target/ClientApplication.jar # throws ExceptionInInitializerError
> java -Djava.util.logging.manager=org.jboss.logmanager.LogManager -jar target/ClientApplication.jar  # no exception 
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 09:13:01 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Thu, 25 Jan 2018 09:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3547) ExceptionInInitializerError
 during create of CLI object on client app
In-Reply-To: <JIRA.12730808.1516889510000@Atlassian.JIRA>
References: <JIRA.12730808.1516889510000@Atlassian.JIRA>
	<JIRA.12730808.1516889510000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730808.1516889510000.98455.1516889581811@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-3547:
----------------------------------
    Priority: Critical  (was: Major)


> ExceptionInInitializerError during create of CLI object on client app
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-3547
>                 URL: https://issues.jboss.org/browse/WFCORE-3547
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Marek Kopeck?
>            Assignee: Jean-Francois Denise
>            Priority: Critical
>         Attachments: single-client.zip
>
>
> ExceptionInInitializerError during create of CLI object on client app.
> *Steps to reproduce:*
> # create simple CLI client app, for example: {code:java}public class App {
>     public static void main(String[] args) throws Exception {
>         CLI cli = CLI.newInstance();
>     }
> } {code}
> # start this application
> *Actual results:*
> {noformat}
> Exception in thread "main" java.lang.ExceptionInInitializerError
>     at org.jboss.as.cli.impl.aesh.AeshCommands.<init>(AeshCommands.java:197)
>     at org.jboss.as.cli.impl.aesh.AeshCommands.<init>(AeshCommands.java:174)
>     at org.jboss.as.cli.impl.CommandContextImpl.<init>(CommandContextImpl.java:352)
>     at org.jboss.as.cli.impl.CommandContextFactoryImpl.newCommandContext(CommandContextFactoryImpl.java:44)
>     at org.jboss.as.cli.scriptsupport.CLI.initOfflineContext(CLI.java:278)
>     at org.jboss.as.cli.scriptsupport.CLI.<init>(CLI.java:53)
>     at org.jboss.as.cli.scriptsupport.CLI.newInstance(CLI.java:62)
>     at com.client.test.App.main(App.java:9)
> Caused by: java.lang.IllegalStateException: The LogManager was not properly installed (you must set the "java.util.logging.manager" system property to "org.jboss.logmanager.LogManager")
>     at org.jboss.logmanager.Logger.getLogger(Logger.java:57)
>     at org.jboss.as.cli.impl.aesh.CLICompletionHandler.<clinit>(CLICompletionHandler.java:45)
>     ... 8 more 
> {noformat}
> *Expected results:*
> No errors
> *Additional info:*
> See attached application  [^single-client.zip] :
> {noformat}
> # old client
> mvn clean
> mvn package  -Dversion.client=3.0.10.Final
> java -jar target/ClientApplication.jar # works correctly with old client
> # new client
> mvn clean
> mvn package  -Dversion.client=4.0.0.Alpha7-SNAPSHOT
> java -jar target/ClientApplication.jar # throws ExceptionInInitializerError
> java -Djava.util.logging.manager=org.jboss.logmanager.LogManager -jar target/ClientApplication.jar  # no exception 
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 09:21:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 25 Jan 2018 09:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1500) Coverity,
 Infinite Loop in FactoryCredentialSource
In-Reply-To: <JIRA.12730813.1516890052000@Atlassian.JIRA>
References: <JIRA.12730813.1516890052000@Atlassian.JIRA>
	<JIRA.12730813.1516890052762@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730813.1516890052000.98496.1516890060342@Atlassian.JIRA>

Martin Choma created ELY-1500:
---------------------------------

             Summary: Coverity, Infinite Loop in FactoryCredentialSource
                 Key: ELY-1500
                 URL: https://issues.jboss.org/browse/ELY-1500
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Credentials
    Affects Versions: 1.2.0.Beta12
            Reporter: Martin Choma
            Priority: Critical


Effectivelly Elytron contains infinite recursion implemented.
{code:java|title=FactoryCredentialSource.java}
    @Override
    public SupportLevel getCredentialAcquireSupport(Class<? extends Credential> credentialType, String algorithmName, AlgorithmParameterSpec parameterSpec) throws IOException {
        return getCredentialAcquireSupport(credentialType, algorithmName, parameterSpec) != null ? SupportLevel.SUPPORTED : SupportLevel.UNSUPPORTED;
    }
{code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 09:22:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 09:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1499) Coverity,
 Resource leak in HttpAuthenticator
In-Reply-To: <JIRA.12730807.1516889489000@Atlassian.JIRA>
References: <JIRA.12730807.1516889489000@Atlassian.JIRA>
	<JIRA.12730807.1516889489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730807.1516889489000.98501.1516890120332@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse reassigned ELY-1499:
-------------------------------------

    Assignee: Darran Lofthouse


> Coverity, Resource leak in HttpAuthenticator
> --------------------------------------------
>
>                 Key: ELY-1499
>                 URL: https://issues.jboss.org/browse/ELY-1499
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.2.0.Beta12
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.2.0.Beta13
>
>
> Despite the fact ServerAuthenticationContext is AutoClosable. Newly created instance in HttpAuthenticator#login() is not closed and no reference is passed outside of method, so is left unclosed forever. 
> [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=46513446&defectInstanceId=9767772&mergedDefectId=1464362



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 09:22:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 09:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1499) Coverity,
 Resource leak in HttpAuthenticator
In-Reply-To: <JIRA.12730807.1516889489000@Atlassian.JIRA>
References: <JIRA.12730807.1516889489000@Atlassian.JIRA>
	<JIRA.12730807.1516889489000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730807.1516889489000.98505.1516890120490@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1499?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated ELY-1499:
----------------------------------
    Fix Version/s: 1.2.0.Beta13


> Coverity, Resource leak in HttpAuthenticator
> --------------------------------------------
>
>                 Key: ELY-1499
>                 URL: https://issues.jboss.org/browse/ELY-1499
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: HTTP
>    Affects Versions: 1.2.0.Beta12
>            Reporter: Martin Choma
>            Assignee: Darran Lofthouse
>            Priority: Critical
>             Fix For: 1.2.0.Beta13
>
>
> Despite the fact ServerAuthenticationContext is AutoClosable. Newly created instance in HttpAuthenticator#login() is not closed and no reference is passed outside of method, so is left unclosed forever. 
> [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=46513446&defectInstanceId=9767772&mergedDefectId=1464362



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 09:26:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 25 Jan 2018 09:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1500) Coverity,
 Infinite Loop in FactoryCredentialSource
In-Reply-To: <JIRA.12730813.1516890053000@Atlassian.JIRA>
References: <JIRA.12730813.1516890053000@Atlassian.JIRA>
	<JIRA.12730813.1516890053000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730813.1516890053000.98560.1516890360903@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1500:
------------------------------
    Description: 
Effectivelly Elytron contains infinite recursion implemented.
{code:java|title=FactoryCredentialSource.java}
    @Override
    public SupportLevel getCredentialAcquireSupport(Class<? extends Credential> credentialType, String algorithmName, AlgorithmParameterSpec parameterSpec) throws IOException {
        return getCredentialAcquireSupport(credentialType, algorithmName, parameterSpec) != null ? SupportLevel.SUPPORTED : SupportLevel.UNSUPPORTED;
    }
{code}

[1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=46596205&defectInstanceId=9782368&mergedDefectId=1464361

  was:
Effectivelly Elytron contains infinite recursion implemented.
{code:java|title=FactoryCredentialSource.java}
    @Override
    public SupportLevel getCredentialAcquireSupport(Class<? extends Credential> credentialType, String algorithmName, AlgorithmParameterSpec parameterSpec) throws IOException {
        return getCredentialAcquireSupport(credentialType, algorithmName, parameterSpec) != null ? SupportLevel.SUPPORTED : SupportLevel.UNSUPPORTED;
    }
{code}



> Coverity, Infinite Loop in FactoryCredentialSource
> --------------------------------------------------
>
>                 Key: ELY-1500
>                 URL: https://issues.jboss.org/browse/ELY-1500
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credentials
>    Affects Versions: 1.2.0.Beta12
>            Reporter: Martin Choma
>            Priority: Critical
>
> Effectivelly Elytron contains infinite recursion implemented.
> {code:java|title=FactoryCredentialSource.java}
>     @Override
>     public SupportLevel getCredentialAcquireSupport(Class<? extends Credential> credentialType, String algorithmName, AlgorithmParameterSpec parameterSpec) throws IOException {
>         return getCredentialAcquireSupport(credentialType, algorithmName, parameterSpec) != null ? SupportLevel.SUPPORTED : SupportLevel.UNSUPPORTED;
>     }
> {code}
> [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=46596205&defectInstanceId=9782368&mergedDefectId=1464361



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 09:40:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Thu, 25 Jan 2018 09:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1500) Coverity,
 Infinite Loop in FactoryCredentialSource
In-Reply-To: <JIRA.12730813.1516890053000@Atlassian.JIRA>
References: <JIRA.12730813.1516890053000@Atlassian.JIRA>
	<JIRA.12730813.1516890053000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730813.1516890053000.98746.1516891200297@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1500:
------------------------------
    Fix Version/s: 1.2.0.Beta14


> Coverity, Infinite Loop in FactoryCredentialSource
> --------------------------------------------------
>
>                 Key: ELY-1500
>                 URL: https://issues.jboss.org/browse/ELY-1500
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credentials
>    Affects Versions: 1.2.0.Beta12
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta14
>
>
> Effectivelly Elytron contains infinite recursion implemented.
> {code:java|title=FactoryCredentialSource.java}
>     @Override
>     public SupportLevel getCredentialAcquireSupport(Class<? extends Credential> credentialType, String algorithmName, AlgorithmParameterSpec parameterSpec) throws IOException {
>         return getCredentialAcquireSupport(credentialType, algorithmName, parameterSpec) != null ? SupportLevel.SUPPORTED : SupportLevel.UNSUPPORTED;
>     }
> {code}
> [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=46596205&defectInstanceId=9782368&mergedDefectId=1464361



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 09:52:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 09:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1427) Credential store type PKCS12
 works fine when using OracleJDK and OpenJDK but doesn't work using IBM JDK.
In-Reply-To: <JIRA.12717607.1508766296000@Atlassian.JIRA>
References: <JIRA.12717607.1508766296000@Atlassian.JIRA>
	<JIRA.12717607.1508766296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12717607.1508766296000.98905.1516891920540@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523888#comment-13523888 ] 

Jan Kalina commented on ELY-1427:
---------------------------------

This is property of IBM Java - its implementation of PKCS12 KeyStore does not allow to store custom objects.
See discussion in ELY-1295.

> Credential store type PKCS12 works fine when using OracleJDK and OpenJDK but doesn't work using IBM JDK.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-1427
>                 URL: https://issues.jboss.org/browse/ELY-1427
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Hynek ?v?bek
>            Priority: Critical
>
> Credential store type PKCS12 works fine when using OracleJDK and OpenJDK.
> Problem occurs when we use IBM JDK, add-alias works fine for first time, but for add-alias for second time with same alias name we expect message about duplicity rather than current error message about SecretKeyFactory not availability.
> {code}
> "WFLYCTL0158: Operation handler failed: java.lang.RuntimeException: WFLYELY00009: Unable to complete operation. 'ELY09504: Cannot acquire a credential from the credential store->Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available->1.2.840.113549.1.7.1 SecretKeyFactory not available'",
> {code}
> *NOTE*
> I met same problem with Oracle JDK 1.8 u66, with u144 is everythink ok.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 09:52:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 09:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1427) Credential store type PKCS12
 works fine when using OracleJDK and OpenJDK but doesn't work using IBM JDK.
In-Reply-To: <JIRA.12717607.1508766296000@Atlassian.JIRA>
References: <JIRA.12717607.1508766296000@Atlassian.JIRA>
	<JIRA.12717607.1508766296000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12717607.1508766296000.98912.1516891920699@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1427?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523888#comment-13523888 ] 

Jan Kalina edited comment on ELY-1427 at 1/25/18 9:51 AM:
----------------------------------------------------------

This is property of IBM Java - its implementation of PKCS12 KeyStore does not allow to store custom objects.
This cannot be supported on IBM Java.
See discussion in ELY-1295.


was (Author: honza889):
This is property of IBM Java - its implementation of PKCS12 KeyStore does not allow to store custom objects.
See discussion in ELY-1295.

> Credential store type PKCS12 works fine when using OracleJDK and OpenJDK but doesn't work using IBM JDK.
> --------------------------------------------------------------------------------------------------------
>
>                 Key: ELY-1427
>                 URL: https://issues.jboss.org/browse/ELY-1427
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Hynek ?v?bek
>            Priority: Critical
>
> Credential store type PKCS12 works fine when using OracleJDK and OpenJDK.
> Problem occurs when we use IBM JDK, add-alias works fine for first time, but for add-alias for second time with same alias name we expect message about duplicity rather than current error message about SecretKeyFactory not availability.
> {code}
> "WFLYCTL0158: Operation handler failed: java.lang.RuntimeException: WFLYELY00009: Unable to complete operation. 'ELY09504: Cannot acquire a credential from the credential store->Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available->1.2.840.113549.1.7.1 SecretKeyFactory not available'",
> {code}
> *NOTE*
> I met same problem with Oracle JDK 1.8 u66, with u144 is everythink ok.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 09:53:01 2018
From: issues at jboss.org (Priyanka Nag (JIRA))
Date: Thu, 25 Jan 2018 09:53:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest
 fails on IBM JDK
In-Reply-To: <JIRA.12702872.1500553419000@Atlassian.JIRA>
References: <JIRA.12702872.1500553419000@Atlassian.JIRA>
	<JIRA.12702872.1500553419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702872.1500553419000.98943.1516891981227@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Priyanka Nag reassigned ELY-1295:
---------------------------------

    Assignee: Priyanka Nag  (was: Jan Kalina)


> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
>                 Key: ELY-1295
>                 URL: https://issues.jboss.org/browse/ELY-1295
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Peter Palaga
>            Assignee: Priyanka Nag
>            Priority: Critical
>              Labels: ibm-java
>             Fix For: 1.2.0.Beta12
>
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>  
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>  
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> 	at java.lang.Class.forNameImpl(Native Method)
> 	at java.lang.Class.forName(Class.java:278)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	at java.security.KeyStore.getEntry(KeyStore.java:1532)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> 	... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/72967600a98dee832e151ff8f6fb64af0a84bd14#diff-faa6b27609575ef29472bcc75c87eb36R87



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 09:54:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 09:54:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1496) Test PKCS12
 KeystoreCredentialStore on non-Oracle JDKs
In-Reply-To: <JIRA.12730635.1516813497000@Atlassian.JIRA>
References: <JIRA.12730635.1516813497000@Atlassian.JIRA>
	<JIRA.12730635.1516813497000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730635.1516813497000.98974.1516892041890@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1496?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1496:
----------------------------
    Description: 
As part of ELY-1494 was disabled testing with PKCS12 KeyStore on non-oracle JDKs, because following problems:

* IBM and HP (and some older Oracle too) requires provider in signed JAR, which fails on directory of classes used by surefire/junit elytron tests (see ELY-1494)
* * IBM does not allow storing custom objects in PKCS12 KeyStore - allows predefined set of specs/algorithms - this cannot be workarounded currently (see discussion in ELY-1295)

This testing should be re-enabled if this will be fixed in mentioned JDKs.

The first problem can be solved on our side too:
* rework junit testing to operate on generated (and possibly signed) elytron JAR
* test this from different module, outside of elytron - when elytron is dependency, it is packed in JAR

  was:
As part of ELY-1494 was disabled testing with PKCS12 KeyStore on non-oracle JDKs, because following problems:

* IBM and HP (and some older Oracle too) requires provider in signed JAR, which fails on directory of classes used by surefire/junit elytron tests (see ELY-1494)
* * IBM does not allow storing custom objects in PKCS12 KeyStore - allows predefined set of specs/algorithms - this cannot be workarounded currently

This testing should be re-enabled if this will be fixed in mentioned JDKs.

The first problem can be solved on our side too:
* rework junit testing to operate on generated (and possibly signed) elytron JAR
* test this from different module, outside of elytron - when elytron is dependency, it is packed in JAR



> Test PKCS12 KeystoreCredentialStore on non-Oracle JDKs
> ------------------------------------------------------
>
>                 Key: ELY-1496
>                 URL: https://issues.jboss.org/browse/ELY-1496
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Credential Store
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Jan Kalina
>            Priority: Minor
>
> As part of ELY-1494 was disabled testing with PKCS12 KeyStore on non-oracle JDKs, because following problems:
> * IBM and HP (and some older Oracle too) requires provider in signed JAR, which fails on directory of classes used by surefire/junit elytron tests (see ELY-1494)
> * * IBM does not allow storing custom objects in PKCS12 KeyStore - allows predefined set of specs/algorithms - this cannot be workarounded currently (see discussion in ELY-1295)
> This testing should be re-enabled if this will be fixed in mentioned JDKs.
> The first problem can be solved on our side too:
> * rework junit testing to operate on generated (and possibly signed) elytron JAR
> * test this from different module, outside of elytron - when elytron is dependency, it is packed in JAR



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 10:00:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 10:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1500) Coverity,
 Infinite Loop in FactoryCredentialSource
In-Reply-To: <JIRA.12730813.1516890053000@Atlassian.JIRA>
References: <JIRA.12730813.1516890053000@Atlassian.JIRA>
	<JIRA.12730813.1516890053000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730813.1516890053000.99017.1516892400384@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1500?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-1500:
-------------------------------

    Assignee: Jan Kalina


> Coverity, Infinite Loop in FactoryCredentialSource
> --------------------------------------------------
>
>                 Key: ELY-1500
>                 URL: https://issues.jboss.org/browse/ELY-1500
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credentials
>    Affects Versions: 1.2.0.Beta12
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.2.0.Beta14
>
>
> Effectivelly Elytron contains infinite recursion implemented.
> {code:java|title=FactoryCredentialSource.java}
>     @Override
>     public SupportLevel getCredentialAcquireSupport(Class<? extends Credential> credentialType, String algorithmName, AlgorithmParameterSpec parameterSpec) throws IOException {
>         return getCredentialAcquireSupport(credentialType, algorithmName, parameterSpec) != null ? SupportLevel.SUPPORTED : SupportLevel.UNSUPPORTED;
>     }
> {code}
> [1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=46596205&defectInstanceId=9782368&mergedDefectId=1464361



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 10:01:01 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Thu, 25 Jan 2018 10:01:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9726) Upgrade JSF based on Mojarra
	2.2.13.SP5
In-Reply-To: <JIRA.12730516.1516788267000@Atlassian.JIRA>
References: <JIRA.12730516.1516788267000@Atlassian.JIRA>
	<JIRA.12730516.1516788267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730516.1516788267000.99043.1516892461648@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9726?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky reassigned WFLY-9726:
-----------------------------------

    Assignee: Ivo Studensky  (was: Bartosz Spyrko-?mietanko)


> Upgrade JSF based on Mojarra 2.2.13.SP5
> ---------------------------------------
>
>                 Key: WFLY-9726
>                 URL: https://issues.jboss.org/browse/WFLY-9726
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: JSF
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>
> Upgrade JSF based on Mojarra 2.2.13.SP. This incorporates the patch for WFLY-8573 / [JAVASERVERFACES_SPEC_PUBLIC-671 | https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-671]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 10:12:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 10:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1474) GssapiCompatibilitySuiteChild
 fails on solaris
In-Reply-To: <JIRA.12726223.1514900643000@Atlassian.JIRA>
References: <JIRA.12726223.1514900643000@Atlassian.JIRA>
	<JIRA.12726223.1514900643000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726223.1514900643000.99201.1516893120952@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523916#comment-13523916 ] 

Jan Kalina commented on ELY-1474:
---------------------------------

GssCompatibilityTests was removed as part of ELY-483.

> GssapiCompatibilitySuiteChild fails on solaris
> ----------------------------------------------
>
>                 Key: ELY-1474
>                 URL: https://issues.jboss.org/browse/ELY-1474
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta13
>
>
> - On same java (Oracle java) test does not fail on other OS
> - We don't test other javas on solaris OS
> Problem is on line comparing expected sasl message witch actual.
> {code:java|title=GssapiCompatibilitySuiteChild}
> exchange = evaluateByClient(exchange);
>         assertEquals(" ", ByteIterator.ofBytes(exchange).hexEncode().drainToString());
> {code}
> Stacktrace
> {noformat}
> org.junit.ComparisonFailure: expected:<...03020110a281bf0481bc[ ]> but was:<...03020110a281bf0481bc[ ]>
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:121)
> {noformat}
> Log
> {noformat}
> 19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:52> loginClient
> Debug is  true storeKey true useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is true principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
> Refreshing Kerberos configuration
> 		[Krb5LoginModule] user entered username: jduke
> principal is jduke at WILDFLY.ORG
> EncryptionKey: keyType=16 keyBytes (hex dump)=0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
> 0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;
> Added server's keyKerberos Principal jduke at WILDFLY.ORGKey Version 0key EncryptionKey: keyType=16 keyBytes (hex dump)=
> 0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
> 0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;
> 		[Krb5LoginModule] added Krb5Principal  jduke at WILDFLY.ORG to Subject
> Commit Succeeded 
> 19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:57> loginServer
> Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator false KeyTab is /mnt/hudson_workspace/workspace/wildfly-elytron-unit-tests/20ff21f6/wildfly-elytron/./target/apache-ds/working/serverKeyTab refreshKrb5Config is true principal is sasl/test_server_1 tryFirstPass is false useFirstPass is false storePass is false clearPass is false
> Refreshing Kerberos configuration
> principal is sasl/test_server_1 at WILDFLY.ORG
> Will use keytab
> Commit Succeeded 
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:68> Acceptor Name 'sasl at test_server_1'
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:100> CallbackHandler does not support CredentialCallback: javax.security.auth.callback.UnsupportedCallbackException
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$NoCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:421)
> 	at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:120)
> 	at org.wildfly.security.sasl.gssapi.GssapiClient.<init>(GssapiClient.java:93)
> 	at org.wildfly.security.sasl.gssapi.GssapiClientFactory.createSaslClient(GssapiClientFactory.java:42)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$0(GssapiCompatibilitySuiteChild.java:103)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:97)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
> 	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runners.Suite.runChild(Suite.java:128)
> 	at org.junit.runners.Suite.runChild(Suite.java:27)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:119> Delegating credential = false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:140> Setting requering mutual authentication to true
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:74> Obtaining GSSCredential for the service from callback handler...
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:80> Unable to obtain GSSCredential from CallbackHandler: javax.security.auth.callback.UnsupportedCallbackException
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$AuthorizeOnlyCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:413)
> 	at org.wildfly.security.sasl.gssapi.GssapiServer.<init>(GssapiServer.java:75)
> 	at org.wildfly.security.sasl.gssapi.GssapiServerFactory.createSaslServer(GssapiServerFactory.java:44)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$1(GssapiCompatibilitySuiteChild.java:111)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:106)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
> 	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runners.Suite.runChild(Suite.java:128)
> 	at org.junit.runners.Suite.runChild(Suite.java:27)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:87> Our name 'sasl at test_server_1'
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:229> GSSContext not established, expecting subsequent exchanges.
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/jdk=java18_default,label=eap-sustaining&&solaris11&&x86_64/testReport/-sustaining&&solaris10&&sparc/testReport
> [2] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 10:12:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 10:12:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1474) GssapiCompatibilitySuiteChild
 fails on solaris
In-Reply-To: <JIRA.12726223.1514900643000@Atlassian.JIRA>
References: <JIRA.12726223.1514900643000@Atlassian.JIRA>
	<JIRA.12726223.1514900643000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726223.1514900643000.99204.1516893121065@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-1474:
-------------------------------

    Assignee: Jan Kalina


> GssapiCompatibilitySuiteChild fails on solaris
> ----------------------------------------------
>
>                 Key: ELY-1474
>                 URL: https://issues.jboss.org/browse/ELY-1474
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.2.0.Beta13
>
>
> - On same java (Oracle java) test does not fail on other OS
> - We don't test other javas on solaris OS
> Problem is on line comparing expected sasl message witch actual.
> {code:java|title=GssapiCompatibilitySuiteChild}
> exchange = evaluateByClient(exchange);
>         assertEquals(" ", ByteIterator.ofBytes(exchange).hexEncode().drainToString());
> {code}
> Stacktrace
> {noformat}
> org.junit.ComparisonFailure: expected:<...03020110a281bf0481bc[ ]> but was:<...03020110a281bf0481bc[ ]>
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:121)
> {noformat}
> Log
> {noformat}
> 19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:52> loginClient
> Debug is  true storeKey true useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is true principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
> Refreshing Kerberos configuration
> 		[Krb5LoginModule] user entered username: jduke
> principal is jduke at WILDFLY.ORG
> EncryptionKey: keyType=16 keyBytes (hex dump)=0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
> 0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;
> Added server's keyKerberos Principal jduke at WILDFLY.ORGKey Version 0key EncryptionKey: keyType=16 keyBytes (hex dump)=
> 0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
> 0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;
> 		[Krb5LoginModule] added Krb5Principal  jduke at WILDFLY.ORG to Subject
> Commit Succeeded 
> 19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:57> loginServer
> Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator false KeyTab is /mnt/hudson_workspace/workspace/wildfly-elytron-unit-tests/20ff21f6/wildfly-elytron/./target/apache-ds/working/serverKeyTab refreshKrb5Config is true principal is sasl/test_server_1 tryFirstPass is false useFirstPass is false storePass is false clearPass is false
> Refreshing Kerberos configuration
> principal is sasl/test_server_1 at WILDFLY.ORG
> Will use keytab
> Commit Succeeded 
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:68> Acceptor Name 'sasl at test_server_1'
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:100> CallbackHandler does not support CredentialCallback: javax.security.auth.callback.UnsupportedCallbackException
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$NoCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:421)
> 	at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:120)
> 	at org.wildfly.security.sasl.gssapi.GssapiClient.<init>(GssapiClient.java:93)
> 	at org.wildfly.security.sasl.gssapi.GssapiClientFactory.createSaslClient(GssapiClientFactory.java:42)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$0(GssapiCompatibilitySuiteChild.java:103)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:97)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
> 	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runners.Suite.runChild(Suite.java:128)
> 	at org.junit.runners.Suite.runChild(Suite.java:27)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:119> Delegating credential = false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:140> Setting requering mutual authentication to true
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:74> Obtaining GSSCredential for the service from callback handler...
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:80> Unable to obtain GSSCredential from CallbackHandler: javax.security.auth.callback.UnsupportedCallbackException
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$AuthorizeOnlyCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:413)
> 	at org.wildfly.security.sasl.gssapi.GssapiServer.<init>(GssapiServer.java:75)
> 	at org.wildfly.security.sasl.gssapi.GssapiServerFactory.createSaslServer(GssapiServerFactory.java:44)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$1(GssapiCompatibilitySuiteChild.java:111)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:106)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
> 	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runners.Suite.runChild(Suite.java:128)
> 	at org.junit.runners.Suite.runChild(Suite.java:27)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:87> Our name 'sasl at test_server_1'
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:229> GSSContext not established, expecting subsequent exchanges.
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/jdk=java18_default,label=eap-sustaining&&solaris11&&x86_64/testReport/-sustaining&&solaris10&&sparc/testReport
> [2] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 10:14:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 10:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1474) GssapiCompatibilitySuiteChild
 fails on solaris
In-Reply-To: <JIRA.12726223.1514900643000@Atlassian.JIRA>
References: <JIRA.12726223.1514900643000@Atlassian.JIRA>
	<JIRA.12726223.1514900643000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726223.1514900643000.99237.1516893240377@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed ELY-1474.
---------------------------
    Resolution: Out of Date


> GssapiCompatibilitySuiteChild fails on solaris
> ----------------------------------------------
>
>                 Key: ELY-1474
>                 URL: https://issues.jboss.org/browse/ELY-1474
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Martin Choma
>            Assignee: Jan Kalina
>            Priority: Critical
>             Fix For: 1.2.0.Beta13
>
>
> - On same java (Oracle java) test does not fail on other OS
> - We don't test other javas on solaris OS
> Problem is on line comparing expected sasl message witch actual.
> {code:java|title=GssapiCompatibilitySuiteChild}
> exchange = evaluateByClient(exchange);
>         assertEquals(" ", ByteIterator.ofBytes(exchange).hexEncode().drainToString());
> {code}
> Stacktrace
> {noformat}
> org.junit.ComparisonFailure: expected:<...03020110a281bf0481bc[ ]> but was:<...03020110a281bf0481bc[ ]>
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:121)
> {noformat}
> Log
> {noformat}
> 19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:52> loginClient
> Debug is  true storeKey true useTicketCache false useKeyTab false doNotPrompt false ticketCache is null isInitiator true KeyTab is null refreshKrb5Config is true principal is null tryFirstPass is false useFirstPass is false storePass is false clearPass is false
> Refreshing Kerberos configuration
> 		[Krb5LoginModule] user entered username: jduke
> principal is jduke at WILDFLY.ORG
> EncryptionKey: keyType=16 keyBytes (hex dump)=0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
> 0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;
> Added server's keyKerberos Principal jduke at WILDFLY.ORGKey Version 0key EncryptionKey: keyType=16 keyBytes (hex dump)=
> 0000: 9D A4 38 51 37 A7 83 F4   70 D6 FB A7 25 70 08 0B  ..8Q7...p...%p..
> 0010: DC 97 23 0E C4 6B 68 3B                            ..#..kh;
> 		[Krb5LoginModule] added Krb5Principal  jduke at WILDFLY.ORG to Subject
> Commit Succeeded 
> 19:00:00,123 DEBUG (main) [org.wildfly.security.sasl.gssapi.JaasUtil] <JaasUtil.java:57> loginServer
> Debug is  true storeKey true useTicketCache false useKeyTab true doNotPrompt true ticketCache is null isInitiator false KeyTab is /mnt/hudson_workspace/workspace/wildfly-elytron-unit-tests/20ff21f6/wildfly-elytron/./target/apache-ds/working/serverKeyTab refreshKrb5Config is true principal is sasl/test_server_1 tryFirstPass is false useFirstPass is false storePass is false clearPass is false
> Refreshing Kerberos configuration
> principal is sasl/test_server_1 at WILDFLY.ORG
> Will use keytab
> Commit Succeeded 
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:68> Acceptor Name 'sasl at test_server_1'
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:100> CallbackHandler does not support CredentialCallback: javax.security.auth.callback.UnsupportedCallbackException
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$NoCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:421)
> 	at org.wildfly.security.sasl.util.AbstractSaslParticipant.tryHandleCallbacks(AbstractSaslParticipant.java:120)
> 	at org.wildfly.security.sasl.gssapi.GssapiClient.<init>(GssapiClient.java:93)
> 	at org.wildfly.security.sasl.gssapi.GssapiClientFactory.createSaslClient(GssapiClientFactory.java:42)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$0(GssapiCompatibilitySuiteChild.java:103)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:97)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
> 	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runners.Suite.runChild(Suite.java:128)
> 	at org.junit.runners.Suite.runChild(Suite.java:27)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:119> Delegating credential = false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:140> Setting requering mutual authentication to true
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <DelegatingBasicLogger.java:159> configuredMaxReceiveBuffer=0
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:96> relaxComplianceChecks=false
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <AbstractGssapiMechanism.java:105> QOP={AUTH}
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:74> Obtaining GSSCredential for the service from callback handler...
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:80> Unable to obtain GSSCredential from CallbackHandler: javax.security.auth.callback.UnsupportedCallbackException
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild$AuthorizeOnlyCallbackHandler.handle(GssapiCompatibilitySuiteChild.java:413)
> 	at org.wildfly.security.sasl.gssapi.GssapiServer.<init>(GssapiServer.java:75)
> 	at org.wildfly.security.sasl.gssapi.GssapiServerFactory.createSaslServer(GssapiServerFactory.java:44)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.lambda$test1Auth$1(GssapiCompatibilitySuiteChild.java:111)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.wildfly.security.sasl.gssapi.GssapiCompatibilitySuiteChild.test1Auth(GssapiCompatibilitySuiteChild.java:106)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.executeTestMethod(JUnit4TestRunnerDecorator.java:162)
> 	at mockit.integration.junit4.internal.JUnit4TestRunnerDecorator.invokeExplosively(JUnit4TestRunnerDecorator.java:71)
> 	at mockit.integration.junit4.internal.MockFrameworkMethod.invokeExplosively(MockFrameworkMethod.java:37)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.junit.runners.Suite.runChild(Suite.java:128)
> 	at org.junit.runners.Suite.runChild(Suite.java:27)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
> 	at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:27)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiServer.java:87> Our name 'sasl at test_server_1'
> 19:00:00,123 TRACE (main) [org.wildfly.security.sasl.gssapi] <GssapiClient.java:229> GSSContext not established, expecting subsequent exchanges.
> {noformat}
> [1] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/jdk=java18_default,label=eap-sustaining&&solaris11&&x86_64/testReport/-sustaining&&solaris10&&sparc/testReport
> [2] https://jenkins.hosts.mwqe.eng.bos.redhat.com/hudson/view/EAP7/view/EAP7-Security/view/Wildfly-Elytron/job/wildfly-elytron-unit-tests/lastCompletedBuild/testReport/



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 10:21:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 10:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.99260.1516893660496@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523924#comment-13523924 ] 

Jan Kalina commented on ELY-1483:
---------------------------------

As confirmed by [~fjuma], all mentioned are false positive - rejecting.

> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta13
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:
> {noformat}
> [ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
> {noformat}
> But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?
> False positives because packages asn/x500 were not public in 1.1.7.final :
> - removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 10:21:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 10:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1483) japicmp detects compatibility
	issues
In-Reply-To: <JIRA.12726900.1515411794000@Atlassian.JIRA>
References: <JIRA.12726900.1515411794000@Atlassian.JIRA>
	<JIRA.12726900.1515411794000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726900.1515411794000.99267.1516893660768@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1483?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed ELY-1483.
---------------------------
    Resolution: Rejected


> japicmp detects compatibility issues
> ------------------------------------
>
>                 Key: ELY-1483
>                 URL: https://issues.jboss.org/browse/ELY-1483
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: API / SPI
>    Affects Versions: 1.2.0.Beta11
>            Reporter: Martin Choma
>            Priority: Critical
>             Fix For: 1.2.0.Beta13
>
>         Attachments: japicmp.html
>
>
> I have used japicmp tool to compare public API [1]. Version 1.1.7.Final was compared with master HEAD (in time of writing 1.2.0.Beta12-SNAPSHOT).  This incompatibility was detected:
> {noformat}
> [ERROR] Failed to execute goal com.github.siom79.japicmp:japicmp-maven-plugin:0.11.0:cmp (default) on project wildfly-elytron: Breaking the build because there is at least one incompatibility: org.wildfly.security.auth.server.event.RealmDefiniteOutcomeAuthenticationEvent.RealmDefiniteOutcomeAuthenticationEvent(org.wildfly.security.auth.server.RealmIdentity,org.wildfly.security.credential.Credential,org.wildfly.security.evidence.Evidence):CONSTRUCTOR_LESS_ACCESSIBLE -> [Help 1]
> {noformat}
> But I would say this is false positive. Looking into ELY-1453 effectively visibility of constructor didn't change.  [~honza889] wdyt?
> False positives because packages asn/x500 were not public in 1.1.7.final :
> - removed org.wildfly.security.asn1.ASN1 (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.asn1.OidsUtil$Category (moved to org.wildfly.security.asn1.util)
> - removed org.wildfly.security.x500.X500PrincipalUtil (moved to org.wildfly.security.x500.util)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - removed org.wildfly.security.asn1.ASN1Encoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DERDecoder.DERDecoder(org.wildfly.security.util.ByteIterator)
> - constructor less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.DEREncoder(org.wildfly.security.util.ByteIterator)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeIA5String(org.wildfly.security.util.ByteStringBuilder)
> - method less accessible package_protected  (<-  public ) org.wildfly.security.asn1.DEREncoder.encodeOctetString(org.wildfly.security.util.ByteStringBuilder)
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/1067



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 10:24:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 10:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-787) SASL mechanisms are not IANA
 registered and specifications are not provided
In-Reply-To: <JIRA.12663379.1479911997000@Atlassian.JIRA>
References: <JIRA.12663379.1479911997000@Atlassian.JIRA>
	<JIRA.12663379.1479911997000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12663379.1479911997000.99307.1516893840953@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-787?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-787:
---------------------------
    Issue Type: Task  (was: Bug)


> SASL mechanisms are not IANA registered and specifications are not provided
> ---------------------------------------------------------------------------
>
>                 Key: ELY-787
>                 URL: https://issues.jboss.org/browse/ELY-787
>             Project: WildFly Elytron
>          Issue Type: Task
>            Reporter: Josef Cacek
>            Priority: Critical
>              Labels: sasl
>
> Elytron comes with set of SASL mechanisms (as requested by EAP7-530), but they don't fit SASL requirements. 
> New mechanisms has to be registered by IANA as requested by [SASL RFC 4422 section 5|https://tools.ietf.org/html/rfc4422#section-5] and Java [SaslClientFactory|http://docs.oracle.com/javase/8/docs/api/javax/security/sasl/SaslClientFactory.html] and [SaslServerFactory|http://docs.oracle.com/javase/8/docs/api/javax/security/sasl/SaslServerFactory.html] contracts.
> Current list of mechanisms provided by Elytron, which are not IANA registered:
> * DIGEST-SHA
> * DIGEST-SHA-256
> * DIGEST-SHA-512
> * JBOSS-LOCAL-USER
> *Suggestion for improvement:*
> Provide specifications for the new mechanisms and register the names by IANA (see [section 7 in RFC-4422|https://tools.ietf.org/html/rfc4422#section-7]).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 10:49:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Thu, 25 Jan 2018 10:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3548) CLI,
 Command executor should create daemon thread
In-Reply-To: <JIRA.12730823.1516895283000@Atlassian.JIRA>
References: <JIRA.12730823.1516895283000@Atlassian.JIRA>
	<JIRA.12730823.1516895283150@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730823.1516895283000.99524.1516895340351@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-3548:
--------------------------------------------

             Summary: CLI, Command executor should create daemon thread
                 Key: WFCORE-3548
                 URL: https://issues.jboss.org/browse/WFCORE-3548
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


A CLI class instance (programmatic access to CLI) should not have to call terminate in order for its process to exit. That is caused by a CLI Executor creating non daemon threads.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 11:02:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 11:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-286) HTTP Digest Authentication
In-Reply-To: <JIRA.12583890.1441307301000@Atlassian.JIRA>
References: <JIRA.12583890.1441307301000@Atlassian.JIRA>
	<JIRA.12583890.1441307301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583890.1441307301000.99623.1516896120667@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523970#comment-13523970 ] 

Jan Kalina commented on ELY-286:
--------------------------------

Missing feature to support RFC 7616:
* support of {{username*}} parameter (for sending encoded UTF-8 username)
* {{userhash}} parameter (sending hash of username instead of username) - MUST be implemented on client, SHOULD be implemented on server (but can be design problem to obtain identity from security realm by username hash)

> HTTP Digest Authentication
> --------------------------
>
>                 Key: ELY-286
>                 URL: https://issues.jboss.org/browse/ELY-286
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta14
>
>
> Original Digest RFC [https://tools.ietf.org/html/rfc2069]
> Current Digest RFC [https://tools.ietf.org/html/rfc2617]
> HTTP 1.1 Authentication (Updates RFC2617) [https://tools.ietf.org/html/rfc7235]
> Draft currently under discussion - [https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/]
> RFC7616 Now Proposed Standard
> "HTTP Digest Access Authentication", September 2015
> [https://www.rfc-editor.org/info/rfc7616]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 11:03:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 11:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-286) HTTP Digest Authentication
In-Reply-To: <JIRA.12583890.1441307301000@Atlassian.JIRA>
References: <JIRA.12583890.1441307301000@Atlassian.JIRA>
	<JIRA.12583890.1441307301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12583890.1441307301000.99629.1516896180634@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-286?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13523970#comment-13523970 ] 

Jan Kalina edited comment on ELY-286 at 1/25/18 11:02 AM:
----------------------------------------------------------

Missing feature to support RFC 7616:
* {{username*}} parameter (for sending encoded UTF-8 username)
* {{userhash}} parameter (sending hash of username instead of username) - MUST be implemented on client, SHOULD be implemented on server (but can be design problem to obtain identity from security realm by username hash)


was (Author: honza889):
Missing feature to support RFC 7616:
* support of {{username*}} parameter (for sending encoded UTF-8 username)
* {{userhash}} parameter (sending hash of username instead of username) - MUST be implemented on client, SHOULD be implemented on server (but can be design problem to obtain identity from security realm by username hash)

> HTTP Digest Authentication
> --------------------------
>
>                 Key: ELY-286
>                 URL: https://issues.jboss.org/browse/ELY-286
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta14
>
>
> Original Digest RFC [https://tools.ietf.org/html/rfc2069]
> Current Digest RFC [https://tools.ietf.org/html/rfc2617]
> HTTP 1.1 Authentication (Updates RFC2617) [https://tools.ietf.org/html/rfc7235]
> Draft currently under discussion - [https://datatracker.ietf.org/doc/draft-ietf-httpauth-digest/]
> RFC7616 Now Proposed Standard
> "HTTP Digest Access Authentication", September 2015
> [https://www.rfc-editor.org/info/rfc7616]



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 11:12:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 11:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-839) SetCredentialsConfiguration not
 overriding getCredentialSource()
In-Reply-To: <JIRA.12667920.1481827126000@Atlassian.JIRA>
References: <JIRA.12667920.1481827126000@Atlassian.JIRA>
	<JIRA.12667920.1481827126000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667920.1481827126000.99759.1516896720152@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-839:
---------------------------
    Fix Version/s: 1.1.0.Beta18


> SetCredentialsConfiguration not overriding getCredentialSource()
> ----------------------------------------------------------------
>
>                 Key: ELY-839
>                 URL: https://issues.jboss.org/browse/ELY-839
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.0.Beta18
>
>
> Various methods manipulating the CredentialSource attempt to obtain the current one to add to it but as it is never returned they would always use the default one.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 11:15:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 11:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-839) SetCredentialsConfiguration not
 overriding getCredentialSource()
In-Reply-To: <JIRA.12667920.1481827126000@Atlassian.JIRA>
References: <JIRA.12667920.1481827126000@Atlassian.JIRA>
	<JIRA.12667920.1481827126000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12667920.1481827126000.99785.1516896900615@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-839?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina resolved ELY-839.
----------------------------
    Resolution: Done


Resolved long time ago + outdated (given class removed already).

> SetCredentialsConfiguration not overriding getCredentialSource()
> ----------------------------------------------------------------
>
>                 Key: ELY-839
>                 URL: https://issues.jboss.org/browse/ELY-839
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>             Fix For: 1.1.0.Beta18
>
>
> Various methods manipulating the CredentialSource attempt to obtain the current one to add to it but as it is never returned they would always use the default one.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 11:16:00 2018
From: issues at jboss.org (Martin Kouba (JIRA))
Date: Thu, 25 Jan 2018 11:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9732) Defer invocation of
 WeldBootstrap.endInitialization() until all EE components are started
In-Reply-To: <JIRA.12730828.1516896942000@Atlassian.JIRA>
References: <JIRA.12730828.1516896942000@Atlassian.JIRA>
	<JIRA.12730828.1516896942493@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730828.1516896942000.99787.1516896960223@Atlassian.JIRA>

Martin Kouba created WFLY-9732:
----------------------------------

             Summary: Defer invocation of WeldBootstrap.endInitialization() until all EE components are started
                 Key: WFLY-9732
                 URL: https://issues.jboss.org/browse/WFLY-9732
             Project: WildFly
          Issue Type: Task
          Components: CDI / Weld
            Reporter: Martin Kouba
            Assignee: Martin Kouba
             Fix For: 12.0.0.Alpha1


WildFly currently invokes {{org.jboss.weld.bootstrap.api.Bootstrap.endInitialization()}} before EE components (such as servlets) are installed. As a result, container lifecycle events (such as {{ProcessInjectionTarget}}) are fired after Weld performs various cleanup actions. This is ok and works fine but prevents from minor optimizations.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 11:20:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 11:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1501) Release WildFly Elytron
	1.1.8.Final
In-Reply-To: <JIRA.12730829.1516897148000@Atlassian.JIRA>
References: <JIRA.12730829.1516897148000@Atlassian.JIRA>
	<JIRA.12730829.1516897148226@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730829.1516897148000.99819.1516897200247@Atlassian.JIRA>

Darran Lofthouse created ELY-1501:
-------------------------------------

             Summary: Release WildFly Elytron 1.1.8.Final
                 Key: ELY-1501
                 URL: https://issues.jboss.org/browse/ELY-1501
             Project: WildFly Elytron
          Issue Type: Release
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.1.8.CR1






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 11:20:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 25 Jan 2018 11:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3549) Drop back to a final
 version of jboss-logmanager
In-Reply-To: <JIRA.12730830.1516897199000@Atlassian.JIRA>
References: <JIRA.12730830.1516897199000@Atlassian.JIRA>
	<JIRA.12730830.1516897199030@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730830.1516897199000.99821.1516897200333@Atlassian.JIRA>

James Perkins created WFCORE-3549:
-------------------------------------

             Summary: Drop back to a final version of jboss-logmanager
                 Key: WFCORE-3549
                 URL: https://issues.jboss.org/browse/WFCORE-3549
             Project: WildFly Core
          Issue Type: Component Upgrade
          Components: Logging
            Reporter: James Perkins
            Assignee: James Perkins


Components in WildFly should generally always be final. There was an upgrade to {{org.jboss.logmanager:jboss-logmanager}} to allow for a {{json-formatter}} PR to be done. This should be done in a topic branch and the log manager upgrade should not be merged in until the log manager itself is final.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 11:23:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 11:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1439) Perform certificate
 authentication only in cases when certificate is present
In-Reply-To: <JIRA.12720201.1510222704000@Atlassian.JIRA>
References: <JIRA.12720201.1510222704000@Atlassian.JIRA>
	<JIRA.12720201.1510222704000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12720201.1510222704000.99834.1516897380549@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1439?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1439:
----------------------------
    Description: 
{panel}
Martin Choma?10:18 AM
I see some client certificate verificaton related exception. However, I am not configuring 2 way SSL, just 1 way SSL. Why does this verification happens eagerly when there is no chance it can success?
Darran Lofthouse?11:03 AM
@MartinChoma it is one of those older APIs where the only way we can find out if we do have a peer certificate is to make the call and find out if we get a response or an exception - that is why it is only logged at TRACE level.??In this case this is in the mechanism initialisation so slightly separate from the SSLContext handling.??Maybe we could double check if we have access to the SSLContext itself at any point and check if needing or wanting a client cert was enabled, but in the want case we would still get this same message if it was not available.
Martin Choma?11:09 AM
@DarranLofthouse , yes I was thinking of optimalization based on leveraging need-client-auth attribute. I will create enhancement ELY JIRA.
Darran Lofthouse?11:10 AM
@MartinChoma what we would need to check is if we get access to that, I can't remember if Remoting passes us the complete SSLContext or just the SSLSession if it exists
{panel}

{noformat}
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "management-client"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.5.Final-redhat-1"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer
10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism ANONYMOUS
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 79 bytes
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) No buffers in queue for message header
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Allocated fresh buffers
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received 79 bytes
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=75 cap=8192]
10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capabilities response
10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: version 1
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote endpoint name "localhost:MANAGEMENT"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: SASL mechanism ANONYMOUS
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) SASL mechanism ANONYMOUS added to allowed set
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: message close protocol supported
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote version is "5.0.5.Final-redhat-1"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels in is "40"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels out is "40"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: authentication service
10:13:29,084 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient for mechanism ANONYMOUS, using Provider WildFlyElytron and protocol remote
10:13:29,087 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient [org.wildfly.security.sasl.util.PrivilegedSaslClient at 286a43a6->org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory$LocalPrincipalSaslClient at 149c06be->org.wildfly.security.sasl.anonymous.AnonymousSaslClient at 56ad35c9] for mechanisms [ANONYMOUS]
10:13:29,088 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client initiating authentication using mechanism ANONYMOUS
10:13:29,091 TRACE [org.jboss.remoting.endpoint] (XNIO-1 I/O-1) Allocated tick to 9 of endpoint "management-client" <7968a9d> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor at 71812f8)
10:13:29,093 TRACE [org.jboss.remoting.remote] (XNIO-1 task-3) Setting read listener to org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication at 4dff2604
10:13:29,094 TRACE [org.jboss.remoting.endpoint] (XNIO-1 task-3) Resource closed count 00000008 of endpoint "management-client" <7968a9d> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor at 71812f8)
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Sent 24 bytes
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Flushed channel
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 24 bytes
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received authentication request
10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Peer unverified: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
	at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1000)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
	at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:68)
	at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
	at org.wildfly.security.sasl.util.SetMechanismInformationSaslServerFactory.createSaslServer(SetMechanismInformationSaslServerFactory.java:74)
	at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory.createSaslServer(AuthenticationCompleteCallbackSaslServerFactory.java:51)
	at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.createSaslServer(TrustManagerSaslServerFactory.java:72)
	at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory.createSaslServer(AuthenticationTimeoutSaslServerFactory.java:74)
	at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
	at org.wildfly.security.sasl.util.SSLSaslServerFactory.createSaslServer(SSLSaslServerFactory.java:67)
	at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
	at org.wildfly.security.sasl.util.ServerNameSaslServerFactory.createSaslServer(ServerNameSaslServerFactory.java:48)
	at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
	at org.wildfly.security.sasl.util.ProtocolSaslServerFactory.createSaslServer(ProtocolSaslServerFactory.java:48)
	at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory.createSaslServer(SecurityIdentitySaslServerFactory.java:51)
	at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:61)
	at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:52)
	at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.createMechanism(AbstractMechanismAuthenticationFactory.java:54)
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:281)
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:141)
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
	at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1131)
	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)

10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback type='SASL' name='ANONYMOUS' host-name='localhost.localdomain' protocol='remote'
10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1 at 2a8e9ff7->org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer at 493accbb->org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1 at 6a9c91e2->org.wildfly.security.sasl.anonymous.AnonymousSaslServer at 2b612585] for mechanism [ANONYMOUS]
{noformat}


  was:
{noformat}
Martin Choma?10:18 AM
I see some client certificate verificaton related exception. However, I am not configuring 2 way SSL, just 1 way SSL. Why does this verification happens eagerly when there is no chance it can success?
Darran Lofthouse?11:03 AM
@MartinChoma it is one of those older APIs where the only way we can find out if we do have a peer certificate is to make the call and find out if we get a response or an exception - that is why it is only logged at TRACE level.??In this case this is in the mechanism initialisation so slightly separate from the SSLContext handling.??Maybe we could double check if we have access to the SSLContext itself at any point and check if needing or wanting a client cert was enabled, but in the want case we would still get this same message if it was not available.
Martin Choma?11:09 AM
@DarranLofthouse , yes I was thinking of optimalization based on leveraging need-client-auth attribute. I will create enhancement ELY JIRA.
Darran Lofthouse?11:10 AM
@MartinChoma what we would need to check is if we get access to that, I can't remember if Remoting passes us the complete SSLContext or just the SSLSession if it exists
{noformat}

{noformat}
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "management-client"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.5.Final-redhat-1"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer
10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism ANONYMOUS
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 79 bytes
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) No buffers in queue for message header
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Allocated fresh buffers
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received 79 bytes
10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=75 cap=8192]
10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capabilities response
10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: version 1
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote endpoint name "localhost:MANAGEMENT"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: SASL mechanism ANONYMOUS
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) SASL mechanism ANONYMOUS added to allowed set
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: message close protocol supported
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote version is "5.0.5.Final-redhat-1"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels in is "40"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels out is "40"
10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: authentication service
10:13:29,084 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient for mechanism ANONYMOUS, using Provider WildFlyElytron and protocol remote
10:13:29,087 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient [org.wildfly.security.sasl.util.PrivilegedSaslClient at 286a43a6->org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory$LocalPrincipalSaslClient at 149c06be->org.wildfly.security.sasl.anonymous.AnonymousSaslClient at 56ad35c9] for mechanisms [ANONYMOUS]
10:13:29,088 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client initiating authentication using mechanism ANONYMOUS
10:13:29,091 TRACE [org.jboss.remoting.endpoint] (XNIO-1 I/O-1) Allocated tick to 9 of endpoint "management-client" <7968a9d> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor at 71812f8)
10:13:29,093 TRACE [org.jboss.remoting.remote] (XNIO-1 task-3) Setting read listener to org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication at 4dff2604
10:13:29,094 TRACE [org.jboss.remoting.endpoint] (XNIO-1 task-3) Resource closed count 00000008 of endpoint "management-client" <7968a9d> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor at 71812f8)
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Sent 24 bytes
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Flushed channel
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 24 bytes
10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received authentication request
10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Peer unverified: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
	at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1000)
	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
	at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:68)
	at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
	at org.wildfly.security.sasl.util.SetMechanismInformationSaslServerFactory.createSaslServer(SetMechanismInformationSaslServerFactory.java:74)
	at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory.createSaslServer(AuthenticationCompleteCallbackSaslServerFactory.java:51)
	at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.createSaslServer(TrustManagerSaslServerFactory.java:72)
	at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory.createSaslServer(AuthenticationTimeoutSaslServerFactory.java:74)
	at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
	at org.wildfly.security.sasl.util.SSLSaslServerFactory.createSaslServer(SSLSaslServerFactory.java:67)
	at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
	at org.wildfly.security.sasl.util.ServerNameSaslServerFactory.createSaslServer(ServerNameSaslServerFactory.java:48)
	at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
	at org.wildfly.security.sasl.util.ProtocolSaslServerFactory.createSaslServer(ProtocolSaslServerFactory.java:48)
	at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory.createSaslServer(SecurityIdentitySaslServerFactory.java:51)
	at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:61)
	at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:52)
	at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.createMechanism(AbstractMechanismAuthenticationFactory.java:54)
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:281)
	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:141)
	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
	at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1131)
	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
	at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)

10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback type='SASL' name='ANONYMOUS' host-name='localhost.localdomain' protocol='remote'
10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1 at 2a8e9ff7->org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer at 493accbb->org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1 at 6a9c91e2->org.wildfly.security.sasl.anonymous.AnonymousSaslServer at 2b612585] for mechanism [ANONYMOUS]
{noformat}




> Perform certificate authentication only in cases when certificate is present
> ----------------------------------------------------------------------------
>
>                 Key: ELY-1439
>                 URL: https://issues.jboss.org/browse/ELY-1439
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Mechanisms
>    Affects Versions: 1.2.0.Beta9
>            Reporter: Martin Choma
>
> {panel}
> Martin Choma?10:18 AM
> I see some client certificate verificaton related exception. However, I am not configuring 2 way SSL, just 1 way SSL. Why does this verification happens eagerly when there is no chance it can success?
> Darran Lofthouse?11:03 AM
> @MartinChoma it is one of those older APIs where the only way we can find out if we do have a peer certificate is to make the call and find out if we get a response or an exception - that is why it is only logged at TRACE level.??In this case this is in the mechanism initialisation so slightly separate from the SSLContext handling.??Maybe we could double check if we have access to the SSLContext itself at any point and check if needing or wanting a client cert was enabled, but in the want case we would still get this same message if it was not available.
> Martin Choma?11:09 AM
> @DarranLofthouse , yes I was thinking of optimalization based on leveraging need-client-auth attribute. I will create enhancement ELY JIRA.
> Darran Lofthouse?11:10 AM
> @MartinChoma what we would need to check is if we get access to that, I can't remember if Remoting passes us the complete SSLContext or just the SSLSession if it exists
> {panel}
> {noformat}
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capabilities request
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: version 1
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote endpoint name "management-client"
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: message close protocol supported
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote version is "5.0.5.Final-redhat-1"
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels in is "40"
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: remote channels out is "40"
> 10:13:29,062 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received capability: authentication service
> 10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) No EXTERNAL mechanism due to unverified SSL peer
> 10:13:29,067 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Added mechanism ANONYMOUS
> 10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 10:13:29,067 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No read bytes available
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Sent 79 bytes
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Flushed channel
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) No buffers in queue for message header
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Allocated fresh buffers
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received 79 bytes
> 10:13:29,068 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Received message java.nio.HeapByteBuffer[pos=0 lim=75 cap=8192]
> 10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capabilities response
> 10:13:29,068 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: version 1
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote endpoint name "localhost:MANAGEMENT"
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: SASL mechanism ANONYMOUS
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) SASL mechanism ANONYMOUS added to allowed set
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: message close protocol supported
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote version is "5.0.5.Final-redhat-1"
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels in is "40"
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: remote channels out is "40"
> 10:13:29,069 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client received capability: authentication service
> 10:13:29,084 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient for mechanism ANONYMOUS, using Provider WildFlyElytron and protocol remote
> 10:13:29,087 TRACE [org.wildfly.security] (XNIO-1 I/O-1) Created SaslClient [org.wildfly.security.sasl.util.PrivilegedSaslClient at 286a43a6->org.wildfly.security.sasl.util.LocalPrincipalSaslClientFactory$LocalPrincipalSaslClient at 149c06be->org.wildfly.security.sasl.anonymous.AnonymousSaslClient at 56ad35c9] for mechanisms [ANONYMOUS]
> 10:13:29,088 TRACE [org.jboss.remoting.remote.client] (XNIO-1 I/O-1) Client initiating authentication using mechanism ANONYMOUS
> 10:13:29,091 TRACE [org.jboss.remoting.endpoint] (XNIO-1 I/O-1) Allocated tick to 9 of endpoint "management-client" <7968a9d> (opened org.jboss.remoting3.EndpointImpl$TrackingExecutor at 71812f8)
> 10:13:29,093 TRACE [org.jboss.remoting.remote] (XNIO-1 task-3) Setting read listener to org.jboss.remoting3.remote.ClientConnectionOpenListener$Authentication at 4dff2604
> 10:13:29,094 TRACE [org.jboss.remoting.endpoint] (XNIO-1 task-3) Resource closed count 00000008 of endpoint "management-client" <7968a9d> (closed org.jboss.remoting3.EndpointImpl$TrackingExecutor at 71812f8)
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Sent 24 bytes
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) No buffers in queue for message header
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (XNIO-1 I/O-1) Flushed channel
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Allocated fresh buffers
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received 24 bytes
> 10:13:29,094 TRACE [org.jboss.remoting.remote.connection] (management I/O-2) Received message java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
> 10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Received java.nio.HeapByteBuffer[pos=0 lim=20 cap=8192]
> 10:13:29,094 TRACE [org.jboss.remoting.remote.server] (management I/O-2) Server received authentication request
> 10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Peer unverified: javax.net.ssl.SSLPeerUnverifiedException: peer not authenticated
> 	at sun.security.ssl.SSLSessionImpl.getPeerCertificates(SSLSessionImpl.java:431)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handleOne(ServerAuthenticationContext.java:1000)
> 	at org.wildfly.security.auth.server.ServerAuthenticationContext$1.handle(ServerAuthenticationContext.java:839)
> 	at org.wildfly.security.sasl.util.SSLQueryCallbackHandler.handle(SSLQueryCallbackHandler.java:68)
> 	at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.lambda$createSaslServer$0(TrustManagerSaslServerFactory.java:96)
> 	at org.wildfly.security.sasl.util.SetMechanismInformationSaslServerFactory.createSaslServer(SetMechanismInformationSaslServerFactory.java:74)
> 	at org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory.createSaslServer(AuthenticationCompleteCallbackSaslServerFactory.java:51)
> 	at org.wildfly.security.sasl.util.TrustManagerSaslServerFactory.createSaslServer(TrustManagerSaslServerFactory.java:72)
> 	at org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory.createSaslServer(AuthenticationTimeoutSaslServerFactory.java:74)
> 	at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
> 	at org.wildfly.security.sasl.util.SSLSaslServerFactory.createSaslServer(SSLSaslServerFactory.java:67)
> 	at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
> 	at org.wildfly.security.sasl.util.ServerNameSaslServerFactory.createSaslServer(ServerNameSaslServerFactory.java:48)
> 	at org.wildfly.security.sasl.util.AbstractDelegatingSaslServerFactory.createSaslServer(AbstractDelegatingSaslServerFactory.java:64)
> 	at org.wildfly.security.sasl.util.ProtocolSaslServerFactory.createSaslServer(ProtocolSaslServerFactory.java:48)
> 	at org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory.createSaslServer(SecurityIdentitySaslServerFactory.java:51)
> 	at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:61)
> 	at org.wildfly.security.auth.server.SaslAuthenticationFactory.doCreate(SaslAuthenticationFactory.java:52)
> 	at org.wildfly.security.auth.server.AbstractMechanismAuthenticationFactory.createMechanism(AbstractMechanismAuthenticationFactory.java:54)
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:281)
> 	at org.jboss.remoting3.remote.ServerConnectionOpenListener$Initial.handleEvent(ServerConnectionOpenListener.java:141)
> 	at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> 	at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> 	at io.undertow.protocols.ssl.SslConduit$SslReadReadyHandler.readReady(SslConduit.java:1131)
> 	at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:89)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:591)
> 10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Handling MechanismInformationCallback type='SASL' name='ANONYMOUS' host-name='localhost.localdomain' protocol='remote'
> 10:13:29,097 TRACE [org.wildfly.security] (management I/O-2) Created SaslServer [org.wildfly.security.sasl.util.SecurityIdentitySaslServerFactory$1 at 2a8e9ff7->org.wildfly.security.sasl.util.AuthenticationTimeoutSaslServerFactory$DelegatingTimeoutSaslServer at 493accbb->org.wildfly.security.sasl.util.AuthenticationCompleteCallbackSaslServerFactory$1 at 6a9c91e2->org.wildfly.security.sasl.anonymous.AnonymousSaslServer at 2b612585] for mechanism [ANONYMOUS]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 11:31:00 2018
From: issues at jboss.org (Chad Poe (JIRA))
Date: Thu, 25 Jan 2018 11:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2275) Null pointer exception when
 calling updateToVersion with data in a stateful KieSession
In-Reply-To: <JIRA.12730836.1516897823000@Atlassian.JIRA>
References: <JIRA.12730836.1516897823000@Atlassian.JIRA>
	<JIRA.12730836.1516897823120@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730836.1516897823000.99866.1516897860490@Atlassian.JIRA>

Chad Poe created DROOLS-2275:
--------------------------------

             Summary: Null pointer exception when calling updateToVersion with data in a stateful KieSession
                 Key: DROOLS-2275
                 URL: https://issues.jboss.org/browse/DROOLS-2275
             Project: Drools
          Issue Type: Bug
         Environment: Wildfly 8.2.1, Standalone
            Reporter: Chad Poe
            Assignee: Edson Tirelli
         Attachments: org.drools.test.beta-memory.zip

This error was first discovered in a proprietary application that is running in wildfly 8.2.1. Up until now I was unable to reproduce outside of the mentioned environment. After narrowing down the exact conditions that cause the error to occur I was able to create a sample project that forces the issue to occur. Below is the stack trace:

Caused by: java.lang.NullPointerException
        at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:93)
        at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:88)
        at org.drools.core.reteoo.SingleObjectSinkAdapter.staticDoLinkRiaNode(SingleObjectSinkAdapter.java:111)
        at org.drools.core.reteoo.SingleObjectSinkAdapter.doLinkRiaNode(SingleObjectSinkAdapter.java:93)
        at org.drools.core.reteoo.RiaPathMemory.doLinkRule(RiaPathMemory.java:52)
        at org.drools.core.reteoo.PathMemory.linkSegment(PathMemory.java:103)
        at org.drools.core.reteoo.SegmentMemory.notifyRuleLinkSegment(SegmentMemory.java:192)
        at org.drools.core.phreak.AddRemoveRule.addNewPaths(AddRemoveRule.java:452)
        at org.drools.core.phreak.AddRemoveRule.addRule(AddRemoveRule.java:123)
        at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:189)
        at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
        at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
        at org.drools.core.impl.KnowledgeBaseImpl.internalAddRule(KnowledgeBaseImpl.java:1530)
        at org.drools.core.impl.KnowledgeBaseImpl.lambda$addRules$4(KnowledgeBaseImpl.java:1523)
        at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
        at org.drools.core.impl.KnowledgeBaseImpl.addRules(KnowledgeBaseImpl.java:1521)
        at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRete(KnowledgeBuilderImpl.java:1010)
        at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRules(KnowledgeBuilderImpl.java:2524)
        at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2450)
        at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:109)
        at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:99)
        at org.drools.compiler.kie.builder.impl.KieContainerImpl.rebuildAll(KieContainerImpl.java:473)
        at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateKBase(KieContainerImpl.java:309)
        at org.drools.compiler.kie.builder.impl.KieContainerImpl.lambda$update$0(KieContainerImpl.java:260)
        at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
        at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:260)
        at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:199)
        at org.drools.test.KieRuntimeManager.buildOnKfs(KieRuntimeManager.java:202)
        at org.drools.test.KieRuntimeManager.loadRule(KieRuntimeManager.java:147)
        at org.drools.test.DroolsReasonerContainer.loadRule(DroolsReasonerContainer.java:22)
        at org.drools.test.App.main(App.java:22)
        ... 6 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 11:39:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 11:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1426) DigestSasl obtains URP digest
 for authzid instead of username
In-Reply-To: <JIRA.12718364.1509035569000@Atlassian.JIRA>
References: <JIRA.12718364.1509035569000@Atlassian.JIRA>
	<JIRA.12718364.1509035569000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718364.1509035569000.99901.1516898340121@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1426:
----------------------------
    Fix Version/s: 1.2.0.Beta11


> DigestSasl obtains URP digest for authzid instead of username
> -------------------------------------------------------------
>
>                 Key: ELY-1426
>                 URL: https://issues.jboss.org/browse/ELY-1426
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: SASL
>    Affects Versions: 1.2.0.Beta8
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta11
>
>
> In following patch was introduced bug:
> https://github.com/wildfly-security/wildfly-elytron/pull/851/files#diff-dc83c9f75c0f78bbdfd49f49d56514faR332
> DigestSaslClient requests URP digest for default userName (authzid), not for authentication name (from NameCallback).
> Code is ok for server side, but not for client side, where credential callback params should require name obtained by NameCallback.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 11:41:00 2018
From: issues at jboss.org (Chad Poe (JIRA))
Date: Thu, 25 Jan 2018 11:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2275) Null pointer exception when
 calling updateToVersion with existing data in a stateful KieSession
In-Reply-To: <JIRA.12730836.1516897823000@Atlassian.JIRA>
References: <JIRA.12730836.1516897823000@Atlassian.JIRA>
	<JIRA.12730836.1516897823000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730836.1516897823000.99926.1516898460945@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chad Poe updated DROOLS-2275:
-----------------------------
    Summary: Null pointer exception when calling updateToVersion with existing data in a stateful KieSession  (was: Null pointer exception when calling updateToVersion with data in a stateful KieSession)


> Null pointer exception when calling updateToVersion with existing data in a stateful KieSession
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2275
>                 URL: https://issues.jboss.org/browse/DROOLS-2275
>             Project: Drools
>          Issue Type: Bug
>         Environment: Wildfly 8.2.1, Standalone
>            Reporter: Chad Poe
>            Assignee: Edson Tirelli
>         Attachments: org.drools.test.beta-memory.zip
>
>
> This error was first discovered in a proprietary application that is running in wildfly 8.2.1. Up until now I was unable to reproduce outside of the mentioned environment. After narrowing down the exact conditions that cause the error to occur I was able to create a sample project that forces the issue to occur. Below is the stack trace:
> Caused by: java.lang.NullPointerException
>         at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:93)
>         at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:88)
>         at org.drools.core.reteoo.SingleObjectSinkAdapter.staticDoLinkRiaNode(SingleObjectSinkAdapter.java:111)
>         at org.drools.core.reteoo.SingleObjectSinkAdapter.doLinkRiaNode(SingleObjectSinkAdapter.java:93)
>         at org.drools.core.reteoo.RiaPathMemory.doLinkRule(RiaPathMemory.java:52)
>         at org.drools.core.reteoo.PathMemory.linkSegment(PathMemory.java:103)
>         at org.drools.core.reteoo.SegmentMemory.notifyRuleLinkSegment(SegmentMemory.java:192)
>         at org.drools.core.phreak.AddRemoveRule.addNewPaths(AddRemoveRule.java:452)
>         at org.drools.core.phreak.AddRemoveRule.addRule(AddRemoveRule.java:123)
>         at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:189)
>         at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
>         at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
>         at org.drools.core.impl.KnowledgeBaseImpl.internalAddRule(KnowledgeBaseImpl.java:1530)
>         at org.drools.core.impl.KnowledgeBaseImpl.lambda$addRules$4(KnowledgeBaseImpl.java:1523)
>         at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
>         at org.drools.core.impl.KnowledgeBaseImpl.addRules(KnowledgeBaseImpl.java:1521)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRete(KnowledgeBuilderImpl.java:1010)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRules(KnowledgeBuilderImpl.java:2524)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2450)
>         at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:109)
>         at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:99)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.rebuildAll(KieContainerImpl.java:473)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateKBase(KieContainerImpl.java:309)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.lambda$update$0(KieContainerImpl.java:260)
>         at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:260)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:199)
>         at org.drools.test.KieRuntimeManager.buildOnKfs(KieRuntimeManager.java:202)
>         at org.drools.test.KieRuntimeManager.loadRule(KieRuntimeManager.java:147)
>         at org.drools.test.DroolsReasonerContainer.loadRule(DroolsReasonerContainer.java:22)
>         at org.drools.test.App.main(App.java:22)
>         ... 6 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 11:55:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Thu, 25 Jan 2018 11:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (LOGTOOL-132) Support low-metaspace
	bundles/classes
In-Reply-To: <JIRA.12725669.1513707798000@Atlassian.JIRA>
References: <JIRA.12725669.1513707798000@Atlassian.JIRA>
	<JIRA.12725669.1513707798000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725669.1513707798000.100038.1516899300166@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/LOGTOOL-132?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524017#comment-13524017 ] 

James Perkins commented on LOGTOOL-132:
---------------------------------------

I think I'm just going break compatibility and remove the previous properties which allowed the generated implementation to work with 3.0.x. For compiling I'll throw an exception if the correct minimum version of {{jboss-logging}} isn't used. I think it will just make it easier. Keeping the compatibility is likely just going to complicated the generated code and we should really leave it very simple as the goal is shrinking the metaspace size.

I seem to have this working well locally. There are few main issues left:
# There was a way for a default locale, LOGTOOL-116, to be set. Given the same implementation is used for all languages we need to away to determine which locale should be used for translated messages vs fallback messages.
# We need to figure out how we fallback from {{fr_CA}} to {{fr}} if both properties files exist
# Performance testing needs to be done.

One kind of interesting thing, and something I'll look at in more depth, is while the implementations seem to be down about 50% in metaspace size the total only seems down about 1%. 

> Support low-metaspace bundles/classes
> -------------------------------------
>
>                 Key: LOGTOOL-132
>                 URL: https://issues.jboss.org/browse/LOGTOOL-132
>             Project: Log Tool
>          Issue Type: Enhancement
>            Reporter: David Lloyd
>            Priority: Critical
>
> Metaspace is at a premium in the application server environment, and the number one consumer is presently generated log classes.
> Introduce a leaner variation on generated classes with the following requirements:
> * The generated class must be {{final}}
> * The generated class must contain no message strings
> * The generated class must accept both a {{Logger}} and a {{Locale}}, and load its resources from a file based on that information
> * The usage of Java 8's locale lookup functionality should be considered, to support language tags etc.; a helper utility could be introduced into {{jboss-logging}} for this
> Here are some implementation ideas:
> * Option 1: The resource files contain only messages, one per line, loaded directly into a {{String[]}} instance field in the implementation class; each logging method uses a hard-coded array index to access its message
> ** A key advantage is that the implementation class is very small, and consumes very little metaspace; also, it is fast, requiring only an array lookup to acquire the string
> ** A disadvantage is, any change to the message set invalidates all the locale files, which must then be regenerated
> ** Also, each locale file must contain all messages, unless a fallback mechanism is used (e.g. an empty line signifies that the string should come from the parent locale)
> * Option 2: The resource files contain key-value pairs, with the key being equal to the method name
> ** Advantage: the file is not invalidated if a key is added, and sub-locales can inherit more easily from parent locales
> ** Disadvantage: the added overhead of mapping lines to methods (for example, using a switch statement to map method names to fixed indexes, or loading the messages into a hash table e.g. {{HashMap}}) will fill metaspace or impact performance, or both



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 12:03:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 12:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1387) SSLContext for where
 authentication client resources load from a URI.
In-Reply-To: <JIRA.12714965.1507288521000@Atlassian.JIRA>
References: <JIRA.12714965.1507288521000@Atlassian.JIRA>
	<JIRA.12714965.1507288521000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12714965.1507288521000.100073.1516899780181@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1387:
----------------------------
    Component/s: Authentication Client


> SSLContext for where authentication client resources load from a URI.
> ---------------------------------------------------------------------
>
>                 Key: ELY-1387
>                 URL: https://issues.jboss.org/browse/ELY-1387
>             Project: WildFly Elytron
>          Issue Type: Enhancement
>          Components: Authentication Client
>            Reporter: Darran Lofthouse
>             Fix For: 2.0.0.Alpha1
>
>
> Where resources can be loaded from a URI we may want to define an SSLContext for access to that resource so we can verify it is a trusted resource.
> i.e. our local config contains internal key and trust stores but the remove destinations may change so we load the certificates and revocation lists from an internal trusted source.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 12:09:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 12:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-262) The equivalent of wrap and
 unwrap for HTTP authentication mechanisms
In-Reply-To: <JIRA.12580681.1438967809000@Atlassian.JIRA>
References: <JIRA.12580681.1438967809000@Atlassian.JIRA>
	<JIRA.12580681.1438967809000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580681.1438967809000.100085.1516900140182@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-262:
---------------------------
    Description: For example, for DIGEST is in RFC 7616 defined integrity protection - qop=auth-int.


> The equivalent of wrap and unwrap for HTTP authentication mechanisms
> --------------------------------------------------------------------
>
>                 Key: ELY-262
>                 URL: https://issues.jboss.org/browse/ELY-262
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: HTTP
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta14
>
>
> For example, for DIGEST is in RFC 7616 defined integrity protection - qop=auth-int.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 12:13:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 12:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-16) Add a RFC2256 based LDAP Realm
In-Reply-To: <JIRA.12544790.1403705518000@Atlassian.JIRA>
References: <JIRA.12544790.1403705518000@Atlassian.JIRA>
	<JIRA.12544790.1403705518000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12544790.1403705518000.100099.1516900380212@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-16?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina resolved ELY-16.
---------------------------
    Fix Version/s: 1.0.0.Alpha1
                       (was: 2.0.0.Alpha1)
       Resolution: Done


> Add a RFC2256 based LDAP Realm
> ------------------------------
>
>                 Key: ELY-16
>                 URL: https://issues.jboss.org/browse/ELY-16
>             Project: WildFly Elytron
>          Issue Type: Sub-task
>            Reporter: Darran Lofthouse
>             Fix For: 1.0.0.Alpha1
>
>
> RFC2256 defines the userPassword attribute on LDAP entries, officially this is supposed to be clear text - however many vendors now support a one way hash where the hash algorithm is specified at the beginning of the attribute value: -
> {noformat}
>     {ssha}izu672WN0xA2ZaYofeiWyQ5QKxEBMNsbyQKwRw==
> {noformat}
> {noformat}
> ( 2.5.4.35 NAME 'userPassword' DESC 'RFC2256/2307: password of user' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 USAGE userApplications X-SCHEMA 'system' )
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 12:17:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 12:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-23) authPassword LDAP attribute -
 add support for RFC5803
In-Reply-To: <JIRA.12546343.1405336653000@Atlassian.JIRA>
References: <JIRA.12546343.1405336653000@Atlassian.JIRA>
	<JIRA.12546343.1405336653000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546343.1405336653000.100112.1516900620292@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-23:
--------------------------
    Summary: authPassword LDAP attribute - add support for RFC5803  (was: Add support for RFC5803)


> authPassword LDAP attribute - add support for RFC5803
> -----------------------------------------------------
>
>                 Key: ELY-23
>                 URL: https://issues.jboss.org/browse/ELY-23
>             Project: WildFly Elytron
>          Issue Type: Sub-task
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta14
>
>
> RFC5803 adds support for storing SCRAM secrets in the 'authPassword' attribute introduced by RFC3112



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 12:17:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 12:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-22) Expand LDAP realm to support
 authPassword attribute (RFC3112)
In-Reply-To: <JIRA.12546341.1405336537000@Atlassian.JIRA>
References: <JIRA.12546341.1405336537000@Atlassian.JIRA>
	<JIRA.12546341.1405336537000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12546341.1405336537000.100119.1516900620969@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-22?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-22:
--------------------------
    Summary: Expand LDAP realm to support authPassword attribute (RFC3112)  (was: Expand LDAP realm to support RFC3112)


> Expand LDAP realm to support authPassword attribute (RFC3112)
> -------------------------------------------------------------
>
>                 Key: ELY-22
>                 URL: https://issues.jboss.org/browse/ELY-22
>             Project: WildFly Elytron
>          Issue Type: Sub-task
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta14
>
>
> RFC3112 adds a new attribute 'authPassword' and can be used to store passwords in various formats. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 12:22:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 12:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-61) Ensure the requirements and
 options for each mechanism are described within the mechanism.
In-Reply-To: <JIRA.12542823.1401900467000@Atlassian.JIRA>
References: <JIRA.12542823.1401900467000@Atlassian.JIRA>
	<JIRA.12542823.1401900467000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542823.1401900467000.100143.1516900920541@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-61?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-61:
--------------------------
    Component/s: Authentication Mechanisms


> Ensure the requirements and options for each mechanism are described within the mechanism.
> ------------------------------------------------------------------------------------------
>
>                 Key: ELY-61
>                 URL: https://issues.jboss.org/browse/ELY-61
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Mechanisms
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta14
>
>
> Everything from callback requirements, supported config options to System properties. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 12:24:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 12:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-61) Ensure the requirements and
 options for each mechanism are described within the mechanism.
In-Reply-To: <JIRA.12542823.1401900467000@Atlassian.JIRA>
References: <JIRA.12542823.1401900467000@Atlassian.JIRA>
	<JIRA.12542823.1401900467000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12542823.1401900467000.100158.1516901040163@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-61?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524029#comment-13524029 ] 

Jan Kalina commented on ELY-61:
-------------------------------

Where it should be described? In javadoc of mechanism classes? Or is some documentation page?

> Ensure the requirements and options for each mechanism are described within the mechanism.
> ------------------------------------------------------------------------------------------
>
>                 Key: ELY-61
>                 URL: https://issues.jboss.org/browse/ELY-61
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Authentication Mechanisms
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta14
>
>
> Everything from callback requirements, supported config options to System properties. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 12:30:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 12:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-63) Pluggable nonce handling strategy
In-Reply-To: <JIRA.12446879.1315944468000@Atlassian.JIRA>
References: <JIRA.12446879.1315944468000@Atlassian.JIRA>
	<JIRA.12446879.1315944468000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446879.1315944468000.100191.1516901400197@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524034#comment-13524034 ] 

Jan Kalina commented on ELY-63:
-------------------------------

NonceManager currently use SecureRandom (hardcoded) - does this mean there should be plugable privateKey generator for NonceManager? Or bigger part of NonceManager should be replacable?

> Pluggable nonce handling strategy
> ---------------------------------
>
>                 Key: ELY-63
>                 URL: https://issues.jboss.org/browse/ELY-63
>             Project: WildFly Elytron
>          Issue Type: Task
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta14
>
>
> Implement a pluggable nonce handling strategy.
> At the very least we need to be able to switch to using a SecureRandom instead of Random.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 12:39:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 12:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1295) KeyStoreCredentialStoreTest
 fails on IBM JDK
In-Reply-To: <JIRA.12702872.1500553419000@Atlassian.JIRA>
References: <JIRA.12702872.1500553419000@Atlassian.JIRA>
	<JIRA.12702872.1500553419000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12702872.1500553419000.100232.1516901940412@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524038#comment-13524038 ] 

Jan Kalina commented on ELY-1295:
---------------------------------

[~rhn-support-pnag], if you are going to document impossibility to use PKCS12 as credential store on IBM, maybe will be ELY-1427 better issue to reference. (This issue is more focused on the test of it.)

> KeyStoreCredentialStoreTest fails on IBM JDK
> --------------------------------------------
>
>                 Key: ELY-1295
>                 URL: https://issues.jboss.org/browse/ELY-1295
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Credential Store
>            Reporter: Peter Palaga
>            Assignee: Priyanka Nag
>            Priority: Critical
>              Labels: ibm-java
>             Fix For: 1.2.0.Beta12
>
>
> {code}
> export JAVA_HOME=path/to/ibm/java8
>  
> $JAVA_HOME/bin/java -version
> java version "1.8.0"
> Java(TM) SE Runtime Environment (build pxa6480sr3fp12-20160919_01(SR3 FP12))
> IBM J9 VM (build 2.8, JRE 1.8.0 Linux amd64-64 Compressed References 20160915_318796 (JIT enabled, AOT enabled)
> J9VM - R28_Java8_SR3_20160915_0912_B318796
> JIT  - tr.r14.java.green_20160818_122998
> GC   - R28_Java8_SR3_20160915_0912_B318796_CMPRSS
> J9CL - 20160915_318796)
> JCL - 20160914_01 based on Oracle jdk8u101-b13
>  
> mvn clean test -Dtest=KeyStoreCredentialStoreTest
> {code}
> Expected: KeyStoreCredentialStoreTest should pass
> Actual: First, the "hack to make JCE believe that it has verified the signature of the WildFlyElytronProvider JAR" [1] throws
> {code}
> java.lang.ClassNotFoundException: javax.crypto.JceSecurity
> 	at java.lang.Class.forNameImpl(Native Method)
> 	at java.lang.Class.forName(Class.java:278)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.installWildFlyElytronProvider(KeyStoreCredentialStoreTest.java:89)
> ...
> {code}
> because {{javax.crypto.JceSecurity}} does not exist in IBM JRE.
> It looks like the hack is actually not necessary anymore, because {{KeyStoreCredentialStoreTest}} is passing also without the hack on both Oracle JDK and OpenJDK.
> But once the hack is removed, on IBM JDK, {{shouldSupportKeyStoreFormat}} passes with format=JCEKS but fails with format=PKCS12 throwing the following exeception:
> {code}
> org.wildfly.security.credential.store.CredentialStoreException: ELY09504: Cannot acquire a credential from the credential store
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:464)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStoreTest.shouldSupportKeyStoreFormat(KeyStoreCredentialStoreTest.java:137)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at java.lang.reflect.Method.invoke(Method.java:508)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
> Caused by: java.security.UnrecoverableKeyException: Get Key failed: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	at java.security.KeyStore.getEntry(KeyStore.java:1532)
> 	at org.wildfly.security.credential.store.impl.KeyStoreCredentialStore.retrieve(KeyStoreCredentialStore.java:462)
> 	... 10 more
> Caused by: java.security.NoSuchAlgorithmException: 1.2.840.113549.1.7.1 SecretKeyFactory not available
> 	... 12 more
> {code}
> [1] https://github.com/wildfly-security/wildfly-elytron/pull/661/commits/72967600a98dee832e151ff8f6fb64af0a84bd14#diff-faa6b27609575ef29472bcc75c87eb36R87



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 12:54:01 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Thu, 25 Jan 2018 12:54:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-63) Pluggable nonce handling strategy
In-Reply-To: <JIRA.12446879.1315944468000@Atlassian.JIRA>
References: <JIRA.12446879.1315944468000@Atlassian.JIRA>
	<JIRA.12446879.1315944468000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12446879.1315944468000.100334.1516902841002@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-63?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524058#comment-13524058 ] 

Darran Lofthouse commented on ELY-63:
-------------------------------------

I need to dig out some notes but we also had some ideas to optimise how nonce counts are monitored within the NonceManager to optimise them and minimise the re-issuing of nonces but that may be another issue.  This was more about adding custom impls but maybe we should get our impl sorted first.

> Pluggable nonce handling strategy
> ---------------------------------
>
>                 Key: ELY-63
>                 URL: https://issues.jboss.org/browse/ELY-63
>             Project: WildFly Elytron
>          Issue Type: Task
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta14
>
>
> Implement a pluggable nonce handling strategy.
> At the very least we need to be able to switch to using a SecureRandom instead of Random.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 13:08:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 25 Jan 2018 13:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3550) Inefficient algorithm for
 converting JMX attribute names to native resource attribute names
In-Reply-To: <JIRA.12730847.1516903651000@Atlassian.JIRA>
References: <JIRA.12730847.1516903651000@Atlassian.JIRA>
	<JIRA.12730847.1516903651589@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730847.1516903651000.100358.1516903680073@Atlassian.JIRA>

Brian Stansberry created WFCORE-3550:
----------------------------------------

             Summary: Inefficient algorithm for converting JMX attribute names to native resource attribute names
                 Key: WFCORE-3550
                 URL: https://issues.jboss.org/browse/WFCORE-3550
             Project: WildFly Core
          Issue Type: Bug
          Components: JMX
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


ModelControllerMBeanHelper is taking an MRR, using it to create a DMR ModelNode description of the resource type, and then iterating over the attribute names in that description tree to try and match up with the requested JMX attribute name. That middle step of creating the DMR description is very expensive; it produces a very large node tree. It's not necessary; the MRR already can tell you the legal attribute names.

I believe this is legacy cruft from the early AS 7 days when the MRR wasn't always reliable for all attribute names. But it's been reliable for a long time now.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 13:31:00 2018
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Thu, 25 Jan 2018 13:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9647) allow property name to be
 specified in PersistenceUnit/PersistenceContext unitName
In-Reply-To: <JIRA.12726233.1514904961000@Atlassian.JIRA>
References: <JIRA.12726233.1514904961000@Atlassian.JIRA>
	<JIRA.12726233.1514904961000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726233.1514904961000.100395.1516905060115@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9647?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Scott Marlow closed WFLY-9647.
------------------------------


> allow property name to be specified in PersistenceUnit/PersistenceContext unitName
> ----------------------------------------------------------------------------------
>
>                 Key: WFLY-9647
>                 URL: https://issues.jboss.org/browse/WFLY-9647
>             Project: WildFly
>          Issue Type: Task
>          Components: JPA / Hibernate
>            Reporter: Scott Marlow
>            Assignee: Scott Marlow
>             Fix For: 12.0.0.Alpha1
>
>
> Add extension that allows system property substitution of unitName:
> {code}
> @PersistenceContext(unitName = ?${test.case.persistence.context}")
>  private EntityManager entityManager;
> @PersistenceUnit(unitName = ?${test.case.persistence.context}")
>  private EntityManagerFactory entityManagerFactory;
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Thu Jan 25 13:51:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 25 Jan 2018 13:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2275) Null pointer exception when
 calling updateToVersion with existing data in a stateful KieSession
In-Reply-To: <JIRA.12730836.1516897823000@Atlassian.JIRA>
References: <JIRA.12730836.1516897823000@Atlassian.JIRA>
	<JIRA.12730836.1516897823000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730836.1516897823000.100462.1516906260710@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned DROOLS-2275:
-------------------------------------

    Assignee: Mario Fusco  (was: Edson Tirelli)


> Null pointer exception when calling updateToVersion with existing data in a stateful KieSession
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2275
>                 URL: https://issues.jboss.org/browse/DROOLS-2275
>             Project: Drools
>          Issue Type: Bug
>         Environment: Wildfly 8.2.1, Standalone
>            Reporter: Chad Poe
>            Assignee: Mario Fusco
>         Attachments: org.drools.test.beta-memory.zip
>
>
> This error was first discovered in a proprietary application that is running in wildfly 8.2.1. Up until now I was unable to reproduce outside of the mentioned environment. After narrowing down the exact conditions that cause the error to occur I was able to create a sample project that forces the issue to occur. Below is the stack trace:
> Caused by: java.lang.NullPointerException
>         at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:93)
>         at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:88)
>         at org.drools.core.reteoo.SingleObjectSinkAdapter.staticDoLinkRiaNode(SingleObjectSinkAdapter.java:111)
>         at org.drools.core.reteoo.SingleObjectSinkAdapter.doLinkRiaNode(SingleObjectSinkAdapter.java:93)
>         at org.drools.core.reteoo.RiaPathMemory.doLinkRule(RiaPathMemory.java:52)
>         at org.drools.core.reteoo.PathMemory.linkSegment(PathMemory.java:103)
>         at org.drools.core.reteoo.SegmentMemory.notifyRuleLinkSegment(SegmentMemory.java:192)
>         at org.drools.core.phreak.AddRemoveRule.addNewPaths(AddRemoveRule.java:452)
>         at org.drools.core.phreak.AddRemoveRule.addRule(AddRemoveRule.java:123)
>         at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:189)
>         at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
>         at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
>         at org.drools.core.impl.KnowledgeBaseImpl.internalAddRule(KnowledgeBaseImpl.java:1530)
>         at org.drools.core.impl.KnowledgeBaseImpl.lambda$addRules$4(KnowledgeBaseImpl.java:1523)
>         at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
>         at org.drools.core.impl.KnowledgeBaseImpl.addRules(KnowledgeBaseImpl.java:1521)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRete(KnowledgeBuilderImpl.java:1010)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRules(KnowledgeBuilderImpl.java:2524)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2450)
>         at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:109)
>         at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:99)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.rebuildAll(KieContainerImpl.java:473)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateKBase(KieContainerImpl.java:309)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.lambda$update$0(KieContainerImpl.java:260)
>         at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:260)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:199)
>         at org.drools.test.KieRuntimeManager.buildOnKfs(KieRuntimeManager.java:202)
>         at org.drools.test.KieRuntimeManager.loadRule(KieRuntimeManager.java:147)
>         at org.drools.test.DroolsReasonerContainer.loadRule(DroolsReasonerContainer.java:22)
>         at org.drools.test.App.main(App.java:22)
>         ... 6 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 13:51:01 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Thu, 25 Jan 2018 13:51:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2275) Null pointer exception when
 calling updateToVersion with existing data in a stateful KieSession
In-Reply-To: <JIRA.12730836.1516897823000@Atlassian.JIRA>
References: <JIRA.12730836.1516897823000@Atlassian.JIRA>
	<JIRA.12730836.1516897823000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730836.1516897823000.100476.1516906261219@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2275?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524068#comment-13524068 ] 

Edson Tirelli commented on DROOLS-2275:
---------------------------------------

[~mfusco] isn't this the same you fixed a few weeks ago?

> Null pointer exception when calling updateToVersion with existing data in a stateful KieSession
> -----------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2275
>                 URL: https://issues.jboss.org/browse/DROOLS-2275
>             Project: Drools
>          Issue Type: Bug
>         Environment: Wildfly 8.2.1, Standalone
>            Reporter: Chad Poe
>            Assignee: Mario Fusco
>         Attachments: org.drools.test.beta-memory.zip
>
>
> This error was first discovered in a proprietary application that is running in wildfly 8.2.1. Up until now I was unable to reproduce outside of the mentioned environment. After narrowing down the exact conditions that cause the error to occur I was able to create a sample project that forces the issue to occur. Below is the stack trace:
> Caused by: java.lang.NullPointerException
>         at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:93)
>         at org.drools.core.reteoo.BetaMemory.linkNode(BetaMemory.java:88)
>         at org.drools.core.reteoo.SingleObjectSinkAdapter.staticDoLinkRiaNode(SingleObjectSinkAdapter.java:111)
>         at org.drools.core.reteoo.SingleObjectSinkAdapter.doLinkRiaNode(SingleObjectSinkAdapter.java:93)
>         at org.drools.core.reteoo.RiaPathMemory.doLinkRule(RiaPathMemory.java:52)
>         at org.drools.core.reteoo.PathMemory.linkSegment(PathMemory.java:103)
>         at org.drools.core.reteoo.SegmentMemory.notifyRuleLinkSegment(SegmentMemory.java:192)
>         at org.drools.core.phreak.AddRemoveRule.addNewPaths(AddRemoveRule.java:452)
>         at org.drools.core.phreak.AddRemoveRule.addRule(AddRemoveRule.java:123)
>         at org.drools.core.reteoo.builder.ReteooRuleBuilder.addSubRule(ReteooRuleBuilder.java:189)
>         at org.drools.core.reteoo.builder.ReteooRuleBuilder.addRule(ReteooRuleBuilder.java:133)
>         at org.drools.core.reteoo.ReteooBuilder.addRule(ReteooBuilder.java:110)
>         at org.drools.core.impl.KnowledgeBaseImpl.internalAddRule(KnowledgeBaseImpl.java:1530)
>         at org.drools.core.impl.KnowledgeBaseImpl.lambda$addRules$4(KnowledgeBaseImpl.java:1523)
>         at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
>         at org.drools.core.impl.KnowledgeBaseImpl.addRules(KnowledgeBaseImpl.java:1521)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.compileRete(KnowledgeBuilderImpl.java:1010)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildRules(KnowledgeBuilderImpl.java:2524)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.buildPackages(KnowledgeBuilderImpl.java:2450)
>         at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.buildPackages(CompositeKnowledgeBuilderImpl.java:109)
>         at org.drools.compiler.builder.impl.CompositeKnowledgeBuilderImpl.build(CompositeKnowledgeBuilderImpl.java:99)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.rebuildAll(KieContainerImpl.java:473)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateKBase(KieContainerImpl.java:309)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.lambda$update$0(KieContainerImpl.java:260)
>         at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:260)
>         at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:199)
>         at org.drools.test.KieRuntimeManager.buildOnKfs(KieRuntimeManager.java:202)
>         at org.drools.test.KieRuntimeManager.loadRule(KieRuntimeManager.java:147)
>         at org.drools.test.DroolsReasonerContainer.loadRule(DroolsReasonerContainer.java:22)
>         at org.drools.test.App.main(App.java:22)
>         ... 6 more



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 14:28:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 25 Jan 2018 14:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3551) Reduce and try to eliminate
 need to read the attribute DMR description in ModelControllerMBeanHelper
In-Reply-To: <JIRA.12730852.1516908462000@Atlassian.JIRA>
References: <JIRA.12730852.1516908462000@Atlassian.JIRA>
	<JIRA.12730852.1516908462323@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730852.1516908462000.100763.1516908480102@Atlassian.JIRA>

Brian Stansberry created WFCORE-3551:
----------------------------------------

             Summary: Reduce and try to eliminate need to read the attribute DMR description in ModelControllerMBeanHelper
                 Key: WFCORE-3551
                 URL: https://issues.jboss.org/browse/WFCORE-3551
             Project: WildFly Core
          Issue Type: Enhancement
          Components: JMX
            Reporter: Brian Stansberry
            Assignee: Kabir Khan


The TypeConverter stuff used by ModelControllerMBeanHelper relies on the full DMR description for an attribute in order to do the conversion. But getting that description is expensive relative to the amount of data that is extracted from it. Task is to figure out a lower overhead way, at least for non-OBJECT/LIST/PROPERTY attributes where all that's needed is AttributeDefinition.getType(). It's more complex for non-simple attributes, but those are less common.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 15:37:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 15:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-54) Support for stronger hashes as
 alternatives to MD5
In-Reply-To: <JIRA.12479914.1354008365000@Atlassian.JIRA>
References: <JIRA.12479914.1354008365000@Atlassian.JIRA>
	<JIRA.12479914.1354008365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479914.1354008365000.101067.1516912620228@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-54?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524103#comment-13524103 ] 

Jan Kalina commented on ELY-54:
-------------------------------

This was completed for HTTP too already - as part of ELY-1369.

> Support for stronger hashes as alternatives to MD5
> --------------------------------------------------
>
>                 Key: ELY-54
>                 URL: https://issues.jboss.org/browse/ELY-54
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta14
>
>
> Presently Digest authentication is based on MD5 - however we should either update the mechanism or add new mechanisms to support the use of stronger hashes.
> As this library is used both client and server side installations that require the stronger hashes can just ensure the client and server have the latest version of this library - installations that still require interaction with MD5 will need to ensure that it is still available as a mechanism.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 15:38:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 15:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-54) Support for stronger hashes as
 alternatives to MD5
In-Reply-To: <JIRA.12479914.1354008365000@Atlassian.JIRA>
References: <JIRA.12479914.1354008365000@Atlassian.JIRA>
	<JIRA.12479914.1354008365000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12479914.1354008365000.101072.1516912680269@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-54?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina resolved ELY-54.
---------------------------
    Fix Version/s: 1.2.0.Beta11
                       (was: 1.2.0.Beta14)
       Resolution: Done


> Support for stronger hashes as alternatives to MD5
> --------------------------------------------------
>
>                 Key: ELY-54
>                 URL: https://issues.jboss.org/browse/ELY-54
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta11
>
>
> Presently Digest authentication is based on MD5 - however we should either update the mechanism or add new mechanisms to support the use of stronger hashes.
> As this library is used both client and server side installations that require the stronger hashes can just ensure the client and server have the latest version of this library - installations that still require interaction with MD5 will need to ensure that it is still available as a mechanism.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 15:53:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 25 Jan 2018 15:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3550) Inefficient algorithm for
 converting JMX attribute names to native resource attribute names
In-Reply-To: <JIRA.12730847.1516903652000@Atlassian.JIRA>
References: <JIRA.12730847.1516903652000@Atlassian.JIRA>
	<JIRA.12730847.1516903652000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730847.1516903652000.101148.1516913580108@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3550?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524109#comment-13524109 ] 

Brian Stansberry commented on WFCORE-3550:
------------------------------------------

Note: looking more closely revealed that the DMR description was additionally used later. But the way the necessary description is obtained can be more efficient, which the PR for this does. WFCORE-3551 is about finding a way to further reduce or maybe eliminate the need for DMR descriptions.

> Inefficient algorithm for converting JMX attribute names to native resource attribute names
> -------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3550
>                 URL: https://issues.jboss.org/browse/WFCORE-3550
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: JMX
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> ModelControllerMBeanHelper is taking an MRR, using it to create a DMR ModelNode description of the resource type, and then iterating over the attribute names in that description tree to try and match up with the requested JMX attribute name. That middle step of creating the DMR description is very expensive; it produces a very large node tree. It's not necessary; the MRR already can tell you the legal attribute names.
> I believe this is legacy cruft from the early AS 7 days when the MRR wasn't always reliable for all attribute names. But it's been reliable for a long time now.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 16:03:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 16:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-170) Transition the still useful
 parts of JBoss Negotiation into Elytron
In-Reply-To: <JIRA.12567097.1427457395000@Atlassian.JIRA>
References: <JIRA.12567097.1427457395000@Atlassian.JIRA>
	<JIRA.12567097.1427457395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567097.1427457395000.101236.1516914180793@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524114#comment-13524114 ] 

Jan Kalina commented on ELY-170:
--------------------------------

SPNEGO in elytron is already complete - will close as out-of-date.

> Transition the still useful parts of JBoss Negotiation into Elytron
> -------------------------------------------------------------------
>
>                 Key: ELY-170
>                 URL: https://issues.jboss.org/browse/ELY-170
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Utils
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta12
>
>
> Generally JBoss Negotiation should be obsolete, however some portions may be useful to be included in Elytron e.g. the SPNEGO parsing so that we can display some meaningful diagnostics.
> By the time we reach the end of WildFly 10 nothing should require a direct dependency on JBoss Negotiation and really it should be removed from the application server distribution.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 16:03:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 16:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-170) Transition the still useful
 parts of JBoss Negotiation into Elytron
In-Reply-To: <JIRA.12567097.1427457395000@Atlassian.JIRA>
References: <JIRA.12567097.1427457395000@Atlassian.JIRA>
	<JIRA.12567097.1427457395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567097.1427457395000.101239.1516914180894@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed ELY-170.
--------------------------
    Fix Version/s: 1.2.0.Beta12
                       (was: 1.2.0.Beta14)
       Resolution: Out of Date


> Transition the still useful parts of JBoss Negotiation into Elytron
> -------------------------------------------------------------------
>
>                 Key: ELY-170
>                 URL: https://issues.jboss.org/browse/ELY-170
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Utils
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta12
>
>
> Generally JBoss Negotiation should be obsolete, however some portions may be useful to be included in Elytron e.g. the SPNEGO parsing so that we can display some meaningful diagnostics.
> By the time we reach the end of WildFly 10 nothing should require a direct dependency on JBoss Negotiation and really it should be removed from the application server distribution.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 16:16:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 16:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-261) Rework (and move)
	UsernamePasswordHashUtil
In-Reply-To: <JIRA.12580680.1438967730000@Atlassian.JIRA>
References: <JIRA.12580680.1438967730000@Atlassian.JIRA>
	<JIRA.12580680.1438967730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580680.1438967730000.101282.1516914960454@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524117#comment-13524117 ] 

Jan Kalina commented on ELY-261:
--------------------------------

Currently is the class already part of the public API so cannot be removed - will be deprecated.

> Rework (and move) UsernamePasswordHashUtil
> ------------------------------------------
>
>                 Key: ELY-261
>                 URL: https://issues.jboss.org/browse/ELY-261
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: API / SPI, Passwords
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta14
>
>
> Firstly this class is not really SASL specific so should be in a general util package.
> Secondly we now have password specs and a PasswordFactory - if this class still has a future then maybe it should be using those instead of it's own custom implementation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 16:16:01 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 16:16:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-261) Rework (and move)
	UsernamePasswordHashUtil
In-Reply-To: <JIRA.12580680.1438967730000@Atlassian.JIRA>
References: <JIRA.12580680.1438967730000@Atlassian.JIRA>
	<JIRA.12580680.1438967730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580680.1438967730000.101289.1516914961098@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-261:
------------------------------

    Assignee: Jan Kalina


> Rework (and move) UsernamePasswordHashUtil
> ------------------------------------------
>
>                 Key: ELY-261
>                 URL: https://issues.jboss.org/browse/ELY-261
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: API / SPI, Passwords
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta14
>
>
> Firstly this class is not really SASL specific so should be in a general util package.
> Secondly we now have password specs and a PasswordFactory - if this class still has a future then maybe it should be using those instead of it's own custom implementation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 17:02:00 2018
From: issues at jboss.org (Ilia Vassilev (JIRA))
Date: Thu, 25 Jan 2018 17:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1502) Coverity,
 Missing call to superclass in AbstractGssapiMechanism
In-Reply-To: <JIRA.12730868.1516917690000@Atlassian.JIRA>
References: <JIRA.12730868.1516917690000@Atlassian.JIRA>
	<JIRA.12730868.1516917690574@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730868.1516917690000.101454.1516917720331@Atlassian.JIRA>

Ilia Vassilev created ELY-1502:
----------------------------------

             Summary: Coverity, Missing call to superclass in AbstractGssapiMechanism
                 Key: ELY-1502
                 URL: https://issues.jboss.org/browse/ELY-1502
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Authentication Mechanisms
    Affects Versions: 1.2.0.Beta11
            Reporter: Ilia Vassilev
            Assignee: Ilia Vassilev


super.getNegotiatedProperty() is not called in AbstractGssapiMechanism#getNegotiatedProperty, although it is called in similar cases in Gs2SaslServer, DigestSaslServer, AnonymousSaslClient.

{code:java|title=AbstractGssapiMechanism.java}
    @Override
    public Object getNegotiatedProperty(String propName) {
        assertComplete();

        switch (propName) {
            case Sasl.QOP:
                return selectedQop.getName();
            case Sasl.MAX_BUFFER:
                return Integer.toString(actualMaxReceiveBuffer != 0 ? actualMaxReceiveBuffer : configuredMaxReceiveBuffer);
            case Sasl.RAW_SEND_SIZE:
                return Integer.toString(maxBuffer);
        }

        return null;
    }
{code}

This coverity report is not caused by recent change in AbstractGssapiMechanism but rather Gs2SaslServer and DigestSaslServer

[1] https://scan7.coverity.com/reports.htm#v23632/p11778/fileInstanceId=44847684&defectInstanceId=9457508&mergedDefectId=1463150



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 17:16:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Thu, 25 Jan 2018 17:16:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-261) Rework (and move)
	UsernamePasswordHashUtil
In-Reply-To: <JIRA.12580680.1438967730000@Atlassian.JIRA>
References: <JIRA.12580680.1438967730000@Atlassian.JIRA>
	<JIRA.12580680.1438967730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580680.1438967730000.101507.1516918560159@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524117#comment-13524117 ] 

Jan Kalina edited comment on ELY-261 at 1/25/18 5:15 PM:
---------------------------------------------------------

Currently is the class already part of the public API so cannot be removed - will be deprecated.
Cannot be adjusted to use PasswordFactory, as it allows to use custom Digest object.


was (Author: honza889):
Currently is the class already part of the public API so cannot be removed - will be deprecated.

> Rework (and move) UsernamePasswordHashUtil
> ------------------------------------------
>
>                 Key: ELY-261
>                 URL: https://issues.jboss.org/browse/ELY-261
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: API / SPI, Passwords
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta14
>
>
> Firstly this class is not really SASL specific so should be in a general util package.
> Secondly we now have password specs and a PasswordFactory - if this class still has a future then maybe it should be using those instead of it's own custom implementation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 17:30:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jan 2018 17:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2235) Intermittent module loading
 failure in InterdependentDeploymentTestCase
In-Reply-To: <JIRA.12673068.1485365894000@Atlassian.JIRA>
References: <JIRA.12673068.1485365894000@Atlassian.JIRA>
	<JIRA.12673068.1485365894000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673068.1485365894000.101522.1516919400278@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reopened WFCORE-2235:
------------------------------------


> Intermittent module loading failure in InterdependentDeploymentTestCase
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-2235
>                 URL: https://issues.jboss.org/browse/WFCORE-2235
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Modules, Server
>    Affects Versions: 3.0.0.Alpha22
>            Reporter: Brian Stansberry
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Alpha3
>
>         Attachments: WFCORE-2235svcdump.txt
>
>
> InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional.
> The test intermittently fails due to a ModuleLoadException while deploying one of the modules:
> https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore_PullRequest
> The most notable bit of info in the log is:
> {code}
> 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar
>     at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
>     at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
>     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: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar
>     at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834)
>     at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472)
>     at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457)
>     at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370)
>     at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147)
>     at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387)
>     at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282)
>     at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270)
>     at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
>     ... 6 more
> {code}
> The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar.
> The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 17:36:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jan 2018 17:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2235) Intermittent module loading
 failure in InterdependentDeploymentTestCase
In-Reply-To: <JIRA.12673068.1485365894000@Atlassian.JIRA>
References: <JIRA.12673068.1485365894000@Atlassian.JIRA>
	<JIRA.12673068.1485365894000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673068.1485365894000.101527.1516919760209@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated WFCORE-2235:
-----------------------------------
    Affects Version/s: 4.0.0.Alpha6
                           (was: 3.0.0.Alpha22)


> Intermittent module loading failure in InterdependentDeploymentTestCase
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-2235
>                 URL: https://issues.jboss.org/browse/WFCORE-2235
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Modules, Server
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Brian Stansberry
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Alpha7
>
>         Attachments: WFCORE-2235svcdump.txt
>
>
> InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional.
> The test intermittently fails due to a ModuleLoadException while deploying one of the modules:
> https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore_PullRequest
> The most notable bit of info in the log is:
> {code}
> 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar
>     at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
>     at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
>     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: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar
>     at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834)
>     at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472)
>     at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457)
>     at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370)
>     at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147)
>     at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387)
>     at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282)
>     at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270)
>     at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
>     ... 6 more
> {code}
> The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar.
> The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 17:36:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jan 2018 17:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2235) Intermittent module loading
 failure in InterdependentDeploymentTestCase
In-Reply-To: <JIRA.12673068.1485365894000@Atlassian.JIRA>
References: <JIRA.12673068.1485365894000@Atlassian.JIRA>
	<JIRA.12673068.1485365894000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673068.1485365894000.101531.1516919760291@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated WFCORE-2235:
-----------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha3)


> Intermittent module loading failure in InterdependentDeploymentTestCase
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-2235
>                 URL: https://issues.jboss.org/browse/WFCORE-2235
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Modules, Server
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Brian Stansberry
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Alpha7
>
>         Attachments: WFCORE-2235svcdump.txt
>
>
> InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional.
> The test intermittently fails due to a ModuleLoadException while deploying one of the modules:
> https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore_PullRequest
> The most notable bit of info in the log is:
> {code}
> 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar
>     at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
>     at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
>     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: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar
>     at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834)
>     at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472)
>     at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457)
>     at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370)
>     at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147)
>     at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387)
>     at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282)
>     at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270)
>     at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
>     ... 6 more
> {code}
> The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar.
> The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 17:37:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Thu, 25 Jan 2018 17:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2235) Intermittent module loading
 failure in InterdependentDeploymentTestCase
In-Reply-To: <JIRA.12673068.1485365894000@Atlassian.JIRA>
References: <JIRA.12673068.1485365894000@Atlassian.JIRA>
	<JIRA.12673068.1485365894000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673068.1485365894000.101535.1516919820129@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka updated WFCORE-2235:
-----------------------------------
    Comment: was deleted

(was: This have been fixed with MSC upgrade.)


> Intermittent module loading failure in InterdependentDeploymentTestCase
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-2235
>                 URL: https://issues.jboss.org/browse/WFCORE-2235
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Modules, Server
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Brian Stansberry
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Alpha7
>
>         Attachments: WFCORE-2235svcdump.txt
>
>
> InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional.
> The test intermittently fails due to a ModuleLoadException while deploying one of the modules:
> https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore_PullRequest
> The most notable bit of info in the log is:
> {code}
> 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar
>     at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
>     at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
>     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: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar
>     at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834)
>     at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472)
>     at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457)
>     at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370)
>     at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147)
>     at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387)
>     at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282)
>     at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270)
>     at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
>     ... 6 more
> {code}
> The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar.
> The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 18:02:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 25 Jan 2018 18:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9733) Correct links and misc
 formatting etc in the "Description of the Management Model" doc
In-Reply-To: <JIRA.12730871.1516921294000@Atlassian.JIRA>
References: <JIRA.12730871.1516921294000@Atlassian.JIRA>
	<JIRA.12730871.1516921294413@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730871.1516921294000.101630.1516921320127@Atlassian.JIRA>

Brian Stansberry created WFLY-9733:
--------------------------------------

             Summary: Correct links and misc formatting etc in the "Description of the Management Model" doc
                 Key: WFLY-9733
                 URL: https://issues.jboss.org/browse/WFLY-9733
             Project: WildFly
          Issue Type: Task
          Components: Documentation, Domain Management
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Thu Jan 25 22:44:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Thu, 25 Jan 2018 22:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9734) Port misc build tweaks to
	WildFly
In-Reply-To: <JIRA.12730894.1516938219000@Atlassian.JIRA>
References: <JIRA.12730894.1516938219000@Atlassian.JIRA>
	<JIRA.12730894.1516938219457@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730894.1516938219000.102277.1516938240086@Atlassian.JIRA>

Brian Stansberry created WFLY-9734:
--------------------------------------

             Summary: Port misc build tweaks to WildFly
                 Key: WFLY-9734
                 URL: https://issues.jboss.org/browse/WFLY-9734
             Project: WildFly
          Issue Type: Task
          Components: Build System
            Reporter: Brian Stansberry
            Assignee: Brian Stansberry


WildFly and EAP have a few minor differences in some build settings; eliminate a few of these.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 01:20:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 26 Jan 2018 01:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1503) SPNEGO fails on
	<distributable/> deployment
In-Reply-To: <JIRA.12730901.1516947581000@Atlassian.JIRA>
References: <JIRA.12730901.1516947581000@Atlassian.JIRA>
	<JIRA.12730901.1516947581003@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730901.1516947581000.102340.1516947600189@Atlassian.JIRA>

Martin Choma created ELY-1503:
---------------------------------

             Summary: SPNEGO fails on <distributable/> deployment
                 Key: ELY-1503
                 URL: https://issues.jboss.org/browse/ELY-1503
             Project: WildFly Elytron
          Issue Type: Bug
            Reporter: Martin Choma
            Assignee: Darran Lofthouse
            Priority: Blocker


Session-scoped (default) SPNEGO authentication does not work on </distributable> deployments.

Works on CONNECTION and NONE scoped.

{code}
07:09:42,554 ERROR [io.undertow.request] (default task-63) UT005023: Exception handling request to /3246302d-d806-4441-ab87-1cf291a618d5/protected/SimpleSecuredServlet: java.lang.IllegalArgumentException: org.infinispan.commons.marshall.NotSerializableException: sun.security.jgss.GSSContextImpl
	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionAttributes.setAttribute(CoarseSessionAttributes.java:71)
	at org.wildfly.clustering.web.undertow.session.DistributableSession.setAttribute(DistributableSession.java:176)
	at io.undertow.servlet.spec.HttpSessionImpl.setAttribute(HttpSessionImpl.java:169)
	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService$4.setAttachment(ApplicationSecurityDomainDefinition.java:676)
	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:199)
	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
	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: org.infinispan.commons.marshall.NotSerializableException: sun.security.jgss.GSSContextImpl
{code}




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 01:21:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 26 Jan 2018 01:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1503) SPNEGO fails on
	<distributable/> deployment
In-Reply-To: <JIRA.12730901.1516947581000@Atlassian.JIRA>
References: <JIRA.12730901.1516947581000@Atlassian.JIRA>
	<JIRA.12730901.1516947581000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730901.1516947581000.102343.1516947660169@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma reassigned ELY-1503:
---------------------------------

    Assignee:     (was: Darran Lofthouse)


> SPNEGO fails on <distributable/> deployment
> -------------------------------------------
>
>                 Key: ELY-1503
>                 URL: https://issues.jboss.org/browse/ELY-1503
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Martin Choma
>            Priority: Blocker
>             Fix For: 1.2.0.Beta14
>
>
> Session-scoped (default) SPNEGO authentication does not work on </distributable> deployments.
> Works on CONNECTION and NONE scoped.
> {code}
> 07:09:42,554 ERROR [io.undertow.request] (default task-63) UT005023: Exception handling request to /3246302d-d806-4441-ab87-1cf291a618d5/protected/SimpleSecuredServlet: java.lang.IllegalArgumentException: org.infinispan.commons.marshall.NotSerializableException: sun.security.jgss.GSSContextImpl
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionAttributes.setAttribute(CoarseSessionAttributes.java:71)
> 	at org.wildfly.clustering.web.undertow.session.DistributableSession.setAttribute(DistributableSession.java:176)
> 	at io.undertow.servlet.spec.HttpSessionImpl.setAttribute(HttpSessionImpl.java:169)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService$4.setAttachment(ApplicationSecurityDomainDefinition.java:676)
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:199)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 	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: org.infinispan.commons.marshall.NotSerializableException: sun.security.jgss.GSSContextImpl
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 01:21:00 2018
From: issues at jboss.org (Martin Choma (JIRA))
Date: Fri, 26 Jan 2018 01:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1503) SPNEGO fails on
	<distributable/> deployment
In-Reply-To: <JIRA.12730901.1516947581000@Atlassian.JIRA>
References: <JIRA.12730901.1516947581000@Atlassian.JIRA>
	<JIRA.12730901.1516947581000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730901.1516947581000.102345.1516947660235@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1503?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Choma updated ELY-1503:
------------------------------
    Fix Version/s: 1.2.0.Beta14


> SPNEGO fails on <distributable/> deployment
> -------------------------------------------
>
>                 Key: ELY-1503
>                 URL: https://issues.jboss.org/browse/ELY-1503
>             Project: WildFly Elytron
>          Issue Type: Bug
>            Reporter: Martin Choma
>            Priority: Blocker
>             Fix For: 1.2.0.Beta14
>
>
> Session-scoped (default) SPNEGO authentication does not work on </distributable> deployments.
> Works on CONNECTION and NONE scoped.
> {code}
> 07:09:42,554 ERROR [io.undertow.request] (default task-63) UT005023: Exception handling request to /3246302d-d806-4441-ab87-1cf291a618d5/protected/SimpleSecuredServlet: java.lang.IllegalArgumentException: org.infinispan.commons.marshall.NotSerializableException: sun.security.jgss.GSSContextImpl
> 	at org.wildfly.clustering.web.infinispan.session.coarse.CoarseSessionAttributes.setAttribute(CoarseSessionAttributes.java:71)
> 	at org.wildfly.clustering.web.undertow.session.DistributableSession.setAttribute(DistributableSession.java:176)
> 	at io.undertow.servlet.spec.HttpSessionImpl.setAttribute(HttpSessionImpl.java:169)
> 	at org.wildfly.extension.undertow.ApplicationSecurityDomainDefinition$ApplicationSecurityDomainService$4.setAttachment(ApplicationSecurityDomainDefinition.java:676)
> 	at org.wildfly.security.http.impl.SpnegoAuthenticationMechanism.evaluateRequest(SpnegoAuthenticationMechanism.java:199)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> 	at org.wildfly.security.http.util.SetMechanismInformationMechanismFactory$1.evaluateRequest(SetMechanismInformationMechanismFactory.java:114)
> 	at org.wildfly.security.http.util.SecurityIdentityServerMechanismFactory$1.evaluateRequest(SecurityIdentityServerMechanismFactory.java:77)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.authenticate(HttpAuthenticator.java:115)
> 	at org.wildfly.security.http.HttpAuthenticator$AuthenticationExchange.access$100(HttpAuthenticator.java:94)
> 	at org.wildfly.security.http.HttpAuthenticator.authenticate(HttpAuthenticator.java:78)
> 	at org.wildfly.elytron.web.undertow.server.SecurityContextImpl.authenticate(SecurityContextImpl.java:100)
> 	at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:55)
> 	at io.undertow.server.handlers.DisableCacheHandler.handleRequest(DisableCacheHandler.java:33)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.security.handlers.AuthenticationConstraintHandler.handleRequest(AuthenticationConstraintHandler.java:53)
> 	at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
> 	at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
> 	at io.undertow.servlet.handlers.security.ServletSecurityConstraintHandler.handleRequest(ServletSecurityConstraintHandler.java:59)
> 	at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at org.wildfly.extension.undertow.deployment.GlobalRequestControllerHandler.handleRequest(GlobalRequestControllerHandler.java:68)
> 	at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:292)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$100(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:138)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$2.call(ServletInitialHandler.java:135)
> 	at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:48)
> 	at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:272)
> 	at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
> 	at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:104)
> 	at io.undertow.server.Connectors.executeRootHandler(Connectors.java:326)
> 	at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:812)
> 	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: org.infinispan.commons.marshall.NotSerializableException: sun.security.jgss.GSSContextImpl
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 01:25:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 26 Jan 2018 01:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2273) [DMN Editor] Contextual
 selection - Hover state
In-Reply-To: <JIRA.12730777.1516881868000@Atlassian.JIRA>
References: <JIRA.12730777.1516881868000@Atlassian.JIRA>
	<JIRA.12730777.1516881868000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730777.1516881868000.102348.1516947900145@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2273:
--------------------------------
    QE Status: ON_QA  (was: NEW)


> [DMN Editor] Contextual selection - Hover state
> -----------------------------------------------
>
>                 Key: DROOLS-2273
>                 URL: https://issues.jboss.org/browse/DROOLS-2273
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> Elements within a logic table that offer contextual actions will present a hover state on focus. Examples of elements that might offer actions include: Rows, cells, columns, table? Or in context terms: Rules, Inputs/Outputs, Context row, etc



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 26 02:23:00 2018
From: issues at jboss.org (Toshiya Kobayashi (JIRA))
Date: Fri, 26 Jan 2018 02:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2276) NoClassDefFoundError is
 thrown on updateToVersion() with rule removal and eval
In-Reply-To: <JIRA.12730905.1516951368000@Atlassian.JIRA>
References: <JIRA.12730905.1516951368000@Atlassian.JIRA>
	<JIRA.12730905.1516951368094@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730905.1516951368000.102474.1516951380737@Atlassian.JIRA>

Toshiya Kobayashi created DROOLS-2276:
-----------------------------------------

             Summary: NoClassDefFoundError is thrown on updateToVersion() with rule removal and eval
                 Key: DROOLS-2276
                 URL: https://issues.jboss.org/browse/DROOLS-2276
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Toshiya Kobayashi
            Assignee: Mario Fusco


Under the conditions:

- updateToVersion() is called twice
- A rule is removed on the version change
- The rule has eval()

NoClassDefFoundError is thrown on the second updateToVersion()

{noformat}
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.801 sec <<< FAILURE! - in org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest
testRuleRemovalAndEval(org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest)  Time elapsed: 1.799 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org/drools/compiler/Rule_R2773041198
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:191)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:181)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:148)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:575)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.drools.compiler.Rule_R2773041198Eval0InvokerGenerated.evaluate(Unknown Source)
	at org.drools.compiler.Rule_R2773041198Eval0Invoker.evaluate(Unknown Source)
	at org.drools.core.rule.EvalCondition.isAllowed(EvalCondition.java:129)
	at org.drools.core.phreak.PhreakEvalNode.doLeftInserts(PhreakEvalNode.java:72)
	at org.drools.core.phreak.PhreakEvalNode.doNode(PhreakEvalNode.java:56)
	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:381)
	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
	at org.drools.core.phreak.AddRemoveRule.flushStagedTuples(AddRemoveRule.java:604)
	at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:164)
	at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:191)
	at org.drools.core.reteoo.ReteooBuilder.removeRules(ReteooBuilder.java:177)
	at org.drools.core.impl.KnowledgeBaseImpl.removeObjectsGeneratedFromResource(KnowledgeBaseImpl.java:1740)
	at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.removeObjectsGeneratedFromResource(KnowledgeBuilderImpl.java:2281)
	at org.drools.compiler.kie.builder.impl.KieBaseUpdater.run(KieBaseUpdater.java:66)
	at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:245)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:182)
	at org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest.testRuleRemovalAndEval(IncrementalCompilationTest.java:4708)
{noformat}

Will send a unit test PR.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 02:27:00 2018
From: issues at jboss.org (Toshiya Kobayashi (JIRA))
Date: Fri, 26 Jan 2018 02:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2276) NoClassDefFoundError is
 thrown on updateToVersion() with rule removal and eval
In-Reply-To: <JIRA.12730905.1516951368000@Atlassian.JIRA>
References: <JIRA.12730905.1516951368000@Atlassian.JIRA>
	<JIRA.12730905.1516951368000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730905.1516951368000.102498.1516951620419@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toshiya Kobayashi updated DROOLS-2276:
--------------------------------------
           Description: 
Under the conditions:

- updateToVersion() is called twice
- A rule is removed on the version change
- The rule has eval()

NoClassDefFoundError is thrown on the second updateToVersion()

{noformat}
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.801 sec <<< FAILURE! - in org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest
testRuleRemovalAndEval(org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest)  Time elapsed: 1.799 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org/drools/compiler/Rule_R2773041198
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:191)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:181)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:148)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:575)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.drools.compiler.Rule_R2773041198Eval0InvokerGenerated.evaluate(Unknown Source)
	at org.drools.compiler.Rule_R2773041198Eval0Invoker.evaluate(Unknown Source)
	at org.drools.core.rule.EvalCondition.isAllowed(EvalCondition.java:129)
	at org.drools.core.phreak.PhreakEvalNode.doLeftInserts(PhreakEvalNode.java:72)
	at org.drools.core.phreak.PhreakEvalNode.doNode(PhreakEvalNode.java:56)
	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:381)
	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
	at org.drools.core.phreak.AddRemoveRule.flushStagedTuples(AddRemoveRule.java:604)
	at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:164)
	at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:191)
	at org.drools.core.reteoo.ReteooBuilder.removeRules(ReteooBuilder.java:177)
	at org.drools.core.impl.KnowledgeBaseImpl.removeObjectsGeneratedFromResource(KnowledgeBaseImpl.java:1740)
	at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.removeObjectsGeneratedFromResource(KnowledgeBuilderImpl.java:2281)
	at org.drools.compiler.kie.builder.impl.KieBaseUpdater.run(KieBaseUpdater.java:66)
	at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:245)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:182)
	at org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest.testRuleRemovalAndEval(IncrementalCompilationTest.java:4708)
{noformat}


  was:
Under the conditions:

- updateToVersion() is called twice
- A rule is removed on the version change
- The rule has eval()

NoClassDefFoundError is thrown on the second updateToVersion()

{noformat}
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.801 sec <<< FAILURE! - in org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest
testRuleRemovalAndEval(org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest)  Time elapsed: 1.799 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org/drools/compiler/Rule_R2773041198
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:191)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:181)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:148)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:575)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.drools.compiler.Rule_R2773041198Eval0InvokerGenerated.evaluate(Unknown Source)
	at org.drools.compiler.Rule_R2773041198Eval0Invoker.evaluate(Unknown Source)
	at org.drools.core.rule.EvalCondition.isAllowed(EvalCondition.java:129)
	at org.drools.core.phreak.PhreakEvalNode.doLeftInserts(PhreakEvalNode.java:72)
	at org.drools.core.phreak.PhreakEvalNode.doNode(PhreakEvalNode.java:56)
	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:381)
	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
	at org.drools.core.phreak.AddRemoveRule.flushStagedTuples(AddRemoveRule.java:604)
	at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:164)
	at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:191)
	at org.drools.core.reteoo.ReteooBuilder.removeRules(ReteooBuilder.java:177)
	at org.drools.core.impl.KnowledgeBaseImpl.removeObjectsGeneratedFromResource(KnowledgeBaseImpl.java:1740)
	at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.removeObjectsGeneratedFromResource(KnowledgeBuilderImpl.java:2281)
	at org.drools.compiler.kie.builder.impl.KieBaseUpdater.run(KieBaseUpdater.java:66)
	at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:245)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:182)
	at org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest.testRuleRemovalAndEval(IncrementalCompilationTest.java:4708)
{noformat}

Will send a unit test PR.

      Git Pull Request: https://github.com/kiegroup/drools/pull/1725
    Steps to Reproduce: - See https://github.com/kiegroup/drools/pull/1725


> NoClassDefFoundError is thrown on updateToVersion() with rule removal and eval
> ------------------------------------------------------------------------------
>
>                 Key: DROOLS-2276
>                 URL: https://issues.jboss.org/browse/DROOLS-2276
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Toshiya Kobayashi
>            Assignee: Mario Fusco
>              Labels: support
>
> Under the conditions:
> - updateToVersion() is called twice
> - A rule is removed on the version change
> - The rule has eval()
> NoClassDefFoundError is thrown on the second updateToVersion()
> {noformat}
> Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.801 sec <<< FAILURE! - in org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest
> testRuleRemovalAndEval(org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest)  Time elapsed: 1.799 sec  <<< ERROR!
> java.lang.NoClassDefFoundError: org/drools/compiler/Rule_R2773041198
> 	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:191)
> 	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:181)
> 	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:148)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> 	at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:575)
> 	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
> 	at org.drools.compiler.Rule_R2773041198Eval0InvokerGenerated.evaluate(Unknown Source)
> 	at org.drools.compiler.Rule_R2773041198Eval0Invoker.evaluate(Unknown Source)
> 	at org.drools.core.rule.EvalCondition.isAllowed(EvalCondition.java:129)
> 	at org.drools.core.phreak.PhreakEvalNode.doLeftInserts(PhreakEvalNode.java:72)
> 	at org.drools.core.phreak.PhreakEvalNode.doNode(PhreakEvalNode.java:56)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:381)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
> 	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
> 	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
> 	at org.drools.core.phreak.AddRemoveRule.flushStagedTuples(AddRemoveRule.java:604)
> 	at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:164)
> 	at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:191)
> 	at org.drools.core.reteoo.ReteooBuilder.removeRules(ReteooBuilder.java:177)
> 	at org.drools.core.impl.KnowledgeBaseImpl.removeObjectsGeneratedFromResource(KnowledgeBaseImpl.java:1740)
> 	at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.removeObjectsGeneratedFromResource(KnowledgeBuilderImpl.java:2281)
> 	at org.drools.compiler.kie.builder.impl.KieBaseUpdater.run(KieBaseUpdater.java:66)
> 	at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:245)
> 	at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:182)
> 	at org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest.testRuleRemovalAndEval(IncrementalCompilationTest.java:4708)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 02:28:00 2018
From: issues at jboss.org (Toshiya Kobayashi (JIRA))
Date: Fri, 26 Jan 2018 02:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2277) NoClassDefFoundError is
 thrown on updateToVersion() with rule removal and eval
In-Reply-To: <JIRA.12730907.1516951640000@Atlassian.JIRA>
References: <JIRA.12730907.1516951640000@Atlassian.JIRA>
	<JIRA.12730907.1516951640335@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730907.1516951640000.102505.1516951680337@Atlassian.JIRA>

Toshiya Kobayashi created DROOLS-2277:
-----------------------------------------

             Summary: NoClassDefFoundError is thrown on updateToVersion() with rule removal and eval
                 Key: DROOLS-2277
                 URL: https://issues.jboss.org/browse/DROOLS-2277
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Toshiya Kobayashi
            Assignee: Mario Fusco


Under the conditions:

- updateToVersion() is called twice
- A rule is removed on the version change
- The rule has eval()

NoClassDefFoundError is thrown on the second updateToVersion()

{noformat}
Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 1.801 sec <<< FAILURE! - in org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest
testRuleRemovalAndEval(org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest)  Time elapsed: 1.799 sec  <<< ERROR!
java.lang.NoClassDefFoundError: org/drools/compiler/Rule_R2773041198
	at org.drools.core.common.ProjectClassLoader.tryDefineType(ProjectClassLoader.java:191)
	at org.drools.core.common.ProjectClassLoader.loadType(ProjectClassLoader.java:181)
	at org.drools.core.common.ProjectClassLoader.loadClass(ProjectClassLoader.java:148)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.loadClass(JavaDialectRuntimeData.java:575)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	at org.drools.compiler.Rule_R2773041198Eval0InvokerGenerated.evaluate(Unknown Source)
	at org.drools.compiler.Rule_R2773041198Eval0Invoker.evaluate(Unknown Source)
	at org.drools.core.rule.EvalCondition.isAllowed(EvalCondition.java:129)
	at org.drools.core.phreak.PhreakEvalNode.doLeftInserts(PhreakEvalNode.java:72)
	at org.drools.core.phreak.PhreakEvalNode.doNode(PhreakEvalNode.java:56)
	at org.drools.core.phreak.RuleNetworkEvaluator.evalNode(RuleNetworkEvaluator.java:381)
	at org.drools.core.phreak.RuleNetworkEvaluator.innerEval(RuleNetworkEvaluator.java:333)
	at org.drools.core.phreak.RuleNetworkEvaluator.outerEval(RuleNetworkEvaluator.java:169)
	at org.drools.core.phreak.AddRemoveRule.forceFlushLeftTuple(AddRemoveRule.java:676)
	at org.drools.core.phreak.AddRemoveRule.flushStagedTuples(AddRemoveRule.java:604)
	at org.drools.core.phreak.AddRemoveRule.removeRule(AddRemoveRule.java:164)
	at org.drools.core.reteoo.ReteooBuilder.removeTerminalNode(ReteooBuilder.java:191)
	at org.drools.core.reteoo.ReteooBuilder.removeRules(ReteooBuilder.java:177)
	at org.drools.core.impl.KnowledgeBaseImpl.removeObjectsGeneratedFromResource(KnowledgeBaseImpl.java:1740)
	at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.removeObjectsGeneratedFromResource(KnowledgeBuilderImpl.java:2281)
	at org.drools.compiler.kie.builder.impl.KieBaseUpdater.run(KieBaseUpdater.java:66)
	at org.drools.core.impl.KnowledgeBaseImpl.enqueueModification(KnowledgeBaseImpl.java:734)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.update(KieContainerImpl.java:245)
	at org.drools.compiler.kie.builder.impl.KieContainerImpl.updateToVersion(KieContainerImpl.java:182)
	at org.drools.compiler.integrationtests.incrementalcompilation.IncrementalCompilationTest.testRuleRemovalAndEval(IncrementalCompilationTest.java:4708)
{noformat}




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 02:50:00 2018
From: issues at jboss.org (Osamu Nagano (JIRA))
Date: Fri, 26 Jan 2018 02:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9735) Add systemd unit file to zip
	distribution
In-Reply-To: <JIRA.12730718.1516864321000@Atlassian.JIRA>
References: <JIRA.12730718.1516864321000@Atlassian.JIRA>
	<JIRA.12730718.1516864321000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730718.1516864321000.102801.1516953000849@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9735?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Osamu Nagano moved JBEAP-14146 to WFLY-9735:
--------------------------------------------

           Project: WildFly  (was: JBoss Enterprise Application Platform)
               Key: WFLY-9735  (was: JBEAP-14146)
        Issue Type: Feature Request  (was: Enhancement)
          Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
       Component/s: Scripts
                        (was: Scripts)
    Target Release:   (was: 7.backlog.GA)


> Add systemd unit file to zip distribution
> -----------------------------------------
>
>                 Key: WFLY-9735
>                 URL: https://issues.jboss.org/browse/WFLY-9735
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Scripts
>            Reporter: Osamu Nagano
>         Attachments: eap7-standalone.service, tomcat8.service
>
>
> Systemd can handle legacy init.d scripts, but many customers have asked for native integration to systemd. We may be able to provide the out-of-the-box unit file or a template of it with some documentation. It seems JWS is considering the same in JWS-811 so EAP may adopt the same way.
> One advantage of systemd is the ability to depends on socket unit file so that we may be able to omit jsvc to listen a privileged port.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 02:53:00 2018
From: issues at jboss.org (Osamu Nagano (JIRA))
Date: Fri, 26 Jan 2018 02:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9735) Add systemd unit file to zip
	distribution
In-Reply-To: <JIRA.12730718.1516864321000@Atlassian.JIRA>
References: <JIRA.12730718.1516864321000@Atlassian.JIRA>
	<JIRA.12730718.1516864321000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730718.1516864321000.102814.1516953180352@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524188#comment-13524188 ] 

Osamu Nagano commented on WFLY-9735:
------------------------------------

Moved from JBEAP-14146 to this WFLY-9735 to discuss in the upstream first.

> Add systemd unit file to zip distribution
> -----------------------------------------
>
>                 Key: WFLY-9735
>                 URL: https://issues.jboss.org/browse/WFLY-9735
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Scripts
>            Reporter: Osamu Nagano
>         Attachments: eap7-standalone.service, tomcat8.service
>
>
> Systemd can handle legacy init.d scripts, but many customers have asked for native integration to systemd. We may be able to provide the out-of-the-box unit file or a template of it with some documentation. It seems JWS is considering the same in JWS-811 so EAP may adopt the same way.
> One advantage of systemd is the ability to depends on socket unit file so that we may be able to omit jsvc to listen a privileged port.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 04:15:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 26 Jan 2018 04:15:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-261) Rework (and move)
	UsernamePasswordHashUtil
In-Reply-To: <JIRA.12580680.1438967730000@Atlassian.JIRA>
References: <JIRA.12580680.1438967730000@Atlassian.JIRA>
	<JIRA.12580680.1438967730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580680.1438967730000.103498.1516958100323@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524240#comment-13524240 ] 

Jan Kalina commented on ELY-261:
--------------------------------

For using PasswordFactory in elytron util (Main class of the elytron jar) there is problem:
WildflyElytronProvider requires classes from wildfly.common - looks like we would have to include wildfly.common into elytron jar :(

{code}
$ java -jar wildfly-elytron-1.2.0.Beta13-SNAPSHOT.jar UsernamePasswordHashUtil admin Test pass
Exception in thread "main" java.lang.BootstrapMethodError: java.lang.NoClassDefFoundError: org/wildfly/common/function/ExceptionSupplier
	at org.wildfly.security.WildFlyElytronProvider.toSupplier(WildFlyElytronProvider.java:393)
	at org.wildfly.security.WildFlyElytronProvider.putHttpAuthenticationMechanismImplementations(WildFlyElytronProvider.java:251)
	at org.wildfly.security.WildFlyElytronProvider.<init>(WildFlyElytronProvider.java:161)
	at org.wildfly.security._private.Main.usernamePasswordHash(Main.java:139)
	at org.wildfly.security._private.Main.main(Main.java:97)
Caused by: java.lang.NoClassDefFoundError: org/wildfly/common/function/ExceptionSupplier
	... 5 more
Caused by: java.lang.ClassNotFoundException: org.wildfly.common.function.ExceptionSupplier
	at java.net.URLClassLoader.findClass(URLClassLoader.java:381)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
	at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:335)
	at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
	... 5 more
{code}

> Rework (and move) UsernamePasswordHashUtil
> ------------------------------------------
>
>                 Key: ELY-261
>                 URL: https://issues.jboss.org/browse/ELY-261
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: API / SPI, Passwords
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta14
>
>
> Firstly this class is not really SASL specific so should be in a general util package.
> Secondly we now have password specs and a PasswordFactory - if this class still has a future then maybe it should be using those instead of it's own custom implementation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 04:53:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Fri, 26 Jan 2018 04:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3552) Upgrade JBoss MSC to
	1.3.0.Final
In-Reply-To: <JIRA.12730967.1516960376000@Atlassian.JIRA>
References: <JIRA.12730967.1516960376000@Atlassian.JIRA>
	<JIRA.12730967.1516960376001@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730967.1516960376000.103909.1516960380628@Atlassian.JIRA>

Richard Opalka created WFCORE-3552:
--------------------------------------

             Summary: Upgrade JBoss MSC to 1.3.0.Final
                 Key: WFCORE-3552
                 URL: https://issues.jboss.org/browse/WFCORE-3552
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: Richard Opalka
            Assignee: Richard Opalka






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 05:17:00 2018
From: issues at jboss.org (Dorin Opris (JIRA))
Date: Fri, 26 Jan 2018 05:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2278) Parallel rules compiling
 does not take into account JVM container security policy
In-Reply-To: <JIRA.12730973.1516961595000@Atlassian.JIRA>
References: <JIRA.12730973.1516961595000@Atlassian.JIRA>
	<JIRA.12730973.1516961595000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730973.1516961595000.104117.1516961820388@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2278?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Dorin Opris updated DROOLS-2278:
--------------------------------
    Security:     (was: Red Hat Internal)


> Parallel rules compiling does not take into account JVM container security policy
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-2278
>                 URL: https://issues.jboss.org/browse/DROOLS-2278
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>         Environment: Linux 2.6.32-696.13.2.el6.x86_64
> OpenJDK Runtime Environment (build 1.8.0_151-b12)
> OpenJDK 64-Bit Server VM (build 25.151-b12, mixed mode)
>            Reporter: Dorin Opris
>            Assignee: Mario Fusco
>
> We deployed Drools 7.5.0.Final libraries in a java container (commercial product) which specifies a security manager and a policy. 
> When running the container with small Drools packages (i.e. number of rules is less than 10) processing goes very well. When it comes to more rules the following exception is issued:
> SEVERE  Failed to instantiate <container_unit>; Caused by: org.jini.rio.core.JSBInstantiationException: 
> java.security.AccessControlException: access denied ("java.lang.RuntimePermission" "createClassLoader")
>         at java.security.AccessControlContext.checkPermission(AccessControlContext.java:472)
>         at java.security.AccessController.checkPermission(AccessController.java:884)
>         at java.lang.SecurityManager.checkPermission(SecurityManager.java:549)
>         at java.lang.SecurityManager.checkCreateClassLoader(SecurityManager.java:611)
>         at java.lang.ClassLoader.checkCreateClassLoader(ClassLoader.java:274)
>         at java.lang.ClassLoader.<init>(ClassLoader.java:316)
>         at org.drools.core.rule.JavaDialectRuntimeData$PackageClassLoader.<init>(JavaDialectRuntimeData.java:573)
>         at org.drools.core.rule.JavaDialectRuntimeData.makeClassLoader(JavaDialectRuntimeData.java:555)
>         at org.drools.core.rule.JavaDialectRuntimeData.onAdd(JavaDialectRuntimeData.java:238)
>         at org.drools.compiler.rule.builder.dialect.java.JavaDialect.<init>(JavaDialect.java:189)
>         at org.drools.compiler.rule.builder.dialect.java.JavaDialectConfiguration.newDialect(JavaDialectConfiguration.java:88)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderConfigurationImpl.buildDialectRegistry(KnowledgeBuilderConfigurationImpl.java:377)
>         at org.drools.compiler.compiler.PackageRegistry.<init>(PackageRegistry.java:51)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.createPackageRegistry(.java:1051)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$getOrCreatePackageRegistry$0(KnowledgeBuilderImpl.java:1026)
>         at java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1660)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.getOrCreatePackageRegistry(KnowledgeBuilderImpl.java:1026)
>         at org.drools.compiler.builder.impl.TypeDeclarationCache.createTypeDeclarationForBean(TypeDeclarationCache.java:262)
>         at org.drools.compiler.builder.impl.TypeDeclarationCache.getAndRegisterTypeDeclaration(TypeDeclarationCache.java:90)
>         at org.drools.compiler.builder.impl.TypeDeclarationBuilder.getAndRegisterTypeDeclaration(TypeDeclarationBuilder.java:69)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.getAndRegisterTypeDeclaration(KnowledgeBuilderImpl.java:1781)
>         at org.drools.compiler.rule.builder.PatternBuilder.processClassObjectType(PatternBuilder.java:306)
>         at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:181)
>         at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:151)
>         at org.drools.compiler.rule.builder.PatternBuilder.build(PatternBuilder.java:133)
>         at org.drools.compiler.rule.builder.GroupElementBuilder.build(GroupElementBuilder.java:66)
>         at org.drools.compiler.rule.builder.RuleBuilder.build(RuleBuilder.java:105)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.addRule(KnowledgeBuilderImpl.java:1202)
>         at org.drools.compiler.builder.impl.KnowledgeBuilderImpl.lambda$compileRulesLevel$3(KnowledgeBuilderImpl.java:1163)
>         at java.util.stream.ForEachOps$ForEachOp$OfRef.accept(ForEachOps.java:184)
>         at java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:175)
>         at java.util.ArrayList$ArrayListSpliterator.forEachRemaining(ArrayList.java:1380)
>         at java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:481)
>         at java.util.stream.ForEachOps$ForEachTask.compute(ForEachOps.java:291)
>         at java.util.concurrent.CountedCompleter.exec(CountedCompleter.java:731)
>         at java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:289)
>         at java.util.concurrent.ForkJoinPool$WorkQueue.runTask(ForkJoinPool.java:1056)
>         at java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:1692)
>         at java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:157)
> It seems Drools 7.* version has introduced parallel compilation of rules using Java platform forkJoin threads that, according to its spec, are a bit security restrictive in the sense that container security policy or container class loader access control context is ignored. 
> "If a SecurityManager is present and no factory is specified, then the default pool uses a factory supplying threads that have no Permissions enabled. The system class loader is used to load these classes." https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/ForkJoinPool.html
> Could Drools fix this serial-parallel asymmetric output of rules compilation logic? Or it's just a Java issue like https://bugs.java.com/view_bug.do?bug_id=8184335 ?



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 05:38:00 2018
From: issues at jboss.org (Tomaz Cerar (JIRA))
Date: Fri, 26 Jan 2018 05:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9736) JDK9+ add
 Automatic-Module-Name to all spec_api deps
In-Reply-To: <JIRA.12730982.1516963047000@Atlassian.JIRA>
References: <JIRA.12730982.1516963047000@Atlassian.JIRA>
	<JIRA.12730982.1516963047908@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730982.1516963047000.104190.1516963080477@Atlassian.JIRA>

Tomaz Cerar created WFLY-9736:
---------------------------------

             Summary: JDK9+ add Automatic-Module-Name to all spec_api deps
                 Key: WFLY-9736
                 URL: https://issues.jboss.org/browse/WFLY-9736
             Project: WildFly
          Issue Type: Task
          Components: Build System
         Environment: JDK9+
            Reporter: Tomaz Cerar
            Assignee: Tomaz Cerar


All spec_api jars should be upgraded to versions that provide Automatic-Module-Name



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 05:58:01 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 26 Jan 2018 05:58:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-261) Rework (and move)
	UsernamePasswordHashUtil
In-Reply-To: <JIRA.12580680.1438967730000@Atlassian.JIRA>
References: <JIRA.12580680.1438967730000@Atlassian.JIRA>
	<JIRA.12580680.1438967730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580680.1438967730000.104277.1516964281011@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524308#comment-13524308 ] 

Darran Lofthouse commented on ELY-261:
--------------------------------------

Actually if we don't already include it I am surprised so I don't think a bad one to add - we use a lot of wildfly.common across Elytron so it probably should already be added.

> Rework (and move) UsernamePasswordHashUtil
> ------------------------------------------
>
>                 Key: ELY-261
>                 URL: https://issues.jboss.org/browse/ELY-261
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: API / SPI, Passwords
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta14
>
>
> Firstly this class is not really SASL specific so should be in a general util package.
> Secondly we now have password specs and a PasswordFactory - if this class still has a future then maybe it should be using those instead of it's own custom implementation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 06:01:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 26 Jan 2018 06:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2160) Enhance UI in Test
	Scenarios Editor
In-Reply-To: <JIRA.12723168.1512142861000@Atlassian.JIRA>
References: <JIRA.12723168.1512142861000@Atlassian.JIRA>
	<JIRA.12723168.1512142861000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723168.1512142861000.104284.1516964460602@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524309#comment-13524309 ] 

Jozef Marko commented on DROOLS-2160:
-------------------------------------

To summarize changes done in this ticket:
- Two new tabs were introduced
-- Audit log: shows flow of events during scenario run and fired events
-- Settings: User configure here more details about scenario, subset of rules to use, date and time which use for scenario ...
- Delete buttons were increased
- "Delete Scenario Block" button was moved below the particular scenario block, previously was in the middle of the block
- There were added spaces between input fields in "given", "call method" and "expect" blocks


> Enhance UI in Test Scenarios Editor
> -----------------------------------
>
>                 Key: DROOLS-2160
>                 URL: https://issues.jboss.org/browse/DROOLS-2160
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Test Scenarios Editor
>            Reporter: Ivo Bek
>            Assignee: Jozef Marko
>              Labels: UX
>         Attachments: Screenshot from 2017-12-01 16-38-52.png
>
>
> Test Scenarios editor needs to be polished:
> * -Delete Buttons are too small - it would be good to enlarge them.- done with [PR|https://github.com/kiegroup/drools-wb/pull/723]
> * Some other elements doesn't have enough space around them.
> * Please do any other small visual changes which makes sense.
> ** -Introduced two new tabs.- resolved by [PR|https://github.com/kiegroup/drools-wb/pull/754]
> *** One shows information about fired rules during scenario run
> *** Second enables to configure, kie base/session, allowed rules, date and time used in scenario



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 06:02:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 26 Jan 2018 06:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2160) Enhance UI in Test
	Scenarios Editor
In-Reply-To: <JIRA.12723168.1512142861000@Atlassian.JIRA>
References: <JIRA.12723168.1512142861000@Atlassian.JIRA>
	<JIRA.12723168.1512142861000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723168.1512142861000.104292.1516964520322@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jozef Marko updated DROOLS-2160:
--------------------------------
    Attachment: Screenshot from 2018-01-26 01-47-48.png


> Enhance UI in Test Scenarios Editor
> -----------------------------------
>
>                 Key: DROOLS-2160
>                 URL: https://issues.jboss.org/browse/DROOLS-2160
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Test Scenarios Editor
>            Reporter: Ivo Bek
>            Assignee: Jozef Marko
>              Labels: UX
>             Fix For: 7.5.0.Final, 7.6.0.Final
>
>         Attachments: Screenshot from 2017-12-01 16-38-52.png, Screenshot from 2018-01-26 01-47-48.png
>
>
> Test Scenarios editor needs to be polished:
> * -Delete Buttons are too small - it would be good to enlarge them.- done with [PR|https://github.com/kiegroup/drools-wb/pull/723]
> * Some other elements doesn't have enough space around them.
> * Please do any other small visual changes which makes sense.
> ** -Introduced two new tabs.- resolved by [PR|https://github.com/kiegroup/drools-wb/pull/754]
> *** One shows information about fired rules during scenario run
> *** Second enables to configure, kie base/session, allowed rules, date and time used in scenario



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 06:02:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Fri, 26 Jan 2018 06:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2160) Enhance UI in Test
	Scenarios Editor
In-Reply-To: <JIRA.12723168.1512142861000@Atlassian.JIRA>
References: <JIRA.12723168.1512142861000@Atlassian.JIRA>
	<JIRA.12723168.1512142861000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12723168.1512142861000.104296.1516964520462@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2160?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524309#comment-13524309 ] 

Jozef Marko edited comment on DROOLS-2160 at 1/26/18 6:01 AM:
--------------------------------------------------------------

To summarize changes done in this ticket:
- Two new tabs were introduced
-- Audit log: shows flow of events during scenario run and fired events
-- Settings: User configure here more details about scenario, subset of rules to use, date and time which use for scenario ...
- Delete buttons were increased
- "Delete Scenario Block" button was moved below the particular scenario block, previously was in the middle of the block
- There were added spaces between input fields in "given", "call method" and "expect" blocks

Final state shown here:
 !Screenshot from 2018-01-26 01-47-48.png|thumbnail! 



was (Author: jomarko):
To summarize changes done in this ticket:
- Two new tabs were introduced
-- Audit log: shows flow of events during scenario run and fired events
-- Settings: User configure here more details about scenario, subset of rules to use, date and time which use for scenario ...
- Delete buttons were increased
- "Delete Scenario Block" button was moved below the particular scenario block, previously was in the middle of the block
- There were added spaces between input fields in "given", "call method" and "expect" blocks


> Enhance UI in Test Scenarios Editor
> -----------------------------------
>
>                 Key: DROOLS-2160
>                 URL: https://issues.jboss.org/browse/DROOLS-2160
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Test Scenarios Editor
>            Reporter: Ivo Bek
>            Assignee: Jozef Marko
>              Labels: UX
>             Fix For: 7.5.0.Final, 7.6.0.Final
>
>         Attachments: Screenshot from 2017-12-01 16-38-52.png, Screenshot from 2018-01-26 01-47-48.png
>
>
> Test Scenarios editor needs to be polished:
> * -Delete Buttons are too small - it would be good to enlarge them.- done with [PR|https://github.com/kiegroup/drools-wb/pull/723]
> * Some other elements doesn't have enough space around them.
> * Please do any other small visual changes which makes sense.
> ** -Introduced two new tabs.- resolved by [PR|https://github.com/kiegroup/drools-wb/pull/754]
> *** One shows information about fired rules during scenario run
> *** Second enables to configure, kie base/session, allowed rules, date and time used in scenario



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 06:26:00 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Fri, 26 Jan 2018 06:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9403) Unable to deploy clustered
 ejb in a mixed domain.
In-Reply-To: <JIRA.12714113.1506716604000@Atlassian.JIRA>
References: <JIRA.12714113.1506716604000@Atlassian.JIRA>
	<JIRA.12714113.1506716604000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12714113.1506716604000.104408.1516965960744@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges reopened WFLY-9403:
--------------------------------


Issue reopened in order to include additional tests

> Unable to deploy clustered ejb in a mixed domain.
> -------------------------------------------------
>
>                 Key: WFLY-9403
>                 URL: https://issues.jboss.org/browse/WFLY-9403
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>    Affects Versions: 11.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Yeray Borges
>             Fix For: 12.0.0.Alpha1
>
>         Attachments: Clusterejb-0.0.1.jar, domain_EAP7.xml, host_EAP7.xml, host_slave_EAP6.xml
>
>
> Using a ha profile in a mixed domain( i.e EAP 7 as a domain controler and EAP 6.3 as a slave) it does not seem possible to deploy ejb successfully. 
> While deploying a simple @clustered ejb on EAP 6.3 server below exception was thrown. This issue is easily replicated.
> {code:java}
> 19:12:11,886 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-16) JNDI bindings for session bean named CounterBean in deployment unit deployment "Clusterejb-0.0.1.jar" are as follows:
>     java:global/Clusterejb-0.0.1/CounterBean!com.test.Counter
>     java:app/Clusterejb-0.0.1/CounterBean!com.test.Counter
>     java:module/CounterBean!com.test.Counter
>     java:jboss/exported/Clusterejb-0.0.1/CounterBean!com.test.Counter
>     java:global/Clusterejb-0.0.1/CounterBean
>     java:app/Clusterejb-0.0.1/CounterBean
>     java:module/CounterBean
> 19:12:12,089 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "Clusterejb-0.0.1.jar" (runtime-name : "Clusterejb-0.0.1.jar")
> 19:12:12,090 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.ejb.cache.cluster.simple (missing) dependents: [service jboss.ejb.cache.cluster]
> 19:12:12,093 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19) started (with errors) in 2654ms - Started 185 of 293 services (14 services failed or missing dependencies, 117 services are lazy, passive or on-demand)
> {code}
> I have attached the configuration files for both EAP 7 and EAP 6. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 06:28:00 2018
From: issues at jboss.org (Yeray Borges (JIRA))
Date: Fri, 26 Jan 2018 06:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9403) Unable to deploy clustered
 ejb in a mixed domain.
In-Reply-To: <JIRA.12714113.1506716604000@Atlassian.JIRA>
References: <JIRA.12714113.1506716604000@Atlassian.JIRA>
	<JIRA.12714113.1506716604000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12714113.1506716604000.104419.1516966080230@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9403?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Yeray Borges updated WFLY-9403:
-------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly/pull/10676, https://github.com/wildfly/wildfly/pull/10797  (was: https://github.com/wildfly/wildfly/pull/10676)


> Unable to deploy clustered ejb in a mixed domain.
> -------------------------------------------------
>
>                 Key: WFLY-9403
>                 URL: https://issues.jboss.org/browse/WFLY-9403
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, EJB
>    Affects Versions: 11.0.0.CR1
>            Reporter: Brad Maxwell
>            Assignee: Yeray Borges
>             Fix For: 12.0.0.Alpha1
>
>         Attachments: Clusterejb-0.0.1.jar, domain_EAP7.xml, host_EAP7.xml, host_slave_EAP6.xml
>
>
> Using a ha profile in a mixed domain( i.e EAP 7 as a domain controler and EAP 6.3 as a slave) it does not seem possible to deploy ejb successfully. 
> While deploying a simple @clustered ejb on EAP 6.3 server below exception was thrown. This issue is easily replicated.
> {code:java}
> 19:12:11,886 INFO  [org.jboss.as.ejb3.deployment.processors.EjbJndiBindingsDeploymentUnitProcessor] (MSC service thread 1-16) JNDI bindings for session bean named CounterBean in deployment unit deployment "Clusterejb-0.0.1.jar" are as follows:
>     java:global/Clusterejb-0.0.1/CounterBean!com.test.Counter
>     java:app/Clusterejb-0.0.1/CounterBean!com.test.Counter
>     java:module/CounterBean!com.test.Counter
>     java:jboss/exported/Clusterejb-0.0.1/CounterBean!com.test.Counter
>     java:global/Clusterejb-0.0.1/CounterBean
>     java:app/Clusterejb-0.0.1/CounterBean
>     java:module/CounterBean
> 19:12:12,089 INFO  [org.jboss.as.server] (Controller Boot Thread) JBAS018559: Deployed "Clusterejb-0.0.1.jar" (runtime-name : "Clusterejb-0.0.1.jar")
> 19:12:12,090 INFO  [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014775:    New missing/unsatisfied dependencies:
>       service jboss.ejb.cache.cluster.simple (missing) dependents: [service jboss.ejb.cache.cluster]
> 19:12:12,093 ERROR [org.jboss.as] (Controller Boot Thread) JBAS015875: JBoss EAP 6.3.0.GA (AS 7.4.0.Final-redhat-19) started (with errors) in 2654ms - Started 185 of 293 services (14 services failed or missing dependencies, 117 services are lazy, passive or on-demand)
> {code}
> I have attached the configuration files for both EAP 7 and EAP 6. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 07:29:00 2018
From: issues at jboss.org (Katerina Novotna (JIRA))
Date: Fri, 26 Jan 2018 07:29:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3553) Improve message from CLI
 when writing into the directory without permission
In-Reply-To: <JIRA.12731011.1516969707000@Atlassian.JIRA>
References: <JIRA.12731011.1516969707000@Atlassian.JIRA>
	<JIRA.12731011.1516969707407@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731011.1516969707000.104976.1516969740224@Atlassian.JIRA>

Katerina Novotna created WFCORE-3553:
----------------------------------------

             Summary: Improve message from CLI when writing into the directory without permission
                 Key: WFCORE-3553
                 URL: https://issues.jboss.org/browse/WFCORE-3553
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
    Affects Versions: 4.0.0.Alpha6
            Reporter: Katerina Novotna
            Assignee: Jean-Francois Denise
            Priority: Minor


*Description of problem:*
Cli displays java exception name when trying to write into the file without permission.

*Actual results:*
[standalone at embedded /] echo aaa > /dir/without/permission
java.nio.file.AccessDeniedException: /dir/without/permission

*Expected results:*
[standalone at embedded /] echo aaa > /dir/without/permission
Couldn't write into the /dir/without/permission. Permission denied.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 07:56:01 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 26 Jan 2018 07:56:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9067) Clean JASPIC Implementation
 with WildFly Elytron
In-Reply-To: <JIRA.12701188.1499696778000@Atlassian.JIRA>
References: <JIRA.12701188.1499696778000@Atlassian.JIRA>
	<JIRA.12701188.1499696778000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12701188.1499696778000.105262.1516971361266@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9067?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Darran Lofthouse updated WFLY-9067:
-----------------------------------
    Description: 
This may be broken down into smaller steps but initially this is the main integration.

h3. Analysis Document: -
https://developer.jboss.org/docs/DOC-56012

  was:
This may be broken down into smaller steps but initially this is the parent tracking task of the feature.

h3. Analysis Document: -
https://developer.jboss.org/docs/DOC-56012



> Clean JASPIC Implementation with WildFly Elytron
> ------------------------------------------------
>
>                 Key: WFLY-9067
>                 URL: https://issues.jboss.org/browse/WFLY-9067
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 12.0.0.Alpha1
>
>
> This may be broken down into smaller steps but initially this is the main integration.
> h3. Analysis Document: -
> https://developer.jboss.org/docs/DOC-56012



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 07:58:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 26 Jan 2018 07:58:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9737) JASPIC LoginModule Profile
 with WildFly Elytron
In-Reply-To: <JIRA.12731017.1516971438000@Atlassian.JIRA>
References: <JIRA.12731017.1516971438000@Atlassian.JIRA>
	<JIRA.12731017.1516971438374@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731017.1516971438000.105270.1516971480427@Atlassian.JIRA>

Darran Lofthouse created WFLY-9737:
--------------------------------------

             Summary: JASPIC LoginModule Profile with WildFly Elytron
                 Key: WFLY-9737
                 URL: https://issues.jboss.org/browse/WFLY-9737
             Project: WildFly
          Issue Type: Feature Request
          Components: Security
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 12.0.0.Alpha1


The JASPIC specification covers the use of LoginModules under a separate profile, once WFLY-9067 is integrated this is a follow up task to add support for this profile.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 08:00:00 2018
From: issues at jboss.org (Katerina Novotna (JIRA))
Date: Fri, 26 Jan 2018 08:00:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3554) Append the content to the
 file with name tmp|file results to 'tmp\|file' being created
In-Reply-To: <JIRA.12731018.1516971580000@Atlassian.JIRA>
References: <JIRA.12731018.1516971580000@Atlassian.JIRA>
	<JIRA.12731018.1516971580006@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731018.1516971580000.105283.1516971600480@Atlassian.JIRA>

Katerina Novotna created WFCORE-3554:
----------------------------------------

             Summary: Append the content to the file with name tmp|file results to 'tmp\|file' being created
                 Key: WFCORE-3554
                 URL: https://issues.jboss.org/browse/WFCORE-3554
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Katerina Novotna
            Assignee: Jean-Francois Denise


*Description of problem:*
Append the content to the file with name tmp|file results to 'tmp\|file' being created.

*Actual results:*
[standalone at embedded /] version >> tmp\|file
The file created is named 'tmp\|file'

*Expected results:*
The file created is named 'tmp|file'



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 08:04:00 2018
From: issues at jboss.org (Katerina Novotna (JIRA))
Date: Fri, 26 Jan 2018 08:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3555) Pipe with echo commad gives
 incorrect result
In-Reply-To: <JIRA.12731019.1516971817000@Atlassian.JIRA>
References: <JIRA.12731019.1516971817000@Atlassian.JIRA>
	<JIRA.12731019.1516971817705@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731019.1516971817000.105297.1516971840176@Atlassian.JIRA>

Katerina Novotna created WFCORE-3555:
----------------------------------------

             Summary: Pipe with echo commad gives incorrect result
                 Key: WFCORE-3555
                 URL: https://issues.jboss.org/browse/WFCORE-3555
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Katerina Novotna
            Assignee: Jean-Francois Denise


*Description of problem:*
When putting 'echo' into the right side of the pipe. Addional 'o' is displayed as result.

*Actual results:*
[standalone at embedded /] version | echo test
o test

*Expected results:*
[standalone at embedded /] version | echo test
test




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 08:09:00 2018
From: issues at jboss.org (Darran Lofthouse (JIRA))
Date: Fri, 26 Jan 2018 08:09:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1504) Support Elytron specific
 callbacks with JASPIC ServerAuthenticationModules
In-Reply-To: <JIRA.12731020.1516972119000@Atlassian.JIRA>
References: <JIRA.12731020.1516972119000@Atlassian.JIRA>
	<JIRA.12731020.1516972119263@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731020.1516972119000.105311.1516972140457@Atlassian.JIRA>

Darran Lofthouse created ELY-1504:
-------------------------------------

             Summary: Support Elytron specific callbacks with JASPIC ServerAuthenticationModules
                 Key: ELY-1504
                 URL: https://issues.jboss.org/browse/ELY-1504
             Project: WildFly Elytron
          Issue Type: Feature Request
            Reporter: Darran Lofthouse
            Assignee: Darran Lofthouse
             Fix For: 1.2.0.Beta14


JASPIC already supports the use of a CallbackHandler for communication between the ServerAuthenticationModule and the container the first stage of implementation is to support the callbacks mandated by the spec - this task is to follow up and add support for Elytron specific callbacks.

The reason to split this out is we may still want to handle our core lifecycle related callbacks so of the remaining callbacks we will need to decide which ones we want to support.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 08:10:00 2018
From: issues at jboss.org (Katerina Novotna (JIRA))
Date: Fri, 26 Jan 2018 08:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3556) Unexpected output with grep
 '^no\(fork\|group\)'
In-Reply-To: <JIRA.12731021.1516972192000@Atlassian.JIRA>
References: <JIRA.12731021.1516972192000@Atlassian.JIRA>
	<JIRA.12731021.1516972192642@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731021.1516972192000.105316.1516972200678@Atlassian.JIRA>

Katerina Novotna created WFCORE-3556:
----------------------------------------

             Summary: Unexpected output with grep '^no\(fork\|group\)'
                 Key: WFCORE-3556
                 URL: https://issues.jboss.org/browse/WFCORE-3556
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Katerina Novotna
            Assignee: Jean-Francois Denise


*Description of problem:*
Aesh grep command doesn't return expected result. The same command with bash grep gives 'nofork' result.

*Actual results:*
[standalone at embedded /] echo nofork | grep '^no\(fork\|group\)'
[standalone at embedded /] 

*Expected results:*
[standalone at embedded /] echo nofork | grep '^no\(fork\|group\)'
[standalone at embedded /] nofork



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 08:13:01 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Fri, 26 Jan 2018 08:13:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3557) Upgrade Wildfly Common to
	1.3.0.Final
In-Reply-To: <JIRA.12731022.1516972355000@Atlassian.JIRA>
References: <JIRA.12731022.1516972355000@Atlassian.JIRA>
	<JIRA.12731022.1516972355926@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731022.1516972355000.105342.1516972381868@Atlassian.JIRA>

Richard Opalka created WFCORE-3557:
--------------------------------------

             Summary: Upgrade Wildfly Common to 1.3.0.Final
                 Key: WFCORE-3557
                 URL: https://issues.jboss.org/browse/WFCORE-3557
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: Richard Opalka
            Assignee: Richard Opalka
             Fix For: 4.0.0.Alpha7






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 08:14:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Fri, 26 Jan 2018 08:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3558) Upgrade JBoss Threads to
	2.3.0.Final
In-Reply-To: <JIRA.12731023.1516972437000@Atlassian.JIRA>
References: <JIRA.12731023.1516972437000@Atlassian.JIRA>
	<JIRA.12731023.1516972437445@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731023.1516972437000.105364.1516972440396@Atlassian.JIRA>

Richard Opalka created WFCORE-3558:
--------------------------------------

             Summary: Upgrade JBoss Threads to 2.3.0.Final
                 Key: WFCORE-3558
                 URL: https://issues.jboss.org/browse/WFCORE-3558
             Project: WildFly Core
          Issue Type: Component Upgrade
            Reporter: Richard Opalka
            Assignee: Richard Opalka
             Fix For: 4.0.0.Alpha7






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 08:25:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Fri, 26 Jan 2018 08:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3558) Upgrade JBoss Threads to
	2.3.0.Final
In-Reply-To: <JIRA.12731023.1516972437000@Atlassian.JIRA>
References: <JIRA.12731023.1516972437000@Atlassian.JIRA>
	<JIRA.12731023.1516972437000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731023.1516972437000.105401.1516973100156@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reassigned WFCORE-3558:
--------------------------------------

    Assignee: David Lloyd  (was: Richard Opalka)


> Upgrade JBoss Threads to 2.3.0.Final
> ------------------------------------
>
>                 Key: WFCORE-3558
>                 URL: https://issues.jboss.org/browse/WFCORE-3558
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>             Fix For: 4.0.0.Alpha7
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 08:26:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Fri, 26 Jan 2018 08:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3557) Upgrade Wildfly Common to
	1.3.0.Final
In-Reply-To: <JIRA.12731022.1516972356000@Atlassian.JIRA>
References: <JIRA.12731022.1516972356000@Atlassian.JIRA>
	<JIRA.12731022.1516972356000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731022.1516972356000.105403.1516973160387@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reassigned WFCORE-3557:
--------------------------------------

    Assignee: David Lloyd  (was: Richard Opalka)


> Upgrade Wildfly Common to 1.3.0.Final
> -------------------------------------
>
>                 Key: WFCORE-3557
>                 URL: https://issues.jboss.org/browse/WFCORE-3557
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>             Fix For: 4.0.0.Alpha7
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 08:26:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Fri, 26 Jan 2018 08:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3552) Upgrade JBoss MSC to
	1.3.0.Final
In-Reply-To: <JIRA.12730967.1516960376000@Atlassian.JIRA>
References: <JIRA.12730967.1516960376000@Atlassian.JIRA>
	<JIRA.12730967.1516960376000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730967.1516960376000.105406.1516973160458@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Richard Opalka reassigned WFCORE-3552:
--------------------------------------

    Assignee: David Lloyd  (was: Richard Opalka)


> Upgrade JBoss MSC to 1.3.0.Final
> --------------------------------
>
>                 Key: WFCORE-3552
>                 URL: https://issues.jboss.org/browse/WFCORE-3552
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 08:57:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Fri, 26 Jan 2018 08:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-170) Transition the still useful
 parts of JBoss Negotiation into Elytron
In-Reply-To: <JIRA.12567097.1427457395000@Atlassian.JIRA>
References: <JIRA.12567097.1427457395000@Atlassian.JIRA>
	<JIRA.12567097.1427457395000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12567097.1427457395000.105632.1516975020528@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-170?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reopened ELY-170:
----------------------------


Still needed, as noted by Darran:
the useful part really relates to the *jboss-negotiation-toolkit* for *debugging / testing a new installation*.??Maybe it doesn't need to live in Elytron itself and we could move it into our samples repo in the incubator but having an easy deployment to test SPNEGO set ups I think over the years has been worthwhile.

> Transition the still useful parts of JBoss Negotiation into Elytron
> -------------------------------------------------------------------
>
>                 Key: ELY-170
>                 URL: https://issues.jboss.org/browse/ELY-170
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: Utils
>            Reporter: Darran Lofthouse
>             Fix For: 1.2.0.Beta12
>
>
> Generally JBoss Negotiation should be obsolete, however some portions may be useful to be included in Elytron e.g. the SPNEGO parsing so that we can display some meaningful diagnostics.
> By the time we reach the end of WildFly 10 nothing should require a direct dependency on JBoss Negotiation and really it should be removed from the application server distribution.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Fri Jan 26 09:53:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Fri, 26 Jan 2018 09:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9738) Extend
 org.jboss.as.clustering.controller.CredentialSourceDependency to support
 LifecycleListener in MSC 1.3
In-Reply-To: <JIRA.12731051.1516978353000@Atlassian.JIRA>
References: <JIRA.12731051.1516978353000@Atlassian.JIRA>
	<JIRA.12731051.1516978353375@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731051.1516978353000.106481.1516978380862@Atlassian.JIRA>

David Lloyd created WFLY-9738:
---------------------------------

             Summary: Extend org.jboss.as.clustering.controller.CredentialSourceDependency to support LifecycleListener in MSC 1.3
                 Key: WFLY-9738
                 URL: https://issues.jboss.org/browse/WFLY-9738
             Project: WildFly
          Issue Type: Task
          Components: Clustering
            Reporter: David Lloyd
            Assignee: David Lloyd
             Fix For: 12.0.0.Alpha1






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 10:04:00 2018
From: issues at jboss.org (Fedor Gavrilov (JIRA))
Date: Fri, 26 Jan 2018 10:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1770) More FEEL runtime cycle
	detection tests
In-Reply-To: <JIRA.12717263.1508421834000@Atlassian.JIRA>
References: <JIRA.12717263.1508421834000@Atlassian.JIRA>
	<JIRA.12717263.1508421834000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12717263.1508421834000.106522.1516979040106@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1770?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Fedor Gavrilov resolved DROOLS-1770.
------------------------------------
    Resolution: Done


> More FEEL runtime cycle detection tests
> ---------------------------------------
>
>                 Key: DROOLS-1770
>                 URL: https://issues.jboss.org/browse/DROOLS-1770
>             Project: Drools
>          Issue Type: Enhancement
>          Components: dmn engine
>    Affects Versions: 7.4.1.Final
>            Reporter: Fedor Gavrilov
>            Assignee: Fedor Gavrilov
>            Priority: Minor
>
> Runtime cycle detecton lacks tests for false positive, such as deadly diamond topology:
> A depends on B and C
> B and C depend on D



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 10:41:01 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 26 Jan 2018 10:41:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3559) FilePermissionTestCase
 permission checking issue
In-Reply-To: <JIRA.12731059.1516981234000@Atlassian.JIRA>
References: <JIRA.12731059.1516981234000@Atlassian.JIRA>
	<JIRA.12731059.1516981234639@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731059.1516981234000.106796.1516981261951@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-3559:
--------------------------------------------

             Summary: FilePermissionTestCase permission checking issue
                 Key: WFCORE-3559
                 URL: https://issues.jboss.org/browse/WFCORE-3559
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI, Test Suite
            Reporter: Jean-Francois Denise
            Assignee: Katerina Novotna


On my mac laptop the test is failing with:
testFileDefaultPermissions(org.jboss.as.test.integration.management.cli.FilePermissionTestCase)  Time elapsed: 1.273 sec  <<< FAILURE!
java.lang.AssertionError: The test file has unexpected permissions: rw-r--r--
Expected: is "rw-rw-r--"
     but: was "rw-r--r--"
	at org.hamcrest.MatcherAssert.assertThat(MatcherAssert.java:20)
	at org.jboss.as.test.integration.management.cli.FilePermissionTestCase.testFileDefaultPermissions(FilePermissionTestCase.java:102)

My mask could make the files to be created with these permissions, do we really want to check that?




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 11:57:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 26 Jan 2018 11:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3554) Append the content to the
 file with name tmp|file results to 'tmp\|file' being created
In-Reply-To: <JIRA.12731018.1516971580000@Atlassian.JIRA>
References: <JIRA.12731018.1516971580000@Atlassian.JIRA>
	<JIRA.12731018.1516971580000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731018.1516971580000.107427.1516985820445@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3554?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3554:
-------------------------------------
    Description: 
*Description of problem:*
Append the content to the file with name tmp|file results to 'tmp\|file' being created.

*Actual results:*
{code}
[standalone at embedded /] version >> tmp\|file
The file created is named 'tmp\|file'
{code}

*Expected results:*
{code}
The file created is named 'tmp|file'
{code}

  was:
*Description of problem:*
Append the content to the file with name tmp|file results to 'tmp\|file' being created.

*Actual results:*
[standalone at embedded /] version >> tmp\|file
The file created is named 'tmp\|file'

*Expected results:*
The file created is named 'tmp|file'



> Append the content to the file with name tmp|file results to 'tmp\|file' being created
> --------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3554
>                 URL: https://issues.jboss.org/browse/WFCORE-3554
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Katerina Novotna
>            Assignee: Jean-Francois Denise
>
> *Description of problem:*
> Append the content to the file with name tmp|file results to 'tmp\|file' being created.
> *Actual results:*
> {code}
> [standalone at embedded /] version >> tmp\|file
> The file created is named 'tmp\|file'
> {code}
> *Expected results:*
> {code}
> The file created is named 'tmp|file'
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 14:01:00 2018
From: issues at jboss.org (Sayed Abdul (JIRA))
Date: Fri, 26 Jan 2018 14:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-783) Error migrating repository
 from 5.x to 6.2
In-Reply-To: <JIRA.12571726.1431611367000@Atlassian.JIRA>
References: <JIRA.12571726.1431611367000@Atlassian.JIRA>
	<JIRA.12571726.1431611367000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571726.1431611367000.107919.1516993260349@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524870#comment-13524870 ] 

Sayed Abdul commented on DROOLS-783:
------------------------------------

Hi Team,
I have a similar assignment to migrate drools 5.0.0 to any latest Guvnor compatible with jboss eap 6.4.
1.I am considering 6.5.0 as the drools version.please suggest if it's fine.
2.Also let me please know if the migration tool supports this migration.

Best regards

> Error migrating repository from 5.x to 6.2
> ------------------------------------------
>
>                 Key: DROOLS-783
>                 URL: https://issues.jboss.org/browse/DROOLS-783
>             Project: Drools
>          Issue Type: Bug
>          Components: tools
>    Affects Versions: 6.2.0.Final
>         Environment: Linux 3.8.13-55.1.5.el6uek.x86_64 #2 SMP Wed Jan 28 17:03:28 PST 2015 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Pierangelo Repetti
>            Assignee: Jan Schatteman
>         Attachments: guvnor-jcr2vfs-migration.git.zip, repository_export.zip, rules.zip, runMigration.log, stderr.out
>
>
> The migration of a rules repository from Guvnor 5.x to KIE WB shows the following error
> java.io.FileNotFoundException: File modules.xml not found
> during the JCR import phase.
> Detail:
> Jcr import started. Reading from import directory ({/home/ecs/brain/migration/drools-wb-jcr2vfs-distribution-6.2.0.Final/bin/tmp-jcr2vfs}).
>   Category import started
>   Category import ended
>   Module import started
> java.io.FileNotFoundException: File modules.xml not found
> 	at org.drools.workbench.jcr2vfsmigration.common.FileManager.getFile(FileManager.java:163)
> 	at org.drools.workbench.jcr2vfsmigration.common.FileManager.getModulesExportFile(FileManager.java:54)
> 	at org.drools.workbench.jcr2vfsmigration.common.FileManager$Proxy$_$$_WeldClientProxy.getModulesExportFile(FileManager$Proxy$_$$_WeldClientProxy.java)
> 	at org.drools.workbench.jcr2vfsmigration.vfsImport.ModuleAssetImporter.importAll(ModuleAssetImporter.java:114)
> 	at org.drools.workbench.jcr2vfsmigration.vfsImport.ModuleAssetImporter$Proxy$_$$_WeldClientProxy.importAll(ModuleAssetImporter$Proxy$_$$_WeldClientProxy.java)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporter.importAll(VfsImporter.java:80)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporter$Proxy$_$$_WeldClientProxy.importAll(VfsImporter$Proxy$_$$_WeldClientProxy.java)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.launchImport(VfsImporterLauncher.java:57)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.run(VfsImporterLauncher.java:49)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.main(VfsImporterLauncher.java:34)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 14:04:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 26 Jan 2018 14:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3375) Upgrade jboss-logmanager
 from 2.1.0.Alpha5 to 2.1.0.Alpha6
In-Reply-To: <JIRA.12717310.1508430469000@Atlassian.JIRA>
References: <JIRA.12717310.1508430469000@Atlassian.JIRA>
	<JIRA.12717310.1508430469000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12717310.1508430469000.107930.1516993440298@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins closed WFCORE-3375.
---------------------------------
    Resolution: Deferred


In WFCORE-3549 we're downgrading back to a final version. 

> Upgrade jboss-logmanager from 2.1.0.Alpha5 to 2.1.0.Alpha6
> ----------------------------------------------------------
>
>                 Key: WFCORE-3375
>                 URL: https://issues.jboss.org/browse/WFCORE-3375
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Logging
>    Affects Versions: 3.0.9.Final
>            Reporter: James Perkins
>            Assignee: James Perkins
>              Labels: downstream_dependency
>
> The {{org.jboss.logmanager:jboss-logmanager:2.1.0.Alpha6}} will introduce a new {{CallerClassLoaderLogContextListener}} which needs to be used to ensure that modules don't create loggers on a deployments log context.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 14:04:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 26 Jan 2018 14:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3549) Drop back to a final
 version of jboss-logmanager 2.0.9.Final
In-Reply-To: <JIRA.12730830.1516897199000@Atlassian.JIRA>
References: <JIRA.12730830.1516897199000@Atlassian.JIRA>
	<JIRA.12730830.1516897199000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730830.1516897199000.107934.1516993440590@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3549?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

James Perkins updated WFCORE-3549:
----------------------------------
    Summary: Drop back to a final version of jboss-logmanager 2.0.9.Final  (was: Drop back to a final version of jboss-logmanager)


> Drop back to a final version of jboss-logmanager 2.0.9.Final
> ------------------------------------------------------------
>
>                 Key: WFCORE-3549
>                 URL: https://issues.jboss.org/browse/WFCORE-3549
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>          Components: Logging
>            Reporter: James Perkins
>            Assignee: James Perkins
>            Priority: Blocker
>
> Components in WildFly should generally always be final. There was an upgrade to {{org.jboss.logmanager:jboss-logmanager}} to allow for a {{json-formatter}} PR to be done. This should be done in a topic branch and the log manager upgrade should not be merged in until the log manager itself is final.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 15:34:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 26 Jan 2018 15:34:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3475) Tighten visibility on some
 AttributeDefinition fields
In-Reply-To: <JIRA.12725805.1513811266000@Atlassian.JIRA>
References: <JIRA.12725805.1513811266000@Atlassian.JIRA>
	<JIRA.12725805.1513811266000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725805.1513811266000.108022.1516998840089@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3475?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3475:
-------------------------------------
    Priority: Major  (was: Minor)


> Tighten visibility on some AttributeDefinition fields
> -----------------------------------------------------
>
>                 Key: WFCORE-3475
>                 URL: https://issues.jboss.org/browse/WFCORE-3475
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>
> AttributeDefinition and some subclasses in the controller module have some fields that are not private. This will make it problematic to evolve the management code in the future. Deprecate any that are protected, with a note to use the getter, and make package protected ones private.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 15:39:01 2018
From: issues at jboss.org (Sayed Abdul (JIRA))
Date: Fri, 26 Jan 2018 15:39:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-783) Error migrating repository
 from 5.x to 6.2
In-Reply-To: <JIRA.12571726.1431611367000@Atlassian.JIRA>
References: <JIRA.12571726.1431611367000@Atlassian.JIRA>
	<JIRA.12571726.1431611367000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571726.1431611367000.108045.1516999141209@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524870#comment-13524870 ] 

Sayed Abdul edited comment on DROOLS-783 at 1/26/18 3:38 PM:
-------------------------------------------------------------

Hi Team,
Please help to migrate drools 5.0.0 to any latest Guvnor compatible with jboss eap 6.4.
1.I am considering 6.5.0 as the drools version.please suggest if it's fine.
2.Also let me please know if the migration tool supports this migration.
- ----------------------------
i am getting below error with the sample repo attached in this ticket.
 repository.xml doeesn't exist, so i renamed the file and getting below errors:

1)01:52:06.624 [main] WARN  o.a.j.c.c.ConfigurationErrorHandler - Warning parsing the configuration at line 1 using system id file:/C:/../drools-wb-jcr2vfs-distribution-6.5.0.Final/drools-wb-jcr2vfs-distribution-6.5.0.Final/migration/repository_export/repository.xml: org.xml.sax.SAXParseException; systemId: file:/C:/../..../drools-wb-jcr2vfs-distribution-6.5.0.Final/drools-wb-jcr2vfs-distribution-6.5.0.Final/migration/repository_export/repository.xml; lineNumber: 1; columnNumber: 470; Document root element "sv:node", must match DOCTYPE root "null".
01:52:06.624 [main] WARN  o.a.j.c.c.ConfigurationErrorHandler - Warning parsing the configuration at line 1 using system id file:/C:/Users/../drools-wb-jcr2vfs-distribution-6.5.0.Final/drools-wb-jcr2vfs-distribution-6.5.0.Final/migration/repository_export/repository.xml: org.xml.sax.SAXParseException; systemId: file:/C:/../../drools-wb-jcr2vfs-distribution-6.5.0.Final/drools-wb-jcr2vfs-distribution-6.5.0.Final/migration/repository_export/repository.xml; lineNumber: 1; columnNumber: 470; Document is invalid: no grammar found.
.
org.jboss.weld.exceptions.WeldException: WELD-000049 Unable to invoke [method] @PostConstruct public org.drools.guvnor.server.repository.RepositoryStartupService.create() on org.drools.guvnor.server.repository.ProductionRepositoryStartupService at 13c3543
        at org.jboss.weld.bean.AbstractClassBean.defaultPostConstruct(AbstractClassBean.java:400)
        at org.jboss.weld.bean.ManagedBean$ManagedBeanInjectionTarget.postConstruct(ManagedBean.java:174)
        at org.jboss.weld.bean.ManagedBean.create(ManagedBean.java:294)
        at org.jboss.weld.context.AbstractContext.get(AbstractContext.java:107)
        at org.jboss.weld.bean.proxy.ContextBeanInstance.getInstance(ContextBeanInstance.java:90)
        at org.jboss.weld.bean.proxy.ProxyMethodHandler.invoke(ProxyMethodHandler.java:79)
        at org.drools.guvnor.server.repository.ProductionRepositoryStartupService$Proxy$_$$_WeldClientProxy.newSession(ProductionRepositoryStartupService$Proxy$_$$_WeldClientProxy.java)
2)Caused by: org.drools.repository.RulesRepositoryException: javax.jcr.RepositoryException: Invalid repository configuration file:
3)INFO  VFS import started. Reading from import directory C:\..\.\drools-wb-jcr2vfs-distribution-6.5.0.Final\drools-wb-jcr2vfs-distribution-6.5.0.Final\bin\tmp-jcr2vfs.
INFO    Module import started
java.io.FileNotFoundException: File modules.xml not found
        at org.drools.workbench.jcr2vfsmigration.common.FileManager.getFile(FileManager.java:167)
        at org.drools.workbench.jcr2vfsmigration.common.FileManager.getModulesExportFile(FileManager.java:58)
        at org.drools.workbench.jcr2vfsmigration.common.FileManager$Proxy$_$$_WeldClientProxy.getModulesExportFile(FileManager$Proxy$_$$_WeldClientProxy.java)
        at org.drools.workbench.jcr2vfsmigration.vfsImport.ModuleAssetImporter.importAll(ModuleAssetImporter.java:123)
        at org.drools.workbench.jcr2vfsmigration.vfsImport.ModuleAssetImporter$Proxy$_$$_WeldClientProxy.importAll(ModuleAssetImporter$Proxy$_$$_WeldClientProxy.java)
        at org.drools.workbench.jcr2vfsmigration.VfsImporter.importAll(VfsImporter.java:65)
        at org.drools.workbench.jcr2vfsmigration.VfsImporter$Proxy$_$$_WeldClientProxy.importAll(VfsImporter$Proxy$_$$_WeldClientProxy.java)
        at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.launchImport(VfsImporterLauncher.java:56)
        at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.run(VfsImporterLauncher.java:48)
        at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.main(VfsImporterLauncher.java:33)
INFO    Module import ended

Thanks


was (Author: sayed):
Hi Team,
I have a similar assignment to migrate drools 5.0.0 to any latest Guvnor compatible with jboss eap 6.4.
1.I am considering 6.5.0 as the drools version.please suggest if it's fine.
2.Also let me please know if the migration tool supports this migration.

Best regards

> Error migrating repository from 5.x to 6.2
> ------------------------------------------
>
>                 Key: DROOLS-783
>                 URL: https://issues.jboss.org/browse/DROOLS-783
>             Project: Drools
>          Issue Type: Bug
>          Components: tools
>    Affects Versions: 6.2.0.Final
>         Environment: Linux 3.8.13-55.1.5.el6uek.x86_64 #2 SMP Wed Jan 28 17:03:28 PST 2015 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Pierangelo Repetti
>            Assignee: Jan Schatteman
>         Attachments: guvnor-jcr2vfs-migration.git.zip, repository_export.zip, rules.zip, runMigration.log, stderr.out
>
>
> The migration of a rules repository from Guvnor 5.x to KIE WB shows the following error
> java.io.FileNotFoundException: File modules.xml not found
> during the JCR import phase.
> Detail:
> Jcr import started. Reading from import directory ({/home/ecs/brain/migration/drools-wb-jcr2vfs-distribution-6.2.0.Final/bin/tmp-jcr2vfs}).
>   Category import started
>   Category import ended
>   Module import started
> java.io.FileNotFoundException: File modules.xml not found
> 	at org.drools.workbench.jcr2vfsmigration.common.FileManager.getFile(FileManager.java:163)
> 	at org.drools.workbench.jcr2vfsmigration.common.FileManager.getModulesExportFile(FileManager.java:54)
> 	at org.drools.workbench.jcr2vfsmigration.common.FileManager$Proxy$_$$_WeldClientProxy.getModulesExportFile(FileManager$Proxy$_$$_WeldClientProxy.java)
> 	at org.drools.workbench.jcr2vfsmigration.vfsImport.ModuleAssetImporter.importAll(ModuleAssetImporter.java:114)
> 	at org.drools.workbench.jcr2vfsmigration.vfsImport.ModuleAssetImporter$Proxy$_$$_WeldClientProxy.importAll(ModuleAssetImporter$Proxy$_$$_WeldClientProxy.java)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporter.importAll(VfsImporter.java:80)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporter$Proxy$_$$_WeldClientProxy.importAll(VfsImporter$Proxy$_$$_WeldClientProxy.java)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.launchImport(VfsImporterLauncher.java:57)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.run(VfsImporterLauncher.java:49)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.main(VfsImporterLauncher.java:34)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 15:56:00 2018
From: issues at jboss.org (Jan Schatteman (JIRA))
Date: Fri, 26 Jan 2018 15:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-783) Error migrating repository
 from 5.x to 6.2
In-Reply-To: <JIRA.12571726.1431611367000@Atlassian.JIRA>
References: <JIRA.12571726.1431611367000@Atlassian.JIRA>
	<JIRA.12571726.1431611367000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12571726.1431611367000.108062.1517000160373@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-783?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Schatteman reassigned DROOLS-783:
-------------------------------------

    Assignee: Edson Tirelli  (was: Jan Schatteman)


> Error migrating repository from 5.x to 6.2
> ------------------------------------------
>
>                 Key: DROOLS-783
>                 URL: https://issues.jboss.org/browse/DROOLS-783
>             Project: Drools
>          Issue Type: Bug
>          Components: tools
>    Affects Versions: 6.2.0.Final
>         Environment: Linux 3.8.13-55.1.5.el6uek.x86_64 #2 SMP Wed Jan 28 17:03:28 PST 2015 x86_64 x86_64 x86_64 GNU/Linux
>            Reporter: Pierangelo Repetti
>            Assignee: Edson Tirelli
>         Attachments: guvnor-jcr2vfs-migration.git.zip, repository_export.zip, rules.zip, runMigration.log, stderr.out
>
>
> The migration of a rules repository from Guvnor 5.x to KIE WB shows the following error
> java.io.FileNotFoundException: File modules.xml not found
> during the JCR import phase.
> Detail:
> Jcr import started. Reading from import directory ({/home/ecs/brain/migration/drools-wb-jcr2vfs-distribution-6.2.0.Final/bin/tmp-jcr2vfs}).
>   Category import started
>   Category import ended
>   Module import started
> java.io.FileNotFoundException: File modules.xml not found
> 	at org.drools.workbench.jcr2vfsmigration.common.FileManager.getFile(FileManager.java:163)
> 	at org.drools.workbench.jcr2vfsmigration.common.FileManager.getModulesExportFile(FileManager.java:54)
> 	at org.drools.workbench.jcr2vfsmigration.common.FileManager$Proxy$_$$_WeldClientProxy.getModulesExportFile(FileManager$Proxy$_$$_WeldClientProxy.java)
> 	at org.drools.workbench.jcr2vfsmigration.vfsImport.ModuleAssetImporter.importAll(ModuleAssetImporter.java:114)
> 	at org.drools.workbench.jcr2vfsmigration.vfsImport.ModuleAssetImporter$Proxy$_$$_WeldClientProxy.importAll(ModuleAssetImporter$Proxy$_$$_WeldClientProxy.java)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporter.importAll(VfsImporter.java:80)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporter$Proxy$_$$_WeldClientProxy.importAll(VfsImporter$Proxy$_$$_WeldClientProxy.java)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.launchImport(VfsImporterLauncher.java:57)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.run(VfsImporterLauncher.java:49)
> 	at org.drools.workbench.jcr2vfsmigration.VfsImporterLauncher.main(VfsImporterLauncher.java:34)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 16:28:00 2018
From: issues at jboss.org (Eric SantAnna (JIRA))
Date: Fri, 26 Jan 2018 16:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9739) JPA / Hibernate: There is
 already an object named 'x' in the database
In-Reply-To: <JIRA.12731092.1517002048000@Atlassian.JIRA>
References: <JIRA.12731092.1517002048000@Atlassian.JIRA>
	<JIRA.12731092.1517002048578@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731092.1517002048000.108074.1517002080113@Atlassian.JIRA>

Eric SantAnna created WFLY-9739:
-----------------------------------

             Summary: JPA / Hibernate: There is already an object named 'x' in the database
                 Key: WFLY-9739
                 URL: https://issues.jboss.org/browse/WFLY-9739
             Project: WildFly
          Issue Type: Bug
          Components: JPA / Hibernate
    Affects Versions: 11.0.0.Final
         Environment: Windows 10 64 bits / Windows Server 2012 R2 64 bits
Java version: 1.8.0_151
SQL Server 2014
            Reporter: Eric SantAnna
            Assignee: Scott Marlow
         Attachments: sqljdbc4.jar, wildfly11-migration.zip

I'm getting an Exception as a warning in the server.log when a database object already exists an my persistence.xml has the property "hibernate.hbm2ddl.auto" set to "update".

This doesn't happen in my tests with 10.1.0.Final.

Appearently, despite these Exceptions, all my applications are running ok.

I saw this behaviour while I was migrating my application from JBoss 7.1.1.Final to Wildfly. I'm deciding between Wildfly 10.1 and 11.
This behaviour isn't good cause, I'm flooding the logs and it doesn't seem reliable for my manager.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 16:53:00 2018
From: issues at jboss.org (Scott Marlow (JIRA))
Date: Fri, 26 Jan 2018 16:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9739) JPA / Hibernate: There is
 already an object named 'x' in the database
In-Reply-To: <JIRA.12731092.1517002049000@Atlassian.JIRA>
References: <JIRA.12731092.1517002049000@Atlassian.JIRA>
	<JIRA.12731092.1517002049000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731092.1517002049000.108183.1517003580356@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524891#comment-13524891 ] 

Scott Marlow commented on WFLY-9739:
------------------------------------

Hi, does the database contain a table called "ANIMAL"?  Or perhaps "animal"?  I'm not sure if there is a bug or not in Hibernate but it sounds like Hibernate may be getting a list of tables from JDBC DatabaseMetaData that contains "Animal" with a different case than expected.  

We will soon reject this issue, since there is no bug to fix in the WildFly project (as far as I can tell).  If there is a Hibernate bug, that can be reported via [https://hibernate.atlassian.net/browse/HHH].  

If you want to let us know the exact case of the ANIMAL table name, that could be helpful.



> JPA / Hibernate: There is already an object named 'x' in the database
> ---------------------------------------------------------------------
>
>                 Key: WFLY-9739
>                 URL: https://issues.jboss.org/browse/WFLY-9739
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 11.0.0.Final
>         Environment: Windows 10 64 bits / Windows Server 2012 R2 64 bits
> Java version: 1.8.0_151
> SQL Server 2014
>            Reporter: Eric SantAnna
>            Assignee: Scott Marlow
>         Attachments: sqljdbc4.jar, wildfly11-migration.zip
>
>
> I'm getting an Exception as a warning in the server.log when a database object already exists an my persistence.xml has the property "hibernate.hbm2ddl.auto" set to "update".
> This doesn't happen in my tests with 10.1.0.Final.
> Appearently, despite these Exceptions, all my applications are running ok.
> I saw this behaviour while I was migrating my application from JBoss 7.1.1.Final to Wildfly. I'm deciding between Wildfly 10.1 and 11.
> This behaviour isn't good cause, I'm flooding the logs and it doesn't seem reliable for my manager.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 16:55:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 26 Jan 2018 16:55:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3560) grep command doesn't close
	file
In-Reply-To: <JIRA.12731096.1517003676000@Atlassian.JIRA>
References: <JIRA.12731096.1517003676000@Atlassian.JIRA>
	<JIRA.12731096.1517003676327@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731096.1517003676000.108202.1517003700627@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-3560:
--------------------------------------------

             Summary: grep command doesn't close file
                 Key: WFCORE-3560
                 URL: https://issues.jboss.org/browse/WFCORE-3560
             Project: WildFly Core
          Issue Type: Bug
            Reporter: Jean-Francois Denise


This can be observed on windows, highlighted by the test org.jboss.as.test.integration.management.cli.GrepTestCase.testGrepWithInputFromFile
Outside tests, the file will be locked during the CLI lifetime.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 17:03:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 26 Jan 2018 17:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3560) grep command doesn't close
	file
In-Reply-To: <JIRA.12731096.1517003676000@Atlassian.JIRA>
References: <JIRA.12731096.1517003676000@Atlassian.JIRA>
	<JIRA.12731096.1517003676000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731096.1517003676000.108228.1517004180205@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise updated WFCORE-3560:
-----------------------------------------
    Component/s: CLI


> grep command doesn't close file
> -------------------------------
>
>                 Key: WFCORE-3560
>                 URL: https://issues.jboss.org/browse/WFCORE-3560
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>
> This can be observed on windows, highlighted by the test org.jboss.as.test.integration.management.cli.GrepTestCase.testGrepWithInputFromFile
> Outside tests, the file will be locked during the CLI lifetime.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 17:03:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 26 Jan 2018 17:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3560) grep command doesn't close
	file
In-Reply-To: <JIRA.12731096.1517003676000@Atlassian.JIRA>
References: <JIRA.12731096.1517003676000@Atlassian.JIRA>
	<JIRA.12731096.1517003676000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731096.1517003676000.108231.1517004180375@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3560?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise reassigned WFCORE-3560:
--------------------------------------------

    Assignee: Jean-Francois Denise


> grep command doesn't close file
> -------------------------------
>
>                 Key: WFCORE-3560
>                 URL: https://issues.jboss.org/browse/WFCORE-3560
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>
> This can be observed on windows, highlighted by the test org.jboss.as.test.integration.management.cli.GrepTestCase.testGrepWithInputFromFile
> Outside tests, the file will be locked during the CLI lifetime.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 17:06:00 2018
From: issues at jboss.org (Eric SantAnna (JIRA))
Date: Fri, 26 Jan 2018 17:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9739) JPA / Hibernate: There is
 already an object named 'x' in the database
In-Reply-To: <JIRA.12731092.1517002049000@Atlassian.JIRA>
References: <JIRA.12731092.1517002049000@Atlassian.JIRA>
	<JIRA.12731092.1517002049000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731092.1517002049000.108234.1517004360186@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524897#comment-13524897 ] 

Eric SantAnna commented on WFLY-9739:
-------------------------------------

The exact case of the created table is 'Animal'.
Thank you for point me in the right direction, I'm going report this with Hibernate.

> JPA / Hibernate: There is already an object named 'x' in the database
> ---------------------------------------------------------------------
>
>                 Key: WFLY-9739
>                 URL: https://issues.jboss.org/browse/WFLY-9739
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 11.0.0.Final
>         Environment: Windows 10 64 bits / Windows Server 2012 R2 64 bits
> Java version: 1.8.0_151
> SQL Server 2014
>            Reporter: Eric SantAnna
>            Assignee: Scott Marlow
>         Attachments: sqljdbc4.jar, wildfly11-migration.zip
>
>
> I'm getting an Exception as a warning in the server.log when a database object already exists an my persistence.xml has the property "hibernate.hbm2ddl.auto" set to "update".
> This doesn't happen in my tests with 10.1.0.Final.
> Appearently, despite these Exceptions, all my applications are running ok.
> I saw this behaviour while I was migrating my application from JBoss 7.1.1.Final to Wildfly. I'm deciding between Wildfly 10.1 and 11.
> This behaviour isn't good cause, I'm flooding the logs and it doesn't seem reliable for my manager.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 17:22:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 26 Jan 2018 17:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3561)
 testAppendCustomFileAbsoluteDirCompletition failures on windows
In-Reply-To: <JIRA.12731097.1517005267000@Atlassian.JIRA>
References: <JIRA.12731097.1517005267000@Atlassian.JIRA>
	<JIRA.12731097.1517005267435@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731097.1517005267000.108251.1517005320156@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-3561:
--------------------------------------------

             Summary: testAppendCustomFileAbsoluteDirCompletition failures on windows
                 Key: WFCORE-3561
                 URL: https://issues.jboss.org/browse/WFCORE-3561
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI, Test Suite
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


The logic to test completion candidates is failing on Windows, should be reviewed.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 17:30:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Fri, 26 Jan 2018 17:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3561)
 testAppendCustomFileAbsoluteDirCompletition failures on windows
In-Reply-To: <JIRA.12731097.1517005267000@Atlassian.JIRA>
References: <JIRA.12731097.1517005267000@Atlassian.JIRA>
	<JIRA.12731097.1517005267000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731097.1517005267000.108280.1517005800197@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3561?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jean-Francois Denise reassigned WFCORE-3561:
--------------------------------------------

    Assignee: Katerina Novotna  (was: Jean-Francois Denise)


> testAppendCustomFileAbsoluteDirCompletition failures on windows
> ---------------------------------------------------------------
>
>                 Key: WFCORE-3561
>                 URL: https://issues.jboss.org/browse/WFCORE-3561
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Test Suite
>            Reporter: Jean-Francois Denise
>            Assignee: Katerina Novotna
>
> The logic to test completion candidates is failing on Windows, should be reviewed.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 19:07:00 2018
From: issues at jboss.org (James Perkins (JIRA))
Date: Fri, 26 Jan 2018 19:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-350) Domain reflects
 jboss.server.xy properties
In-Reply-To: <JIRA.12447180.1316175858000@Atlassian.JIRA>
References: <JIRA.12447180.1316175858000@Atlassian.JIRA>
	<JIRA.12447180.1316175858000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447180.1316175858000.108352.1517011620210@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524905#comment-13524905 ] 

James Perkins commented on WFCORE-350:
--------------------------------------

Was the intention to not allow these {{jboss.server.*}} properties not to be set in domain mode? For example is passing {{-Djboss.server.log.dir=/var/logs/wildfly}} not allowed to be set in the {{JAVA_OPTS}} or {{HOST_CONTROLLER_JAVA_OPTS}}?

> Domain reflects jboss.server.xy properties
> ------------------------------------------
>
>                 Key: WFCORE-350
>                 URL: https://issues.jboss.org/browse/WFCORE-350
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Rostislav Svoboda
>            Assignee: ehsavoie Hugonnet
>            Priority: Minor
>             Fix For: 3.0.0.Alpha23
>
>
> Domain reflects jboss.server.xy properties, tested with jboss.server.log.dir property.
> The same server.log file is used for both server-one and server-two. Only file boot.log is created in  domain/servers/server-one/log and domain/servers/server-two/log directory. In my case file server.log contains log only for server-one, there is no log for server-two.
> I think jboss.server.xy properties shouldn't be reflected in domain instances.
> Even structure of https://docs.jboss.org/author/display/AS71/Command+line+parameters implies that jboss.server.xy properties are used for Standalone.
> Reproducer of my steps:
> {code}
>  rm -rf domain/servers
>  bin/domain.sh -Djboss.server.log.dir=/tmp/
>  ls -aR domain/servers/server-one/log
>  ls -aR domain/servers/server-two/log
>  ls -l /tmp/server*
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 20:04:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 26 Jan 2018 20:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-350) Domain reflects
 jboss.server.xy properties
In-Reply-To: <JIRA.12447180.1316175858000@Atlassian.JIRA>
References: <JIRA.12447180.1316175858000@Atlassian.JIRA>
	<JIRA.12447180.1316175858000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447180.1316175858000.108375.1517015040603@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524907#comment-13524907 ] 

Brian Stansberry commented on WFCORE-350:
-----------------------------------------

The intent is if you set them on the HC or PC process they have no meaningful effect, i.e. the HC/PC doesn't use them itself and doesn't pass them to its servers. An HC can control > 1 server so setting server specific settings to a common value on the HC and then having that passed in to its server means all the servers will collide. In your example you'd have multiple processes fighting over /var/logs/wildfly/server.log.

You use the /host=x/server-config=y/system-property=z resources if you want control these properties on the servers. I'm not sure but I believe you can use domain-wide, host-wide or server-group wide system-property resources for jboss.server.... props if you want, but you need to understand what processes are going to get those properties and avoid collisions.

> Domain reflects jboss.server.xy properties
> ------------------------------------------
>
>                 Key: WFCORE-350
>                 URL: https://issues.jboss.org/browse/WFCORE-350
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Rostislav Svoboda
>            Assignee: ehsavoie Hugonnet
>            Priority: Minor
>             Fix For: 3.0.0.Alpha23
>
>
> Domain reflects jboss.server.xy properties, tested with jboss.server.log.dir property.
> The same server.log file is used for both server-one and server-two. Only file boot.log is created in  domain/servers/server-one/log and domain/servers/server-two/log directory. In my case file server.log contains log only for server-one, there is no log for server-two.
> I think jboss.server.xy properties shouldn't be reflected in domain instances.
> Even structure of https://docs.jboss.org/author/display/AS71/Command+line+parameters implies that jboss.server.xy properties are used for Standalone.
> Reproducer of my steps:
> {code}
>  rm -rf domain/servers
>  bin/domain.sh -Djboss.server.log.dir=/tmp/
>  ls -aR domain/servers/server-one/log
>  ls -aR domain/servers/server-two/log
>  ls -l /tmp/server*
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Fri Jan 26 20:05:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Fri, 26 Jan 2018 20:05:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-350) Domain reflects
 jboss.server.xy properties
In-Reply-To: <JIRA.12447180.1316175858000@Atlassian.JIRA>
References: <JIRA.12447180.1316175858000@Atlassian.JIRA>
	<JIRA.12447180.1316175858000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12447180.1316175858000.108381.1517015100294@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-350?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13524907#comment-13524907 ] 

Brian Stansberry edited comment on WFCORE-350 at 1/26/18 8:04 PM:
------------------------------------------------------------------

The intent is if you set them on the HC or PC process they have no meaningful effect, i.e. the HC/PC doesn't use them itself and doesn't pass them to its servers. An HC can control > 1 server so setting server specific settings to a common value on the HC and then having that passed in to its servers means all the servers will collide. In your example you'd have multiple processes fighting over /var/logs/wildfly/server.log.

You use the /host=x/server-config=y/system-property=z resources if you want control these properties on the servers. I'm not sure but I believe you can use domain-wide, host-wide or server-group wide system-property resources for jboss.server.... props if you want, but you need to understand what processes are going to get those properties and avoid collisions.


was (Author: brian.stansberry):
The intent is if you set them on the HC or PC process they have no meaningful effect, i.e. the HC/PC doesn't use them itself and doesn't pass them to its servers. An HC can control > 1 server so setting server specific settings to a common value on the HC and then having that passed in to its server means all the servers will collide. In your example you'd have multiple processes fighting over /var/logs/wildfly/server.log.

You use the /host=x/server-config=y/system-property=z resources if you want control these properties on the servers. I'm not sure but I believe you can use domain-wide, host-wide or server-group wide system-property resources for jboss.server.... props if you want, but you need to understand what processes are going to get those properties and avoid collisions.

> Domain reflects jboss.server.xy properties
> ------------------------------------------
>
>                 Key: WFCORE-350
>                 URL: https://issues.jboss.org/browse/WFCORE-350
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Rostislav Svoboda
>            Assignee: ehsavoie Hugonnet
>            Priority: Minor
>             Fix For: 3.0.0.Alpha23
>
>
> Domain reflects jboss.server.xy properties, tested with jboss.server.log.dir property.
> The same server.log file is used for both server-one and server-two. Only file boot.log is created in  domain/servers/server-one/log and domain/servers/server-two/log directory. In my case file server.log contains log only for server-one, there is no log for server-two.
> I think jboss.server.xy properties shouldn't be reflected in domain instances.
> Even structure of https://docs.jboss.org/author/display/AS71/Command+line+parameters implies that jboss.server.xy properties are used for Standalone.
> Reproducer of my steps:
> {code}
>  rm -rf domain/servers
>  bin/domain.sh -Djboss.server.log.dir=/tmp/
>  ls -aR domain/servers/server-one/log
>  ls -aR domain/servers/server-two/log
>  ls -l /tmp/server*
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3558) Upgrade JBoss Threads to
	2.3.0.Final
In-Reply-To: <JIRA.12731023.1516972437000@Atlassian.JIRA>
References: <JIRA.12731023.1516972437000@Atlassian.JIRA>
	<JIRA.12731023.1516972437000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731023.1516972437000.108468.1517054763373@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3558:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Upgrade JBoss Threads to 2.3.0.Final
> ------------------------------------
>
>                 Key: WFCORE-3558
>                 URL: https://issues.jboss.org/browse/WFCORE-3558
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>             Fix For: 4.0.0.Alpha8
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3557) Upgrade Wildfly Common to
	1.3.0.Final
In-Reply-To: <JIRA.12731022.1516972356000@Atlassian.JIRA>
References: <JIRA.12731022.1516972356000@Atlassian.JIRA>
	<JIRA.12731022.1516972356000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731022.1516972356000.108472.1517054763707@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3557:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Upgrade Wildfly Common to 1.3.0.Final
> -------------------------------------
>
>                 Key: WFCORE-3557
>                 URL: https://issues.jboss.org/browse/WFCORE-3557
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>             Fix For: 4.0.0.Alpha8
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3542) Elytron JDBC realm password
 mapping is not consistent with underlying implementation
In-Reply-To: <JIRA.12730594.1516805741000@Atlassian.JIRA>
References: <JIRA.12730594.1516805741000@Atlassian.JIRA>
	<JIRA.12730594.1516805741000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730594.1516805741000.108479.1517054764422@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3542:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Elytron JDBC realm password mapping is not consistent with underlying implementation
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3542
>                 URL: https://issues.jboss.org/browse/WFCORE-3542
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha8
>
>
> There is no way to configure the JDBC realm to use modular crypt in WildFly, even though the underlying realm does support it.
> The problem is that the {{salt-index}} and {{itereration-count-index}} attributes should be optional, and if they not given, a value of {{-1}} should be passed to the mapper.  By omitting both of these values, the database column values will then be recognized as modular-crypt strings.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3527) Remove OSGi obsolete code
In-Reply-To: <JIRA.12729983.1516378481000@Atlassian.JIRA>
References: <JIRA.12729983.1516378481000@Atlassian.JIRA>
	<JIRA.12729983.1516378481000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729983.1516378481000.108482.1517054764710@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3527:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Remove OSGi obsolete code
> -------------------------
>
>                 Key: WFCORE-3527
>                 URL: https://issues.jboss.org/browse/WFCORE-3527
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Server
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Alpha8
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3519) Add JASPI Module
In-Reply-To: <JIRA.12729731.1516279301000@Atlassian.JIRA>
References: <JIRA.12729731.1516279301000@Atlassian.JIRA>
	<JIRA.12729731.1516279301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729731.1516279301000.108489.1517054765343@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3519:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Add JASPI Module
> ----------------
>
>                 Key: WFCORE-3519
>                 URL: https://issues.jboss.org/browse/WFCORE-3519
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha8
>
>
> (Copy from WildFly)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3457) Reduce class loading of
 Elytron subsystem
In-Reply-To: <JIRA.12724639.1513168462000@Atlassian.JIRA>
References: <JIRA.12724639.1513168462000@Atlassian.JIRA>
	<JIRA.12724639.1513168462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724639.1513168462000.108496.1517054765622@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3457:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Reduce class loading of Elytron subsystem
> -----------------------------------------
>
>                 Key: WFCORE-3457
>                 URL: https://issues.jboss.org/browse/WFCORE-3457
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha8
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3424) Replace MSC listeners with
 stability monitors
In-Reply-To: <JIRA.12721337.1510844543000@Atlassian.JIRA>
References: <JIRA.12721337.1510844543000@Atlassian.JIRA>
	<JIRA.12721337.1510844543000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721337.1510844543000.108499.1517054765760@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3424:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Replace MSC listeners with stability monitors
> ---------------------------------------------
>
>                 Key: WFCORE-3424
>                 URL: https://issues.jboss.org/browse/WFCORE-3424
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Server
>    Affects Versions: 4.0.0.Alpha2
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Alpha8
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:06 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3386) Add configuration required
 to support JASPIC to the Elytron subsystem
In-Reply-To: <JIRA.12718363.1509034738000@Atlassian.JIRA>
References: <JIRA.12718363.1509034738000@Atlassian.JIRA>
	<JIRA.12718363.1509034738000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718363.1509034738000.108506.1517054766122@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3386:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Add configuration required to support JASPIC to the Elytron subsystem
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-3386
>                 URL: https://issues.jboss.org/browse/WFCORE-3386
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha8
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:06 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3382) Further Enhance Elytron
 Permission Configuration
In-Reply-To: <JIRA.12718138.1508950408000@Atlassian.JIRA>
References: <JIRA.12718138.1508950408000@Atlassian.JIRA>
	<JIRA.12718138.1508950408000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718138.1508950408000.108514.1517054766350@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3382:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Further Enhance Elytron Permission Configuration
> ------------------------------------------------
>
>                 Key: WFCORE-3382
>                 URL: https://issues.jboss.org/browse/WFCORE-3382
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Alpha8
>
>
> This has currently been simplified to a single resource for the out of the box configuration, however this brings issues as now permissions are duplicated so modifications need to be replicated instead of to a single location.
> Finding a way for the default required permissions to be defined in one location could help eliminate the duplication.
> We could also consider going one step further and subsystems register the default permissions that should be granted.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:06 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3360) Eliminate
 org.wildfly.extension.elytron.ProviderUtil
In-Reply-To: <JIRA.12716717.1508231768000@Atlassian.JIRA>
References: <JIRA.12716717.1508231768000@Atlassian.JIRA>
	<JIRA.12716717.1508231768000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12716717.1508231768000.108521.1517054766573@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3360:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Eliminate org.wildfly.extension.elytron.ProviderUtil
> ----------------------------------------------------
>
>                 Key: WFCORE-3360
>                 URL: https://issues.jboss.org/browse/WFCORE-3360
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Alpha8
>
>
> WildFly Elytron contains a public utility class org.wildfly.security.util.ProviderUtil for the same purpose, we should use the code within WildFly Elytron and not custom code within the subsystem.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:06 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3255) Complex type
 AttributeDefinition variants don't handle ParameterCorrector properly
In-Reply-To: <JIRA.12710526.1504748362000@Atlassian.JIRA>
References: <JIRA.12710526.1504748362000@Atlassian.JIRA>
	<JIRA.12710526.1504748362000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12710526.1504748362000.108523.1517054766638@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3255:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Complex type AttributeDefinition variants don't handle ParameterCorrector properly
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-3255
>                 URL: https://issues.jboss.org/browse/WFCORE-3255
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.1.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 4.0.0.Alpha8
>
>
> If a field in a complex attribute (i.e. one that uses Object...AttributeDefinition) has a ParameterCorrector configured, that corrector never gets called. That's because only a corrector on the top level attribute gets called.
> These classes should automatically use an internal corrector that first calls any corrector configured for fields, and then, if one is present, calls any top level corrector.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:06 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3181) Review
 CustomCredentialSecurityFactoryTestCase
In-Reply-To: <JIRA.12707010.1502379745000@Atlassian.JIRA>
References: <JIRA.12707010.1502379745000@Atlassian.JIRA>
	<JIRA.12707010.1502379745000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12707010.1502379745000.108530.1517054766870@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3181:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Review CustomCredentialSecurityFactoryTestCase
> ----------------------------------------------
>
>                 Key: WFCORE-3181
>                 URL: https://issues.jboss.org/browse/WFCORE-3181
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security, Test Suite
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Alpha8
>
>
> The test case CustomCredentialSecurityFactoryTestCase appears to be testing that the 'code does what it does' rather than testing the 'code is doing what it should'.
> The test is testing a custom credential security factory can be called but the test is using HTTP Basic authentication and relying on SPNEGO authentication being triggered as this is the only mechanism that currently uses this factory.
> Should a minor change be required to the SPNEGO authentication mechanism which affects when this credential factory is called this test case could subsequently fail.
> If possible it would be better to convert this test to be a SPNEGO test and then test the behaviour of the credential security factory affects the mechanism as expected.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:07 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3167) option to filter out aged
 out patches from the patching history
In-Reply-To: <JIRA.12706634.1502219553000@Atlassian.JIRA>
References: <JIRA.12706634.1502219553000@Atlassian.JIRA>
	<JIRA.12706634.1502219553000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12706634.1502219553000.108535.1517054767047@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3167:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> option to filter out aged out patches from the patching history
> ---------------------------------------------------------------
>
>                 Key: WFCORE-3167
>                 URL: https://issues.jboss.org/browse/WFCORE-3167
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI, Patching 
>    Affects Versions: 3.0.0.Beta30
>            Reporter: Alexey Loubyansky
>            Assignee: Alexey Loubyansky
>             Fix For: 4.0.0.Alpha8
>
>
> show-history management operation (and patch history cli command) returns all the patches that have been applied to the installation even if some of them have been aged out by executing ageout-history management operation.
> In some cases it would be useful to filter out the aged out patches from the result, leaving only the patches that can actually be rolled back by a user.
> That could be achieved by adding an optional boolean parameter exclude-agedout (with default value false to preserve the current behavior) to show-history operation.
> The high level CLI command patch history could include an equivalent --exclude-agedout argument.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:07 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3107) Allow slave hosts to ignore
 missing RBAC config resources
In-Reply-To: <JIRA.12704736.1501032152000@Atlassian.JIRA>
References: <JIRA.12704736.1501032152000@Atlassian.JIRA>
	<JIRA.12704736.1501032152000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12704736.1501032152000.108537.1517054767105@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3107:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Allow slave hosts to ignore missing RBAC config resources
> ---------------------------------------------------------
>
>                 Key: WFCORE-3107
>                 URL: https://issues.jboss.org/browse/WFCORE-3107
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 4.0.0.Alpha8
>
>
> Part of parent issue whereby slaves can ignore missing RBAC constraint resources for write requests coming from the DC.
> If the DC sent the request, then the address is ok overall. So if it's missing on the slave that means the slave doesn't have that constraint registered and doesn't need to handle the op.
> This fix could possibly be backported to the 2.1.x and to EAP 6.4.x in lieu of adding transformers as part of the parent issue. In the case of 2.1.x it also allows slaves to ignore the related extension even if the code for it is present (which is only a minor benefit.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:07 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3073) Handle Shutdown via TERM
	gracefully
In-Reply-To: <JIRA.12700921.1499443726000@Atlassian.JIRA>
References: <JIRA.12700921.1499443726000@Atlassian.JIRA>
	<JIRA.12700921.1499443726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12700921.1499443726000.108547.1517054767422@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3073:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Handle Shutdown via TERM gracefully
> -----------------------------------
>
>                 Key: WFCORE-3073
>                 URL: https://issues.jboss.org/browse/WFCORE-3073
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Ben Parees
>            Assignee: Brian Stansberry
>             Fix For: 4.0.0.Alpha8
>
>
> The wildfly server currently -terminates immediately- performs a standard (non-graceful) shutdown in response to a TERM signal.  To achieve a -clean- graceful shutdown requires invoking the CLI tooling.  This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved. 
> While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
> Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:07 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3019) The bin/product.conf and
 the org.jboss.as.product:wildfly-core module should come in via an FP
In-Reply-To: <JIRA.12699548.1498596551000@Atlassian.JIRA>
References: <JIRA.12699548.1498596551000@Atlassian.JIRA>
	<JIRA.12699548.1498596551000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12699548.1498596551000.108550.1517054767497@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3019:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3019
>                 URL: https://issues.jboss.org/browse/WFCORE-3019
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Server
>            Reporter: Brian Stansberry
>            Assignee: James Perkins
>             Fix For: 4.0.0.Alpha8
>
>
> For WFLY-4692 we moved the "product" stuff out of core-feature-pack and into dist. But this means it doesn't end up in the skinny dist produced by the "build" module. Plus it makes the "dist" a kind of FP of its own.
> The stuff in dist/src/distribution should be its own FP. That one *perhaps* depends on core-feature-pack. Then build and dist use the new FP in addition to or instead of core-feature-pack.
> So, core-feature-pack is independently usable, in other dists, but our offiical build/dist, which has our official product module, picks up the new FP.
> Whether the new "product" FP depends on core-feature-pack depends on how we want to use it; i.e. can this bin/product.conf and module be used in some other flavor of dist.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:07 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2746) Move elytron management
 security tests from full to core
In-Reply-To: <JIRA.12690293.1493753754000@Atlassian.JIRA>
References: <JIRA.12690293.1493753754000@Atlassian.JIRA>
	<JIRA.12690293.1493753754000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12690293.1493753754000.108558.1517054767743@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2746:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Move elytron management security tests from full to core
> --------------------------------------------------------
>
>                 Key: WFCORE-2746
>                 URL: https://issues.jboss.org/browse/WFCORE-2746
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security, Test Suite
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Alpha8
>
>
> Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
> Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723
> There are a number of aspects to this, for which I'll create subtasks.
> Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
> -org.jboss.as.test.integration.security.perimeter.* [2]-
> -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase-
> -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
> -org.jboss.as.test.integration.security.credentialreference [2]-
> integration/elytron/
> [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
> [2] Currently using Arquillian.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:07 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:07 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2589) Eliminate MSC OPTIONAL
 dependencies usage
In-Reply-To: <JIRA.12684776.1490708029000@Atlassian.JIRA>
References: <JIRA.12684776.1490708029000@Atlassian.JIRA>
	<JIRA.12684776.1490708029000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12684776.1490708029000.108562.1517054767832@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2589:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Eliminate MSC OPTIONAL dependencies usage
> -----------------------------------------
>
>                 Key: WFCORE-2589
>                 URL: https://issues.jboss.org/browse/WFCORE-2589
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Alpha8
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:08 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2497) Convert
 *-authentication-factory resources to be child resources of security-domain
In-Reply-To: <JIRA.12678139.1487691523000@Atlassian.JIRA>
References: <JIRA.12678139.1487691523000@Atlassian.JIRA>
	<JIRA.12678139.1487691523000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678139.1487691523000.108569.1517054768035@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2497:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Convert *-authentication-factory resources to be child resources of security-domain
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-2497
>                 URL: https://issues.jboss.org/browse/WFCORE-2497
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Alpha8
>
>
> This is a good example of where child resources work.
> The authentication factory resources have a mandatory dependency on a single security domain.
> The configuration within the factory is related to it's security domain.
> There is only a single resource that can provide security domains.
> The behaviour of the parent is unaffected by the existence or configuration of the child.
> The parent and child manage their own services independently with the child's service depending on the parent's service.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:08 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2365) Review
 custom-modifiable-realm resource in Elytron subsystem
In-Reply-To: <JIRA.12651212.1474463004000@Atlassian.JIRA>
References: <JIRA.12651212.1474463004000@Atlassian.JIRA>
	<JIRA.12651212.1474463004000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651212.1474463004000.108575.1517054768228@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2365:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Review custom-modifiable-realm resource in Elytron subsystem
> ------------------------------------------------------------
>
>                 Key: WFCORE-2365
>                 URL: https://issues.jboss.org/browse/WFCORE-2365
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>             Fix For: 4.0.0.Alpha8
>
>
> See description of JBEAP-6100 for more details.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:08 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2349) Add
 RemoteManagementPermission and RemoteJMXPermission checks for remote
 clients.
In-Reply-To: <JIRA.12679810.1488466192000@Atlassian.JIRA>
References: <JIRA.12679810.1488466192000@Atlassian.JIRA>
	<JIRA.12679810.1488466192000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679810.1488466192000.108582.1517054768432@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2349:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients.
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-2349
>                 URL: https://issues.jboss.org/browse/WFCORE-2349
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Alpha8
>
>
> Other services such as EJB and transactions have a Remote*Permission to verify the remote client has the required permission to use that service - this should be repeated for the management related services to control what a remote client can and can not connect to.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:08 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2336) Remove
	ModelController.createClient
In-Reply-To: <JIRA.12679023.1488205057000@Atlassian.JIRA>
References: <JIRA.12679023.1488205057000@Atlassian.JIRA>
	<JIRA.12679023.1488205057000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679023.1488205057000.108584.1517054768485@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2336:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Remove ModelController.createClient
> -----------------------------------
>
>                 Key: WFCORE-2336
>                 URL: https://issues.jboss.org/browse/WFCORE-2336
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Alpha8
>
>
> Follow up on WFCORE-1507 by removing ModelController.createClient and any use of it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:08 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2235) Intermittent module loading
 failure in InterdependentDeploymentTestCase
In-Reply-To: <JIRA.12673068.1485365894000@Atlassian.JIRA>
References: <JIRA.12673068.1485365894000@Atlassian.JIRA>
	<JIRA.12673068.1485365894000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673068.1485365894000.108588.1517054768595@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2235:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Intermittent module loading failure in InterdependentDeploymentTestCase
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-2235
>                 URL: https://issues.jboss.org/browse/WFCORE-2235
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Modules, Server
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Brian Stansberry
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Alpha8
>
>         Attachments: WFCORE-2235svcdump.txt
>
>
> InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional.
> The test intermittently fails due to a ModuleLoadException while deploying one of the modules:
> https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore_PullRequest
> The most notable bit of info in the log is:
> {code}
> 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar
>     at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
>     at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
>     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: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar
>     at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834)
>     at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472)
>     at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457)
>     at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370)
>     at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147)
>     at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387)
>     at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282)
>     at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270)
>     at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
>     ... 6 more
> {code}
> The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar.
> The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:08 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1960) Get rid of attributes of
 type LIST of PROPERTY; use OBJECT of STRING
In-Reply-To: <JIRA.12660236.1478622756000@Atlassian.JIRA>
References: <JIRA.12660236.1478622756000@Atlassian.JIRA>
	<JIRA.12660236.1478622756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660236.1478622756000.108591.1517054768679@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1960:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING
> --------------------------------------------------------------------
>
>                 Key: WFCORE-1960
>                 URL: https://issues.jboss.org/browse/WFCORE-1960
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Ken Wills
>             Fix For: 4.0.0.Alpha8
>
>         Attachments: rrd.txt
>
>
> A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap<String, String>, with ordering based on insertion. So such a description is fine for a path address attribute. 
> I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model) so removing the only usage of it will help.
> We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:08 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1944) Convert domain-management
 tests to reference Elytron SecurityRealm and remove old CallbackHandler
 code.
In-Reply-To: <JIRA.12659650.1478461931000@Atlassian.JIRA>
References: <JIRA.12659650.1478461931000@Atlassian.JIRA>
	<JIRA.12659650.1478461931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659650.1478461931000.108598.1517054768888@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1944:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1944
>                 URL: https://issues.jboss.org/browse/WFCORE-1944
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Alpha8
>
>
> The important pieces of code within the legacy security realms are being wrapped using Elytron components, items like the legacy CallbackHandlers can be removed but existing tests need porting to call Elytron APIs.
> The legacy tests do need to be retained as they offer a good level of regression testing for the legacy realms.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:08 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1649) RBAC constraint config
 modifications will fail in a mixed domain if the modified constraint is not
 present in the legacy slave
In-Reply-To: <JIRA.12638588.1468361977000@Atlassian.JIRA>
References: <JIRA.12638588.1468361977000@Atlassian.JIRA>
	<JIRA.12638588.1468361977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638588.1468361977000.108602.1517054768993@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1649:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1649
>                 URL: https://issues.jboss.org/browse/WFCORE-1649
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>              Labels: domain-mode
>             Fix For: 4.0.0.Alpha8
>
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:09 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1489) Expose
 (un)registerNotificationHandler() on OperationContext
In-Reply-To: <JIRA.12616058.1461163906000@Atlassian.JIRA>
References: <JIRA.12616058.1461163906000@Atlassian.JIRA>
	<JIRA.12616058.1461163906000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616058.1461163906000.108606.1517054769107@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1489:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> Expose (un)registerNotificationHandler() on OperationContext
> ------------------------------------------------------------
>
>                 Key: WFCORE-1489
>                 URL: https://issues.jboss.org/browse/WFCORE-1489
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Jeff Mesnil
>             Fix For: 4.0.0.Alpha8
>
>
> Currently the only way to (un)register notifications is via the NotificationHandlerRegistration exposed by ModelController.getNotificationRegistry(). It would be nice to not have to install a service whose only purpose is to get hold of the ModelController from OSH's.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:06:09 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:06:09 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1307) jboss-cli returns success
 when WFLYCTL0009: Failed to store configuration occurred
In-Reply-To: <JIRA.12599757.1452996122000@Atlassian.JIRA>
References: <JIRA.12599757.1452996122000@Atlassian.JIRA>
	<JIRA.12599757.1452996122000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599757.1452996122000.108616.1517054769417@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1307:
-------------------------------------
    Fix Version/s: 4.0.0.Alpha8
                       (was: 4.0.0.Alpha7)


> jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-1307
>                 URL: https://issues.jboss.org/browse/WFCORE-1307
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.7.Final
>            Reporter: Brad Maxwell
>            Assignee: Ken Wills
>             Fix For: 4.0.0.Alpha8
>
>
> If the server is started, and a cli call is made that fails to persist to the standalone.xml returns success even though it failed. 
> Start the server.
> Simple way to reproduce is to change the permissions on the configuration directory then run some cli commands such as shown below:
> {code}
> $ ./bin/jboss-cli.sh -c
> [standalone at localhost:9990 /] /system-property=foo1:add(value=bar1)
> {"outcome" => "success"}
> [standalone at localhost:9999 /] /subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
> {"outcome" => "success"}
> {code}
> {code}
> 19:53:17,823 ERROR [stderr] (management-handler-thread - 1) java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) 	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) 	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) 	at java.nio.file.Files.newByteChannel(Files.java:361)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) 	at java.nio.file.Files.createFile(Files.java:632)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:125)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) 	at java.security.AccessController.doPrivileged(Native Method)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) 	at java.lang.Thread.run(Thread.java:745)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 19:53:17,831 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0009: Failed to store configuration to standalone.xml: java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> 	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 	at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> 	at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> 	at java.nio.file.Files.deleteIfExists(Files.java:1165)
> 	at java.nio.file.Files.copy(Files.java:3004)
> 	at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:109)
> 	at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> 	at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> 	at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> 	at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 	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)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 07:31:00 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 07:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2088) Enhance CLI to support Aesh
	Commands
In-Reply-To: <JIRA.12665642.1481038936000@Atlassian.JIRA>
References: <JIRA.12665642.1481038936000@Atlassian.JIRA>
	<JIRA.12665642.1481038936000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12665642.1481038936000.108620.1517056260202@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2088?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2088:
-------------------------------------
    Git Pull Request: https://github.com/wildfly/wildfly-core/pull/2946  (was: https://github.com/wildfly/wildfly-core/pull/2843)


> Enhance CLI to support Aesh Commands
> ------------------------------------
>
>                 Key: WFCORE-2088
>                 URL: https://issues.jboss.org/browse/WFCORE-2088
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: CLI
>            Reporter: Jean-Francois Denise
>            Assignee: Jean-Francois Denise
>             Fix For: 4.0.0.Alpha8
>
>
> In order to modernize the way to develop CLI commands, CLI needs to support commands developed with aesh 1.0 API. Aesh has been recently re-architectured to expose a Command Runtime that we can integrate in CLI.
> The first immediate benefit of this integration is the ability to load aesh based commands exposed by extensions.
> The patch command should be a candidate to validate this integration of aesh commands.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 08:32:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Sat, 27 Jan 2018 08:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-5332) Allow configure max-threads
 and core-threads independently. Allow idle thread reusage.
In-Reply-To: <JIRA.12584791.1442226574000@Atlassian.JIRA>
References: <JIRA.12584791.1442226574000@Atlassian.JIRA>
	<JIRA.12584791.1442226574000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12584791.1442226574000.108661.1517059920546@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-5332?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-5332.
-------------------------------
    Fix Version/s: 12.0.0.Alpha1
       Resolution: Done


> Allow configure max-threads and core-threads independently. Allow idle thread reusage.
> --------------------------------------------------------------------------------------
>
>                 Key: WFLY-5332
>                 URL: https://issues.jboss.org/browse/WFLY-5332
>             Project: WildFly
>          Issue Type: Feature Request
>          Components: EJB
>            Reporter: Panagiotis Sotiropoulos
>            Assignee: David Lloyd
>             Fix For: 12.0.0.Alpha1
>
>         Attachments: JBossThreadPoolExecutor.jpg, JBossThreadPoolReuseIdleThreadsExecutor.jpg, ModifiedJBossThreadPoolExecutorStateDiagram.jpg
>
>
> Description of problem:
> It looks like the ejb3 subsystem thread pool configuration is hard coded to create an unbounded thread pool, where it it looks like max-threads = core-threads, and thus the threads will increase up to the max-threads configured and then remain there.  The keep-alive setting which appears in many of the docs & default configurations is ineffective since max=core.
> ejb3/src/main/java/org/jboss/as/ejb3/subsystem/EJB3SubsystemRootResourceDefinition.java
> I tried defining a different thread pool in the threads subsystem and tried to reference it from the ejb3 subsystem, however it looks like the ejb3 subsystem only looks for thread pools configured in the ejb3 subsystem.
> Additional desired functionality according to PRODMGT-1401:
> "the desired functionality is to, when a new request arrives
> and there is an idle thread, use that thread instead of creating a new 
> thread [up until max-threads]."



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:02 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3542) Elytron JDBC realm password
 mapping is not consistent with underlying implementation
In-Reply-To: <JIRA.12730594.1516805741000@Atlassian.JIRA>
References: <JIRA.12730594.1516805741000@Atlassian.JIRA>
	<JIRA.12730594.1516805741000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730594.1516805741000.108709.1517066462651@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3542:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Elytron JDBC realm password mapping is not consistent with underlying implementation
> ------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3542
>                 URL: https://issues.jboss.org/browse/WFCORE-3542
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: David Lloyd
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Beta1
>
>
> There is no way to configure the JDBC realm to use modular crypt in WildFly, even though the underlying realm does support it.
> The problem is that the {{salt-index}} and {{itereration-count-index}} attributes should be optional, and if they not given, a value of {{-1}} should be passed to the mapper.  By omitting both of these values, the database column values will then be recognized as modular-crypt strings.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:02 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3527) Remove OSGi obsolete code
In-Reply-To: <JIRA.12729983.1516378481000@Atlassian.JIRA>
References: <JIRA.12729983.1516378481000@Atlassian.JIRA>
	<JIRA.12729983.1516378481000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729983.1516378481000.108712.1517066462799@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3527:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Remove OSGi obsolete code
> -------------------------
>
>                 Key: WFCORE-3527
>                 URL: https://issues.jboss.org/browse/WFCORE-3527
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Server
>    Affects Versions: 4.0.0.Alpha5
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Beta1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:02 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3519) Add JASPI Module
In-Reply-To: <JIRA.12729731.1516279301000@Atlassian.JIRA>
References: <JIRA.12729731.1516279301000@Atlassian.JIRA>
	<JIRA.12729731.1516279301000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729731.1516279301000.108719.1517066462951@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3519?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3519:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Add JASPI Module
> ----------------
>
>                 Key: WFCORE-3519
>                 URL: https://issues.jboss.org/browse/WFCORE-3519
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Beta1
>
>
> (Copy from WildFly)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3457) Reduce class loading of
 Elytron subsystem
In-Reply-To: <JIRA.12724639.1513168462000@Atlassian.JIRA>
References: <JIRA.12724639.1513168462000@Atlassian.JIRA>
	<JIRA.12724639.1513168462000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724639.1513168462000.108726.1517066463125@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3457:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Reduce class loading of Elytron subsystem
> -----------------------------------------
>
>                 Key: WFCORE-3457
>                 URL: https://issues.jboss.org/browse/WFCORE-3457
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Beta1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3424) Replace MSC listeners with
 stability monitors
In-Reply-To: <JIRA.12721337.1510844543000@Atlassian.JIRA>
References: <JIRA.12721337.1510844543000@Atlassian.JIRA>
	<JIRA.12721337.1510844543000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12721337.1510844543000.108729.1517066463202@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3424:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Replace MSC listeners with stability monitors
> ---------------------------------------------
>
>                 Key: WFCORE-3424
>                 URL: https://issues.jboss.org/browse/WFCORE-3424
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Server
>    Affects Versions: 4.0.0.Alpha2
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Beta1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3386) Add configuration required
 to support JASPIC to the Elytron subsystem
In-Reply-To: <JIRA.12718363.1509034738000@Atlassian.JIRA>
References: <JIRA.12718363.1509034738000@Atlassian.JIRA>
	<JIRA.12718363.1509034738000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718363.1509034738000.108736.1517066463369@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3386?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3386:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Add configuration required to support JASPIC to the Elytron subsystem
> ---------------------------------------------------------------------
>
>                 Key: WFCORE-3386
>                 URL: https://issues.jboss.org/browse/WFCORE-3386
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Beta1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3382) Further Enhance Elytron
 Permission Configuration
In-Reply-To: <JIRA.12718138.1508950408000@Atlassian.JIRA>
References: <JIRA.12718138.1508950408000@Atlassian.JIRA>
	<JIRA.12718138.1508950408000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718138.1508950408000.108744.1517066463603@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3382?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3382:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Further Enhance Elytron Permission Configuration
> ------------------------------------------------
>
>                 Key: WFCORE-3382
>                 URL: https://issues.jboss.org/browse/WFCORE-3382
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Security
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Beta1
>
>
> This has currently been simplified to a single resource for the out of the box configuration, however this brings issues as now permissions are duplicated so modifications need to be replicated instead of to a single location.
> Finding a way for the default required permissions to be defined in one location could help eliminate the duplication.
> We could also consider going one step further and subsystems register the default permissions that should be granted.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3360) Eliminate
 org.wildfly.extension.elytron.ProviderUtil
In-Reply-To: <JIRA.12716717.1508231768000@Atlassian.JIRA>
References: <JIRA.12716717.1508231768000@Atlassian.JIRA>
	<JIRA.12716717.1508231768000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12716717.1508231768000.108751.1517066463813@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3360:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Eliminate org.wildfly.extension.elytron.ProviderUtil
> ----------------------------------------------------
>
>                 Key: WFCORE-3360
>                 URL: https://issues.jboss.org/browse/WFCORE-3360
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>            Assignee: Darran Lofthouse
>             Fix For: 4.0.0.Beta1
>
>
> WildFly Elytron contains a public utility class org.wildfly.security.util.ProviderUtil for the same purpose, we should use the code within WildFly Elytron and not custom code within the subsystem.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:03 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:03 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3255) Complex type
 AttributeDefinition variants don't handle ParameterCorrector properly
In-Reply-To: <JIRA.12710526.1504748362000@Atlassian.JIRA>
References: <JIRA.12710526.1504748362000@Atlassian.JIRA>
	<JIRA.12710526.1504748362000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12710526.1504748362000.108753.1517066463894@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3255:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Complex type AttributeDefinition variants don't handle ParameterCorrector properly
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-3255
>                 URL: https://issues.jboss.org/browse/WFCORE-3255
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 3.0.1.Final
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 4.0.0.Beta1
>
>
> If a field in a complex attribute (i.e. one that uses Object...AttributeDefinition) has a ParameterCorrector configured, that corrector never gets called. That's because only a corrector on the top level attribute gets called.
> These classes should automatically use an internal corrector that first calls any corrector configured for fields, and then, if one is present, calls any top level corrector.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3181) Review
 CustomCredentialSecurityFactoryTestCase
In-Reply-To: <JIRA.12707010.1502379745000@Atlassian.JIRA>
References: <JIRA.12707010.1502379745000@Atlassian.JIRA>
	<JIRA.12707010.1502379745000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12707010.1502379745000.108760.1517066464095@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3181?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3181:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Review CustomCredentialSecurityFactoryTestCase
> ----------------------------------------------
>
>                 Key: WFCORE-3181
>                 URL: https://issues.jboss.org/browse/WFCORE-3181
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security, Test Suite
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Beta1
>
>
> The test case CustomCredentialSecurityFactoryTestCase appears to be testing that the 'code does what it does' rather than testing the 'code is doing what it should'.
> The test is testing a custom credential security factory can be called but the test is using HTTP Basic authentication and relying on SPNEGO authentication being triggered as this is the only mechanism that currently uses this factory.
> Should a minor change be required to the SPNEGO authentication mechanism which affects when this credential factory is called this test case could subsequently fail.
> If possible it would be better to convert this test to be a SPNEGO test and then test the behaviour of the credential security factory affects the mechanism as expected.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3107) Allow slave hosts to ignore
 missing RBAC config resources
In-Reply-To: <JIRA.12704736.1501032152000@Atlassian.JIRA>
References: <JIRA.12704736.1501032152000@Atlassian.JIRA>
	<JIRA.12704736.1501032152000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12704736.1501032152000.108762.1517066464150@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3107:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Allow slave hosts to ignore missing RBAC config resources
> ---------------------------------------------------------
>
>                 Key: WFCORE-3107
>                 URL: https://issues.jboss.org/browse/WFCORE-3107
>             Project: WildFly Core
>          Issue Type: Sub-task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>             Fix For: 4.0.0.Beta1
>
>
> Part of parent issue whereby slaves can ignore missing RBAC constraint resources for write requests coming from the DC.
> If the DC sent the request, then the address is ok overall. So if it's missing on the slave that means the slave doesn't have that constraint registered and doesn't need to handle the op.
> This fix could possibly be backported to the 2.1.x and to EAP 6.4.x in lieu of adding transformers as part of the parent issue. In the case of 2.1.x it also allows slaves to ignore the related extension even if the code for it is present (which is only a minor benefit.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3073) Handle Shutdown via TERM
	gracefully
In-Reply-To: <JIRA.12700921.1499443726000@Atlassian.JIRA>
References: <JIRA.12700921.1499443726000@Atlassian.JIRA>
	<JIRA.12700921.1499443726000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12700921.1499443726000.108772.1517066464466@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3073?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3073:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Handle Shutdown via TERM gracefully
> -----------------------------------
>
>                 Key: WFCORE-3073
>                 URL: https://issues.jboss.org/browse/WFCORE-3073
>             Project: WildFly Core
>          Issue Type: Feature Request
>          Components: Domain Management
>            Reporter: Ben Parees
>            Assignee: Brian Stansberry
>             Fix For: 4.0.0.Beta1
>
>
> The wildfly server currently -terminates immediately- performs a standard (non-graceful) shutdown in response to a TERM signal.  To achieve a -clean- graceful shutdown requires invoking the CLI tooling.  This is particularly problematic in container environments like kubernetes where the container process (wildfly in this case) is going to get a TERM signal when the container needs to be moved. 
> While it's possible to wrapper the process and handle the TERM and then invoke the CLI, it would be preferable for the server process itself to cleanly handle a TERM signal by waiting for in-flight requests to complete (w/ some grace period of course).
> Having this as configurable behavior would be good if there are backwards compatibility concerns about introducing this behavior change.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3019) The bin/product.conf and
 the org.jboss.as.product:wildfly-core module should come in via an FP
In-Reply-To: <JIRA.12699548.1498596551000@Atlassian.JIRA>
References: <JIRA.12699548.1498596551000@Atlassian.JIRA>
	<JIRA.12699548.1498596551000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12699548.1498596551000.108775.1517066464530@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3019?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-3019:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> The bin/product.conf and the org.jboss.as.product:wildfly-core module should come in via an FP
> ----------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-3019
>                 URL: https://issues.jboss.org/browse/WFCORE-3019
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Server
>            Reporter: Brian Stansberry
>            Assignee: James Perkins
>             Fix For: 4.0.0.Beta1
>
>
> For WFLY-4692 we moved the "product" stuff out of core-feature-pack and into dist. But this means it doesn't end up in the skinny dist produced by the "build" module. Plus it makes the "dist" a kind of FP of its own.
> The stuff in dist/src/distribution should be its own FP. That one *perhaps* depends on core-feature-pack. Then build and dist use the new FP in addition to or instead of core-feature-pack.
> So, core-feature-pack is independently usable, in other dists, but our offiical build/dist, which has our official product module, picks up the new FP.
> Whether the new "product" FP depends on core-feature-pack depends on how we want to use it; i.e. can this bin/product.conf and module be used in some other flavor of dist.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2746) Move elytron management
 security tests from full to core
In-Reply-To: <JIRA.12690293.1493753754000@Atlassian.JIRA>
References: <JIRA.12690293.1493753754000@Atlassian.JIRA>
	<JIRA.12690293.1493753754000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12690293.1493753754000.108783.1517066464751@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2746:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Move elytron management security tests from full to core
> --------------------------------------------------------
>
>                 Key: WFCORE-2746
>                 URL: https://issues.jboss.org/browse/WFCORE-2746
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security, Test Suite
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Beta1
>
>
> Since until recently the elytron subsystem wasn't part of the core feature pack, a lot of integration tests of its use ended up in the WildFly full testsuite instead of in core. This task is to get tests that are only testing core functionality moved into the core testsuite. Because that's the right thing to do, but also because it's useful in practice by eliminating a cause for messy coordinated changes to core and full such that code changes in core can be tested.
> Corresponding Wildfly JIRA: https://issues.jboss.org/browse/WFLY-8723
> There are a number of aspects to this, for which I'll create subtasks.
> Following is an initial list of tests that should be moved. *This is meant to be a living list, with things added as they are noticed.* So anyone should feel free to edit this JIRA description to add things to the list.
> -org.jboss.as.test.integration.security.perimeter.* [2]-
> -org.jboss.as.test.manualmode.mgmt.elytron.HttpMgmtInterfaceElytronAuthenticationTestCase-
> -org.jboss.as.test.integration.domain.AbstractSlaveHCAuthenticationTestCase and subclasses.[1]-
> -org.jboss.as.test.integration.security.credentialreference [2]-
> integration/elytron/
> [1] One subclass of this is not related to elytron but should be moved to core too. I haven't looked closely but it uses vault, which may be why it is in full. But we can use vault in the core testsuite now.
> [2] Currently using Arquillian.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:04 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:04 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2589) Eliminate MSC OPTIONAL
 dependencies usage
In-Reply-To: <JIRA.12684776.1490708029000@Atlassian.JIRA>
References: <JIRA.12684776.1490708029000@Atlassian.JIRA>
	<JIRA.12684776.1490708029000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12684776.1490708029000.108786.1517066464853@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2589:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Eliminate MSC OPTIONAL dependencies usage
> -----------------------------------------
>
>                 Key: WFCORE-2589
>                 URL: https://issues.jboss.org/browse/WFCORE-2589
>             Project: WildFly Core
>          Issue Type: Task
>            Reporter: Richard Opalka
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Beta1
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2497) Convert
 *-authentication-factory resources to be child resources of security-domain
In-Reply-To: <JIRA.12678139.1487691523000@Atlassian.JIRA>
References: <JIRA.12678139.1487691523000@Atlassian.JIRA>
	<JIRA.12678139.1487691523000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12678139.1487691523000.108794.1517066465026@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2497?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2497:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Convert *-authentication-factory resources to be child resources of security-domain
> -----------------------------------------------------------------------------------
>
>                 Key: WFCORE-2497
>                 URL: https://issues.jboss.org/browse/WFCORE-2497
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Security
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Beta1
>
>
> This is a good example of where child resources work.
> The authentication factory resources have a mandatory dependency on a single security domain.
> The configuration within the factory is related to it's security domain.
> There is only a single resource that can provide security domains.
> The behaviour of the parent is unaffected by the existence or configuration of the child.
> The parent and child manage their own services independently with the child's service depending on the parent's service.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2349) Add
 RemoteManagementPermission and RemoteJMXPermission checks for remote
 clients.
In-Reply-To: <JIRA.12679810.1488466192000@Atlassian.JIRA>
References: <JIRA.12679810.1488466192000@Atlassian.JIRA>
	<JIRA.12679810.1488466192000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679810.1488466192000.108807.1517066465357@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2349:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Add RemoteManagementPermission and RemoteJMXPermission checks for remote clients.
> ---------------------------------------------------------------------------------
>
>                 Key: WFCORE-2349
>                 URL: https://issues.jboss.org/browse/WFCORE-2349
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Beta1
>
>
> Other services such as EJB and transactions have a Remote*Permission to verify the remote client has the required permission to use that service - this should be repeated for the management related services to control what a remote client can and can not connect to.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2336) Remove
	ModelController.createClient
In-Reply-To: <JIRA.12679023.1488205057000@Atlassian.JIRA>
References: <JIRA.12679023.1488205057000@Atlassian.JIRA>
	<JIRA.12679023.1488205057000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12679023.1488205057000.108809.1517066465434@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2336?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2336:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Remove ModelController.createClient
> -----------------------------------
>
>                 Key: WFCORE-2336
>                 URL: https://issues.jboss.org/browse/WFCORE-2336
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management
>            Reporter: Brian Stansberry
>             Fix For: 4.0.0.Beta1
>
>
> Follow up on WFCORE-1507 by removing ModelController.createClient and any use of it.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2235) Intermittent module loading
 failure in InterdependentDeploymentTestCase
In-Reply-To: <JIRA.12673068.1485365894000@Atlassian.JIRA>
References: <JIRA.12673068.1485365894000@Atlassian.JIRA>
	<JIRA.12673068.1485365894000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12673068.1485365894000.108813.1517066465535@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2235?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2235:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Intermittent module loading failure in InterdependentDeploymentTestCase
> -----------------------------------------------------------------------
>
>                 Key: WFCORE-2235
>                 URL: https://issues.jboss.org/browse/WFCORE-2235
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Modules, Server
>    Affects Versions: 4.0.0.Alpha6
>            Reporter: Brian Stansberry
>            Assignee: Richard Opalka
>             Fix For: 4.0.0.Beta1
>
>         Attachments: WFCORE-2235svcdump.txt
>
>
> InterdependentDeploymentTestCase tests deployment handling of a set of interdependent deployments, where some of the dependencies are optional.
> The test intermittently fails due to a ModuleLoadException while deploying one of the modules:
> https://ci.wildfly.org/viewLog.html?buildId=42957&buildTypeId=WildFlyCore_PullRequest
> The most notable bit of info in the log is:
> {code}
> 17:32:08,639 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-2) MSC000001: Failed to start service jboss.module.service."deployment.interrelated-c.jar".main: org.jboss.msc.service.StartException in service jboss.module.service."deployment.interrelated-c.jar".main: WFLYSRV0179: Failed to load module: deployment.interrelated-c.jar
>     at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:91)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:2032)
>     at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1955)
>     at org.jboss.msc.service.MSCExecutor$1.run(MSCExecutor.java:77)
>     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: org.jboss.modules.ModuleNotFoundException: deployment.interrelated-c.jar
>     at org.jboss.modules.ModuleLoader$FutureModule.getModule(ModuleLoader.java:834)
>     at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:472)
>     at org.jboss.modules.ModuleLoader.loadModuleLocal(ModuleLoader.java:457)
>     at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:370)
>     at org.jboss.as.server.moduleservice.ServiceModuleLoader.preloadModule(ServiceModuleLoader.java:147)
>     at org.jboss.modules.ModuleLoader.preloadModule(ModuleLoader.java:387)
>     at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:282)
>     at org.jboss.modules.ModuleLoader.loadModule(ModuleLoader.java:270)
>     at org.jboss.as.server.moduleservice.ModuleLoadService.start(ModuleLoadService.java:68)
>     ... 6 more
> {code}
> The interrelated-c.jar deployment depends (*not optionally*) on interrelated-a.jar.The failure occurs during execution of a management op that redeploys interrelated-a.jar. FWIW, another deployment in the set, interrelated-f.jar, does depend optionally on interrelated-c.jar.
> The full stdout output for the failed test in the above linked CI run also includes a dump of all MSC services following the failure. Note though that the failure does not result in MSC not obtaining stability. Inability to reach stability was the initial problem that led to the introduction of this test (see https://github.com/wildfly/wildfly-core/pull/2099.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1960) Get rid of attributes of
 type LIST of PROPERTY; use OBJECT of STRING
In-Reply-To: <JIRA.12660236.1478622756000@Atlassian.JIRA>
References: <JIRA.12660236.1478622756000@Atlassian.JIRA>
	<JIRA.12660236.1478622756000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12660236.1478622756000.108816.1517066465640@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1960?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1960:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Get rid of attributes of type LIST of PROPERTY; use OBJECT of STRING
> --------------------------------------------------------------------
>
>                 Key: WFCORE-1960
>                 URL: https://issues.jboss.org/browse/WFCORE-1960
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Ken Wills
>             Fix For: 4.0.0.Beta1
>
>         Attachments: rrd.txt
>
>
> A read-resource-description output of a standalone-full-ha.xml server (see attached) shows a couple attributes that are of type LIST, value-type PROPERTY. (Just text search for PROPERTY.) We should convert those to OBJECT, value-type STRING. Both represent a resource address. An object of string is equivalent to a LinkedHashMap<String, String>, with ordering based on insertion. So such a description is fine for a path address attribute. 
> I'd like to get rid of the notion of PROPERTY in our spec definition of how to describe attributes, parameters and value-types (https://docs.jboss.org/author/display/WFLY/Description+of+the+Management+Model) so removing the only usage of it will help.
> We should still accept PROPERTY as inputs when we can do conversion to the defined type. This is all about tightening up the spec to remove the not-really-necessary PROPERTY concept.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1944) Convert domain-management
 tests to reference Elytron SecurityRealm and remove old CallbackHandler
 code.
In-Reply-To: <JIRA.12659650.1478461931000@Atlassian.JIRA>
References: <JIRA.12659650.1478461931000@Atlassian.JIRA>
	<JIRA.12659650.1478461931000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12659650.1478461931000.108823.1517066465828@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1944:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Convert domain-management tests to reference Elytron SecurityRealm and remove old CallbackHandler code.
> -------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1944
>                 URL: https://issues.jboss.org/browse/WFCORE-1944
>             Project: WildFly Core
>          Issue Type: Task
>          Components: Domain Management, Security
>            Reporter: Darran Lofthouse
>             Fix For: 4.0.0.Beta1
>
>
> The important pieces of code within the legacy security realms are being wrapped using Elytron components, items like the legacy CallbackHandlers can be removed but existing tests need porting to call Elytron APIs.
> The legacy tests do need to be retained as they offer a good level of regression testing for the legacy realms.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1649) RBAC constraint config
 modifications will fail in a mixed domain if the modified constraint is not
 present in the legacy slave
In-Reply-To: <JIRA.12638588.1468361977000@Atlassian.JIRA>
References: <JIRA.12638588.1468361977000@Atlassian.JIRA>
	<JIRA.12638588.1468361977000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12638588.1468361977000.108827.1517066465947@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1649?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1649:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> RBAC constraint config modifications will fail in a mixed domain if the modified constraint is not present in the legacy slave
> ------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFCORE-1649
>                 URL: https://issues.jboss.org/browse/WFCORE-1649
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>            Reporter: Brian Stansberry
>            Assignee: Brian Stansberry
>            Priority: Critical
>              Labels: domain-mode
>             Fix For: 4.0.0.Beta1
>
>
> The management model for RBAC constraints is maintained using synthetic resources, with resources only existing for those items (SensitivityClassification and ApplicationClassification) that are registered in the current process. Operations that touch classifications unknown to that process will fail due to missing resource problems.
> This is a big problem in the following scenarios:
> 1) Mixed domain, where legacy slaves do not know about newly introduced classifications.
> 2) Slimming scenarios where slaves are ignoring unrelated parts of the domain wide config and also don't have some extension installed, resulting in classifications registered by those extensions not being present.
> A partial workaround to 1) is for the kernel to register transformers for newly introduced classifications (e.g. SERVER_SSL added in EAP 6.4.7 and EAP 7). But:
> -- that doesn't help with problem 2)
> -- only the kernel can register kernel transformers, so if extensions add new classifications there is no way for them to register the transformer.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:06 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1489) Expose
 (un)registerNotificationHandler() on OperationContext
In-Reply-To: <JIRA.12616058.1461163906000@Atlassian.JIRA>
References: <JIRA.12616058.1461163906000@Atlassian.JIRA>
	<JIRA.12616058.1461163906000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12616058.1461163906000.108831.1517066466083@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1489:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Expose (un)registerNotificationHandler() on OperationContext
> ------------------------------------------------------------
>
>                 Key: WFCORE-1489
>                 URL: https://issues.jboss.org/browse/WFCORE-1489
>             Project: WildFly Core
>          Issue Type: Enhancement
>          Components: Domain Management
>            Reporter: Kabir Khan
>            Assignee: Jeff Mesnil
>             Fix For: 4.0.0.Beta1
>
>
> Currently the only way to (un)register notifications is via the NotificationHandlerRegistration exposed by ModelController.getNotificationRegistry(). It would be nice to not have to install a service whose only purpose is to get hold of the ModelController from OSH's.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:06 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:06 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-1307) jboss-cli returns success
 when WFLYCTL0009: Failed to store configuration occurred
In-Reply-To: <JIRA.12599757.1452996122000@Atlassian.JIRA>
References: <JIRA.12599757.1452996122000@Atlassian.JIRA>
	<JIRA.12599757.1452996122000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12599757.1452996122000.108841.1517066466334@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-1307:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> jboss-cli returns success when WFLYCTL0009: Failed to store configuration occurred
> ----------------------------------------------------------------------------------
>
>                 Key: WFCORE-1307
>                 URL: https://issues.jboss.org/browse/WFCORE-1307
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Domain Management
>    Affects Versions: 2.0.7.Final
>            Reporter: Brad Maxwell
>            Assignee: Ken Wills
>             Fix For: 4.0.0.Beta1
>
>
> If the server is started, and a cli call is made that fails to persist to the standalone.xml returns success even though it failed. 
> Start the server.
> Simple way to reproduce is to change the permissions on the configuration directory then run some cli commands such as shown below:
> {code}
> $ ./bin/jboss-cli.sh -c
> [standalone at localhost:9990 /] /system-property=foo1:add(value=bar1)
> {"outcome" => "success"}
> [standalone at localhost:9999 /] /subsystem=ejb3:write-attribute(name=enable-statistics,value=true)
> {"outcome" => "success"}
> {code}
> {code}
> 19:53:17,823 ERROR [stderr] (management-handler-thread - 1) java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) 	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 19:53:17,824 ERROR [stderr] (management-handler-thread - 1) 	at sun.nio.fs.UnixFileSystemProvider.newByteChannel(UnixFileSystemProvider.java:214)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) 	at java.nio.file.Files.newByteChannel(Files.java:361)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) 	at java.nio.file.Files.createFile(Files.java:632)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.persistence.FilePersistenceUtils.createTempFileWithAttributes(FilePersistenceUtils.java:125)
> 19:53:17,825 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:104)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> 19:53:17,826 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 19:53:17,827 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> 19:53:17,828 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) 	at java.security.AccessController.doPrivileged(Native Method)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 19:53:17,829 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) 	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> 19:53:17,830 ERROR [stderr] (management-handler-thread - 1) 	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) 	at java.lang.Thread.run(Thread.java:745)
> 19:53:17,831 ERROR [stderr] (management-handler-thread - 1) 	at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 19:53:17,831 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) WFLYCTL0009: Failed to store configuration to standalone.xml: java.nio.file.AccessDeniedException: /tmp/wildfly-10.0.0.CR5/standalone/configuration/standalone.xml.tmp
> 	at sun.nio.fs.UnixException.translateToIOException(UnixException.java:84)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:102)
> 	at sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:107)
> 	at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:244)
> 	at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> 	at java.nio.file.Files.deleteIfExists(Files.java:1165)
> 	at java.nio.file.Files.copy(Files.java:3004)
> 	at org.jboss.as.controller.persistence.FilePersistenceUtils.writeToTempFile(FilePersistenceUtils.java:109)
> 	at org.jboss.as.controller.persistence.ConfigurationFilePersistenceResource.doCommit(ConfigurationFilePersistenceResource.java:55)
> 	at org.jboss.as.controller.persistence.AbstractFilePersistenceResource.commit(AbstractFilePersistenceResource.java:58)
> 	at org.jboss.as.controller.ModelControllerImpl$4.commit(ModelControllerImpl.java:781)
> 	at org.jboss.as.controller.AbstractOperationContext.executeDoneStage(AbstractOperationContext.java:743)
> 	at org.jboss.as.controller.AbstractOperationContext.processStages(AbstractOperationContext.java:680)
> 	at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:370)
> 	at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1344)
> 	at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> 	at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:217)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:208)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.access$300(ModelControllerClientOperationHandler.java:130)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:152)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1$1.run(ModelControllerClientOperationHandler.java:148)
> 	at java.security.AccessController.doPrivileged(Native Method)
> 	at javax.security.auth.Subject.doAs(Subject.java:422)
> 	at org.jboss.as.controller.AccessAuditContext.doAs(AccessAuditContext.java:92)
> 	at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:148)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$ManagementRequestContextImpl$1.doExecute(AbstractMessageHandler.java:363)
> 	at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:472)
> 	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)
> {code}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sat Jan 27 10:21:05 2018
From: issues at jboss.org (Brian Stansberry (JIRA))
Date: Sat, 27 Jan 2018 10:21:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-2365) Review
 custom-modifiable-realm resource in Elytron subsystem
In-Reply-To: <JIRA.12651212.1474463004000@Atlassian.JIRA>
References: <JIRA.12651212.1474463004000@Atlassian.JIRA>
	<JIRA.12651212.1474463004000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12651212.1474463004000.108800.1517066465151@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-2365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Brian Stansberry updated WFCORE-2365:
-------------------------------------
    Fix Version/s: 4.0.0.Beta1
                       (was: 4.0.0.Alpha8)


> Review custom-modifiable-realm resource in Elytron subsystem
> ------------------------------------------------------------
>
>                 Key: WFCORE-2365
>                 URL: https://issues.jboss.org/browse/WFCORE-2365
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>            Reporter: Ondrej Lukas
>             Fix For: 4.0.0.Beta1
>
>
> See description of JBEAP-6100 for more details.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 28 09:06:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Sun, 28 Jan 2018 09:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3558) Upgrade JBoss Threads to
	2.3.0.Final
In-Reply-To: <JIRA.12731023.1516972437000@Atlassian.JIRA>
References: <JIRA.12731023.1516972437000@Atlassian.JIRA>
	<JIRA.12731023.1516972437000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731023.1516972437000.108968.1517148360553@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3558?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFCORE-3558:
--------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha8)


> Upgrade JBoss Threads to 2.3.0.Final
> ------------------------------------
>
>                 Key: WFCORE-3558
>                 URL: https://issues.jboss.org/browse/WFCORE-3558
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>             Fix For: 4.0.0.Alpha7
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 28 09:06:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Sun, 28 Jan 2018 09:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3557) Upgrade Wildfly Common to
	1.3.0.Final
In-Reply-To: <JIRA.12731022.1516972356000@Atlassian.JIRA>
References: <JIRA.12731022.1516972356000@Atlassian.JIRA>
	<JIRA.12731022.1516972356000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731022.1516972356000.108972.1517148360646@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3557?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFCORE-3557:
--------------------------------
    Fix Version/s: 4.0.0.Alpha7
                       (was: 4.0.0.Alpha8)


> Upgrade Wildfly Common to 1.3.0.Final
> -------------------------------------
>
>                 Key: WFCORE-3557
>                 URL: https://issues.jboss.org/browse/WFCORE-3557
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>             Fix For: 4.0.0.Alpha7
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 28 09:06:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Sun, 28 Jan 2018 09:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3552) Upgrade JBoss MSC to
	1.3.0.Final
In-Reply-To: <JIRA.12730967.1516960376000@Atlassian.JIRA>
References: <JIRA.12730967.1516960376000@Atlassian.JIRA>
	<JIRA.12730967.1516960376000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730967.1516960376000.108975.1517148360762@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3552?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd updated WFCORE-3552:
--------------------------------
    Fix Version/s: 4.0.0.Alpha7


> Upgrade JBoss MSC to 1.3.0.Final
> --------------------------------
>
>                 Key: WFCORE-3552
>                 URL: https://issues.jboss.org/browse/WFCORE-3552
>             Project: WildFly Core
>          Issue Type: Component Upgrade
>            Reporter: Richard Opalka
>            Assignee: David Lloyd
>             Fix For: 4.0.0.Alpha7
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Sun Jan 28 22:07:00 2018
From: issues at jboss.org (Chao Wang (JIRA))
Date: Sun, 28 Jan 2018 22:07:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9740) JspTagTestCase fails on
	Windows
In-Reply-To: <JIRA.12731235.1517195218000@Atlassian.JIRA>
References: <JIRA.12731235.1517195218000@Atlassian.JIRA>
	<JIRA.12731235.1517195218542@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731235.1517195218000.109200.1517195220202@Atlassian.JIRA>

Chao Wang created WFLY-9740:
-------------------------------

             Summary: JspTagTestCase fails on Windows
                 Key: WFLY-9740
                 URL: https://issues.jboss.org/browse/WFLY-9740
             Project: WildFly
          Issue Type: Bug
          Components: Test Suite
    Affects Versions: 10.1.0.CR1
         Environment: Windows 10, Oracle JDK 1.8.0_92
            Reporter: Chao Wang
            Assignee: Tomaz Cerar
             Fix For: 12.0.0.Alpha1


build.bat clean install failed with
-------------------------------------------------------------------------------
Test set: org.jboss.as.test.integration.jsp.JspTagTestCase
-------------------------------------------------------------------------------
Tests run: 1, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.768 sec <<< FAILURE! - in org.jboss.as.test.integration.jsp.JspTagTestCase
test(org.jboss.as.test.integration.jsp.JspTagTestCase)  Time elapsed: 0.486 sec  <<< FAILURE!
org.junit.ComparisonFailure: expected:<This is a header[


<div>tag</div>

Static content]
> but was:<This is a header[


<div>tag</div>

Static content
]
>
	at org.junit.Assert.assertEquals(Assert.java:115)
	at org.junit.Assert.assertEquals(Assert.java:144)
	at org.jboss.as.test.integration.jsp.JspTagTestCase.test(JspTagTestCase.java:67)

Replacing all occurence of "\n" with System.getProperty("line.separator") in the expected String solved the problem for me.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 02:51:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 29 Jan 2018 02:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9741) Upgrade WildFly Http Client
	to 1.0.9
In-Reply-To: <JIRA.12731249.1517212224000@Atlassian.JIRA>
References: <JIRA.12731249.1517212224000@Atlassian.JIRA>
	<JIRA.12731249.1517212224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731249.1517212224000.109561.1517212260708@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky moved JBEAP-14161 to WFLY-9741:
---------------------------------------------

        Project: WildFly  (was: JBoss Enterprise Application Platform)
            Key: WFLY-9741  (was: JBEAP-14161)
       Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
    Component/s: Web (Undertow)
                     (was: Web (Undertow))


> Upgrade WildFly Http Client to 1.0.9
> ------------------------------------
>
>                 Key: WFLY-9741
>                 URL: https://issues.jboss.org/browse/WFLY-9741
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web (Undertow)
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 02:52:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 29 Jan 2018 02:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9741) Upgrade WildFly Http Client
	to 1.0.9
In-Reply-To: <JIRA.12731249.1517212224000@Atlassian.JIRA>
References: <JIRA.12731249.1517212224000@Atlassian.JIRA>
	<JIRA.12731249.1517212224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731249.1517212224000.109567.1517212320383@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky reassigned WFLY-9741:
-----------------------------------

    Assignee: Stuart Douglas  (was: Ivo Studensky)


> Upgrade WildFly Http Client to 1.0.9
> ------------------------------------
>
>                 Key: WFLY-9741
>                 URL: https://issues.jboss.org/browse/WFLY-9741
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web (Undertow)
>            Reporter: Ivo Studensky
>            Assignee: Stuart Douglas
>              Labels: downstream_dependency
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 02:52:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 29 Jan 2018 02:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9741) Upgrade WildFly Http Client
	to 1.0.9
In-Reply-To: <JIRA.12731249.1517212224000@Atlassian.JIRA>
References: <JIRA.12731249.1517212224000@Atlassian.JIRA>
	<JIRA.12731249.1517212224000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731249.1517212224000.109572.1517212320564@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9741?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated WFLY-9741:
--------------------------------
    Labels: downstream_dependency  (was: )


> Upgrade WildFly Http Client to 1.0.9
> ------------------------------------
>
>                 Key: WFLY-9741
>                 URL: https://issues.jboss.org/browse/WFLY-9741
>             Project: WildFly
>          Issue Type: Component Upgrade
>          Components: Web (Undertow)
>            Reporter: Ivo Studensky
>            Assignee: Stuart Douglas
>              Labels: downstream_dependency
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 04:36:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 29 Jan 2018 04:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2279) Realign extension registers
 test to master using DMNProfile
In-Reply-To: <JIRA.12731264.1517218507000@Atlassian.JIRA>
References: <JIRA.12731264.1517218507000@Atlassian.JIRA>
	<JIRA.12731264.1517218507733@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731264.1517218507000.110083.1517218560326@Atlassian.JIRA>

Matteo Mortari created DROOLS-2279:
--------------------------------------

             Summary: Realign extension registers test to master using DMNProfile
                 Key: DROOLS-2279
                 URL: https://issues.jboss.org/browse/DROOLS-2279
             Project: Drools
          Issue Type: Task
          Components: dmn engine
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari


Following work on [DROOLS-2264] the DMN extension register mechanism is no longer supported.

In order to use extension registers, it is now required to configure them using a DMNProfile.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 05:27:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 29 Jan 2018 05:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1505)
 org.wildfly.security.asn1.DEREncoderTest fails on new JDK 7v.161
In-Reply-To: <JIRA.12731270.1517221559000@Atlassian.JIRA>
References: <JIRA.12731270.1517221559000@Atlassian.JIRA>
	<JIRA.12731270.1517221559667@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731270.1517221559000.110344.1517221620549@Atlassian.JIRA>

Ivo Studensky created ELY-1505:
----------------------------------

             Summary: org.wildfly.security.asn1.DEREncoderTest fails on new JDK 7v.161
                 Key: ELY-1505
                 URL: https://issues.jboss.org/browse/ELY-1505
             Project: WildFly Elytron
          Issue Type: Bug
          Components: Testsuite
            Reporter: Ivo Studensky
            Priority: Minor


The org.wildfly.security.asn1.DEREncoderTest#testEncodeDSAKey() fails on JDK7 v.161 due to:
{noformat}
[ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.124 s  <<< ERROR!
java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
	at sun.security.provider.DSA.checkKey(DSA.java:111)
	at sun.security.provider.DSA.engineInitSign(DSA.java:143)
	at java.security.Signature$Delegate.init(Signature.java:1156)
	at java.security.Signature$Delegate.chooseProvider(Signature.java:1116)
	at java.security.Signature$Delegate.engineInitSign(Signature.java:1180)
	at java.security.Signature.initSign(Signature.java:531)
	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:458)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
{noformat}

It affects also older tags, not only 1.1.8. It might be related to 
https://bugs.java.com/view_bug.do?bug_id=8184341

It seems to be a testsuite issue only.




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 05:27:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 29 Jan 2018 05:27:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1505)
 org.wildfly.security.asn1.DEREncoderTest fails on new JDK7 v.161
In-Reply-To: <JIRA.12731270.1517221560000@Atlassian.JIRA>
References: <JIRA.12731270.1517221560000@Atlassian.JIRA>
	<JIRA.12731270.1517221560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731270.1517221560000.110353.1517221620862@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated ELY-1505:
-------------------------------
    Summary: org.wildfly.security.asn1.DEREncoderTest fails on new JDK7 v.161  (was: org.wildfly.security.asn1.DEREncoderTest fails on new JDK 7v.161)


> org.wildfly.security.asn1.DEREncoderTest fails on new JDK7 v.161
> ----------------------------------------------------------------
>
>                 Key: ELY-1505
>                 URL: https://issues.jboss.org/browse/ELY-1505
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Ivo Studensky
>            Priority: Minor
>
> The org.wildfly.security.asn1.DEREncoderTest#testEncodeDSAKey() fails on JDK7 v.161 due to:
> {noformat}
> [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.124 s  <<< ERROR!
> java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> 	at sun.security.provider.DSA.checkKey(DSA.java:111)
> 	at sun.security.provider.DSA.engineInitSign(DSA.java:143)
> 	at java.security.Signature$Delegate.init(Signature.java:1156)
> 	at java.security.Signature$Delegate.chooseProvider(Signature.java:1116)
> 	at java.security.Signature$Delegate.engineInitSign(Signature.java:1180)
> 	at java.security.Signature.initSign(Signature.java:531)
> 	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:458)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {noformat}
> It affects also older tags, not only 1.1.8. It might be related to 
> https://bugs.java.com/view_bug.do?bug_id=8184341
> It seems to be a testsuite issue only.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 05:32:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 29 Jan 2018 05:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1505)
 org.wildfly.security.asn1.DEREncoderTest fails on new JDK7 v.161
In-Reply-To: <JIRA.12731270.1517221560000@Atlassian.JIRA>
References: <JIRA.12731270.1517221560000@Atlassian.JIRA>
	<JIRA.12731270.1517221560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731270.1517221560000.110372.1517221920212@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky reassigned ELY-1505:
----------------------------------

    Assignee: Ivo Studensky


> org.wildfly.security.asn1.DEREncoderTest fails on new JDK7 v.161
> ----------------------------------------------------------------
>
>                 Key: ELY-1505
>                 URL: https://issues.jboss.org/browse/ELY-1505
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>            Priority: Minor
>
> The org.wildfly.security.asn1.DEREncoderTest#testEncodeDSAKey() fails on JDK7 v.161 due to:
> {noformat}
> [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.124 s  <<< ERROR!
> java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> 	at sun.security.provider.DSA.checkKey(DSA.java:111)
> 	at sun.security.provider.DSA.engineInitSign(DSA.java:143)
> 	at java.security.Signature$Delegate.init(Signature.java:1156)
> 	at java.security.Signature$Delegate.chooseProvider(Signature.java:1116)
> 	at java.security.Signature$Delegate.engineInitSign(Signature.java:1180)
> 	at java.security.Signature.initSign(Signature.java:531)
> 	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:458)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {noformat}
> It affects also older tags, not only 1.1.8. It might be related to 
> https://bugs.java.com/view_bug.do?bug_id=8184341
> It seems to be a testsuite issue only.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 05:32:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 29 Jan 2018 05:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1505)
 org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
In-Reply-To: <JIRA.12731270.1517221560000@Atlassian.JIRA>
References: <JIRA.12731270.1517221560000@Atlassian.JIRA>
	<JIRA.12731270.1517221560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731270.1517221560000.110375.1517221920316@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated ELY-1505:
-------------------------------
    Summary: org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161  (was: org.wildfly.security.asn1.DEREncoderTest fails on new JDK7 v.161)


> org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
> ----------------------------------------------------------------
>
>                 Key: ELY-1505
>                 URL: https://issues.jboss.org/browse/ELY-1505
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>            Priority: Minor
>
> The org.wildfly.security.asn1.DEREncoderTest#testEncodeDSAKey() fails on JDK7 v.161 due to:
> {noformat}
> [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.124 s  <<< ERROR!
> java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> 	at sun.security.provider.DSA.checkKey(DSA.java:111)
> 	at sun.security.provider.DSA.engineInitSign(DSA.java:143)
> 	at java.security.Signature$Delegate.init(Signature.java:1156)
> 	at java.security.Signature$Delegate.chooseProvider(Signature.java:1116)
> 	at java.security.Signature$Delegate.engineInitSign(Signature.java:1180)
> 	at java.security.Signature.initSign(Signature.java:531)
> 	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:458)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {noformat}
> It affects also older tags, not only 1.1.8. It might be related to 
> https://bugs.java.com/view_bug.do?bug_id=8184341
> It seems to be a testsuite issue only.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 05:33:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 29 Jan 2018 05:33:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1505)
 org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
In-Reply-To: <JIRA.12731270.1517221560000@Atlassian.JIRA>
References: <JIRA.12731270.1517221560000@Atlassian.JIRA>
	<JIRA.12731270.1517221560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731270.1517221560000.110378.1517221980365@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky updated ELY-1505:
-------------------------------
    Description: 
The org.wildfly.security.asn1.DEREncoderTest#testEncodeDSAKey() fails on JDK8 v.161 due to:
{noformat}
[ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.124 s  <<< ERROR!
java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
	at sun.security.provider.DSA.checkKey(DSA.java:111)
	at sun.security.provider.DSA.engineInitSign(DSA.java:143)
	at java.security.Signature$Delegate.init(Signature.java:1156)
	at java.security.Signature$Delegate.chooseProvider(Signature.java:1116)
	at java.security.Signature$Delegate.engineInitSign(Signature.java:1180)
	at java.security.Signature.initSign(Signature.java:531)
	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:458)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
{noformat}

It affects also older tags, not only 1.1.8. It might be related to 
https://bugs.java.com/view_bug.do?bug_id=8184341

It seems to be a testsuite issue only.


  was:
The org.wildfly.security.asn1.DEREncoderTest#testEncodeDSAKey() fails on JDK7 v.161 due to:
{noformat}
[ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.124 s  <<< ERROR!
java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
	at sun.security.provider.DSA.checkKey(DSA.java:111)
	at sun.security.provider.DSA.engineInitSign(DSA.java:143)
	at java.security.Signature$Delegate.init(Signature.java:1156)
	at java.security.Signature$Delegate.chooseProvider(Signature.java:1116)
	at java.security.Signature$Delegate.engineInitSign(Signature.java:1180)
	at java.security.Signature.initSign(Signature.java:531)
	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:458)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:498)
	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
{noformat}

It affects also older tags, not only 1.1.8. It might be related to 
https://bugs.java.com/view_bug.do?bug_id=8184341

It seems to be a testsuite issue only.




> org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
> ----------------------------------------------------------------
>
>                 Key: ELY-1505
>                 URL: https://issues.jboss.org/browse/ELY-1505
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Ivo Studensky
>            Assignee: Ivo Studensky
>            Priority: Minor
>
> The org.wildfly.security.asn1.DEREncoderTest#testEncodeDSAKey() fails on JDK8 v.161 due to:
> {noformat}
> [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.124 s  <<< ERROR!
> java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> 	at sun.security.provider.DSA.checkKey(DSA.java:111)
> 	at sun.security.provider.DSA.engineInitSign(DSA.java:143)
> 	at java.security.Signature$Delegate.init(Signature.java:1156)
> 	at java.security.Signature$Delegate.chooseProvider(Signature.java:1116)
> 	at java.security.Signature$Delegate.engineInitSign(Signature.java:1180)
> 	at java.security.Signature.initSign(Signature.java:531)
> 	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:458)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {noformat}
> It affects also older tags, not only 1.1.8. It might be related to 
> https://bugs.java.com/view_bug.do?bug_id=8184341
> It seems to be a testsuite issue only.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 05:41:00 2018
From: issues at jboss.org (Jozef Marko (JIRA))
Date: Mon, 29 Jan 2018 05:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1966) [DMN Editor] Ensure UI
 model has hashCode/equals implementations
In-Reply-To: <JIRA.12698102.1497948438000@Atlassian.JIRA>
References: <JIRA.12698102.1497948438000@Atlassian.JIRA>
	<JIRA.12698102.1497948438000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12698102.1497948438000.110409.1517222460284@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525105#comment-13525105 ] 

Jozef Marko commented on DROOLS-1966:
-------------------------------------

[~manstis] Hi, I just wanted ask, if we still plan to add some model classes, in other words, isn't there the right time for this task?

> [DMN Editor] Ensure UI model has hashCode/equals implementations
> ----------------------------------------------------------------
>
>                 Key: DROOLS-1966
>                 URL: https://issues.jboss.org/browse/DROOLS-1966
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> See https://github.com/kiegroup/kie-wb-common/pull/920 (for Stunner's implementation).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 05:57:00 2018
From: issues at jboss.org (Michael Anstis (JIRA))
Date: Mon, 29 Jan 2018 05:57:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1966) [DMN Editor] Ensure UI
 model has hashCode/equals implementations
In-Reply-To: <JIRA.12698102.1497948438000@Atlassian.JIRA>
References: <JIRA.12698102.1497948438000@Atlassian.JIRA>
	<JIRA.12698102.1497948438000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12698102.1497948438000.110486.1517223420485@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-1966?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525108#comment-13525108 ] 

Michael Anstis commented on DROOLS-1966:
----------------------------------------

Hi [~jomarko] we have lots of model classes already; but they lack implementation of {{equals( o )}} and {{hashCode()}} methods.

See:
https://github.com/kiegroup/kie-wb-common/tree/master/kie-wb-common-dmn/kie-wb-common-dmn-api/src/main/java/org/kie/workbench/common/dmn/api/definition
https://github.com/kiegroup/kie-wb-common/tree/master/kie-wb-common-dmn/kie-wb-common-dmn-api/src/main/java/org/kie/workbench/common/dmn/api/property

This means the "dirty" mechanism will not work properly when opening, changing (for example a property) and saving.

> [DMN Editor] Ensure UI model has hashCode/equals implementations
> ----------------------------------------------------------------
>
>                 Key: DROOLS-1966
>                 URL: https://issues.jboss.org/browse/DROOLS-1966
>             Project: Drools
>          Issue Type: Task
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> See https://github.com/kiegroup/kie-wb-common/pull/920 (for Stunner's implementation).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 07:17:00 2018
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Mon, 29 Jan 2018 07:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2233) DMN:
 time(date("2017-08-10")) should return 00:00:00z time
In-Reply-To: <JIRA.12727497.1515672063000@Atlassian.JIRA>
References: <JIRA.12727497.1515672063000@Atlassian.JIRA>
	<JIRA.12727497.1515672063000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727497.1515672063000.58.1517228220168@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525214#comment-13525214 ] 

Tibor Zim?nyi commented on DROOLS-2233:
---------------------------------------

Merged as part of this PR https://github.com/kiegroup/drools/pull/1711

> DMN: time(date("2017-08-10")) should return 00:00:00z time
> ----------------------------------------------------------
>
>                 Key: DROOLS-2233
>                 URL: https://issues.jboss.org/browse/DROOLS-2233
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Tibor Zim?nyi
>             Fix For: 7.6.0.Final
>
>
> According to the specification in section "10.3.2.3.5 date": 
> "Where necessary, including the valuedt function (see 10.3.2.x.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00)."
> Currently the case time(date("2017-08-10")) returns null, because the evaluation ends with DateTimeException, because internally we represent dates as LocalDate class, which doesn't have time part. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 29 07:17:00 2018
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Mon, 29 Jan 2018 07:17:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2233) DMN:
 time(date("2017-08-10")) should return 00:00:00z time
In-Reply-To: <JIRA.12727497.1515672063000@Atlassian.JIRA>
References: <JIRA.12727497.1515672063000@Atlassian.JIRA>
	<JIRA.12727497.1515672063000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12727497.1515672063000.60.1517228220255@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2233?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tibor Zim?nyi resolved DROOLS-2233.
-----------------------------------
    Fix Version/s: 7.6.0.Final
       Resolution: Done


> DMN: time(date("2017-08-10")) should return 00:00:00z time
> ----------------------------------------------------------
>
>                 Key: DROOLS-2233
>                 URL: https://issues.jboss.org/browse/DROOLS-2233
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Tibor Zim?nyi
>             Fix For: 7.6.0.Final
>
>
> According to the specification in section "10.3.2.3.5 date": 
> "Where necessary, including the valuedt function (see 10.3.2.x.6), a date value is considered to be equivalent to a date time value in which the time of day is UTC midnight (00:00:00)."
> Currently the case time(date("2017-08-10")) returns null, because the evaluation ends with DateTimeException, because internally we represent dates as LocalDate class, which doesn't have time part. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 29 09:11:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 29 Jan 2018 09:11:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1505)
 org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
In-Reply-To: <JIRA.12731270.1517221560000@Atlassian.JIRA>
References: <JIRA.12731270.1517221560000@Atlassian.JIRA>
	<JIRA.12731270.1517221560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731270.1517221560000.1213.1517235060469@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina reassigned ELY-1505:
-------------------------------

    Assignee: Jan Kalina  (was: Ivo Studensky)


> org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
> ----------------------------------------------------------------
>
>                 Key: ELY-1505
>                 URL: https://issues.jboss.org/browse/ELY-1505
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Ivo Studensky
>            Assignee: Jan Kalina
>            Priority: Minor
>
> The org.wildfly.security.asn1.DEREncoderTest#testEncodeDSAKey() fails on JDK8 v.161 due to:
> {noformat}
> [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.124 s  <<< ERROR!
> java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> 	at sun.security.provider.DSA.checkKey(DSA.java:111)
> 	at sun.security.provider.DSA.engineInitSign(DSA.java:143)
> 	at java.security.Signature$Delegate.init(Signature.java:1156)
> 	at java.security.Signature$Delegate.chooseProvider(Signature.java:1116)
> 	at java.security.Signature$Delegate.engineInitSign(Signature.java:1180)
> 	at java.security.Signature.initSign(Signature.java:531)
> 	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:458)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {noformat}
> It affects also older tags, not only 1.1.8. It might be related to 
> https://bugs.java.com/view_bug.do?bug_id=8184341
> It seems to be a testsuite issue only.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 09:51:00 2018
From: issues at jboss.org (Markus Dlugi (JIRA))
Date: Mon, 29 Jan 2018 09:51:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9742) ClassLoader leak in JBoss
 Threads caused by MDBs
In-Reply-To: <JIRA.12731375.1517237459000@Atlassian.JIRA>
References: <JIRA.12731375.1517237459000@Atlassian.JIRA>
	<JIRA.12731375.1517237459181@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731375.1517237459000.1622.1517237460484@Atlassian.JIRA>

Markus Dlugi created WFLY-9742:
----------------------------------

             Summary: ClassLoader leak in JBoss Threads caused by MDBs
                 Key: WFLY-9742
                 URL: https://issues.jboss.org/browse/WFLY-9742
             Project: WildFly
          Issue Type: Bug
    Affects Versions: 11.0.0.Final
            Reporter: Markus Dlugi
            Assignee: Jason Greene
         Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip

There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs. When a new MDB is created and a new thread for the MDB is started in the JCA thread pool ("default-threads - x"), the thread will be created using the context classloader of the MDB's deployment unit. This is because [MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/messagedriven/MessageDrivenComponent.java#L275] sets the context classloader of the ServerService thread in order to create the MDB, and this classloader will then also be used by the child thread.

In the default configuration, the threads in the default thread pool will not be terminated and therefore the thread will keep the reference to the classloader even when the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError: Metaspace" after a couple of redeployments.

As a workaround, we changed [JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-threads/blob/master/src/main/java/org/jboss/threads/JBossThreadFactory.java#L104] to set the context classloader to null after a new thread has been created. While this fixes the issue for us, I am not sure whether this is a good solution for all consumers of the thread factory, or if this should be fixed in the JCA subsystem instead. That's also the reason why I opened this issue against the WildFly project instead of JBoss Threads.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 10:08:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Mon, 29 Jan 2018 10:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2279) Realign extension registers
 test to master using DMNProfile
In-Reply-To: <JIRA.12731264.1517218508000@Atlassian.JIRA>
References: <JIRA.12731264.1517218508000@Atlassian.JIRA>
	<JIRA.12731264.1517218508000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731264.1517218508000.1839.1517238480457@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2279?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525404#comment-13525404 ] 

Matteo Mortari commented on DROOLS-2279:
----------------------------------------

Fixed with https://github.com/kiegroup/drools/commit/7997f8505a391eaa35506361d47e80a281b8cfab

As a result of [DROOLS-2264] the original extension register configuration mechanism is no longer supported.
In order to use extension registers, it is now required to configure them using a DMNProfile.

Migration guide.
Can reference commit [7997f850|https://github.com/kiegroup/drools/commit/7997f8505a391eaa35506361d47e80a281b8cfab] for an example of migration.

1. Create a DMNProfile with the desired extension registers. Example [create DMNProfile|https://github.com/kiegroup/drools/commit/7997f8505a391eaa35506361d47e80a281b8cfab#diff-3da931fb28aa23a8b5bb0142fabbf07dR21]

2. replace old configuration of extension register (system property or kmodule entry) with the configuration of the new DMNProfile created from step1. Examples:
[Replace system property|https://github.com/kiegroup/drools/commit/7997f8505a391eaa35506361d47e80a281b8cfab#diff-268b8210dd41982e5417d3778418dcfeL54], [replace kmodule entry|https://github.com/kiegroup/drools/commit/7997f8505a391eaa35506361d47e80a281b8cfab#diff-268b8210dd41982e5417d3778418dcfeL99]

 

> Realign extension registers test to master using DMNProfile
> -----------------------------------------------------------
>
>                 Key: DROOLS-2279
>                 URL: https://issues.jboss.org/browse/DROOLS-2279
>             Project: Drools
>          Issue Type: Task
>          Components: dmn engine
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>
> Following work on [DROOLS-2264] the DMN extension register mechanism is no longer supported.
> In order to use extension registers, it is now required to configure them using a DMNProfile.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 10:31:00 2018
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Mon, 29 Jan 2018 10:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2280) Test
 RuleUnitTest.testNamingConventionOnDrlFile() uses OS specific separator
 character
In-Reply-To: <JIRA.12731384.1517239802000@Atlassian.JIRA>
References: <JIRA.12731384.1517239802000@Atlassian.JIRA>
	<JIRA.12731384.1517239802827@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731384.1517239802000.2004.1517239860517@Atlassian.JIRA>

Tibor Zim?nyi created DROOLS-2280:
-------------------------------------

             Summary: Test RuleUnitTest.testNamingConventionOnDrlFile() uses OS specific separator character
                 Key: DROOLS-2280
                 URL: https://issues.jboss.org/browse/DROOLS-2280
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.5.0.Final
            Reporter: Tibor Zim?nyi
            Assignee: Tibor Zim?nyi
            Priority: Minor


When running testNamingConventionOnDrlFile test on Windows, it fails on NPE, because the engine cannot find the rule unit "org/kie/test/MyRuleUnit" defined in the test, because it contains "/" separator character. 

I will provide a fix to the test. 

For resolving the rule unit class, the engine uses OS independent character correctly here [1].

[1] https://github.com/kiegroup/drools/blob/5fad04919f255933bdd34afdb8da10b94f2c8c43/drools-compiler/src/main/java/org/drools/compiler/rule/builder/RuleBuildContext.java#L184



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 29 10:35:08 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 29 Jan 2018 10:35:08 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1946) DMN Editor
In-Reply-To: <JIRA.12696991.1497281558000@Atlassian.JIRA>
References: <JIRA.12696991.1497281558000@Atlassian.JIRA>
	<JIRA.12696991.1497281558000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696991.1497281558000.2061.1517240108173@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1946:
-----------------------------------
    Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06  (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04)


> DMN Editor
> ----------
>
>                 Key: DROOLS-1946
>                 URL: https://issues.jboss.org/browse/DROOLS-1946
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>              Labels: UX
>             Fix For: 7.6.0.Final
>
>
> Place holder for all DMN Editor related activities



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 10:35:10 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 29 Jan 2018 10:35:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1825) [Guided Decision Table]
 Ability to change HIT policy in a decision table anytime
In-Reply-To: <JIRA.12697420.1497441043000@Atlassian.JIRA>
References: <JIRA.12697420.1497441043000@Atlassian.JIRA>
	<JIRA.12697420.1497441043000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12697420.1497441043000.2142.1517240110240@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1825:
-----------------------------------
    Sprint: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06  (was: 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04)


> [Guided Decision Table] Ability to change HIT policy in a decision table anytime
> --------------------------------------------------------------------------------
>
>                 Key: DROOLS-1825
>                 URL: https://issues.jboss.org/browse/DROOLS-1825
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.1.0.Beta2
>            Reporter: Ivo Bek
>            Assignee: Toni Rikkola
>            Priority: Critical
>              Labels: UX
>         Attachments: DROOLS-1825 (Parent Rule).png, DecisionTable1.png, DecisionTable2.png, GDTAnalysis at 2x.png, GDTColumns at 2x.png
>
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> Today, it's possible to set 1 of 5 HIT policies when we create a new guided decision table. However, the user might not know which HIT policy he/she should use at this early beginning. Therefore, it should be possible to set the policy to None when we create a new guided decision table and set the HIT policy later after we add columns and rows, fill in some data and see and decide based on the created table how the rules should behave using the HIT policy.
> Thus, it should be possible to change HIT policy in a decision table anytime.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 10:35:10 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 29 Jan 2018 10:35:10 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1609) Augment FEEL AST node at
 compilation with return type
In-Reply-To: <JIRA.12696318.1496844128000@Atlassian.JIRA>
References: <JIRA.12696318.1496844128000@Atlassian.JIRA>
	<JIRA.12696318.1496844128000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12696318.1496844128000.2148.1517240110370@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1609?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1609:
-----------------------------------
    Sprint: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06  (was: 2017 Week 24-25, 2017 Week 26-27, 2017 Week 28-29, 2017 Week 30-31, 2017 Week 32-33, 2017 Week 34-35, 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04)


> Augment FEEL AST node at compilation with return type
> -----------------------------------------------------
>
>                 Key: DROOLS-1609
>                 URL: https://issues.jboss.org/browse/DROOLS-1609
>             Project: Drools
>          Issue Type: Enhancement
>          Components: dmn engine
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>            Priority: Minor
>
> This is needed so to be able to determine the result of a boxed function at compile time, in turn to be able at compile time to determine a valid compilation without error of a BKM for instance.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 10:35:11 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 29 Jan 2018 10:35:11 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1701) FEEL code generation and
	compilation
In-Reply-To: <JIRA.12707146.1502459679000@Atlassian.JIRA>
References: <JIRA.12707146.1502459679000@Atlassian.JIRA>
	<JIRA.12707146.1502459679000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12707146.1502459679000.2172.1517240111388@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1701:
-----------------------------------
    Sprint: 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06  (was: 2017 Week 36-37, 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04)


> FEEL code generation and compilation
> ------------------------------------
>
>                 Key: DROOLS-1701
>                 URL: https://issues.jboss.org/browse/DROOLS-1701
>             Project: Drools
>          Issue Type: Task
>          Components: dmn engine
>            Reporter: Matteo Mortari
>            Assignee: Matteo Mortari
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 10:35:12 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 29 Jan 2018 10:35:12 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-1795) [Guided Decision Table]
 Invalid error message when renaming bound variable name in conditional BRL
 column.
In-Reply-To: <JIRA.12712612.1505924833000@Atlassian.JIRA>
References: <JIRA.12712612.1505924833000@Atlassian.JIRA>
	<JIRA.12712612.1505924833000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12712612.1505924833000.2196.1517240112111@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-1795?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-1795:
-----------------------------------
    Sprint: 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06  (was: 2017 Week 38-39, 2017 Week 40-41-42, 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04)


> [Guided Decision Table] Invalid error message when renaming bound variable name in conditional BRL column.
> ----------------------------------------------------------------------------------------------------------
>
>                 Key: DROOLS-1795
>                 URL: https://issues.jboss.org/browse/DROOLS-1795
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>    Affects Versions: 7.0.0.Final
>            Reporter: Mark Coble
>            Assignee: Mark Coble
>            Priority: Minor
>             Fix For: 7.0.0.Final
>
>         Attachments: guvnor-3507.png
>
>
> If a condition BRL column is added to a DT with bound variables that are used in an action column and that variable name is subsequently changed, the attached error message occurs when updating the action column with the new variable name.   In the attached message the original variable name is 'app'.  Hitting 'ok' returns you to the DT which has actually refactored the DT with the new variable name and validation is successful.  



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 10:35:13 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 29 Jan 2018 10:35:13 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2109) [XLS Decision Table] New
 Asset Dialogue misses descriptions
In-Reply-To: <JIRA.12719362.1509700869000@Atlassian.JIRA>
References: <JIRA.12719362.1509700869000@Atlassian.JIRA>
	<JIRA.12719362.1509700869000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12719362.1509700869000.2229.1517240113333@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2109:
-----------------------------------
    Sprint: 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06  (was: 2017 Week 43-44, 2017 Week 45-46, 2017 Week 47-48, 2017 Week 49-50, 2017 Week 51-52, 2018 Week 01-02, 2018 Week 03-04)


> [XLS Decision Table] New Asset Dialogue misses descriptions
> -----------------------------------------------------------
>
>                 Key: DROOLS-2109
>                 URL: https://issues.jboss.org/browse/DROOLS-2109
>             Project: Drools
>          Issue Type: Bug
>          Components: XLS Decision Table Editor
>    Affects Versions: 7.5.0.Final
>            Reporter: Jozef Marko
>            Assignee: Jozef Marko
>            Priority: Optional
>         Attachments: Screenshot from 2017-11-03 10-20-21.png
>
>
> The attached dialogue shows missing descriptions for table format and file selector.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 10:35:14 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 29 Jan 2018 10:35:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2214) [DMN Editor] Content of the
 decision node is not copied
In-Reply-To: <JIRA.12726674.1515132440000@Atlassian.JIRA>
References: <JIRA.12726674.1515132440000@Atlassian.JIRA>
	<JIRA.12726674.1515132440000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726674.1515132440000.2275.1517240114816@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2214:
-----------------------------------
    Sprint: 2018 Week 03-04, 2018 Week 05-06  (was: 2018 Week 03-04)


> [DMN Editor] Content of the decision node is not copied
> -------------------------------------------------------
>
>                 Key: DROOLS-2214
>                 URL: https://issues.jboss.org/browse/DROOLS-2214
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Michael Anstis
>              Labels: Stunner
>
> User has possibility to copy a DRG node by a CTRL+C shortcut, however the problem is that content of the node is not copied.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 10:35:14 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 29 Jan 2018 10:35:14 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2217) [DMN Editor] Allow DMN
 persistence for an incomplete, still being authored, DMN model
In-Reply-To: <JIRA.12726677.1515133515000@Atlassian.JIRA>
References: <JIRA.12726677.1515133515000@Atlassian.JIRA>
	<JIRA.12726677.1515133515000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12726677.1515133515000.2280.1517240114998@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2217?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2217:
-----------------------------------
    Sprint: 2018 Week 01-02, 2018 Week 03-04, 2018 Week 05-06  (was: 2018 Week 01-02, 2018 Week 03-04)


> [DMN Editor] Allow DMN persistence for an incomplete, still being authored, DMN model
> -------------------------------------------------------------------------------------
>
>                 Key: DROOLS-2217
>                 URL: https://issues.jboss.org/browse/DROOLS-2217
>             Project: Drools
>          Issue Type: Bug
>          Components: DMN Editor
>    Affects Versions: 7.6.0.Final
>            Reporter: Jozef Marko
>            Assignee: Matteo Mortari
>         Attachments: Screenshot from 2018-01-22 14-01-38.png, Screenshot from 2018-01-22 14-02-13.png, error.log
>
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 10:35:16 2018
From: issues at jboss.org (Kris Verlaenen (JIRA))
Date: Mon, 29 Jan 2018 10:35:16 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2273) [DMN Editor] Contextual
 selection - Hover state
In-Reply-To: <JIRA.12730777.1516881868000@Atlassian.JIRA>
References: <JIRA.12730777.1516881868000@Atlassian.JIRA>
	<JIRA.12730777.1516881868000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730777.1516881868000.2306.1517240116095@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2273?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Kris Verlaenen updated DROOLS-2273:
-----------------------------------
    Sprint: 2018 Week 03-04, 2018 Week 05-06  (was: 2018 Week 03-04)


> [DMN Editor] Contextual selection - Hover state
> -----------------------------------------------
>
>                 Key: DROOLS-2273
>                 URL: https://issues.jboss.org/browse/DROOLS-2273
>             Project: Drools
>          Issue Type: Feature Request
>          Components: DMN Editor
>            Reporter: Michael Anstis
>            Assignee: Michael Anstis
>
> Elements within a logic table that offer contextual actions will present a hover state on focus. Examples of elements that might offer actions include: Rows, cells, columns, table? Or in context terms: Rules, Inputs/Outputs, Context row, etc



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Mon Jan 29 11:25:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 29 Jan 2018 11:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1505)
 org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
In-Reply-To: <JIRA.12731270.1517221560000@Atlassian.JIRA>
References: <JIRA.12731270.1517221560000@Atlassian.JIRA>
	<JIRA.12731270.1517221560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731270.1517221560000.2613.1517243100500@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525464#comment-13525464 ] 

Jan Kalina commented on ELY-1505:
---------------------------------

[~istudens] I am testing against *Oracle-jdk-8u161* (from Oracle's tar.gz) on Fedora 27 and the test succeed. How has you achieved it?

> org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
> ----------------------------------------------------------------
>
>                 Key: ELY-1505
>                 URL: https://issues.jboss.org/browse/ELY-1505
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Ivo Studensky
>            Assignee: Jan Kalina
>            Priority: Minor
>
> The org.wildfly.security.asn1.DEREncoderTest#testEncodeDSAKey() fails on JDK8 v.161 due to:
> {noformat}
> [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.124 s  <<< ERROR!
> java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> 	at sun.security.provider.DSA.checkKey(DSA.java:111)
> 	at sun.security.provider.DSA.engineInitSign(DSA.java:143)
> 	at java.security.Signature$Delegate.init(Signature.java:1156)
> 	at java.security.Signature$Delegate.chooseProvider(Signature.java:1116)
> 	at java.security.Signature$Delegate.engineInitSign(Signature.java:1180)
> 	at java.security.Signature.initSign(Signature.java:531)
> 	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:458)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {noformat}
> It affects also older tags, not only 1.1.8. It might be related to 
> https://bugs.java.com/view_bug.do?bug_id=8184341
> It seems to be a testsuite issue only.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 11:26:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 29 Jan 2018 11:26:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1505)
 org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
In-Reply-To: <JIRA.12731270.1517221560000@Atlassian.JIRA>
References: <JIRA.12731270.1517221560000@Atlassian.JIRA>
	<JIRA.12731270.1517221560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731270.1517221560000.2620.1517243160208@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525464#comment-13525464 ] 

Jan Kalina edited comment on ELY-1505 at 1/29/18 11:25 AM:
-----------------------------------------------------------

[~istudens] I am testing against *Oracle-jdk-8u161* (from Oracle's tar.gz) on Fedora 27 and the test succeed. How has you achieved it?

{code}
JAVA_HOME=/opt/Oracle-jdk-8u161 PATH=/opt/Oracle-jdk-8u161/bin/:$PATH mvn test -Dtest=org.wildfly.security.asn1.DEREncoderTest
{code}
{code}
[INFO] Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.212 s - in org.wildfly.security.asn1.DEREncoderTest
{code}


was (Author: honza889):
[~istudens] I am testing against *Oracle-jdk-8u161* (from Oracle's tar.gz) on Fedora 27 and the test succeed. How has you achieved it?

> org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
> ----------------------------------------------------------------
>
>                 Key: ELY-1505
>                 URL: https://issues.jboss.org/browse/ELY-1505
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Ivo Studensky
>            Assignee: Jan Kalina
>            Priority: Minor
>
> The org.wildfly.security.asn1.DEREncoderTest#testEncodeDSAKey() fails on JDK8 v.161 due to:
> {noformat}
> [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.124 s  <<< ERROR!
> java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> 	at sun.security.provider.DSA.checkKey(DSA.java:111)
> 	at sun.security.provider.DSA.engineInitSign(DSA.java:143)
> 	at java.security.Signature$Delegate.init(Signature.java:1156)
> 	at java.security.Signature$Delegate.chooseProvider(Signature.java:1116)
> 	at java.security.Signature$Delegate.engineInitSign(Signature.java:1180)
> 	at java.security.Signature.initSign(Signature.java:531)
> 	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:458)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {noformat}
> It affects also older tags, not only 1.1.8. It might be related to 
> https://bugs.java.com/view_bug.do?bug_id=8184341
> It seems to be a testsuite issue only.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 11:30:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 29 Jan 2018 11:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1506) Test intermediate CA certs for
 client SSL auth
In-Reply-To: <JIRA.12731402.1517243381000@Atlassian.JIRA>
References: <JIRA.12731402.1517243381000@Atlassian.JIRA>
	<JIRA.12731402.1517243381329@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731402.1517243381000.2651.1517243400472@Atlassian.JIRA>

Jan Kalina created ELY-1506:
-------------------------------

             Summary: Test intermediate CA certs for client SSL auth
                 Key: ELY-1506
                 URL: https://issues.jboss.org/browse/ELY-1506
             Project: WildFly Elytron
          Issue Type: Task
    Affects Versions: 1.2.0.Beta12
            Reporter: Jan Kalina
            Assignee: Jan Kalina


Into Elytron SSL tests should be added test with intermediate CA:

* Root CA cert will be present in server truststore
* Intermediate CA cert will be signed by Root CA
* client cert will be signed by intermediate CA and used by client



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 11:30:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 29 Jan 2018 11:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1506) Test intermediate CA certs for
 client SSL auth
In-Reply-To: <JIRA.12731402.1517243381000@Atlassian.JIRA>
References: <JIRA.12731402.1517243381000@Atlassian.JIRA>
	<JIRA.12731402.1517243381000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731402.1517243381000.2658.1517243400728@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1506?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina updated ELY-1506:
----------------------------
    Component/s: Testsuite


> Test intermediate CA certs for client SSL auth
> ----------------------------------------------
>
>                 Key: ELY-1506
>                 URL: https://issues.jboss.org/browse/ELY-1506
>             Project: WildFly Elytron
>          Issue Type: Task
>          Components: Testsuite
>    Affects Versions: 1.2.0.Beta12
>            Reporter: Jan Kalina
>            Assignee: Jan Kalina
>
> Into Elytron SSL tests should be added test with intermediate CA:
> * Root CA cert will be present in server truststore
> * Intermediate CA cert will be signed by Root CA
> * client cert will be signed by intermediate CA and used by client



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 11:36:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 29 Jan 2018 11:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1505)
 org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
In-Reply-To: <JIRA.12731270.1517221560000@Atlassian.JIRA>
References: <JIRA.12731270.1517221560000@Atlassian.JIRA>
	<JIRA.12731270.1517221560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731270.1517221560000.2681.1517243760660@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525471#comment-13525471 ] 

Jan Kalina commented on ELY-1505:
---------------------------------

This is already fixed in upstream - see ELY-1490.

> org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
> ----------------------------------------------------------------
>
>                 Key: ELY-1505
>                 URL: https://issues.jboss.org/browse/ELY-1505
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Ivo Studensky
>            Assignee: Jan Kalina
>            Priority: Minor
>
> The org.wildfly.security.asn1.DEREncoderTest#testEncodeDSAKey() fails on JDK8 v.161 due to:
> {noformat}
> [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.124 s  <<< ERROR!
> java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> 	at sun.security.provider.DSA.checkKey(DSA.java:111)
> 	at sun.security.provider.DSA.engineInitSign(DSA.java:143)
> 	at java.security.Signature$Delegate.init(Signature.java:1156)
> 	at java.security.Signature$Delegate.chooseProvider(Signature.java:1116)
> 	at java.security.Signature$Delegate.engineInitSign(Signature.java:1180)
> 	at java.security.Signature.initSign(Signature.java:531)
> 	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:458)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {noformat}
> It affects also older tags, not only 1.1.8. It might be related to 
> https://bugs.java.com/view_bug.do?bug_id=8184341
> It seems to be a testsuite issue only.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 11:36:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 29 Jan 2018 11:36:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1505)
 org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
In-Reply-To: <JIRA.12731270.1517221560000@Atlassian.JIRA>
References: <JIRA.12731270.1517221560000@Atlassian.JIRA>
	<JIRA.12731270.1517221560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731270.1517221560000.2688.1517243760959@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525464#comment-13525464 ] 

Jan Kalina edited comment on ELY-1505 at 1/29/18 11:35 AM:
-----------------------------------------------------------

[~istudens] I am testing against *Oracle-jdk-8u161* (from Oracle's tar.gz) on Fedora 27 and the test succeed.


was (Author: honza889):
[~istudens] I am testing against *Oracle-jdk-8u161* (from Oracle's tar.gz) on Fedora 27 and the test succeed. How has you achieved it?

{code}
JAVA_HOME=/opt/Oracle-jdk-8u161 PATH=/opt/Oracle-jdk-8u161/bin/:$PATH mvn test -Dtest=org.wildfly.security.asn1.DEREncoderTest
{code}
{code}
[INFO] Tests run: 30, Failures: 0, Errors: 0, Skipped: 0, Time elapsed: 0.212 s - in org.wildfly.security.asn1.DEREncoderTest
{code}

> org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
> ----------------------------------------------------------------
>
>                 Key: ELY-1505
>                 URL: https://issues.jboss.org/browse/ELY-1505
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Ivo Studensky
>            Assignee: Jan Kalina
>            Priority: Minor
>
> The org.wildfly.security.asn1.DEREncoderTest#testEncodeDSAKey() fails on JDK8 v.161 due to:
> {noformat}
> [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.124 s  <<< ERROR!
> java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> 	at sun.security.provider.DSA.checkKey(DSA.java:111)
> 	at sun.security.provider.DSA.engineInitSign(DSA.java:143)
> 	at java.security.Signature$Delegate.init(Signature.java:1156)
> 	at java.security.Signature$Delegate.chooseProvider(Signature.java:1116)
> 	at java.security.Signature$Delegate.engineInitSign(Signature.java:1180)
> 	at java.security.Signature.initSign(Signature.java:531)
> 	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:458)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {noformat}
> It affects also older tags, not only 1.1.8. It might be related to 
> https://bugs.java.com/view_bug.do?bug_id=8184341
> It seems to be a testsuite issue only.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 11:37:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 29 Jan 2018 11:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1505)
 org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
In-Reply-To: <JIRA.12731270.1517221560000@Atlassian.JIRA>
References: <JIRA.12731270.1517221560000@Atlassian.JIRA>
	<JIRA.12731270.1517221560000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731270.1517221560000.2691.1517243820428@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1505?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Jan Kalina closed ELY-1505.
---------------------------
    Fix Version/s: 1.2.0.Beta12
       Resolution: Duplicate Issue


> org.wildfly.security.asn1.DEREncoderTest fails on new JDK8 v.161
> ----------------------------------------------------------------
>
>                 Key: ELY-1505
>                 URL: https://issues.jboss.org/browse/ELY-1505
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: Ivo Studensky
>            Assignee: Jan Kalina
>            Priority: Minor
>             Fix For: 1.2.0.Beta12
>
>
> The org.wildfly.security.asn1.DEREncoderTest#testEncodeDSAKey() fails on JDK8 v.161 due to:
> {noformat}
> [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.124 s  <<< ERROR!
> java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> 	at sun.security.provider.DSA.checkKey(DSA.java:111)
> 	at sun.security.provider.DSA.engineInitSign(DSA.java:143)
> 	at java.security.Signature$Delegate.init(Signature.java:1156)
> 	at java.security.Signature$Delegate.chooseProvider(Signature.java:1116)
> 	at java.security.Signature$Delegate.engineInitSign(Signature.java:1180)
> 	at java.security.Signature.initSign(Signature.java:531)
> 	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:458)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> 	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
> 	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> 	at java.lang.reflect.Method.invoke(Method.java:498)
> 	at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
> 	at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
> 	at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
> 	at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
> 	at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
> 	at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
> 	at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
> 	at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
> 	at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
> 	at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
> 	at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
> 	at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
> 	at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> 	at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:386)
> 	at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:323)
> 	at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:143)
> {noformat}
> It affects also older tags, not only 1.1.8. It might be related to 
> https://bugs.java.com/view_bug.do?bug_id=8184341
> It seems to be a testsuite issue only.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 11:47:00 2018
From: issues at jboss.org (Jan Kalina (JIRA))
Date: Mon, 29 Jan 2018 11:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-261) Rework (and move)
	UsernamePasswordHashUtil
In-Reply-To: <JIRA.12580680.1438967730000@Atlassian.JIRA>
References: <JIRA.12580680.1438967730000@Atlassian.JIRA>
	<JIRA.12580680.1438967730000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12580680.1438967730000.2749.1517244420398@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/ELY-261?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525476#comment-13525476 ] 

Jan Kalina commented on ELY-261:
--------------------------------

It is not, but as I has just discused with [~pskopek], the tool in Main class of elytron is legacy and can be removed - no need to solve dependencies when running elytron jar directly.
(Otherwise, if we want to keep the tool, we can add it into wildfly-elytron-tool, where are such dependencies solved.)

> Rework (and move) UsernamePasswordHashUtil
> ------------------------------------------
>
>                 Key: ELY-261
>                 URL: https://issues.jboss.org/browse/ELY-261
>             Project: WildFly Elytron
>          Issue Type: Feature Request
>          Components: API / SPI, Passwords
>            Reporter: Darran Lofthouse
>            Assignee: Jan Kalina
>             Fix For: 1.2.0.Beta14
>
>
> Firstly this class is not really SASL specific so should be in a general util package.
> Secondly we now have password specs and a PasswordFactory - if this class still has a future then maybe it should be using those instead of it's own custom implementation.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Mon Jan 29 14:49:00 2018
From: issues at jboss.org (Ivo Studensky (JIRA))
Date: Mon, 29 Jan 2018 14:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (ELY-1490) Java 9: Test fails on Oracle
 9.0.4 and later due to SHA-1 usage
In-Reply-To: <JIRA.12729511.1516199886000@Atlassian.JIRA>
References: <JIRA.12729511.1516199886000@Atlassian.JIRA>
	<JIRA.12729511.1516199886000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729511.1516199886000.4097.1517255340494@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/ELY-1490?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ivo Studensky reopened ELY-1490:
--------------------------------


Re-opening for private 1.1.x branch. Elytron can't be productized because of this.

> Java 9: Test fails on Oracle 9.0.4 and later due to SHA-1 usage
> ---------------------------------------------------------------
>
>                 Key: ELY-1490
>                 URL: https://issues.jboss.org/browse/ELY-1490
>             Project: WildFly Elytron
>          Issue Type: Bug
>          Components: Testsuite
>            Reporter: David Lloyd
>            Assignee: David Lloyd
>              Labels: Java9
>             Fix For: 1.2.0.Beta12
>
>
> The error is:
> {noformat}
> [ERROR] Tests run: 30, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.197 s <<< FAILURE! - in org.wildfly.security.asn1.DEREncoderTest
> [ERROR] testEncodeDSAKey(org.wildfly.security.asn1.DEREncoderTest)  Time elapsed: 0.053 s  <<< ERROR!
> java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
> 	at java.base/java.security.Signature$Delegate.init(Signature.java:1178)
> 	at java.base/java.security.Signature$Delegate.chooseProvider(Signature.java:1138)
> 	at java.base/java.security.Signature$Delegate.engineInitSign(Signature.java:1202)
> 	at java.base/java.security.Signature.initSign(Signature.java:545)
> 	at org.wildfly.security.asn1.DEREncoderTest.testEncodeDSAKey(DEREncoderTest.java:426)
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 02:59:00 2018
From: issues at jboss.org (Martin Stefanko (JIRA))
Date: Tue, 30 Jan 2018 02:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3555) Pipe with echo commad gives
 incorrect result
In-Reply-To: <JIRA.12731019.1516971818000@Atlassian.JIRA>
References: <JIRA.12731019.1516971818000@Atlassian.JIRA>
	<JIRA.12731019.1516971818000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731019.1516971818000.5892.1517299140632@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3555?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Stefanko reassigned WFCORE-3555:
---------------------------------------

    Assignee: Martin Stefanko  (was: Jean-Francois Denise)


> Pipe with echo commad gives incorrect result
> --------------------------------------------
>
>                 Key: WFCORE-3555
>                 URL: https://issues.jboss.org/browse/WFCORE-3555
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Katerina Novotna
>            Assignee: Martin Stefanko
>
> *Description of problem:*
> When putting 'echo' into the right side of the pipe. Addional 'o' is displayed as result.
> *Actual results:*
> [standalone at embedded /] version | echo test
> o test
> *Expected results:*
> [standalone at embedded /] version | echo test
> test



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 03:10:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 30 Jan 2018 03:10:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2281) fix OOPath doc EBNF
In-Reply-To: <JIRA.12731515.1517299775000@Atlassian.JIRA>
References: <JIRA.12731515.1517299775000@Atlassian.JIRA>
	<JIRA.12731515.1517299775618@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731515.1517299775000.5917.1517299800363@Atlassian.JIRA>

Matteo Mortari created DROOLS-2281:
--------------------------------------

             Summary: fix OOPath doc EBNF
                 Key: DROOLS-2281
                 URL: https://issues.jboss.org/browse/DROOLS-2281
             Project: Drools
          Issue Type: Task
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari


The OOPath doc EBNF contains a binding in the chunk, which is actually not present in the anltr/implementation.

{code:java}
xpathChunk returns [BaseDescr result]
     : (xpathSeparator ID)=> xpathSeparator ID (DOT ID)* (HASH ID)? (LEFT_SQUARE xpathExpressionList RIGHT_SQUARE)?
     ;
{code}




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 03:19:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Tue, 30 Jan 2018 03:19:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3562) Deployment disable-all
 doesn't correct function at domain
In-Reply-To: <JIRA.12731519.1517300290000@Atlassian.JIRA>
References: <JIRA.12731519.1517300290000@Atlassian.JIRA>
	<JIRA.12731519.1517300290079@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731519.1517300290000.5971.1517300340322@Atlassian.JIRA>

Vratislav Marek created WFCORE-3562:
---------------------------------------

             Summary: Deployment disable-all doesn't correct function at domain
                 Key: WFCORE-3562
                 URL: https://issues.jboss.org/browse/WFCORE-3562
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Vratislav Marek
            Assignee: Jean-Francois Denise


Domain 

{noformat}
[domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups
org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
[domain at localhost:9990 /]
{noformat}

{noformat}
[domain at localhost:9990 /] undeploy * --keep-content --all-relevant-server-groups
org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
[domain at localhost:9990 /]
{noformat}

{noformat}
[domain at localhost:9990 /] deployment disable-all --server-groups=main-server-group
{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
    (\"server-group\" => \"main-server-group\"),
    (\"deployment\" => \"cli-test-app2-deploy-all.war\")
]' not found"}}
[domain at localhost:9990 /]
{noformat}

{noformat}
[domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group
{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
    (\"server-group\" => \"main-server-group\"),
    (\"deployment\" => \"cli-test-app2-deploy-all.war\")
]' not found"}}
[domain at localhost:9990 /]
{noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 03:35:00 2018
From: issues at jboss.org (Matteo Mortari (JIRA))
Date: Tue, 30 Jan 2018 03:35:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2282) fix OOPath doc EBNF
In-Reply-To: <JIRA.12731521.1517301299000@Atlassian.JIRA>
References: <JIRA.12731521.1517301299000@Atlassian.JIRA>
	<JIRA.12731521.1517301299569@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731521.1517301299000.6057.1517301300244@Atlassian.JIRA>

Matteo Mortari created DROOLS-2282:
--------------------------------------

             Summary: fix OOPath doc EBNF
                 Key: DROOLS-2282
                 URL: https://issues.jboss.org/browse/DROOLS-2282
             Project: Drools
          Issue Type: Task
            Reporter: Matteo Mortari
            Assignee: Matteo Mortari


The OOPath doc EBNF contains a binding in the chunk, which is actually not present in the anltr/implementation.

{code:java}
xpathChunk returns [BaseDescr result]
     : (xpathSeparator ID)=> xpathSeparator ID (DOT ID)* (HASH ID)? (LEFT_SQUARE xpathExpressionList RIGHT_SQUARE)?
     ;
{code}




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 04:59:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Tue, 30 Jan 2018 04:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3563) Could not enable
 application deployment on two server groups in domain
In-Reply-To: <JIRA.12731530.1517306316000@Atlassian.JIRA>
References: <JIRA.12731530.1517306316000@Atlassian.JIRA>
	<JIRA.12731530.1517306316107@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731530.1517306316000.6537.1517306340177@Atlassian.JIRA>

Vratislav Marek created WFCORE-3563:
---------------------------------------

             Summary: Could not enable application deployment on two server groups in domain
                 Key: WFCORE-3563
                 URL: https://issues.jboss.org/browse/WFCORE-3563
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Vratislav Marek
            Assignee: Jean-Francois Denise


{noformat}
[domain at localhost:9990 /] deployment enable --server-groups=other-server-group,main-server-group cli-test-app-deploy-all.ear
{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [
    (\"server-group\" => \"other-server-group\"),
    (\"deployment\" => \"cli-test-app-deploy-all.ear\")
]"}}
[domain at localhost:9990 /] 
{noformat}

{noformat}
[domain at localhost:9990 /] deploy --name=cli-test-app-deploy-all.ear --server-groups=other-server-group,main-server-group
{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [
    (\"server-group\" => \"other-server-group\"),
    (\"deployment\" => \"cli-test-app-deploy-all.ear\")
]"}}
[domain at localhost:9990 /]
{noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 05:21:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Tue, 30 Jan 2018 05:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3564) Bad CLI complementation
	server groups
In-Reply-To: <JIRA.12731536.1517307609000@Atlassian.JIRA>
References: <JIRA.12731536.1517307609000@Atlassian.JIRA>
	<JIRA.12731536.1517307609429@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731536.1517307609000.7216.1517307660256@Atlassian.JIRA>

Vratislav Marek created WFCORE-3564:
---------------------------------------

             Summary: Bad CLI complementation server groups
                 Key: WFCORE-3564
                 URL: https://issues.jboss.org/browse/WFCORE-3564
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Vratislav Marek
            Assignee: Jean-Francois Denise


*Cli complementation insert the whole word without delete writed letters*
* --server-groups={color:#d04437}m{color}main-server-group
* --server-groups={color:#d04437}o{color}other-server-group
* --server-groups={color:#d04437}othe{color}other-server-group

{noformat}
[domain at localhost:9990 /] deployment disable * --server-groups=
main-server-group  other-server-group  
[domain at localhost:9990 /] deployment disable * --server-groups=mmain-server-group 
{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"server-group\" => \"mmain-server-group\")]' not found"}}
[domain at localhost:9990 /] deployment disable * --server-groups=oother-server-group
{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"server-group\" => \"oother-server-group\")]' not found"}}
[domain at localhost:9990 /]
[domain at localhost:9990 /] deployment disable * --server-groups=otheother-server-group 
{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"server-group\" => \"otheother-server-group\")]' not found"}}
[domain at localhost:9990 /]
{noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 05:23:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Tue, 30 Jan 2018 05:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3562) Deployment disable-all
 doesn't correct function at domain
In-Reply-To: <JIRA.12731519.1517300290000@Atlassian.JIRA>
References: <JIRA.12731519.1517300290000@Atlassian.JIRA>
	<JIRA.12731519.1517300290000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731519.1517300290000.7240.1517307780724@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vratislav Marek updated WFCORE-3562:
------------------------------------
    Affects Version/s: 4.0.0.Alpha8


> Deployment disable-all doesn't correct function at domain
> ---------------------------------------------------------
>
>                 Key: WFCORE-3562
>                 URL: https://issues.jboss.org/browse/WFCORE-3562
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> Domain 
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 05:23:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Tue, 30 Jan 2018 05:23:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3562) Deployment disable-all
 doesn't correct function at domain
In-Reply-To: <JIRA.12731519.1517300290000@Atlassian.JIRA>
References: <JIRA.12731519.1517300290000@Atlassian.JIRA>
	<JIRA.12731519.1517300290000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731519.1517300290000.7244.1517307780846@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vratislav Marek updated WFCORE-3562:
------------------------------------
    Affects Version/s:     (was: 4.0.0.Alpha8)


> Deployment disable-all doesn't correct function at domain
> ---------------------------------------------------------
>
>                 Key: WFCORE-3562
>                 URL: https://issues.jboss.org/browse/WFCORE-3562
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> Domain 
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 06:41:00 2018
From: issues at jboss.org (Ryan Emerson (JIRA))
Date: Tue, 30 Jan 2018 06:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2248) SASL protocol should not pass
 null callbackhandlers to Factories
In-Reply-To: <JIRA.12731557.1517312404000@Atlassian.JIRA>
References: <JIRA.12731557.1517312404000@Atlassian.JIRA>
	<JIRA.12731557.1517312404310@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731557.1517312404000.7800.1517312460168@Atlassian.JIRA>

Ryan Emerson created JGRP-2248:
----------------------------------

             Summary: SASL protocol should not pass null callbackhandlers to Factories
                 Key: JGRP-2248
                 URL: https://issues.jboss.org/browse/JGRP-2248
             Project: JGroups
          Issue Type: Enhancement
            Reporter: Ryan Emerson
            Assignee: Bela Ban


Currently it's possible for the client and server callback handlers to be null when passed to the respective Sasl Factory. When utilising the Elytron Sasl factories this results in an IllegalArgumentException being thrown. To avoid this we should ensure that the callback handlers are non-null when passed to the factory implementations, e.g. pass a NoOpCallbackHandler.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 06:41:00 2018
From: issues at jboss.org (Ryan Emerson (JIRA))
Date: Tue, 30 Jan 2018 06:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2248) SASL protocol should not pass
 null callbackhandlers to Factories
In-Reply-To: <JIRA.12731557.1517312404000@Atlassian.JIRA>
References: <JIRA.12731557.1517312404000@Atlassian.JIRA>
	<JIRA.12731557.1517312404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731557.1517312404000.7803.1517312460265@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan Emerson reassigned JGRP-2248:
----------------------------------

    Assignee: Ryan Emerson  (was: Bela Ban)


> SASL protocol should not pass null callbackhandlers to Factories
> ----------------------------------------------------------------
>
>                 Key: JGRP-2248
>                 URL: https://issues.jboss.org/browse/JGRP-2248
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 4.0.9
>            Reporter: Ryan Emerson
>            Assignee: Ryan Emerson
>
> Currently it's possible for the client and server callback handlers to be null when passed to the respective Sasl Factory. When utilising the Elytron Sasl factories this results in an IllegalArgumentException being thrown. To avoid this we should ensure that the callback handlers are non-null when passed to the factory implementations, e.g. pass a NoOpCallbackHandler.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 06:41:00 2018
From: issues at jboss.org (Ryan Emerson (JIRA))
Date: Tue, 30 Jan 2018 06:41:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2248) SASL protocol should not pass
 null callbackhandlers to Factories
In-Reply-To: <JIRA.12731557.1517312404000@Atlassian.JIRA>
References: <JIRA.12731557.1517312404000@Atlassian.JIRA>
	<JIRA.12731557.1517312404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731557.1517312404000.7806.1517312460367@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Ryan Emerson updated JGRP-2248:
-------------------------------
    Affects Version/s: 4.0.9


> SASL protocol should not pass null callbackhandlers to Factories
> ----------------------------------------------------------------
>
>                 Key: JGRP-2248
>                 URL: https://issues.jboss.org/browse/JGRP-2248
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 4.0.9
>            Reporter: Ryan Emerson
>            Assignee: Ryan Emerson
>
> Currently it's possible for the client and server callback handlers to be null when passed to the respective Sasl Factory. When utilising the Elytron Sasl factories this results in an IllegalArgumentException being thrown. To avoid this we should ensure that the callback handlers are non-null when passed to the factory implementations, e.g. pass a NoOpCallbackHandler.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 06:48:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Tue, 30 Jan 2018 06:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2248) SASL protocol should not pass
 null callbackhandlers to Factories
In-Reply-To: <JIRA.12731557.1517312404000@Atlassian.JIRA>
References: <JIRA.12731557.1517312404000@Atlassian.JIRA>
	<JIRA.12731557.1517312404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731557.1517312404000.7904.1517312880189@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2248:
---------------------------
    Fix Version/s: 4.0.10


> SASL protocol should not pass null callbackhandlers to Factories
> ----------------------------------------------------------------
>
>                 Key: JGRP-2248
>                 URL: https://issues.jboss.org/browse/JGRP-2248
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 4.0.9
>            Reporter: Ryan Emerson
>            Assignee: Ryan Emerson
>             Fix For: 4.0.10
>
>
> Currently it's possible for the client and server callback handlers to be null when passed to the respective Sasl Factory. When utilising the Elytron Sasl factories this results in an IllegalArgumentException being thrown. To avoid this we should ensure that the callback handlers are non-null when passed to the factory implementations, e.g. pass a NoOpCallbackHandler.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 07:04:00 2018
From: issues at jboss.org (Kabir Khan (JIRA))
Date: Tue, 30 Jan 2018 07:04:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9634) Enable
 MixedDomainDeploymentTest.testExplodedDeployment() for EAP 7.1.0
In-Reply-To: <JIRA.12725937.1513892690000@Atlassian.JIRA>
References: <JIRA.12725937.1513892690000@Atlassian.JIRA>
	<JIRA.12725937.1513892690000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12725937.1513892690000.7983.1517313840322@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9634?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525823#comment-13525823 ] 

Kabir Khan commented on WFLY-9634:
----------------------------------

[~ehugonnet] The mixed domain tests have been merged, so this is ready for investigation :)

> Enable MixedDomainDeploymentTest.testExplodedDeployment() for EAP 7.1.0
> -----------------------------------------------------------------------
>
>                 Key: WFLY-9634
>                 URL: https://issues.jboss.org/browse/WFLY-9634
>             Project: WildFly
>          Issue Type: Task
>          Components: Domain Management, Test Suite
>            Reporter: Kabir Khan
>            Assignee: ehsavoie Hugonnet
>             Fix For: 12.0.0.Alpha1
>
>
> I have added an
> {code}
>         // TODO WFLY-9634
>         Assume.assumeFalse(supportManagedExplodedDeployment());
> {code}
> to this test in https://github.com/wildfly/wildfly/pull/10730 which introduces the 7.1.0 mixed domain tests. See WFCORE-3479 for more details.
> If for some reason the decision is to *not* allow this use case from within a composite, this test should be rewritten to not use a composite.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 07:14:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 30 Jan 2018 07:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6457) JMS 2.1 Support
In-Reply-To: <JIRA.12612932.1459635475000@Atlassian.JIRA>
References: <JIRA.12612932.1459635475000@Atlassian.JIRA>
	<JIRA.12612932.1459635475000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12612932.1459635475000.8056.1517314440787@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6457?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-6457.
-------------------------------
    Resolution: Rejected


Dropped.

> JMS 2.1 Support
> ---------------
>
>                 Key: WFLY-6457
>                 URL: https://issues.jboss.org/browse/WFLY-6457
>             Project: WildFly
>          Issue Type: Sub-task
>            Reporter: David Lloyd
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 07:14:01 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 30 Jan 2018 07:14:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-6463) Common Annotations 1.3 Support
In-Reply-To: <JIRA.12612938.1459635639000@Atlassian.JIRA>
References: <JIRA.12612938.1459635639000@Atlassian.JIRA>
	<JIRA.12612938.1459635639000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12612938.1459635639000.8081.1517314441623@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-6463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd resolved WFLY-6463.
-------------------------------
    Resolution: Rejected


Dropped.

> Common Annotations 1.3 Support
> ------------------------------
>
>                 Key: WFLY-6463
>                 URL: https://issues.jboss.org/browse/WFLY-6463
>             Project: WildFly
>          Issue Type: Sub-task
>          Components: EE
>            Reporter: David Lloyd
>




--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 07:28:01 2018
From: issues at jboss.org (=?UTF-8?Q?Christoph_B=C3=B6hme_=28JIRA=29?=)
Date: Tue, 30 Jan 2018 07:28:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3565) RequestController ignores
 queued tasks if max requests is configured
In-Reply-To: <JIRA.12731610.1517315269000@Atlassian.JIRA>
References: <JIRA.12731610.1517315269000@Atlassian.JIRA>
	<JIRA.12731610.1517315269010@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731610.1517315269000.8245.1517315281230@Atlassian.JIRA>

Christoph B?hme created WFCORE-3565:
---------------------------------------

             Summary: RequestController ignores queued tasks if max requests is configured
                 Key: WFCORE-3565
                 URL: https://issues.jboss.org/browse/WFCORE-3565
             Project: WildFly Core
          Issue Type: Bug
    Affects Versions: 4.0.0.Alpha7, 3.0.8.Final
            Reporter: Christoph B?hme


We encountered an issue with EJB timers stopping randomly if the container is under load. Sometimes the timers get stalled right after deployment without firing at all. Sometimes the timers work fine for a couple of days before they suddenly stop working. The timers are defined using the {{@Scheduled}} annotation.

We found out that the reason for the randomly stopping timers is a bug in the {{RequestController}} class which only appears if a maximum number of requests is configured in the request controller subsystem. If a timer is being triggered while the container has reached the request limit then the timer is put into a task queue to be processed later. However, the task queue is never checked for queued tasks if the request number goes down again. This leaves the timers stuck in the queue. Since every timer needs to reregister after it has been triggered, the timers appear to have stopped.

In old versions of the {{RequestController}} class from before release wildfly-core-1.0.0.Alpha14 it looks like the idea was to check for queued requests whenever a request finished (see [here|https://github.com/wildfly/wildfly-core/blob/a426a14db6466549159a5528dcee9f4b7087d334/request-controller/src/main/java/org/wildfly/extension/requestcontroller/RequestController.java#L369]).



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan 30 07:38:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 30 Jan 2018 07:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9742) ClassLoader leak in JBoss
 Threads caused by MDBs
In-Reply-To: <JIRA.12731375.1517237459000@Atlassian.JIRA>
References: <JIRA.12731375.1517237459000@Atlassian.JIRA>
	<JIRA.12731375.1517237459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731375.1517237459000.8294.1517315880427@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525852#comment-13525852 ] 

David Lloyd commented on WFLY-9742:
-----------------------------------

I think there isn't one single perfect answer, but the best answer is probably to clear TCCL in JBoss Threads.  The inherited TCCL behavior is usually not helpful, especially for pooled threads.

> ClassLoader leak in JBoss Threads caused by MDBs
> ------------------------------------------------
>
>                 Key: WFLY-9742
>                 URL: https://issues.jboss.org/browse/WFLY-9742
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.Final
>            Reporter: Markus Dlugi
>            Assignee: Jason Greene
>         Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip
>
>
> There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs. When a new MDB is created and a new thread for the MDB is started in the JCA thread pool ("default-threads - x"), the thread will be created using the context classloader of the MDB's deployment unit. This is because [MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/messagedriven/MessageDrivenComponent.java#L275] sets the context classloader of the ServerService thread in order to create the MDB, and this classloader will then also be used by the child thread.
> In the default configuration, the threads in the default thread pool will not be terminated and therefore the thread will keep the reference to the classloader even when the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError: Metaspace" after a couple of redeployments.
> As a workaround, we changed [JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-threads/blob/master/src/main/java/org/jboss/threads/JBossThreadFactory.java#L104] to set the context classloader to null after a new thread has been created. While this fixes the issue for us, I am not sure whether this is a good solution for all consumers of the thread factory, or if this should be fixed in the JCA subsystem instead. That's also the reason why I opened this issue against the WildFly project instead of JBoss Threads.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 07:42:00 2018
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 30 Jan 2018 07:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-232) Deployment fails when
 Dependencies is empty in a jars manifest
In-Reply-To: <JIRA.12474406.1347532970000@Atlassian.JIRA>
References: <JIRA.12474406.1347532970000@Atlassian.JIRA>
	<JIRA.12474406.1347532970000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474406.1347532970000.8327.1517316120433@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525855#comment-13525855 ] 

RH Bugzilla Integration commented on WFLY-232:
----------------------------------------------

Masafumi Miura <mmiura at redhat.com> changed the Status of [bug 1539985|https://bugzilla.redhat.com/show_bug.cgi?id=1539985] from ASSIGNED to NEW

> Deployment fails when Dependencies is empty in a jars manifest
> --------------------------------------------------------------
>
>                 Key: WFLY-232
>                 URL: https://issues.jboss.org/browse/WFLY-232
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: G?bor Farkas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: empty-manifest.ear
>
>
> I have a WAR, which produces the following error on deployment:
> Caused by: java.lang.IllegalArgumentException: Empty module specification
> 	at org.jboss.modules.ModuleIdentifier.fromString(ModuleIdentifier.java:169) [jboss-modules.jar:1.1.1.GA]
> 	at org.jboss.as.server.deployment.module.ManifestDependencyProcessor.deploy(ManifestDependencyProcessor.java:83) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> 	... 5 more
> I found that my WAR contains a jar in WEB-INF/lib that has empty dependencies defined in its manifest. More exactly it's "Dependencies: ", so the colon is followed by a space character before the new line characters. The ManifestDependencyProcessor parses this as one dependency, the name of which is the empty string.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan 30 07:42:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Tue, 30 Jan 2018 07:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3566) Different results of
 disabling commands already disabled deployment
In-Reply-To: <JIRA.12731615.1517316083000@Atlassian.JIRA>
References: <JIRA.12731615.1517316083000@Atlassian.JIRA>
	<JIRA.12731615.1517316083456@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731615.1517316083000.8338.1517316120715@Atlassian.JIRA>

Vratislav Marek created WFCORE-3566:
---------------------------------------

             Summary: Different results of disabling commands already disabled deployment
                 Key: WFCORE-3566
                 URL: https://issues.jboss.org/browse/WFCORE-3566
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Vratislav Marek
            Assignee: Jean-Francois Denise


*Different command result in standalone and domain mode*
* In standalone return 
{noformat}
WFLYCTL0155: 'steps' may not be null
{noformat}
* In domain return nothing, no warning or error

{noformat}
[standalone at localhost:9990 /] deployment info
NAME                        RUNTIME-NAME                PERSISTENT ENABLED STATUS  
cli-test-another-deploy.war cli-test-another-deploy.war true       true    OK      
cli-test-app1-deploy.war    cli-test-app1-deploy.war    true       false   STOPPED 
cli-test-app2-deploy.war    cli-test-app2-deploy.war    true       true    OK      
[standalone at localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
WFLYCTL0155: 'steps' may not be null
[standalone at localhost:9990 /]
{noformat}

{noformat}
[domain at localhost:9990 /] deployment info --server-groups=main-server-group
NAME                            RUNTIME-NAME                    STATE     
cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled   
cli-test-app1-deploy-all.war    cli-test-app1-deploy-all.war    added     
cli-test-app2-deploy-all.war    cli-test-app2-deploy-all.war    not added 
cli-test-app3-deploy-all.war    cli-test-app3-deploy-all.war    enabled   
[domain at localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
[domain at localhost:9990 /]
{noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 07:42:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Tue, 30 Jan 2018 07:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3566) Different results of
 disabling commands already disabled deployment
In-Reply-To: <JIRA.12731615.1517316083000@Atlassian.JIRA>
References: <JIRA.12731615.1517316083000@Atlassian.JIRA>
	<JIRA.12731615.1517316083000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731615.1517316083000.8347.1517316120911@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vratislav Marek updated WFCORE-3566:
------------------------------------
    Description: 
*Different command result of  in standalone and domain mode*
* In standalone return 
{noformat}
WFLYCTL0155: 'steps' may not be null
{noformat}
* In domain return nothing, no warning or error

{noformat}
[standalone at localhost:9990 /] deployment info
NAME                        RUNTIME-NAME                PERSISTENT ENABLED STATUS  
cli-test-another-deploy.war cli-test-another-deploy.war true       true    OK      
cli-test-app1-deploy.war    cli-test-app1-deploy.war    true       false   STOPPED 
cli-test-app2-deploy.war    cli-test-app2-deploy.war    true       true    OK      
[standalone at localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
WFLYCTL0155: 'steps' may not be null
[standalone at localhost:9990 /]
{noformat}

{noformat}
[domain at localhost:9990 /] deployment info --server-groups=main-server-group
NAME                            RUNTIME-NAME                    STATE     
cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled   
cli-test-app1-deploy-all.war    cli-test-app1-deploy-all.war    added     
cli-test-app2-deploy-all.war    cli-test-app2-deploy-all.war    not added 
cli-test-app3-deploy-all.war    cli-test-app3-deploy-all.war    enabled   
[domain at localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
[domain at localhost:9990 /]
{noformat}

  was:
*Different command result in standalone and domain mode*
* In standalone return 
{noformat}
WFLYCTL0155: 'steps' may not be null
{noformat}
* In domain return nothing, no warning or error

{noformat}
[standalone at localhost:9990 /] deployment info
NAME                        RUNTIME-NAME                PERSISTENT ENABLED STATUS  
cli-test-another-deploy.war cli-test-another-deploy.war true       true    OK      
cli-test-app1-deploy.war    cli-test-app1-deploy.war    true       false   STOPPED 
cli-test-app2-deploy.war    cli-test-app2-deploy.war    true       true    OK      
[standalone at localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
WFLYCTL0155: 'steps' may not be null
[standalone at localhost:9990 /]
{noformat}

{noformat}
[domain at localhost:9990 /] deployment info --server-groups=main-server-group
NAME                            RUNTIME-NAME                    STATE     
cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled   
cli-test-app1-deploy-all.war    cli-test-app1-deploy-all.war    added     
cli-test-app2-deploy-all.war    cli-test-app2-deploy-all.war    not added 
cli-test-app3-deploy-all.war    cli-test-app3-deploy-all.war    enabled   
[domain at localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
[domain at localhost:9990 /]
{noformat}



> Different results of disabling commands already disabled deployment
> -------------------------------------------------------------------
>
>                 Key: WFCORE-3566
>                 URL: https://issues.jboss.org/browse/WFCORE-3566
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> *Different command result of  in standalone and domain mode*
> * In standalone return 
> {noformat}
> WFLYCTL0155: 'steps' may not be null
> {noformat}
> * In domain return nothing, no warning or error
> {noformat}
> [standalone at localhost:9990 /] deployment info
> NAME                        RUNTIME-NAME                PERSISTENT ENABLED STATUS  
> cli-test-another-deploy.war cli-test-another-deploy.war true       true    OK      
> cli-test-app1-deploy.war    cli-test-app1-deploy.war    true       false   STOPPED 
> cli-test-app2-deploy.war    cli-test-app2-deploy.war    true       true    OK      
> [standalone at localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
> WFLYCTL0155: 'steps' may not be null
> [standalone at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deployment info --server-groups=main-server-group
> NAME                            RUNTIME-NAME                    STATE     
> cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled   
> cli-test-app1-deploy-all.war    cli-test-app1-deploy-all.war    added     
> cli-test-app2-deploy-all.war    cli-test-app2-deploy-all.war    not added 
> cli-test-app3-deploy-all.war    cli-test-app3-deploy-all.war    enabled   
> [domain at localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 07:43:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Tue, 30 Jan 2018 07:43:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3566) Different results of
 disabling commands already disabled deployment
In-Reply-To: <JIRA.12731615.1517316083000@Atlassian.JIRA>
References: <JIRA.12731615.1517316083000@Atlassian.JIRA>
	<JIRA.12731615.1517316083000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731615.1517316083000.8352.1517316180422@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vratislav Marek updated WFCORE-3566:
------------------------------------
    Description: 
*Different command result of disabling already disabled deployment in standalone and domain mode*
* In standalone return 
{noformat}
WFLYCTL0155: 'steps' may not be null
{noformat}
* In domain return nothing, no warning or error

{noformat}
[standalone at localhost:9990 /] deployment info
NAME                        RUNTIME-NAME                PERSISTENT ENABLED STATUS  
cli-test-another-deploy.war cli-test-another-deploy.war true       true    OK      
cli-test-app1-deploy.war    cli-test-app1-deploy.war    true       false   STOPPED 
cli-test-app2-deploy.war    cli-test-app2-deploy.war    true       true    OK      
[standalone at localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
WFLYCTL0155: 'steps' may not be null
[standalone at localhost:9990 /]
{noformat}

{noformat}
[domain at localhost:9990 /] deployment info --server-groups=main-server-group
NAME                            RUNTIME-NAME                    STATE     
cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled   
cli-test-app1-deploy-all.war    cli-test-app1-deploy-all.war    added     
cli-test-app2-deploy-all.war    cli-test-app2-deploy-all.war    not added 
cli-test-app3-deploy-all.war    cli-test-app3-deploy-all.war    enabled   
[domain at localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
[domain at localhost:9990 /]
{noformat}

  was:
*Different command result of  in standalone and domain mode*
* In standalone return 
{noformat}
WFLYCTL0155: 'steps' may not be null
{noformat}
* In domain return nothing, no warning or error

{noformat}
[standalone at localhost:9990 /] deployment info
NAME                        RUNTIME-NAME                PERSISTENT ENABLED STATUS  
cli-test-another-deploy.war cli-test-another-deploy.war true       true    OK      
cli-test-app1-deploy.war    cli-test-app1-deploy.war    true       false   STOPPED 
cli-test-app2-deploy.war    cli-test-app2-deploy.war    true       true    OK      
[standalone at localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
WFLYCTL0155: 'steps' may not be null
[standalone at localhost:9990 /]
{noformat}

{noformat}
[domain at localhost:9990 /] deployment info --server-groups=main-server-group
NAME                            RUNTIME-NAME                    STATE     
cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled   
cli-test-app1-deploy-all.war    cli-test-app1-deploy-all.war    added     
cli-test-app2-deploy-all.war    cli-test-app2-deploy-all.war    not added 
cli-test-app3-deploy-all.war    cli-test-app3-deploy-all.war    enabled   
[domain at localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
[domain at localhost:9990 /]
{noformat}



> Different results of disabling commands already disabled deployment
> -------------------------------------------------------------------
>
>                 Key: WFCORE-3566
>                 URL: https://issues.jboss.org/browse/WFCORE-3566
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> *Different command result of disabling already disabled deployment in standalone and domain mode*
> * In standalone return 
> {noformat}
> WFLYCTL0155: 'steps' may not be null
> {noformat}
> * In domain return nothing, no warning or error
> {noformat}
> [standalone at localhost:9990 /] deployment info
> NAME                        RUNTIME-NAME                PERSISTENT ENABLED STATUS  
> cli-test-another-deploy.war cli-test-another-deploy.war true       true    OK      
> cli-test-app1-deploy.war    cli-test-app1-deploy.war    true       false   STOPPED 
> cli-test-app2-deploy.war    cli-test-app2-deploy.war    true       true    OK      
> [standalone at localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
> WFLYCTL0155: 'steps' may not be null
> [standalone at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deployment info --server-groups=main-server-group
> NAME                            RUNTIME-NAME                    STATE     
> cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled   
> cli-test-app1-deploy-all.war    cli-test-app1-deploy-all.war    added     
> cli-test-app2-deploy-all.war    cli-test-app2-deploy-all.war    not added 
> cli-test-app3-deploy-all.war    cli-test-app3-deploy-all.war    enabled   
> [domain at localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 07:47:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Tue, 30 Jan 2018 07:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3566) Different results of
 disabling commands already disabled deployment
In-Reply-To: <JIRA.12731615.1517316083000@Atlassian.JIRA>
References: <JIRA.12731615.1517316083000@Atlassian.JIRA>
	<JIRA.12731615.1517316083000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731615.1517316083000.8378.1517316420281@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525860#comment-13525860 ] 

Vratislav Marek commented on WFCORE-3566:
-----------------------------------------

Should they both commands to warn or report an error?

> Different results of disabling commands already disabled deployment
> -------------------------------------------------------------------
>
>                 Key: WFCORE-3566
>                 URL: https://issues.jboss.org/browse/WFCORE-3566
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> *Different command result of disabling already disabled deployment in standalone and domain mode*
> * In standalone return 
> {noformat}
> WFLYCTL0155: 'steps' may not be null
> {noformat}
> * In domain return nothing, no warning or error
> {noformat}
> [standalone at localhost:9990 /] deployment info
> NAME                        RUNTIME-NAME                PERSISTENT ENABLED STATUS  
> cli-test-another-deploy.war cli-test-another-deploy.war true       true    OK      
> cli-test-app1-deploy.war    cli-test-app1-deploy.war    true       false   STOPPED 
> cli-test-app2-deploy.war    cli-test-app2-deploy.war    true       true    OK      
> [standalone at localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
> WFLYCTL0155: 'steps' may not be null
> [standalone at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deployment info --server-groups=main-server-group
> NAME                            RUNTIME-NAME                    STATE     
> cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled   
> cli-test-app1-deploy-all.war    cli-test-app1-deploy-all.war    added     
> cli-test-app2-deploy-all.war    cli-test-app2-deploy-all.war    not added 
> cli-test-app3-deploy-all.war    cli-test-app3-deploy-all.war    enabled   
> [domain at localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 07:50:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 30 Jan 2018 07:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9742) ClassLoader leak in JBoss
 Threads caused by MDBs
In-Reply-To: <JIRA.12731375.1517237459000@Atlassian.JIRA>
References: <JIRA.12731375.1517237459000@Atlassian.JIRA>
	<JIRA.12731375.1517237459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731375.1517237459000.8398.1517316600466@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

David Lloyd reassigned WFLY-9742:
---------------------------------

    Assignee: David Lloyd  (was: Jason Greene)


> ClassLoader leak in JBoss Threads caused by MDBs
> ------------------------------------------------
>
>                 Key: WFLY-9742
>                 URL: https://issues.jboss.org/browse/WFLY-9742
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.Final
>            Reporter: Markus Dlugi
>            Assignee: David Lloyd
>         Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip
>
>
> There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs. When a new MDB is created and a new thread for the MDB is started in the JCA thread pool ("default-threads - x"), the thread will be created using the context classloader of the MDB's deployment unit. This is because [MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/messagedriven/MessageDrivenComponent.java#L275] sets the context classloader of the ServerService thread in order to create the MDB, and this classloader will then also be used by the child thread.
> In the default configuration, the threads in the default thread pool will not be terminated and therefore the thread will keep the reference to the classloader even when the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError: Metaspace" after a couple of redeployments.
> As a workaround, we changed [JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-threads/blob/master/src/main/java/org/jboss/threads/JBossThreadFactory.java#L104] to set the context classloader to null after a new thread has been created. While this fixes the issue for us, I am not sure whether this is a good solution for all consumers of the thread factory, or if this should be fixed in the JCA subsystem instead. That's also the reason why I opened this issue against the WildFly project instead of JBoss Threads.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 08:10:02 2018
From: issues at jboss.org (Martin Weiler (JIRA))
Date: Tue, 30 Jan 2018 08:10:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2283) [GSS](6.4.z) NPE when
 creating KieModuleMetaData with wrong release id
In-Reply-To: <JIRA.12731655.1517317782000@Atlassian.JIRA>
References: <JIRA.12731655.1517317782000@Atlassian.JIRA>
	<JIRA.12731655.1517317782663@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731655.1517317782000.8702.1517317802138@Atlassian.JIRA>

Martin Weiler created DROOLS-2283:
-------------------------------------

             Summary: [GSS](6.4.z) NPE when creating KieModuleMetaData with wrong release id
                 Key: DROOLS-2283
                 URL: https://issues.jboss.org/browse/DROOLS-2283
             Project: Drools
          Issue Type: Bug
          Components: core engine
    Affects Versions: 7.0.0.CR3
            Reporter: Martin Weiler
            Assignee: Mario Fusco
             Fix For: 7.0.0.Final


If user tries to create new KieModuleMetaData using KieModuleMetaData.Factory.newKieModuleMetaData() with not existing release id then NPE is thrown, see stacktrace in attachment.

This error can be simulated on Kie server. See PR with reproducer [1].


[1] https://github.com/kiegroup/droolsjbpm-integration/pull/950



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 08:10:02 2018
From: issues at jboss.org (Markus Dlugi (JIRA))
Date: Tue, 30 Jan 2018 08:10:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9742) ClassLoader leak in JBoss
 Threads caused by MDBs
In-Reply-To: <JIRA.12731375.1517237459000@Atlassian.JIRA>
References: <JIRA.12731375.1517237459000@Atlassian.JIRA>
	<JIRA.12731375.1517237459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731375.1517237459000.8705.1517317802227@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525886#comment-13525886 ] 

Markus Dlugi commented on WFLY-9742:
------------------------------------

Alright, thanks for the quick response. That's what I thought as well, I just wasn't sure that there is no code which relies on the initial TCCL of the JBoss Threads.

I could provide a PR for this if you want? Although it's just one line of code, so it might be easier for you to do it yourself.

> ClassLoader leak in JBoss Threads caused by MDBs
> ------------------------------------------------
>
>                 Key: WFLY-9742
>                 URL: https://issues.jboss.org/browse/WFLY-9742
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.Final
>            Reporter: Markus Dlugi
>            Assignee: David Lloyd
>         Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip
>
>
> There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs. When a new MDB is created and a new thread for the MDB is started in the JCA thread pool ("default-threads - x"), the thread will be created using the context classloader of the MDB's deployment unit. This is because [MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/messagedriven/MessageDrivenComponent.java#L275] sets the context classloader of the ServerService thread in order to create the MDB, and this classloader will then also be used by the child thread.
> In the default configuration, the threads in the default thread pool will not be terminated and therefore the thread will keep the reference to the classloader even when the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError: Metaspace" after a couple of redeployments.
> As a workaround, we changed [JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-threads/blob/master/src/main/java/org/jboss/threads/JBossThreadFactory.java#L104] to set the context classloader to null after a new thread has been created. While this fixes the issue for us, I am not sure whether this is a good solution for all consumers of the thread factory, or if this should be fixed in the JCA subsystem instead. That's also the reason why I opened this issue against the WildFly project instead of JBoss Threads.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 08:14:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 30 Jan 2018 08:14:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3563) Could not enable
 application deployment on two server groups in domain
In-Reply-To: <JIRA.12731530.1517306316000@Atlassian.JIRA>
References: <JIRA.12731530.1517306316000@Atlassian.JIRA>
	<JIRA.12731530.1517306316000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731530.1517306316000.8788.1517318040862@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525892#comment-13525892 ] 

Jean-Francois Denise commented on WFCORE-3563:
----------------------------------------------

[~vmarek], is it a new behavior? I just checked in 3.x branch and the behavior is similar, we can't re-deploy a disabled deployment in domain mode from the command. [~mkopecky] could you confirm that 7.1 has same behavior?

> Could not enable application deployment on two server groups in domain
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-3563
>                 URL: https://issues.jboss.org/browse/WFCORE-3563
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> {noformat}
> [domain at localhost:9990 /] deployment enable --server-groups=other-server-group,main-server-group cli-test-app-deploy-all.ear
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [
>     (\"server-group\" => \"other-server-group\"),
>     (\"deployment\" => \"cli-test-app-deploy-all.ear\")
> ]"}}
> [domain at localhost:9990 /] 
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deploy --name=cli-test-app-deploy-all.ear --server-groups=other-server-group,main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [
>     (\"server-group\" => \"other-server-group\"),
>     (\"deployment\" => \"cli-test-app-deploy-all.ear\")
> ]"}}
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 08:25:00 2018
From: issues at jboss.org (Leonid Konov (JIRA))
Date: Tue, 30 Jan 2018 08:25:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JBWEB-316) Invalid URL
In-Reply-To: <JIRA.12731660.1517318685000@Atlassian.JIRA>
References: <JIRA.12731660.1517318685000@Atlassian.JIRA>
	<JIRA.12731660.1517318685251@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731660.1517318685000.9038.1517318700624@Atlassian.JIRA>

Leonid Konov created JBWEB-316:
----------------------------------

             Summary: Invalid URL
                 Key: JBWEB-316
                 URL: https://issues.jboss.org/browse/JBWEB-316
             Project: JBoss Web
          Issue Type: Enhancement
            Reporter: Leonid Konov
            Assignee: Remy Maucherat
            Priority: Minor


http://jbossweb.jboss.org/downloads/jboss-native-2-0-8.html

All download hyperlinks does not works 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 08:31:00 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Tue, 30 Jan 2018 08:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9742) ClassLoader leak in JBoss
 Threads caused by MDBs
In-Reply-To: <JIRA.12731375.1517237459000@Atlassian.JIRA>
References: <JIRA.12731375.1517237459000@Atlassian.JIRA>
	<JIRA.12731375.1517237459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731375.1517237459000.9107.1517319060902@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9742?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525920#comment-13525920 ] 

David Lloyd commented on WFLY-9742:
-----------------------------------

I'm in a conference this week, so I won't get to it until next week.  If you want to work up a PR that would be great.

> ClassLoader leak in JBoss Threads caused by MDBs
> ------------------------------------------------
>
>                 Key: WFLY-9742
>                 URL: https://issues.jboss.org/browse/WFLY-9742
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.Final
>            Reporter: Markus Dlugi
>            Assignee: David Lloyd
>         Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip
>
>
> There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs. When a new MDB is created and a new thread for the MDB is started in the JCA thread pool ("default-threads - x"), the thread will be created using the context classloader of the MDB's deployment unit. This is because [MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/messagedriven/MessageDrivenComponent.java#L275] sets the context classloader of the ServerService thread in order to create the MDB, and this classloader will then also be used by the child thread.
> In the default configuration, the threads in the default thread pool will not be terminated and therefore the thread will keep the reference to the classloader even when the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError: Metaspace" after a couple of redeployments.
> As a workaround, we changed [JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-threads/blob/master/src/main/java/org/jboss/threads/JBossThreadFactory.java#L104] to set the context classloader to null after a new thread has been created. While this fixes the issue for us, I am not sure whether this is a good solution for all consumers of the thread factory, or if this should be fixed in the JCA subsystem instead. That's also the reason why I opened this issue against the WildFly project instead of JBoss Threads.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 08:32:00 2018
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Tue, 30 Jan 2018 08:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2280) Resolving rule unit
 classnames depends on File.separator character
In-Reply-To: <JIRA.12731384.1517239803000@Atlassian.JIRA>
References: <JIRA.12731384.1517239803000@Atlassian.JIRA>
	<JIRA.12731384.1517239803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731384.1517239803000.9112.1517319120410@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tibor Zim?nyi updated DROOLS-2280:
----------------------------------
    Summary: Resolving rule unit classnames depends on File.separator character  (was: Test RuleUnitTest.testNamingConventionOnDrlFile() uses OS specific separator character)


> Resolving rule unit classnames depends on File.separator character
> ------------------------------------------------------------------
>
>                 Key: DROOLS-2280
>                 URL: https://issues.jboss.org/browse/DROOLS-2280
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Tibor Zim?nyi
>            Priority: Minor
>
> When running testNamingConventionOnDrlFile test on Windows, it fails on NPE, because the engine cannot find the rule unit "org/kie/test/MyRuleUnit" defined in the test, because it contains "/" separator character. 
> I will provide a fix to the test. 
> For resolving the rule unit class, the engine uses OS independent character correctly here [1].
> [1] https://github.com/kiegroup/drools/blob/5fad04919f255933bdd34afdb8da10b94f2c8c43/drools-compiler/src/main/java/org/drools/compiler/rule/builder/RuleBuildContext.java#L184



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan 30 08:34:01 2018
From: issues at jboss.org (=?UTF-8?Q?Tibor_Zim=C3=A1nyi_=28JIRA=29?=)
Date: Tue, 30 Jan 2018 08:34:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2280) Resolving rule unit
 classnames depends on File.separator character
In-Reply-To: <JIRA.12731384.1517239803000@Atlassian.JIRA>
References: <JIRA.12731384.1517239803000@Atlassian.JIRA>
	<JIRA.12731384.1517239803000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731384.1517239803000.9181.1517319241792@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Tibor Zim?nyi updated DROOLS-2280:
----------------------------------
    Description: 
When running testNamingConventionOnDrlFile test on Windows, it fails on NPE, because the engine cannot find the rule unit "org/kie/test/MyRuleUnit" defined in the test, because it contains "/" separator character. The method that resolves the classname searches for File.separator character in the mentioned string, which is "\" on Windows [1]. 

This is a bug, because e.g. MemoryFileSystem uses "/" also when running on Windows. The classname resolution should be OS independent.  

[1] https://github.com/kiegroup/drools/blob/5fad04919f255933bdd34afdb8da10b94f2c8c43/drools-compiler/src/main/java/org/drools/compiler/rule/builder/RuleBuildContext.java#L184

  was:
When running testNamingConventionOnDrlFile test on Windows, it fails on NPE, because the engine cannot find the rule unit "org/kie/test/MyRuleUnit" defined in the test, because it contains "/" separator character. 

I will provide a fix to the test. 

For resolving the rule unit class, the engine uses OS independent character correctly here [1].

[1] https://github.com/kiegroup/drools/blob/5fad04919f255933bdd34afdb8da10b94f2c8c43/drools-compiler/src/main/java/org/drools/compiler/rule/builder/RuleBuildContext.java#L184



> Resolving rule unit classnames depends on File.separator character
> ------------------------------------------------------------------
>
>                 Key: DROOLS-2280
>                 URL: https://issues.jboss.org/browse/DROOLS-2280
>             Project: Drools
>          Issue Type: Bug
>          Components: core engine
>    Affects Versions: 7.5.0.Final
>            Reporter: Tibor Zim?nyi
>            Assignee: Tibor Zim?nyi
>            Priority: Minor
>
> When running testNamingConventionOnDrlFile test on Windows, it fails on NPE, because the engine cannot find the rule unit "org/kie/test/MyRuleUnit" defined in the test, because it contains "/" separator character. The method that resolves the classname searches for File.separator character in the mentioned string, which is "\" on Windows [1]. 
> This is a bug, because e.g. MemoryFileSystem uses "/" also when running on Windows. The classname resolution should be OS independent.  
> [1] https://github.com/kiegroup/drools/blob/5fad04919f255933bdd34afdb8da10b94f2c8c43/drools-compiler/src/main/java/org/drools/compiler/rule/builder/RuleBuildContext.java#L184



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Tue Jan 30 08:47:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 30 Jan 2018 08:47:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3564) Bad CLI complementation
	server groups
In-Reply-To: <JIRA.12731536.1517307609000@Atlassian.JIRA>
References: <JIRA.12731536.1517307609000@Atlassian.JIRA>
	<JIRA.12731536.1517307609000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731536.1517307609000.9308.1517320020249@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525936#comment-13525936 ] 

Jean-Francois Denise commented on WFCORE-3564:
----------------------------------------------

[~vmarek], thank-you for reporting the issue, if you plan to add a unit test to cover the problem,  we have a CliCompletionTestCase class in testsuite/domain that is perfect to deal with this kind of issues. You could add a new test in it.
Thanks.

> Bad CLI complementation server groups
> -------------------------------------
>
>                 Key: WFCORE-3564
>                 URL: https://issues.jboss.org/browse/WFCORE-3564
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> *Cli complementation insert the whole word without delete writed letters*
> * --server-groups={color:#d04437}m{color}main-server-group
> * --server-groups={color:#d04437}o{color}other-server-group
> * --server-groups={color:#d04437}othe{color}other-server-group
> {noformat}
> [domain at localhost:9990 /] deployment disable * --server-groups=
> main-server-group  other-server-group  
> [domain at localhost:9990 /] deployment disable * --server-groups=mmain-server-group 
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"server-group\" => \"mmain-server-group\")]' not found"}}
> [domain at localhost:9990 /] deployment disable * --server-groups=oother-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"server-group\" => \"oother-server-group\")]' not found"}}
> [domain at localhost:9990 /]
> [domain at localhost:9990 /] deployment disable * --server-groups=otheother-server-group 
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"server-group\" => \"otheother-server-group\")]' not found"}}
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 08:54:00 2018
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Tue, 30 Jan 2018 08:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3273) sharedState is passed null
 by PluginAuthenticationCallbackHandler
In-Reply-To: <JIRA.12711153.1505133831000@Atlassian.JIRA>
References: <JIRA.12711153.1505133831000@Atlassian.JIRA>
	<JIRA.12711153.1505133831000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12711153.1505133831000.9363.1517320440461@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3273?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525946#comment-13525946 ] 

RH Bugzilla Integration commented on WFCORE-3273:
-------------------------------------------------

Lukas Svaty <lsvaty at redhat.com> changed the Status of [bug 1490383|https://bugzilla.redhat.com/show_bug.cgi?id=1490383] from ON_QA to VERIFIED

> sharedState is passed null by PluginAuthenticationCallbackHandler
> -----------------------------------------------------------------
>
>                 Key: WFCORE-3273
>                 URL: https://issues.jboss.org/browse/WFCORE-3273
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: Security
>         Environment: Fedora 26, using ovirt-engine-wildfly package
>            Reporter: Roy Golan
>            Assignee: Darran Lofthouse
>             Fix For: 3.0.2.Final, 4.0.0.Alpha1
>
>
> oVirt's ovirt-engine uses an authentication plugin [1] for management interface that recently after upgrading to Wildfly 11 stopped working. The reason is the sharedState passed to the plugin's init method is now null.
> A current workaround this would be to avoid adding the plugin into the shareState, but that means any delegating plugin would fail to find this plugin and possibly other bad stuff I'm not aware of.
> [1] https://gerrit.ovirt.org/gitweb?p=ovirt-engine.git;a=blob;f=backend/manager/modules/auth-plugin/src/main/java/org/ovirt/engine/core/jboss_auth_plugin/OvirtAuthPlugIn.java;h=fe2fcb400c0c81d661c03fac173d6ad416b42b9d;hb=95d62f8d7879b1863f2db74f88affb246cf94b37#l26



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 09:08:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Tue, 30 Jan 2018 09:08:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3563) Could not enable
 application deployment on two server groups in domain
In-Reply-To: <JIRA.12731530.1517306316000@Atlassian.JIRA>
References: <JIRA.12731530.1517306316000@Atlassian.JIRA>
	<JIRA.12731530.1517306316000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731530.1517306316000.9536.1517321280634@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525969#comment-13525969 ] 

Vratislav Marek commented on WFCORE-3563:
-----------------------------------------

*I found it in version Jboss EAP7 to*
{noformat}
[domain at localhost:9990 /] version
JBoss Admin Command-line Interface
JBOSS_HOME: /media/Data/TestArea/Install/EAP
Release: 3.0.10.Final-redhat-1 "Kenny"
Product: JBoss EAP 7.1.0.GA
JAVA_HOME: /var/jdk-stable/
java.version: 1.8.0_151
java.vm.vendor: Oracle Corporation
java.vm.version: 25.151-b12
os.name: Linux
os.version: 4.13.16-100.fc25.x86_64
[domain at localhost:9990 /]
{noformat}

{noformat}
[domain at localhost:9990 /] deploy --server-groups=main-server-group,other-server-group /media/Data/Repos/Remote/Public/tmp/Resource/Part000.war
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME        RUNTIME-NAME STATE   
Part000.war Part000.war  enabled 
[domain at localhost:9990 /] deployment-info --server-group=other-server-group
NAME        RUNTIME-NAME STATE   
Part000.war Part000.war  enabled 
[domain at localhost:9990 /]
[domain at localhost:9990 /] undeploy Part000.war --keep-content --server-groups=main-server-group,other-server-group
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME        RUNTIME-NAME STATE 
Part000.war Part000.war  added 
[domain at localhost:9990 /] deployment-info --server-group=other-server-group
NAME        RUNTIME-NAME STATE 
Part000.war Part000.war  added 
[domain at localhost:9990 /] undeploy Part000.war --keep-content --server-groups=main-server-group,other-server-group
[domain at localhost:9990 /] deploy --name=Part000.war --server-groups=main-server-group,other-server-group
{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [
    (\"server-group\" => \"main-server-group\"),
    (\"deployment\" => \"Part000.war\")
[domain at localhost:9990 /] 
{noformat}

> Could not enable application deployment on two server groups in domain
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-3563
>                 URL: https://issues.jboss.org/browse/WFCORE-3563
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> {noformat}
> [domain at localhost:9990 /] deployment enable --server-groups=other-server-group,main-server-group cli-test-app-deploy-all.ear
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [
>     (\"server-group\" => \"other-server-group\"),
>     (\"deployment\" => \"cli-test-app-deploy-all.ear\")
> ]"}}
> [domain at localhost:9990 /] 
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deploy --name=cli-test-app-deploy-all.ear --server-groups=other-server-group,main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [
>     (\"server-group\" => \"other-server-group\"),
>     (\"deployment\" => \"cli-test-app-deploy-all.ear\")
> ]"}}
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 09:12:00 2018
From: issues at jboss.org (Markus Dlugi (JIRA))
Date: Tue, 30 Jan 2018 09:12:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9742) ClassLoader leak in JBoss
 Threads caused by MDBs
In-Reply-To: <JIRA.12731375.1517237459000@Atlassian.JIRA>
References: <JIRA.12731375.1517237459000@Atlassian.JIRA>
	<JIRA.12731375.1517237459000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731375.1517237459000.9657.1517321520450@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9742?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Markus Dlugi updated WFLY-9742:
-------------------------------
    Git Pull Request: https://github.com/jbossas/jboss-threads/pull/24


> ClassLoader leak in JBoss Threads caused by MDBs
> ------------------------------------------------
>
>                 Key: WFLY-9742
>                 URL: https://issues.jboss.org/browse/WFLY-9742
>             Project: WildFly
>          Issue Type: Bug
>    Affects Versions: 11.0.0.Final
>            Reporter: Markus Dlugi
>            Assignee: David Lloyd
>         Attachments: default-threads-tccl.png, jboss-threads-tccl-example.zip
>
>
> There is a classloader leak in JBoss Threads which is most noticable when deploying MDBs. When a new MDB is created and a new thread for the MDB is started in the JCA thread pool ("default-threads - x"), the thread will be created using the context classloader of the MDB's deployment unit. This is because [MessageDrivenComponent.activate()|https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jboss/as/ejb3/component/messagedriven/MessageDrivenComponent.java#L275] sets the context classloader of the ServerService thread in order to create the MDB, and this classloader will then also be used by the child thread.
> In the default configuration, the threads in the default thread pool will not be terminated and therefore the thread will keep the reference to the classloader even when the deployment unit is undeployed. This in turn can lead to "OutOfMemoryError: Metaspace" after a couple of redeployments.
> As a workaround, we changed [JBossThreadFactory.createThread()|https://github.com/jbossas/jboss-threads/blob/master/src/main/java/org/jboss/threads/JBossThreadFactory.java#L104] to set the context classloader to null after a new thread has been created. While this fixes the issue for us, I am not sure whether this is a good solution for all consumers of the thread factory, or if this should be fixed in the JCA subsystem instead. That's also the reason why I opened this issue against the WildFly project instead of JBoss Threads.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 09:16:01 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 30 Jan 2018 09:16:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3567) CLI,
 deployment enable-all/disable-all doesn't propose domain specific
 options
In-Reply-To: <JIRA.12731672.1517321743000@Atlassian.JIRA>
References: <JIRA.12731672.1517321743000@Atlassian.JIRA>
	<JIRA.12731672.1517321743908@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731672.1517321743000.9725.1517321761120@Atlassian.JIRA>

Jean-Francois Denise created WFCORE-3567:
--------------------------------------------

             Summary: CLI, deployment enable-all/disable-all doesn't propose domain specific options
                 Key: WFCORE-3567
                 URL: https://issues.jboss.org/browse/WFCORE-3567
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI
            Reporter: Jean-Francois Denise
            Assignee: Jean-Francois Denise


The activators attached to these options are expecting an argument value, but there is no such argument.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 09:17:01 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 30 Jan 2018 09:17:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3564) Bad CLI complementation
	server groups
In-Reply-To: <JIRA.12731536.1517307609000@Atlassian.JIRA>
References: <JIRA.12731536.1517307609000@Atlassian.JIRA>
	<JIRA.12731536.1517307609000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731536.1517307609000.9760.1517321821417@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13525992#comment-13525992 ] 

Jean-Francois Denise commented on WFCORE-3564:
----------------------------------------------

[~vmarek], FYI, I found an issue related to completion in domain mode: https://issues.jboss.org/browse/WFCORE-3567
Just in case you ran into it yourself.


> Bad CLI complementation server groups
> -------------------------------------
>
>                 Key: WFCORE-3564
>                 URL: https://issues.jboss.org/browse/WFCORE-3564
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> *Cli complementation insert the whole word without delete writed letters*
> * --server-groups={color:#d04437}m{color}main-server-group
> * --server-groups={color:#d04437}o{color}other-server-group
> * --server-groups={color:#d04437}othe{color}other-server-group
> {noformat}
> [domain at localhost:9990 /] deployment disable * --server-groups=
> main-server-group  other-server-group  
> [domain at localhost:9990 /] deployment disable * --server-groups=mmain-server-group 
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"server-group\" => \"mmain-server-group\")]' not found"}}
> [domain at localhost:9990 /] deployment disable * --server-groups=oother-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"server-group\" => \"oother-server-group\")]' not found"}}
> [domain at localhost:9990 /]
> [domain at localhost:9990 /] deployment disable * --server-groups=otheother-server-group 
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0216: Management resource '[(\"server-group\" => \"otheother-server-group\")]' not found"}}
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 09:24:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 30 Jan 2018 09:24:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9743) wildscribe: Consider using
 strikethrough for deprecated model attribute/operation/children names
In-Reply-To: <JIRA.12731675.1517322229000@Atlassian.JIRA>
References: <JIRA.12731675.1517322229000@Atlassian.JIRA>
	<JIRA.12731675.1517322229876@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731675.1517322229000.9819.1517322240338@Atlassian.JIRA>

Radoslav Husar created WFLY-9743:
------------------------------------

             Summary: wildscribe: Consider using strikethrough for deprecated model attribute/operation/children names
                 Key: WFLY-9743
                 URL: https://issues.jboss.org/browse/WFLY-9743
             Project: WildFly
          Issue Type: Component Upgrade
          Components: Documentation
            Reporter: Radoslav Husar






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 09:38:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 30 Jan 2018 09:38:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9744) Improve Infinispan subsystem
 model descriptions
In-Reply-To: <JIRA.12731678.1517323021000@Atlassian.JIRA>
References: <JIRA.12731678.1517323021000@Atlassian.JIRA>
	<JIRA.12731678.1517323021206@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731678.1517323021000.9971.1517323080175@Atlassian.JIRA>

Radoslav Husar created WFLY-9744:
------------------------------------

             Summary: Improve Infinispan subsystem model descriptions 
                 Key: WFLY-9744
                 URL: https://issues.jboss.org/browse/WFLY-9744
             Project: WildFly
          Issue Type: Task
          Components: Clustering
            Reporter: Radoslav Husar
            Assignee: Paul Ferraro


In order not to duplicate documentation in docs/ and wildscribe, we can link from documentation to wildscribe.

* the descriptions should avoid using domain model terminology (e.g. attributes, child)
* should describe behavior
* take out the redundant verb (unless appropriate, e.g. in operation desc.)



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 09:39:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 30 Jan 2018 09:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9745) Missing clustering API
 documentation in wildfly-capabilities
In-Reply-To: <JIRA.12731679.1517323082000@Atlassian.JIRA>
References: <JIRA.12731679.1517323082000@Atlassian.JIRA>
	<JIRA.12731679.1517323082901@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731679.1517323082000.9978.1517323140308@Atlassian.JIRA>

Radoslav Husar created WFLY-9745:
------------------------------------

             Summary: Missing clustering API documentation in wildfly-capabilities 
                 Key: WFLY-9745
                 URL: https://issues.jboss.org/browse/WFLY-9745
             Project: WildFly
          Issue Type: Task
          Components: Clustering, Documentation
            Reporter: Radoslav Husar
            Assignee: Paul Ferraro






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 09:39:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 30 Jan 2018 09:39:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9745) Missing clustering API
 documentation in wildfly-capabilities
In-Reply-To: <JIRA.12731679.1517323083000@Atlassian.JIRA>
References: <JIRA.12731679.1517323083000@Atlassian.JIRA>
	<JIRA.12731679.1517323083000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731679.1517323083000.9985.1517323140539@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-9745:
---------------------------------
    Description: e.g. https://github.com/wildfly/wildfly-capabilities/tree/master/org/wildfly/clustering/group/capability.adoc linked from wildscribe


> Missing clustering API documentation in wildfly-capabilities 
> -------------------------------------------------------------
>
>                 Key: WFLY-9745
>                 URL: https://issues.jboss.org/browse/WFLY-9745
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering, Documentation
>            Reporter: Radoslav Husar
>            Assignee: Paul Ferraro
>
> e.g. https://github.com/wildfly/wildfly-capabilities/tree/master/org/wildfly/clustering/group/capability.adoc linked from wildscribe



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 10:01:00 2018
From: issues at jboss.org (Jean-Francois Denise (JIRA))
Date: Tue, 30 Jan 2018 10:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3562) Deployment disable-all
 doesn't correct function at domain
In-Reply-To: <JIRA.12731519.1517300290000@Atlassian.JIRA>
References: <JIRA.12731519.1517300290000@Atlassian.JIRA>
	<JIRA.12731519.1517300290000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731519.1517300290000.10287.1517324460427@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526034#comment-13526034 ] 

Jean-Francois Denise commented on WFCORE-3562:
----------------------------------------------

[~vmarek], are you 100% sure of your steps?
I did:
[domain at localhost:9990 /] deployment deploy-file  ../../NetBeansProjects/TestApp/dist/TestApp.war --server-groups=main-server-group,other-server-group --name=Test2
[domain at localhost:9990 /] deployment deploy-file  ../../NetBeansProjects/TestApp/dist/TestApp.war --server-groups=main-server-group,other-server-group
[domain at localhost:9990 /] deployment disable Test2 --server-groups=other-server-group
[domain at localhost:9990 /] deployment disable TestApp.war --server-groups=main-server-group
[domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups

And it worked as expected. Am I missing something? Thank-you.

> Deployment disable-all doesn't correct function at domain
> ---------------------------------------------------------
>
>                 Key: WFCORE-3562
>                 URL: https://issues.jboss.org/browse/WFCORE-3562
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> Domain 
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 11:48:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 30 Jan 2018 11:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9678) Expand clustering test cases
 to 3-node cluster
In-Reply-To: <JIRA.12729233.1516104791000@Atlassian.JIRA>
References: <JIRA.12729233.1516104791000@Atlassian.JIRA>
	<JIRA.12729233.1516104791000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729233.1516104791000.11502.1517330880284@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-9678:
---------------------------------
    Fix Version/s:     (was: 12.0.0.Alpha1)


> Expand clustering test cases to 3-node cluster
> ----------------------------------------------
>
>                 Key: WFLY-9678
>                 URL: https://issues.jboss.org/browse/WFLY-9678
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 11.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> The core of the problem is that since all cases run against 2-node cluster a remote fetch is never tested given that numOwners defaults to 2.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 11:48:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 30 Jan 2018 11:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9678) Expand clustering test cases
 to 3-node cluster
In-Reply-To: <JIRA.12729233.1516104791000@Atlassian.JIRA>
References: <JIRA.12729233.1516104791000@Atlassian.JIRA>
	<JIRA.12729233.1516104791000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729233.1516104791000.11512.1517330880617@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-9678:
---------------------------------
    Description: The core of the problem is that since all cases run against 2-node cluster a remote get(..) is never being tested given that numOwners defaults to 2.  (was: The core of the problem is that since all cases run against 2-node cluster a remote fetch is never tested given that numOwners defaults to 2.)


> Expand clustering test cases to 3-node cluster
> ----------------------------------------------
>
>                 Key: WFLY-9678
>                 URL: https://issues.jboss.org/browse/WFLY-9678
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 11.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>
> The core of the problem is that since all cases run against 2-node cluster a remote get(..) is never being tested given that numOwners defaults to 2.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 11:49:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 30 Jan 2018 11:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9572) Speed-up clustering testsuite
In-Reply-To: <JIRA.12722241.1511518148000@Atlassian.JIRA>
References: <JIRA.12722241.1511518148000@Atlassian.JIRA>
	<JIRA.12722241.1511518148000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722241.1511518148000.11515.1517330940369@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar resolved WFLY-9572.
----------------------------------
    Fix Version/s: 12.0.0.Alpha1
       Resolution: Done


> Speed-up clustering testsuite
> -----------------------------
>
>                 Key: WFLY-9572
>                 URL: https://issues.jboss.org/browse/WFLY-9572
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering, Test Suite
>    Affects Versions: 11.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 12.0.0.Alpha1
>
>
> Tracking issue for speeding up clustering testsuite.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 11:49:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 30 Jan 2018 11:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9572) Speed-up clustering testsuite
In-Reply-To: <JIRA.12722241.1511518148000@Atlassian.JIRA>
References: <JIRA.12722241.1511518148000@Atlassian.JIRA>
	<JIRA.12722241.1511518148000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12722241.1511518148000.11518.1517330940450@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526144#comment-13526144 ] 

Radoslav Husar commented on WFLY-9572:
--------------------------------------

All incorporated issues are resolved, there is a couple of follow up Jiras that will follow to expand the testsuite.

> Speed-up clustering testsuite
> -----------------------------
>
>                 Key: WFLY-9572
>                 URL: https://issues.jboss.org/browse/WFLY-9572
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering, Test Suite
>    Affects Versions: 11.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>             Fix For: 12.0.0.Alpha1
>
>
> Tracking issue for speeding up clustering testsuite.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 11:49:00 2018
From: issues at jboss.org (Radoslav Husar (JIRA))
Date: Tue, 30 Jan 2018 11:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9678) Expand clustering test cases
 to 3-node cluster
In-Reply-To: <JIRA.12729233.1516104791000@Atlassian.JIRA>
References: <JIRA.12729233.1516104791000@Atlassian.JIRA>
	<JIRA.12729233.1516104791000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729233.1516104791000.11521.1517330940760@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9678?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Radoslav Husar updated WFLY-9678:
---------------------------------
    Priority: Critical  (was: Major)


> Expand clustering test cases to 3-node cluster
> ----------------------------------------------
>
>                 Key: WFLY-9678
>                 URL: https://issues.jboss.org/browse/WFLY-9678
>             Project: WildFly
>          Issue Type: Task
>          Components: Clustering
>    Affects Versions: 11.0.0.Final
>            Reporter: Radoslav Husar
>            Assignee: Radoslav Husar
>            Priority: Critical
>
> The core of the problem is that since all cases run against 2-node cluster a remote get(..) is never being tested given that numOwners defaults to 2.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 11:52:00 2018
From: issues at jboss.org (Alexandre Porcelli (JIRA))
Date: Tue, 30 Jan 2018 11:52:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2268) Add more fine-grained
 control on all assets
In-Reply-To: <JIRA.12730525.1516792019000@Atlassian.JIRA>
References: <JIRA.12730525.1516792019000@Atlassian.JIRA>
	<JIRA.12730525.1516792019000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730525.1516792019000.11553.1517331120700@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/DROOLS-2268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526150#comment-13526150 ] 

Alexandre Porcelli commented on DROOLS-2268:
--------------------------------------------

I don't see permission per file happening any time soon.

> Add more fine-grained control on all assets
> -------------------------------------------
>
>                 Key: DROOLS-2268
>                 URL: https://issues.jboss.org/browse/DROOLS-2268
>             Project: Drools
>          Issue Type: Enhancement
>          Components: Artifact Repository
>    Affects Versions: 6.5.0.Final
>            Reporter: Richard Bourner
>            Assignee: Michael Anstis
>            Priority: Minor
>
> Currently, permissions within Business Central are only at projects level.
> It would be interesting to be able to enable permissions at a more fine-grained level.
> For instance, in a single project of one repository, having some people with read-only access on some assets, and other people have read/write access to the same assets.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 15:42:00 2018
From: issues at jboss.org (Gail Badner (JIRA))
Date: Tue, 30 Jan 2018 15:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9739) JPA / Hibernate: There is
 already an object named 'x' in the database
In-Reply-To: <JIRA.12731092.1517002049000@Atlassian.JIRA>
References: <JIRA.12731092.1517002049000@Atlassian.JIRA>
	<JIRA.12731092.1517002049000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731092.1517002049000.12800.1517344920116@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9739?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526277#comment-13526277 ] 

Gail Badner commented on WFLY-9739:
-----------------------------------

[~smarlow], I see https://hibernate.atlassian.net/browse/HHH-12259. Can this issue be rejected now?

> JPA / Hibernate: There is already an object named 'x' in the database
> ---------------------------------------------------------------------
>
>                 Key: WFLY-9739
>                 URL: https://issues.jboss.org/browse/WFLY-9739
>             Project: WildFly
>          Issue Type: Bug
>          Components: JPA / Hibernate
>    Affects Versions: 11.0.0.Final
>         Environment: Windows 10 64 bits / Windows Server 2012 R2 64 bits
> Java version: 1.8.0_151
> SQL Server 2014
>            Reporter: Eric SantAnna
>            Assignee: Scott Marlow
>         Attachments: sqljdbc4.jar, wildfly11-migration.zip
>
>
> I'm getting an Exception as a warning in the server.log when a database object already exists an my persistence.xml has the property "hibernate.hbm2ddl.auto" set to "update".
> This doesn't happen in my tests with 10.1.0.Final.
> Appearently, despite these Exceptions, all my applications are running ok.
> I saw this behaviour while I was migrating my application from JBoss 7.1.1.Final to Wildfly. I'm deciding between Wildfly 10.1 and 11.
> This behaviour isn't good cause, I'm flooding the logs and it doesn't seem reliable for my manager.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Tue Jan 30 22:50:00 2018
From: issues at jboss.org (Chao Wang (JIRA))
Date: Tue, 30 Jan 2018 22:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3568) Allow CLI output scrolling
In-Reply-To: <JIRA.12731769.1517370575000@Atlassian.JIRA>
References: <JIRA.12731769.1517370575000@Atlassian.JIRA>
	<JIRA.12731769.1517370575585@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731769.1517370575000.13382.1517370600251@Atlassian.JIRA>

Chao Wang created WFCORE-3568:
---------------------------------

             Summary: Allow CLI output scrolling
                 Key: WFCORE-3568
                 URL: https://issues.jboss.org/browse/WFCORE-3568
             Project: WildFly Core
          Issue Type: Enhancement
          Components: CLI
    Affects Versions: 4.0.0.Alpha8
            Reporter: Chao Wang
            Assignee: Jean-Francois Denise


Mouse scrolling is forbidden to large CLI out. User has to press {{Down}} or {{Enter}} to navigate.
It would be nice to allow fast scrolling or {{PgUp}} / {{PgDn}}. e.g.
{noformat}
[standalone at localhost:9990 /] /core-service=capability-registry:read-resource
{
    "outcome" => "success",
    "result" => {
        "capabilities" => [
            {
                "name" => "org.wildfly.batch.configuration",
                "dynamic" => false,
                "scope" => "global",
                "registration-points" => ["/subsystem=batch-jberet"]
            },
            {
                "name" => "org.wildfly.batch.job.repository.in-memory",
                "dynamic" => false,
                "scope" => "global",
                "registration-points" => ["/subsystem=batch-jberet/in-memory-job-repository=in-memory"]
            },
            {
                "name" => "org.wildfly.batch.thread.pool.batch",
                "dynamic" => false,
                "scope" => "global",
                "registration-points" => ["/subsystem=batch-jberet/thread-pool=batch"]
            },
            {
                "name" => "org.wildfly.clustering.cache.default-group.ejb",
                "dynamic" => false,
                "scope" => "global",
                "registration-points" => ["/subsystem=infinispan/cache-container=ejb"]
            },
            {
                "name" => "org.wildfly.clustering.cache.default-group.server",
                "dynamic" => false,
                "scope" => "global",
                "registration-points" => ["/subsystem=infinispan/cache-container=server"]
            },
            {
                "name" => "org.wildfly.clustering.cache.default-group.web",
                "dynamic" => false,
                "scope" => "global",
                "registration-points" => ["/subsystem=infinispan/cache-container=web"]
            },
            {
                "name" => "org.wildfly.clustering.cache.default-node-factory.ejb",
                "dynamic" => false,
                "scope" => "global",
                "registration-points" => ["/subsystem=infinispan/cache-container=ejb"]
            },
            {
                "name" => "org.wildfly.clustering.cache.default-node-factory.server",
                "dynamic" => false,
--More(2%)--
{noformat}

Also, after pressing {{Down}} or {{Enter}} to display more output, user can not press {{up}} to go up. User has to inconveniently use scroll up.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 01:22:00 2018
From: issues at jboss.org (Chao Wang (JIRA))
Date: Wed, 31 Jan 2018 01:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3569) NPE is shown in server
	shutdown
In-Reply-To: <JIRA.12731773.1517379694000@Atlassian.JIRA>
References: <JIRA.12731773.1517379694000@Atlassian.JIRA>
	<JIRA.12731773.1517379694272@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731773.1517379694000.13643.1517379720126@Atlassian.JIRA>

Chao Wang created WFCORE-3569:
---------------------------------

             Summary: NPE is shown in server shutdown
                 Key: WFCORE-3569
                 URL: https://issues.jboss.org/browse/WFCORE-3569
             Project: WildFly Core
          Issue Type: Bug
          Components: CLI, Domain Management, IO, Server
    Affects Versions: 4.0.0.Alpha8
            Reporter: Chao Wang
            Assignee: David Lloyd
            Priority: Critical


NullPointerException is shown in server shutdown with an open CLI connection in current WFLY master since WFCORE 4.0.0.Alpha7.

Start the server and open a CLI connection, then stop server with Ctrl + C. We will see

{noformat}
13:15:09,136 ERROR [org.jboss.threads.errors] (management task-1) Thread Thread[management task-1,5,main] threw an uncaught exception: java.lang.NullPointerException
	at org.jboss.as.server.mgmt.ManagementWorkerService.stopDone(ManagementWorkerService.java:72)
	at org.xnio.XnioWorker$1.run(XnioWorker.java:138)
	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
	at org.jboss.threads.EnhancedQueueExecutor.completeTermination(EnhancedQueueExecutor.java:1755)
	at org.jboss.threads.EnhancedQueueExecutor.tryDeallocateThread(EnhancedQueueExecutor.java:1578)
	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1393)
	at java.lang.Thread.run(Thread.java:748)

{noformat}

I assign this to David as it seems this is caused by WFCORE-3397 and https://github.com/wildfly/wildfly-core/pull/3072 Please feel free to reassign to correct person. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 02:30:00 2018
From: issues at jboss.org (Vratislav Marek (JIRA))
Date: Wed, 31 Jan 2018 02:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3562) Deployment disable-all
 doesn't correct function at domain
In-Reply-To: <JIRA.12731519.1517300290000@Atlassian.JIRA>
References: <JIRA.12731519.1517300290000@Atlassian.JIRA>
	<JIRA.12731519.1517300290000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731519.1517300290000.13852.1517383800375@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526387#comment-13526387 ] 

Vratislav Marek commented on WFCORE-3562:
-----------------------------------------

[~jdenise], I am sure with my steps, you miss two next deployments.
I tray it again...
With two it worked as expected:
{noformat}
[domain at localhost:9990 /] deployment deploy-file --server-groups=main-server-group /media/Data/Repos/Remote/Public/wildfly-core/testsuite/domain/target/cli-test-app1-deploy-all.war
[domain at localhost:9990 /] deployment deploy-file --server-groups=other-server-group,main-server-group /media/Data/Repos/Remote/Public/wildfly-core/testsuite/domain/target/cli-test-app3-deploy-all.war
[domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups
[domain at localhost:9990 /] deployment info --server-group=
failure-test-group  ignored-profile  ignored-sockets  main-server-group  minimal  other-server-group  reload-test-group  
[domain at localhost:9990 /] deployment info --server-group=main-server-group 
NAME                         RUNTIME-NAME                 STATE 
cli-test-app1-deploy-all.war cli-test-app1-deploy-all.war added 
cli-test-app3-deploy-all.war cli-test-app3-deploy-all.war added 
[domain at localhost:9990 /] deployment info --server-group=other-server-group 
NAME                         RUNTIME-NAME                 STATE     
cli-test-app1-deploy-all.war cli-test-app1-deploy-all.war not added 
cli-test-app3-deploy-all.war cli-test-app3-deploy-all.war added     
[domain at localhost:9990 /] deployment undeploy * --all-relevant-server-groups 
[domain at localhost:9990 /] deployment info --server-group=other-server-group 
[domain at localhost:9990 /] 
{noformat}

But with 3 deployments doesn't:
{noformat}
[domain at localhost:9990 /] deployment deploy-file --server-groups=main-server-group /media/Data/Repos/Remote/Public/wildfly-core/testsuite/domain/target/cli-test-app1-deploy-all.war
[domain at localhost:9990 /] deployment deploy-file --server-groups=main-server-group /media/Data/Repos/Remote/Public/wildfly-core/testsuite/domain/target/cli-test-another-deploy-all.war
[domain at localhost:9990 /] deployment deploy-file --server-groups=other-server-group,main-server-group /media/Data/Repos/Remote/Public/wildfly-core/testsuite/domain/target/cli-test-app3-deploy-all.war
[domain at localhost:9990 /] 
[domain at localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
[domain at localhost:9990 /] 
[domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups
org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
[domain at localhost:9990 /] deployment info --server-group=main-server-group 
NAME                            RUNTIME-NAME                    STATE   
cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled 
cli-test-app1-deploy-all.war    cli-test-app1-deploy-all.war    added   
cli-test-app3-deploy-all.war    cli-test-app3-deploy-all.war    enabled 
[domain at localhost:9990 /] deployment info --server-group=other-server-group 
NAME                            RUNTIME-NAME                    STATE     
cli-test-another-deploy-all.war cli-test-another-deploy-all.war not added 
cli-test-app1-deploy-all.war    cli-test-app1-deploy-all.war    not added 
cli-test-app3-deploy-all.war    cli-test-app3-deploy-all.war    enabled   
[domain at localhost:9990 /] 
{noformat}

If I tested it with less than 4 before some deployments must be remaining installed.

> Deployment disable-all doesn't correct function at domain
> ---------------------------------------------------------
>
>                 Key: WFCORE-3562
>                 URL: https://issues.jboss.org/browse/WFCORE-3562
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> Domain 
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 02:53:01 2018
From: issues at jboss.org (David Lloyd (JIRA))
Date: Wed, 31 Jan 2018 02:53:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3569) NPE is shown in server
	shutdown
In-Reply-To: <JIRA.12731773.1517379694000@Atlassian.JIRA>
References: <JIRA.12731773.1517379694000@Atlassian.JIRA>
	<JIRA.12731773.1517379694000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731773.1517379694000.13992.1517385181195@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526404#comment-13526404 ] 

David Lloyd commented on WFCORE-3569:
-------------------------------------

[~brian.stansberry] this looks like the same issue you were seeing, right?

> NPE is shown in server shutdown
> -------------------------------
>
>                 Key: WFCORE-3569
>                 URL: https://issues.jboss.org/browse/WFCORE-3569
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management, IO, Server
>    Affects Versions: 4.0.0.Alpha8
>            Reporter: Chao Wang
>            Assignee: David Lloyd
>            Priority: Critical
>
> NullPointerException is shown in server shutdown with an open CLI connection in current WFLY master since WFCORE 4.0.0.Alpha7.
> Start the server and open a CLI connection, then stop server with Ctrl + C. We will see
> {noformat}
> 13:15:09,136 ERROR [org.jboss.threads.errors] (management task-1) Thread Thread[management task-1,5,main] threw an uncaught exception: java.lang.NullPointerException
> 	at org.jboss.as.server.mgmt.ManagementWorkerService.stopDone(ManagementWorkerService.java:72)
> 	at org.xnio.XnioWorker$1.run(XnioWorker.java:138)
> 	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> 	at org.jboss.threads.EnhancedQueueExecutor.completeTermination(EnhancedQueueExecutor.java:1755)
> 	at org.jboss.threads.EnhancedQueueExecutor.tryDeallocateThread(EnhancedQueueExecutor.java:1578)
> 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1393)
> 	at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I assign this to David as it seems this is caused by WFCORE-3397 and https://github.com/wildfly/wildfly-core/pull/3072 Please feel free to reassign to correct person. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 04:42:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 31 Jan 2018 04:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3562) Deployment disable-all
 doesn't correct function at domain
In-Reply-To: <JIRA.12731519.1517300290000@Atlassian.JIRA>
References: <JIRA.12731519.1517300290000@Atlassian.JIRA>
	<JIRA.12731519.1517300290000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731519.1517300290000.14722.1517391720541@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526467#comment-13526467 ] 

Marek Kopeck? commented on WFCORE-3562:
---------------------------------------

I'm able to reproduce this issue with three deployments too. I attached deployments that I used.

This is not a regression against EAP 7.1, because legacy deploy commands works correctly, but new deployment command doesn't work in this scenario.

*These are my experiments:*
*New way:*
{noformat}
deployment deploy-file --server-groups=main-server-group ~/erase15/app01.war
deployment deploy-file --server-groups=main-server-group ~/erase15/app02.war
deployment deploy-file --server-groups=other-server-group,main-server-group ~/erase15/app03.war
deployment disable --server-groups=main-server-group app01.war
deployment info --server-group=main-server-group
deployment disable-all --all-relevant-server-groups
deployment info --server-group=main-server-group
{noformat}

WF master results (error occurs):
{noformat}
[domain at localhost:9990 /] deployment deploy-file --server-groups=main-server-group ~/erase15/app01.war
[domain at localhost:9990 /] deployment deploy-file --server-groups=main-server-group ~/erase15/app02.war
[domain at localhost:9990 /] deployment deploy-file --server-groups=other-server-group,main-server-group ~/erase15/app03.war
[domain at localhost:9990 /] deployment disable --server-groups=main-server-group app01.war
[domain at localhost:9990 /] deployment info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups
org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
[domain at localhost:9990 /] deployment info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] 
{noformat}

*Legacy way:*
{noformat}
deploy ~/erase15/app01.war --server-groups=main-server-group
deploy ~/erase15/app02.war --server-groups=main-server-group
deploy ~/erase15/app03.war --server-groups=other-server-group,main-server-group
undeploy app01.war --keep-content --server-groups=main-server-group
deployment-info --server-group=main-server-group
undeploy * --keep-content --server-groups=main-server-group
deployment-info --server-group=main-server-group
{noformat}


EAP 7.1 results (error doesn't occurs):
{noformat}
[mkopecky at dhcp-10-40-5-4 bin]$ ./jboss-cli.sh -c
[domain at localhost:9990 /] deploy ~/erase15/app01.war --server-groups=main-server-group
[domain at localhost:9990 /] deploy ~/erase15/app02.war --server-groups=main-server-group
[domain at localhost:9990 /] deploy ~/erase15/app03.war --server-groups=other-server-group,main-server-group
[domain at localhost:9990 /] undeploy app01.war --keep-content --server-groups=main-server-group
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME      RUNTIME-NAME STATE 
app01.war app01.war    added 
app02.war app02.war    added 
app03.war app03.war    added 
[domain at localhost:9990 /] 
{noformat}


WF master results (error doesn't occurs):
{noformat}
[domain at localhost:9990 /] deploy ~/erase15/app01.war --server-groups=main-server-group
[domain at localhost:9990 /] deploy ~/erase15/app02.war --server-groups=main-server-group
[domain at localhost:9990 /] deploy ~/erase15/app03.war --server-groups=other-server-group,main-server-group
[domain at localhost:9990 /] undeploy app01.war --keep-content --server-groups=main-server-group
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME      RUNTIME-NAME STATE 
app01.war app01.war    added 
app02.war app02.war    added 
app03.war app03.war    added 
[domain at localhost:9990 /] 
{noformat}

> Deployment disable-all doesn't correct function at domain
> ---------------------------------------------------------
>
>                 Key: WFCORE-3562
>                 URL: https://issues.jboss.org/browse/WFCORE-3562
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>         Attachments: app01.war, app02.war, app03.war
>
>
> Domain 
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 04:42:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 31 Jan 2018 04:42:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3562) Deployment disable-all
 doesn't correct function at domain
In-Reply-To: <JIRA.12731519.1517300290000@Atlassian.JIRA>
References: <JIRA.12731519.1517300290000@Atlassian.JIRA>
	<JIRA.12731519.1517300290000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731519.1517300290000.14727.1517391720729@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFCORE-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Marek Kopeck? updated WFCORE-3562:
----------------------------------
    Attachment: app01.war
                app02.war
                app03.war


> Deployment disable-all doesn't correct function at domain
> ---------------------------------------------------------
>
>                 Key: WFCORE-3562
>                 URL: https://issues.jboss.org/browse/WFCORE-3562
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>         Attachments: app01.war, app02.war, app03.war
>
>
> Domain 
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 04:53:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 31 Jan 2018 04:53:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3566) Different results of
 disabling commands already disabled deployment
In-Reply-To: <JIRA.12731615.1517316083000@Atlassian.JIRA>
References: <JIRA.12731615.1517316083000@Atlassian.JIRA>
	<JIRA.12731615.1517316083000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731615.1517316083000.14763.1517392380570@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3566?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526473#comment-13526473 ] 

Marek Kopeck? commented on WFCORE-3566:
---------------------------------------

Warning message should be similar in both cases and this warning message should be user-friendly.

Anyway, this is not regression against EAP 7.1.

*Experiments for EAP 7.1:*

Domain:
{noformat}
[domain at localhost:9990 /] deployment deploy-file --server-groups=main-server-group ~/erase15/app01.war
Unexpected command 'deployment deploy-file --server-groups=main-server-group ~/erase15/app01.war'. Type 'help --commands' for the list of supported commands.
[domain at localhost:9990 /] deploy ~/erase15/app01.war --server-groups=main-server-group
[domain at localhost:9990 /] undeploy app01.war --keep-content --server-groups=main-server-group
[domain at localhost:9990 /] undeploy app01.war --keep-content --server-groups=main-server-group
[domain at localhost:9990 /] 
{noformat}

Standalone:
{noformat}
[standalone at localhost:9990 /] deploy ~/erase15/app01.war 
[standalone at localhost:9990 /] undeploy app01.war --keep-content
[standalone at localhost:9990 /] undeploy app01.war --keep-content
Undeploy failed: WFLYCTL0155: 'steps' may not be null
[standalone at localhost:9990 /] 
{noformat}


> Different results of disabling commands already disabled deployment
> -------------------------------------------------------------------
>
>                 Key: WFCORE-3566
>                 URL: https://issues.jboss.org/browse/WFCORE-3566
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> *Different command result of disabling already disabled deployment in standalone and domain mode*
> * In standalone return 
> {noformat}
> WFLYCTL0155: 'steps' may not be null
> {noformat}
> * In domain return nothing, no warning or error
> {noformat}
> [standalone at localhost:9990 /] deployment info
> NAME                        RUNTIME-NAME                PERSISTENT ENABLED STATUS  
> cli-test-another-deploy.war cli-test-another-deploy.war true       true    OK      
> cli-test-app1-deploy.war    cli-test-app1-deploy.war    true       false   STOPPED 
> cli-test-app2-deploy.war    cli-test-app2-deploy.war    true       true    OK      
> [standalone at localhost:9990 /] deployment disable cli-test-app1-deploy-all.war
> WFLYCTL0155: 'steps' may not be null
> [standalone at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deployment info --server-groups=main-server-group
> NAME                            RUNTIME-NAME                    STATE     
> cli-test-another-deploy-all.war cli-test-another-deploy-all.war enabled   
> cli-test-app1-deploy-all.war    cli-test-app1-deploy-all.war    added     
> cli-test-app2-deploy-all.war    cli-test-app2-deploy-all.war    not added 
> cli-test-app3-deploy-all.war    cli-test-app3-deploy-all.war    enabled   
> [domain at localhost:9990 /] deployment disable --server-groups=main-server-group cli-test-app1-deploy-all.war
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 06:32:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 31 Jan 2018 06:32:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9746) Revert JGroups capability
 reference to ChannelFactory
In-Reply-To: <JIRA.12731831.1517398208000@Atlassian.JIRA>
References: <JIRA.12731831.1517398208000@Atlassian.JIRA>
	<JIRA.12731831.1517398208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731831.1517398208000.15794.1517398320725@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Ferraro moved JBEAP-14176 to WFLY-9746:
--------------------------------------------

              Project: WildFly  (was: JBoss Enterprise Application Platform)
                  Key: WFLY-9746  (was: JBEAP-14176)
             Workflow: GIT Pull Request workflow   (was: CDW with loose statuses v1)
          Component/s: Clustering
                       JMS
                           (was: Clustering)
                           (was: JMS)
    Affects Version/s: 12.0.0.Alpha1
                           (was: 7.2.0.GA)


> Revert JGroups capability reference to ChannelFactory
> -----------------------------------------------------
>
>                 Key: WFLY-9746
>                 URL: https://issues.jboss.org/browse/WFLY-9746
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, JMS
>    Affects Versions: 12.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Blocker
>
> There is regression If Artemis is configured to JGroups tcp stack to form cluster then server does not start and fail with:
> {code}
> 13:24:02,424 INFO  [org.jboss.ws.common.management] (MSC service thread 1-8) JBWS022052: Starting JBossWS 5.1.9.Final (Apache CXF 3.1.12) 
> 13:24:02,428 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "messaging-activemq"),
>     ("server" => "default")
> ]) - failure description: {
>     "WFLYCTL0412: Required services that are not installed:" => [
>         "jboss.messaging-activemq.default",
>         "org.wildfly.clustering.command-dispatcher-factory.tcp"
>     ],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => [
>         "jboss.messaging-activemq.default.jms.manager is missing [jboss.messaging-activemq.default]",
>         "jboss.messaging-activemq.default is missing [org.wildfly.clustering.command-dispatcher-factory.tcp]"
>     ]
> }
> 13:24:02,438 INFO  [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184:    New missing/unsatisfied dependencies:
>       service jboss.messaging-activemq.default (unavailable) dependents: [service jboss.messaging-activemq.default.jms.manager] 
>       service org.wildfly.clustering.command-dispatcher-factory.tcp (missing) dependents: [service jboss.messaging-activemq.default] 
> 13:24:02,485 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 13:24:02,487 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:11990/management
> 13:24:02,487 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:11990
> {code}
> Configuration of jgroups and messaging-activemq subsystem:
> {code}
>         <subsystem xmlns="urn:jboss:domain:jgroups:5.0">
>             <channels default="ee">
>                 <channel name="ee" stack="udp" cluster="ejb"/>
>             </channels>
>      ...
>                 <stack name="tcp">
>                     <transport type="TCP" socket-binding="jgroups-tcp"/>
>                     <protocol type="org.jgroups.protocols.TCPPING">
>                         <property name="port_range">
>                             10
>                         </property>
>                         <property name="num_initial_members">
>                             1
>                         </property>
>                         <property name="initial_hosts">
>                             127.0.0.1[9600]
>                         </property>
>                         <property name="timeout">
>                             3000
>                         </property>
>                     </protocol>
>                     <protocol type="MERGE3"/>
>                     <protocol type="FD_SOCK"/>
>                     <protocol type="FD"/>
>                     <protocol type="VERIFY_SUSPECT"/>
>                     <protocol type="pbcast.NAKACK"/>
>                     <protocol type="UNICAST3"/>
>                     <protocol type="pbcast.STABLE"/>
>                     <protocol type="pbcast.GMS"/>
>                     <protocol type="UFC"/>
>                     <protocol type="MFC"/>
>                     <protocol type="FRAG2"/>
>                     <protocol type="RSVP"/>
>                 </stack>
>             </stacks>
>         </subsystem>
> ....
>         <subsystem xmlns="urn:jboss:domain:messaging-activemq:3.0">
>             <server name="default" persistence-enabled="true" id-cache-size="200000">
>                 <broadcast-group name="bg-group1" jgroups-stack="tcp" jgroups-channel="udp" broadcast-period="2000" connectors="connector"/>
>                 <discovery-group name="dg-group1" jgroups-stack="tcp" jgroups-channel="udp" refresh-timeout="10000"/>
>                 <cluster-connection name="my-cluster" address="jms" connector-name="connector" check-period="30000" connection-ttl="60000" call-timeout="30000" discovery-group="dg-group1"/>
> ...
>             </server>
>         </subsystem>
> {code}
> Attaching the whole config: standalone-full-ha.xml



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 06:37:00 2018
From: issues at jboss.org (Paul Ferraro (JIRA))
Date: Wed, 31 Jan 2018 06:37:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9746) Revert JGroups capability
 reference to ChannelFactory
In-Reply-To: <JIRA.12731831.1517398208000@Atlassian.JIRA>
References: <JIRA.12731831.1517398208000@Atlassian.JIRA>
	<JIRA.12731831.1517398208000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731831.1517398208000.15827.1517398620543@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526540#comment-13526540 ] 

Paul Ferraro commented on WFLY-9746:
------------------------------------

WFLY-9271 changed the jgroups-stack capability reference to refer to a CommandDispatcherFactory capability.  This breaks configuration that specified a JGroups-stack based JChannelFactory.  To restore compatibility, we should revert this capability reference and in the event that a corresponding CommandDispatcherFactory capability does not exist, auto-create the missing JGroups channel resource required to create it.

> Revert JGroups capability reference to ChannelFactory
> -----------------------------------------------------
>
>                 Key: WFLY-9746
>                 URL: https://issues.jboss.org/browse/WFLY-9746
>             Project: WildFly
>          Issue Type: Bug
>          Components: Clustering, JMS
>    Affects Versions: 12.0.0.Alpha1
>            Reporter: Paul Ferraro
>            Assignee: Paul Ferraro
>            Priority: Blocker
>
> There is regression If Artemis is configured to JGroups tcp stack to form cluster then server does not start and fail with:
> {code}
> 13:24:02,424 INFO  [org.jboss.ws.common.management] (MSC service thread 1-8) JBWS022052: Starting JBossWS 5.1.9.Final (Apache CXF 3.1.12) 
> 13:24:02,428 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) WFLYCTL0013: Operation ("add") failed - address: ([
>     ("subsystem" => "messaging-activemq"),
>     ("server" => "default")
> ]) - failure description: {
>     "WFLYCTL0412: Required services that are not installed:" => [
>         "jboss.messaging-activemq.default",
>         "org.wildfly.clustering.command-dispatcher-factory.tcp"
>     ],
>     "WFLYCTL0180: Services with missing/unavailable dependencies" => [
>         "jboss.messaging-activemq.default.jms.manager is missing [jboss.messaging-activemq.default]",
>         "jboss.messaging-activemq.default is missing [org.wildfly.clustering.command-dispatcher-factory.tcp]"
>     ]
> }
> 13:24:02,438 INFO  [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report
> WFLYCTL0184:    New missing/unsatisfied dependencies:
>       service jboss.messaging-activemq.default (unavailable) dependents: [service jboss.messaging-activemq.default.jms.manager] 
>       service org.wildfly.clustering.command-dispatcher-factory.tcp (missing) dependents: [service jboss.messaging-activemq.default] 
> 13:24:02,485 INFO  [org.jboss.as.server] (Controller Boot Thread) WFLYSRV0212: Resuming server
> 13:24:02,487 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0060: Http management interface listening on http://127.0.0.1:11990/management
> 13:24:02,487 INFO  [org.jboss.as] (Controller Boot Thread) WFLYSRV0051: Admin console listening on http://127.0.0.1:11990
> {code}
> Configuration of jgroups and messaging-activemq subsystem:
> {code}
>         <subsystem xmlns="urn:jboss:domain:jgroups:5.0">
>             <channels default="ee">
>                 <channel name="ee" stack="udp" cluster="ejb"/>
>             </channels>
>      ...
>                 <stack name="tcp">
>                     <transport type="TCP" socket-binding="jgroups-tcp"/>
>                     <protocol type="org.jgroups.protocols.TCPPING">
>                         <property name="port_range">
>                             10
>                         </property>
>                         <property name="num_initial_members">
>                             1
>                         </property>
>                         <property name="initial_hosts">
>                             127.0.0.1[9600]
>                         </property>
>                         <property name="timeout">
>                             3000
>                         </property>
>                     </protocol>
>                     <protocol type="MERGE3"/>
>                     <protocol type="FD_SOCK"/>
>                     <protocol type="FD"/>
>                     <protocol type="VERIFY_SUSPECT"/>
>                     <protocol type="pbcast.NAKACK"/>
>                     <protocol type="UNICAST3"/>
>                     <protocol type="pbcast.STABLE"/>
>                     <protocol type="pbcast.GMS"/>
>                     <protocol type="UFC"/>
>                     <protocol type="MFC"/>
>                     <protocol type="FRAG2"/>
>                     <protocol type="RSVP"/>
>                 </stack>
>             </stacks>
>         </subsystem>
> ....
>         <subsystem xmlns="urn:jboss:domain:messaging-activemq:3.0">
>             <server name="default" persistence-enabled="true" id-cache-size="200000">
>                 <broadcast-group name="bg-group1" jgroups-stack="tcp" jgroups-channel="udp" broadcast-period="2000" connectors="connector"/>
>                 <discovery-group name="dg-group1" jgroups-stack="tcp" jgroups-channel="udp" refresh-timeout="10000"/>
>                 <cluster-connection name="my-cluster" address="jms" connector-name="connector" check-period="30000" connection-ttl="60000" call-timeout="30000" discovery-group="dg-group1"/>
> ...
>             </server>
>         </subsystem>
> {code}
> Attaching the whole config: standalone-full-ha.xml



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 06:49:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Wed, 31 Jan 2018 06:49:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3569) NPE is shown in server
	shutdown
In-Reply-To: <JIRA.12731773.1517379694000@Atlassian.JIRA>
References: <JIRA.12731773.1517379694000@Atlassian.JIRA>
	<JIRA.12731773.1517379694000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731773.1517379694000.15965.1517399340620@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526548#comment-13526548 ] 

Richard Opalka commented on WFCORE-3569:
----------------------------------------

The following commit introduced this issue:
https://github.com/xnio/xnio/commit/071800e0a85c9da9b88a976ac7ecb85760924dbf
Before there was DebugAbortPolicy rejection execution handler associated with task pool.
Since now on there's termination task created and associated with task pool.
I was able to reproduce this issue with the following stack traces describing the problem:
---
java.lang.Exception:
 	at org.jboss.as.server.mgmt.ManagementWorkerService.stopDone(ManagementWorkerService.java:69)
 	at org.xnio.nio.NioXnioWorker.closeResource(NioXnioWorker.java:264)
 	at org.xnio.nio.NioXnioWorker.taskPoolTerminated(NioXnioWorker.java:360)
 	at org.xnio.XnioWorker$1.run(XnioWorker.java:127)
 	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1983)
 	at org.jboss.threads.EnhancedQueueExecutor.completeTermination(EnhancedQueueExecutor.java:1759)
 	at org.jboss.threads.EnhancedQueueExecutor.tryDeallocateThread(EnhancedQueueExecutor.java:1580)
 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1393)
 	at java.lang.Thread.run(Thread.java:748)

java.lang.Exception:
 	at org.jboss.as.server.mgmt.ManagementWorkerService.stopDone(ManagementWorkerService.java:69)
 	at org.xnio.XnioWorker$1.run(XnioWorker.java:138)
 	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1983)
 	at org.jboss.threads.EnhancedQueueExecutor.completeTermination(EnhancedQueueExecutor.java:1759)
 	at org.jboss.threads.EnhancedQueueExecutor.tryDeallocateThread(EnhancedQueueExecutor.java:1580)
 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1393)
 	at java.lang.Thread.run(Thread.java:748)
---
>From the stack traces above you can see that ManagementWorkerService.stopDone() is called twice.
Further more it is called twice from the same thread while executing terminationTask.

These are the possibilities how to fix this issue:
 * either return back to DebugAbortPolicy rejection execution handler
 * or eliminate call on line 137 because it "somehow" duplicates what is happening on line 126 already
 * or make ManagementWorkerService.stopDone() idempotent
Since I don't know XNIO implementation details I can't say which of above proposals is the appropriate one (if any)

> NPE is shown in server shutdown
> -------------------------------
>
>                 Key: WFCORE-3569
>                 URL: https://issues.jboss.org/browse/WFCORE-3569
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management, IO, Server
>    Affects Versions: 4.0.0.Alpha8
>            Reporter: Chao Wang
>            Assignee: David Lloyd
>            Priority: Critical
>
> NullPointerException is shown in server shutdown with an open CLI connection in current WFLY master since WFCORE 4.0.0.Alpha7.
> Start the server and open a CLI connection, then stop server with Ctrl + C. We will see
> {noformat}
> 13:15:09,136 ERROR [org.jboss.threads.errors] (management task-1) Thread Thread[management task-1,5,main] threw an uncaught exception: java.lang.NullPointerException
> 	at org.jboss.as.server.mgmt.ManagementWorkerService.stopDone(ManagementWorkerService.java:72)
> 	at org.xnio.XnioWorker$1.run(XnioWorker.java:138)
> 	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> 	at org.jboss.threads.EnhancedQueueExecutor.completeTermination(EnhancedQueueExecutor.java:1755)
> 	at org.jboss.threads.EnhancedQueueExecutor.tryDeallocateThread(EnhancedQueueExecutor.java:1578)
> 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1393)
> 	at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I assign this to David as it seems this is caused by WFCORE-3397 and https://github.com/wildfly/wildfly-core/pull/3072 Please feel free to reassign to correct person. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 06:50:00 2018
From: issues at jboss.org (Richard Opalka (JIRA))
Date: Wed, 31 Jan 2018 06:50:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3569) NPE is shown in server
	shutdown
In-Reply-To: <JIRA.12731773.1517379694000@Atlassian.JIRA>
References: <JIRA.12731773.1517379694000@Atlassian.JIRA>
	<JIRA.12731773.1517379694000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731773.1517379694000.15971.1517399400314@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3569?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526548#comment-13526548 ] 

Richard Opalka edited comment on WFCORE-3569 at 1/31/18 6:49 AM:
-----------------------------------------------------------------

The following commit introduced this issue:
https://github.com/xnio/xnio/commit/071800e0a85c9da9b88a976ac7ecb85760924dbf
Before there was DebugAbortPolicy rejection execution handler associated with task pool.
Since now on there's termination task created and associated with task pool.
I was able to reproduce this issue with the following stack traces describing the problem:
---
java.lang.Exception:
 	at org.jboss.as.server.mgmt.ManagementWorkerService.stopDone(ManagementWorkerService.java:69)
 	at org.xnio.nio.NioXnioWorker.closeResource(NioXnioWorker.java:264)
 	at org.xnio.nio.NioXnioWorker.taskPoolTerminated(NioXnioWorker.java:360)
 	at org.xnio.XnioWorker$1.run(XnioWorker.java:127)
 	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1983)
 	at org.jboss.threads.EnhancedQueueExecutor.completeTermination(EnhancedQueueExecutor.java:1759)
 	at org.jboss.threads.EnhancedQueueExecutor.tryDeallocateThread(EnhancedQueueExecutor.java:1580)
 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1393)
 	at java.lang.Thread.run(Thread.java:748)

java.lang.Exception:
 	at org.jboss.as.server.mgmt.ManagementWorkerService.stopDone(ManagementWorkerService.java:69)
 	at org.xnio.XnioWorker$1.run(XnioWorker.java:138)
 	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1983)
 	at org.jboss.threads.EnhancedQueueExecutor.completeTermination(EnhancedQueueExecutor.java:1759)
 	at org.jboss.threads.EnhancedQueueExecutor.tryDeallocateThread(EnhancedQueueExecutor.java:1580)
 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1393)
 	at java.lang.Thread.run(Thread.java:748)
---
>From the stack traces above you can see that ManagementWorkerService.stopDone() is called twice.
Further more it is called twice from the same thread while executing terminationTask.

These are the possibilities how to fix this issue:
 * either return back to DebugAbortPolicy rejection execution handler
 * or eliminate call on line 137 because it "somehow" duplicates what is happening on line 126 already
 * or make ManagementWorkerService.stopDone() idempotent

Since I don't know XNIO implementation details I can't say which of above proposals is the appropriate one (if any)


was (Author: ropalka):
The following commit introduced this issue:
https://github.com/xnio/xnio/commit/071800e0a85c9da9b88a976ac7ecb85760924dbf
Before there was DebugAbortPolicy rejection execution handler associated with task pool.
Since now on there's termination task created and associated with task pool.
I was able to reproduce this issue with the following stack traces describing the problem:
---
java.lang.Exception:
 	at org.jboss.as.server.mgmt.ManagementWorkerService.stopDone(ManagementWorkerService.java:69)
 	at org.xnio.nio.NioXnioWorker.closeResource(NioXnioWorker.java:264)
 	at org.xnio.nio.NioXnioWorker.taskPoolTerminated(NioXnioWorker.java:360)
 	at org.xnio.XnioWorker$1.run(XnioWorker.java:127)
 	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1983)
 	at org.jboss.threads.EnhancedQueueExecutor.completeTermination(EnhancedQueueExecutor.java:1759)
 	at org.jboss.threads.EnhancedQueueExecutor.tryDeallocateThread(EnhancedQueueExecutor.java:1580)
 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1393)
 	at java.lang.Thread.run(Thread.java:748)

java.lang.Exception:
 	at org.jboss.as.server.mgmt.ManagementWorkerService.stopDone(ManagementWorkerService.java:69)
 	at org.xnio.XnioWorker$1.run(XnioWorker.java:138)
 	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1983)
 	at org.jboss.threads.EnhancedQueueExecutor.completeTermination(EnhancedQueueExecutor.java:1759)
 	at org.jboss.threads.EnhancedQueueExecutor.tryDeallocateThread(EnhancedQueueExecutor.java:1580)
 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1393)
 	at java.lang.Thread.run(Thread.java:748)
---
>From the stack traces above you can see that ManagementWorkerService.stopDone() is called twice.
Further more it is called twice from the same thread while executing terminationTask.

These are the possibilities how to fix this issue:
 * either return back to DebugAbortPolicy rejection execution handler
 * or eliminate call on line 137 because it "somehow" duplicates what is happening on line 126 already
 * or make ManagementWorkerService.stopDone() idempotent
Since I don't know XNIO implementation details I can't say which of above proposals is the appropriate one (if any)

> NPE is shown in server shutdown
> -------------------------------
>
>                 Key: WFCORE-3569
>                 URL: https://issues.jboss.org/browse/WFCORE-3569
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI, Domain Management, IO, Server
>    Affects Versions: 4.0.0.Alpha8
>            Reporter: Chao Wang
>            Assignee: David Lloyd
>            Priority: Critical
>
> NullPointerException is shown in server shutdown with an open CLI connection in current WFLY master since WFCORE 4.0.0.Alpha7.
> Start the server and open a CLI connection, then stop server with Ctrl + C. We will see
> {noformat}
> 13:15:09,136 ERROR [org.jboss.threads.errors] (management task-1) Thread Thread[management task-1,5,main] threw an uncaught exception: java.lang.NullPointerException
> 	at org.jboss.as.server.mgmt.ManagementWorkerService.stopDone(ManagementWorkerService.java:72)
> 	at org.xnio.XnioWorker$1.run(XnioWorker.java:138)
> 	at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1979)
> 	at org.jboss.threads.EnhancedQueueExecutor.completeTermination(EnhancedQueueExecutor.java:1755)
> 	at org.jboss.threads.EnhancedQueueExecutor.tryDeallocateThread(EnhancedQueueExecutor.java:1578)
> 	at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1393)
> 	at java.lang.Thread.run(Thread.java:748)
> {noformat}
> I assign this to David as it seems this is caused by WFCORE-3397 and https://github.com/wildfly/wildfly-core/pull/3072 Please feel free to reassign to correct person. 



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 06:56:00 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 31 Jan 2018 06:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3563) Could not enable
 application deployment on two server groups in domain
In-Reply-To: <JIRA.12731530.1517306316000@Atlassian.JIRA>
References: <JIRA.12731530.1517306316000@Atlassian.JIRA>
	<JIRA.12731530.1517306316000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731530.1517306316000.16023.1517399760251@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3563?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526555#comment-13526555 ] 

Marek Kopeck? commented on WFCORE-3563:
---------------------------------------

[~jdenise]: I confirm [~vmarek] previous comment, this issue is valid also for EAP 7.1

> Could not enable application deployment on two server groups in domain
> ----------------------------------------------------------------------
>
>                 Key: WFCORE-3563
>                 URL: https://issues.jboss.org/browse/WFCORE-3563
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>
> {noformat}
> [domain at localhost:9990 /] deployment enable --server-groups=other-server-group,main-server-group cli-test-app-deploy-all.ear
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [
>     (\"server-group\" => \"other-server-group\"),
>     (\"deployment\" => \"cli-test-app-deploy-all.ear\")
> ]"}}
> [domain at localhost:9990 /] 
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deploy --name=cli-test-app-deploy-all.ear --server-groups=other-server-group,main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-1" => "WFLYCTL0212: Duplicate resource [
>     (\"server-group\" => \"other-server-group\"),
>     (\"deployment\" => \"cli-test-app-deploy-all.ear\")
> ]"}}
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 08:06:00 2018
From: issues at jboss.org (RH Bugzilla Integration (JIRA))
Date: Wed, 31 Jan 2018 08:06:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-232) Deployment fails when
 Dependencies is empty in a jars manifest
In-Reply-To: <JIRA.12474406.1347532970000@Atlassian.JIRA>
References: <JIRA.12474406.1347532970000@Atlassian.JIRA>
	<JIRA.12474406.1347532970000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12474406.1347532970000.16617.1517403960408@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526603#comment-13526603 ] 

RH Bugzilla Integration commented on WFLY-232:
----------------------------------------------

Anup Kumar Dey <andey at redhat.com> changed the Status of [bug 1539985|https://bugzilla.redhat.com/show_bug.cgi?id=1539985] from NEW to ASSIGNED

> Deployment fails when Dependencies is empty in a jars manifest
> --------------------------------------------------------------
>
>                 Key: WFLY-232
>                 URL: https://issues.jboss.org/browse/WFLY-232
>             Project: WildFly
>          Issue Type: Enhancement
>            Reporter: G?bor Farkas
>            Assignee: Stuart Douglas
>             Fix For: 8.0.0.Alpha1
>
>         Attachments: empty-manifest.ear
>
>
> I have a WAR, which produces the following error on deployment:
> Caused by: java.lang.IllegalArgumentException: Empty module specification
> 	at org.jboss.modules.ModuleIdentifier.fromString(ModuleIdentifier.java:169) [jboss-modules.jar:1.1.1.GA]
> 	at org.jboss.as.server.deployment.module.ManifestDependencyProcessor.deploy(ManifestDependencyProcessor.java:83) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> 	at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:113) [jboss-as-server-7.1.1.Final.jar:7.1.1.Final]
> 	... 5 more
> I found that my WAR contains a jar in WEB-INF/lib that has empty dependencies defined in its manifest. More exactly it's "Dependencies: ", so the colon is followed by a space character before the new line characters. The ManifestDependencyProcessor parses this as one dependency, the name of which is the empty string.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 08:25:01 2018
From: issues at jboss.org (Toni Rikkola (JIRA))
Date: Wed, 31 Jan 2018 08:25:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2263) Unexpected results in GDST
 when using enumerations with commas
In-Reply-To: <JIRA.12730351.1516712572000@Atlassian.JIRA>
References: <JIRA.12730351.1516712572000@Atlassian.JIRA>
	<JIRA.12730351.1516712572000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730351.1516712572000.16764.1517405101210@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Toni Rikkola updated DROOLS-2263:
---------------------------------
    Summary: Unexpected results in GDST when using enumerations with commas  (was: [GSS] (6.4.z) Unexpected results in GDST when using enumerations with commas)


> Unexpected results in GDST when using enumerations with commas
> --------------------------------------------------------------
>
>                 Key: DROOLS-2263
>                 URL: https://issues.jboss.org/browse/DROOLS-2263
>             Project: Drools
>          Issue Type: Bug
>          Components: Guided Decision Table Editor
>            Reporter: Toni Rikkola
>            Assignee: Toni Rikkola
>
> When using enumerations where the values itself contain a comma, the rules generated by a GDST are unexpected, as the "contains in" operator splits those values in the enumerations. Example enumeration:
> {noformat}
>    fact: person
>    field: city
>    context: ['paris','london','new york,boston']
> {noformat}
> Note: see the 'new york, boston' sample.
> The code generated will be:
> {noformat}
> rule "Row 1 personGDT"
>     dialect "mvel"
>     when
>         p : person( city in ( "new york", "boston" ) )
>     then
> end
> {noformat}
> Basically "paris" and "new york,boston" will be treated by the DSL parser as 3 strings in the DRL generation and will produce someting simiular to
>    p : person( city in ( "paris", "new york", "boston" ) )
> But what the customer expects is the following
>    p : person( city in ( "paris", "new york,boston" ) )



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 08:47:01 2018
From: issues at jboss.org (=?UTF-8?Q?Marek_Kopeck=C3=BD_=28JIRA=29?=)
Date: Wed, 31 Jan 2018 08:47:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFCORE-3562) Deployment disable-all
 doesn't correct function at domain
In-Reply-To: <JIRA.12731519.1517300290000@Atlassian.JIRA>
References: <JIRA.12731519.1517300290000@Atlassian.JIRA>
	<JIRA.12731519.1517300290000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731519.1517300290000.17090.1517406421021@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFCORE-3562?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526467#comment-13526467 ] 

Marek Kopeck? edited comment on WFCORE-3562 at 1/31/18 8:46 AM:
----------------------------------------------------------------

I'm able to reproduce this issue with three deployments too. I attached deployments that I used.

This is not a regression against EAP 7.1, because legacy deploy commands doesn't work correctly on EAP 7.1 too.

*These are my experiments:*
*New way:*
{noformat}
deployment deploy-file --server-groups=main-server-group ~/erase15/app01.war
deployment deploy-file --server-groups=main-server-group ~/erase15/app02.war
deployment deploy-file --server-groups=other-server-group,main-server-group ~/erase15/app03.war
deployment disable --server-groups=main-server-group app01.war
deployment info --server-group=main-server-group
deployment disable-all --all-relevant-server-groups
deployment info --server-group=main-server-group
{noformat}

WF master results (error occurs):
{noformat}
[domain at localhost:9990 /] deployment deploy-file --server-groups=main-server-group ~/erase15/app01.war
[domain at localhost:9990 /] deployment deploy-file --server-groups=main-server-group ~/erase15/app02.war
[domain at localhost:9990 /] deployment deploy-file --server-groups=other-server-group,main-server-group ~/erase15/app03.war
[domain at localhost:9990 /] deployment disable --server-groups=main-server-group app01.war
[domain at localhost:9990 /] deployment info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups
org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
[domain at localhost:9990 /] deployment info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] 
{noformat}

*Legacy way:*
{noformat}
deploy ~/erase15/app01.war --server-groups=main-server-group
deploy ~/erase15/app02.war --server-groups=main-server-group
deploy ~/erase15/app03.war --server-groups=other-server-group,main-server-group
undeploy app01.war --keep-content --server-groups=main-server-group
deployment-info --server-group=main-server-group
undeploy * --keep-content --server-groups=main-server-group,other-server-group
deployment-info --server-group=main-server-group
{noformat}


EAP 7.1 results (error occurs):
{noformat}
[domain at localhost:9990 /] deploy ~/erase15/app01.war --server-groups=main-server-group
[domain at localhost:9990 /] deploy ~/erase15/app02.war --server-groups=main-server-group
[domain at localhost:9990 /] deploy ~/erase15/app03.war --server-groups=other-server-group,main-server-group
[domain at localhost:9990 /] undeploy app01.war --keep-content --server-groups=main-server-group
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group,other-server-group
{"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => "WFLYCTL0216: Management resource '[
    (\"server-group\" => \"other-server-group\"),
    (\"deployment\" => \"app01.war\")
]' not found"}}
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] 
{noformat}


WF master results (error occurs):
{noformat}
[domain at localhost:9990 /] deploy ~/erase15/app01.war --server-groups=main-server-group
[domain at localhost:9990 /] deploy ~/erase15/app02.war --server-groups=main-server-group
[domain at localhost:9990 /] deploy ~/erase15/app03.war --server-groups=other-server-group,main-server-group
[domain at localhost:9990 /] undeploy app01.war --keep-content --server-groups=main-server-group
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group,other-server-group
Undeploy failed: {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-2" => "WFLYCTL0216: Management resource '[
    (\"server-group\" => \"other-server-group\"),
    (\"deployment\" => \"app01.war\")
]' not found"}}
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] 
{noformat}


was (Author: mkopecky):
I'm able to reproduce this issue with three deployments too. I attached deployments that I used.

This is not a regression against EAP 7.1, because legacy deploy commands works correctly, but new deployment command doesn't work in this scenario.

*These are my experiments:*
*New way:*
{noformat}
deployment deploy-file --server-groups=main-server-group ~/erase15/app01.war
deployment deploy-file --server-groups=main-server-group ~/erase15/app02.war
deployment deploy-file --server-groups=other-server-group,main-server-group ~/erase15/app03.war
deployment disable --server-groups=main-server-group app01.war
deployment info --server-group=main-server-group
deployment disable-all --all-relevant-server-groups
deployment info --server-group=main-server-group
{noformat}

WF master results (error occurs):
{noformat}
[domain at localhost:9990 /] deployment deploy-file --server-groups=main-server-group ~/erase15/app01.war
[domain at localhost:9990 /] deployment deploy-file --server-groups=main-server-group ~/erase15/app02.war
[domain at localhost:9990 /] deployment deploy-file --server-groups=other-server-group,main-server-group ~/erase15/app03.war
[domain at localhost:9990 /] deployment disable --server-groups=main-server-group app01.war
[domain at localhost:9990 /] deployment info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups
org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
[domain at localhost:9990 /] deployment info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] 
{noformat}

*Legacy way:*
{noformat}
deploy ~/erase15/app01.war --server-groups=main-server-group
deploy ~/erase15/app02.war --server-groups=main-server-group
deploy ~/erase15/app03.war --server-groups=other-server-group,main-server-group
undeploy app01.war --keep-content --server-groups=main-server-group
deployment-info --server-group=main-server-group
undeploy * --keep-content --server-groups=main-server-group
deployment-info --server-group=main-server-group
{noformat}


EAP 7.1 results (error doesn't occurs):
{noformat}
[mkopecky at dhcp-10-40-5-4 bin]$ ./jboss-cli.sh -c
[domain at localhost:9990 /] deploy ~/erase15/app01.war --server-groups=main-server-group
[domain at localhost:9990 /] deploy ~/erase15/app02.war --server-groups=main-server-group
[domain at localhost:9990 /] deploy ~/erase15/app03.war --server-groups=other-server-group,main-server-group
[domain at localhost:9990 /] undeploy app01.war --keep-content --server-groups=main-server-group
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME      RUNTIME-NAME STATE 
app01.war app01.war    added 
app02.war app02.war    added 
app03.war app03.war    added 
[domain at localhost:9990 /] 
{noformat}


WF master results (error doesn't occurs):
{noformat}
[domain at localhost:9990 /] deploy ~/erase15/app01.war --server-groups=main-server-group
[domain at localhost:9990 /] deploy ~/erase15/app02.war --server-groups=main-server-group
[domain at localhost:9990 /] deploy ~/erase15/app03.war --server-groups=other-server-group,main-server-group
[domain at localhost:9990 /] undeploy app01.war --keep-content --server-groups=main-server-group
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME      RUNTIME-NAME STATE   
app01.war app01.war    added   
app02.war app02.war    enabled 
app03.war app03.war    enabled 
[domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group
[domain at localhost:9990 /] deployment-info --server-group=main-server-group
NAME      RUNTIME-NAME STATE 
app01.war app01.war    added 
app02.war app02.war    added 
app03.war app03.war    added 
[domain at localhost:9990 /] 
{noformat}

> Deployment disable-all doesn't correct function at domain
> ---------------------------------------------------------
>
>                 Key: WFCORE-3562
>                 URL: https://issues.jboss.org/browse/WFCORE-3562
>             Project: WildFly Core
>          Issue Type: Bug
>          Components: CLI
>            Reporter: Vratislav Marek
>            Assignee: Jean-Francois Denise
>         Attachments: app01.war, app02.war, app03.war
>
>
> Domain 
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --all-relevant-server-groups
> org.jboss.as.cli.operation.OperationFormatException: None of the server groups is specified or references specified deployment.
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] deployment disable-all --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}
> {noformat}
> [domain at localhost:9990 /] undeploy * --keep-content --server-groups=main-server-group
> {"WFLYCTL0062: Composite operation failed and was rolled back. Steps that failed:" => {"Operation step-4" => "WFLYCTL0216: Management resource '[
>     (\"server-group\" => \"main-server-group\"),
>     (\"deployment\" => \"cli-test-app2-deploy-all.war\")
> ]' not found"}}
> [domain at localhost:9990 /]
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 09:47:01 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 31 Jan 2018 09:47:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2284) Implement an executable
 model for drools and a java dsl to instance it
In-Reply-To: <JIRA.12731911.1517410019000@Atlassian.JIRA>
References: <JIRA.12731911.1517410019000@Atlassian.JIRA>
	<JIRA.12731911.1517410019066@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731911.1517410019000.17689.1517410021017@Atlassian.JIRA>

Mario Fusco created DROOLS-2284:
-----------------------------------

             Summary: Implement an executable model for drools and a java dsl to instance it
                 Key: DROOLS-2284
                 URL: https://issues.jboss.org/browse/DROOLS-2284
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Mario Fusco
            Assignee: Mario Fusco






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 09:48:00 2018
From: issues at jboss.org (Mario Fusco (JIRA))
Date: Wed, 31 Jan 2018 09:48:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2285) Implement an executable
 model for drools and a java dsl to instance it
In-Reply-To: <JIRA.12731912.1517410058000@Atlassian.JIRA>
References: <JIRA.12731912.1517410058000@Atlassian.JIRA>
	<JIRA.12731912.1517410058561@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731912.1517410058000.17694.1517410080364@Atlassian.JIRA>

Mario Fusco created DROOLS-2285:
-----------------------------------

             Summary: Implement an executable model for drools and a java dsl to instance it
                 Key: DROOLS-2285
                 URL: https://issues.jboss.org/browse/DROOLS-2285
             Project: Drools
          Issue Type: Bug
          Components: core engine
            Reporter: Mario Fusco
            Assignee: Mario Fusco






--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 09:54:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 31 Jan 2018 09:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old
 members doesn't seem to get removed
In-Reply-To: <JIRA.12718955.1509544557000@Atlassian.JIRA>
References: <JIRA.12718955.1509544557000@Atlassian.JIRA>
	<JIRA.12718955.1509544557000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718955.1509544557000.17732.1517410440263@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526705#comment-13526705 ] 

Bela Ban commented on JGRP-2232:
--------------------------------

OK, this issue has been fixed and tested with {{FILE_PING}}. Todo: test with {{NATIVE_S3_PING}}. This can be done one {{4.0.10.Final}} has been released.

> Using NATIVE_S3_PING old members doesn't seem to get removed
> ------------------------------------------------------------
>
>                 Key: JGRP-2232
>                 URL: https://issues.jboss.org/browse/JGRP-2232
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.7
>         Environment: Spring Boot / Boxfuse / AWS
>            Reporter: Jesper Blomquist
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0.10
>
>
> According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
> Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).
> Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
> 967 elements:
> {noformat}
> i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
> i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
> i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
> i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
> i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
> i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
> i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
> i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
> i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
> i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
> i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
> i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 09:54:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 31 Jan 2018 09:54:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2232) Using NATIVE_S3_PING old
 members doesn't seem to get removed
In-Reply-To: <JIRA.12718955.1509544557000@Atlassian.JIRA>
References: <JIRA.12718955.1509544557000@Atlassian.JIRA>
	<JIRA.12718955.1509544557000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12718955.1509544557000.17736.1517410440366@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2232?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2232.
----------------------------
    Resolution: Done


> Using NATIVE_S3_PING old members doesn't seem to get removed
> ------------------------------------------------------------
>
>                 Key: JGRP-2232
>                 URL: https://issues.jboss.org/browse/JGRP-2232
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.7
>         Environment: Spring Boot / Boxfuse / AWS
>            Reporter: Jesper Blomquist
>            Assignee: Bela Ban
>            Priority: Minor
>             Fix For: 4.0.10
>
>
> According to: http://www.jgroups.org/manual4/index.html#FILE_PING old members should be removed if there is a reaper task is running (which seem to be the default), but this does not happen for us.
> Both the s3 file, and the "logical address cache" keeps growing. We have a cluster of about 10 members (they comes and goes due to auto scaling). Nothing is ever marked as "removable" and nothing is ever older than 60 sec (same as the reaper interval?!).
> Below is a (truncated) dump from JMX of the logical address cache (everything always has the same age):
> 967 elements:
> {noformat}
> i-0704cf3786731075b-10202: 25c4cd46-6e4d-d198-88f5-bfa65b4bfb4e: 10.0.82.106:7800 (20 secs old)
> i-08fb0ad436efed1b2-18812: f4fef542-42ab-2c7b-a1f1-10ad90112e27: 10.0.118.75:7800 (20 secs old)
> i-0b9f077af97ef256f-11379: 47aea44c-9f2d-4200-d606-2f4c2844efc8: 10.0.85.52:7800 (20 secs old)
> i-06e220104b9e0069a-55132: b86864f0-8961-4565-c935-dc03137a16da: 10.0.67.5:7800 (20 secs old)
> i-0d3bbedeca8c7eb7d-33369: 9b37f425-7da5-d3ee-cfd5-5d1b4d2266b9: 10.0.116.207:7800 (20 secs old)
> i-074806dc606197fc9-46262: 99a2f550-5628-5d2c-1167-38268f804139: 10.0.109.149:7800 (20 secs old)
> i-0bbd38020b6184cb1-22367: e46e3ed5-0c75-1230-94aa-deb1cd1a9bf1: 10.0.124.183:7800 (20 secs old)
> i-0ff325c578faf6ad9-2376: c4c48178-cdbf-530a-155f-bba1f01a65e2: 10.0.100.143:7800 (20 secs old)
> i-03d819b23eb1357ba-64126: b89f5117-8ebf-df14-ece1-adba632c0245: 10.0.67.163:7800 (20 secs old)
> i-09e9907ee27aef2a0-37490: 8ee85310-39c7-0617-0fc8-3d4f002a1894: 10.0.108.234:7800 (20 secs old)
> i-0da90751a5093a880-28069: ecd33ad7-f261-5b71-8deb-b9fe5b4ed05d: 10.0.77.132:7800 (20 secs old)
> i-03213f181d96c70d3-57318: d962cfd0-8c5e-4129-334f-ffa10309ec30: 10.0.112.182:7800 (20 secs old)
> ...
> {noformat}



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 09:56:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 31 Jan 2018 09:56:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not
 clearing the crashed members
In-Reply-To: <JIRA.12729827.1516314140000@Atlassian.JIRA>
References: <JIRA.12729827.1516314140000@Atlassian.JIRA>
	<JIRA.12729827.1516314140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729827.1516314140000.17748.1517410560347@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2245:
---------------------------
    Description: 
1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.

I think the issue is 


handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.

{code:java}
 // remove all files which are not from the current members
    protected void handleView(View new_view, View old_view, boolean coord_changed) {
        if(is_coord) {
            if(coord_changed) {
                if(remove_all_data_on_view_change)
                    removeAll(cluster_name);
                else if(remove_old_coords_on_view_change) {
                    Address old_coord=old_view != null? old_view.getCreator() : null;
                    if(old_coord != null)
                        remove(cluster_name, old_coord);
                }
            }
            if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
                writeAll();
                if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
                    startInfoWriter();
            }
        }
        else if(coord_changed) // I'm no longer the coordinator
            remove(cluster_name, local_addr);
    }
{code}

4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts

sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.


  was:
1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.

I think the issue is 


handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.

 // remove all files which are not from the current members
    protected void handleView(View new_view, View old_view, boolean coord_changed) {
        if(is_coord) {
            if(coord_changed) {
                if(remove_all_data_on_view_change)
                    removeAll(cluster_name);
                else if(remove_old_coords_on_view_change) {
                    Address old_coord=old_view != null? old_view.getCreator() : null;
                    if(old_coord != null)
                        remove(cluster_name, old_coord);
                }
            }
            if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
                writeAll();
                if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
                    startInfoWriter();
            }
        }
        else if(coord_changed) // I'm no longer the coordinator
            remove(cluster_name, local_addr);
    }

4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts

sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.




> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
>                 Key: JGRP-2245
>                 URL: https://issues.jboss.org/browse/JGRP-2245
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.8
>            Reporter: Sibin Karnavar
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 4.0.10
>
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is 
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
> {code:java}
>  // remove all files which are not from the current members
>     protected void handleView(View new_view, View old_view, boolean coord_changed) {
>         if(is_coord) {
>             if(coord_changed) {
>                 if(remove_all_data_on_view_change)
>                     removeAll(cluster_name);
>                 else if(remove_old_coords_on_view_change) {
>                     Address old_coord=old_view != null? old_view.getCreator() : null;
>                     if(old_coord != null)
>                         remove(cluster_name, old_coord);
>                 }
>             }
>             if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
>                 writeAll();
>                 if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
>                     startInfoWriter();
>             }
>         }
>         else if(coord_changed) // I'm no longer the coordinator
>             remove(cluster_name, local_addr);
>     }
> {code}
> 4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 10:22:00 2018
From: issues at jboss.org (Thomas Mantegazzi (JIRA))
Date: Wed, 31 Jan 2018 10:22:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2286) [DMN engine] Java Object in
 DMNContext not working properly with Filter function.
In-Reply-To: <JIRA.12731931.1517412100000@Atlassian.JIRA>
References: <JIRA.12731931.1517412100000@Atlassian.JIRA>
	<JIRA.12731931.1517412100858@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731931.1517412100000.17980.1517412120972@Atlassian.JIRA>

Thomas Mantegazzi created DROOLS-2286:
-----------------------------------------

             Summary: [DMN engine] Java Object in DMNContext not working properly with Filter function.
                 Key: DROOLS-2286
                 URL: https://issues.jboss.org/browse/DROOLS-2286
             Project: Drools
          Issue Type: Bug
          Components: dmn engine
    Affects Versions: 7.5.0.Final, 7.4.1.Final
            Reporter: Thomas Mantegazzi
            Assignee: Edson Tirelli
         Attachments: FilterJohns.dmn, FilterOnObjectListBug.java

When trying to evaluate a FEEL expression like: 

{code:java}
personList[name = "John"]
{code}

by inserting into the _DMNContext_ a _Java Object_, the _DMN engine_ doesn't seem to be able to fetch the  _name_ field from the object. This doesn't happen if instead of _Java Objects_ we insert a Map.

While trying to debug, it seems that the problem is happening in the following method of  _FilterExpressionNode_.
{code:java}
private void evaluateExpressionInContext(EvaluationContext ctx, List results, Object v) {
        try {
            ctx.enterFrame();
            // handle it as a predicate
            ctx.setValue( "item", v );
            // if it is a Map, need to add all string keys as variables in the context
            if( v instanceof Map ) {
                Set<Map.Entry> set = ((Map) v).entrySet();
                for( Map.Entry ce : set ) {
                    if( ce.getKey() instanceof String ) {
                        ctx.setValue( (String) ce.getKey(), ce.getValue() );
                    }
                }
            }

            Object r = this.filter.evaluate( ctx );
            if( r instanceof Boolean && ((Boolean)r) == Boolean.TRUE ) {
                results.add( v );
            }
        } finally {
            ctx.exitFrame();
        }
    }
{code}

Also attatched java and DMN test files that showcases the issue.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 10:28:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 31 Jan 2018 10:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not
 clearing the crashed members
In-Reply-To: <JIRA.12729827.1516314140000@Atlassian.JIRA>
References: <JIRA.12729827.1516314140000@Atlassian.JIRA>
	<JIRA.12729827.1516314140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729827.1516314140000.18051.1517412480674@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban resolved JGRP-2245.
----------------------------
    Resolution: Duplicate Issue


Fixed by JGRP-2232

> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
>                 Key: JGRP-2245
>                 URL: https://issues.jboss.org/browse/JGRP-2245
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.8
>            Reporter: Sibin Karnavar
>            Assignee: Bela Ban
>            Priority: Critical
>             Fix For: 4.0.10
>
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is 
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
> {code:java}
>  // remove all files which are not from the current members
>     protected void handleView(View new_view, View old_view, boolean coord_changed) {
>         if(is_coord) {
>             if(coord_changed) {
>                 if(remove_all_data_on_view_change)
>                     removeAll(cluster_name);
>                 else if(remove_old_coords_on_view_change) {
>                     Address old_coord=old_view != null? old_view.getCreator() : null;
>                     if(old_coord != null)
>                         remove(cluster_name, old_coord);
>                 }
>             }
>             if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
>                 writeAll();
>                 if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
>                     startInfoWriter();
>             }
>         }
>         else if(coord_changed) // I'm no longer the coordinator
>             remove(cluster_name, local_addr);
>     }
> {code}
> 4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 10:28:00 2018
From: issues at jboss.org (Edson Tirelli (JIRA))
Date: Wed, 31 Jan 2018 10:28:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (DROOLS-2286) [DMN engine] Java Object in
 DMNContext not working properly with Filter function.
In-Reply-To: <JIRA.12731931.1517412101000@Atlassian.JIRA>
References: <JIRA.12731931.1517412101000@Atlassian.JIRA>
	<JIRA.12731931.1517412101000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731931.1517412101000.18055.1517412480819@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/DROOLS-2286?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Edson Tirelli reassigned DROOLS-2286:
-------------------------------------

    Assignee: Matteo Mortari  (was: Edson Tirelli)


> [DMN engine] Java Object in DMNContext not working properly with Filter function.
> ---------------------------------------------------------------------------------
>
>                 Key: DROOLS-2286
>                 URL: https://issues.jboss.org/browse/DROOLS-2286
>             Project: Drools
>          Issue Type: Bug
>          Components: dmn engine
>    Affects Versions: 7.4.1.Final, 7.5.0.Final
>            Reporter: Thomas Mantegazzi
>            Assignee: Matteo Mortari
>         Attachments: FilterJohns.dmn, FilterOnObjectListBug.java
>
>
> When trying to evaluate a FEEL expression like: 
> {code:java}
> personList[name = "John"]
> {code}
> by inserting into the _DMNContext_ a _Java Object_, the _DMN engine_ doesn't seem to be able to fetch the  _name_ field from the object. This doesn't happen if instead of _Java Objects_ we insert a Map.
> While trying to debug, it seems that the problem is happening in the following method of  _FilterExpressionNode_.
> {code:java}
> private void evaluateExpressionInContext(EvaluationContext ctx, List results, Object v) {
>         try {
>             ctx.enterFrame();
>             // handle it as a predicate
>             ctx.setValue( "item", v );
>             // if it is a Map, need to add all string keys as variables in the context
>             if( v instanceof Map ) {
>                 Set<Map.Entry> set = ((Map) v).entrySet();
>                 for( Map.Entry ce : set ) {
>                     if( ce.getKey() instanceof String ) {
>                         ctx.setValue( (String) ce.getKey(), ce.getValue() );
>                     }
>                 }
>             }
>             Object r = this.filter.evaluate( ctx );
>             if( r instanceof Boolean && ((Boolean)r) == Boolean.TRUE ) {
>                 results.add( v );
>             }
>         } finally {
>             ctx.exitFrame();
>         }
>     }
> {code}
> Also attatched java and DMN test files that showcases the issue.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 10:28:01 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 31 Jan 2018 10:28:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not
 clearing the crashed members
In-Reply-To: <JIRA.12729827.1516314140000@Atlassian.JIRA>
References: <JIRA.12729827.1516314140000@Atlassian.JIRA>
	<JIRA.12729827.1516314140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729827.1516314140000.18065.1517412481161@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2245:
---------------------------
    Priority: Major  (was: Critical)


> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
>                 Key: JGRP-2245
>                 URL: https://issues.jboss.org/browse/JGRP-2245
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.8
>            Reporter: Sibin Karnavar
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is 
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
> {code:java}
>  // remove all files which are not from the current members
>     protected void handleView(View new_view, View old_view, boolean coord_changed) {
>         if(is_coord) {
>             if(coord_changed) {
>                 if(remove_all_data_on_view_change)
>                     removeAll(cluster_name);
>                 else if(remove_old_coords_on_view_change) {
>                     Address old_coord=old_view != null? old_view.getCreator() : null;
>                     if(old_coord != null)
>                         remove(cluster_name, old_coord);
>                 }
>             }
>             if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
>                 writeAll();
>                 if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
>                     startInfoWriter();
>             }
>         }
>         else if(coord_changed) // I'm no longer the coordinator
>             remove(cluster_name, local_addr);
>     }
> {code}
> 4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 10:30:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 31 Jan 2018 10:30:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not
 clearing the crashed members
In-Reply-To: <JIRA.12729827.1516314140000@Atlassian.JIRA>
References: <JIRA.12729827.1516314140000@Atlassian.JIRA>
	<JIRA.12729827.1516314140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729827.1516314140000.18074.1517412600433@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526732#comment-13526732 ] 

Bela Ban commented on JGRP-2245:
--------------------------------

Let me know if this works! You need 4.0.10 (not yet released) to test, or a build of JGroups master.

> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
>                 Key: JGRP-2245
>                 URL: https://issues.jboss.org/browse/JGRP-2245
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.8
>            Reporter: Sibin Karnavar
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is 
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
> {code:java}
>  // remove all files which are not from the current members
>     protected void handleView(View new_view, View old_view, boolean coord_changed) {
>         if(is_coord) {
>             if(coord_changed) {
>                 if(remove_all_data_on_view_change)
>                     removeAll(cluster_name);
>                 else if(remove_old_coords_on_view_change) {
>                     Address old_coord=old_view != null? old_view.getCreator() : null;
>                     if(old_coord != null)
>                         remove(cluster_name, old_coord);
>                 }
>             }
>             if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
>                 writeAll();
>                 if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
>                     startInfoWriter();
>             }
>         }
>         else if(coord_changed) // I'm no longer the coordinator
>             remove(cluster_name, local_addr);
>     }
> {code}
> 4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 10:31:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 31 Jan 2018 10:31:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not
 clearing the crashed members
In-Reply-To: <JIRA.12729827.1516314140000@Atlassian.JIRA>
References: <JIRA.12729827.1516314140000@Atlassian.JIRA>
	<JIRA.12729827.1516314140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729827.1516314140000.18092.1517412660351@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13521120#comment-13521120 ] 

Bela Ban edited comment on JGRP-2245 at 1/31/18 10:30 AM:
----------------------------------------------------------

Will you be able to make JGroups writes only its own address to DB or just the new view or latest


was (Author: sibin.karnavar):
Will you be able to make J GROUP writes only its own address to DB or just the new view or latest

> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
>                 Key: JGRP-2245
>                 URL: https://issues.jboss.org/browse/JGRP-2245
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.8
>            Reporter: Sibin Karnavar
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is 
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
> {code:java}
>  // remove all files which are not from the current members
>     protected void handleView(View new_view, View old_view, boolean coord_changed) {
>         if(is_coord) {
>             if(coord_changed) {
>                 if(remove_all_data_on_view_change)
>                     removeAll(cluster_name);
>                 else if(remove_old_coords_on_view_change) {
>                     Address old_coord=old_view != null? old_view.getCreator() : null;
>                     if(old_coord != null)
>                         remove(cluster_name, old_coord);
>                 }
>             }
>             if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
>                 writeAll();
>                 if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
>                     startInfoWriter();
>             }
>         }
>         else if(coord_changed) // I'm no longer the coordinator
>             remove(cluster_name, local_addr);
>     }
> {code}
> 4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 10:39:02 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 31 Jan 2018 10:39:02 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2248) SASL protocol should not pass
 null callbackhandlers to Factories
In-Reply-To: <JIRA.12731557.1517312404000@Atlassian.JIRA>
References: <JIRA.12731557.1517312404000@Atlassian.JIRA>
	<JIRA.12731557.1517312404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731557.1517312404000.18182.1517413142457@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526743#comment-13526743 ] 

Bela Ban commented on JGRP-2248:
--------------------------------

I plan to release 4.0.10.Final within 1-2 weeks, so if this issue makes that cut, I won't mind...

> SASL protocol should not pass null callbackhandlers to Factories
> ----------------------------------------------------------------
>
>                 Key: JGRP-2248
>                 URL: https://issues.jboss.org/browse/JGRP-2248
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 4.0.9
>            Reporter: Ryan Emerson
>            Assignee: Ryan Emerson
>             Fix For: 4.0.10
>
>
> Currently it's possible for the client and server callback handlers to be null when passed to the respective Sasl Factory. When utilising the Elytron Sasl factories this results in an IllegalArgumentException being thrown. To avoid this we should ensure that the callback handlers are non-null when passed to the factory implementations, e.g. pass a NoOpCallbackHandler.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 10:40:00 2018
From: issues at jboss.org (Bela Ban (JIRA))
Date: Wed, 31 Jan 2018 10:40:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2241) Bundler using direct memory
	as buffer
In-Reply-To: <JIRA.12724097.1512738713000@Atlassian.JIRA>
References: <JIRA.12724097.1512738713000@Atlassian.JIRA>
	<JIRA.12724097.1512738713000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12724097.1512738713000.18203.1517413200502@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/JGRP-2241?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Bela Ban updated JGRP-2241:
---------------------------
    Fix Version/s: 4.0.11
                       (was: 4.0.10)


> Bundler using direct memory as buffer
> -------------------------------------
>
>                 Key: JGRP-2241
>                 URL: https://issues.jboss.org/browse/JGRP-2241
>             Project: JGroups
>          Issue Type: Feature Request
>            Reporter: Bela Ban
>            Assignee: Bela Ban
>             Fix For: 4.0.11
>
>
> The current bundler impls use a byte[] array in an output stream as buffer into which messages are written.
> If we instead used a direct byte buffer (off-heap), the JDK would not create an additional copy but simply pass the contents to the corresponding socket. This would reduce the memory allocation rate.
> Direct buffers can also be used on the receiver side, investigate.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 10:46:00 2018
From: issues at jboss.org (Sibin Karnavar (JIRA))
Date: Wed, 31 Jan 2018 10:46:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not
 clearing the crashed members
In-Reply-To: <JIRA.12729827.1516314140000@Atlassian.JIRA>
References: <JIRA.12729827.1516314140000@Atlassian.JIRA>
	<JIRA.12729827.1516314140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729827.1516314140000.18311.1517413560315@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526753#comment-13526753 ] 

Sibin Karnavar commented on JGRP-2245:
--------------------------------------

Thank you. I will test this out and update you on this.

> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
>                 Key: JGRP-2245
>                 URL: https://issues.jboss.org/browse/JGRP-2245
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.8
>            Reporter: Sibin Karnavar
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is 
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
> {code:java}
>  // remove all files which are not from the current members
>     protected void handleView(View new_view, View old_view, boolean coord_changed) {
>         if(is_coord) {
>             if(coord_changed) {
>                 if(remove_all_data_on_view_change)
>                     removeAll(cluster_name);
>                 else if(remove_old_coords_on_view_change) {
>                     Address old_coord=old_view != null? old_view.getCreator() : null;
>                     if(old_coord != null)
>                         remove(cluster_name, old_coord);
>                 }
>             }
>             if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
>                 writeAll();
>                 if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
>                     startInfoWriter();
>             }
>         }
>         else if(coord_changed) // I'm no longer the coordinator
>             remove(cluster_name, local_addr);
>     }
> {code}
> 4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 11:44:00 2018
From: issues at jboss.org (Ryan Emerson (JIRA))
Date: Wed, 31 Jan 2018 11:44:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2248) SASL protocol should not pass
 null callbackhandlers to Factories
In-Reply-To: <JIRA.12731557.1517312404000@Atlassian.JIRA>
References: <JIRA.12731557.1517312404000@Atlassian.JIRA>
	<JIRA.12731557.1517312404000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731557.1517312404000.18941.1517417040207@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526805#comment-13526805 ] 

Ryan Emerson commented on JGRP-2248:
------------------------------------

[~belaban] Done. If we can get 4.0.10.Final in time for ISPN 9.2.0.Final (14/02) that would be ideal as it would allow me to remove my current workaround before release.

> SASL protocol should not pass null callbackhandlers to Factories
> ----------------------------------------------------------------
>
>                 Key: JGRP-2248
>                 URL: https://issues.jboss.org/browse/JGRP-2248
>             Project: JGroups
>          Issue Type: Enhancement
>    Affects Versions: 4.0.9
>            Reporter: Ryan Emerson
>            Assignee: Ryan Emerson
>             Fix For: 4.0.10
>
>
> Currently it's possible for the client and server callback handlers to be null when passed to the respective Sasl Factory. When utilising the Elytron Sasl factories this results in an IllegalArgumentException being thrown. To avoid this we should ensure that the callback handlers are non-null when passed to the factory implementations, e.g. pass a NoOpCallbackHandler.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 13:58:01 2018
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 31 Jan 2018 13:58:01 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9747)
 wildfly-arquillian-container-managed: java.lang.ClassNotFoundException:
 org.wildfly.security.permission.AbstractNameSetOnlyPermission
In-Reply-To: <JIRA.12731980.1517425068000@Atlassian.JIRA>
References: <JIRA.12731980.1517425068000@Atlassian.JIRA>
	<JIRA.12731980.1517425068705@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731980.1517425068000.19505.1517425081856@Atlassian.JIRA>

Geoffrey De Smet created WFLY-9747:
--------------------------------------

             Summary: wildfly-arquillian-container-managed: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
                 Key: WFLY-9747
                 URL: https://issues.jboss.org/browse/WFLY-9747
             Project: WildFly
          Issue Type: Bug
            Reporter: Geoffrey De Smet
            Assignee: Jason Greene


I get this error:

{code}
[INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
WARNING: Bundles path is deprecated and no longer used.
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
[ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)

{code}

With this parent pom:

{code}
  <properties>
    <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
    <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
    <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.arquillian</groupId>
        <artifactId>arquillian-bom</artifactId>
        <version>${version.org.jboss.arquillian}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.wildfly.arquillian</groupId>
        <artifactId>wildfly-arquillian-container-managed</artifactId>
        <version>${version.org.wildfly.arquillian}</version>
      </dependency>
      <dependency>
        <groupId>org.jboss.resteasy</groupId>
        <artifactId>resteasy-client</artifactId>
        <version>${version.org.jboss.resteasy}</version>
      </dependency>
...
{code}

and this child pom:

{code}
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.arquillian.junit</groupId>
      <artifactId>arquillian-junit-container</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-depchain</artifactId>
      <type>pom</type>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.wildfly.arquillian</groupId>
      <artifactId>wildfly-arquillian-container-managed</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.resteasy</groupId>
      <artifactId>resteasy-client</artifactId>
      <scope>test</scope>
    </dependency>
{code}

I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (note eap)).
Anyway, wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."

Spring boot gets this right, so can we.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 13:59:00 2018
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 31 Jan 2018 13:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9747)
 wildfly-arquillian-container-managed: java.lang.ClassNotFoundException:
 org.wildfly.security.permission.AbstractNameSetOnlyPermission
In-Reply-To: <JIRA.12731980.1517425069000@Atlassian.JIRA>
References: <JIRA.12731980.1517425069000@Atlassian.JIRA>
	<JIRA.12731980.1517425069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731980.1517425069000.19508.1517425140257@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated WFLY-9747:
-----------------------------------
    Description: 
I get this error:

{code}
[INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
WARNING: Bundles path is deprecated and no longer used.
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
[ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)

{code}

With this parent pom:

{code}
  <properties>
    <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
    <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
    <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.arquillian</groupId>
        <artifactId>arquillian-bom</artifactId>
        <version>${version.org.jboss.arquillian}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.wildfly.arquillian</groupId>
        <artifactId>wildfly-arquillian-container-managed</artifactId>
        <version>${version.org.wildfly.arquillian}</version>
      </dependency>
      <dependency>
        <groupId>org.jboss.resteasy</groupId>
        <artifactId>resteasy-client</artifactId>
        <version>${version.org.jboss.resteasy}</version>
      </dependency>
...
{code}

and this child pom:

{code}
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.arquillian.junit</groupId>
      <artifactId>arquillian-junit-container</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-depchain</artifactId>
      <type>pom</type>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.wildfly.arquillian</groupId>
      <artifactId>wildfly-arquillian-container-managed</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.resteasy</groupId>
      <artifactId>resteasy-client</artifactId>
      <scope>test</scope>
    </dependency>
{code}

I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (note eap)).
Anyway, wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."


  was:
I get this error:

{code}
[INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
WARNING: Bundles path is deprecated and no longer used.
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
[ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)

{code}

With this parent pom:

{code}
  <properties>
    <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
    <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
    <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.arquillian</groupId>
        <artifactId>arquillian-bom</artifactId>
        <version>${version.org.jboss.arquillian}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.wildfly.arquillian</groupId>
        <artifactId>wildfly-arquillian-container-managed</artifactId>
        <version>${version.org.wildfly.arquillian}</version>
      </dependency>
      <dependency>
        <groupId>org.jboss.resteasy</groupId>
        <artifactId>resteasy-client</artifactId>
        <version>${version.org.jboss.resteasy}</version>
      </dependency>
...
{code}

and this child pom:

{code}
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.arquillian.junit</groupId>
      <artifactId>arquillian-junit-container</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-depchain</artifactId>
      <type>pom</type>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.wildfly.arquillian</groupId>
      <artifactId>wildfly-arquillian-container-managed</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.resteasy</groupId>
      <artifactId>resteasy-client</artifactId>
      <scope>test</scope>
    </dependency>
{code}

I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (note eap)).
Anyway, wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."

Spring boot gets this right, so can we.



> wildfly-arquillian-container-managed: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9747
>                 URL: https://issues.jboss.org/browse/WFLY-9747
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Geoffrey De Smet
>            Assignee: Jason Greene
>
> I get this error:
> {code}
> [INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> WARNING: Bundles path is deprecated and no longer used.
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> [ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
> java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> {code}
> With this parent pom:
> {code}
>   <properties>
>     <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
>     <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
>     <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
>   </properties>
>   <dependencyManagement>
>     <dependencies>
>       <dependency>
>         <groupId>org.jboss.arquillian</groupId>
>         <artifactId>arquillian-bom</artifactId>
>         <version>${version.org.jboss.arquillian}</version>
>         <type>pom</type>
>         <scope>import</scope>
>       </dependency>
>       <dependency>
>         <groupId>org.wildfly.arquillian</groupId>
>         <artifactId>wildfly-arquillian-container-managed</artifactId>
>         <version>${version.org.wildfly.arquillian}</version>
>       </dependency>
>       <dependency>
>         <groupId>org.jboss.resteasy</groupId>
>         <artifactId>resteasy-client</artifactId>
>         <version>${version.org.jboss.resteasy}</version>
>       </dependency>
> ...
> {code}
> and this child pom:
> {code}
>     <dependency>
>       <groupId>junit</groupId>
>       <artifactId>junit</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.arquillian.junit</groupId>
>       <artifactId>arquillian-junit-container</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.shrinkwrap.resolver</groupId>
>       <artifactId>shrinkwrap-resolver-depchain</artifactId>
>       <type>pom</type>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.wildfly.arquillian</groupId>
>       <artifactId>wildfly-arquillian-container-managed</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.resteasy</groupId>
>       <artifactId>resteasy-client</artifactId>
>       <scope>test</scope>
>     </dependency>
> {code}
> I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (note eap)).
> Anyway, wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 13:59:00 2018
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 31 Jan 2018 13:59:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9747)
 wildfly-arquillian-container-managed: java.lang.ClassNotFoundException:
 org.wildfly.security.permission.AbstractNameSetOnlyPermission
In-Reply-To: <JIRA.12731980.1517425069000@Atlassian.JIRA>
References: <JIRA.12731980.1517425069000@Atlassian.JIRA>
	<JIRA.12731980.1517425069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731980.1517425069000.19512.1517425140772@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated WFLY-9747:
-----------------------------------
    Description: 
I get this error:

{code}
[INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
WARNING: Bundles path is deprecated and no longer used.
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
[ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)

{code}

With this parent pom:

{code}
  <properties>
    <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
    <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
    <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.arquillian</groupId>
        <artifactId>arquillian-bom</artifactId>
        <version>${version.org.jboss.arquillian}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.wildfly.arquillian</groupId>
        <artifactId>wildfly-arquillian-container-managed</artifactId>
        <version>${version.org.wildfly.arquillian}</version>
      </dependency>
      <dependency>
        <groupId>org.jboss.resteasy</groupId>
        <artifactId>resteasy-client</artifactId>
        <version>${version.org.jboss.resteasy}</version>
      </dependency>
...
{code}

and this child pom:

{code}
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.arquillian.junit</groupId>
      <artifactId>arquillian-junit-container</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-depchain</artifactId>
      <type>pom</type>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.wildfly.arquillian</groupId>
      <artifactId>wildfly-arquillian-container-managed</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.resteasy</groupId>
      <artifactId>resteasy-client</artifactId>
      <scope>test</scope>
    </dependency>
{code}

I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).
Anyway, wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."


  was:
I get this error:

{code}
[INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
WARNING: Bundles path is deprecated and no longer used.
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
[ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)

{code}

With this parent pom:

{code}
  <properties>
    <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
    <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
    <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.arquillian</groupId>
        <artifactId>arquillian-bom</artifactId>
        <version>${version.org.jboss.arquillian}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.wildfly.arquillian</groupId>
        <artifactId>wildfly-arquillian-container-managed</artifactId>
        <version>${version.org.wildfly.arquillian}</version>
      </dependency>
      <dependency>
        <groupId>org.jboss.resteasy</groupId>
        <artifactId>resteasy-client</artifactId>
        <version>${version.org.jboss.resteasy}</version>
      </dependency>
...
{code}

and this child pom:

{code}
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.arquillian.junit</groupId>
      <artifactId>arquillian-junit-container</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-depchain</artifactId>
      <type>pom</type>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.wildfly.arquillian</groupId>
      <artifactId>wildfly-arquillian-container-managed</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.resteasy</groupId>
      <artifactId>resteasy-client</artifactId>
      <scope>test</scope>
    </dependency>
{code}

I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (note eap)).
Anyway, wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."




> wildfly-arquillian-container-managed: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9747
>                 URL: https://issues.jboss.org/browse/WFLY-9747
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Geoffrey De Smet
>            Assignee: Jason Greene
>
> I get this error:
> {code}
> [INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> WARNING: Bundles path is deprecated and no longer used.
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> [ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
> java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> {code}
> With this parent pom:
> {code}
>   <properties>
>     <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
>     <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
>     <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
>   </properties>
>   <dependencyManagement>
>     <dependencies>
>       <dependency>
>         <groupId>org.jboss.arquillian</groupId>
>         <artifactId>arquillian-bom</artifactId>
>         <version>${version.org.jboss.arquillian}</version>
>         <type>pom</type>
>         <scope>import</scope>
>       </dependency>
>       <dependency>
>         <groupId>org.wildfly.arquillian</groupId>
>         <artifactId>wildfly-arquillian-container-managed</artifactId>
>         <version>${version.org.wildfly.arquillian}</version>
>       </dependency>
>       <dependency>
>         <groupId>org.jboss.resteasy</groupId>
>         <artifactId>resteasy-client</artifactId>
>         <version>${version.org.jboss.resteasy}</version>
>       </dependency>
> ...
> {code}
> and this child pom:
> {code}
>     <dependency>
>       <groupId>junit</groupId>
>       <artifactId>junit</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.arquillian.junit</groupId>
>       <artifactId>arquillian-junit-container</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.shrinkwrap.resolver</groupId>
>       <artifactId>shrinkwrap-resolver-depchain</artifactId>
>       <type>pom</type>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.wildfly.arquillian</groupId>
>       <artifactId>wildfly-arquillian-container-managed</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.resteasy</groupId>
>       <artifactId>resteasy-client</artifactId>
>       <scope>test</scope>
>     </dependency>
> {code}
> I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).
> Anyway, wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 14:01:00 2018
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 31 Jan 2018 14:01:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9747)
 wildfly-arquillian-container-managed: java.lang.ClassNotFoundException:
 org.wildfly.security.permission.AbstractNameSetOnlyPermission
In-Reply-To: <JIRA.12731980.1517425069000@Atlassian.JIRA>
References: <JIRA.12731980.1517425069000@Atlassian.JIRA>
	<JIRA.12731980.1517425069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731980.1517425069000.19532.1517425260833@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated WFLY-9747:
-----------------------------------
    Description: 
I get this error:

{code}
[INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
WARNING: Bundles path is deprecated and no longer used.
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
[ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)

{code}

With this parent pom:

{code}
  <properties>
    <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
    <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
    <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.arquillian</groupId>
        <artifactId>arquillian-bom</artifactId>
        <version>${version.org.jboss.arquillian}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.wildfly.arquillian</groupId>
        <artifactId>wildfly-arquillian-container-managed</artifactId>
        <version>${version.org.wildfly.arquillian}</version>
      </dependency>
      <dependency>
        <groupId>org.jboss.resteasy</groupId>
        <artifactId>resteasy-client</artifactId>
        <version>${version.org.jboss.resteasy}</version>
      </dependency>
...
{code}

and this child pom:

{code}
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.arquillian.junit</groupId>
      <artifactId>arquillian-junit-container</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-depchain</artifactId>
      <type>pom</type>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.wildfly.arquillian</groupId>
      <artifactId>wildfly-arquillian-container-managed</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.resteasy</groupId>
      <artifactId>resteasy-client</artifactId>
      <scope>test</scope>
    </dependency>
{code}

I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).

Solution proposal A)
wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."

Solution proposal B)
Use the same version numbers for wildfly-arquillian-container-managed (currently 2.1.0.Final) as for wildfly.


  was:
I get this error:

{code}
[INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
WARNING: Bundles path is deprecated and no longer used.
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
[ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)

{code}

With this parent pom:

{code}
  <properties>
    <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
    <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
    <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.arquillian</groupId>
        <artifactId>arquillian-bom</artifactId>
        <version>${version.org.jboss.arquillian}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.wildfly.arquillian</groupId>
        <artifactId>wildfly-arquillian-container-managed</artifactId>
        <version>${version.org.wildfly.arquillian}</version>
      </dependency>
      <dependency>
        <groupId>org.jboss.resteasy</groupId>
        <artifactId>resteasy-client</artifactId>
        <version>${version.org.jboss.resteasy}</version>
      </dependency>
...
{code}

and this child pom:

{code}
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.arquillian.junit</groupId>
      <artifactId>arquillian-junit-container</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-depchain</artifactId>
      <type>pom</type>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.wildfly.arquillian</groupId>
      <artifactId>wildfly-arquillian-container-managed</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.resteasy</groupId>
      <artifactId>resteasy-client</artifactId>
      <scope>test</scope>
    </dependency>
{code}

I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).
Anyway, wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."




> wildfly-arquillian-container-managed: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9747
>                 URL: https://issues.jboss.org/browse/WFLY-9747
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Geoffrey De Smet
>            Assignee: Jason Greene
>
> I get this error:
> {code}
> [INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> WARNING: Bundles path is deprecated and no longer used.
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> [ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
> java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> {code}
> With this parent pom:
> {code}
>   <properties>
>     <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
>     <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
>     <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
>   </properties>
>   <dependencyManagement>
>     <dependencies>
>       <dependency>
>         <groupId>org.jboss.arquillian</groupId>
>         <artifactId>arquillian-bom</artifactId>
>         <version>${version.org.jboss.arquillian}</version>
>         <type>pom</type>
>         <scope>import</scope>
>       </dependency>
>       <dependency>
>         <groupId>org.wildfly.arquillian</groupId>
>         <artifactId>wildfly-arquillian-container-managed</artifactId>
>         <version>${version.org.wildfly.arquillian}</version>
>       </dependency>
>       <dependency>
>         <groupId>org.jboss.resteasy</groupId>
>         <artifactId>resteasy-client</artifactId>
>         <version>${version.org.jboss.resteasy}</version>
>       </dependency>
> ...
> {code}
> and this child pom:
> {code}
>     <dependency>
>       <groupId>junit</groupId>
>       <artifactId>junit</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.arquillian.junit</groupId>
>       <artifactId>arquillian-junit-container</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.shrinkwrap.resolver</groupId>
>       <artifactId>shrinkwrap-resolver-depchain</artifactId>
>       <type>pom</type>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.wildfly.arquillian</groupId>
>       <artifactId>wildfly-arquillian-container-managed</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.resteasy</groupId>
>       <artifactId>resteasy-client</artifactId>
>       <scope>test</scope>
>     </dependency>
> {code}
> I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).
> Solution proposal A)
> wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."
> Solution proposal B)
> Use the same version numbers for wildfly-arquillian-container-managed (currently 2.1.0.Final) as for wildfly.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 14:02:00 2018
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 31 Jan 2018 14:02:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9747)
 wildfly-arquillian-container-managed: java.lang.ClassNotFoundException:
 org.wildfly.security.permission.AbstractNameSetOnlyPermission
In-Reply-To: <JIRA.12731980.1517425069000@Atlassian.JIRA>
References: <JIRA.12731980.1517425069000@Atlassian.JIRA>
	<JIRA.12731980.1517425069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731980.1517425069000.19538.1517425320450@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated WFLY-9747:
-----------------------------------
    Description: 
On a pretty vanilla war file with a bit JAX-RS and JPA, I get this error:

{code}
[INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
WARNING: Bundles path is deprecated and no longer used.
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
[ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)

{code}

With this parent pom:

{code}
  <properties>
    <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
    <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
    <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.arquillian</groupId>
        <artifactId>arquillian-bom</artifactId>
        <version>${version.org.jboss.arquillian}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.wildfly.arquillian</groupId>
        <artifactId>wildfly-arquillian-container-managed</artifactId>
        <version>${version.org.wildfly.arquillian}</version>
      </dependency>
      <dependency>
        <groupId>org.jboss.resteasy</groupId>
        <artifactId>resteasy-client</artifactId>
        <version>${version.org.jboss.resteasy}</version>
      </dependency>
...
{code}

and this child pom:

{code}
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.arquillian.junit</groupId>
      <artifactId>arquillian-junit-container</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-depchain</artifactId>
      <type>pom</type>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.wildfly.arquillian</groupId>
      <artifactId>wildfly-arquillian-container-managed</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.resteasy</groupId>
      <artifactId>resteasy-client</artifactId>
      <scope>test</scope>
    </dependency>
{code}

I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).

Solution proposal A)
wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."

Solution proposal B)
Use the same version numbers for wildfly-arquillian-container-managed (currently 2.1.0.Final) as for wildfly.


  was:
I get this error:

{code}
[INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
WARNING: Bundles path is deprecated and no longer used.
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
[ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)

{code}

With this parent pom:

{code}
  <properties>
    <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
    <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
    <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.arquillian</groupId>
        <artifactId>arquillian-bom</artifactId>
        <version>${version.org.jboss.arquillian}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.wildfly.arquillian</groupId>
        <artifactId>wildfly-arquillian-container-managed</artifactId>
        <version>${version.org.wildfly.arquillian}</version>
      </dependency>
      <dependency>
        <groupId>org.jboss.resteasy</groupId>
        <artifactId>resteasy-client</artifactId>
        <version>${version.org.jboss.resteasy}</version>
      </dependency>
...
{code}

and this child pom:

{code}
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.arquillian.junit</groupId>
      <artifactId>arquillian-junit-container</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-depchain</artifactId>
      <type>pom</type>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.wildfly.arquillian</groupId>
      <artifactId>wildfly-arquillian-container-managed</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.resteasy</groupId>
      <artifactId>resteasy-client</artifactId>
      <scope>test</scope>
    </dependency>
{code}

I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).

Solution proposal A)
wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."

Solution proposal B)
Use the same version numbers for wildfly-arquillian-container-managed (currently 2.1.0.Final) as for wildfly.




> wildfly-arquillian-container-managed: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9747
>                 URL: https://issues.jboss.org/browse/WFLY-9747
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Geoffrey De Smet
>            Assignee: Jason Greene
>
> On a pretty vanilla war file with a bit JAX-RS and JPA, I get this error:
> {code}
> [INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> WARNING: Bundles path is deprecated and no longer used.
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> [ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
> java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> {code}
> With this parent pom:
> {code}
>   <properties>
>     <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
>     <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
>     <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
>   </properties>
>   <dependencyManagement>
>     <dependencies>
>       <dependency>
>         <groupId>org.jboss.arquillian</groupId>
>         <artifactId>arquillian-bom</artifactId>
>         <version>${version.org.jboss.arquillian}</version>
>         <type>pom</type>
>         <scope>import</scope>
>       </dependency>
>       <dependency>
>         <groupId>org.wildfly.arquillian</groupId>
>         <artifactId>wildfly-arquillian-container-managed</artifactId>
>         <version>${version.org.wildfly.arquillian}</version>
>       </dependency>
>       <dependency>
>         <groupId>org.jboss.resteasy</groupId>
>         <artifactId>resteasy-client</artifactId>
>         <version>${version.org.jboss.resteasy}</version>
>       </dependency>
> ...
> {code}
> and this child pom:
> {code}
>     <dependency>
>       <groupId>junit</groupId>
>       <artifactId>junit</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.arquillian.junit</groupId>
>       <artifactId>arquillian-junit-container</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.shrinkwrap.resolver</groupId>
>       <artifactId>shrinkwrap-resolver-depchain</artifactId>
>       <type>pom</type>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.wildfly.arquillian</groupId>
>       <artifactId>wildfly-arquillian-container-managed</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.resteasy</groupId>
>       <artifactId>resteasy-client</artifactId>
>       <scope>test</scope>
>     </dependency>
> {code}
> I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).
> Solution proposal A)
> wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."
> Solution proposal B)
> Use the same version numbers for wildfly-arquillian-container-managed (currently 2.1.0.Final) as for wildfly.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 14:03:00 2018
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 31 Jan 2018 14:03:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9747)
 wildfly-arquillian-container-managed: java.lang.ClassNotFoundException:
 org.wildfly.security.permission.AbstractNameSetOnlyPermission
In-Reply-To: <JIRA.12731980.1517425069000@Atlassian.JIRA>
References: <JIRA.12731980.1517425069000@Atlassian.JIRA>
	<JIRA.12731980.1517425069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731980.1517425069000.19540.1517425380376@Atlassian.JIRA>


     [ https://issues.jboss.org/browse/WFLY-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Geoffrey De Smet updated WFLY-9747:
-----------------------------------
    Description: 
On a pretty vanilla war file with a bit JAX-RS and arquillian, I get this error when trying to run an arquillian test (that worked before we upgraded the wildfly version):

{code}
[INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
WARNING: Bundles path is deprecated and no longer used.
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
[ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)

{code}

With this parent pom:

{code}
  <properties>
    <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
    <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
    <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.arquillian</groupId>
        <artifactId>arquillian-bom</artifactId>
        <version>${version.org.jboss.arquillian}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.wildfly.arquillian</groupId>
        <artifactId>wildfly-arquillian-container-managed</artifactId>
        <version>${version.org.wildfly.arquillian}</version>
      </dependency>
      <dependency>
        <groupId>org.jboss.resteasy</groupId>
        <artifactId>resteasy-client</artifactId>
        <version>${version.org.jboss.resteasy}</version>
      </dependency>
...
{code}

and this child pom:

{code}
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.arquillian.junit</groupId>
      <artifactId>arquillian-junit-container</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-depchain</artifactId>
      <type>pom</type>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.wildfly.arquillian</groupId>
      <artifactId>wildfly-arquillian-container-managed</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.resteasy</groupId>
      <artifactId>resteasy-client</artifactId>
      <scope>test</scope>
    </dependency>
{code}

I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).

Solution proposal A)
wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."

Solution proposal B)
Use the same version numbers for wildfly-arquillian-container-managed (currently 2.1.0.Final) as for wildfly.


  was:
On a pretty vanilla war file with a bit JAX-RS and JPA, I get this error:

{code}
[INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
WARNING: Bundles path is deprecated and no longer used.
Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
[ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
[ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
        at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
        at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
        at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)

{code}

With this parent pom:

{code}
  <properties>
    <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
    <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
    <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
  </properties>
  <dependencyManagement>
    <dependencies>
      <dependency>
        <groupId>org.jboss.arquillian</groupId>
        <artifactId>arquillian-bom</artifactId>
        <version>${version.org.jboss.arquillian}</version>
        <type>pom</type>
        <scope>import</scope>
      </dependency>
      <dependency>
        <groupId>org.wildfly.arquillian</groupId>
        <artifactId>wildfly-arquillian-container-managed</artifactId>
        <version>${version.org.wildfly.arquillian}</version>
      </dependency>
      <dependency>
        <groupId>org.jboss.resteasy</groupId>
        <artifactId>resteasy-client</artifactId>
        <version>${version.org.jboss.resteasy}</version>
      </dependency>
...
{code}

and this child pom:

{code}
    <dependency>
      <groupId>junit</groupId>
      <artifactId>junit</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.arquillian.junit</groupId>
      <artifactId>arquillian-junit-container</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.shrinkwrap.resolver</groupId>
      <artifactId>shrinkwrap-resolver-depchain</artifactId>
      <type>pom</type>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.wildfly.arquillian</groupId>
      <artifactId>wildfly-arquillian-container-managed</artifactId>
      <scope>test</scope>
    </dependency>
    <dependency>
      <groupId>org.jboss.resteasy</groupId>
      <artifactId>resteasy-client</artifactId>
      <scope>test</scope>
    </dependency>
{code}

I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).

Solution proposal A)
wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."

Solution proposal B)
Use the same version numbers for wildfly-arquillian-container-managed (currently 2.1.0.Final) as for wildfly.




> wildfly-arquillian-container-managed: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9747
>                 URL: https://issues.jboss.org/browse/WFLY-9747
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Geoffrey De Smet
>            Assignee: Jason Greene
>
> On a pretty vanilla war file with a bit JAX-RS and arquillian, I get this error when trying to run an arquillian test (that worked before we upgraded the wildfly version):
> {code}
> [INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> WARNING: Bundles path is deprecated and no longer used.
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> [ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
> java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> {code}
> With this parent pom:
> {code}
>   <properties>
>     <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
>     <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
>     <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
>   </properties>
>   <dependencyManagement>
>     <dependencies>
>       <dependency>
>         <groupId>org.jboss.arquillian</groupId>
>         <artifactId>arquillian-bom</artifactId>
>         <version>${version.org.jboss.arquillian}</version>
>         <type>pom</type>
>         <scope>import</scope>
>       </dependency>
>       <dependency>
>         <groupId>org.wildfly.arquillian</groupId>
>         <artifactId>wildfly-arquillian-container-managed</artifactId>
>         <version>${version.org.wildfly.arquillian}</version>
>       </dependency>
>       <dependency>
>         <groupId>org.jboss.resteasy</groupId>
>         <artifactId>resteasy-client</artifactId>
>         <version>${version.org.jboss.resteasy}</version>
>       </dependency>
> ...
> {code}
> and this child pom:
> {code}
>     <dependency>
>       <groupId>junit</groupId>
>       <artifactId>junit</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.arquillian.junit</groupId>
>       <artifactId>arquillian-junit-container</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.shrinkwrap.resolver</groupId>
>       <artifactId>shrinkwrap-resolver-depchain</artifactId>
>       <type>pom</type>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.wildfly.arquillian</groupId>
>       <artifactId>wildfly-arquillian-container-managed</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.resteasy</groupId>
>       <artifactId>resteasy-client</artifactId>
>       <scope>test</scope>
>     </dependency>
> {code}
> I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).
> Solution proposal A)
> wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."
> Solution proposal B)
> Use the same version numbers for wildfly-arquillian-container-managed (currently 2.1.0.Final) as for wildfly.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 14:13:00 2018
From: issues at jboss.org (Sibin Karnavar (JIRA))
Date: Wed, 31 Jan 2018 14:13:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (JGRP-2245) JGroup JDBC_PING is not
 clearing the crashed members
In-Reply-To: <JIRA.12729827.1516314140000@Atlassian.JIRA>
References: <JIRA.12729827.1516314140000@Atlassian.JIRA>
	<JIRA.12729827.1516314140000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12729827.1516314140000.19581.1517425980120@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/JGRP-2245?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526853#comment-13526853 ] 

Sibin Karnavar commented on JGRP-2245:
--------------------------------------

I have done a quick test on my local box. Initial test results are looking good.

I can see that,  its Removing the left members when the coordinator changes. and I can see that it writes only the current members to DB on view change.  I can also see that, when a node crashes, the crashed members are still in the database till the co coordinator changes (That looks fine to me)

I will be deploying it in AWS and doing some more tests cases.

Thank You

> JGroup JDBC_PING is not clearing the crashed members
> ----------------------------------------------------
>
>                 Key: JGRP-2245
>                 URL: https://issues.jboss.org/browse/JGRP-2245
>             Project: JGroups
>          Issue Type: Bug
>    Affects Versions: 4.0.8
>            Reporter: Sibin Karnavar
>            Assignee: Bela Ban
>             Fix For: 4.0.10
>
>
> 1) In AWS cloud environments, IP address will be different when a node crashes and when a new cluster node gets recreated.
> 2) In this situation, JGroup is not clearing logical_addr_cache and it gets confused, when we restart the cluster nodes.
> 3)logical_addr_cache_max_size and the eviction did not work because, the cache is again getting updated from the ping and it never getting marked as removable.
> I think the issue is 
> handleView method is always re writing the entire cache on view change to the db. So even if we clear the table with the help of above mentioned flags (remove_all_data_on_view_change && remove_old_coords_on_view_change) , its getting re written to the table.
> {code:java}
>  // remove all files which are not from the current members
>     protected void handleView(View new_view, View old_view, boolean coord_changed) {
>         if(is_coord) {
>             if(coord_changed) {
>                 if(remove_all_data_on_view_change)
>                     removeAll(cluster_name);
>                 else if(remove_old_coords_on_view_change) {
>                     Address old_coord=old_view != null? old_view.getCreator() : null;
>                     if(old_coord != null)
>                         remove(cluster_name, old_coord);
>                 }
>             }
>             if(coord_changed || View.diff(old_view, new_view)[1].length > 0) {
>                 writeAll();
>                 if(remove_all_data_on_view_change || remove_old_coords_on_view_change)
>                     startInfoWriter();
>             }
>         }
>         else if(coord_changed) // I'm no longer the coordinator
>             remove(cluster_name, local_addr);
>     }
> {code}
> 4) Because of the crashed members  (non existing ip address), we are getting lot of socket timeouts
> sendToMembers of TP is trying to send messages to old crashed members and writing error logs while startup.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

From issues at jboss.org  Wed Jan 31 14:20:00 2018
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 31 Jan 2018 14:20:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9747)
 wildfly-arquillian-container-managed: java.lang.ClassNotFoundException:
 org.wildfly.security.permission.AbstractNameSetOnlyPermission
In-Reply-To: <JIRA.12731980.1517425069000@Atlassian.JIRA>
References: <JIRA.12731980.1517425069000@Atlassian.JIRA>
	<JIRA.12731980.1517425069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731980.1517425069000.19639.1517426400691@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526866#comment-13526866 ] 

Geoffrey De Smet commented on WFLY-9747:
----------------------------------------

org.wildfly.security.permission.AbstractNameSetOnlyPermission comes from wildfly-elytron.jar and if I compare a working project with older version with my non-working project, I notice that my newer project has the older wildfly-elytron jar:
{code}
// Working project with wildfly and arquillian
[INFO] |  +- org.wildfly.arquillian:wildfly-arquillian-protocol-jmx:jar:2.0.0.Final:test
[INFO] |  |  +- org.wildfly.security:wildfly-elytron:jar:1.1.0.Final:test
{code}
{code}
// My project with wildfly and arquillian
[INFO] +- org.wildfly.arquillian:wildfly-arquillian-container-managed:jar:2.1.0.Final:test
...
[INFO] |  +- org.wildfly.arquillian:wildfly-arquillian-protocol-jmx:jar:2.0.0.Final:test
[INFO] |  |  +- org.wildfly.security:wildfly-elytron:jar:1.0.2.Final:test
{code}

Manually hacking that to add wildfly-elytron 1.1.0.Final makes the error disappear.

Solution proposal C)
Have wildfly-arquillian-protocol-jmx depnd on wildfly-elytron 1.1.0.Final instead of 1.0.2.Final.

> wildfly-arquillian-container-managed: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9747
>                 URL: https://issues.jboss.org/browse/WFLY-9747
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Geoffrey De Smet
>            Assignee: Jason Greene
>
> On a pretty vanilla war file with a bit JAX-RS and arquillian, I get this error when trying to run an arquillian test (that worked before we upgraded the wildfly version):
> {code}
> [INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> WARNING: Bundles path is deprecated and no longer used.
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> [ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
> java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> {code}
> With this parent pom:
> {code}
>   <properties>
>     <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
>     <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
>     <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
>   </properties>
>   <dependencyManagement>
>     <dependencies>
>       <dependency>
>         <groupId>org.jboss.arquillian</groupId>
>         <artifactId>arquillian-bom</artifactId>
>         <version>${version.org.jboss.arquillian}</version>
>         <type>pom</type>
>         <scope>import</scope>
>       </dependency>
>       <dependency>
>         <groupId>org.wildfly.arquillian</groupId>
>         <artifactId>wildfly-arquillian-container-managed</artifactId>
>         <version>${version.org.wildfly.arquillian}</version>
>       </dependency>
>       <dependency>
>         <groupId>org.jboss.resteasy</groupId>
>         <artifactId>resteasy-client</artifactId>
>         <version>${version.org.jboss.resteasy}</version>
>       </dependency>
> ...
> {code}
> and this child pom:
> {code}
>     <dependency>
>       <groupId>junit</groupId>
>       <artifactId>junit</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.arquillian.junit</groupId>
>       <artifactId>arquillian-junit-container</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.shrinkwrap.resolver</groupId>
>       <artifactId>shrinkwrap-resolver-depchain</artifactId>
>       <type>pom</type>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.wildfly.arquillian</groupId>
>       <artifactId>wildfly-arquillian-container-managed</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.resteasy</groupId>
>       <artifactId>resteasy-client</artifactId>
>       <scope>test</scope>
>     </dependency>
> {code}
> I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).
> Solution proposal A)
> wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."
> Solution proposal B)
> Use the same version numbers for wildfly-arquillian-container-managed (currently 2.1.0.Final) as for wildfly.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 14:21:00 2018
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 31 Jan 2018 14:21:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9747)
 wildfly-arquillian-container-managed: java.lang.ClassNotFoundException:
 org.wildfly.security.permission.AbstractNameSetOnlyPermission
In-Reply-To: <JIRA.12731980.1517425069000@Atlassian.JIRA>
References: <JIRA.12731980.1517425069000@Atlassian.JIRA>
	<JIRA.12731980.1517425069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731980.1517425069000.19645.1517426460426@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526866#comment-13526866 ] 

Geoffrey De Smet edited comment on WFLY-9747 at 1/31/18 2:20 PM:
-----------------------------------------------------------------

org.wildfly.security.permission.AbstractNameSetOnlyPermission comes from wildfly-elytron.jar and if I compare a working project with older version with my non-working project, I notice that my newer project has the older wildfly-elytron jar:
{code}
// Working project with wildfly and arquillian
[INFO] |  +- org.wildfly.arquillian:wildfly-arquillian-protocol-jmx:jar:2.0.0.Final:test
[INFO] |  |  +- org.wildfly.security:wildfly-elytron:jar:1.1.0.Final:test
{code}
{code}
// My failing project with wildfly and arquillian
[INFO] +- org.wildfly.arquillian:wildfly-arquillian-container-managed:jar:2.1.0.Final:test
...
[INFO] |  +- org.wildfly.arquillian:wildfly-arquillian-protocol-jmx:jar:2.0.0.Final:test
[INFO] |  |  +- org.wildfly.security:wildfly-elytron:jar:1.0.2.Final:test
{code}

Manually hacking that to add wildfly-elytron 1.1.0.Final makes the error disappear.

Solution proposal C)
Have wildfly-arquillian-protocol-jmx depnd on wildfly-elytron 1.1.0.Final instead of 1.0.2.Final.


was (Author: ge0ffrey):
org.wildfly.security.permission.AbstractNameSetOnlyPermission comes from wildfly-elytron.jar and if I compare a working project with older version with my non-working project, I notice that my newer project has the older wildfly-elytron jar:
{code}
// Working project with wildfly and arquillian
[INFO] |  +- org.wildfly.arquillian:wildfly-arquillian-protocol-jmx:jar:2.0.0.Final:test
[INFO] |  |  +- org.wildfly.security:wildfly-elytron:jar:1.1.0.Final:test
{code}
{code}
// My project with wildfly and arquillian
[INFO] +- org.wildfly.arquillian:wildfly-arquillian-container-managed:jar:2.1.0.Final:test
...
[INFO] |  +- org.wildfly.arquillian:wildfly-arquillian-protocol-jmx:jar:2.0.0.Final:test
[INFO] |  |  +- org.wildfly.security:wildfly-elytron:jar:1.0.2.Final:test
{code}

Manually hacking that to add wildfly-elytron 1.1.0.Final makes the error disappear.

Solution proposal C)
Have wildfly-arquillian-protocol-jmx depnd on wildfly-elytron 1.1.0.Final instead of 1.0.2.Final.

> wildfly-arquillian-container-managed: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9747
>                 URL: https://issues.jboss.org/browse/WFLY-9747
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Geoffrey De Smet
>            Assignee: Jason Greene
>
> On a pretty vanilla war file with a bit JAX-RS and arquillian, I get this error when trying to run an arquillian test (that worked before we upgraded the wildfly version):
> {code}
> [INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> WARNING: Bundles path is deprecated and no longer used.
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> [ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
> java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> {code}
> With this parent pom:
> {code}
>   <properties>
>     <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
>     <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
>     <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
>   </properties>
>   <dependencyManagement>
>     <dependencies>
>       <dependency>
>         <groupId>org.jboss.arquillian</groupId>
>         <artifactId>arquillian-bom</artifactId>
>         <version>${version.org.jboss.arquillian}</version>
>         <type>pom</type>
>         <scope>import</scope>
>       </dependency>
>       <dependency>
>         <groupId>org.wildfly.arquillian</groupId>
>         <artifactId>wildfly-arquillian-container-managed</artifactId>
>         <version>${version.org.wildfly.arquillian}</version>
>       </dependency>
>       <dependency>
>         <groupId>org.jboss.resteasy</groupId>
>         <artifactId>resteasy-client</artifactId>
>         <version>${version.org.jboss.resteasy}</version>
>       </dependency>
> ...
> {code}
> and this child pom:
> {code}
>     <dependency>
>       <groupId>junit</groupId>
>       <artifactId>junit</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.arquillian.junit</groupId>
>       <artifactId>arquillian-junit-container</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.shrinkwrap.resolver</groupId>
>       <artifactId>shrinkwrap-resolver-depchain</artifactId>
>       <type>pom</type>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.wildfly.arquillian</groupId>
>       <artifactId>wildfly-arquillian-container-managed</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.resteasy</groupId>
>       <artifactId>resteasy-client</artifactId>
>       <scope>test</scope>
>     </dependency>
> {code}
> I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).
> Solution proposal A)
> wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."
> Solution proposal B)
> Use the same version numbers for wildfly-arquillian-container-managed (currently 2.1.0.Final) as for wildfly.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 14:23:05 2018
From: issues at jboss.org (Geoffrey De Smet (JIRA))
Date: Wed, 31 Jan 2018 14:23:05 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9747)
 wildfly-arquillian-container-managed: java.lang.ClassNotFoundException:
 org.wildfly.security.permission.AbstractNameSetOnlyPermission
In-Reply-To: <JIRA.12731980.1517425069000@Atlassian.JIRA>
References: <JIRA.12731980.1517425069000@Atlassian.JIRA>
	<JIRA.12731980.1517425069000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12731980.1517425069000.19713.1517426585148@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9747?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526868#comment-13526868 ] 

Geoffrey De Smet commented on WFLY-9747:
----------------------------------------

*Workaround*

Add this dependency after the wildfly-arquillian-container-managed 2.1.0.Final dependency:

{code}
    <dependency>
      <!-- TODO Workaround to fix wildfly-arquillian-container-managed https://issues.jboss.org/browse/WFLY-9747 -->
      <groupId>org.wildfly.security</groupId>
      <artifactId>wildfly-elytron</artifactId>
      <version>1.1.0.Final</version>
      <scope>test</scope>
    </dependency>
{code}

> wildfly-arquillian-container-managed: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
> -------------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: WFLY-9747
>                 URL: https://issues.jboss.org/browse/WFLY-9747
>             Project: WildFly
>          Issue Type: Bug
>            Reporter: Geoffrey De Smet
>            Assignee: Jason Greene
>
> On a pretty vanilla war file with a bit JAX-RS and arquillian, I get this error when trying to run an arquillian test (that worked before we upgraded the wildfly version):
> {code}
> [INFO] Running org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> WARNING: Bundles path is deprecated and no longer used.
> Jan 31, 2018 7:52:20 PM org.jboss.as.arquillian.container.managed.ManagedDeployableContainer startInternal
> INFO: Starting container with: [/usr/lib/jvm/java-openjdk/bin/java, -D[Standalone], -Djboss.socket.binding.port-offset=10000, -Xms512m, -Xmx1024m, -XX:MaxPermSize=512m, -ea, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Dorg.jboss.boot.log.file=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log/server.log, -Dlogging.configuration=file:/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration/logging.properties, -jar, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/jboss-modules.jar, -mp, /home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/modules, org.jboss.as.standalone, -Djboss.home.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final, -Djboss.server.base.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone, -Djboss.server.log.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/log, -Djboss.server.config.dir=/home/ge0ffrey/projects/jboss/optashift/optashift-employee-rostering/local/appserver/wildfly-10.1.0.Final/standalone/configuration]
> OpenJDK 64-Bit Server VM warning: ignoring option MaxPermSize=512m; support was removed in 8.0
> [ERROR] Tests run: 1, Failures: 0, Errors: 1, Skipped: 0, Time elapsed: 0.449 s <<< FAILURE! - in org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest
> [ERROR] org.optaplanner.openshift.employeerostering.webapp.skill.SkillRestServiceTest  Time elapsed: 0.448 s  <<< ERROR!
> java.lang.NoClassDefFoundError: org/wildfly/security/permission/AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> Caused by: java.lang.ClassNotFoundException: org.wildfly.security.permission.AbstractNameSetOnlyPermission
>         at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:365)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:272)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:236)
>         at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:159)
> {code}
> With this parent pom:
> {code}
>   <properties>
>     <version.org.jboss.arquillian>1.2.1.Final</version.org.jboss.arquillian>
>     <version.org.wildfly.arquillian>2.1.0.Final</version.org.wildfly.arquillian>
>     <version.org.jboss.resteasy>3.1.4.Final</version.org.jboss.resteasy>
>   </properties>
>   <dependencyManagement>
>     <dependencies>
>       <dependency>
>         <groupId>org.jboss.arquillian</groupId>
>         <artifactId>arquillian-bom</artifactId>
>         <version>${version.org.jboss.arquillian}</version>
>         <type>pom</type>
>         <scope>import</scope>
>       </dependency>
>       <dependency>
>         <groupId>org.wildfly.arquillian</groupId>
>         <artifactId>wildfly-arquillian-container-managed</artifactId>
>         <version>${version.org.wildfly.arquillian}</version>
>       </dependency>
>       <dependency>
>         <groupId>org.jboss.resteasy</groupId>
>         <artifactId>resteasy-client</artifactId>
>         <version>${version.org.jboss.resteasy}</version>
>       </dependency>
> ...
> {code}
> and this child pom:
> {code}
>     <dependency>
>       <groupId>junit</groupId>
>       <artifactId>junit</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.arquillian.junit</groupId>
>       <artifactId>arquillian-junit-container</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.shrinkwrap.resolver</groupId>
>       <artifactId>shrinkwrap-resolver-depchain</artifactId>
>       <type>pom</type>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.wildfly.arquillian</groupId>
>       <artifactId>wildfly-arquillian-container-managed</artifactId>
>       <scope>test</scope>
>     </dependency>
>     <dependency>
>       <groupId>org.jboss.resteasy</groupId>
>       <artifactId>resteasy-client</artifactId>
>       <scope>test</scope>
>     </dependency>
> {code}
> I am probably not using a correct version combination of arquillian and wildfly, but for mere mortals such as myself it takes days to find a working versions combination of arquillian and wildfly - everytime I need to upgrade wildfly. (The arquillian guides and arquillian-showcase-jaxrs are all hopelessly outdated in this aspect, they still mention jboss-as (= wildfly 7)).
> Solution proposal A)
> wildfly-arquillian-managed should automatically detect that it's a wrong version combination and give an error message like "I am not build to work with version x, but it seems like you're combining me with version y."
> Solution proposal B)
> Use the same version numbers for wildfly-arquillian-container-managed (currently 2.1.0.Final) as for wildfly.



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)


From issues at jboss.org  Wed Jan 31 15:45:00 2018
From: issues at jboss.org (Daniel Wiseman (JIRA))
Date: Wed, 31 Jan 2018 15:45:00 -0500 (EST)
Subject: [jboss-jira] [JBoss JIRA] (WFLY-9727) WildFly Randomly Terminates
 after 5-10 minutes
In-Reply-To: <JIRA.12730697.1516830753000@Atlassian.JIRA>
References: <JIRA.12730697.1516830753000@Atlassian.JIRA>
	<JIRA.12730697.1516830753000@jira.app.mwc.hst.phx2.redhat.com>
Message-ID: <JIRA.12730697.1516830753000.20337.1517431500254@Atlassian.JIRA>


    [ https://issues.jboss.org/browse/WFLY-9727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13526923#comment-13526923 ] 

Daniel Wiseman commented on WFLY-9727:
--------------------------------------

[~dmlloyd] I added that flag to my VM arguments in my WildFly server's launch configuration settings within Eclipse, started up my server, and I can no longer load any page from my project from my browser. In the my WildFly logs I noticed a service monitor within my project failed due to an IOException:

{{Caused by: java.io.IOException: Operation failed with status WAITING
	at org.jboss.remotingjmx.RemotingConnector.internalRemotingConnect(RemotingConnector.java:247)
	at org.jboss.remotingjmx.RemotingConnector.internalConnect(RemotingConnector.java:158)
	at org.jboss.remotingjmx.RemotingConnector.connect(RemotingConnector.java:105)
	at javax.management.remote.JMXConnectorFactory.connect(JMXConnectorFactory.java:270)
	at com.soasta.common.diagnostics.jmx.Wildfly10Server.connect(Wildfly10Server.java:90)
	at com.soasta.monitor.resource.ConnectTask.taskExecute(ConnectTask.java:74)
	... 1 more}}

> WildFly Randomly Terminates after 5-10 minutes
> ----------------------------------------------
>
>                 Key: WFLY-9727
>                 URL: https://issues.jboss.org/browse/WFLY-9727
>             Project: WildFly
>          Issue Type: Bug
>          Components: Server
>    Affects Versions: 10.0.0.Final
>         Environment: Running WildFly 10.x from within Eclipse Oxygen (4.7.2) on 2015 MacBook Pro running OS X El Capitan (10.11.6)
>            Reporter: Daniel Wiseman
>            Assignee: Jason Greene
>            Priority: Blocker
>   Original Estimate: 1 week
>  Remaining Estimate: 1 week
>
> I've been experiencing an odd intermittent issue on my WildFly server that has been running on my local system. Every other day or so my server will shutdown, without warning, after running for five to ten minutes from launch. The WildFly server logs contain no errors but the Eclipse logs output these two stack identical stack traces every time:
> {{Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
> 	at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
> 	at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
> 	at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
> 	at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
> 	at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
> 	at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)
> Exception in thread "Remoting "management-client" I/O-1" java.util.concurrent.RejectedExecutionException: XNIO007007: Thread is terminating
> 	at org.xnio.nio.WorkerThread.execute(WorkerThread.java:588)
> 	at org.xnio.AbstractIoFuture.runNotifier(AbstractIoFuture.java:354)
> 	at org.xnio.AbstractIoFuture.runAllNotifiers(AbstractIoFuture.java:233)
> 	at org.xnio.AbstractIoFuture.setCancelled(AbstractIoFuture.java:291)
> 	at org.xnio.FutureResult.setCancelled(FutureResult.java:98)
> 	at org.xnio.nio.WorkerThread$ConnectHandle.forceTermination(WorkerThread.java:339)
> 	at org.xnio.nio.WorkerThread.run(WorkerThread.java:492)}}
> This issue will occur on every server start for an entire day and then the next day it won't happen at all. However, when it happens it makes debugging the software I write that runs of the server near impossible. Does anyone have any ideas what could be causing this issue? Let me know if you need more details, thanks!



--
This message was sent by Atlassian JIRA
(v7.5.0#75005)

